Comparaison des bibliothèques de mise en réseau Android: OkHTTP, Retrofit et Volley [fermé]

579

Question en deux parties d'un développeur iOS apprenant Android, travaillant sur un projet Android qui fera une variété de demandes de JSON à l'image pour télécharger en streaming de l'audio et de la vidéo:

  1. Sur iOS, j'ai beaucoup utilisé le projet AFNetworking . Existe-t-il une bibliothèque équivalente pour Android?

  2. J'ai lu OkHTTP et Retrofit by Square, ainsi que Volley, mais je n'ai pas encore d'expérience en développement avec eux. J'espère que quelqu'un pourrait fournir des exemples concrets de meilleurs cas d'utilisation pour chacun. D'après ce que j'ai lu, OkHTTP semble être le plus robuste des trois, et pourrait gérer les exigences de ce projet (mentionné ci-dessus).

Alfie Hanssen
la source
3
Si vous utilisez l'implémentation interne de HttpUrlConnection, vous devez considérer que HttpUrlConnection utilise des tentatives silencieuses sur les requêtes POST. Cela m'a causé beaucoup de dégâts. Pour plus d'informations, cliquez ici: stackoverflow.com/a/37675253/2061089
oli
1
si quelqu'un a besoin d'une liste de toutes les bibliothèques de réseautage, vous pouvez le trouver sur mon article de blog androidredman.wordpress.com/2017/06/26/…
Manohar Reddy
Volley peut exécuter les versions héritées d'Apache, HttpUrlConnection, Apache-4 ou OkHttp. Où sont Retrofit vraiment seulement des exécutions d'OkHttp. La mise à niveau est beaucoup plus facile à configurer.
bitsabhi

Réponses:

647

J'espère que quelqu'un pourra fournir des exemples concrets de meilleurs cas d'utilisation pour chacun.

Utilisez Retrofit si vous communiquez avec un service Web. Utilisez la bibliothèque de pairs Picasso si vous téléchargez des images. Utilisez OkHTTP si vous devez effectuer des opérations HTTP qui se trouvent en dehors de Retrofit / Picasso.

Volley rivalise à peu près avec Retrofit + Picasso. Du côté positif, c'est une bibliothèque. Du côté négatif, il s'agit d' une bibliothèque non documentée, non prise en charge, «jetez le code sur le mur et faites une présentation I | O dessus».

EDIT - Volley est désormais officiellement pris en charge par Google. Veuillez vous référer au Guide du développeur Google

D'après ce que j'ai lu, OkHTTP semble être le plus robuste des 3

Retrofit utilise OkHTTP automatiquement si disponible. Il y a un Gist de Jake Wharton qui relie Volley à OkHTTP.

et pourrait gérer les exigences de ce projet (mentionné ci-dessus).

Vous n'en utiliserez probablement aucun pour le "téléchargement en continu d'audio et de vidéo", selon la définition conventionnelle du "streaming". Au lieu de cela, le cadre multimédia d'Android traitera ces demandes HTTP pour vous.

Cela étant dit, si vous essayez de faire votre propre streaming HTTP, OkHTTP devrait gérer ce scénario; Je ne me souviens pas à quel point Volley gérerait ce scénario. Ni Retrofit ni Picasso ne sont conçus pour cela.

CommonsWare
la source
4
Merci @CommonsWare pour la réponse concise et la note sur la steez non documentée de Volley (j'ai eu cette impression, en particulier par rapport aux autres projets). M'aide vraiment à faire décoller les choses.
Alfie Hanssen
18
Une autre excellente réponse de @CommonsWare. Quelqu'un peut-il vérifier comment RoboSpice s'intègre dans tout cela?
user1923613
3
@ user1923613 github.com/octo-online/robospice si vous utilisez volley pour les appels réseau, alors pas besoin d'utiliser robospice !, volley fait la plupart des choses que Robospice fait pour les appels réseau, Robospice prend en charge REST prêt à l'emploi (en utilisant Spring Android ou Google Http Client ou Retrofit) .si vous voulez une mise en réseau rapide et un chargement d'images avec un client réseau robuste, vous pouvez vous lancer! mais vous pouvez remplacer la tâche asynchrone Android normale que vous utilisez Robospice pour de meilleures performances et éviter les fuites de mémoire!
LOG_TAG
4
@frostymarvelous: Je pense que les documents non documentés et non pris en charge sont plus que suffisants pour justifier. Ce n'est pas comme si Google n'avait pas de système pour gérer de manière plus formelle des choses comme celle-ci (par exemple, la bibliothèque de support Android). Au cours des deux années qui se sont écoulées depuis cette réponse, du côté positif, il existe un certain soutien de la communauté, y compris un empaquetage non officiel du code dans un artefact.
CommonsWare
4
@AbhinavVutukuri: Vous commentez une réponse d'il y a plus de deux ans. A cette époque, il n'y avait aucune documentation.
CommonsWare
361

En regardant la perspective Volley, voici quelques avantages pour votre besoin:

Volley, d'une part, se concentre totalement sur la gestion de petites requêtes HTTP individuelles. Donc, si la gestion de vos requêtes HTTP a des bizarreries, Volley a probablement un crochet pour vous. Si, d'autre part, vous avez une bizarrerie dans la gestion de votre image, le seul vrai crochet que vous avez est ImageCache . "Ce n'est pas rien, mais ce n'est pas beaucoup!". mais il a plus d'autres avantages comme Une fois que vous définissez vos demandes, les utiliser à partir d'un fragment ou d'une activité est indolore contrairement aux AsyncTasks parallèles

Avantages et inconvénients de Volley:

Alors qu'est-ce qui est bien avec Volley?

  • La partie mise en réseau n'est pas seulement pour les images. Volley est destiné à faire partie intégrante de votre back-end. Pour un nouveau projet basé sur un simple service REST, cela pourrait être une grande victoire.

  • NetworkImageView est plus agressif à propos du nettoyage des demandes que Picasso, et plus conservateur dans ses modèles d'utilisation de GC. NetworkImageView s'appuie exclusivement sur des références de mémoire solides et nettoie toutes les données de demande dès qu'une nouvelle demande est faite pour une ImageView, ou dès que cette ImageView passe hors écran.

  • Performance. Ce message n'évaluera pas cette affirmation, mais ils ont clairement pris soin d'être judicieux dans leurs modèles d'utilisation de la mémoire. Volley fait également un effort pour regrouper les rappels au thread principal afin de réduire le changement de contexte.

  • Volley a apparemment aussi un avenir. Consultez RequestFuture si vous êtes intéressé.

  • Si vous avez affaire à des images compressées à haute résolution, Volley est la seule solution ici qui fonctionne bien.

  • Volley peut être utilisé avec Okhttp (la nouvelle version d'Okhttp prend en charge NIO pour de meilleures performances)

  • Volley joue bien avec le cycle de vie de l'activité.

Problèmes avec Volley:
Étant donné que Volley est nouveau, peu de choses ne sont pas encore prises en charge, mais elles sont corrigées.

  1. Demandes en plusieurs parties (solution: https://github.com/vinaysshenoy/enhanced-volley )

  2. le code d'état 201 est considéré comme une erreur, les codes d'état de 200 à 207 sont maintenant des réponses réussies. (Correction: https://github.com/Vinayrraj/CustomVolley )

    Mise à jour: dans la dernière version de Google Volley, le bug des codes d'état 2XX est maintenant corrigé ! Merci à Ficus Kirkpatrick!

  3. c'est moins documenté mais beaucoup de gens soutiennent la volley dans github, la documentation de type java peut être trouvée ici . Sur le site Web des développeurs Android, vous pouvez trouver un guide pour la transmission de données réseau à l'aide de Volley . Et le code source de volley peut être trouvé sur Google Git

  4. Pour résoudre / modifier la politique de redirection du cadre Volley, utilisez Volley avec OkHTTP ( CommonsWare mentionné ci-dessus)

Vous pouvez également lire le chargement de l'image de Comparaison de Volley avec Picasso

Rénovation:

Il est publié par Square , cela offre des API REST très faciles à utiliser (Mise à jour: Voila! Avec support NIO)

Avantages de Retrofit:

  • Comparé à Volley, le code API REST de Retrofit est bref et fournit une excellente documentation API et a un bon support dans les communautés! Il est très facile de l'ajouter aux projets.

  • Nous pouvons l'utiliser avec n'importe quelle bibliothèque de sérialisation, avec gestion des erreurs.

Mise à jour: - Il y a beaucoup de très bons changements dans Retrofit 2.0.0-beta2

  • la version 1.6 de Retrofit avec OkHttp 2.0 est désormais dépendante d' Okio pour prendre en charge java.io et java.nio, ce qui facilite l'accès, le stockage et le traitement de vos données à l'aide de ByteString et Buffer pour faire des choses intelligentes pour économiser le CPU et la mémoire. (Pour info: cela me rappelle la bibliothèque OIN de Koush avec prise en charge NIO!) Nous pouvons utiliser Retrofit avec RxJava pour combiner et chaîner les appels REST à l'aide de rxObservables pour éviter les chaînes de rappel laides (pour éviter l'enfer de rappel !!) .

Inconvénients de Retrofit pour la version 1.6:

  • La fonctionnalité de gestion des erreurs liée à la mémoire n'est pas bonne (dans les anciennes versions de Retrofit / OkHttp), je ne sais pas si elle a été améliorée avec le support Okio avec Java NIO.

  • Une assistance minimale au filetage peut entraîner un rappel de l'enfer si nous l'utilisons de manière incorrecte.

(Tous les inconvénients ci-dessus ont été résolus dans la nouvelle version de Retrofit 2.0 beta)

================================================== ======================

Mise à jour:

Android Async vs Volley vs Retrofit benchmarks de performance (millisecondes, une valeur inférieure est meilleure):

Android Async vs Volley vs Retrofit benchmarks de performance

(Pour info ci-dessus, les informations sur les repères de mise à niveau s'amélioreront avec la prise en charge de Java NIO car la nouvelle version d'OKhttp dépend de la bibliothèque NIO Okio)

Dans les trois tests avec des répétitions variables (1 à 25 fois), Volley était de 50% à 75% plus rapide. La mise à niveau s'est effectuée à une vitesse impressionnante de 50% à 90% plus rapide que les AsyncTasks, atteignant le même point de terminaison le même nombre de fois. Dans la suite de tests Dashboard, cela s'est traduit par un chargement / analyse des données plusieurs secondes plus rapide. C'est une énorme différence dans le monde réel. Afin de rendre les tests équitables, les temps pour AsyncTasks / Volley incluaient l'analyse JSON car Retrofit le faisait automatiquement pour vous.

RetroFit remporte le test de référence!

Finalement, nous avons décidé de choisir Retrofit pour notre application. Non seulement il est ridiculement rapide, mais il correspond assez bien à notre architecture existante. Nous avons pu créer une interface de rappel parent qui effectue automatiquement la gestion des erreurs, la mise en cache et la pagination avec peu ou pas d'effort pour nos API. Afin de fusionner dans Retrofit, nous avons dû renommer nos variables pour rendre nos modèles conformes à GSON, écrire quelques interfaces simples, supprimer des fonctions de l'ancienne API et modifier nos fragments pour ne pas utiliser AsyncTasks. Maintenant que nous avons converti quelques fragments, c'est assez indolore. Il y a eu des difficultés et des problèmes croissants que nous avons dû surmonter, mais dans l'ensemble, tout s'est bien passé. Au début, nous avons rencontré quelques problèmes techniques / bugs, mais Square a une fantastique communauté Google+ qui a pu nous aider à le résoudre.

Quand utiliser Volley?!

Nous pouvons utiliser Volley lorsque nous avons besoin de charger des images ainsi que de consommer des API REST !, le système de mise en file d'attente des appels réseau est nécessaire pour de nombreuses demandes n / w en même temps! Volley a également une meilleure gestion des erreurs liées à la mémoire que Retrofit!

OkHttp peut être utilisé avec Volley, Retrofit utilise OkHttp par défaut! Il a un support SPDY , un pool de connexions, une mise en cache disque, une compression transparente! Récemment, il a obtenu un certain support de java NIO avec Okio bibliothèque .

Source, crédit: volley-vs-retrofit par M. Josh Ruesch

Remarque: À propos du streaming, cela dépend du type de streaming que vous souhaitez, comme RTSP / RTCP.

LOG_TAG
la source
@ Jan1337z +1 pour l'information! Je l'ai mis à jour! android.googlesource.com/platform/frameworks/volley
LOG_TAG
4
@LOG_TAG, il serait intéressant de comparer RoboSpice dans votre échantillon. Nous proposons même un module Retrofit donc je pense que cela nécessiterait très peu de changements. La source est-elle disponible quelque part? L'avantage de RS est qu'il gère correctement le cycle de vie de l'activité qui exécute les requêtes réseau, et nous fournissons également une mise en cache transparente, je suppose que la surcharge serait faible par rapport à une demande de retrofit pure.
Snicolas
@Snicolas J'ai obtenu ces résultats de référence par le blog Josh Ruesch , vous pouvez voir les conversions entre Ficus Kirkpatrick (fondateur de Volley), Josh Ruesch! Il n'a pas encore partagé de projet de test de référence n'importe où! Pour info, je viens de commencer à apprendre votre RoboSpice avec un échantillon de mise à niveau face à ce problème de notification :)
LOG_TAG
3
Salut! À propos des demandes en plusieurs parties avec Volley, je pense que nous pouvons utiliser MultipartEntityBuilderen httpmimebibliothèque avec lui.
BNK
2
Quelqu'un d'autre a-t-il vérifié ces repères? Étant donné que la bibliothèque http apache est obsolète dans M (et que je l'utilisais pour le générateur de parties multiples), j'ai décidé de migrer mon code réseau vers Retrofit. J'ai initialement changé l'un des appels GET pour obtenir un tas d'objets du serveur. J'ai chronométré le Retrofit vs AsyncTask (avec ma propre analyse JSON). La performance était très proche, pas une amélioration de 3x comme indiqué dans la colonne "One Discussion" du tableau. Certes, le code résultant est beaucoup plus propre et je n'ai pas eu à écrire mon propre analyseur JSON, mais pour une seule demande GET, l'amélioration n'était pas là.
Gary Kipnis
44

RoboSpice Vs. Volée

Depuis https://groups.google.com/forum/#!topic/robospice/QwVCfY_glOQ

  • RoboSpice (RS) est basé sur les services et est plus respectueux de la philosophie Android que Volley. Volley est basé sur les threads et ce n'est pas ainsi que le traitement en arrière-plan doit avoir lieu sur Android. En fin de compte, vous pouvez creuser les deux bibliothèques et trouver qu'elles sont assez similaires, mais notre façon de faire le traitement en arrière-plan est plus orientée vers Android, cela nous permet, par exemple, de dire aux utilisateurs que RS fait réellement quelque chose en arrière-plan, ce qui serait difficile pour la volée (en fait ce n'est pas du tout).
  • RoboSpice et volley offrent tous deux des fonctionnalités intéressantes telles que la priorisation, les politiques de nouvelle tentative, l'annulation de la demande. Mais RS offre plus: une mise en cache plus avancée et c'est un gros problème, avec la gestion du cache, l'agrégation des demandes, plus de fonctionnalités comme la reconnexion à une demande en attente, la gestion de l'expiration du cache sans compter sur les en-têtes de serveur, etc.
  • RoboSpice fait plus en dehors de UI Thread: volley désérialise vos POJO sur le thread principal, ce qui est horrible à mon avis. Avec RS, votre application sera plus réactive.
  • En termes de vitesse, nous avons certainement besoin de mesures. RS est devenu super rapide maintenant, mais nous n'avons toujours pas de chiffre à mettre ici. Volley devrait théoriquement être un peu plus rapide, mais RS est maintenant massivement parallèle ... qui sait?
  • RoboSpice offre une large gamme de compatibilité avec les extensions. Vous pouvez l'utiliser avec okhttp, retrofit, ormlite (beta), jackson, jackson2, gson, xml serializer, google http client, spring android ... Beaucoup. Volley peut être utilisé avec ok http et utilise gson. c'est ça.
  • Volley offre plus de sucre UI que RS. Volley fournit NetworkImageView, RS fournit un adaptateur de liste de diffusion. En termes de fonctionnalités, ce n'est pas si loin, mais je pense que Volley est plus avancé sur ce sujet.
  • Plus de 200 bogues ont été résolus dans RoboSpice depuis sa sortie initiale. Il est assez robuste et largement utilisé en production. Volley est moins mature mais sa base d'utilisateurs devrait croître rapidement (effet Google).
  • RoboSpice est disponible sur maven central. Volley est difficile à trouver;)
Snicolas
la source
Robospice utilise les services Android pour l'appel REST, pouvons-nous utiliser Robospice avec Retrofit pour minimiser les efforts d'analyse gson, de la même manière que nous pouvons utiliser Volley (basé sur la bande de roulement) avec Robospice? (pas sûr que ce soit le bon qsn à demander) Je cherche juste du volley avec service!
LOG_TAG
1
Volley avec service est essentiellement RS. Ou, chronologiquement, Volley est RS sans service et il manque quelques autres fonctionnalités. Et oui, vous pouvez utiliser Retrofit avec RS, et même ajouter okhttp si vous le souhaitez.
Snicolas
7
Pourquoi la volée est-elle difficile à trouver? compile 'com.mcxiaoke.volley:library:1.0.+'
Rob
1
@Rob il fut un temps où le clone de mcxiaoke n'était pas disponible. Vous avez dû inclure manuellement la volée dans votre application.
frostymarvelous
"volley désérialise vos POJO sur le fil principal". Vous pouvez recevoir les données JSON retournées et les désérialiser vous-même sur un thread séparé si cela pose un problème.
AndroidDev
20

AFNetworking pour Android:

La mise en réseau Android rapide est arrivée

La bibliothèque de mise en réseau Android rapide prend en charge tous les types de requêtes HTTP / HTTPS comme GET, POST, DELETE, HEAD, PUT, PATCH

La bibliothèque de réseautage Android rapide prend en charge le téléchargement de tout type de fichier

La bibliothèque de mise en réseau Android rapide prend en charge le téléchargement de tout type de fichier (prend en charge le téléchargement en plusieurs parties)

La bibliothèque de mise en réseau Android rapide prend en charge l'annulation d'une demande

La bibliothèque de mise en réseau Android rapide prend en charge la définition de la priorité pour toute demande (FAIBLE, MOYEN, ÉLEVÉ, IMMÉDIATE)

La bibliothèque de mise en réseau Android rapide prend en charge RxJava

Comme il utilise OkHttp comme couche réseau, il prend en charge:

La bibliothèque de mise en réseau Android rapide prend en charge la prise en charge HTTP / 2 permet à toutes les demandes au même hôte de partager un socket

La bibliothèque de mise en réseau Android rapide utilise le pool de connexions qui réduit la latence des demandes (si HTTP / 2 n'est pas disponible)

GZIP transparent réduit les tailles de téléchargement

La bibliothèque de réseautage Android rapide prend en charge la mise en cache des réponses, ce qui évite complètement le réseau pour les demandes répétées

Merci: la bibliothèque est créée par moi

Amit Shekhar
la source
1
Vous déclarez que votre bibliothèque prend en charge HTTP / 2, mais vous ne dites pas s'il existe une exigence d'API pour la prise en charge HTTP / 2. Ma compréhension était que le niveau d'API Android inférieur à 5.0 n'avait pas les bonnes méthodes de cryptage SSL pour prendre en charge HTTP / 2. Ne pas frapper, juste essayer d'évaluer pleinement votre solution proposée.
DoctorD
@AmitShekhar: Je voulais juste savoir lequel est le meilleur pour les appels d'API dans Android. J'utilise la bibliothèque de mise en réseau Android, ce qui est génial pour mettre en œuvre Retrofit, Volley ou la mise en réseau Android?
Parth Bhayani
@Amit Shekhar Quelle est l'efficacité de la mise en réseau Android rapide pour le téléchargement d'images en plusieurs parties, en particulier lorsqu'il s'agit de scénarios Internet bas?
user3135923
18

Async HTTP client loopj vs Volley

Les spécificités de mon projet sont de petites requêtes HTTP REST, toutes les 1-5 minutes.

J'utilise un client HTTP asynchrone (1.4.1) depuis longtemps. Les performances sont meilleures que l'utilisation du vanilla Apache httpClient ou d'une connexion URL HTTP. Quoi qu'il en soit, la nouvelle version de la bibliothèque ne fonctionne pas pour moi: la bibliothèque inter exception coupe la chaîne de rappels.

La lecture de toutes les réponses m'a motivé à essayer quelque chose de nouveau. J'ai choisi la bibliothèque HTTP Volley.

Après l'avoir utilisé pendant un certain temps, même sans tests, je vois clairement que le temps de réponse est tombé à 1,5x, 2x Volley.

Peut-être que Retrofit est meilleur qu'un client HTTP asynchrone? Je dois l'essayer. Mais je suis sûr que Volley n'est pas pour moi.

Sergey Vakulenko
la source
Toute analyse de Retrofit Vs AsyncHttpClient ??? Veuillez poster si oui @Sergey
IshRoid
J'utilise AsyncHttpClient depuis quelques années. La mauvaise partie est que le repo github est de 2 ans sans engagement.
Vitor Hugo Schwaab,
Ce n'est plus réel, async http est trop démodé. Pensez à passer à une autre bibliothèque. Volley est également devenu un très bon choix.
Sergey Vakulenko
Sergey, @IshRoid je suis toujours à la recherche d'une réponse à votre question j'utilise AsyncHttpClient dois-je utiliser quelque chose d'autre comme RxJava Retrofit ou toute autre chose..Veuillez me le faire savoir .. en attendant avec impatience une réponse
Deep Dave
11

Juste pour ajouter un peu à la discussion de mon expérience de travail avec Volley:

  1. Volley ne gère en aucun cas les téléchargements en continu ou les téléchargements. Autrement dit, le corps de la demande doit être en mémoire dans son intégralité et vous ne pouvez pas utiliser un OutputStreampour écrire le corps de la demande dans le socket sous-jacent, ni utiliser un InputStreampour lire le corps de la réponse, comme c'est le cas pour Basic HttpURLConnection. Ainsi, Volley est un mauvais choix pour télécharger ou télécharger des fichiers volumineux. Vos demandes et réponses doivent être petites. C'est l'une des plus grandes limitations de Volley que j'ai personnellement rencontrées. Pour ce que ça vaut, OkHttp a des interfaces pour travailler avec les flux.

  2. Le manque de documentation officielle est ennuyeux, même si j'ai pu contourner cela en lisant le code source, ce qui est assez facile à suivre. Ce qui est plus gênant, c'est que, pour autant que je sache, Volley n'a pas de versions officielles et aucun artefact Maven ou Gradle, et donc le gérer comme une dépendance devient plus un casse-tête que, disons, toutes les bibliothèques que Square a publiées . Vous venez de cloner un dépôt, de construire un pot et vous êtes seul. Vous cherchez une correction de bogue? Va chercher et j'espère que c'est là. Vous pourriez aussi avoir d'autres trucs; cela ne sera pas documenté. À mon avis, cela signifie effectivement que Volley est une bibliothèque tierce non prise en charge, même si la base de code est raisonnablement active. Caveat emptor.

  3. En gros, avoir le Content-Type lié au type classe / demande (JsonObjectRequest, ImageRequest, etc.) est un peu gênant et réduit un peu la flexibilité du code appelant, car vous êtes lié à la hiérarchie de types de demande existante de Volley. J'aime la simplicité de simplement définir Content-Type comme un en-tête comme les autres (ne le faites pas avec Volley, au fait; vous vous retrouverez avec deux en-têtes Content-Type!). C'est juste mon opinion personnelle, cependant, et cela peut être contourné.

Cela ne veut pas dire que Volley ne possède pas de fonctionnalités utiles. C'est certainement le cas. Des politiques de relance facilement personnalisables, une mise en cache transparente, une API d'annulation et la prise en charge de la planification des demandes et des connexions simultanées sont d'excellentes fonctionnalités. Sachez simplement qu'il n'est pas destiné à tous les cas d'utilisation HTTP (voir l'élément 1 ci-dessus), et qu'il y a quelques maux de tête impliqués dans la mise en production de Volley dans votre application (élément 2).

Jeff
la source
Le chargement complet de la mémoire est ce que je me tue lentement. Dieu merci, quelqu'un d'autre l'a mentionné.
TheSunny
La bibliothèque peut également faire une copie défensive de votre corps de demande, de sorte que la consommation de mémoire pour les demandes volumineuses pourrait être le double de ce à quoi vous pourriez vous attendre.
Jeff
9

J'ai récemment trouvé une bibliothèque appelée ion qui apporte un petit plus à la table.

ion a un support intégré pour le téléchargement d'images intégré à ImageView, JSON (avec l'aide de GSON), des fichiers et un support de threading UI très pratique.

Je l'utilise sur un nouveau projet et jusqu'à présent, les résultats ont été bons. Son utilisation est beaucoup plus simple que Volley ou Retrofit.

Tiago Gaspar
la source
2
ion vs retrofit, lequel recommanderiez-vous?
Sreekanth Karumanaghat
Retrofit is better then ion
Rajesh Koshti
4

Ajout à la réponse acceptée et à ce que LOG_TAG a dit .... pour que Volley analyse vos données dans un thread d'arrière-plan, vous devez sous-classer Request<YourClassName>car la onResponseméthode est appelée sur le thread principal et l'analyse sur le thread principal peut entraîner un décalage de l'interface utilisateur si votre réponse est grand. Lisez ici comment procéder.

upenpat
la source
1
à droite ... Volley analyse la réponse sur le thread principal, ce qui entraîne un retard de l'interface utilisateur lorsque la réponse est très importante.
Gopal Singh Sirvi
3

Retrofit 1.9.0 contre RoboSpice

J'utilise les deux dans mon application.

Robospice fonctionne plus rapidement que Retrofit chaque fois que j'analyse la classe JSON imbriquée. Parce que Spice Manger fera tout pour vous. Dans Retrofit, vous devez créer GsonConverter et le désérialiser.

J'ai créé deux fragments dans la même activité et appelé en même temps avec deux mêmes types d'URL.

09-23 20:12:32.830  16002-16002/com.urbanpro.seeker E/RETROFIT   RestAdapter Init
09-23 20:12:32.833  16002-16002/com.urbanpro.seeker E/RETROFIT calling the method
09-23 20:12:32.837  16002-16002/com.urbanpro.seeker E/ROBOSPICE initialzig spice manager
09-23 20:12:32.860  16002-16002/com.urbanpro.seeker E/ROBOSPICE Executing the method
09-23 20:12:33.537  16002-16002/com.urbanpro.seeker E/ROBOSPICE on SUcceess
09-23 20:12:33.553  16002-16002/com.urbanpro.seeker E/ROBOSPICE gettting the all contents
09-23 20:12:33.601  16002-21819/com.urbanpro.seeker E/RETROFIT deseriazation starts
09-23 20:12:33.603  16002-21819/com.urbanpro.seeker E/RETROFIT deseriazation ends
Asthme
la source
2

Et encore une autre option: https://github.com/apptik/jus

  • Il est modulaire comme Volley, mais plus étendu et la documentation s'améliore, prenant en charge différentes piles et convertisseurs HTTP prêts à l'emploi
  • Il dispose d'un module pour générer des mappages d'interface API de serveur comme Retrofit
  • Il prend également en charge JavaRx

Et de nombreuses autres fonctionnalités pratiques comme les marqueurs, les transformateurs, etc.

Kalin
la source