Sincronizando Android con la Nube

Viendo la presentación Developing Android REST client applications se habla dos errores muy grandes que todo principiante comete al implementar servicios web con Android:

• ejecutar el servicio web en el hilo principal
• alojar los recursos obtenidos en la memoria en lugar de en almacenamiento permanente

La parte negativa del primer punto es que las transferencias de datos pueden llevar bastante tiempo derivando en una UI lenta y en ocasiones que esta deje de responder. Por otro lado el no persistir los datos se pude pensar que hará nuestra aplicación mas rápida. Pero ¿que pasa si el S.O. decide expulsar de memoria a nuestra aplicación para darle lugar a otra? Que tendremos que volver a pedir los datos al servidor conllevando mas gasto de CPU por lo tanto de batería y el esperar tiempo necesario para volver a transferir el recurso.

En la charla se proponen tres patrones de diseño diferentes:

• Service
• Content Provider
• Content Provider y SyncAdapter

Cada uno de las diseños se pueden ver las transparencias de la charla.

En este caso veamos como se implementa el ultimo de ellos. En los dos primeros patrones tenemos que encargarnos manualmente del estado de los recursos y de las transacciones, pero en el ultimo caso todo esto se hace automáticamente a través de SyncAdapter. SyncAdapter sera el encargado de gestionar el estado de los recursos y actualizarlos cuando sea conveniente, este es el patrón usado por Gmal, Facebook, LastFM, por citar algunos.

Imagen tomada de las transparencias de la presentación.

Como vemos la estructura se divide en cinco partes. La capa mas alta se encarga de mostrar los datos al usuario. La actividad es una actividad común y corriente, que interactúa con el usuario guardando pidiéndole o mostrando los datos que nos interesen. El CursorAdaptar es quien refresca los datos que están en el ContentProvider con la interfaz, mostrando siempre los datos mas recientes. Los datos son almacenados en un ContentProvider, si no quieren usar un content provider para guardar los datos deberán engañar al sistema, creando uno que no haga nada, en StackOverflow se explica mas o menos como hacerlo.

ContentProvider

Como crear un ContentProvider ya se explico en un post anterior así que como es de suponer no se volverá a explicar. Es más, dicho post fue pensado para usarlo como base para este.

Account Authenticator
Para poder sincronizar nuestra aplicación con un servidor primero debemos agregar una cuenta al sistema.  Para ello que mejor que echarle un vistazo a los ejemplos de Google, en concreto a este. El ejemplo también se puede encontrar dentro del SDK que tenemos instalado, pero no es exactamente igual a la versión online, traten de usar la versión online que es la mas actual.

Dentro del paquete authenticator se implementa la gestión de cuentas haciendo uso de tres clases:

• Authenticator: implementa la gestión de la cuenta.
• AuthenticationService: define un servicio que instancia a Authenticator para realizar las tareas en el background.
• AuthenticatorActivity: la actividad mostrada para pedir las claves al usuario.

Para tener todo la gestión de cuentas haremos uso del viejo y querido copy & paste, en un mundo ideal funcionaria sin ninguna modificación pero es demasiado bueno para ser verdad asi que hay que hacer algunas modificaciones. En el ejemplo usa otra dos clases, Constants y NetworkUtilities. Si quieren también las pueden copiar, sino:

• definir las dos constantes definidas en Constants en la clase Authenticator
• reemplazar Networkutilities por la clase donde este implementado el acceso al servidor, el método authenticate es el que nos interesa, ya que es con el que se validan las credenciales del usuario.

Si usaron AuthenticatorActivity en lugar de una actividad propia, hay que copiar el fichero xml/authenticator.xml, el contenido de values/strings.xml, y añadir al Manifest la definición del servicio y de la actividad.
La variable android:name indica la ruta de la clase AuthenticatorService.


Con eso si instalamos nuestra aplicación al ir a Settings > Accounts and sync > Add account saldrá nuestro el tipo de cuenta que acabamos de definir.

Tengan muchísimo cuidado al declarar el servicio ya que al estar trabajando con XML es muy fácil meter la pata, en mi caso cuando se creaba la cuenta se iniciaba la sesión sin problema pero mas tarde al volver a intentarlo no se iniciaba la sesión porque no estaba guardando el password de usuario. Todo eso por tener mal los ficheros XML.


SyncAdapter
Con lo anterior ya esta la gestión de la cuenta ahora viene lo que realmente nos interesa como sincronizar nuestro teléfono con un servidor. Nuevamente tendremos que crear un servicio para que se ejecute ocultamente sin molestar a nadie. Para eso se precisan dos clases SyncAdapter y SyncService.

SyncAdapter define las acciones a realizar cuando se lleva a cabo la sincronizacion, en este caso llama al metodo syncLog de la clase VideoLogger.

syncLog implementa lo que realmente se hace al sincronizar, esto puede ir dentro de syncAdapter, pero pero claridad y facilidad de mantenimiento decididí gestionarlo aparte. Como veran primero obtiene todos los objetos PendingMovie que hay almacenados y luego va iterando sobre ellos y subiendolos al servidor, en este caso en concreto el metodo upload, borrara el objeto del ContentProvider una vez recibido el ACK del servidor.


Y SyncService instancia a SyncAdapter comom un singleton y lo vincula al servicio.

Finalmente hay que crear un XML con la definición del syncadapter y definir el servicio en el Manifest.


res/xml/syncadapter.xml

Y eso es todo.