Posts Tagged ‘windowsphone’


Este post lo hago de urgencia pues acabo de experimentar todo lo que no se debe hacer en el tema de sincronización. Para esto les doy un resumen de mi entorno de desarrollo:

  • Servidor: Instancia en Cloudant.com
  • Cliente: PouchDB como base de datos con sincronización al iniciar el app
  • Framework: Ionic

En resumen, se inicia una sincronización entre mi base de datos local en PouchDB y la base remota en Cloudant. Y puede ser todo lindo en Producción, pero como estamos en Desarrollo, el proceso normal es parar e iniciar el app a cada rato. Ahora veamos las consecuencias en desarrollo:

  • Costo: Cloudant te cobra por transacciones y te dice que por transacciones “pesadas” te va a cobrar mas, y pone varias transacciones HTTP y las define como pesadas. Lo que no dice es que hay otras transacciones que se utilizan para la sincronización que también se califican como pesadas, principalmente OPTIONS que se manda a cada rato. Por lo tanto, cada sincronización es bastante intensiva en costo.
  • Tráfico: Para un modelo de desarrollo, no es bueno iniciar conexiones de datos muy seguido. Entonces, el modelo debe saber cuando es bueno iniciar la sincronización sin importar que sea en Desarrollo o Producción.
  • Batería: Como consecuencia de la reducción de tráfico, estaremos también bajando el consumo de energía en el móvil.

No malentiendan, CouchDB/PouchDB es muy bueno, y si existe la necesidad, podemos activar la sincronización “live”, pero como no todos tenemos servidores y ancho de banda de sobra, tenemos que pensar en servicios en demanda en la red, como Cloudant en mi caso. Tengan en cuenta que otros servicios como IrisCouch, también cobran por transacciones.

La salida que encontré depende de como se necesita que fluyan los datos:

  • El recolector de datos: si nuestra app necesita solamente capturar datos y no necesito bajar información desde el servidor. En este caso, lo mejor es implementar un contador que incrementaremos cada vez que se actualice o se inserte un dato nuevo. Lo bueno es que para un entorno NoSQL, insertar o actualizar es el mismo método, así que en ese método podremos insertar el incremento del contador. Luego, al momento antes de sincronizar, verificaremos si es que el contador es mayor a 0, de lo contrario no iniciaremos la sincronización. Sincronizar solamente cuando hayan datos locales.
  • El visualizador de datos: Aquí es totalmente al revés, el app jala información del servidor. En este caso, la primera alternativa es la de fijar un tiempo de sincronización relativamente alto, agregar un visor de la última fecha de sincronización y la opción para forzar la sincronización manualmente.
  • Finalmente, como siempre, en la vida real tendremos una combinación de necesidades, así que la recomendación final es la de utilizar un proceso de sincronizacion para descargar datos y otro para subir datos.

Hay una función que no he mencionado aún: Sincronización filtrada. Esto es super útil y lo voy a desarrollar en otro Post, Básicamente es la de descargar solamente la información que me interesa. Esto es tan importante que todos deben usarlo si es que tenemos que descargar datos.

En conclusión, es muy fácil sincronizar sin límites, pero en la vida real, no hay que pedir más de lo que debemos consumir.





%d bloggers like this: