android - 带有游标加载器的 Volley 或 Service

Question

当我从网络服务下载数据时，我几乎总是使用服务。我将结果存储在数据库中，并使用游标加载器在我的 View 中显示结果。但是在 Google 发布网络库 Volley 之后，我变得有点困惑。 volley 库使用异步任务而不是服务，并且不使用游标。我认为我应该避免异步任务并将我的数据存储在数据库中，以便我可以正确处理方向变化 - 而不会丢失数据并且不需要再次下载数据。

所以我的问题是，什么时候应该使用 Volley 而不是我自己的下载策略？

Answer 1

传统拱门

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

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

用户界面启动查询和游标加载 -> 更新用户界面。

仅截击

对于 volley，很容易跳过之前在服务和数据库中处理的整个组件。

用户界面Volley 请求 -> Volley 响应 -> 更新 ui

但是，根据您尝试显示的数据，甚至可能是您针对以下任何要求查询的服务器，这很快就会崩溃

• 正在显示的数据未由相同的 URL(例如页面)完整描述

用户可能会向下滚动并拉入更多页面。然而，当用户返回 Activity 或什至只是简单地旋转时，对 Volley 的调用将仅返回初始页面的结果，除非您特别记住该页面包含的所有其他查询。对于一个旨在更方便的架构来说，这变成了大量的工作。甚至是略有不同的页面，如果用户所做的只是旋转手机，这对用户来说可能是一种不一致的体验。

• 需要修改数据

在本地应用更改然后在任何时候应用到服务器更容易。仅使用 volley，您必须同步进行 REST 更新和重新查询(所有先前的查询)。

• 速度和毅力

Volley 真的很快。但是，它缺乏任何持久性，除了可用的缓存命中率取决于您正在查询的服务器。激进的缓存甚至会使用陈旧的数据对您的应用造成严重破坏。在浏览可能实际引用过去查询中的数据的多个 Activity 时，从本地数据库中提取数据可提供一致且快速的体验。纯粹的 volley 体验可能需要您查询技术上已经从以前的查询中获得的数据，但没有中央数据存储来获取这些数据。

混合 Volley 和光标

这些天我实际上跳过了服务部分，但其他一切都来自传统架构

UI发起volley查询和游标加载->更新ui

齐发查询 -> 更新数据库 -> 通知

此外，没有什么可以阻止您让 ui ping 一个服务，然后该服务使用 volley...它看起来更传统，将更多的控制逻辑移动到更集中的地方可能是有值(value)的，但事实上它正在运行从“服务”内部实际上没有提供任何技术优势。

总结

希望对您有所帮助。基本上，不要只尝试 Volley ，我试过了，如果这对你有用，那将是一个非常具体和简单的应用程序，希望我已经找出了主要的陷阱。

此外，尽管 robospice 在服务中，但我发现了同样的陷阱......但是...... YMMV