我暂时使用了Loaders API＆＃39}。我找到了很好的解决方案和最优雅的设计来解决大多数应用程序的一般问题：显示＆＃34;处理＆＃34;动态内容对Fragment / Activity的干扰最小 - 加载数据的责任以及封装在Loader中的所有逻辑......
当从加载器返回的数据初始化UI时触发问题，触发更改它初始化的相同数据。
为了更清楚，让我们说我们的主要活动或片段显示无尽的帖子列表（如Facebook或Google+应用）。我们假设此应用使用某种AsyncTaskLoader或CusorLoader：
显示帖子列表的ListView将在Activity生命周期的正确时间使用加载器数据进行初始化。
现在让我们说同时收到GCM推送，并触发对数据源的更新。仍然一切都很好：加载器将通过数据更改来更新活动。
在下面的扩张中，事情变得越来越混乱：1）用户点击＆＃34;喜欢＆＃34;其中一个帖子的按钮
2）后台任务/服务启动网络操作以更新服务器上的帖子状态
3）UI应立即更改（适配器通知数据集已更改），而无需等待网络响应，因为用户必须知道发生了某些事情（可能也不是全屏阻止进度条）
4）网络请求已完成（未必成功）
在以下各方面的事情中，各个方面的控制都很快失控：
假设要在装载机的专属责任中更新的相同小部件被迫在本地更新，以反映不一定是＆＃34; final＆＃34;的临时状态。数据源的状态（例如 - 如果网络响应因各种原因而失败..）
现在让我们说网络操作尚未完成并且仍在飞行中，并且由于另一个原因（GCM推送/正在执行中的其他后台操作），Loader重新加载并通知活动有新数据。现在它已经非常不舒服了：有一个新的数据，但UI仍处于我前面描述的模式。我发现自己实现了解决此类冲突的逻辑，并决定UI是否需要对加载器数据源作出反应。
现在，您可以对帖子执行的操作量以及帖子数量存在多个问题。
出于这种原因，我的结论是，当数据源可以从一个＆＃34;写入＆＃34;中解决时，Loader是一个非常有问题的解决方案。从此数据源初始化的相同UI触发的操作。
但是，另一方面，我没有看到任何其他解决方案，以优雅的设计处理我描述的问题，尽管这是一种非常常见的情况。
我的问题主要是：
在我描述的这种情况下，是否有关于如何使用加载器的指导原则？
是否有更好的解决方案/ API组件或设计我没有考虑解决此类要求？
提前感谢，
答案 0 :(得分：0)
Loader是非常有问题的解决方案的情况并非如此。相反，Web服务调用和推送通知是异步，以及将这些调度传递的结果数据集成到现有数据集中的问题（并在Activity / {{1生命周期）是一个复杂的情况，框架试图尽可能地简化和概括。这些概括是Fragment，LoaderManager和ContentProvider类及其相关技术。
在没有看到任何现有代码或提出任何其他高级解决方案的情况下，这是我可以敦促您尝试的最简单的方法（如果您还没有尝试过）：每当网络服务呼叫完成或收到通知后，请致电
SyncAdapter或
Loader.reset();
并确保将LoaderManager.restartLoader();
清除为
Adapter这会将新添加的数据加载到视图中。在异步任务完成时刷新数据集是程序员的职责。