Volley — mi ez, a Google hálózati könyvtárának jellemzői

Mi az a Volley?

Volley — egy hálózati kommunikációs könyvtár Android-alkalmazásokhoz, amelyet a Google az I/O 2013 konferencián mutatott be. A Volley név „sortüzet” jelent — a könyvtár több párhuzamos gyors kérés végrehajtására szolgál, ami jellemző az UI-orientált alkalmazásokra, ahol a felület válaszsebessége fontos.

A Volley a HttpURLConnection és AsyncTask problémáinak megoldásaként jött létre: manuális szálkezelés, gyorsítótárazás hiánya, a kérések priorizálásának nehézsége és terjengős kód. A Google a Volley-t „fire-and-forget” típusú műveletek könyvtáraként pozicionálta — olyan kis kérések, amelyek eredménye azonnal megjelenik a felületen.

A Volley architektúrája három fő komponensből áll: RequestQueue (sorkezelő), CacheDispatcher (szál a gyorsítótárazott válaszokhoz) és NetworkDispatcher (hálózati szálak). Ez az architektúra automatikusan elosztja a kéréseket: először a gyorsítótár ellenőrzése történik, és csak annak hiányában kerül sor a hálózati kérésre. Ez 50–80%-kal csökkenti a késleltetést az ismétlődő adatok esetében.

Hogyan működik a Volley

RequestQueue — a Volley központi osztálya. Request<T> objektumokat adnak hozzá, és a sor automatikusan elosztja őket két száltípusra: CacheDispatcher (egy szál, a lehetséges gyorsítótárral rendelkező kéréseket dolgozza fel) és NetworkDispatcher (több szál, valódi HTTP-kéréseket hajtanak végre). Alapértelmezés szerint a Volley 4 hálózati szálat hoz létre.

Egy kérés hozzáadásakor a RequestQueue ellenőrzi, hogy kiszolgálható-e a gyorsítótárból. Ha a gyorsítótár naprakész választ tartalmaz, a CacheDispatcher azonnal visszaadja azt, hálózati kérés nélkül. Ha a gyorsítótár elavult vagy hiányzik, a kérés továbbításra kerül a NetworkDispatcher felé. A kérés prioritása (low, normal, high, immediate) határozza meg a feldolgozási sorrendet a sorban — a high prioritású kérések a normal előtt kerülnek feldolgozásra.

A kérés végrehajtása után az eredmény a Handleren keresztül a főszálba (UI thread) kerül. A Volley automatikusan átkapcsolja az onResponse() és onErrorResponse() callbackeket a főszálra, így a callbackben közvetlenül frissítheti a felületet további átkapcsolások nélkül. Ez leegyszerűsíti a kódot és kiküszöböli a szálakkal kapcsolatos hibák egész osztályát.

A Volley másik jellemzője a kérések automatikus deduplikációja. Ha két azonos GET-kérés ugyanarra az URL-re azonos paraméterekkel kerül a sorba, a Volley csak az egyiket hajtja végre, és ugyanazt a választ adja vissza mindkét callbacknek. Ez különösen hasznos olyan képernyőkön, ahol több komponens egymástól függetlenül kéri ugyanazokat az adatokat — például a felhasználói profil, amely egyszerre szükséges a fejlécnek és a beállításokat tartalmazó fragmentnek.

A kérés életciklusa a Volley-ben

Minden kérés egy lépéssorozaton megy keresztül: Request létrehozása, hozzáadás a RequestQueue-hoz, gyorsítótár ellenőrzése (CacheDispatcher), HTTP-kérés végrehajtása (NetworkDispatcher), válasz feldolgozása a Response.Listeneren keresztül, eredmény továbbítása az UI szálba. A kérés törlésekor (cancel) a RequestQueue eltávolítja a sorból és megakadályozza a callbackek meghívását.

A Volley támogatja a RetryPolicy-t is, amely meghatározza az újrapróbálkozások számát hibák esetén. A DefaultRetryPolicy alapértelmezés szerint egy újrapróbálkozást végez 2,5 másodperces időtúllépéssel. Instabil kapcsolatok esetén az újrapróbálkozások száma 3-ra, az időtúllépés pedig 10 másodpercre növelhető. Egyedi RetryPolicy a RetryPolicy interfészen keresztül valósítható meg a getCurrentTimeout, getCurrentRetryCount és retry metódusokkal.

Volley kéréstípusok

A Volley kész kéréstípusokat biztosít a gyakori adatformátumokhoz. Minden típus implementálja a Request<T> absztrakt osztályt és meghatározza a válasz feldolgozásának módját. Egyedi formátumokhoz saját típust hozhat létre a parseNetworkResponse metódus felülírásával.

Egyedi kérések

A Gson vagy Kotlinx Serialization használatához létrehozhat egy egyedi Request<T>-t, amely a parseNetworkResponse-ben a kiválasztott feldolgozót használja. Ez lehetővé teszi tipizált objektumok közvetlen elérését, megkerülve a JSONObject manuális feldolgozását. Ez a megközelítés különösen hasznos olyan projekteknél, amelyek már használnak serializációt Gson vagy Moshi segítségével.

Adatok küldéséhez a Volley három testtípust támogat: JSONObject (a JsonObjectRequest segítségével POST metódussal), Form-encoded (HashMap<String, String> segítségével a konstruktorban) és Multipart (egyedi MultipartRequest segítségével). A Multipart kérések hasznosak képek és fájlok feltöltéséhez, de manuális implementációt igényelnek, mivel a Volley-nek nincs beépített támogatása a multipart/form-data-hoz, ellentétben az OkHttp-val vagy a Dio-val.

A Volley korlátai nagy válaszok esetén válnak észrevehetővé. A Volley a teljes választ a memóriába tölti, mielőtt átadná a callbacknek, ami OutOfMemoryError-t okozhat a 10–20 MB-nál nagyobb JSON-fájlok esetén. Nagy fájlok betöltésére a Volley nem alkalmas — használja a DownloadManager-t vagy az OkHttp-t streaming ResponseBody-val. A Volley nem támogatja a megszakított letöltések folytatását (Range header) és nem működik streaming protokollokkal, mint a Server-Sent Events vagy a WebSocket valós időben.

Volley kódpéldák Java és Kotlin nyelven

Nézzük meg az alap példát — StringRequest adatok lekéréséhez a szerverről. Először a RequestQueue jön létre a Volley.newRequestQueue(context) segítségével. Ezután a kérés URL-lel és sikeres/hibás callbackekkel kerül összeállításra.

val queue = Volley.newRequestQueue(context)

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

queue.add(request)

A JSON-kéréshez a JsonObjectRequest használatos, amely automatikusan feldolgozza a választ JSONObject-té. A Volley támogatja a GET és POST kéréseket. POST esetén egy JSONObject kerül a kérés törzsébe.

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("Létrehozva: ${response.getString("id")}")
    },
    { println("Hiba: $it") }
)

queue.add(request)

Kérések törlése

A kérés törléséhez a cancel() metódus vagy a csoportos törlés címke alapján használható. Törléskor a Volley nem hívja meg sem az onResponse-t, sem az onErrorResponse-t, ami megakadályozza a felület frissítését a képernyő elhagyása után. Ez fontos a memóriaszivárgás megelőzéséhez Activity-ben és Fragment-ben.

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

// Megszakítás a képernyő elhagyásakor
queue.cancelAll("profile_request")

ImageLoader és NetworkImageView

ImageLoader — egy wrapper osztály a RequestQueue fölött, optimalizálva képek betöltésére. Támogatja a memória-gyorsítótárat (LruCache) és automatikusan törli a kéréseket az ImageView újrafelhasználásakor a RecyclerView listákban. Az ImageLoader skálázza a képeket a View méretére, memóriát takarítva meg.

NetworkImageView — egy egyedi View, amely integrálódik az ImageLoader-rel és automatikusan kezeli a betöltést: helyőrzőt állít be betöltéskor, hibára cseréli meghibásodáskor és törli a kérést, amikor a View elhagyja a képernyőt. A DefaultImageUrlLoader betölti a képet URL alapján és elmenti az LruCache-be a gyors újbóli megjelenítéshez.

Az ImageLoader használatához elegendő egy példány létrehozása az ImageLoader(queue, ImageCache) segítségével, ahol az ImageCache az ImageCache interfész implementációja LruCache-cel a belsejében. A NetworkImageView XML-ben a setImageUrl() metóduson keresztül kapcsolódik az ImageLoader-hez, és a teljes betöltés teljesen automatikusan történik, további kód nélkül a helyőrzők és hibák kezeléséhez.

Gyakori hibák a Volley használatakor

RequestQueue létrehozása minden Activity-ben — gyakori hiba, amely a szálak többszörözéséhez és a gyorsítótár zavarához vezet. A RequestQueue-t egyszer ajánlott létrehozni az Application-ben vagy egy singleton osztályon keresztül. Ellenkező esetben minden képernyőnek saját szálpoolja lesz, és a gyorsítótár külön kerül tárolásra minden sorhoz.

A kérések törlésének figyelmen kívül hagyása képernyőelforgatáskor. A konfiguráció változásakor az Activity újra létrejön, és a régi Activity callbackjei a memóriában maradnak. Ez szivárgáshoz és a megsemmisült View frissítésére tett kísérlethez vezet. Mindig törölje a kéréseket az onStop()-ban a cancelAll() segítségével, az Activity-re jellemző címkével.

A Volley nem támogatja a HTTP/2-t és a korutinokat — ez nem használati hiba, hanem architektúrális korlátozás. A Volley 2013-ban jött létre, és nem támogatja a modern protokollokat és a Kotlin korutinokat. Új projektekhez a Google a Retrofit + OkHttp használatát ajánlja. A Volley csak legacy projektek támogatására vagy egyszerű alkalmazásokhoz alkalmas minimális hálózati követelményekkel.