从本地服务沟通进度

Question

我正在构建的应用程序使用本地Service将文件从网络下载到手机的SD卡。在这个应用程序中，用户可以浏览书籍列表，并在线阅读。用户还可以下载pdf副本以供离线查看。

要处理下载，我使用的是本地绑定Service。我不希望这个Service一直运行，只有在下载文件时。因此Service可以在其任务完成时自行关闭，我不绑定服务，而是通过传递给Context.startService的Intent发送“enqueue for download”命令。

可供下载的书籍显示在列表中。用户可以通过点击列表中的行来选择下载图书。在下载时，我需要在实际的书籍列表行上使用ProgressBar来显示下载进度。我还需要在行上显示一本书是否可以下载，或者下载是否已完成或失败。例如，书籍可以在整个应用程序中以不同的活动显示 - 例如在搜索中或在用户喜爱的书籍列表中。当书籍显示在不同的地方时，这些不是同一个对象，但它们的唯一标识是bookId。

因为我不想从每一个Activity绑定到服务，我的设想是使用一个public static final HashMap上Service类本身包含的bookId映射下载状况，排队，下载，取消了enum，等等。每个书籍视图在显示时都会检查该静态HashMap，并且如果bookId在地图中，则检索并显示其状态。我并不特别喜欢这个想法，但目前这是我能想到从服务中检索状态的唯一方式，而不必绑定到它并启动它。

此外，如果是活动下载，我需要从Service获取下载进度百分比，对于给定的bookId。再次，我宁愿不从任何活动绑定到服务，所以我不知道如何去从Service检索当前的进度。我目前的计划是使用某种单身中介，Service将推送更新，并且可以读取视图。但我对这个想法并不满意。

我想避免绑定到每个Activity的Service的原因是1.）我已经在运行另一个Service和2.）绑定是冗长的，我想避免需要传递引用到Service（但毫无疑问，这不是太多问题）。

也许绑定到本地Service是不是足够昂贵，以保证这种其他设置？我不应该关心每个Activity的绑定吗？也许这是一个非问题？

Answer 1

我想避免结合 从每个活动服务的原因是 1）我已经运行的其他服务

然后考虑两者结合。

2。）结合是冗长，我想避免需要围绕一个 引用传递到服务

每一项活动都应该有自己的连接服务。

也许绑定到本地服务 是不是足够昂贵，以保证此 其他设置？

绑定到本地服务的行为是很便宜的。