Volley — wat is het, kenmerken van de Google netwerkbibliotheek

Wat is Volley?

Volley — is een bibliotheek voor netwerkcommunicatie in Android-apps, gepresenteerd door Google op de I/O 2013-conferentie. De naam Volley betekent „salvo” — de bibliotheek is ontworpen voor het uitvoeren van meerdere parallelle snelle verzoeken, kenmerkend voor UI-georiënteerde apps waar de reactiesnelheid van de interface belangrijk is.

Volley is gemaakt als oplossing voor de problemen van HttpURLConnection en AsyncTask: handmatig threadbeheer, gebrek aan caching, moeilijkheid van het prioriteren van verzoeken en omvangrijke code. Google positioneerde Volley als een bibliotheek voor „fire-and-forget”-operaties — kleine verzoeken waarvan het resultaat direct in de interface wordt weergegeven.

De architectuur van Volley omvat drie hoofdcomponenten: RequestQueue (wachtrijbeheerder), CacheDispatcher (thread voor gecachte antwoorden) en NetworkDispatcher (netwerkthreads). Deze architectuur verdeelt verzoeken automatisch: eerst wordt de cache gecontroleerd en alleen bij afwezigheid wordt een netwerkverzoek uitgevoerd. Dit vermindert de vertraging voor herhaalde gegevens met 50–80%.

Hoe werkt Volley

RequestQueue — de centrale klasse van Volley. Request<T>-objecten worden eraan toegevoegd en de wachtrij verdeelt ze automatisch over twee typen threads: CacheDispatcher (één thread, verwerkt verzoeken met mogelijke cache) en NetworkDispatcher (meerdere threads, voeren echte HTTP-verzoeken uit). Standaard maakt Volley 4 netwerkthreads aan.

Bij het toevoegen van een verzoek controleert RequestQueue of het vanuit de cache kan worden afgehandeld. Als de cache een actueel antwoord bevat, retourneert CacheDispatcher dit onmiddellijk, zonder netwerkverzoek. Als de cache verouderd is of ontbreekt, wordt het verzoek doorgestuurd naar NetworkDispatcher. De prioriteit van het verzoek (low, normal, high, immediate) bepaalt de verwerkingsvolgorde in de wachtrij — verzoeken met hoge prioriteit worden vóór normale verwerkt.

Na uitvoering van het verzoek wordt het resultaat via Handler naar de hoofdthread (UI-thread) gebracht. Volley schakelt de callbacks onResponse() en onErrorResponse() automatisch naar de hoofdthread, zodat u de interface direct in de callback kunt bijwerken zonder extra schakelingen. Dit vereenvoudigt de code en elimineert een hele klasse van thread-gerelateerde fouten.

Een ander kenmerk van Volley is automatische deduplicatie van verzoeken. Als twee identieke GET-verzoeken naar dezelfde URL met dezelfde parameters aan de wachtrij worden toegevoegd, voert Volley slechts één ervan uit en retourneert hetzelfde antwoord aan beide callbacks. Dit is vooral nuttig voor schermen waar meerdere componenten onafhankelijk dezelfde gegevens opvragen — bijvoorbeeld het gebruikersprofiel dat tegelijkertijd nodig is voor zowel de header als het fragment met instellingen.

Levenscyclus van een verzoek in Volley

Elk verzoek doorloopt een reeks stappen: aanmaken van Request, toevoegen aan RequestQueue, cachecontrole (CacheDispatcher), uitvoeren van HTTP-verzoek (NetworkDispatcher), parsen van antwoord via Response.Listener, leveren van resultaat aan de UI-thread. Bij annuleren van het verzoek (cancel) verwijdert RequestQueue het uit de wachtrij en voorkomt het aanroepen van callbacks.

Volley ondersteunt ook RetryPolicy, dat het aantal herhaalpogingen bij fouten bepaalt. DefaultRetryPolicy doet standaard één herhaalpoging met een time-out van 2,5 seconde. Voor onstabiele verbindingen kan het aantal pogingen worden verhoogd naar 3 en de time-out naar 10 seconden. Een aangepaste RetryPolicy wordt geïmplementeerd via de interface RetryPolicy met de methoden getCurrentTimeout, getCurrentRetryCount en retry.

Volley-verzoektypen

Volley biedt kant-en-klare verzoektypen voor gangbare gegevensformaten. Elk type implementeert de abstracte klasse Request<T> en bepaalt de manier waarop het antwoord wordt geparsed. Voor aangepaste formaten kunt u uw eigen type maken door de methode parseNetworkResponse te overschrijven.

Aangepaste verzoeken

Voor het werken met Gson of Kotlinx Serialization kunt u een aangepaste Request<T> maken die in parseNetworkResponse de gekozen parser gebruikt. Hiermee kunt u direct getypeerde objecten verkrijgen, zonder handmatig JSONObject te parseren. Deze aanpak is vooral nuttig voor projecten die al serialisatie via Gson of Moshi gebruiken.

Voor het verzenden van gegevens ondersteunt Volley drie typen body: JSONObject (via JsonObjectRequest met POST-methode), Form-encoded (via HashMap<String, String> in de constructor) en Multipart (via aangepaste MultipartRequest). Multipart-verzoeken zijn nuttig voor het uploaden van afbeeldingen en bestanden, maar vereisen handmatige implementatie omdat Volley geen ingebouwde ondersteuning heeft voor multipart/form-data, in tegenstelling tot OkHttp of Dio.

De beperkingen van Volley worden zichtbaar bij het werken met grote antwoorden. Volley laadt het volledige antwoord in het geheugen voordat het aan de callback wordt doorgegeven, wat kan leiden tot OutOfMemoryError voor JSON-bestanden groter dan 10–20 MB. Voor het laden van grote bestanden is Volley niet geschikt — gebruik DownloadManager of OkHttp met streaming ResponseBody. Volley ondersteunt ook geen hervatting van onderbroken downloads (Range-header) en werkt niet met streamingprotocollen zoals Server-Sent Events of WebSocket in realtime.

Volley-codevoorbeelden in Java en Kotlin

Laten we een basaal voorbeeld bekijken — StringRequest voor het ophalen van gegevens van de server. Eerst wordt RequestQueue gemaakt via Volley.newRequestQueue(context). Vervolgens wordt het verzoek met URL en callbacks voor succes en fout samengesteld.

val queue = Volley.newRequestQueue(context)

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

queue.add(request)

Voor een JSON-verzoek wordt JsonObjectRequest gebruikt, dat het antwoord automatisch naar JSONObject parset. Volley ondersteunt GET- en POST-verzoeken. Voor POST wordt een JSONObject in de body van het verzoek meegestuurd.

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

queue.add(request)

Verzoeken annuleren

Voor het annuleren van een verzoek wordt de methode cancel() of groepsannulering per tag gebruikt. Bij annulering roept Volley noch onResponse noch onErrorResponse aan, wat voorkomt dat de interface wordt bijgewerkt na het verlaten van het scherm. Dit is belangrijk om geheugenlekken in Activity en Fragment te voorkomen.

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

// Annuleren bij verlaten van scherm
queue.cancelAll("profile_request")

ImageLoader en NetworkImageView

ImageLoader — is een wrapper-klasse over RequestQueue, geoptimaliseerd voor het laden van afbeeldingen. Het ondersteunt geheugencache (LruCache) en annuleert automatisch verzoeken bij hergebruik van ImageView in RecyclerView-lijsten. ImageLoader schaalt ook afbeeldingen naar de grootte van de View, wat geheugen bespaart.

NetworkImageView — is een aangepaste View die integreert met ImageLoader en het laden automatisch beheert: plaatst een placeholder tijdens het laden, vervangt door fout bij storing en annuleert het verzoek wanneer de View het scherm verlaat. DefaultImageUrlLoader laadt de afbeelding via URL en slaat deze op in LruCache voor snelle herweergave.

Voor het gebruik van ImageLoader volstaat het om een instantie te maken via ImageLoader(queue, ImageCache), waarbij ImageCache de implementatie is van de ImageCache-interface met LruCache erin. NetworkImageView in XML wordt via de methode setImageUrl() aan ImageLoader gekoppeld en het hele laden gebeurt volledig automatisch zonder extra code voor het verwerken van placeholders en fouten.

Veelgemaakte fouten bij het werken met Volley

RequestQueue in elke Activity aanmaken — een veelgemaakte fout die leidt tot duplicatie van threads en verwarring in de cache. Het wordt aanbevolen om RequestQueue één keer aan te maken in Application of via een singleton-klasse. Anders heeft elk scherm zijn eigen threadpool en wordt de cache apart voor elke wachtrij opgeslagen.

Het negeren van het annuleren van verzoeken bij schermrotatie. Bij configuratiewijziging wordt de Activity opnieuw aangemaakt en blijven de callbacks van de oude Activity in het geheugen hangen. Dit leidt tot lekken en pogingen om een vernietigde View bij te werken. Annuleer altijd verzoeken in onStop() via cancelAll() met een voor de Activity specifieke tag.

Volley ondersteunt geen HTTP/2 en coroutines — dit is geen gebruikersfout, maar een architectuurbeperking. Volley is gemaakt in 2013 en ondersteunt geen moderne protocollen en Kotlin-coroutines. Voor nieuwe projecten raadt Google Retrofit + OkHttp aan. Volley is alleen geschikt voor ondersteuning van legacy-projecten of eenvoudige apps met minimale netwerkvereisten.