AsyncTaskLoader如何缓存数据?

时间:2012-08-02 23:00:46

标签: android android-fragments asynctaskloader

我有一个活动,它实现了所有这些代码所在的片段。通过示例可以最好地解释这一点,因为代码是保密的。这个例子反映了我想要做的事情和我通过测试观察到的事情

ex。)我有一个rss阅读器片段,它从两个带有Loader Id(Loader 1,Loader2)的独特Loader中获取两个唯一对象(A,B)

Object A: 

int[] fullArticleIdList;
List<ArticlePreview> partialArcticlePreviewList;

Object B:

List<ArticlePreview> partialArcticlePreviewList;

在创建时,我在Loader 1上调用“initloader”来获取对象A.滚动浏览可用文章后,它会触及从对象A返回的partialArcticlePreviewList的底部,并使用“在Loader 2上获取对象B的重新启动器”来获取更多文章。允许用户阅读它们并继续为所有文章执行此操作。

这样可以正常工作,直到用户旋转设备,从而调用onCreate。现在当在Loader 1上调用initloader时,它会在连接到loader 1后立即跳转到onLoadFinished并返回一个Loader 1.当正确返回articleIds时,返回的partialArcticlePreviewList是从Loader 2获取对象B的那个。

loader manager是否只在缓存中保留一个对象实例并在多个加载器之间共享?从广泛的测试(5个多小时试图找到问题并查看Eclipse调试器中的加载器ID /缓存/地址)看来,它覆盖了Loader 1的partialArcticlePreviewList以及它在Loader 2的partialArcticlePreviewList中收到的数据。虽然这种情况对于单个Loader来说是理想的,但我认为每个Loaders的缓存都是独立的。显然,加载器的一个优点是它们易于使用和通过屏幕旋转和数据缓存持久化,但它似乎并不像隐含的那样工作。我们通过保留片段的实例并在onCreateView和onDestroyView中编写适当的代码以避免内存泄漏来规避问题,但这是一个很好的解决方案吗?

编辑:忘记添加,我们正在使用兼容性库v4。此外,查看加载器的android源代码似乎没有说明为什么加载器返回错误的数据为“mId”的情况。

1 个答案:

答案 0 :(得分:3)

用于解决此问题的最终解决方案只是自己管理数据而不依赖于加载器。

当加载程序只为屏幕加载一个东西时,加载程序可以很好地保留数据,但是对于分页,它们创建了所有这些麻烦,它们的运行方式仍然不是很清楚;结论是它们没有按预期运行或者我们的实现是错误的,只有在更高级的用例中才会显现出来。

为了自己管理数据,我们使用捆绑/保留片段的组合,同时小心地在onDestroyView中正确清理所有内容。我们还使加载器检查我们的数据集在旋转后执行回调时是否已经有数据,因此我们不会将分页数据两次添加到数据集中。另一种选择是使用单例对象。

希望将来可以帮助其他人。