Volley Introduction

Overview

As a Java lib for handling the http request, volley supports some useful features.

Http features are well supported and the APIs for the user are well constructed.
Parallelly sending requests. Of course, this is how volley basiclly works but the user can specify the number of the working threads.
Async Response handling.
Caching requests.
Retry policies are configurable.
Cancelling a request by the user.

There are two queues maintained by volley. One is called network request queue and the other is cache request queue. Threads are running to take the requests from the queues and send the data contained in the request to the network by HTTP or respond the request with the cached data. Only one thread is running for the cache request queue. By default, four threads are running for the network request queue.

The diagram pictures the general process of making a http request using volley.

The primary Java classes are as below.

NetworkDispatcher

Below is about the details of processing a request. RequestQueue keep an array which reserves all the NetworkDispatcher instances. With the RequestQueue started, all the dispatcher threads are launched. The threads share the same network request queue from which the network request is consumed by the threads one by one.

Each loop of the network dispatcher thread just calls the function processRequest. With no request in the queue, the function will be blocked by PriorityBlockingQueue on taking a request, and in case of a InterruptedException the thread just return and quit. While the dispatcher running, the thread is with the priority of THREAD_PRIORITY_BACKGROUND, and with a request has been taken all exceptions including network errors and unexpected exceptions are eaten and just trigger posting volley error to the response delivery and then to the callback of the user object.

CacheDispatcher

Below is about the details of processing cached requests.

A request can be set as should cache or not when created. When accessing a cached request, the state could be cache-miss, cache-hit-expired, cache-hit and cache-hit-refresh-needed.

Request Queue

The class RequestQueue is exported to the user, and the user need to create a RequestQueue instance during the app is launching.

Add a request.

Finish a request.

Retry Policy

Each separated request can have a different retry policy which is assigned to the request object when it is created.

While some error happens and during the exception handling for sending the request to the network , retry policy will work to decide if to repeat or transfer the exception to the process of processRequest.

Response Delivery

A response delivery is used by the network dispatcher to dispatch the response of a request to the user. Both the request and the response are posted to the response delivery which, on a separated thread, will call the user callback to handle the response and call finishing the request asynchronously, and that thread can be assigned when the request queue is initialized.

Cancel and finish a request

Regarding cancelling a request, this is about that a request is not necessary to be alive and it is canclled by the user without any http result needed. When a request is cancelled, just a flag is set to mark the status but the request is not removed from the queue.

Regarding finishing a request, it is the last operation that volley has to act during the lifecircle of a reuqest. The request is removed from the queue. The user doesn’t take care of anything about when and how the request is finished. It is the internal job of volley.

Usage expanding and Demo

Here I attached a demo which includes the volley source code and some simple code about how to use volley. What’s more, I added some java classes for demonstrating accessing the local data such as reading a file on the sdcard or getting data from the database asynchronously. That is just rough, for which please refer to the files LocalRequest.java, LocalWork.java, LocalWorkCallback, LocalWorkResponse and LocalWorkResult.

代码下载