是否应该使用Loaders访问Web服务？

Question

据我所知,Loader框架适用于访问ContentProvider/SQLite数据库中本地存储的数据.我们有CursorLoader类可以很好地处理这个用例.

但我想知道使用Loader框架编写扩展Loader/AsyncTaskLoader以访问远程Web服务(例如REST Web服务)的类是否切实可行？我一直认为这个框架对于这个用例来说有点过于僵化和混乱(缺乏适当的文档).我更喜欢使用AsyncTasks/Services以更常规的方式处理REST调用.但最近我发现一些使用AsyncTaskLoaders的文章并开始怀疑.

那么为什么有人会使用Loaders来访问Web服务呢？我在这里看到的唯一优势是装载机自动保留其结果.之后没有Cursor可以管理.

Answer 1

实际上,您可能想要使用像Volley这样的网络库.这有一些很好的功能,如请求批处理和图像缓存.尽管如此,为了争论,我们可以比较Service,Loaders和AsyncTask.

如果要在更改活动或后台应用程序时允许加载继续,则可以使用服务.或者,如果要导出服务,以便多个应用程序可以使用它.否则,请使用Loader或AsyncTaskLoader.

与AsyncTasks相比,Loaders有一些优势.

• 在Activity完成后,它们不太可能通过执行代码导致崩溃,因为他们知道android生命周期.
• 该设计不鼓励引用Views或Activities.这减少了在活动完成后强制活动停留在内存中的可能性.
• 监视数据源的更改并在发生回调时触发回调
• 它们内置了缓存,在旋转后很有用.对于Cursors,CursorLoader自动将正确位置重新连接到最后加载的Cursor

但是,它们也有缺点

• API是非常繁琐的多比AsyncTask.特别是如果您关心与旧版Android的兼容性
• 您已经在onSaveInstanceState()中存储UI状态,因此使用Loader's会导致您以多种方式保存状态.阅读和理解这可能会令人困惑.特别是如果你最终将保留的碎片混合到混合物中.
• 在Loader您的实际需要高速缓存加载的结果,而不是UI状态

我假设你只是从网络服务阅读,而不是写作.如果您正在对Web服务执行更新,并且需要查看服务的响应,那么这会改变一些事情.AsyncTask如果在轮换期间收到响应,则使用an 可能会阻止您获得响应.