Volley — ano ito, mga tampok ng Google network library

Ano ang Volley?

Volley — ay isang library para sa network communication sa mga Android application, na ipinakita ng Google sa kumperensya ng I/O 2013. Ang pangalang Volley ay nangangahulugang “salvo” — ang library ay dinisenyo para sa pag-execute ng maraming parallel na mabilis na request, na karaniwan sa mga UI-oriented na application kung saan mahalaga ang bilis ng pagtugon ng interface.

Ang Volley ay ginawa bilang solusyon sa mga problema ng HttpURLConnection at AsyncTask: manu-manong pamamahala ng thread, kawalan ng caching, kahirapan sa pag-priprioritize ng mga request, at mabigat na code. Inilagay ng Google ang Volley bilang isang library para sa mga operasyong fire-and-forget — maliliit na request na ang resulta ay agad na ipinapakita sa interface.

Ang arkitektura ng Volley ay may tatlong pangunahing bahagi: RequestQueue (manager ng pila), CacheDispatcher (thread para sa mga naka-cache na tugon), at NetworkDispatcher (mga network thread). Ang arkitekturang ito ay awtomatikong namamahagi ng mga request: una ay sinusuri ang cache at kung wala lamang ito saka isinasagawa ang network request. Binabawasan nito ang latency para sa paulit-ulit na data ng 50–80%.

Paano gumagana ang Volley

RequestQueue — ang sentral na klase ng Volley. Ang mga Request<T> na object ay idinaragdag dito, at awtomatikong ipinamahagi ng pila ang mga ito sa dalawang uri ng thread: CacheDispatcher (isang thread, nagpoproseso ng mga request na may posibleng cache) at NetworkDispatcher (maraming thread, nag-execute ng mga aktwal na HTTP request). Bilang default, gumagawa ang Volley ng 4 na network thread.

Kapag may idinagdag na request, sinusuri ng RequestQueue kung maaari itong serbisyuhan mula sa cache. Kung ang cache ay naglalaman ng napapanahong tugon, ibinabalik ito agad ng CacheDispatcher, nang walang network request. Kung ang cache ay luma o wala, ang request ay ipinapasa sa NetworkDispatcher. Ang priyoridad ng request (low, normal, high, immediate) ay tumutukoy sa pagkakasunod-sunod ng pagproseso sa loob ng pila — ang mga request na may high priority ay pinoproseso bago ang normal.

Pagkatapos ma-execute ang request, ang resulta ay inihatid sa pangunahing thread (UI thread) sa pamamagitan ng Handler. Awtomatikong inililipat ng Volley ang mga callback na onResponse() at onErrorResponse() sa pangunahing thread, kaya maaari mong direktang i-update ang interface sa callback nang walang karagdagang paglilipat. Pinapasimple nito ang code at inaalis ang buong klase ng mga error na nauugnay sa thread.

Ang isa pang tampok ng Volley ay awtomatikong deduplikasyon ng mga request. Kung dalawang magkaparehong GET request sa parehong URL na may parehong parameter ang idinagdag sa pila, isa lang sa mga ito ang ini-execute ng Volley at ibinabalik ang parehong tugon sa parehong callback. Ito ay lalong kapaki-pakinabang para sa mga screen kung saan maraming component ang independiyenteng humihingi ng parehong data — halimbawa, profile ng user na sabay na kailangan ng header at ng fragment na may mga setting.

Ikot ng buhay ng request sa Volley

Bawat request ay dumadaan sa isang serye ng mga hakbang: paggawa ng Request, pagdagdag sa RequestQueue, pag-check ng cache (CacheDispatcher), pag-execute ng HTTP request (NetworkDispatcher), pag-parse ng tugon sa pamamagitan ng Response.Listener, paghahatid ng resulta sa UI thread. Kapag kinansela ang request (cancel), tinatanggal ito ng RequestQueue mula sa pila at pinipigilan ang pagtawag ng mga callback.

Sinusuportahan din ng Volley ang RetryPolicy, na tumutukoy sa bilang ng mga pagsubok muli kapag may mga pagkabigo. Ang DefaultRetryPolicy ay gumagawa ng isang pagsubok muli na may timeout na 2.5 segundo bilang default. Para sa mga hindi matatag na koneksyon, ang bilang ng mga pagsubok ay maaaring dagdagan sa 3, at ang timeout sa 10 segundo. Ang custom na RetryPolicy ay ipinapatupad sa pamamagitan ng interface ng RetryPolicy na may mga pamamaraan na getCurrentTimeout, getCurrentRetryCount, at retry.

Mga uri ng request sa Volley

Nagbibigay ang Volley ng mga handa nang uri ng request para sa mga karaniwang format ng data. Bawat uri ay nagpapatupad ng abstract class na Request<T> at tinutukoy ang paraan ng pag-parse ng tugon. Para sa mga custom na format, maaari kang gumawa ng sarili mong uri sa pamamagitan ng pag-override sa paraang parseNetworkResponse.

Mga custom na request

Para sa pagtatrabaho sa Gson o Kotlinx Serialization maaari kang gumawa ng custom na Request<T> na gumagamit ng napiling parser sa parseNetworkResponse. Ito ay nagbibigay-daan sa direktang pagkuha ng mga na-type na object, na lumalampas sa manu-manong pag-parse ng JSONObject. Ang ganitong approach ay lalong kapaki-pakinabang para sa mga proyektong gumagamit na ng serialization sa pamamagitan ng Gson o Moshi.

Para sa pagpapadala ng data, sinusuportahan ng Volley ang tatlong uri ng body: JSONObject (sa pamamagitan ng JsonObjectRequest na may POST method), Form-encoded (sa pamamagitan ng HashMap<String, String> sa constructor), at Multipart (sa pamamagitan ng custom na MultipartRequest). Ang mga Multipart request ay kapaki-pakinabang para sa pag-upload ng mga imahe at file, ngunit nangangailangan ng manu-manong implementasyon dahil ang Volley ay walang built-in na suporta para sa multipart/form-data hindi katulad ng OkHttp o Dio.

Ang mga limitasyon ng Volley ay nagiging kapansin-pansin kapag nagtatrabaho sa malalaking tugon. Ini-load ng Volley ang buong tugon sa memorya bago ito ipasa sa callback, na maaaring magdulot ng OutOfMemoryError para sa mga JSON file na mas malaki sa 10–20 MB. Para sa pag-load ng malalaking file, hindi angkop ang Volley — gamitin ang DownloadManager o OkHttp na may streaming na ResponseBody. Hindi rin sinusuportahan ng Volley ang pagpapatuloy ng mga naantala na download (Range header) at hindi gumagana sa mga streaming protocol tulad ng Server-Sent Events o WebSocket sa real-time.

Mga halimbawa ng Volley code sa Java at Kotlin

Tingnan natin ang pangunahing halimbawa — StringRequest para sa pagkuha ng data mula sa server. Una, ginagawa ang RequestQueue sa pamamagitan ng Volley.newRequestQueue(context). Pagkatapos, ang request na may URL at mga callback para sa tagumpay at error ay binubuo.

val queue = Volley.newRequestQueue(context)

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

queue.add(request)

Para sa JSON request ginagamit ang JsonObjectRequest, na awtomatikong nag-parse ng tugon sa JSONObject. Sinusuportahan ng Volley ang GET at POST request. Para sa POST, isang JSONObject ang ipinapadala sa body ng request.

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

queue.add(request)

Pagkansela ng mga request

Para sa pagkansela ng request ginagamit ang paraan ng cancel() o group cancellation ayon sa tag. Kapag kinansela, hindi tinatawag ng Volley ang onResponse o onErrorResponse, na pumipigil sa pag-update ng interface pagkatapos umalis sa screen. Ito ay mahalaga para maiwasan ang pagtagas ng memorya sa Activity at Fragment.

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

// Kanselahin kapag umalis sa screen
queue.cancelAll("profile_request")

ImageLoader at NetworkImageView

ImageLoader — ay isang wrapper class sa ibabaw ng RequestQueue, na na-optimize para sa pag-load ng mga imahe. Sinusuportahan nito ang memory cache (LruCache) at awtomatikong kinakansela ang mga request kapag muling ginamit ang ImageView sa mga listahan ng RecyclerView. Ini-scale din ng ImageLoader ang mga imahe sa laki ng View, na nakakatipid ng memorya.

NetworkImageView — ay isang custom na View na nagsasama sa ImageLoader at awtomatikong namamahala ng pag-load: nagtatakda ng placeholder habang naglo-load, pinapalitan ng error kapag nabigo, at kinakansela ang request kapag umalis ang View sa screen. Ang DefaultImageUrlLoader ay naglo-load ng imahe sa pamamagitan ng URL at ini-save ito sa LruCache para sa mabilis na muling pagpapakita.

Para magamit ang ImageLoader, sapat na ang gumawa ng instance sa pamamagitan ng ImageLoader(queue, ImageCache), kung saan ang ImageCache ay ang implementasyon ng interface ng ImageCache na may LruCache sa loob. Ang NetworkImageView sa XML ay kumokonekta sa ImageLoader sa pamamagitan ng paraang setImageUrl(), at ang buong pag-load ay nangyayari nang ganap na awtomatiko nang walang karagdagang code para sa paghawak ng mga placeholder at error.

Mga karaniwang pagkakamali sa paggamit ng Volley

Pag-gawa ng RequestQueue sa bawat Activity — isang karaniwang pagkakamali na humahantong sa pagdoble ng mga thread at pagkalito sa cache. Inirerekomenda na gumawa ng RequestQueue nang isang beses sa Application o sa pamamagitan ng singleton class. Kung hindi, ang bawat screen ay magkakaroon ng sarili nitong thread pool, at ang cache ay maiimbak nang hiwalay para sa bawat pila.

Pagwawalang-bahala sa pagkansela ng mga request sa pag-ikot ng screen. Kapag nagbago ang configuration, ang Activity ay muling nilikha at ang mga callback ng lumang Activity ay nananatili sa memorya. Ito ay humahantong sa pagtagas at pagtatangkang i-update ang nawasak na View. Palaging kanselahin ang mga request sa onStop() sa pamamagitan ng cancelAll() na may tag na tiyak sa Activity.

Hindi sinusuportahan ng Volley ang HTTP/2 at coroutine — ito ay hindi error sa paggamit, kundi isang limitasyon sa arkitektura. Ang Volley ay ginawa noong 2013 at hindi sumusuporta sa mga modernong protocol at Kotlin coroutine. Para sa mga bagong proyekto, inirerekomenda ng Google ang Retrofit + OkHttp. Ang Volley ay angkop lamang para sa pagsuporta sa mga legacy project o simpleng application na may minimal na pangangailangan sa network.