使用游标加载器进行排球或服务

Question

当我从Web服务下载数据时,我几乎总是使用服务.我将结果存储在数据库中,并使用游标加载器在我的视图中显示结果.但谷歌发布网络库后,我已经变得有些困惑了.排球库使用异步任务而不是服务,它不使用游标.我认为我应该避免异步任务并将我的数据存储在数据库中,以便我可以正确处理方向更改 - 而不会丢失数据并且需要再次下载数据.所以我的问题是,我什么时候应该使用Volley而不是我自己的下载策略？

Answer 1

传统拱门

就个人而言,过去我发现使用服务实施起来很麻烦,但最终结构良好,并且是一种良好的一致体验.但线程性能......难以管理.

服务 查询 - >数据库加载 - >通知

UI 启动查询和游标加载 - >更新ui.

仅排球

对于凌空,很容易跳过先前在服务和数据库中处理的整个组件.

UI 排球请求 - >排球响应 - >更新ui

但是,根据您尝试显示的数据,甚至您要查询的服务器是否满足以下任何要求,这会很快崩溃

• 显示的数据没有完全由相同的URL描述(例如页面)

用户可能向下滚动并拉入更多页面.但是,当用户返回活动或甚至只是旋转时,对Volley的调用将仅返回初始页面的结果,除非您特别记住该页面包含的所有其他查询.对于一个更方便的架构来说,这会成为很多工作.或者甚至是稍微不同的页面,如果他们所做的只是旋转手机,这对用户来说可能是不一致的体验.

• 必须修改数据

在本地应用更改然后随时应用于服务器更容易.仅使用齐射,您必须同步执行REST更新和重新查询(以前的所有查询).

• 速度和持久性

排球真的很快.但是,除了可用的缓存命中之外,它缺少任何持久性,这可能取决于您要查询的服务器.积极的缓存甚至会对您的应用程序造成严重破坏.在浏览可能实际引用过去查询中的数据的多个活动时,从本地数据库中提取可提供一致且快速的体验.纯粹的排球体验可能要求您从先前的查询中查询技术上已有的数据,但没有中央数据存储来从中获取数据.

混合排球和光标

这些天我实际上跳过了服务部分,但其他一切仍然来自传统的拱门

UI启动齐射查询和游标加载 - >更新ui

排球查询 - >更新数据库 - >通知

此外,没有什么能阻止你使用ui ping服务然后服务使用凌空......看起来更传统可能有价值将更多的控制逻辑移动到更集中的地方,但事实上它是从一个内部运行的"服务"实际上没有技术优势.

摘要

我希望有所帮助.基本上,不要试图只是排球,我试过,如果这对你有用,那么这将是一个非常具体和简单的应用程序,并希望我已经确定了主要的陷阱.

此外,我发现了与robospice相同的陷阱,尽管它正在服务......但是...... YMMV

Answer 2

Volley只是一个辅助层,用于与管理线程和内容的服务器进行通信.是的,它已经实现了很好的线程缓存和东西.但您不必在活动中使用它.我甚至会说你不应该.我们都知道服务实际上是进行任何后台网络工作的地方.它旨在经受配置更改,是您的应用程序声明它在后台工作的自然方式,系统应特别小心.

想象一下,没有Volley.你会怎么做？我打赌你会在服务中使用线程支持,这对(我们都知道服务在主线程上运行)？它可能像IntentService一样简单,它是一个静态工作线程和一个处理程序.或者您可能会喜欢并使用ExecutorService来拥有一个线程池.或者你可以疯狂,new Thread()每次都开始onStartCommand().无论适合您的需求和品味.

所以我更喜欢将Volley视为完成这项任务的另一种方式.这次你不需要自己做任何线程的工作,你只需让Volley为你做.

所以底线是使用Volley AND Service.