Una app para equipo de campo que funciona sin señal

Resumen:

• Sin conexión no es una función que se agrega después: es una decisión de arquitectura.
• La app guarda local y sincroniza en cola, con reintentos y sin perder nada.
• Los conflictos se evitan por diseño, repartiendo la propiedad del dato.
• El usuario tiene que ver el estado: capturado, pendiente, enviado.
• El supervisor necesita un tablero de sincronización, no suposiciones.

Una empresa de mantenimiento industrial nos buscó con un problema que sonaba a software y era de señal. Habían comprado una app para que sus 23 técnicos registraran servicios, y seis meses después el 70 por ciento de los reportes seguía llegando en hojas fotografiadas por WhatsApp.

La razón era simple: los técnicos trabajaban en sótanos de hoteles, cuartos de máquinas y naves con estructura metálica. Lugares donde no hay red. La app pedía señal para abrir el formulario, así que el técnico hacía lo único que podía hacer: sacaba la hoja.

Lo que significa «funciona sin señal»

No significa que la app no se caiga. Significa que la app no necesita el servidor para hacer su trabajo.

Son dos diseños distintos desde la base. En el primero, cada pantalla pregunta al servidor qué mostrar: sin red no hay pantalla. En el segundo, el teléfono tiene su propia copia de lo que el técnico necesita —sus órdenes del día, el catálogo de equipos, los tipos de falla— y el servidor es a quien le cuenta después lo que pasó.

¿Se puede usar una app sin internet?

Sí, si se diseñó para eso desde el principio. La app guarda la información en el teléfono y la sincroniza cuando recupera señal. Lo que no funciona es tomar una app que depende del servidor para cada pantalla y "agregarle" modo sin conexión después: eso casi siempre significa reescribirla.

Las cuatro piezas

Base de datos en el teléfono. Una copia local de lo que el usuario necesita para trabajar hoy. No todo el sistema: sus órdenes asignadas, los catálogos que usa y el histórico reciente del equipo que va a atender. En la práctica son unos pocos megabytes.

Cola de envíos. Cada cosa que el técnico captura entra a una fila de pendientes. Cuando hay red, la fila se vacía en orden. Si un envío falla, se reintenta más tarde en vez de desaparecer. La captura nunca depende de que el envío tenga éxito.

Descarga de lo nuevo. Al recuperar señal la app también baja lo que cambió: una orden reasignada, un equipo dado de baja, un precio actualizado. Si solo sube y no baja, el técnico trabaja con información vieja y eso genera errores peores que el papel.

Estado visible. Tres etiquetas que el usuario entiende sin explicación: guardado en el teléfono, pendiente de enviar, confirmado por el servidor. Cuando el usuario no sabe si su trabajo se registró, lo vuelve a capturar o lo anota en papel «por si acaso». Las dos cosas arruinan el dato.

El problema de verdad difícil: los conflictos

Dos técnicos sin señal editan el mismo registro. Ambos sincronizan. ¿Cuál gana?

No hay respuesta técnica universal; hay una decisión de negocio que alguien tiene que tomar antes de programar. Las opciones reales:

La segunda regla resuelve casi todo en campo. Si cada orden de servicio tiene un responsable y solo él la captura, no hay nada que reconciliar. Esto es diseño del modelo de datos, no programación defensiva.

¿Qué pasa si dos personas editan el mismo registro sin conexión?

Hay que decidir la regla antes de programar. Lo más común y lo más sano en operación de campo es que cada persona sea dueña de sus propios registros, de modo que el conflicto no pueda ocurrir. Cuando el dato sí es compartido, la regla tiene que ser explícita y el usuario debe poder ver qué pasó con su captura.

Las fotos, que siempre se subestiman

En una app de campo las fotos son el 90 por ciento de los datos que se transmiten. Un reporte de servicio con ocho fotos de 4 megabytes son 32 megabytes por orden. Veinte órdenes al día por 23 técnicos y la cuenta de datos se vuelve el costo principal.

Tres cosas que resuelven el problema: comprimir en el teléfono antes de guardar —a 1,200 píxeles de ancho casi nunca se pierde información útil—, subir las fotos en una cola aparte y de menor prioridad que los datos del reporte, y dejar que el usuario elija subir solo con red inalámbrica.

¿Cuánto más cuesta construir una app que trabaje sin conexión?

Entre un 25 y un 40 por ciento sobre la misma app en línea, porque hay que resolver almacenamiento local, cola de envíos, reintentos y estados de sincronización. Es más barato que descubrir a los tres meses que el equipo volvió al papel.

¿Una app web puede funcionar sin conexión?

Hasta cierto punto, con una aplicación web progresiva. Sirve bien para consultar y para capturar formularios sencillos. Cuando hace falta cámara intensiva, lectura de códigos a volumen, GPS en segundo plano o muchas fotos pesadas, la app nativa sigue siendo más confiable.

Lo que el supervisor necesita ver

Este es el punto que casi nadie pide y que cambia la operación. Cuando los datos llegan con retraso variable, la ausencia de información es ambigua: ¿el técnico no trabajó, o no ha sincronizado?

El tablero de sincronización responde eso. Por cada dispositivo: última conexión, registros pendientes, versión de la app. Con eso el supervisor sabe que el técnico de la zona norte lleva seis horas sin reportar porque está en una nave, no porque esté sin hacer nada.

¿Cómo sabe el supervisor qué información ya llegó y cuál no?

Con un tablero de sincronización: qué dispositivos reportaron, cuándo fue su última conexión y cuántos registros traen pendientes. Sin eso, nadie sabe si la ausencia de datos significa que no hubo trabajo o que el teléfono no ha sincronizado.

Cómo terminó

Reconstruimos la app con base local y cola de envíos. El cambio medible no fue técnico: a las ocho semanas, el 96 por ciento de los servicios se registraba en la app el mismo día, contra el 30 por ciento anterior.

Y apareció un beneficio que no estaba en el alcance. Con los reportes completos y con fecha real, la empresa pudo facturar servicios que antes se perdían porque la hoja nunca llegaba a la oficina. Eso solo recuperó más de lo que costó el proyecto.