0

我正在开发一个 Android 数据输入应用程序，它将输入的数据保存到一个文件中。A Service（我们称之为它）使用文件名启动，并加载和保存从用户访问FileIOService的每个传递给它的数据。Activity

我正在努力使整个应用程序尽可能健壮，目前我觉得我需要特别注意每个应用程序Activity和Service. 以下是我可以看到的问题：

  • 如果Service被系统杀死，它需要重新启动并打开它打开的文件：我可以使用START_REDELIVER_INTENT.
  • 如果 anActivity被破坏，例如由于方向变化，它需要重新连接到Service.

问题是，一旦 Activity 启动 Service，Service 还需要一段时间才能完成打开文件并为 I/O 请求做好准备。为了解决这个问题，在我的活动中，我有两个：

  • 内部类子类化 ServiceConnection，其onServiceConnected()方法已完成
  • 对 BroadcastReceiver 的匿名内部子类的私有引用，其handleMessage()方法已完成。当服务发出广播以指示它已完成打开其文件时，将调用此方法。

然后这两个方法setUpActivity()都会调用一个从Service. 这就是它开始变得丑陋的地方。因为onServiceConnected()可能在文件准备好 I/O 之前运行，并且handleMessage()可能在Service未绑定到时被调用Activity，所以我必须同时设置handleMessage()并onServiceConnected()设置稍后可以签入的布尔标志setUpActivity()，如下所示：

if ((fileLoaded && serviceConnected))
{
    //access the file data
}

正如我所说，这感觉丑陋和尴尬，并且依赖于设置额外的布尔变量。

还有另一个问题 - 如果我在返回我的应用程序时Activity启动了一个外部应用程序，如相机应用程序，并且两者都可能已被破坏（尤其是在方向改变时）并且应用程序崩溃。ActivityServiceActivity

我的感觉是，我可能会遗漏一些整体模式，这些模式将定义每个模式Activity应该如何与Service.

4

1 回答 1

0

让我们忽略一个事实，即我怀疑这是否是服务的有效用例（其存在只是为了读取和写入文件的服务？）。

如果服务被系统杀死，它需要重新启动并打开它打开的文件：我可以使用 START_REDELIVER_INTENT 来处理这个问题。

该服务没有“被系统杀死”。该进程被系统杀死。这将消除您的活动以及您的服务。

一个可能的例外是如果用户从设置中手动停止服务（并且只有服务），在这种情况下，我不知道预期的行为会是什么。这在当今应该相当少见，尤其是对于用户刚刚使用的应用程序。用户将更倾向于使用任务管理器，例如将您的应用程序从最近任务列表中删除，这将摆脱整个过程，而不仅仅是服务。

如果一个 Activity 被破坏，例如由于方向改变，它需要重新连接到服务。

不必要：

  • 使用Application上下文 ( getApplicationContext()) 而不是Activity直接从

  • 使用保留的片段来维护跨配置更改的绑定

我的感觉是我可能遗漏了一些整体模式，这些模式将定义每个 Activity 应如何与服务相关，反之亦然，同时保持健壮并能够应对意外终止/重启。

这是我试图完全避免绑定模式的众多原因之一。使用服务来处理通过 发送的命令，startService()结果（如果有）由LocalBroadcastManager、Otto 或 greenrobot 的 EventBus 或“真实”广播Intent，或者可能是Messenger. 特别是当服务是 时IntentService，当没有更多工作要做时，服务会很好地自行清理。

于 2013-06-18T13:40:44.793 回答