Foto: Tiger Lily · Fuente original · Pexels License. Redimensionado para web, sin alterar el contenido. No implica respaldo del autor ni del fabricante.
Capturar sin conexión exige una cola local persistente, identificadores únicos por operación, reglas para conflictos y reintentos seguros que no dupliquen movimientos. La marca de tiempo del dispositivo no basta como árbitro: conviene versionar registros y definir qué gana en una colisión. Los datos guardados en el equipo requieren cifrado, borrado remoto y política de retención. Sin pruebas con cortes reales, el diseño es solo una hipótesis.
Cuándo hace falta trabajar sin conexión
No todas las operaciones necesitan funcionar sin red, y diseñar todo para eso encarece el proyecto. Distinga operaciones que deben poder realizarse siempre (recibir, mover, contar) de las que requieren respuesta inmediata del servidor (validar un pedido contra existencias en tiempo real, reservar un recurso único). Para cada una, decida: ¿se bloquea la acción sin red, se permite con riesgo asumido o se captura y concilia después?
La documentación de Android sobre apps offline-first define este tipo de aplicación como una que puede realizar todas o un subconjunto crítico de su funcionalidad sin acceso a internet, y recuerda que la conexión puede ser limitada, interrumpida de forma transitoria o intermitente. Es un buen marco de partida, aunque su aplicación de almacén pueda ser un producto de terceros que usted no programa.
La cola local de operaciones
Cada acción del operador debería guardarse localmente como una operación con identificador único generado en el dispositivo, tipo, datos, usuario, equipo, momento de captura y estado (pendiente, enviada, confirmada, rechazada). La base local debe sobrevivir a reinicios y a descargas completas de batería. Un identificador único por operación permite que el servidor reconozca reintentos y no cree duplicados, lo que se denomina idempotencia.
La guía de WorkManager de Android describe cómo definir trabajo en segundo plano, programarlo una vez o de forma periódica, y devolver un resultado de reintento (Result.retry) para que el sistema lo vuelva a intentar según una política de reintento. También aclara que el momento de ejecución depende de las restricciones de la solicitud y de las optimizaciones del sistema, por lo que una sincronización diferible no ocurre al instante. Úselo como ejemplo de patrón, no como obligación: lo decisivo es que la sincronización sea persistente, reintente con espera creciente y registre fallas.
Conflictos, versiones y marcas de tiempo
Dos operadores pueden modificar el mismo registro sin conexión: uno cuenta 12 unidades, otro mueve 3 a otra ubicación. Al sincronizar, ¿qué cifra queda? No existe una respuesta técnica universal; es una regla de negocio. Defina por cada tipo de dato:
- Operaciones aditivas (movimientos, recepciones): se aplican en secuencia, no se sobrescriben.
- Valores absolutos (conteos): se compara contra la versión del registro que el dispositivo conocía y se señala el conflicto si cambió.
- Documentos cerrados: se rechazan cambios sobre registros ya cerrados y se envían a revisión.
Las marcas de tiempo del dispositivo pueden estar desfasadas por reloj mal ajustado o zona horaria; úselas como información, no como árbitro único. Un número de versión o contador por registro suele ser más fiable. Registre ambos: hora de captura en el dispositivo y hora de recepción en el servidor.
Reintentos y duplicados
| Escenario | Riesgo | Mitigación |
|---|---|---|
| Se corta la red tras enviar y antes de la respuesta | El dispositivo reenvía y se duplica | Identificador único de operación e idempotencia en servidor |
| Se reinicia el equipo con cola pendiente | Pérdida de operaciones | Almacenamiento persistente y confirmación por operación |
| Servidor rechaza una operación | El operador no se entera | Estado visible y lista de excepciones por resolver |
| Reloj del equipo desfasado | Orden incorrecto | Versiones y hora del servidor como complemento |
Muestre al operador un estado claro: cuántas operaciones están pendientes, cuáles fallaron y qué debe hacer. Un indicador oculto genera la falsa impresión de que todo se guardó.
Privacidad y seguridad de datos locales
Los datos guardados offline están en un equipo que puede perderse. Minimice lo almacenado: solo los campos necesarios y por el tiempo necesario. Active el cifrado de almacenamiento que ofrezca la plataforma, use bloqueo de pantalla o modo dedicado y defina el procedimiento de borrado remoto si hay pérdida. La guía NIST SP 800-124 Rev. 2 trata los controles y el ciclo de vida de los dispositivos móviles empresariales, incluido su retiro. Si los datos incluyen información personal, consulte a su responsable de privacidad y revise el aviso aplicable en su organización; este artículo no ofrece una conclusión legal.
Pruebas con cortes reales
Pruebe modo avión durante capturas, apagado forzado, batería agotada, reloj desajustado, servidor lento, doble envío y sincronización masiva al volver a la red, con muchos equipos a la vez. Mida cuánto tarda en vaciarse una cola grande y si la aplicación sigue utilizable mientras sincroniza. Ejemplo hipotético: si 50 equipos regresan a cobertura al terminar el turno, el servidor podría recibir una ráfaga; compruebe límites antes de producción.
Ejemplo hipotético de flujo de recepción
Hipotético. Un operador registra la recepción de una tarima en una zona sin red. La aplicación genera una operación con identificador único, guarda la cantidad, la ubicación y el usuario, y muestra «pendiente de sincronizar». Al volver la red, envía la operación; el servidor la registra y responde. Si la respuesta se pierde, el equipo reenvía la misma operación con el mismo identificador y el servidor reconoce que ya la procesó. Si otro operador ya cerró el documento de recepción, el servidor rechaza la operación y la aplicación la muestra en una lista de excepciones para que el supervisor decida. Ese recorrido, con sus casos de error, es lo que hay que escribir y probar antes de lanzar.
Observe que el diseño no supone que el dispositivo tenga siempre la razón. La captura local es un registro de lo que ocurrió en campo, y el servidor sigue siendo el responsable de las reglas del negocio. Esa separación facilita la auditoría y reduce discusiones sobre quién alteró un dato.
Cómo decidir el alcance
Empiece por una lista de operaciones y marque, para cada una, la tolerancia a la ausencia de red. Implemente offline primero en las críticas, con reglas de conflicto escritas y probadas. Si su software es de terceros, solicite documentación de su comportamiento sin conexión y pruebe cada caso en su piloto.
¿Con Wi-Fi bueno ya no necesito offline?
Siempre habrá microcortes; la cola local protege los datos.
Para revisar el flujo con su equipo, puede contactar a ARKCOM.
Fuentes y alcance
- Build an offline-first app | Android Developers · Android Developers (Google)
Primaria: arquitectura offline-first - Get started with WorkManager | Android Developers · Android Developers (Google)
Primaria: trabajo persistente en segundo plano - NIST SP 800-124 Rev. 2: Guidelines for Managing the Security of Mobile Devices in the Enterprise · NIST CSRC
Primaria: marco de gestión y ciclo de vida de dispositivos móviles
Artículo informativo preparado con apoyo de IA. No constituye una cotización, garantía de desempeño ni validación de compatibilidad. Confirma las especificaciones vigentes con el fabricante y valida tu caso con una prueba. Conoce el criterio editorial.
Las referencias respaldan aspectos concretos, no una garantía de resultados ni la vigencia de todas las condiciones descritas. Los ejemplos y listas de verificación orientan la evaluación; no sustituyen asesoría técnica o jurídica para tu caso. Las fotografías son ilustrativas: no acreditan clientes, instalaciones ni proyectos de ARKCOM, ni implican respaldo de marcas o personas. Los precios visibles no son cotizaciones para México.
¿Qué necesita tu operación?
Comparte tu proceso, volumen y sistemas actuales para iniciar la conversación.
Contactar a ARKCOM