谷歌io 2010中的其他客户端应用程序设计方法是否仍然是最新的？

Question

两年过去了,有片段,意图服务,游标加载器.方法是否仍然是最新的,或者是否有任何更好或成熟的模式来设计Android休息客户端,特别是与选项B相比(我没有权限发布图像,而是可以从这篇文章中找到图像).

我知道内容提供商部分是必不可少的.那么服务助手和服务组件呢？到目前为止,startService方法是Context或其子类的本质.这意味着服务助手将是一项活动.因此,从内容提供商发起活动是优雅的,还是应该从顶部的活动开始.

• 对于那些深入研究google io 2011 iosched应​​用程序源代码的人,您是否会将HomeActivity中的静态类SyncStatusUpdaterFragment视为服务帮助程序,虽然它无法启动SyncService,但它会收听来自SyncService的回调,触发UI的刷新.那可能被视为Virgil Dobjanschi方法的变化吗？

有服务,意图服务,asyncTask和线程.在我看来,意图服务适合于从远程服务器同步大量数据.这就是为什么他们在iosched中使用它.但常见的情况是只有部分项目将与远程服务器同步.意图服务太沉重了.甚至是服务方式.我们可以只使用内容提供程序中的asyncTask或线程或其中的某个组件来完成此类任务.或者是否有任何令人信服的理由使用该服务,并通过服务助手服务处理器路径.我说的是一个严肃的申请.

你有什么看法？

Answer 1

那么从内容提供者发起一个活动是否优雅，或者应该从顶部的活动发起。

您永远不会从内容提供商发起活动。一切都应该从您的活动开始，无论是 AsyncTask、服务还是内容提供商请求......

AsyncTasks 通常是一个糟糕的选择。它们在处理配置更改（即屏幕方向更改）方面存在缺陷。加载器是解决这个问题的方法，但困难的部分是将其与网络调用包装在一起。一种解决方案是从自定义加载程序（AsyncTaskLoader 的子类）构建网络调用。

然而，就我而言，我关注了 2010 年 Google IO 演示。构建了一个 ServiceHelper 类来管理 Service 对象中对服务器的请求（它启动线程来执行网络查询）。ServiceHelper 管理可以从调用 Activity 创建的 ResultReceiver。这允许活动侦听来自服务请求的事件，例如查询何时开始和完成（或何时出错）。这些线程将调用其网络查询，然后将结果数据存储在 ContentProvider 中（用于缓存并在必要时跨多个 Activity 使用）。

同时，我在 Activity 上有一个 CursorLoader，它监听网络线程将写入的端点。显然，有很多中间立场需要您自己解决。例如您的缓存策略和此类实现的开销。但这实际上取决于您正在构建的应用程序以及您正在集成的 API。

所以，是的，我认为 2010 年的演讲仍然有效。他的演讲有很多模糊的地方，今天仍在继续。您仍然需要制定适合您的应用程序的设计

希望我的想法能帮助您开始。