I almost always use a Service when I download data from a web service. I store the result in a database and displays the result in my view using a cursor loader. But after Google released the network library Volley I have become a bit confused. The volley library uses async tasks instead of a Service and it doesn't use cursors. I thought that I was supposed to avoid async task and store my data in a database so that I could handle orientation changes properly - without loosing data and having the need to download the data again.
So my question is, when should I use Volley instead of my own download strategy?
Personally, in the past I've found using a service to be cumbersome to implement but at the end of the day was well structured and was a good consistent experience. But threading performance... hard to manage.
Service query - > database load -> notify
UI initiate query and cursor load - > update ui.
With volley it is tempting to skip the entire component that was previously handled within a service and database.
UI Volley request -> Volley response -> update ui
However, this falls apart quite quickly depending on the data you are trying to display and perhaps even the server you are querying against for any of the following requirements
The user might scroll down and pull in more pages. However when the user comes back to the activity or even simply rotates, the call to Volley will return a result for only the initial page unless you specifically remember all of the other queries that the page consists. This becomes a lot of work for an architecture that is meant to be more convenient. Or even a page that is slightly different, this can be an inconsistent experience to the user if all they did was rotate the phone.
It's easier to apply the change locally and then apply to the server whenever. With volley only, you would have to do an REST update and requery (of all previous queries) synchronously.
Volley is really fast. However, it lacks any persistence apart from cache hits where available which can depend on the server you are querying. Aggressive caching can even wreak havoc on your app with stale data. Pulling from a local database provides a consistent and fast experience when navigating through multiple activities that might actually be referencing data in past queries. A pure volley experience might require you to query for data you technically already have from previous queries but have no central data store to get that data from.
These days I actually skip the service part, but everything else remains from the traditional arch
UI initiate volley query and cursor load - > update ui
Volley query -> update database -> notify
Also, there is nothing stopping you from having the ui ping a service and then the service uses volley... It will look more traditional there might be value moving more control logic to somewhere more centralised, but that fact that it's run from within a "service" actually offers no technical advantage.
I hope that helps. Basically, don't attempt to go volley only, I tried and it would be a very specific and simple app if that's what worked for you and hopefully I've identified the main pitfalls.
Also, I found the same pitfalls with robospice despite it being in a service... But... YMMV