Comparación de las bibliotecas de redes de Android: OkHTTP, Retrofit y Volley [cerrado]

579

Pregunta en dos partes de un desarrollador de iOS que está aprendiendo Android, trabajando en un proyecto de Android que hará una variedad de solicitudes de JSON a la imagen para la descarga de audio y video:

  1. En iOS, he usado el proyecto AFNetworking ampliamente. ¿Hay una biblioteca equivalente para Android?

  2. He leído sobre OkHTTP y Retrofit by Square, así como sobre Volley, pero todavía no tengo experiencia desarrollando con ellos. Espero que alguien pueda proporcionar algunos ejemplos concretos de los mejores casos de uso para cada uno. Por lo que he leído, parece que OkHTTP es el más robusto de los tres, y podría manejar los requisitos de este proyecto (mencionado anteriormente).

Alfie Hanssen
fuente
3
Si está utilizando la implementación interna de HttpUrlConnection, debe considerar que HttpUrlConnection usa reintentos silenciosos en las solicitudes POST. Eso me causó muchos daños. Para obtener más información, lea aquí: stackoverflow.com/a/37675253/2061089
oli
1
si alguien necesita una lista de todas las bibliotecas de redes, puede encontrarla en mi blog androidredman.wordpress.com/2017/06/26/…
Manohar Reddy
Volley puede ejecutar Apache, HttpUrlConnection, Apache-4 u OkHttp heredados. ¿Dónde están Retrofit realmente solo ejecuta OkHttp. La actualización es mucho más fácil de configurar.
bitsabhi

Respuestas:

647

Espero que alguien pueda proporcionar algunos ejemplos concretos de los mejores casos de uso para cada uno.

Use Retrofit si se está comunicando con un servicio web. Use la biblioteca de pares Picasso si está descargando imágenes. Use OkHTTP si necesita realizar operaciones HTTP que se encuentran fuera de Retrofit / Picasso.

Volley compite aproximadamente con Retrofit + Picasso. En el lado positivo, es una biblioteca. En el lado negativo, es una biblioteca indocumentada, no admitida, "arroje el código sobre la pared y haga una presentación de I | O en él".

EDITAR - Volley ahora es oficialmente compatible con Google. Consulte la Guía para desarrolladores de Google

Por lo que he leído, parece que OkHTTP es el más robusto de los 3

La actualización utiliza OkHTTP automáticamente si está disponible. Hay un Gist de Jake Wharton que conecta Volley a OkHTTP.

y podría manejar los requisitos de este proyecto (mencionado anteriormente).

Probablemente no utilizará ninguno de ellos para la "descarga de transmisión de audio y video", según la definición convencional de "transmisión". En cambio, el marco de medios de Android manejará esas solicitudes HTTP por usted.

Dicho esto, si va a intentar hacer su propia transmisión basada en HTTP, OkHTTP debería manejar ese escenario; No recuerdo qué tan bien Volley manejaría ese escenario. Ni Retrofit ni Picasso están diseñados para eso.

CommonsWare
fuente
44
Gracias @CommonsWare por la respuesta concisa, y la nota sobre el steez indocumentado de Volley (tuvo esa impresión, especialmente en comparación con los otros proyectos). Definitivamente me ayuda a despegar las cosas.
Alfie Hanssen
18
Otra gran respuesta de @CommonsWare. ¿Alguien puede seguir cómo RoboSpice encaja en todo esto?
user1923613
3
@ user1923613 github.com/octo-online/robospice si está utilizando volley para llamadas de red, entonces no es necesario usar robospice !, volley hace muchas de las cosas que hace Robospice para llamadas de red, Robospice admite REST de fábrica (usando Spring Android o Google Http Client o Retrofit) .Si desea una conexión en red y una carga de imágenes rápidas con un cliente de red robusto, ¡puede jugar voleibol! ¡pero puede reemplazar la tarea asíncrona normal de Android que usa Robospice para un mejor rendimiento y evitar pérdidas de memoria!
LOG_TAG
44
@frostymarvelous: Siento que indocumentado y sin soporte es una justificación más que suficiente. No es que Google carezca de un sistema para manejar más formalmente cosas como esta (por ejemplo, Biblioteca de soporte de Android). En los dos años transcurridos desde esta respuesta, en el lado positivo, hay una cierta cantidad de apoyo de la comunidad, incluido un paquete no oficial del código en un artefacto.
CommonsWare
44
@AbhinavVutukuri: Estás comentando una respuesta de hace más de dos años. En ese momento, no había documentación.
CommonsWare
361

Mirando la perspectiva de Volley aquí hay algunas ventajas para su requerimiento:

Volley, por un lado, está totalmente enfocado en manejar pequeñas solicitudes HTTP individuales. Entonces, si su manejo de solicitudes HTTP tiene algunas peculiaridades, Volley probablemente tiene un enganche para usted. Si, por otro lado, tiene una peculiaridad en el manejo de su imagen, el único gancho real que tiene es ImageCache . "¡No es nada, pero tampoco es mucho!". pero tiene más otras ventajas como Una vez que defina sus solicitudes, usarlas desde un fragmento o actividad es indoloro, a diferencia de AsyncTasks paralelas

Pros y contras de Volley:

Entonces, ¿qué tiene de bueno Volley?

  • La parte de redes no es solo para imágenes. Volley está destinado a ser una parte integral de su back-end. Para un proyecto nuevo basado en un servicio REST simple, esto podría ser una gran victoria.

  • NetworkImageView es más agresivo con respecto a la limpieza de solicitudes que Picasso, y más conservador en sus patrones de uso de GC. NetworkImageView se basa exclusivamente en fuertes referencias de memoria y limpia todos los datos de solicitud tan pronto como se realiza una nueva solicitud para un ImageView, o tan pronto como ImageView se mueve fuera de la pantalla.

  • Actuación. Esta publicación no evaluará esta afirmación, pero claramente se han cuidado de ser juiciosos en sus patrones de uso de memoria. Volley también hace un esfuerzo para realizar devoluciones de llamadas por lotes al hilo principal para reducir el cambio de contexto.

  • Al parecer, Volley también tiene futuros. Echa un vistazo a RequestFuture si estás interesado.

  • Si se trata de imágenes comprimidas de alta resolución, Volley es la única solución aquí que funciona bien.

  • Volley se puede usar con Okhttp (la nueva versión de Okhttp admite NIO para un mejor rendimiento)

  • Volley juega bien con el ciclo de vida de la Actividad.

Problemas con Volley:
dado que Volley es nuevo, todavía no se admiten algunas cosas, pero está solucionado.

  1. Solicitudes de varias partes (Solución: https://github.com/vinaysshenoy/enhanced-volley )

  2. el código de estado 201 se toma como un error, el código de estado de 200 a 207 son respuestas exitosas ahora. (Solucionado: https://github.com/Vinayrraj/CustomVolley )

    Actualización: en la última versión de Google Volley, el error de los códigos de estado 2XX está solucionado ahora ¡Gracias a Ficus Kirkpatrick!

  3. está menos documentado, pero muchas de las personas están apoyando la volea en github, aquí se puede encontrar documentación similar a Java . En el sitio web para desarrolladores de Android, puede encontrar una guía para la transmisión de datos de red con Volley . Y el código fuente de voley se puede encontrar en Google Git

  4. Para resolver / cambiar la Política de redireccionamiento de Volley Framework, use Volley con OkHTTP (CommonsWare mencionado anteriormente)

También puedes leer esta imagen que compara la carga de Volley con Picasso

Retrofit:

Es lanzado por Square , esto ofrece API REST muy fáciles de usar (Actualización: ¡Voila! Con soporte NIO)

Ventajas de la modificación:

  • En comparación con Volley, el código REST API de Retrofit es breve y proporciona una excelente documentación API y tiene un buen soporte en las comunidades. Es muy fácil agregar a los proyectos.

  • Podemos usarlo con cualquier biblioteca de serialización, con manejo de errores.

Actualización: - Hay muchos cambios muy buenos en Retrofit 2.0.0-beta2

  • la versión 1.6 de reequipamiento con OkHttp 2.0 depende ahora de Okio al apoyo java.io y java.nio que hace que sea mucho más fácil de acceder, almacenar y procesar los datos mediante ByteString y Buffer de hacer algunas cosas inteligentes para ahorrar la CPU y la memoria. (FYI: ¡Esto me recuerda a la biblioteca OIN de Koush con soporte NIO!) Podemos usar Retrofit junto con RxJava para combinar y encadenar llamadas REST usando rxObservables para evitar cadenas de devolución de llamada feas (¡para evitar el infierno de devolución de llamada!) .

Contras de Retrofit para la versión 1.6:

  • La funcionalidad de manejo de errores relacionada con la memoria no es buena (en versiones anteriores de Retrofit / OkHttp) no estoy seguro si se ha mejorado con el soporte de Okio con Java NIO.

  • La asistencia mínima de subprocesos puede resultar en un infierno de devolución de llamadas si lo usamos de manera incorrecta.

(Todos los inconvenientes anteriores se han resuelto en la nueva versión de Retrofit 2.0 beta)

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

Actualizar:

Pruebas de rendimiento de Android Async vs Volley vs Retrofit (milisegundos, menor valor es mejor):

Pruebas de rendimiento de Android Async vs Volley vs Retrofit

(Para su información anterior, la información de los puntos de referencia de actualización mejorará con la compatibilidad con Java NIO porque la nueva versión de OKhttp depende de la biblioteca NIO Okio)

En las tres pruebas con varias repeticiones (1 - 25 veces), Volley fue de 50% a 75% más rápido. La modernización registró un impresionante 50% a 90% más rápido que las AsyncTasks, alcanzando el mismo punto final la misma cantidad de veces. En el conjunto de pruebas del Tablero, esto se tradujo en cargar / analizar los datos varios segundos más rápido. Esa es una gran diferencia en el mundo real. Para que las pruebas sean justas, los tiempos para AsyncTasks / Volley incluyeron el análisis JSON como Retrofit lo hace por usted automáticamente.

RetroFit gana en la prueba de referencia!

Al final, decidimos utilizar Retrofit para nuestra aplicación. No solo es ridículamente rápido, sino que combina bastante bien con nuestra arquitectura existente. Pudimos crear una interfaz de devolución de llamada principal que realiza automáticamente el manejo de errores, el almacenamiento en caché y la paginación con poco o ningún esfuerzo para nuestras API. Para fusionarnos en Retrofit, tuvimos que cambiar el nombre de nuestras variables para que nuestros modelos fueran compatibles con GSON, escribir algunas interfaces simples, eliminar funciones de la API anterior y modificar nuestros fragmentos para no usar AsyncTasks. Ahora que tenemos algunos fragmentos completamente convertidos, es bastante indoloro. Hubo algunos dolores de crecimiento y problemas que tuvimos que superar, pero en general todo salió bien. Al principio, nos encontramos con algunos problemas técnicos / errores, pero Square tiene una fantástica comunidad de Google+ que pudo ayudarnos a superarlo.

¿Cuándo usar Volley?

¡Podemos usar Volley cuando necesitemos cargar imágenes, así como consumir API REST! ¡también Volley tiene mejor manejo de errores relacionados con la memoria que Retrofit!

OkHttp se puede usar con Volley, Retrofit usa OkHttp de forma predeterminada. Tiene soporte SPDY , agrupación de conexiones, almacenamiento en caché de disco, compresión transparente. Recientemente, obtuvo cierto soporte de Java NIO con la biblioteca Okio .

Fuente, crédito: volley-vs-retrofit por el Sr. Josh Ruesch

Nota: Acerca de la transmisión depende del tipo de transmisión que desee, como RTSP / RTCP.

LOG_TAG
fuente
@ Jan1337z +1 para la información! Lo he actualizado! android.googlesource.com/platform/frameworks/volley
LOG_TAG
44
@LOG_TAG sería interesante comparar RoboSpice en su muestra. Incluso ofrecemos un módulo Retrofit, así que creo que esto requeriría muy pocos cambios. ¿La fuente está disponible en alguna parte? La ventaja de RS es que maneja adecuadamente el ciclo de vida de la actividad que realiza las solicitudes de red, y también proporcionamos almacenamiento en caché transparente, supongo que la sobrecarga sería pequeña en comparación con una solicitud de actualización pura.
Snicolas
@Snicolas ¡Obtuve este resultado de referencia del blog Josh Ruesch , puedes ver las conversiones entre Ficus Kirkpatrick (fundador de Volley), Josh Ruesch! ¡Todavía no ha compartido el proyecto de prueba de referencia en ningún lado! FYI: Acabo de comenzar a aprender su RoboSpice con una muestra de modificación que enfrenta este problema de notificación :)
LOG_TAG
3
¡Hola! Acerca de las solicitudes multiparte con Volley, creo que podemos usarlo MultipartEntityBuilderen la httpmimebiblioteca.
BNK
2
¿Alguien más ha verificado estos puntos de referencia? Como la biblioteca http apache está en desuso en M (y la estaba usando para el generador de partes múltiples), decidí migrar mi código de red a Retrofit. Inicialmente cambié una de las llamadas GET para obtener un montón de objetos del servidor. Tomé el tiempo de Retrofit vs AsyncTask (con mi propio análisis JSON). El rendimiento fue muy cercano, no una mejora 3 veces mayor como se muestra en la columna "Una discusión" de la tabla. Por supuesto, el código resultante es mucho más limpio y no tuve que escribir mi propio analizador JSON, pero para una sola solicitud GET la mejora no estaba allí.
Gary Kipnis
44

RoboSpice vs. Voleo

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

  • RoboSpice (RS) está basado en el servicio y es más respetuoso de la filosofía de Android que Volley. Volley está basado en subprocesos y esta no es la forma en que el procesamiento en segundo plano debería tener lugar en Android. En última instancia, puede desenterrar ambas bibliotecas y descubrir que son bastante similares, pero nuestra forma de procesar en segundo plano está más orientada a Android, nos permite, por ejemplo, decirles a los usuarios que RS está haciendo algo en segundo plano, lo que sería difícil para volea (en realidad no lo hace en absoluto).
  • RoboSpice y volley ofrecen buenas características como priorización, políticas de reintento, solicitud de cancelación. Pero RS ofrece más: un almacenamiento en caché más avanzado y que es grande, con gestión de caché, agregación de solicitudes, más características como volver a conectar a una solicitud pendiente, lidiar con la caducidad de la caché sin depender de los encabezados del servidor, etc.
  • RoboSpice hace más cosas fuera de UI Thread: volley deserializará tus POJOs en el hilo principal, lo cual es horrible para mí. Con RS su aplicación será más receptiva.
  • En términos de velocidad, definitivamente necesitamos métricas. RS se ha vuelto súper rápido ahora, pero aún no tenemos figura para poner aquí. En teoría, el voley debería ser un poco más rápido, pero RS ahora es masivamente paralelo ... ¿quién sabe?
  • RoboSpice ofrece un amplio rango de compatibilidad con extensiones. Puede usarlo con okhttp, retrofit, ormlite (beta), jackson, jackson2, gson, xml serializer, google http client, spring android ... Bastante. Volley se puede usar con ok http y usa gson. Eso es.
  • Volley ofrece más azúcar UI que RS. Volley proporciona NetworkImageView, RS proporciona un adaptador de lista de spicel. En términos de características no está tan lejos, pero creo que Volley está más avanzado en este tema.
  • Se han resuelto más de 200 errores en RoboSpice desde su lanzamiento inicial. Es bastante robusto y se usa mucho en la producción. Volley es menos maduro, pero su base de usuarios debería estar creciendo rápidamente (efecto Google).
  • RoboSpice está disponible en maven central. Volley es difícil de encontrar;)
Snicolas
fuente
Robospice usa servicios de Android para llamadas REST, podemos usar Robospice con Retrofit para minimizar los esfuerzos de análisis de gson, de la misma manera que podemos usar Volley (basado en la banda de rodadura) con Robospice? (no estoy seguro de que sea la pregunta correcta) ¡Solo estoy buscando volea con servicio!
LOG_TAG
1
Volley con servicio es básicamente RS. O, cronológicamente hablando, Volley es RS sin servicio y faltan algunas otras características. Y sí, puede usar Retrofit con RS e incluso agregar okhttp si lo desea.
Snicolas
77
¿Por qué es difícil encontrar volley? compile 'com.mcxiaoke.volley:library:1.0.+'
Rob
1
@Rob hubo un momento en que el clon de mcxiaoke no estaba disponible. Debes incluir manualmente volley en tu aplicación.
frostymarvelous
"volley deserializará tus POJO en el hilo principal". Puede recibir los datos JSON devueltos y deserializarlos usted mismo en un hilo separado si esto es un problema.
AndroidDev
20

AFNetworking para Android:

Rápida red de Android está aquí

Fast Android Networking Library admite todos los tipos de solicitud HTTP / HTTPS como GET, POST, DELETE, HEAD, PUT, PATCH

Fast Android Networking Library admite la descarga de cualquier tipo de archivo

Fast Android Networking Library admite la carga de cualquier tipo de archivo (admite carga multiparte)

Fast Android Networking Library admite la cancelación de una solicitud

Fast Android Networking Library admite la configuración de prioridad para cualquier solicitud (BAJA, MEDIA, ALTA, INMEDIATA)

Fast Android Networking Library es compatible con RxJava

Como utiliza OkHttp como capa de red, admite:

Fast Android Networking Library admite HTTP / 2, permite que todas las solicitudes al mismo host compartan un socket

Fast Android Networking Library utiliza una agrupación de conexiones que reduce la latencia de la solicitud (si HTTP / 2 no está disponible)

GZIP transparente reduce los tamaños de descarga

Fast Android Networking Library admite el almacenamiento en caché de respuestas que evita la red por completo para las solicitudes repetidas

Gracias: la biblioteca fue creada por mí.

Amit Shekhar
fuente
1
Usted declara que su biblioteca admite HTTP / 2, pero no dice si existe un requisito de API para el soporte HTTP / 2. Comprendí que el nivel de API de Android inferior a 5.0 no tenía los métodos de cifrado SSL adecuados para admitir HTTP / 2. No toca, solo intenta evaluar completamente la solución propuesta.
DoctorD
@AmitShekhar: Solo quería saber cuál es el mejor para las llamadas API en Android. Estoy usando la Biblioteca de redes de Android, ¿qué es genial para implementar Retrofit, Volley o Android Networking?
Parth Bhayani
@Amit Shekhar ¿Qué tan eficiente es Fast Android Networking para la carga de imágenes de varias partes, especialmente cuando se trata de escenarios de bajo nivel de Internet?
user3135923
18

Cliente HTTP asíncrono loopj vs.Volley

Los detalles de mi proyecto son pequeñas solicitudes HTTP REST, cada 1-5 minutos.

Utilicé un cliente HTTP asíncrono (1.4.1) durante mucho tiempo. El rendimiento es mejor que usar el httpClient Apache de vainilla o una conexión URL HTTP. De todos modos, la nueva versión de la biblioteca no funciona para mí: la biblioteca inter excepción cortó la cadena de devoluciones de llamada.

Leer todas las respuestas me motivó a probar algo nuevo. Elegí la biblioteca Volley HTTP.

Después de usarlo durante un tiempo, incluso sin pruebas, veo claramente que el tiempo de respuesta se ha reducido a 1.5x, 2x Volley.

¿Quizás Retrofit es mejor que un cliente HTTP asíncrono? Necesito probarlo. Pero estoy seguro de que Volley no es para mí.

Sergey Vakulenko
fuente
¿Algún análisis sobre Retrofit Vs AsyncHttpClient ??? Por favor, publique si sí @Sergey
IshRoid
Estoy usando AsyncHttpClient durante unos años. Lo malo es que el repositorio de github es de 2 años sin compromiso.
Vitor Hugo Schwaab
Ya no es real, el http asincrónico es demasiado antiguo. Considere cambiar a otra biblioteca. Volley también se convirtió en una muy buena elección.
Sergey Vakulenko
Sergey, @IshRoid Todavía estoy buscando respuesta a tu pregunta. Estoy usando AsyncHttpClient. ¿Debería usar algo más como RxJava Retrofit o cualquier otra cosa? Por favor, házmelo saber ... Esperando ansiosamente la respuesta
Deep Dave
11

Solo para agregar un poco a la discusión de mi experiencia trabajando con Volley:

  1. Volley no maneja las cargas o descargas de transmisión en ningún sentido. Es decir, todo el cuerpo de la solicitud debe estar en la memoria y no puede usar un OutputStreampara escribir el cuerpo de la solicitud en el socket subyacente, ni puede usar un InputStreampara leer el cuerpo de la respuesta, como lo HttpURLConnectionhace básico . Entonces, Volley es una mala elección para cargar o descargar archivos grandes. Sus solicitudes y respuestas deben ser pequeñas. Esta es una de las mayores limitaciones de Volley que he encontrado personalmente. Por lo que vale, OkHttp tiene interfaces para trabajar con transmisiones.

  2. La falta de documentación oficial es molesta, aunque he podido solucionarlo leyendo el código fuente, que es bastante fácil de seguir. Lo que es más molesto es que, por lo que puedo decir, Volley no tiene versiones de lanzamiento oficiales ni artefactos de Maven o Gradle, y por lo tanto, manejarlo como una dependencia se vuelve más dolor de cabeza que, por ejemplo, cualquiera de las bibliotecas que Square ha lanzado . Simplemente clonas un repositorio, construyes un frasco y estás solo. Buscando una corrección de errores? Busca y espera que esté allí. También puede obtener otras cosas; No será documentado. En mi opinión, esto significa efectivamente que Volley es una biblioteca de terceros no compatible, aunque la base de código esté razonablemente activa. Advertencia emptor.

  3. Como nit, tener el Tipo de contenido vinculado al tipo de clase / solicitud (JsonObjectRequest, ImageRequest, etc.) es algo incómodo y reduce un poco la flexibilidad del código de llamada, ya que está vinculado a la jerarquía de tipos de Solicitud existente de Volley. Me gusta la sencillez de configurar Content-Type como un encabezado como cualquier otro (por cierto, no hagas esto con Volley; ¡terminarás con dos encabezados Content-Type!). Sin embargo, esa es solo mi opinión personal, y se puede solucionar.

Eso no quiere decir que Volley no tenga algunas características útiles. Ciertamente lo hace. Políticas de reintento fácilmente personalizables, almacenamiento en caché transparente, una API de cancelación y soporte para la programación de solicitudes y conexiones concurrentes son excelentes características. Solo sepa que no está destinado a todos los casos de uso de HTTP (consulte el elemento 1 anterior), y que hay algunos dolores de cabeza involucrados en poner Volley en uso de producción en su aplicación (elemento 2).

Jeff
fuente
La carga de memoria completa es lo que lentamente me está matando. Gracias a Dios que alguien más lo mencionó.
TheSunny
La biblioteca también puede hacer una copia defensiva de su cuerpo de solicitud, por lo que el consumo de memoria para solicitudes grandes podría ser el doble de lo que podría esperar.
Jeff
9

Recientemente encontré una lib llamada ion que aporta un poco más a la mesa.

ion tiene soporte incorporado para descarga de imágenes integrado con ImageView, JSON (con la ayuda de GSON), archivos y un soporte muy práctico para subprocesos de UI.

Lo estoy usando en un nuevo proyecto y hasta ahora los resultados han sido buenos. Su uso es mucho más simple que Volley o Retrofit.

Tiago Gaspar
fuente
2
ion vs retrofit, ¿cuál recomendarías?
Sreekanth Karumanaghat
Reequipamiento es mejor que la de iones
Rajesh Koshti
4

Agregando a la respuesta aceptada y lo que LOG_TAG dijo ... para que Volley analice sus datos en un subproceso en segundo plano, debe subclasificar Request<YourClassName>como onResponsese llama al método en el subproceso principal y el análisis en el subproceso principal puede hacer que la interfaz de usuario se retrase si su respuesta es grande. Lea aquí sobre cómo hacer eso.

Upenpat
fuente
1
bien ... volley analiza la respuesta en el hilo principal que hace que se retrase cuando la respuesta es realmente grande.
Gopal Singh Sirvi
3

Retrofit 1.9.0 vs. RoboSpice

Estoy usando ambos en mi aplicación.

Robospice funciona más rápido que Retrofit cada vez que analizo la clase JSON anidada. Porque Spice Manger hará todo por ti. En Retrofit necesitas crear GsonConverter y deserializarlo.

Creé dos fragmentos en la misma actividad y llamé al mismo tiempo con dos tipos de 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
Asma
fuente
2

Y otra opción más: https://github.com/apptik/jus

  • Es modular como Volley, pero más extendido y la documentación está mejorando, soportando diferentes pilas y convertidores HTTP listos para usar.
  • Tiene un módulo para generar asignaciones de interfaz API del servidor como Retrofit
  • También tiene soporte JavaRx

Y muchas otras funciones útiles como marcadores, transformadores, etc.

Kalin
fuente