Los equipos de campo trabajan en sótanos, túneles, valles remotos y zonas de catástrofe donde la antena de móvil es lo que se rompió. Cualquier herramienta geoespacial pensada para ellos tiene que funcionar sin conexión alguna, durante horas, y luego reconciliar limpiamente cuando la conexión vuelve.
Esto se acota de forma rutinaria como una función -«añadir soporte sin conexión»- y no lo es. Es una decisión de arquitectura que toca tu modelo de datos, tu estrategia de identificadores, tu semántica de conflictos y tu interfaz. Adaptarla a un sistema diseñado en torno a un servidor en vivo se acerca a una reescritura, así que la decisión hay que tomarla antes de la primera línea de código.
El dispositivo es una réplica, no una caché
La decisión más consecuente con diferencia es cómo piensas en el dispositivo. Una caché es una copia temporal de un estado autoritativo del servidor. Una réplica es un participante de pleno derecho que puede originar cambios autoritativos por sí sola.
Las herramientas de campo necesitan réplicas. Un inspector que registra cuarenta observaciones a lo largo de seis horas sin cobertura ha creado seis horas de datos autoritativos. Eso no es una caché obsoleta que invalidar; es el registro primario, y el servidor nunca lo ha visto. Los sistemas construidos sobre semántica de caché tienden a gestionar esto descartando el estado local en caso de conflicto, lo que en un contexto de campo significa perder en silencio un día del trabajo de alguien.
Los identificadores tienen que generarse en el cliente
Si el servidor asigna identificadores, el dispositivo no puede crear un registro sin conexión. Esa sola restricción hace imposible la operación genuina sin conexión, y es asombroso con qué frecuencia se descubre tarde.
Genera UUID en el dispositivo. Esto tiene un segundo beneficio que importa más de lo que parece al principio: hace la sincronización idempotente. Si un dispositivo no está seguro de si una subida tuvo éxito -la conexión se cayó a mitad de la petición, lo que pasa constantemente- puede reintentar con seguridad, porque el identificador ya está fijado y el servidor puede reconocer el duplicado.
Decide la semántica de conflictos por campo, no por registro
Dos inspectores editan el mismo activo estando ambos sin conexión. Ambos sincronizan. ¿Qué debería pasar?
«Gana la última escritura» es el valor por defecto y suele estar mal, porque descarta en silencio el trabajo de una persona. Pero la respuesta correcta no es uniforme en todos tus datos: depende de lo que signifique el campo.
- Las observaciones son de solo añadir. Dos inspectores registrando observaciones separadas no es un conflicto en absoluto; ambas son ciertas. Modélalas como un registro de eventos en lugar de un campo mutable y el conflicto desaparece por completo.
- Los campos de estado sí entran en conflicto de verdad. Si uno marca un activo como «reparado» y otro lo marca como «condenado», alguien tiene que decidir. Sácalo a un humano, con ambos valores y ambas marcas de tiempo.
- Las correcciones de geometría suelen resolverse por recencia más metadatos de precisión. Una corrección registrada con mejor precisión de GPS debería ganar en general, sea cual sea el orden.
- Las fotos y los adjuntos nunca entran en conflicto. Guárdalos todos, atribuidos.
El objetivo no es evitar los conflictos. Es asegurarse de que ningún conflicto se resuelve en silencio de una forma que pierde información.
Los mapas base son el problema logístico difícil
Los teselados vectoriales y ráster para una gran área de operación son gigabytes. No puedes pedirle a un equipo de campo que se lo descargue por la conexión de un hotel la noche anterior, y no puedes enviarlo con la app.
El enfoque viable es el precacheo acotado por región y dirigido por el propio trabajo: cuando se asigna un trabajo a un dispositivo, los teselados del área de ese trabajo se ponen en cola para descarga mientras el dispositivo todavía tiene buena conexión. Los teselados vectoriales ayudan mucho aquí, ya que son bastante más pequeños que el ráster a un detalle equivalente y pueden reestilizarse en el dispositivo sin volver a descargarlos.
Muestra el estado de sincronización con honestidad
La interfaz debe responder siempre, sin que el usuario lo pida: qué hay solo en este dispositivo, qué ha llegado al servidor y qué ha fallado. Un solo indicador giratorio no comunica esto.
El estado por registro merece el coste de interfaz. Un trabajador de campo que decide si es seguro devolver la tableta al final del turno necesita saber si su tarde se ha subido. La ambigüedad aquí erosiona la confianza en la herramienta más rápido que casi cualquier otro defecto, y un equipo de campo que no confía en la herramienta vuelve al papel.
