REST API Client Library for Android

Question

We are building a location based messaging app which uses Parse.com as back-end (Parse.com is similar to Urban Airship/PubNub, etc) and we now want to switch to our own back-end for better control. For this, we have built a node.js based back-end with functionality exposed over REST API

To consume this API, we want to build an Android library (similar to Parse.com's Android SDK) which abstracts all the HTTP Requests/Response or REST API calls and provides direct functions for various operations like getUsers(), sendMessage(), etc

Ways to implement REST API Client in Android :

• Using IntentService + ResultReceiver
• Service
• AsyncTask
• Using Loaders

Now, considering that we want to build an android library and there could be simultaneous REST API calls while the user is interacting with the app, which approach would be the best to go ahead with ? I am open to other suggestions / recommendations as well.

UPDATE: We first built our own library using IntentService + ResultReceiver which worked fine. But we later stumbled across Android Async Http. Use it. It's awesome!

Answer 1

Best implimentation I have seen based on Google IO Pro Tips 2010 is the RoboSpice library, which is REST based and very cleverly works with the Activity lifecycle as to not leak memory.

Quick infographic the library is here

• Loaders are designed for database, not REST, they are reset on activity reset meaning you loose your data.
• Async task, just no.
• Intent Service + Result receiver is basically how RoboSpice work, so if you are building your own lib, I would take this approach!
• Service is also good, similar to the IntentService Method, but IntentService works a little better in this instance.

The Service method maybe better, look at the robospice service they use an ExecutorService which terminates the Service when it has run out of Requests to work through, this is more Java concurrency than Android specific. Main thing to note that the service runs whilst processing requests then terminates its self if their are none left.

The advantage of using the ExecutorService or any type of thread pool, is that you can define how many requests you can run at once. unless you have a very fast connection 2-4 is the most i would ever suggest.