应该使用Loaders来访问Web服务吗？

据我所知，Loader框架适用于访问本地存储在ContentProvider/SQLite数据库中的数据。我们有CursorLoader类可以很好地处理这个用例。应该使用Loaders来访问Web服务吗？

但我不知道使用Loader框架编写扩展Loader/AsyncTaskLoader以访问远程Web服务（例如REST Web服务）的类是否实用？我一直认为这个框架对于这个用例来说过于僵硬和混乱（缺乏适当的文档）。我更喜欢使用AsyncTasks/Services更经常地处理REST调用。但是最近我发现了一些使用AsyncTaskLoaders的文章，并开始怀疑。

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

来源

2013-05-12 Zsombor Erdődy-Nagy

你可以分享你所指的教程吗？ – 2013-05-12 18:54:38

在这里你可以去：http://neilgoodman.net/2011/12/26/modern-techniques-for-implementing-rest-clients-on-android-4-0-and-below-part-1/ – 2013-05-12 18:56:42

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

如果您希望在更改活动或背景应用程序时允许加载继续，那么服务就是要走的路。或者，如果您想导出您的服务，以便多个应用程序可以使用它。否则，请使用Loader或AsyncTaskLoader。

与AsyncTasks相比，装载机有几个优点。

它们不太可能在Activity完成后通过执行代码导致崩溃，因为他们知道android生命周期。
该设计不鼓励参考View或活动。这可以降低强制Activity在完成后保留在内存中的可能性。
监视数据源的更改并在发生触发时触发回调
它们内置了可在循环后有用的高速缓存。对于Cursor秒，CursorLoader自动重新连接在正确的位置上一个光标加载

不过，他们也有缺点

的API是极其较为繁琐超过AsyncTask。特别是如果你关心与旧版Android的兼容性
你已经将UI状态存储在onSaveInstanceState（）中，所以使用Loader可以让你以多种方式保存状态。这可能会令人困惑，阅读和理解。特别是如果你最终混合残留的碎片。
的Loader缓存加载的结果，而不是UI状态，你实际上需要

我假设你只是从Web服务读，不写。如果您正在执行Web服务的更新，并且您需要查看服务的响应，那么这会改变事情。使用AsyncTask可能会阻止您获得响应，如果在循环过程中收到响应。

来源

2013-05-12 18:52:16

有些情况下Loader适合web服务：当您的服务器可以发送推送通知回到客户端，通知数据已更改。

来源

2014-05-28 06:34:54 AVEbrahimi

应该使用Loaders来访问Web服务吗？

回答

相关问题