谷歌IO2010年的REST客户端应用程序设计方法仍然适用吗？

Question

谷歌IO2010年的REST客户端应用程序设计方法仍然适用吗？

9

两年过去了，出现了片段、意图服务和游标加载器。这种方法仍然适用吗？或者有没有更好或更成熟的模式来设计Android REST客户端，特别是与选项B进行比较（我没有发布图片的特权，但可以在this post中找到图片）。

引用：我知道内容提供程序部分很重要。那么服务助手和服务组件呢？到目前为止，startService方法是Context或其子类的一种自然形式。这意味着服务助手将是一个活动。因此，从内容提供程序启动一个活动是否优雅，还是应该从顶部的活动启动？

对于那些挖掘google io 2011 iosched app source code的人，你们是否认为HomeActivity中的静态类SyncStatusUpdaterFragment是服务助手，尽管它无法启动SyncService，但它确实会监听来自SyncService的回调并触发UI的刷新。所以它可以被看作是Virgil Dobjanschi方法的一种变体吗？

有服务、Intent Service、AsyncTask和线程。在我看来，Intent Service适合从远程服务器同步大量数据。这就是为什么他们在iosched中使用它的原因。但是通常情况下，只有部分项目将与远程服务器同步。因此，Intent Service太重了，即使是服务方法也是如此。我们能否只使用AsyncTask或线程在内容提供程序或某些组件中完成这种任务？或者是否有令人信服的理由使用服务，并通过服务助手-服务处理器路径进行操作。我谈论的是一个严肃的应用。

那你的意见是什么？

- Ren Ji

我对Android/REST开发太新了，无法回答你的问题，而且我自己也很难想出一个好的应用程序架构，但也许下面的链接可以帮到你（还有第二部分）：http://neilgoodman.net/2011/12/26/modern-techniques-for-implementing-rest-clients-on-android-4-0-and-below-part-1/ - yniq

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- kwazi · Accepted Answer

从内容提供者启动活动是否优雅，还是应该从顶部的活动开始？

永远不要从内容提供者启动活动。一切都应该从您的活动开始，无论是AsyncTask、Service还是Content Provider请求...

AsyncTasks通常是一个糟糕的选择。当涉及到配置更改（例如屏幕方向更改）时，它们很容易出现问题。Loaders是解决此问题的方法，但困难的部分是将其与网络调用结合起来。一种解决方案是从自定义加载器（子类化AsyncTaskLoader）构建网络调用。

然而，在我的情况下，我遵循了2010年Google IO演示。构建了一个类ServiceHelper，在Service对象中管理对服务器的请求（启动线程执行网络查询）。ServiceHelper管理可以从调用活动创建的ResultReceiver。这允许活动监听来自Service请求的事件，例如查询何时开始、完成（或错误时）。这些线程将调用它们的网络查询，然后将结果数据存储在ContentProvider中（以进行缓存并跨多个活动使用，如果需要）。

同时，在Activity上有一个CursorLoader，监听网络线程将写入的终点。显然，仍有很多中间地带需要自己解决...例如缓存策略和实现的开销。但这真的取决于您正在构建的应用程序和您正在集成的API。

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

希望我的想法能帮助您入门...