Even if this thread has accepted answer, feel free to propose other ideas, you do use or like
I've met these articles:
And that lead me to this Google I/O 2010 video about REST client applications
Since now, I've been creating REST component as static component in my Application controller class.
From now, I think, I should change the pattern. Somebody pointed out that Google IOSched application is great sample of how to write REST clients on Android. Somebody else told that this ways is too overcomplicated.
So, can anybody please show us what is the best practice? In short and simple way.
The IOSched application is too complex for sample use-case.
Never use AsynTask to perform network request or whatever that need to be persisted. Async Task are strongly tied to your activity and if the user change the orientation of the screen since the App is re created the AsyncTask will be stopped.
I suggest you to use Service pattern with Intent Service and ResultReceiver. Take a look to RESTDroid. It's a library that allows you to perform any kind of REST request asynchronously and notify your UI with Request Listeners implementing the Virgil Dobjanschi's service pattern.
There is plenty of libraries out there and I'm using this one: https://github.com/nerde/rest-resource. This was created by me, and, as you can see in the documentation, it's way cleaner and simpler than the other ones. It's not focused on Android, but I'm using in it and it's working pretty well.
It supports HTTP Basic Auth. It does the dirty job of serializing and deserializing JSON objects. You will like it, specially if your API is Rails like.
There is another library with much cleaner API and type-safe data. https://github.com/kodart/Httpzoid
Here is a simple usage example
Or more complex with callbacks
It is fresh new, but looks very promising.
EDIT 2 (October 2017):
It is 2017. Just use Retrofit. There is almost no reason to use anything else.
EDIT:
The original answer is more than a year and a half old at the time of this edit. Although the concepts presented in original answer still hold, as other answers point out, there are now libraries out there that make this task easier for you. More importantly, some of these libraries handle device configuration changes for you.
The original answer is retained below for reference. But please also take the time to examine some of the Rest client libraries for Android to see if they fit your use cases. The following is a list of some of the libraries I've evaluated. It is by no means intended to be an exhaustive list.
Original Answer:
Presenting my approach to having REST clients on Android. I do not claim it is the best though :) Also, note that this is what I came up with in response to my requirement. You might need to have more layers/add more complexity if your use case demands it. For example, I do not have local storage at all; because my app can tolerate loss of a few REST responses.
My approach uses just
AsyncTask
s under the covers. In my case, I "call" these Tasks from myActivity
instance; but to fully account for cases like screen rotation, you might choose to call them from aService
or such.I consciously chose my REST client itself to be an API. This means, that the app which uses my REST client need not even be aware of the actual REST URL's and the data format used.
The client would have 2 layers:
Top layer: The purpose of this layer is to provide methods which mirror the functionality of the REST API. For example, you could have one Java method corresponding to every URL in your REST API (or even two - one for GETs and one for POSTs).
This is the entry point into the REST client API. This is the layer the app would use normally. It could be a singleton, but not necessarily.
The response of the REST call is parsed by this layer into a POJO and returned to the app.
This is the lower level
AsyncTask
layer, which uses HTTP client methods to actually go out and make that REST call.In addition, I chose to use a Callback mechanism to communicate the result of the
AsyncTask
s back to the app.Enough of text. Let's see some code now. Lets take a hypothetical REST API URL - http://myhypotheticalapi.com/user/profile
The top layer might look like this:
Note that the app doesn't use the JSON or XML (or whatever other format) returned by the REST API directly. Instead, the app only sees the bean
Profile
.Then, the lower layer (AsyncTask layer) might look like this:
Here's how an app might use the API (in an
Activity
orService
):I hope the comments are sufficient to explain the design; but I'd be glad to provide more info.
Disclaimer: I am involved in the rest2mobile open source project
Another alternative as a REST client is to use rest2mobile.
The approach is slightly different as it uses concrete rest examples to generate the client code for the REST service. The code replaces the REST URL and JSON payloads with native java methods and POJOs. It also automatically handles server connections, asynchronous invocations and POJO to/from JSON conversions.
Note that this tool comes in different flavors (cli, plugins, android/ios/js support) and you can use the android studio plugin to generate the API directly into your app.
All the code can be found on github here.
"Developing Android REST client applications" by Virgil Dobjanschi led to much discussion, since no source code was presented during the session or was provided afterwards.
The only reference implementation I know (please comment if you know more) is available at Datadroid (the Google IO session is mentioned under /presentation). It is a library which you can use in your own application.
The second link asks for the "best" REST framework, which is discussed heavily on stackoverflow. For me the application size is important, followed by the performance of the implementation.
Therefore I stick to org.json or GSON for complexer scenarios. For the architecture of an org.json implementation, I am using a static class which represents the server use cases (e.g. findPerson, getPerson). I call this functionality from a service and use utility classes which are doing the mapping (project specific) and the network IO (my own REST template for plain GET or POST). I try to avoid the usage of reflection.