Blog Post

Android, Mobile, Technologies

Networking for Android made easy: The Volley Library 

When developing an app on native Android you definitely at some point happen to need to make a network call, say, calling a JSON api. Being either your own well known or third party api you always need to get your hands on that tedious boilerplate code: create an AsyncTask and in it’s doInBackground() method implement the HTTP call using either the buggy and already deprecated apache HttpClient library, or take the HttpURLConnection approach. And what about concurrent network calls? synchronisation? scheduling? IO exceptions? request retry and back-off? and what about caching?

This is were Volley comes handy. Android engineers @ Google took all their lessons learnt while developing quality production apps over these years and wrapped them up in this library which basically provides an interface to step up and think less on the underlying network layer, caching, synchronisation and boilerplate network transports and focus more on logical operations and how to intersect network with the UI hierarchy.

It offers out of the box:

  • Trivial Image downloading and JSON apis access
  • Memory and disk caching
  • Parallel request execution and priorization
  • Powerful customisation abilities
  • Debugging and tracing tools
  • among others..

Suitable for RPC like operations, fetching metadata and updating the UI, not so much for heavy data download or media streaming. Regardless, you are not restricted to take a volley-only approach as you can still use it for your RPCs and take a different approach in another scenario, like using a DownloadManager for heavy file download.

I recently faced a project in which I had the need for fast networking and cacheable lightweight responses. So after surfing the web looking at the docs and various examples, I figured Volley suited this scenario perfectly and decided to give it a try. I found it extremely intuitive to use, time-saving and above all less error prone as it abstracted away all the networking code I would have needed to make the network calls and handle memory and disk caching.

I will present below some of the features I’ve been testing and using and show some I find particularly interesting for you to give it a try. I will also show how things are done using an HttpUrlConnection approach to show how Volley simplifies, reduces size and errors in our code and saves us time.

I will be building a simple Chuck Norris jokes app to show you how things work on Volley for those well known patterns compared to other networking approaches.

I will be using the rest api provided by the Internet Chuck Norris Database

Main Activity

Our Main Activity basically instantiates the Volley RequestQueue and inflates a main view that consists of two Buttons and a TextView. First Button fetches a random joke using HttpUrlConnection approach, and second Button does the same but using Volley. Finally, the TextView is the one populated with the joke fetched by the service. Instantiating the request queue on the Activity is not a good practice, as it will live in the process that holds the Activity as long as the activity is running. Thus, it should be instantiated at application scope to be available and used from different app components in either a custom Application class or using a singleton. As for this single Activity example, we will leave the queue at Activity scope.

JSON api request

Below is the code for a JSON api call using HttpURLConnection approach. Basically, we will need to create an AsyncTask, override the doInBackground method with our network call and then post the results to the UI thread in the onPostExecute method.

Let’s see now how the same network call is approached with Volley

You can see that most of the boilerplate code is gone with Volley (try-catches, HttpUrlConnection setup, response parsing, etc); also note that onResponse callback is practically the same as the onPostExecute callback on the AsyncTask, which means that portability to Volley does not entail major changes in your app. Volley also allows you to pass in an error listener in case the requests fail with, say, an HTTP 404 or 500 response code.

Apart from JSON object requests, Volley also provides support for raw text request (StringRequest) which you can then parse to whatever you need to; JSON array requests that it parses a JSON array object as the response; and powerful Bitmap request handling which we will discuss later.

So far so good.. but, what if we want to cache the joke to prevent the roundtrip to the server.


Let’s see how we can handle caching using the HttpUrlConnection approach. We can make use of the class introduced in Android 4.0+ devices. Note that the following code will not work on Android versions previous to 4.0, but for the sake of this post I will only use cache if device’s SDK version is greater or equal to 4.0 (Ice Cream Sandwich).

I will first need to install HttpResponseCache in order to retrieve our cached response later on. In this example cache will be stored in the application’s secure cache directory getCacheDir().

Following is the code to retrieve an entry from the application’s cache I installed above.

So basically, I will go ahead and wire this with our HttpUrlConnection by adding the following code before initiating the connection to check if we have a cached entry available and return that one instead.

Let’s now see how this would be approached with Volley.

By default, Volley parses the Cache-Control HTTP headers set in the response to determine if it should be cached or not, and if so, determines the cache entry TTL.

In this case, the api returns Cache-Control: no-cache, must-revalidate which means that response will not be cached at all. As I mentioned above, Volley has powerful customisation abilities and, as such, we can force it to cache the response by basically overriding the method that parses the response headers. I will override the JsonObjectRequest.parseNetworkResponse method and build the JSONObject response myself from the response raw byte[] array data, and set the Cache entry for the current response. I will force the entry to be cached 24 hours in this case, you can set this arbitarily to whichever value you need to.

The following method checks for a valid cache entry and will be called before building and queuing the request. If entry is available, it builds a JSONObject from the cached entry byte[] array data and displays it in our TextView.

Request cancellation

Another great feature is request cancelling – note this is also available when working with AsyncTasks. For instance, you can keep track of your in-flight AsyncTasks and cancel them all, say, on the onStop callback of the activity.

You can also keep track of your in-flight Volley requests and cancel them all.

Not a major difference here. However, Volley also provides the ability to create batches or scopes of request to cancel by tagging the requests with a certain object. In this case I cancel all the requests in the Activity scope.

This comes handy when, for instance, you have a tabbed view pager with multiple fragments and multiple requests per fragment. So you can go ahead and tag your requests with the Tab object and cancel the requests when the Tab is un-selected and it’s content is not visible to the user and cannot interact with it.

Volley also allows you to provide a filter to determine which requests to cancel. For example, you would want to cancel all your image requests at a given moment, and keep your in-flight JSON requests in the request queue.


Volley also provides out of the box request priorization. Requests are processed from higher priorities to lower priorities, in FIFO order. For example, you can set your main metadata requests with a higher priority that your image request so you don’t need to wait until your image assets load to allow the user to see your data and interact with it. You can set this either inline at request creation time, or extending one of the base Request classes provided in the toolbox and Override the getPriority() method – see Image loading example below.

Request Retry policy

Volley allows you to define a Retry policy. The toolbox provides a default policy (2500 millisecond timeout, and 1 retry attempt) for you to use or you can pass in your own custom RetryPolicy implementation.

Image Loading

Volley has powerful and customisable image loading capabilities. Let’s see how a simple Image download task can be implemented using HttpUrlConnection.

The network request and image decoding is performed in a worker thread and the Bitmap posted to the UI thread, not affecting the UI thread execution and responsiveness. However, no caching is made and lots of boiler plate code is introduced, regardless of how simple this example is. See try catch blocks, connection setup… imagine if we add caching and a retry and back-off algorithm.

Lets now see how to approach this with Volley. I will add a new default ImageView to the View hierarchy to display images retrieved with Volley.

I will use an ImageRequest object that comes built-in the Volley toolbox.

Regardless of the simplicity of this examples, it’s noticeable how all the boilerplate code is gone and reduced to a couple of callbacks. Also, note that image caching is enabled by default, so no need to add any extra code as you would have for an HttpUrlConnection approach. Handling and maintaining caching using a HashMap or a LruCaches is tedious and too error prone. Volley does all that for ourselves deciding whether to cache response or not, based only on “Cache-Control” and “Expires” HTTP headers.

Note that we also set the Priority of the ImageRequest to LOW – something that you would generally do as we mentioned above.

There is more…

Volley also provides an ImageLoader helper class. You can make use of it if you need to have a more customised image loading implementation. In order to use it you need to have a RequestQueue instantiated and your own ImageCache implementation.

Here is a basic ImageCache that extends the LruCache that comes bundled in the Android SDKs.

On the Java side, use the ImageLoader as follows

And for super super lazy programmers, the toolbox includes a NetworkImageView that be can directly include in the View hierarchy and then set the image URL from the Java code. The View handles itself  the request lifecycle depending on the View state, like when the View gets detached from the View hierarchy the request is cancelled.

Wrapping up..

We covered the core features of the Volley library toolbox and compared them with it’s HttpUrlConnection approach. There is a couple more features to go over. Make sure you visit the official docs for further details.

It’s worth mentioning that I am not trying to sell you this library above any other library you may find or have used while developing networking in your apps. Nevertheless, I believe it’s extremely positive that Google’s Android engineers put together all their learnt lessons over the years into this single library and be able to take advantage of that in our apps, mainly in those common patterns that are basically full of boilerplate code that is pretty straightforward but extremely tedious to code.

I uploaded the app’s code into github in case you want to see how all things are wired together

Definitely Volley is a great alternative for you to take into account when having to dig into networking code in your android app.

(Visited 7,401 times, 1 visits today)

Related posts