There are lot of discussion about REST client implementation in android, based on the talk at GoogleIO 2010, by Virgil Dobjanschi. My requirement may not necessarily involved, as I have some freedom to choose the configuration.
I only target tablets
configuration changes can be prevented if no other easy way (fix at Landscape mode etc)
I am trying to achieve.
Basic CRUD operation to my server (JSON RPC/ REST). Basically mimic an ajax request from android app (no webview, need native app)
Based on the above mentioned talk, and some reading I see these options.
Implement any of the 3 mentioned in the Google IO talk
Especially, the last pattern may be more suitable as I don't care much of caching. But not sure how "real time" is sync implementation.
Use HTTP request in AsyncTask. Simplest, but need to avoid re-sending request during change in device configuration (orientation change etc). Even if I fix at one orientation, recreation of activity still happens. So need to handle it elegantly.
Use service to handle http request. So far, it say use service for long ruiing request. Not sure whether it is a good approach for simple GET/POST/PUt requests.
Please share your experience on what could be the best way.
EDIT:
Further search reveal some nice posts and code samples.
Spring for Android
RoboSpice
Using Loader
Using service
I am thinking about doing it through service. Please comment your suggestions.
Related
I am a Java developer with no Android experience, and I am trying to quickly put an app together. It seems that what I would normally do in Java isn't helping.
At this stage, ease of implementation is more important than efficiency or style - I will sort the latter out when there is more time and I will have educated myself properly when it comes to Android.
People can use the app to ask for support, or offer it to those who need it. Asking for support posts a request with the details to the server, and that's done.
Now I would like the app to post an asynchronous request to the server, to be notified of outstanding support requests once a minute. I guess it's the same principle of WhatsApp checking if there is any new message on the server.
I tried doing that in a separate thread with an infinite loop which sleeps for 60 seconds but for some reasons that stops the UI from working.
From what I now understand, I should use a service with a Looper, a Timer and a Handler. Is that correct?
Could anybody point me to a tutorial which explains exactly what to do, step by step? Or at least suggest keywords I should look for?
All I found so far are snippets of code which don't work together when I try to assemble it. Possibly because I am not searching for the right terms?
Thanks, Dan
You could try the following approach:
Create a service that runs in the background to check for newly added data in the server.
If you prefer to make it user-driven, you can let users refresh the list on the device to actually trigger the requests to the server.
Libraries like Retrofit can make your life easier when it comes to making http requests - always avoid the main UI thread when doing this.
Another library that you could use to decouple your application using Events is EventBus. Assuming you are running a background service to check for updates, you can use EventBus to update your User Interfaces when something new is retrieved from the server through a GET request.
I hope this gives you an idea on how to proceed with the solution. Good luck!
I have been reading a lot about network operations with android and how to do it properly. The documentation suggests using Volley and it abstracts the process making the network request:
http://developer.android.com/training/volley/simple.html
As I use Retrofit in my app I thought that the best practice was to use Loaders as they behave well on orientation change, but I found this:
http://www.androiddesignpatterns.com/2012/08/implementing-loaders.html
"Using a Loader to perform network requests isn't great practice, because (1) it means that your application will be hard on the battery (having to poll for new data from the network repeatedly each time you start the Activity, (2) there is no way to observer the network for content changes without polling it repeatedly, and (3) your application won't work offline."
(1) isn't particularly true because you can just resume the loader on activity creation. I don't think I fully understand point (2) and point (3) isn't a concern for me as there is no way for my app to work properly offline.
However, this caught my eye, again, from the same link.
"So my answer is to forget about using the Loader/AsyncTask combination entirely and to stick with a Service. The Service can poll the network for data every once and a while and insert new data into a ContentProvider. You can then use a CursorLoader to load data from the ContentProvider without it needing to know anything about where the data coming from."
Has anyone used this approach of using a Service to poll the network and populate a ContentProvider? I don't think it will work properly with my app as it uses a RESTful API that is constantly requested. I don't think it will be particular effective, but I might be missing something here.
Sorry for the long question. It is not a question exactly, but I wish to create a discussion around the topic.
My question is kinda theorical, hope I can get a clear explanation on this.
I've been looking for a nice rest api consumer for android (or some clear info on how to develop a solid one) and I found the rest api design talk from google IO 2010.
"Developing Android REST Client Applications - Google"
It's been 4 since this talk and I think there might exitst new designs and techniques for this matter, or not ?
The scenario that I think that would work the best for me is this one:
So my first question is, does this architecture is still valid for a new app (Starting from the beginning) ?
I've found Retrofit, which seems a pretty nice and stable Api for the rest service, but I can't quite understand how it works, like if it is a good approach to call my api endpoints from activities (or frags) and the library handles the resume/pause (delivering results when activity is on hold, or not) or I must implement this myself.
Sorry for the long post and thanks for the patience !
You must implement how to handle that yourself, to answer your question.
Yes, that architecture is valid, but RetroFit only forms part of the "Rest Method" block. How would you implement it? That depend on what you want. You could use Retrofit (AKA the REST Method) inside the service, and that would be ok, however you can also skip using services and use it inside of an activity or fragment. However if you do the second option(activities/fragments) you can not think in handling the activity life cycle within retrofit(onStart, onPause, etc..) because since these are network calls, you must perform them on worker threads(AsyncTasks for instance).
So in conclusion, whatever option you decide, being Services or worker threads, you must think in using perhaps observers to control your activity/fragment, and remember that requesting network data is always done out of the ui thread. Implementations of how to handle the situation may be done by you depending on your needs and complexity of the application.
I need to make for school an app that runs on Android. Actually there are two apps, a client and a server. Ther server runs on a PC while the clients run on Android devices. I want to know what is the best technology for this. I know RMI and WebServices are not implemented in Android so what are the alternatives (besides actually communicating with sockets in the traditional way). One alternative that I did not look into is REST, but I will need to be able to notify a client once another client has done something, similar to turn base games where Player A notifies Player B that he made his move.
Like I said, sockets do the trick, but are little low-level compared to RMI and WebServices and only want to use those as a last resort.
Keep it simple. Use REST and have the clients poll for updates.
Also, if you get to a point down the road where you need to scale, this solution is actually fairly easy to scale because your servers do not need to maintain connections. Since there is no shared state between a particular server and the client (there is shared server between the application and the client), you can easily add more servers to handle the polling and put them behind a load balancer.
You can also add in caching so that the polling just gets the exact same response without causing a re-compute of the response. You would then be able to have the back-end game-state servers update the caches when the game state changes. This would let you poll much more frequently and still have a very flexible, scalable architecture.
For a turn-based game you can take a look at XMPP (e.g. Smack) that is traditionally used for instant messaging. It would also be interesting to create a game using C2DM that is used for push notifications.
You can also look into HTTP streaming which is essentially an unending HTTP response in which player moves are fed into.
Alternatively you can look into binary messaging systems that are more suited for real-time games but still applicable such as RabbitMQ (what's wrong with a smooth turn-based game?).
Based on Google I/O video, http://www.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html, I got this question...
No matter the call is rest calls or normal http calls, they will have same issue mentioned in this video. So that means it is not good implementation if we use asynctask from activity.
Isn't it too complex to always implement Service and content provider even we just need to make a simple http call to a server and get a bunch of text to display on android?
This really confuse me, what do you guys think?
yeah its a lot of work for a one-off service call. Lately I have been using the new loader api for this type of thing. More specifically the AsyncLoader