Is the rest client app design approach in google io 2010 still up to date?

Question

two years past, there comes fragment, intent service, cursor loader. Is the approach still up to date, or is there any better or mature pattern to design an android rest client, especially compare to the option B (I don't have the privilege to post image, instead the image could be found from this post).

I know the content provider part is essential. what about the service helper and service component? Up till now, the startService method is a nature of Context or its subclasses. which means the service helper would be an activity. So is it elegant to initiate an activity from a content provider, or should it be initiate from the activity on the top.

• for those of you who digged into the google io 2011 iosched app source code, will you consider the static class SyncStatusUpdaterFragment in HomeActivity as the service helper, though it couldn't start the SyncService, but it does listen to the call back from SyncService and trigger refresh of UI. So could it be seen as a variance of the Virgil Dobjanschi's approach?

There comes service, intent service, asyncTask and thread. In my opinion, the intent service is suitable for sync of mega pack of data from remote server. That why they use it in the iosched. But the common scenario is that only a part of items will be synchronized with the remote server. So the intent service is too heavy. even the service approach. could we just use the asyncTask or thread in the content provider or some component of that to accomplish this kind of task. Or is there any convincing reason to use the service, and go through the service helper-service-processor path. I am talking about a serious application.

so what's you opinion?

Answer 1

So is it elegant to initiate an activity from a content provider, or should it be initiate from the activity on the top.

You'll never ever initiate an activity from the content provider. Everything should start from your activity, whether that's a AsyncTask, Service, or Content Provider request...

AsyncTasks are generally a poor choice. They're simply flawed when it comes to dealing with configuration changes (i.e. screen orientation change). Loaders are the solution to this, but the difficult part is wrapping that together with your network calls. One solution is to build the network calls from a custom loader (subclassing AsyncTaskLoader).

However, in my case, I followed the 2010 Google IO presentation. Built a class, ServiceHelper, to manage requests to the server in a Service object (which launches threads to perform network queries). The ServiceHelper manages the ResultReceivers which can be created from the calling Activity. This allows the activity to listen to events from the Service request such as when the query starts and finishes (or when it errors out). These threads will call their network queries and then store the resulting data in a ContentProvider (for caching and to use across multiple Activities if necessary).

At the same time, I have a CursorLoader on the Activity that listens to the endpoint which the network thread will write to. Obviously there's a lot of middle ground to work out yourself.. such as your caching policy and the overhead for such an implementation. But that really depends on the app you're building and the API you're integrating with.

So yes, I think that the 2010 presentation is still valid.. there were a lot of vague areas of his presentation and the continues today. You'll have to still work out a design that works for your app

Hopefully, my thoughts will help you get started..