Volley — apa itu, fitur pustaka jaringan Google

Apa itu Volley?

Volley — adalah pustaka untuk komunikasi jaringan dalam aplikasi Android, yang diperkenalkan oleh Google pada konferensi I/O 2013. Nama Volley berarti “tembakan” — pustaka ini dirancang untuk mengeksekusi banyak permintaan cepat paralel, yang khas untuk aplikasi berorientasi UI di mana kecepatan respons antarmuka penting.

Volley diciptakan sebagai solusi untuk masalah HttpURLConnection dan AsyncTask: manajemen thread manual, tidak adanya caching, sulitnya memprioritaskan permintaan, dan kode yang berbelit-belit. Google memposisikan Volley sebagai pustaka untuk operasi fire-and-forget — permintaan kecil yang hasilnya langsung ditampilkan di antarmuka.

Arsitektur Volley mencakup tiga komponen utama: RequestQueue (manajer antrian), CacheDispatcher (thread untuk respons cache), dan NetworkDispatcher (thread jaringan). Arsitektur ini secara otomatis mendistribusikan permintaan: pertama cache diperiksa dan hanya jika tidak ada, permintaan jaringan dieksekusi. Ini mengurangi latensi untuk data berulang sebesar 50–80%.

Bagaimana Volley bekerja

RequestQueue — kelas sentral Volley. Objek Request<T> ditambahkan ke dalamnya, dan antrian secara otomatis mendistribusikannya ke dua jenis thread: CacheDispatcher (satu thread, memproses permintaan dengan kemungkinan cache) dan NetworkDispatcher (beberapa thread, mengeksekusi permintaan HTTP nyata). Secara default, Volley membuat 4 thread jaringan.

Saat permintaan ditambahkan, RequestQueue memeriksa apakah dapat dilayani dari cache. Jika cache berisi respons terkini, CacheDispatcher segera mengembalikannya, tanpa permintaan jaringan. Jika cache kedaluwarsa atau tidak ada, permintaan diteruskan ke NetworkDispatcher. Prioritas permintaan (low, normal, high, immediate) menentukan urutan pemrosesan dalam antrian — permintaan dengan prioritas high diproses lebih dulu dari normal.

Setelah permintaan dieksekusi, hasilnya dikirim ke thread utama (UI thread) melalui Handler. Volley secara otomatis mengalihkan callback onResponse() dan onErrorResponse() ke thread utama, sehingga Anda dapat langsung memperbarui antarmuka di dalam callback tanpa pengalihan tambahan. Ini menyederhanakan kode dan menghilangkan seluruh kelas kesalahan terkait thread.

Fitur lain dari Volley adalah deduplikasi otomatis permintaan. Jika dua permintaan GET identik ke URL yang sama dengan parameter yang sama ditambahkan ke antrian, Volley hanya mengeksekusi satu di antaranya dan mengembalikan respons yang sama ke kedua callback. Ini sangat berguna untuk layar di mana beberapa komponen secara independen meminta data yang sama — misalnya, profil pengguna yang sekaligus diperlukan oleh header dan fragmen dengan pengaturan.

Siklus hidup permintaan di Volley

Setiap permintaan melalui serangkaian langkah: pembuatan Request, penambahan ke RequestQueue, pemeriksaan cache (CacheDispatcher), eksekusi permintaan HTTP (NetworkDispatcher), parsing respons melalui Response.Listener, pengiriman hasil ke thread UI. Saat permintaan dibatalkan (cancel), RequestQueue menghapusnya dari antrian dan mencegah pemanggilan callback.

Volley juga mendukung RetryPolicy, yang menentukan jumlah percobaan ulang saat terjadi kegagalan. DefaultRetryPolicy secara default melakukan satu percobaan ulang dengan waktu tunggu 2,5 detik. Untuk koneksi yang tidak stabil, jumlah percobaan dapat ditingkatkan menjadi 3, dan waktu tunggu menjadi 10 detik. RetryPolicy kustom diimplementasikan melalui antarmuka RetryPolicy dengan metode getCurrentTimeout, getCurrentRetryCount, dan retry.

Jenis permintaan Volley

Volley menyediakan jenis permintaan siap pakai untuk format data umum. Setiap jenis mengimplementasikan kelas abstrak Request<T> dan menentukan cara parsing respons. Untuk format kustom, Anda dapat membuat jenis sendiri dengan menimpa metode parseNetworkResponse.

Permintaan kustom

Untuk bekerja dengan Gson atau Kotlinx Serialization, Anda dapat membuat Request<T> kustom yang menggunakan parser yang dipilih dalam parseNetworkResponse. Ini memungkinkan memperoleh objek yang diketik secara langsung, melewati parsing manual JSONObject. Pendekatan ini sangat berguna untuk proyek yang sudah menggunakan serialisasi melalui Gson atau Moshi.

Untuk mengirim data, Volley mendukung tiga jenis body: JSONObject (melalui JsonObjectRequest dengan metode POST), Form-encoded (melalui HashMap<String, String> di konstruktor), dan Multipart (melalui MultipartRequest kustom). Permintaan Multipart berguna untuk mengunggah gambar dan file, tetapi memerlukan implementasi manual karena Volley tidak memiliki dukungan bawaan untuk multipart/form-data tidak seperti OkHttp atau Dio.

Keterbatasan Volley menjadi terlihat saat bekerja dengan respons besar. Volley memuat seluruh respons ke memori sebelum meneruskannya ke callback, yang dapat menyebabkan OutOfMemoryError untuk file JSON yang lebih besar dari 10–20 MB. Untuk memuat file besar, Volley tidak cocok — gunakan DownloadManager atau OkHttp dengan ResponseBody streaming. Volley juga tidak mendukung kelanjutan unduhan yang terputus (Range header) dan tidak bekerja dengan protokol streaming seperti Server-Sent Events atau WebSocket secara real-time.

Contoh kode Volley di Java dan Kotlin

Mari kita lihat contoh dasar — StringRequest untuk mengambil data dari server. Pertama, RequestQueue dibuat melalui Volley.newRequestQueue(context). Kemudian permintaan dengan URL dan callback untuk sukses dan error disusun.

val queue = Volley.newRequestQueue(context)

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

queue.add(request)

Untuk permintaan JSON digunakan JsonObjectRequest, yang secara otomatis memparsing respons menjadi JSONObject. Volley mendukung permintaan GET dan POST. Untuk POST, JSONObject dikirim dalam body permintaan.

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

queue.add(request)

Membatalkan permintaan

Untuk membatalkan permintaan digunakan metode cancel() atau pembatalan grup berdasarkan tag. Saat dibatalkan, Volley tidak memanggil onResponse maupun onErrorResponse, yang mencegah pembaruan antarmuka setelah meninggalkan layar. Ini penting untuk mencegah kebocoran memori di Activity dan Fragment.

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

// Batalkan saat meninggalkan layar
queue.cancelAll("profile_request")

ImageLoader dan NetworkImageView

ImageLoader — adalah kelas wrapper di atas RequestQueue, dioptimalkan untuk memuat gambar. Ini mendukung cache memori (LruCache) dan secara otomatis membatalkan permintaan saat ImageView digunakan kembali dalam daftar RecyclerView. ImageLoader juga menskalakan gambar ke ukuran View, menghemat memori.

NetworkImageView — adalah View kustom yang terintegrasi dengan ImageLoader dan secara otomatis mengelola pemuatan: menetapkan placeholder saat memuat, menggantinya dengan error saat gagal, dan membatalkan permintaan saat View meninggalkan layar. DefaultImageUrlLoader memuat gambar melalui URL dan menyimpannya di LruCache untuk ditampilkan kembali dengan cepat.

Untuk menggunakan ImageLoader, cukup buat instance melalui ImageLoader(queue, ImageCache), di mana ImageCache adalah implementasi dari antarmuka ImageCache dengan LruCache di dalamnya. NetworkImageView dalam XML terhubung ke ImageLoader melalui metode setImageUrl(), dan seluruh pemuatan terjadi sepenuhnya otomatis tanpa kode tambahan untuk menangani placeholder dan error.

Kesalahan umum saat bekerja dengan Volley

Membuat RequestQueue di setiap Activity — kesalahan umum yang menyebabkan duplikasi thread dan kebingungan dalam cache. Disarankan untuk membuat RequestQueue satu kali di Application atau melalui kelas singleton. Jika tidak, setiap layar akan memiliki kumpulan thread sendiri, dan cache akan disimpan terpisah untuk setiap antrian.

Mengabaikan pembatalan permintaan saat rotasi layar. Saat konfigurasi berubah, Activity dibuat ulang dan callback Activity lama tetap berada di memori. Ini menyebabkan kebocoran dan upaya untuk memperbarui View yang sudah dihancurkan. Selalu batalkan permintaan di onStop() melalui cancelAll() dengan tag khusus Activity.

Volley tidak mendukung HTTP/2 dan coroutine — ini bukan kesalahan penggunaan, melainkan keterbatasan arsitektur. Volley dibuat pada tahun 2013 dan tidak mendukung protokol modern dan coroutine Kotlin. Untuk proyek baru, Google merekomendasikan Retrofit + OkHttp. Volley hanya cocok untuk mendukung proyek legacy atau aplikasi sederhana dengan kebutuhan jaringan minimal.