Volley — cos'è, caratteristiche della libreria di rete di Google

Cos'è Volley?

Volley è una libreria per la comunicazione di rete nelle applicazioni Android, presentata da Google alla conferenza I/O 2013. Il nome Volley significa “una salva” — la libreria è progettata per eseguire più richieste veloci in parallelo, caratteristiche delle applicazioni orientate all'interfaccia utente dove la velocità di risposta dell'interfaccia è importante.

Volley è stata creata come soluzione ai problemi di HttpURLConnection e AsyncTask: gestione manuale dei thread, mancanza di caching, complessità di prioritizzazione delle richieste e codice ingombrante. Google ha posizionato Volley come una libreria per operazioni di tipo “fire-and-forget” — piccole richieste il cui risultato viene visualizzato immediatamente nell'interfaccia.

L'architettura di Volley include tre componenti principali: RequestQueue (gestore della coda), CacheDispatcher (thread per le risposte memorizzate nella cache) e NetworkDispatcher (thread di rete). Questa architettura distribuisce automaticamente le richieste: prima viene controllata la cache, e solo in sua assenza viene effettuata una richiesta di rete. Ciò riduce la latenza per i dati ripetuti del 50–80%.

Come funziona Volley

RequestQueue è la classe centrale di Volley. Gli oggetti Request<T> vengono aggiunti ad essa, e la coda li distribuisce automaticamente tra due tipi di thread: CacheDispatcher (un thread, gestisce le richieste con possibile cache) e NetworkDispatcher (diversi thread, eseguono le richieste HTTP reali). Per impostazione predefinita, Volley crea 4 thread di rete.

Quando viene aggiunta una richiesta, RequestQueue verifica se può essere servita dalla cache. Se la cache contiene una risposta aggiornata, CacheDispatcher la restituisce immediatamente, senza una richiesta di rete. Se la cache è obsoleta o assente, la richiesta viene passata a NetworkDispatcher. La priorità della richiesta (low, normal, high, immediate) determina l'ordine di elaborazione all'interno della coda — le richieste con priorità high vengono elaborate prima di quelle normal.

Dopo l'esecuzione della richiesta, il risultato viene consegnato al thread principale (UI thread) tramite Handler. Volley commuta automaticamente i callback onResponse() e onErrorResponse() al thread principale, quindi l'interfaccia può essere aggiornata direttamente nel callback senza ulteriori cambi di thread. Ciò semplifica il codice ed elimina un'intera classe di errori di threading.

Un'altra caratteristica di Volley è la deduplicazione automatica delle richieste. Se due richieste GET identiche allo stesso URL con gli stessi parametri vengono aggiunte alla coda, Volley ne esegue solo una e restituisce la stessa risposta a entrambi i callback. Ciò è particolarmente utile per schermate in cui più componenti richiedono indipendentemente gli stessi dati — ad esempio, un profilo utente che è necessario contemporaneamente sia per l'intestazione che per un frammento delle impostazioni.

Ciclo di vita di una richiesta in Volley

Ogni richiesta attraversa una sequenza di passaggi: creazione di una Request, aggiunta a RequestQueue, verifica della cache (CacheDispatcher), esecuzione della richiesta HTTP (NetworkDispatcher), parsing della risposta tramite Response.Listener, consegna del risultato al thread UI. Quando una richiesta viene annullata (cancel), RequestQueue la rimuove dalla coda e impedisce la chiamata dei callback.

Volley supporta anche RetryPolicy, che determina il numero di tentativi di ripetizione in caso di fallimenti. DefaultRetryPolicy per impostazione predefinita effettua un tentativo di ripetizione con un timeout di 2,5 secondi. Per connessioni instabili, il numero di tentativi può essere aumentato a 3 e il timeout a 10 secondi. Una RetryPolicy personalizzata viene implementata tramite l'interfaccia RetryPolicy con i metodi getCurrentTimeout, getCurrentRetryCount e retry.

Tipi di richiesta Volley

Volley fornisce tipi di richiesta pronti all'uso per formati di dati comuni. Ogni tipo implementa la classe astratta Request<T> e definisce un metodo per analizzare la risposta. Per formati personalizzati, puoi creare il tuo tipo sovrascrivendo il metodo parseNetworkResponse.

Richieste personalizzate

Per lavorare con Gson o Kotlinx Serialization, puoi creare una Request<T> personalizzata che utilizzi il parser scelto in parseNetworkResponse. Ciò consente di ricevere oggetti tipizzati direttamente, evitando l'analisi manuale di JSONObject. Questo approccio è particolarmente utile per progetti che già utilizzano la serializzazione tramite Gson o Moshi.

Per inviare dati, Volley supporta tre tipi di corpo: JSONObject (tramite JsonObjectRequest con metodo POST), Form-encoded (tramite HashMap<String, String> nel costruttore) e Multipart (tramite un MultipartRequest personalizzato). Le richieste Multipart sono utili per caricare immagini e file ma richiedono un'implementazione manuale poiché Volley non ha un supporto integrato per multipart/form-data, a differenza di OkHttp o Dio.

I limiti di Volley diventano evidenti quando si lavora con risposte di grandi dimensioni. Volley carica l'intera risposta in memoria prima di passarla al callback, il che può causare OutOfMemoryError per file JSON più grandi di 10–20 MB. Per scaricare file di grandi dimensioni, Volley non è adatto — utilizza DownloadManager o OkHttp con ResponseBody in streaming. Volley inoltre non supporta la ripresa di download interrotti (intestazione Range) e non funziona con protocolli di streaming come Server-Sent Events o WebSocket in tempo reale.

Esempi di codice Volley in Java e Kotlin

Diamo un'occhiata a un esempio di base — un StringRequest per recuperare dati da un server. Innanzitutto, viene creata una RequestQueue tramite Volley.newRequestQueue(context). Quindi viene formata una richiesta con un URL e callback di successo ed errore.

val queue = Volley.newRequestQueue(context)

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

queue.add(request)

Per una richiesta JSON, viene utilizzato JsonObjectRequest, che analizza automaticamente la risposta in un JSONObject. Volley supporta richieste GET e POST. Per POST, un JSONObject viene passato nel corpo della richiesta.

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("Creato: ${response.getString("id")}")
    },
    { println("Errore: $it") }
)

queue.add(request)

Annullamento delle richieste

Per annullare una richiesta, si utilizza il metodo cancel() o l'annullamento di gruppo per tag. Durante l'annullamento, Volley non chiama né onResponse né onErrorResponse, impedendo aggiornamenti dell'interfaccia dopo aver lasciato la schermata. Ciò è importante per prevenire perdite di memoria in Activity e Fragment.

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

// Annullamento all'uscita dallo schermo
queue.cancelAll("profile_request")

ImageLoader e NetworkImageView

ImageLoader è una classe wrapper su RequestQueue, ottimizzata per il caricamento di immagini. Supporta la cache in memoria (LruCache) e annulla automaticamente le richieste quando ImageView viene riutilizzato nelle liste RecyclerView. ImageLoader ridimensiona anche le immagini per adattarle alle dimensioni della View, risparmiando memoria.

NetworkImageView è una View personalizzata che si integra con ImageLoader e gestisce automaticamente il caricamento: mostra un placeholder durante il caricamento, lo sostituisce con un errore in caso di fallimento e annulla la richiesta quando la View lascia la schermata. DefaultImageUrlLoader carica un'immagine per URL e la memorizza in LruCache per una rapida ri-visualizzazione.

Per utilizzare ImageLoader, basta creare un'istanza tramite ImageLoader(queue, ImageCache), dove ImageCache è un'implementazione dell'interfaccia ImageCache con LruCache all'interno. NetworkImageView nel layout XML viene collegato a ImageLoader tramite il metodo setImageUrl(), e tutto il caricamento avviene completamente in automatico senza codice aggiuntivo per gestire placeholder ed errori.

Errori comuni quando si lavora con Volley

Creare una RequestQueue in ogni Activity è un errore comune che porta alla duplicazione dei thread e confusione nella cache. Si consiglia di creare RequestQueue una volta in Application o tramite una classe singleton. Altrimenti, ogni schermata avrà il proprio pool di thread e la cache verrà memorizzata separatamente per ogni coda.

Ignorare l'annullamento delle richieste durante la rotazione dello schermo. Quando la configurazione cambia, l'Activity viene ricreata e i callback della vecchia Activity continuano a rimanere in memoria. Ciò causa perdite e tentativi di aggiornare una View distrutta. Annulla sempre le richieste in onStop() tramite cancelAll() con un tag specifico dell'Activity.

Volley non supporta HTTP/2 e le coroutine — questo non è un errore di utilizzo ma una limitazione architetturale. Volley è stato creato nel 2013 e non supporta protocolli moderni e le coroutine di Kotlin. Per i nuovi progetti, Google raccomanda di utilizzare Retrofit + OkHttp. Volley è adatto solo per supportare progetti legacy o applicazioni semplici con requisiti di rete minimi.