Aplicación sin conexión: cuando falta la red

Un sótano que inspeccionar, un aparcamiento subterráneo, una obra en zona rural, un almacén de muros gruesos: el terreno suele estar donde la red no llega. Una aplicación que muestra un mensaje de error en ese momento pierde la partida. El técnico apunta en una libreta, fotografía con la cámara del teléfono, y todo vuelve al recorrido que la aplicación debía suprimir: volver a teclear por la noche, fotos extraviadas, información que llega con un día de retraso.

El modo sin conexión no es una casilla que se marca en un presupuesto. Es una serie de decisiones, de la más sencilla a la más costosa, que conviene tomar con conocimiento de causa.

En resumen

• El modo sin conexión tiene tres niveles: la aplicación se abre, los datos ya vistos siguen siendo consultables, los registros esperan a que vuelva la red.
• El tercer nivel es el más útil sobre el terreno, y el más caro, porque todo se juega en la sincronización.
• Dos personas que modifican la misma ficha sin conexión plantean una cuestión de negocio, no solo técnica: ¿quién tiene razón?
• Una aplicación instalable desde el navegador cubre los dos primeros niveles; el tercero es más sólido en una aplicación nativa.
• La decisión se toma a partir de una observación: ¿dónde pierden la red sus equipos, y durante cuánto tiempo?

Los tres niveles del modo sin conexión

Decir que una aplicación «funciona sin conexión» puede significar tres cosas muy diferentes.

1. 01Se abre.

   Las pantallas se guardan en el teléfono: la aplicación arranca sin red, en lugar de mostrar una página en blanco. Sus datos, en cambio, necesitan conexión para actualizarse.

2. 02Se consulta.

   Los expedientes ya abiertos (la ficha del cliente, el plano, la lista de intervenciones del día) siguen siendo legibles, con la fecha de su última actualización.

3. 03Registra.

   Los datos introducidos, las casillas marcadas y las fotos se guardan en el teléfono y se envían al servidor cuando vuelve la red, sin perder nada ni enviar nada dos veces.

Cada nivel se apoya en el anterior, y cada uno añade trabajo. El primero es casi un ajuste. El segundo exige elegir qué guarda el teléfono y durante cuánto tiempo. El tercero cambia la arquitectura de la aplicación.

Lo que el modo sin conexión cambia para el equipo

El beneficio no se mide en funcionalidades, sino en gestos que el equipo ya no tiene que hacer.

• Registrar in situ, una sola vez. La constatación se hace delante del equipo, no de memoria al volver a la furgoneta. Los detalles que se olvidan en veinte minutos se quedan en el expediente.
• Se acabó el doble circuito. Sin modo sin conexión, el equipo conserva la libreta «por si acaso», y vuelve la doble introducción de datos. Con él, la libreta desaparece de verdad.
• Una prueba fechada. La foto y la hora de la intervención se adjuntan al expediente en el momento en que se toman, y no cuando vuelve la red.
• Menos espera. Nadie busca una barra de cobertura con el teléfono en alto antes de poder pasar a la tarea siguiente.

Estas ganancias suponen que la aplicación ya se ha adoptado: las condiciones de adopción, pantallas cortas y acceso sin fricción, se detallan en lo que una aplicación de campo cambia para sus equipos.

El verdadero tema: la sincronización

Guardar en el teléfono es la parte fácil. El trabajo está en el regreso de la red.

Tres preguntas deciden la calidad de este recorrido.

No enviar nada dos veces. Un envío interrumpido se volverá a intentar. Si cada registro lleva un identificador único creado en el teléfono, el servidor reconoce un envío ya recibido y no crea un duplicado.

No fiarse del reloj del teléfono. Se puede ajustar a mano. El teléfono puede anotar la hora del registro a título informativo, pero lo que cuenta (el día de una intervención, un plazo) se valida en el servidor, como explicamos en la seguridad de una aplicación.

Saber quién tiene razón. Dos técnicos modifican la misma ficha, cada uno en un sótano. El primero que recupera la red envía su versión; ¿sobrescribe el segundo la primera? Firestore, la base de datos de Google para aplicaciones, lo escribe claramente en su documentación sobre el modo sin conexión: para varias modificaciones de un mismo documento, gana la última escritura.

Web instalable o aplicación de las tiendas

La elección entre una aplicación web instalable y una aplicación nativa, comparada en PWA o aplicación nativa, adquiere un matiz particular cuando falta la red.

Los límites de la web están documentados. WebKit, el motor de Safari, describe en su política de almacenamiento de 2023 un borrado automático de los datos de un sitio cuando se supera la cuota, cuando al dispositivo le falta espacio o cuando el sitio no se ha usado desde hace un tiempo. La interfaz que permite a una aplicación web aplazar un envío hasta que vuelva la red no está disponible en varios de los navegadores más utilizados, según la documentación de MDN. Y en la web, la persistencia sin conexión de Firestore está desactivada por defecto, con un consejo: preguntar al usuario si está en un dispositivo de confianza antes de guardar datos sensibles.

En el lado nativo, una aplicación construida con Expo dispone de una base SQLite en el teléfono, que persiste de un reinicio a otro. La elección del back-end también cuenta: Firestore incluye el modo sin conexión de serie en Android y iPhone, mientras que una base Postgres como la de Supabase exige organizar la sincronización, como detalla Supabase, Firebase o servidor propio.

Para una herramienta interna que sobre todo debe abrirse y consultarse sin red, la aplicación instalable suele bastar. Cuando registros importantes deben sobrevivir a una jornada sin red, la aplicación nativa es más segura.

Lo que cuesta, y cuándo prescindir de ello

El modo sin conexión completo es una de las decisiones que más hacen variar el precio de una aplicación: afecta a cada pantalla de registro, añade pruebas (cortar la red en mitad de un envío, dos teléfonos sobre la misma ficha) y se mantiene en cada versión, como el resto del presupuesto de mantenimiento.

Se puede prescindir de él cuando los cortes son breves y escasos, cuando el registro puede esperar unos minutos o cuando la aplicación sirve sobre todo para consultar. No se puede prescindir de él cuando el equipo pasa horas sin red, o cuando un registro perdido tiene un coste real: una constatación discutible, una entrega no probada, una intervención refacturada.

Por dónde empezar

1. 01Registrar las zonas sin cobertura.

   Durante dos semanas, el equipo anota dónde falta la red y durante cuánto tiempo.

2. 02Clasificar los gestos.

   Cuáles deben hacerse sin red (registrar una constatación, hacer una foto), cuáles pueden esperar (consultar el historial completo).

3. 03Escribir las reglas de conflicto.

   Para cada dato que pueden modificar varias personas, quién gana.

4. 04Probar sin red.

   Con una primera versión, en modo avión, con las personas que la usarán.

Estas decisiones se escriben en el pliego de condiciones de la aplicación y se prueban pronto con un prototipo navegable. Las demás decisiones de un proyecto tienen cada una su artículo: a medida o herramienta del mercado, publicar con su propia cuenta de desarrollador, las notificaciones, la suscripción, el portal de clientes, la IA en una aplicación, la recuperación de una aplicación abandonada, el low-code y el vibe coding.

Nuestro desarrollo de aplicaciones empieza con un encuadre escrito: lo que la aplicación hace el primer día, con o sin red.

Preguntas frecuentes

Fuentes

1. Documentación de Firebase, acceso a datos sin conexión (nueva pestaña)firebase.google.com
2. WebKit, actualización de la política de almacenamiento, agosto de 2023 (nueva pestaña)webkit.org
3. MDN, Background Synchronization API (nueva pestaña)developer.mozilla.org
4. Documentación de Expo, SQLite (nueva pestaña)docs.expo.dev