Android development, like most development, has commonly performed operations that developers tend to re-write from scratch repeatedly. One of the most common is an asynchronous web request to get/post data to a service for your app.

The Android SDK has progressed over the years, providing helpful libraries for performing these Async Tasks with relative ease, but the developer is still left with a myriad of fringe cases to consider, support, and plan for. For example, there are multiple HttpClients to choose from when building your web request, and Android recommends a specific client for specific versions of Android, but the developer is responsible for using the right one on the right device.

Google Volley

At Google I/O this year, Google announced a library it had built called Volley. The goal of Volley is to further simplify and standardize the network request process in Android development. The library takes care of all of the mundane details involved with making an Async HTTP request, provides thorough error handling, and handles any version specific optimizations for you. On top of that, it adds a control called NetworkImageView which gives you async image loading from URL’s along with image caching and lazy loading out of the box.

The problem with Google Volley is that it is almost completely undocumented. Beyond making a basic GET request, which is covered in the Google I/O video, you’re on your own to figure out the rest. Using the NetworkImageView requires that you establish an ImageLoader object, and there are no details describing how to build that object (although I provide the how-to here). Likewise, performing a POST request is done in a non-obvious manner.

How to execute a POST Request

Performing a POST request is similar to a GET request only with some extra function overrides. The proper overrides are hard to know about unless someone shows you due to the lack of documentation which I mentioned. Here is a full example of a POST request to get you going.

public static void postNewComment(Context context,final UserAccount userAccount,final String comment,final int blogId,final int postId){
RequestQueue queue = Volley.newRequestQueue(context);
StringRequest sr = new StringRequest(Request.Method.POST,, new Response.Listener<String>() {
public void onResponse(String response) {
}, new Response.ErrorListener() {
public void onErrorResponse(VolleyError error) {
protected Map<String,String> getParams(){
Map<String,String> params = new HashMap<String, String>();
params.put(comment, Uri.encode(comment));
return params;
public Map<String, String> getHeaders() throws AuthFailureError {
Map<String,String> params = new HashMap<String, String>();
return params;
public interface PostCommentResponseListener {
public void requestStarted();
public void requestCompleted();
public void requestEndedWithError(VolleyError error);

NOTE: I’ve included the PostCommentResponseListener interface just so you can see it. It’s a simple delegate for the async request.

If you’ve performed a GET request with volley this should look pretty familiar with the exceptions of the getParams() and getHeaders() overrides.

To POST values to the server, you simply store the values in a HashMap as key,value pairs. Overriding the getParams method allows you to build the HashMap and return the object to the Volley request for posting. Similarly, if you need to add any headers to the request, you override the getHeaders method and build/return your key,value pairs in a HashMap there as well.


The major shortcoming of Volley is its lack of documentation. Google does provide some, but it’s not enough to get you through an entire app build using the library. Because of this, many developer are quick to dismiss Volley and instead opt for a combination of 2 – 3 other libraries to accomplish the same tasks (notably those provided by Square).

While using separate libraries for each separate component may result in each piece being slightly more efficient, I’m a big proponent of relying on as few 3rd party libraries as possible. Given that Volley combines at least 2 stand alone libraries (NetworkImage and HTTP requests) into one, I’m willing to forgive the slightly longer discovery process in favor of maintainability and, in the end, ease of implementation.