Volley — qu'est-ce que c'est, caractéristiques de la bibliothèque réseau de Google

Qu'est-ce que Volley ?

Volley est une bibliothèque de communication réseau pour les applications Android, présentée par Google lors de la conférence I/O 2013. Le nom Volley signifie « une salve » — la bibliothèque est conçue pour exécuter plusieurs requêtes rapides en parallèle, caractéristiques des applications orientées UI où la vitesse de réponse de l'interface est importante.

Volley a été créée comme une solution aux problèmes de HttpURLConnection et AsyncTask : gestion manuelle des threads, absence de cache, complexité de priorisation des requêtes et code volumineux. Google a positionné Volley comme une bibliothèque pour les opérations de type « fire-and-forget » — de petites requêtes dont le résultat s'affiche immédiatement dans l'interface.

L'architecture de Volley comprend trois composants principaux : RequestQueue (gestionnaire de file d'attente), CacheDispatcher (thread pour les réponses mises en cache) et NetworkDispatcher (threads réseau). Cette architecture distribue automatiquement les requêtes : le cache est d'abord vérifié, et ce n'est qu'en son absence qu'une requête réseau est effectuée. Cela réduit la latence pour les données répétées de 50 à 80 %.

Comment fonctionne Volley

RequestQueue est la classe centrale de Volley. Des objets Request<T> y sont ajoutés, et la file d'attente les distribue automatiquement entre deux types de threads : CacheDispatcher (un thread, gère les requêtes avec cache possible) et NetworkDispatcher (plusieurs threads, effectuent les requêtes HTTP réelles). Par défaut, Volley crée 4 threads réseau.

Lorsqu'une requête est ajoutée, RequestQueue vérifie si elle peut être servie depuis le cache. Si le cache contient une réponse à jour, CacheDispatcher la retourne immédiatement, sans requête réseau. Si le cache est obsolète ou absent, la requête est transmise à NetworkDispatcher. La priorité de la requête (low, normal, high, immediate) détermine l'ordre de traitement dans la file d'attente — les requêtes avec une priorité high sont traitées avant les normales.

Après l'exécution de la requête, le résultat est livré au thread principal (UI thread) via Handler. Volley bascule automatiquement les callbacks onResponse() et onErrorResponse() vers le thread principal, de sorte que l'interface peut être mise à jour directement dans le callback sans changement de thread supplémentaire. Cela simplifie le code et élimine toute une classe d'erreurs de threading.

Une autre caractéristique de Volley est la déduplication automatique des requêtes. Si deux requêtes GET identiques vers la même URL avec les mêmes paramètres sont ajoutées à la file d'attente, Volley n'en exécute qu'une seule et retourne la même réponse aux deux callbacks. C'est particulièrement utile pour les écrans où plusieurs composants demandent indépendamment les mêmes données — par exemple, un profil utilisateur qui est nécessaire à la fois à l'en-tête et à un fragment de paramètres.

Cycle de vie d'une requête dans Volley

Chaque requête passe par une séquence d'étapes : création d'une Request, ajout à RequestQueue, vérification du cache (CacheDispatcher), exécution de la requête HTTP (NetworkDispatcher), analyse de la réponse via Response.Listener, livraison du résultat au thread UI. Lorsqu'une requête est annulée (cancel), RequestQueue la supprime de la file d'attente et empêche l'appel des callbacks.

Volley prend également en charge RetryPolicy, qui détermine le nombre de tentatives en cas d'échec. DefaultRetryPolicy effectue par défaut une tentative avec un délai d'attente de 2,5 secondes. Pour les connexions instables, le nombre de tentatives peut être augmenté à 3 et le délai d'attente à 10 secondes. Une RetryPolicy personnalisée est implémentée via l'interface RetryPolicy avec les méthodes getCurrentTimeout, getCurrentRetryCount et retry.

Types de requêtes Volley

Volley fournit des types de requêtes prêts à l'emploi pour les formats de données courants. Chaque type implémente la classe abstraite Request<T> et définit une méthode pour analyser la réponse. Pour les formats personnalisés, vous pouvez créer votre propre type en redéfinissant la méthode parseNetworkResponse.

Requêtes personnalisées

Pour travailler avec Gson ou Kotlinx Serialization, vous pouvez créer une Request<T> personnalisée qui utilise l'analyseur choisi dans parseNetworkResponse. Cela permet de recevoir des objets typés directement, en évitant l'analyse manuelle de JSONObject. Cette approche est particulièrement utile pour les projets qui utilisent déjà la sérialisation via Gson ou Moshi.

Pour envoyer des données, Volley prend en charge trois types de corps : JSONObject (via JsonObjectRequest avec la méthode POST), Form-encoded (via HashMap<String, String> dans le constructeur) et Multipart (via un MultipartRequest personnalisé). Les requêtes Multipart sont utiles pour télécharger des images et des fichiers mais nécessitent une implémentation manuelle car Volley n'a pas de prise en charge intégrée pour multipart/form-data, contrairement à OkHttp ou Dio.

Les limitations de Volley deviennent perceptibles lors du traitement de grandes réponses. Volley charge l'intégralité de la réponse en mémoire avant de la passer au callback, ce qui peut provoquer une OutOfMemoryError pour les fichiers JSON de plus de 10 à 20 Mo. Pour télécharger de gros fichiers, Volley n'est pas adapté — utilisez DownloadManager ou OkHttp avec ResponseBody en streaming. Volley ne prend pas non plus en charge la reprise des téléchargements interrompus (en-tête Range) et ne fonctionne pas avec les protocoles de streaming comme Server-Sent Events ou WebSocket en temps réel.

Exemples de code Volley en Java et Kotlin

Regardons un exemple de base — un StringRequest pour récupérer des données depuis un serveur. D'abord, une RequestQueue est créée via Volley.newRequestQueue(context). Ensuite, une requête est formée avec une URL et des callbacks de succès et d'erreur.

val queue = Volley.newRequestQueue(context)

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

queue.add(request)

Pour une requête JSON, JsonObjectRequest est utilisé, qui analyse automatiquement la réponse en un JSONObject. Volley prend en charge les requêtes GET et POST. Pour POST, un JSONObject est passé dans le corps de la requête.

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

queue.add(request)

Annulation des requêtes

Pour annuler une requête, la méthode cancel() ou l'annulation groupée par tag est utilisée. Lors de l'annulation, Volley n'appelle ni onResponse ni onErrorResponse, ce qui évite les mises à jour de l'interface après avoir quitté l'écran. C'est important pour prévenir les fuites mémoire dans Activity et Fragment.

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

// Annulation en quittant l'écran
queue.cancelAll("profile_request")

ImageLoader et NetworkImageView

ImageLoader est une classe wrapper autour de RequestQueue, optimisée pour le chargement d'images. Il prend en charge le cache mémoire (LruCache) et annule automatiquement les requêtes lors de la réutilisation d'ImageView dans les listes RecyclerView. ImageLoader redimensionne également les images à la taille de la View, économisant ainsi la mémoire.

NetworkImageView est une View personnalisée qui s'intègre à ImageLoader et gère automatiquement le chargement : affiche un placeholder pendant le chargement, le remplace par une erreur en cas d'échec et annule la requête lorsque la View quitte l'écran. DefaultImageUrlLoader charge une image par URL et la stocke dans LruCache pour un réaffichage rapide.

Pour utiliser ImageLoader, créez simplement une instance via ImageLoader(queue, ImageCache), où ImageCache est une implémentation de l'interface ImageCache avec LruCache à l'intérieur. NetworkImageView dans le layout XML est lié à ImageLoader via la méthode setImageUrl(), et tout le chargement se fait complètement automatiquement sans code supplémentaire pour gérer les placeholders et les erreurs.

Erreurs courantes lors de l'utilisation de Volley

Créer une RequestQueue dans chaque Activity est une erreur courante qui entraîne une duplication des threads et une confusion du cache. Il est recommandé de créer RequestQueue une fois dans Application ou via une classe singleton. Sinon, chaque écran aura son propre pool de threads et le cache sera stocké séparément pour chaque file d'attente.

Ignorer l'annulation des requêtes lors de la rotation de l'écran. Lors d'un changement de configuration, l'Activity est recréée et les callbacks de l'ancienne Activity continuent de résider en mémoire. Cela provoque des fuites et des tentatives de mise à jour d'une View détruite. Annulez toujours les requêtes dans onStop() via cancelAll() avec un tag spécifique à l'Activity.

Volley ne prend pas en charge HTTP/2 et les coroutines — ce n'est pas une erreur d'utilisation mais une limitation architecturale. Volley a été créé en 2013 et ne prend pas en charge les protocoles modernes et les coroutines Kotlin. Pour les nouveaux projets, Google recommande d'utiliser Retrofit + OkHttp. Volley ne convient que pour la prise en charge de projets existants ou d'applications simples avec des besoins réseau minimaux.