Volley — шта је то, карактеристике Google мрежне библиотеке

Шта је Volley?

Volley — је библиотека за мрежну комуникацију у Android апликацијама, представљена од стране Google-а на конференцији I/O 2013. Назив Volley значи „салва“ — библиотека је намењена за извршавање више паралелних брзих захтева, карактеристичних за UI-оријентисане апликације где је важна брзина одзива интерфејса.

Volley је створена као решење проблема HttpURLConnection и AsyncTask: ручно управљање нитима, недостатак кеширања, тешкоћа приоритизације захтева и гломазан код. Google је позиционирао Volley као библиотеку за операције типа fire-and-forget — малих захтева чији се резултат одмах приказује у интерфејсу.

Архитектура Volley-ја укључује три главне компоненте: RequestQueue (менаџер реда), CacheDispatcher (нит за кеширане одговоре) и NetworkDispatcher (мрежне нити). Ова архитектура аутоматски распоређује захтеве: прво се проверава кеш и само у његовом одсуству извршава се мрежни захтев. Ово смањује кашњење за понављајуће податке за 50–80%.

Како ради Volley

RequestQueue — централна класа Volley-ја. У њу се додају објекти Request<T>, и ред их аутоматски распоређује на два типа нити: CacheDispatcher (једна нит, обрађује захтеве са могућим кешом) и NetworkDispatcher (више нити, извршавају стварне HTTP захтеве). Подразумевано Volley креира 4 мрежне нити.

При додавању захтева RequestQueue проверава да ли се може обслужити из кеша. Ако кеш садржи актуелан одговор, CacheDispatcher га враћа одмах, без мрежног захтева. Ако је кеш застарео или недостаје, захтев се прослеђује NetworkDispatcher-у. Приоритет захтева (low, normal, high, immediate) одређује редослед обраде унутар реда — захтеви са high приоритетом се обрађују пре normal.

Након извршења захтева, резултат се доставља у главну нит (UI thread) преко Handler-а. Volley аутоматски пребацује callback-ове onResponse() и onErrorResponse() на главну нит, тако да можете директно ажурирати интерфејс у callback-у без додатних пребацивања. Ово поједностављује код и елиминише читаву класу грешака везаних за нити.

Још једна карактеристика Volley-ја је аутоматска дедупликација захтева. Ако су у ред додата два идентична GET захтева ка истом URL-у са истим параметрима, Volley извршава само један од њих и враћа исти одговор оба callback-а. Ово је посебно корисно за екране где неколико компоненти независно захтева исте податке — на пример, профил корисника који је истовремено потребан и заглављу и фрагменту са подешавањима.

Животни циклус захтева у Volley-ју

Сваки захтев пролази кроз низ корака: креирање Request, додавање у RequestQueue, провера кеша (CacheDispatcher), извршење HTTP захтева (NetworkDispatcher), парсирање одговора кроз Response.Listener, достављање резултата у UI нит. При отказивању захтева (cancel) RequestQueue га уклања из реда и спречава позив callback-ова.

Volley такође подржава RetryPolicy, који одређује број поновних покушаја при отказима. DefaultRetryPolicy подразумевано чини један поновни покушај са тајмаутом од 2,5 секунде. За нестабилне везе број покушаја се може повећати на 3, а тајмаут на 10 секунди. Прилагођени RetryPolicy се имплементира кроз интерфејс RetryPolicy са методама getCurrentTimeout, getCurrentRetryCount и retry.

Типови захтева Volley

Volley пружа готове типове захтева за уобичајене формате података. Сваки тип имплементира апстрактну класу Request<T> и дефинише начин парсирања одговора. За прилагођене формате можете креирати сопствени тип, преписујући метод parseNetworkResponse.

Прилагођени захтеви

За рад са Gson или Kotlinx Serialization можете креирати прилагођени Request<T> који у parseNetworkResponse користи изабрани парсер. Ово омогућава добијање типизованих објеката директно, заобилазећи ручно парсирање JSONObject-а. Такав приступ је посебно користан за пројекте који већ користе серијализацију кроз Gson или Moshi.

За слање података Volley подржава три типа тела: JSONObject (кроз JsonObjectRequest са POST методом), Form-encoded (кроз HashMap<String, String> у конструктору) и Multipart (кроз прилагођени MultipartRequest). Multipart захтеви су корисни за отпремање слика и датотека, али захтевају ручну имплементацију, јер Volley нема уграђену подршку за multipart/form-data за разлику од OkHttp или Dio.

Ограничења Volley-ја постају приметна при раду са великим одговорима. Volley учитава цео одговор у меморију пре прослеђивања callback-у, што може изазвати OutOfMemoryError за JSON датотеке веће од 10–20 MB. За учитавање великих датотека Volley није погодан — користите DownloadManager или OkHttp са токовним ResponseBody. Volley такође не подржава наставак прекинутих преузимања (Range header) и не ради са токовним протоколима попут Server-Sent Events или WebSocket у реалном времену.

Примери кода Volley у Java и Kotlin

Размотримо основни пример — StringRequest за добијање података са сервера. Прво се креира RequestQueue кроз Volley.newRequestQueue(context). Затим се формира захтев са URL-ом и callback-овима за успех и грешку.

val queue = Volley.newRequestQueue(context)

val request = StringRequest(
    Request.Method.GET,
    "https://api.github.com/users/octocat",
    { response ->
        println("Одговор: $response")
    },
    { error ->
        println("Грешка: ${error.message}")
    }
)

queue.add(request)

За JSON захтев користи се JsonObjectRequest који аутоматски парсира одговор у JSONObject. Volley подржава GET и POST захтеве. За POST се прослеђује JSONObject у телу захтева.

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("Креирано: ${response.getString("id")}")
    },
    { println("Грешка: $it") }
)

queue.add(request)

Отказивање захтева

За отказивање захтева користи се метод cancel() или групно отказивање по тагу. При отказивању Volley не позива ни onResponse ни onErrorResponse, што спречава ажурирање интерфејса након напуштања екрана. Ово је важно за спречавање цурења меморије у Activity и Fragment.

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

// Откажи при напуштању екрана
queue.cancelAll("profile_request")

ImageLoader и NetworkImageView

ImageLoader — је класа омотач над RequestQueue, оптимизована за учитавање слика. Подржава меморијски кеш (LruCache) и аутоматски отказује захтеве при поновном коришћењу ImageView у RecyclerView листама. ImageLoader такође скалира слике на величину View, штедећи меморију.

NetworkImageView — је прилагођени View који се интегрише са ImageLoader-ом и аутоматски управља учитавањем: поставља placeholder током учитавања, замењује га грешком при отказу и отказује захтев при напуштању екрана од стране View-а. DefaultImageUrlLoader учитава слику по URL-у и чува је у LruCache-у за брзо поновно приказивање.

За коришћење ImageLoader-а довољно је креирати инстанцу кроз ImageLoader(queue, ImageCache), где је ImageCache имплементација интерфејса ImageCache са LruCache-ом изнутра. NetworkImageView у XML-у се повезује са ImageLoader-ом кроз метод setImageUrl(), и целокупно учитавање се одвија потпуно аутоматски без додатног кода за обраду placeholder-а и грешака.

Типичне грешке при раду са Volley

Креирање RequestQueue у сваком Activity-ју — честа грешка која доводи до дуплирања нити и забуне у кешу. RequestQueue се препоручује креирати једном у Application-у или кроз singleton класу. У супротном, сваки екран ће имати свој pool нити, а кеш ће се чувати одвојено за сваки ред.

Игнорисање отказивања захтева при ротацији екрана. При промени конфигурације Activity се поново креира, а callback-ови старог Activity-ја остају у меморији. То доводи до цурења и покушаја ажурирања уништеног View-а. Увек отказујте захтеве у onStop() кроз cancelAll() са тагом специфичним за Activity.

Volley не подржава HTTP/2 и корутине — ово није грешка употребе, већ архитектонско ограничење. Volley је креиран 2013. године и не подржава модерне протоколе и Kotlin корутине. За нове пројекте Google препоручује Retrofit + OkHttp. Volley је погодан само за подршку legacy пројеката или једноставних апликација са минималним мрежним захтевима.