Voleibol o servicio con cargador de cursor

Arco Tradicional

Personalmente, en el pasado he encontrado usando un servicio para ser engorroso para implementar, pero al final del día estaba bien estructurado y era una buena experiencia consistente. Pero el rendimiento de subprocesos … difícil de manejar.

Consulta de servicio -> carga de base de datos -> notificar

UI iniciar la consulta y la carga del cursor -> update ui.

Sólo Volley

Con volley es tentador omitir el componente entero que fue manejado previamente dentro de un servicio y una base de datos.

UI Volley solicitud -> Volley respuesta -> actualización ui

Sin embargo, esto se desmorona muy rápidamente dependiendo de los datos que usted está intentando exhibir y quizás incluso del servidor usted está consultando contra para cualquiera de los requisitos siguientes

• Los datos que se muestran no se describen completamente por la misma URL (por ejemplo, páginas)

El usuario puede desplazarse hacia abajo y extraer más páginas. Sin embargo, cuando el usuario vuelve a la actividad o simplemente gira, la llamada a Volley devolverá un resultado sólo para la página inicial a menos que recuerde específicamente todas las otras consultas que contiene la página. Esto se convierte en un montón de trabajo para una arquitectura que está destinado a ser más conveniente. O incluso una página que es ligeramente diferente, esto puede ser una experiencia inconsistente para el usuario si lo único que hicieron fue rotar el teléfono.

• Los datos deben ser modificados

Es más fácil aplicar el cambio localmente y luego aplicarlo al servidor siempre. Con volley sólo, tendría que hacer una actualización REST y requery (de todas las consultas anteriores) de forma sincrónica.

• Velocidad y persistencia

Volley es muy rápido. Sin embargo, carece de cualquier persistencia aparte de los éxitos de caché donde está disponible, que puede depender del servidor que está consultando. El almacenamiento en caché agresivo puede causar estragos en su aplicación con datos obsoletos. La extracción de una base de datos local proporciona una experiencia constante y rápida al navegar por varias actividades que en realidad podrían referenciar datos en consultas anteriores. Una experiencia de volea pura puede requerir que consulte los datos que técnicamente ya tiene de consultas anteriores, pero no tiene un almacén de datos central para obtener esos datos.

Voleibol híbrido y cursores

En estos días en realidad saltar la parte de servicio, pero todo lo demás se mantiene desde el arco tradicional

UI inicia la consulta de volley y la carga del cursor -> update ui

Volley consulta -> actualización de la base de datos -> notificar

Además, no hay nada que lo detenga de tener el ping ui un servicio y, a continuación, el servicio utiliza volea … Se verá más tradicional que podría ser el valor mover más lógica de control a un lugar más centralizado, pero el hecho de que se ejecuta desde dentro de un "Servicio" en realidad no ofrece ninguna ventaja técnica.

Resumen

Espero que eso ayude. Básicamente, no intente volar sólo, lo intenté y sería una aplicación muy específica y sencilla si eso es lo que funcionó para usted y espero que he identificado las dificultades principales.

Además, encontré las mismas trampas con robospice a pesar de estar en un servicio … Pero … YMMV

Volley es sólo una capa de ayuda para comunicarse con el servidor que gestiona los hilos y otras cosas. Sí, ya implementa el almacenamiento en caché de threading agradable y otras cosas. Pero no tienes que usarlo en tus actividades. Incluso diría que no deberías. Todos sabemos que el servicio es de hecho el lugar para hacer cualquier trabajo de red de fondo. Está diseñado para sobrevivir a los cambios de configuración y es una manera natural para su aplicación de declarar que funciona en segundo plano y debe ser tomado con especial cuidado por el sistema.

Imagínate, no había Volley. ¿Qué harías? Apuesto a que sería imlement su soporte de subprocesos en un servicio, a la derecha (todos sabemos Servicios de trabajo en el hilo principal)? Puede ser tan simple como un IntentService, que es un único subproceso de trabajo estático y un controlador para él. O puede ir de fantasía y utilizar ExecutorService para tener un grupo de hilos. O puede volverse loco e iniciar un new Thread() cada vez en onStartCommand() . Lo que se adapte a sus necesidades y gustos.

Así que prefiero mirar Volley como sólo otra manera de lograr estas tareas. Esta vez usted no necesita hacer ningún trabajo con hilos usted mismo, sólo tiene Volley hacerlo por usted.

Así que la línea de fondo es el uso de volea y servicio juntos.

Encontré el mismo problema, y ​​no me gustaba tener procesos separados para solicitud local y de red. He ampliado la biblioteca Volley para incluir el proceso de tener una solicitud de base de datos local (para contenido sin conexión) y una solicitud de red.

Básicamente tengo un CompleteRequest que volverá:

• Una respuesta intermedia, que puede ser de caché http o de base de datos local (ejecutar en paralelo, el más rápido que termina devolver un resultado, el segundo es ignorado)
• Una respuesta final, que será de la red (o un error)

La solicitud se ve así:

 public class SampleRequest extends CompleteRequest<Object> { public SampleRequest(int method, String url, ResponseListener<Object> responseListener, Response.ErrorListener errorListener) { super(method, url, responseListener, errorListener); } @Override protected Object getLocalResponse() { // query your local database for example // return the result or null if there is no result from database return new Object(); } @Override public void saveNetworkResponseToLocal(Object response) { // save the network response to the local database // next time the request is performed the local response will return the result faster than the network request } @Override protected BallResponse<Object> parseBallNetworkResponse(NetworkResponse response) { // parse the result from the network request, in the same way than with volley return Response.success(new Object()); } } 

Y usted realiza la petición como esa, con el oyente de la respuesta que incluye el intermedio y la respuesta final:

 mRequestQue.add(new SampleRequest(Request.Method.GET, "http://some.url", new ResponseListener<Object>() { @Override public void onIntermediateResponse(Object response, BallResponse.ResponseSource responseSource) { // intermediate response, such as from local database or soft cached network response } @Override public void onFinalResponse(Object response, BallResponse.ResponseSource responseSource) { // final response, which is the network response } @Override public void onFinalResponseIdenticalToIntermediate(BallResponse.ResponseSource responseSource) { // final response is identical to intermediate one // happens when intermediate is from soft cache and network response is identical (not modified) } }, new Response.ErrorListener() { @Override public void onErrorResponse(VolleyError error) { // network response is an error, in the same way than with volley } } )); 

Todavía está en una fase temprana de desarrollo, pero lo estoy usando en varias aplicaciones y funciona bien. Escribí un readme rápido con ejemplos y hay proyecto de ejemplo que puede ayudar.

Puedes consultarlo en https://github.com/lukaspili/Volley-Ball

Siempre use volley para descargar cosas. Si además necesita mantener datos en db, todavía puede usarlo. Basta con repensar su arquitectura. Volley es una herramienta de red, nada más que eso.

Oh y volley no utiliza AsyncTasks.

Volley está destinado a proporcionar una forma más conveniente para asincrónicamente realizar las solicitudes de red. No requiere que subclases un Service o un AsyncTask , y su sintaxis es muy sencillo para cualquier desarrollador experimentado.

Como se ha indicado anteriormente, esto es totalmente una conveniencia . Si usted tiene un mecanismo que funciona bien, entonces por todos los medios lo utilizan. Si usted se encuentra reescribiendo el código constantemente que sigue su modelo existente, usted puede desear mirar en una biblioteca reutilizable, tal como Volley o droidQuery .

No hay respuesta correcta o incorrecta. Sin embargo, puede haber un factor mejor o peor . La principal comparación aquí es la velocidad. Volley cuenta con velocidades rápidas, y planes para apoyar OKHTTP pronto, así como para convertirse en parte del SDK de Android (o un paquete de compatibilidad), continuando creciendo con la plataforma Android. Si estas cosas son importantes para usted, entonces tal vez debería cambiar para aplicaciones futuras (a menos que tenga un retraso notable en las aplicaciones actuales, tendría dificultades para ver un punto para cambiar el código de trabajo).