Definiendo la Comunicación Pasiva entre el Servidor y la App

En los últimos días, y lo que todavía me queda, he estado y estoy trabajando en la comunicación de la BBDD del Cliente (La App Android) y la BBDD del Servidor (BackEnd Node.js). Me refiero a la comunicación pasiva, la que el usuario no debería darse cuenta.

Por un lado me refiero a comunicación activa, la que está en primer plano y el usuario se puede dar cuenta que está ocurriendo. Por ejemplo, cuando crea una Qdada y la guarda. En ese momento se abre un Progress Dialog y hasta que esa comunicación entre el SmartPhone y el Servidor no termine (para bien o para mal debido a los timeOuts que he configurado) el usuario no podrá seguir usando la app. Estas comunicaciones en primer plano, suelen durar muy poco, casi tan poco que al usuario no le da tiempo de ver el Progress Dialog que aparece. Pero por si en un determinado momento algún fallo ocurre en la comunciación, pues lo he configurado para que aparezca estos Progress Dialog no cancelables, como dije antes. Esta labor ya la realice, y así la expliqué en Post pasados del blog.

Este tipo de comunicaciones, que se hagan ad-hoc en primer plano, también se pueden trasladar a la demás información. Por ejemplo, para cargar la información de los Fragments de la Activity del Home (que como recordareis son los que muestran las listas de las Qdadas en las que estamos involucrados), se podría también tirar de comunicaciones en primer plano. Me refiero en primer plano para representar el hecho de que hasta que no se han terminado las comunicaciones, no se recoge ninguna información para mostrar en los fragments. Esto no quiere decir que las llamadas a los web services se hagan en hilos independientes, que de hecho se hacen así para no sobrecargar y saturar el hilo principal. Pues bien, se podría configurar todo para que hasta que no llegue la información almacenada, y totalmente actualizada, del servidor, no se mostrara nada en la app (en lo referente a la información de las Qdadas). Esta es una práctica también habitual, y con la que suelen trabajar la mayorías de aplicaciones. En local poseen muy poca información, y se basa casi siempre en tener la BBDD del servidor que es la que nutre a las aplicaciones clientes mediante llamadas o servicios propios.

Pues bien, en esta app lo que quise hacer es implementar un protocolo distinto al que estaba habituado a usar, y a ver. La idea es que la información que se almacene en el servidor, esté replicada en local (con la salvedad que en el servidor estará toda, y en local sólo lo referente a el usuario de ese smartphone). De esta manera, si se quiere usar la app cuando no hay conexión o lo que sea, sea posible visualizar las Qdadas (aunque estas igual no estas actualizadas al 100%). Así que el protocolo me gustó bastante y lo decidí implementar en la app. Es algo más complejo que esto, que iré evolucionando con el paso del tiempo, pero para que os hagais una idea clara, básicamente es esto, lo que de momento quiero hacer. Esta idea me surgió tras hablar con el encargado de desarrollo de una empresa Tinerfeña (no diré el producto ni el nombre de la compañia por temas de privacidad) que me comentaba como habían elaborado el diseño interno de su última app (para móviles) que tanta repercusión ha tenido en los últimos meses en Tenerife. Era un paradigma que yo había pensado, porque la idea es la ideal de hacer para toda app, pero que siempre tenía algún inconveniente que desechaba su implantación. Pues bien, tras preguntarle sobre ese paradigma, y tras responderme siempre con buenas propuestas, me decidí a realizarlo.

La idea es que exista un hilo que cada cierto tiempo (configurable, ahora le he puesto 5 minutos, habría que analizar y estudiar este tiempo) se comunicara con el servidor para actualizar toda la información de la BBDD Local de la app Android. Por otro lado, todo lo que el usuario hiciera en la app, tiraría de la BBDD Local, por lo que la fluidez de la misma siempre sería la mejor posible. Y así es como lo he implementado, y estoy implantándolo. Esto hace que toda la parte del front-end de la app, tire directamente de la BBDD de MySQL de Android, y que las actualizaciones de esta BBDD se haga totalmente de forma pasiva para el usuario, que no se enterará. Esto tiene sus pros y contras. Por ejemplo, evita diversos problemas que el usuario se de cuenta cuando no hay conexión. En cambio no siempre tiene la info 100% actualizada, pero el tiempo de refresco creo que es adecuado para que ‘los pros’ pesen más que ‘los contras’.

Modelo de Sincronización entre BBDD Local y BBDD Servidor de manera transparente a la App. (Imagen cogida de un producto de IBM)

Y hasta aquí en esta entrada, a ver si termino pronto esto de la comunicación pasiva, y ya sólo quedaría el tema de enviar las Qdadas mediante las notificaciones push (que ya configuré), recibirlas en Android y mostrarselas al usuario en la app. Y probar que todo, absolutamente todo, funcione como debería, jeje.

Y como siempre os dejo con el commit de esto que comento: COMMIT.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s