Cómo gestionar la falta de conectividad en aplicaciones Ionic

Es un hecho que casi todas las aplicaciones de hoy día necesitan conexión a internet pero, ¿cuántas de todas ellas están preparadas para soportar un modo offline o una pérdida –puntual o prolongada- de conectividad? ¿Cuántas de ellas nos van a permitir seguir interactuando sin mostrar un mensaje de alerta, de error o de “inténtalo más tarde”?

En este post os daremos a conocer qué es el concepto de Offline First, o cómo poder gestionar esa ausencia de conectividad y que no suponga una pérdida de experiencia de usuario.

La conectividad, en un mundo globalizado, ¿todavía es un problema?

Incluso en las ciudades más desarrolladas del mundo, existen lugares (comunes) donde podremos encontrarnos sin conectividad, como las redes de transporte público. Es cierto que estas limitaciones van desapareciendo poco a poco, pero existen otras áreas menos desarrolladas (como las zonas rurales) que se ven afectadas aún por la falta de cobertura.

Esta distinción, acusada también por aspectos geográficos, se ha hecho tan evidente que ha llegado a acuñarse un concepto exclusivo para designarla: la brecha digital. Aunque engloba a otros términos relacionados (como dispositivos, tipos de accesos y conexión, etc.), nos centraremos en una de las más básicas: la falta de cobertura o conectividad a la red de redes.

Antes de entrar en más detalles, el lector quizás se pregunte en qué situaciones se nos presenta la pérdida de conectividad:

• Para cualquiera, en el día a día, al desplazarnos por la ciudad en metro, y queremos ir leyendo las noticias, los últimos tweets, escribiendo por WhatsApp…
• Para un comercial, cuando visita zonas rurales haciendo nuevos clientes, ofreciendo nuevos productos, etc.
• Para un operario de grúa de una compañía de seguros, para rellenar los datos del parte de asistencia o accidente.

El stack tecnológico

La experiencia que os contamos en este artículo se trata de escenarios offline centrados en aplicaciones móviles desarrolladas con el framework Ionic a partir de su versión 2. Por otro lado, el backend pasa a un segundo plano, pues lo único necesario es que el lado servidor exponga un API REST para gestionar las operaciones típicas de CRUD (create – read – update – delete) a través de las cuales poder persistir la información enviada por la aplicación móvil.

Nuestro gran aliado: PouchDB

Para los que no conozcáis PouchDB, se trata de una base de datos, agnóstica de cualquier framework y open-source, que es capaz de ejecutarse en el navegador, permitiendo así almacenar información tanto con conexión como sin ella.

En la parte que nos atañe, el browser (también corre sobre Electron, NW.js ó Chrome apps entre otros), cuenta con una variedad de adaptadores de bases de datos soportadas por los navegadores. Es decir, PouchDB, en sí mismo, no es una base de datos per se, sino que actúa como capa de abstracción para IndexedDB y WebSQL entre otros.

Independientemente del adaptador escogido, lo que PouchDB nos ofrecerá será métodos para poder guardar objetos, modificarlos, recuperarlos y eliminarlos, de manera que ese cambio, aunque cerremos la aplicación, seguirá ahí. Dicho de otro modo, este será nuestro almacén de datos principal, incluso cuando estemos con conectividad, de modo que el flujo de nuestros datos será similar al siguiente diagrama:

Es decir, debemos dejar de pensar en interactuar con el backend sólo cuando haya conectividad, porque estaremos incurriendo en un error que se opone al concepto de offline first. Una de estas premisas es que la falta o no de conectividad no se debe entender como una situación de error, sino como una característica de nuestra aplicación. ¿Tengo conectividad? Sincronizo. ¿No existe conexión? Almaceno localmente y en cuanto tenga, sincronizo.

Esta idea, vale su peso en oro, ya que es la piedra angular del resto de beneficios que nos puede aportar a nuestras aplicaciones, y en definitiva, a los usuarios de las mismas. Del mismo modo que hizo mobile first en cuanto a diseño para adaptar el contenido en primer lugar a dispositivos móviles, offline first trata de buscar esa mejora progresiva pero utilizando la conectividad cuando esté disponible; mientras tanto, la aplicación funcionará del mismo modo, pues como hemos comentado, no consideraremos nunca como situación anómala el que no exista conexión. La peculiaridad será que los datos son almacenados localmente hasta que puedan ser sincronizados.

¿Merece la pena ese enfoque? ¿Realmente tiene ventajas?

Absolutamente. La primera ventaja, parece obvia, pues el usuario va a poder seguir interactuando con la aplicación del mismo modo, exista o no conexión a Internet, por lo que la experiencia de usuario no se verá mermada.

En segundo lugar, los recursos de un dispositivo móvil, como todos sabemos (y hasta hemos llegado a sufrir/padecer), no son ilimitados. Pero no sólo me refiero a batería, sino que también podría ser el tráfico y ancho de banda de la conexión. Recordemos algunos de los ejemplos que habíamos mencionado al comienzo del artículo. ¿Es necesario que toda esa documentación que necesita procesar, sea sincronizada con el servidor en ese justo momento? ¿Se podría subir al servidor esos documentos utilizando conexión WiFi en lugar de 2G/3G/4G (según disponibilidad además)? Si es necesario realizar fotografías para adjuntarlas a un expediente, ¿impacta que sean sincronizadas al final de la jornada laboral? Probablemente no necesiten ser enviadas al momento (en caso además de tener Internet). Utilizando esta técnica estamos consiguiendo que el comercial o el operario puedan realizar su trabajo sin impedimentos (experiencia de usuario), sino que además estaremos haciendo un uso eficiente de los recursos del dispositivo.

En tercer lugar, y aplicando el simple principio de localidad, si los datos los tenemos ya en la BD, ¿para qué invertir nuevamente tiempo y recursos en una llamada a backend? Aprovechemos esa base de datos local de la que disponemos: por defecto, siempre se acudirá al almacenamiento local para mostrar al usuario la información disponible lo más rápido posible; en paralelo se lanza la llamada a backend para recuperar la información actual y más reciente (en caso de existir). Con los datos recuperados:

• Notificamos al usuario que existe información actualizada (como Twitter cuando nos indica que hay nuevos tweets).
• Actualizamos la base de datos local, de modo que si el usuario sale y vuelve a entrar en la aplicación (incluso estando en offline), podrá seguir contando con dichos datos actualizados.

Conclusiones

Como hemos visto, el concepto de offline first implica un cambio de paradigma y en cómo los datos van a fluir por la aplicación.

Sin embargo, hemos evidenciado también algunos de los principales beneficios que obtendremos al trabajar con un almacenamiento local en el dispositivo móvil, como el ser más rápidos mostrando datos o poder seguir trabajando con la información de modo offline y de manera transparente para el usuario, teniendo la certeza y la tranquilidad de que serán sincronizados en cuanto se recupere la conectividad.

Y vosotros, queridos lectores, ¿os animáis a jugar con el offline first? Si tenéis dudas o queréis profundizar sobre este tema, podéis poneros en contacto conmigo sin problemas, escribiendo un mensaje en este post.

¡Un tech-saludo!