Offline-First Urban Lighting App Transformation

Hola, y bienvenidos a Shining Offline, una charla sobre las mejores prácticas acerca de cómo casi luchamos y cómo el principio de offline first nos ayudó. Soy Thorsten Hell y trabajo para una pequeña empresa de software llamada Kismet en el suroeste de Alemania. Hoy quiero compartir cómo nos encontramos a un paso del desastre con el primer sistema móvil de información de iluminación urbana del Consejo Municipal de Wuppertal, y cómo el enfoque de offline first nos salvó, convirtiendo un momento difícil en una experiencia más fluida y fácil para nuestro equipo.

Aquí está la estructura de mi charla. Comenzaré con una introducción con una diapositiva sobre Kismet. Luego, explicaré qué es el sistema original de Bayless y por qué lo desarrollamos. Después mostraré cómo hicimos la transición de iOS a una aplicación web progresiva, enfocándonos en un enfoque offline first de cuatro dimensiones. Al final, resaltaré los puntos más importantes desde mi perspectiva.

Kismet comenzó en 2002 como una empresa derivada de EIG en la Universidad de Ciencias Aplicadas de Saarland. Nuestro enfoque principal es construir soluciones de software para ciudades y organismos gubernamentales locales utilizando tecnologías open-source. Somos una empresa 100% remota y hemos estado trabajando de forma remota mucho antes de la pandemia.

Entonces, hablemos de Bayless. ¿Qué es? En 2008, la Administración de la Ciudad de Wuppertal nos pidió que desarrolláramos un sistema de información para gestionar la iluminación de la ciudad. Necesitaba integrarse con la infraestructura geoespacial data que ya habíamos ayudado a construir. Con los sistemas antiguos, como BS2000 o MSXS, la georreferenciación se hacía manualmente en mapas impresos. Decidimos utilizar una aplicación Java Rich Client, que era bastante común en ese momento. Lo realmente nuevo era el componente de mapa integrado. La aplicación se encargaba de registrar y gestionar todo tipo de objetos en la infraestructura de iluminación. Esto incluía no solo las luces, sino también postes, estaciones de interruptores, cajas de empalme e incluso cables con ganchos de pared, que son accesorios colocados en los edificios para sostener cuerdas y cables en su lugar. Incluso estas pequeñas piezas estaban georreferenciadas y se mostraban en el mapa.

Además de gestionar los objetos de la infraestructura de iluminación, el sistema también manejaba órdenes de trabajo, en ese momento como informes. Estos informes se imprimían, se llevaban al campo, se completaban a mano y luego se ingresaban nuevamente en el sistema, lo que causaba mucho esfuerzo innecesario e inconvenientes tanto para los proveedores de servicios como para los operadores.

En 2015, por lo tanto, surgió la demanda de una solución móvil, y ambiciosamente tuvimos la brillante idea de construir una aplicación nativa de iOS utilizando Swift. Utilizamos el componente de mapa nativo de iOS. En eso, permitimos a los usuarios buscar objetos en el sistema, mostrar estos objetos en diferentes mapas de fondo de iOS, y acceder a información detallada de cada objeto, incluyendo imágenes. Los usuarios también podían realizar acciones en los objetos, como tomar fotos o informar problemas. La aplicación permitía cargar órdenes de trabajo y gestionarlas a través de protocolos vinculados a cada objeto específico que estaban de alguna manera relacionados con la orden de trabajo. Las asignaciones de trabajo aquí van desde pintar sobre pruebas eléctricastesting hasta verificaciones de estabilidad y otras tareas. En este ejemplo, se muestra el pequeño formulario que los usuarios necesitaban completar para una prueba de estabilidad.

Tuvimos varios problemas con esta aplicación de iOS. Después de que se construyó la aplicación, básicamente estaba completa en cuanto a funciones, por lo que no se planificó un desarrollo mayor por parte de la ciudad. Además, no pasamos por la App Store. Utilizamos una distribución ad hoc, que se puede hacer si tienes un recuento de implementación de menos de 100 dispositivos. Por lo tanto, constantemente estábamos implementando actualizaciones para ajustar los archivos de certificado debido a dispositivos nuevos o modificados y actualizaciones relacionadas con los cambios de Swift. Pero uno de los mayores desafíos fue cómo nuestra aplicación se comunicaba con la infraestructura. Se comunicaba con el resto del sistema como si fuera una aplicación de intranet, porque eso es lo que hicimos durante años. A menudo escuchábamos que la aplicación no funcionaba incluso cuando el problema no estaba en nuestro lado. Cada vez teníamos que demostrar primero que no éramos culpables. Esto fue especialmente desafiante con la comprensión del nivel de servicio del departamento de TI de la ciudad en ese entonces. Por ejemplo, cuando hacían cambios en las reglas del firewall un viernes a las 2 p.m. y luego se iban para el fin de semana. Así que bienvenidos a Elm Street. Como puedes imaginar, no estábamos muy contentos con cómo iban las cosas. Finalmente, logramos convencer al cliente de hacer el cambio a una aplicación web progresiva.

Afortunadamente, para entonces, habíamos adquirido experiencia con aplicaciones de una sola página construidas utilizando React y Leaflet y habíamos desarrollado varios mapas de temas, que son pequeñas aplicaciones que intentan llenar el vacío entre los grandes portales GIS y los mapas básicos deslizantes. Aquí hay algunos ejemplos de esos mapas de temas. Van desde mapas para estaciones de monitoreo ambiental hasta mapas de la ciudad con puntos de interés hasta mapas de estaciones de carga para la electromovilidad o mapas de peligro de lluvias intensas. La aplicación para el equipo de alarma ambiental o la aplicación ciudadana para calcular las tarifas de aguas pluviales basadas en superficies selladas también se construyeron utilizando estos componentes y muchos más. Así que teníamos el conocimiento para construir estos sistemas y estábamos emocionados de usar estos componentes que desarrollamos en la nueva aplicación web progresiva Bayliss.

El diseño de la nueva PWA debe basarse en la aplicación existente, pero con mejoras en la usabilidad y con el cambio de utilizar ahora mapas y servicios de la infraestructura propia de la ciudad, ya no los mapas de Apple. Ahora les mostraré la nueva PWA.

La experiencia del usuario comienza como antes, con una pantalla de inicio de sesión. Visualmente, el diseño sigue siendo casi el mismo que la aplicación de iOS. Los usuarios pueden enfocarse en buscar solo objetos en el centro del mapa. Pueden cambiar entre tres fondos de mapas diferentes. El fondo se puede hacer más transparente para mejorar la visibilidad de los objetos. El primer cambio pequeño detrás de escena es que ahora la búsqueda de posicionamiento utiliza el directorio de calles de la ciudad. También se ha ajustado la presentación de la información y ahora siempre se posiciona en la misma área de la pantalla. Utilizando componentes del proyecto que mencioné anteriormente, los mapas de temas, pudimos superar la funcionalidad de la aplicación de iOS sin requerir demasiado esfuerzo.

Como una mejora importante, las nuevas hojas de datos presentan la información sobre los objetos de manera mucho más clara, simplemente porque tenemos más espacio para usar. Sin embargo, se tuvieron que mantener las funciones principales. Los usuarios tuvieron que configurar su propia navegación. Los usuarios aún pueden capturar fotos de cada objeto que encuentren. Pueden informar problemas relacionados con un objeto. Pueden seleccionar y ver órdenes de trabajo y seleccionar la tarea que necesitan realizar dentro de dicha orden de trabajo. Aquí vemos la interfaz de usuario mejorada para actualizar el estado de un objeto de iluminación que se informó como roto. Y aquí vemos el pequeño formulario para completar cuando un trabajador realmente reemplazó la bombilla según una orden de trabajo. Al utilizar nuestra propia aplicación, logramos solucionar aproximadamente el 50% de los problemas que teníamos con la aplicación anterior. También significó que ya no dependíamos de esa única persona que conocía un poco de Swift. Así que pudimos distribuir el trabajo de manera más equitativa.

Pero, ¿qué pasa con el resto? Bueno, como mencioné anteriormente, el principio de primero sin conexión ayudó mucho. Implementamos el principio de primero sin conexión en cuatro dimensiones diferentes: PWA, mapas sin conexión, datos de la aplicación y sincronización en lugar de publicar. La parte de PWA fue la más fácil. Es bastante estándar y encontrarás muchas instrucciones al respecto. Creamos un service worker para nuestra aplicación, lo que le permite iniciarse incluso sin conexión a Internet o con una conexión deficiente, agregando algunas etiquetas de medición y un archivo de manifiesto. Y, bueno, se ve y se siente como una aplicación. Pero esto es bastante común, así que no entraré en detalles aquí.

Proporcionar un fondo de mapa sin conexión a internet es ciertamente más interesante. Después de descartar la primera idea de usar un service worker para interceptar el tráfico, encontramos una solución utilizando el protocolo de la aplicación MapLibreGL. Con esa gran característica, pudimos establecer una función de tipo de carga personalizada. Primero, necesitamos almacenar los 30 megabytes de teselas vectoriales de la ciudad de Ubatal en un IndexedDB. Y luego, con la ayuda de esta función de tipo de carga personalizada, podemos acceder a las teselas sin conexión a través de la red.

Para una charla en una conferencia alemana, preparé un proyecto en GitHub donde puedes ver cómo funciona esto en detalle. El proyecto ilustra los siete pasos para tener un mapa disponible sin conexión, incluyendo una instancia en ejecución donde puedes saltar a través de los pasos. En Beelis, así es como se ve el acceso sin conexión a la capa vectorial. El usuario simplemente marca una casilla para habilitarlo y luego se descarga y guarda el archivo en la database. Eso es todo. Una vez hecho, el mapa de fondo se puede acceder completamente sin conexión sin necesidad de una conexión a internet. Lo verás en acción más adelante en la presentación.

El siguiente nivel implica los data de la aplicación. Esto significa que necesitamos tener todos los data de los objetos en el navegador. Con todos los data de los objetos, me refiero a toda la información sobre luces, cables, órdenes de trabajo, y demás. Y para que sea posible la búsqueda, también necesitamos almacenar un índice de geometría de todos los objetos. Sin embargo, no almacenamos imágenes en el modo sin conexión debido al tamaño. Luego, cuando la aplicación está en modo sin conexión, los data ya no se cargan directamente desde el sistema en vivo sino desde esta caché de la aplicación o mejor dicho, almacenamiento sin conexión de la aplicación. Así es como se ve en la aplicación. Por lo general, antes de que un usuario salga de su oficina para trabajar en las calles, debe actualizar la caché. Este proceso de actualización es manual y debe ser iniciado por el usuario. Con el Wi-Fi de la oficina, todo el proceso lleva menos de un minuto. Una vez actualizado, se puede activar el modo sin conexión dentro de la aplicación. Lo demuestro aquí activando el modo avión. Aquí puedes ver tanto los data disponibles sin conexión como el mapa accesible sin conexión. Funciona tan bien que los usuarios a menudo cambian a este modo para acelerar las cosas cuando su conexión móvil no es buena. La capa final del paradigma de primero sin conexión en Bayless es la sincronización en lugar de publicar.

En nuestras comunicaciones con el punto final de la aplicación iOS, no utilizamos operaciones CRUD tradicionales. En su lugar, nos comunicamos a través de acciones específicas como informar una interrupción o agregar una imagen. El desafío fue que estas acciones eran desencadenadas directamente por la interfaz de usuario. Para habilitar este comportamiento sin conexión, las acciones junto con sus cargas ahora se escriben en una tabla localmente. Luego, esta tabla se sincroniza con el servidor en nuestro centro de datos. Cuando la tabla sincronizada cambia en el servidor, realizamos las llamadas API adecuadas y escribimos los resultados de vuelta en la tabla en el servidor. El proceso de sincronización establecido garantiza que estas actualizaciones se entreguen de vuelta al dispositivo final.

El núcleo sin conexión se implementó utilizando la combinación de RxDB y Hasura PostgresQL. Aquí puedes ver el esquema. En el lado izquierdo, puedes ver nuestra infraestructura de internet con un punto final de API público. En el centro, puedes ver lo que llamamos nuestro núcleo sin conexión, que se encuentra en el centro de datos del cual somos responsables. Y en el lado derecho, puedes ver el dispositivo final que es la PWA que se ejecuta en un iPad. Con ese comportamiento, abordamos muchos problemas relacionados con la confiabilidad. La aplicación se volvió más resistente a problemas con las conexiones móviles, la infraestructura de la ciudad o incluso los tiempos de inactividad de nuestras API. Pero también introdujimos algunos problemas nuevos.

En primer lugar, tuvimos estados intermedios más largos. Por lo tanto, necesitábamos visualizar los cambios que existen exclusivamente en el dispositivo final en cualquier momento. Lo logramos con marcas claras en la interfaz de usuario. Por ejemplo, si un número se genera normalmente en el servidor, simplemente no podemos mostrarlo antes de que se realice un viaje de ida y vuelta. En ese caso, reemplazamos los caminos generados con estrellas. En segundo lugar, tuvimos que lidiar con posibles conflictos. Para mantener la consistencia, simplemente ejecutamos todas las solicitudes en su orden original como si todos los servicios hubieran estado en línea todo el tiempo. Este método ayuda a prevenir conflictos entre los cambios sin conexión y el sistema en vivo. El siguiente punto fue la necesidad de una retroalimentación detallada del estado. Proporcionar a los usuarios retroalimentación sobre el guardado exitoso de los datos es esencial. Los indicadores visuales en la interfaz de usuario ayudan a los usuarios a comprender el estado actual de sus datos, especialmente en modo sin conexión. El último punto es la confianza. Para tranquilizar nuestra conciencia y proporcionar una red de seguridad, cada dispositivo final puede descargar la tabla de acciones. Esta función sirve como precaución en caso de que algo salga mal. Sin embargo, nunca hemos tenido que usar esta función de respaldo, lo que destaca la estabilidad y confiabilidad de nuestro sistema.

Entonces, ¿cuál es la conclusión principal aquí? En primer lugar, el enfoque de offline-first no se detiene solo en la configuración de una aplicación web progresiva. La parte más importante es que requiere un esfuerzo significativo. Pero la buena noticia es que si estás yendo más allá, los usuarios están muy satisfechos.

Quiero mencionar como una nota al margen, aunque no estamos restringidos a ellos, los iPads siguen siendo los dispositivos de elección. Por lo tanto, no hay dispositivos Android en este momento en nuestro trabajo de campo.

Muchas gracias por escuchar y gracias a React Summit US por tenerme. Espero que nuestro viaje haya sido útil para todos ustedes. No dudes en contactarme en línea si tienes alguna pregunta. Seguro que me encontrarás. Gracias.