Loader框架与普通的AsyncTask

Question

在我的应用程序中,我需要很多CRUD东西:从本地SQLite数据库读取记录,插入对象和更新东西.大多数查询都非常简单,即使在UI线程上运行它们也不会阻塞,但是在这个应用程序中我想采用Windows Phone模式:一个out动画立即开始,动画在结果传递时开始动画.

我计划使用一个AsyncTask用于工作,但我注意到Honeycomb(和compat包)引入了这个新的Loader框架.主要优势似乎是Loader生存配置加载的数据发生了变化.该LoaderEx通过SQLite和框架之间的桥梁Commonsware项目,但有些问题出现.

1. 资源清理:我使用单个活动,创建SQLiteOpenHelper onCreate()并关闭它onDestroy().由于加载程序管理器可能仍在运行,我检查它并pendingClose在我的回调对象上设置一个标志,因此它将在加载完成时关闭游标和帮助程序.我认为不关闭数据库是没有害处的,但SQLite抱怨如果你不这样做,我不喜欢错误消息:)这里的重点是数据不能在配置更改中存活,因此Loader优势消失

2. 我应该创建多少个装载机？假设我有心爱的Customer人和Order桌子.装载机被认定ID就像CUST_L和ORD_L,但每次用户点击一些总结的时间我想与细节的屏幕带来.我应该restart是一个装有不同参数的装载机,还是应该init是一个带有随机ID的新装载机？这可能会发生几十次.Loader框架是针对许多小型运行的作业,还是仅针对一些长时间运行的任务？

3. ID在LoaderCallbacks界面内使用s 的目的是什么？为什么不简单initLoader(params, callback)？我不认为可以在回调中重用一些逻辑:最终他会分支(带ID if-else或switchID),所以我不明白给回调对象赋予标识符的意义,而不是一个天真的方法-每次操作回调.

我问这个是因为整个框架似乎对我来说过于工程化而没有实际效用.我不明白用a集中代码的意义LoaderManager,我看不出任何新的机会AsyncTask没有提供.

唯一的胜利点是配置改变生存,但由于资源清理我无法利用它,我无法找出另一种方法来关闭SQLiteOpenHelper因为(很明显)SQLiteCursorLoader需要它但是清理它取决于用户.所以AsyncTask看起来似乎是赢家的选择,但也许我错过了一些东西.

Answer 1

1. 内容提供者比“原始数据库”方法强大得多。stackoverflow 上的很多链接都引发了对此的讨论。
2. LoaderManager 尝试通过 ID 来区分加载程序（这就是 initLoader 的签名指定此参数的原因）。如果具有特定 ID 的加载器的数据已经存在，则需要加载器的 ID 来重新传递缓存结果（因此无需再次异步重新加载）。
3. restartLoader 调用强制 LoaderManager 启动先前创建的加载程序指定的异步操作。initLoader 在创建新加载器之前尝试重用现有加载器。
4. Fragment 和 Activity 都有自己的 LoaderManager，且不重叠。

我的经验表明，尽管使用内容提供程序听起来实施起来有点大材小用，但它实际上在未来会带来很好的回报。性能影响微不足道（尝试测量它），UI-Data 绑定是开箱即用的（因为内容观察器和 CursorLoaders 能够订阅 Uri 通知），框架通过加载器实现同步性。恕我直言，每当需要数据库时，大多数时候使用带有加载器的内容提供程序是您能想到的最佳解决方案。

其他涉及直接使用数据库的场景将迫使您手动实现所有操作。