Volley — What It Is, Features of Google's Networking Library

What is Volley?

Volley is a library for network communication in Android applications, introduced by Google at the I/O 2013 conference. The name Volley means “a salvo” — the library is designed for executing multiple parallel fast requests, characteristic of UI-oriented applications where interface response speed is important.

Volley was created as a solution to the problems of HttpURLConnection and AsyncTask: manual thread management, lack of caching, complexity of request prioritization, and cumbersome code. Google positioned Volley as a library for “fire-and-forget” operations — small requests whose results are immediately displayed in the interface.

The Volley architecture includes three main components: RequestQueue (queue manager), CacheDispatcher (thread for cached responses), and NetworkDispatcher (network threads). This architecture automatically distributes requests: the cache is checked first, and only if it is absent is a network request made. This reduces latency for repeated data by 50–80%.

How Volley Works

RequestQueue is Volley’s central class. Request<T> objects are added to it, and the queue automatically distributes them across two types of threads: CacheDispatcher (one thread, handles requests with possible cache) and NetworkDispatcher (multiple threads, perform actual HTTP requests). By default, Volley creates 4 network threads.

When a request is added, RequestQueue checks whether it can be served from cache. If the cache contains an up-to-date response, CacheDispatcher returns it immediately, without a network request. If the cache is outdated or absent, the request is passed to NetworkDispatcher. Request priority (low, normal, high, immediate) determines the order of processing within the queue — requests with high priority are processed before normal ones.

After the request is executed, the result is delivered to the main thread (UI thread) via Handler. Volley automatically switches onResponse() and onErrorResponse() callbacks to the main thread, so the interface can be updated directly in the callback without additional thread switching. This simplifies the code and eliminates a whole class of threading errors.

Another feature of Volley is automatic request deduplication. If two identical GET requests to the same URL with the same parameters are added to the queue, Volley executes only one of them and returns the same response to both callbacks. This is especially useful for screens where multiple components independently request the same data — for example, a user profile that is simultaneously needed by the header and a settings fragment.

Request Lifecycle in Volley

Each request goes through a sequence of steps: creating a Request, adding it to RequestQueue, checking the cache (CacheDispatcher), executing the HTTP request (NetworkDispatcher), parsing the response via Response.Listener, delivering the result to the UI thread. When a request is canceled (cancel), RequestQueue removes it from the queue and prevents callbacks from being invoked.

Volley also supports RetryPolicy, which determines the number of retry attempts on failures. DefaultRetryPolicy by default makes one retry attempt with a timeout of 2.5 seconds. For unstable connections, the number of retries can be increased to 3, and the timeout to 10 seconds. A custom RetryPolicy is implemented via the RetryPolicy interface with methods getCurrentTimeout, getCurrentRetryCount, and retry.

Volley Request Types

Volley provides ready-made request types for common data formats. Each type implements the abstract class Request<T> and defines a method for parsing the response. For custom formats, you can create your own type by overriding the parseNetworkResponse method.

Custom Requests

To work with Gson or Kotlinx Serialization, you can create a custom Request<T> that uses the chosen parser in parseNetworkResponse. This allows you to receive typed objects directly, bypassing manual JSONObject parsing. This approach is especially useful for projects already using serialization via Gson or Moshi.

For sending data, Volley supports three body types: JSONObject (via JsonObjectRequest with POST method), Form-encoded (via HashMap<String, String> in the constructor), and Multipart (via a custom MultipartRequest). Multipart requests are useful for uploading images and files but require manual implementation since Volley has no built-in support for multipart/form-data, unlike OkHttp or Dio.

Volley’s limitations become noticeable when working with large responses. Volley loads the entire response into memory before passing it to the callback, which can cause OutOfMemoryError for JSON files larger than 10–20 MB. For downloading large files, Volley is not suitable — use DownloadManager or OkHttp with streaming ResponseBody. Volley also does not support resuming interrupted downloads (Range header) and does not work with streaming protocols like Server-Sent Events or real-time WebSocket.

Volley Code Examples in Java and Kotlin

Let’s look at a basic example — a StringRequest for fetching data from a server. First, a RequestQueue is created via Volley.newRequestQueue(context). Then a request is formed with a URL and success and error callbacks.

val queue = Volley.newRequestQueue(context)

val request = StringRequest(
    Request.Method.GET,
    "https://api.github.com/users/octocat",
    { response ->
        println("Response: $response")
    },
    { error ->
        println("Error: ${error.message}")
    }
)

queue.add(request)

For a JSON request, JsonObjectRequest is used, which automatically parses the response into a JSONObject. Volley supports GET and POST requests. For POST, a JSONObject is passed in the request body.

val jsonBody = JSONObject()
jsonBody.put("name", "New Repo")
jsonBody.put("description", "Created via Volley")

val request = JsonObjectRequest(
    Request.Method.POST,
    "https://api.github.com/user/repos",
    jsonBody,
    { response ->
        println("Created: ${response.getString("id")}")
    },
    { println("Error: $it") }
)

queue.add(request)

Canceling Requests

To cancel a request, the cancel() method or group cancellation by tag is used. When canceled, Volley does not call either onResponse or onErrorResponse, which prevents interface updates after leaving the screen. This is important for preventing memory leaks in Activity and Fragment.

request.tag = "profile_request"
queue.add(request)

// Cancellation on leaving the screen
queue.cancelAll("profile_request")

ImageLoader and NetworkImageView

ImageLoader is a wrapper class over RequestQueue, optimized for loading images. It supports memory cache (LruCache) and automatically cancels requests when ImageView is reused in RecyclerView lists. ImageLoader also scales images to fit the View size, saving memory.

NetworkImageView is a custom View that integrates with ImageLoader and automatically manages loading: it sets a placeholder during loading, replaces it with an error on failure, and cancels the request when the View leaves the screen. DefaultImageUrlLoader loads an image by URL and stores it in LruCache for fast re-display.

To use ImageLoader, simply create an instance via ImageLoader(queue, ImageCache), where ImageCache is an implementation of the ImageCache interface with LruCache inside. NetworkImageView in XML layout is linked to ImageLoader via the setImageUrl() method, and all loading happens completely automatically without additional code for handling placeholders and errors.

Common Mistakes When Working with Volley

Creating a RequestQueue in each Activity is a common mistake that leads to thread duplication and cache confusion. It is recommended to create RequestQueue once in Application or via a singleton class. Otherwise, each screen will have its own thread pool, and the cache will be stored separately for each queue.

Ignoring request cancellation on screen rotation. When the configuration changes, the Activity is recreated, and the callbacks of the old Activity continue to linger in memory. This leads to leaks and attempts to update a destroyed View. Always cancel requests in onStop() via cancelAll() with a tag specific to the Activity.

Volley does not support HTTP/2 and coroutines — this is not a usage error but an architectural limitation. Volley was created in 2013 and does not support modern protocols and Kotlin coroutines. For new projects, Google recommends using Retrofit + OkHttp. Volley is only suitable for supporting legacy projects or simple applications with minimal networking requirements.