Android Volley, A Networking Library (Part 1)by Mir Suhail
Volley is a networking library developed by Google and introduced during Google I/O 2013. It was developed because of the absence, in the Android SDK, of a networking class capable of working without interfering with the user experience.
Until the release of Volley, the canonical Java class
java.net.HttpURLConnection and the Apache
org.apache.http.client were the only tools available to Android programmers to develop a RESTful system between a client and a remote backend.
Using the above two classes, if we wanted to cache images or prioritize requests, we had to develop it from scratch! This was really hefty work.
Fortunately, now there’s Volley, created and tailored to fulfill these needs.
There are a lot of features and reasons which accede the developers to use Volley over other networking options available. Some of them are:
Google+ team did a series of performance tests on different methods we can use to make network requests on Android. Volley got a score ten times better than other alternatives when used in RESTful applications.
HttpUrlConnection and HttpClient are becoming outdated
In HttpUrlConnection and HttpClient, there are some known issues and bugs that were never fixed. Moreover,
HttpClient was deprecated in the last API update (API 22), which means that it will no longer be maintained and may be removed in a future release, which is sufficient reason for switching to a more reliable way of handling the network requests.
Volley doesn’t use AsyncTask
Since API level 11 (i.e Honeycomb), android enforces to perform network operations on a separate thread, different from the main thread. This substantial change led the way to massive use of the
AsyncTask<Params, Progress, Result> specification.
An asynchronous task is defined by a computation that runs on a background thread and whose result is published on the UI thread. An AsyncTask is defined by 3 generic types, called
Result, and 4 steps, called
The main problem with AsyncTask, however, is the serialization of the calls. Using the
AsyncTask class, we can’t decide which request goes first and which one has to wait. Everything happens FIFO order.
The problems with this approach arises, for example, when you have to load a list of items that have an attached thumbnail. When the user scrolls down and expects newer results, we can’t convey the activity to first load JSON of the next page and only then images of the previous one. This can become a serious user experience problem in applications where the list of new items is more important than thumbnail associated with it.
Volley aims to solve this problem by including a powerful cancellation API. We no longer need to check in
onPostExecute whether the activity was destroyed while performing the call. This helps avoiding an unwanted
Volley Caches Everything
Volley automatically caches requests and this gives a boost in user experience. Considering the previous example where the list of items gets loaded from network with each item having the thumbnail attached, when the user rotates the screen, the activity gets crashed and the list has to reload from the network, a significant waste of resources and a poor user experience.
Volley becomes extremely useful for overcoming situations like this. It remembers previous calls it performed and handles activity destruction and reconstruction. It caches everything without us having to worry about it.
Small Metadata Operations
Volley proves to be perfect for small network calls, such as JSON objects, lists, details of a selected item, and so on. It has been devised for RESTful applications and in this particular case it gives its very best.
It is not so good, however, when employed for streaming operations and large downloads. Contrary to common belief, Volley’s name doesn’t come from the sport dictionary. It’s rather intended as repeated bursts of calls, grouped together. It’s somehow intuitive why this library doesn’t come in handy when, instead of a volley of arrows, we want to fire a cannon ball.
Volley works on three different levels with each level operating on its own thread.
Image Source: https://developer.android.com/training/volley/simple.html
On the main thread, consistently with what we already do in the
AsyncTask specification, we are only allowed to fire the request and handle its response.
The main consequence is that we can actually ignore everything that was going on in the
doInBackground method. Volley automatically manages the HTTP transactions and catching network errors that we needed to care about before.
Cache and Network Threads
When we add a request to the queue, several things happens under the hood. First, Volley checks if the request can be serviced from cache. If it can, cached response is read, parsed, and delivered. Otherwise it is passed to the network thread.
On the network thread, a round-robin with a series of threads is constantly working. The first available network thread de-queues the request, makes HTTP request, parses response, and writes it to cache. To finish, it dispatches the parsed response back to the main thread where your listeners are waiting to handle the result.
In the next part we will discuss, how to actually setup the project, import volley library and use the volley RequestQueue class objects.
Click here for the Part 2 of this topic.
Have a nice day!