Aplicación empresarial offline: cómo diseñar la sincronización
Por Carlos Isidoro De Ayala Diaz ·
Aplicación empresarial offline: qué datos guardar, cómo encolar cambios, resolver conflictos y probar la sincronización antes de desarrollar el proyecto.
Decide qué debe seguir funcionando cuando desaparece la conexión
Una aplicación empresarial no necesita replicar todas sus funciones para ser útil sin cobertura. El primer paso es describir las tareas que no pueden esperar: consultar una orden de trabajo, registrar una visita, preparar un pedido, leer instrucciones o capturar una firma. Para cada tarea se indica qué datos necesita, cuánto tiempo pueden tener de antigüedad, qué operaciones pueden quedar pendientes y cuál debe bloquearse hasta recuperar la red. Esta decisión evita convertir el modo offline en una copia completa del sistema central sin una razón operativa.
También se define una fuente de verdad. La app puede leer desde una base local para responder con rapidez, mientras el servidor mantiene el estado compartido por la organización. Android recomienda que una arquitectura offline disponga de una fuente local y otra de red, y que la capa de datos coordine ambas. Eso no significa que el último valor guardado en el teléfono sea siempre correcto: la interfaz debe mostrar cuándo se sincronizó, qué información puede estar desactualizada y qué acción todavía no ha llegado al servidor.
El modelo de datos se diseña para sincronizar unidades con sentido. Un pedido puede contener cabecera, líneas, precios, adjuntos y aprobaciones con reglas distintas. Descargar una lista sin sus dependencias puede dejar una pantalla visible pero inutilizable. Conviene determinar qué registros pertenecen al usuario, a la sede o a una ruta; qué históricos necesita; y qué datos deben borrarse al completar la tarea. Las fotografías y documentos suelen requerir colas y límites separados porque pesan más, fallan de otra forma y pueden contener información sensible.
El alcance identifica además restricciones del dispositivo: espacio, batería, versiones de iOS y Android, uso compartido, cierre de sesión y posibilidad de pérdida. Una función offline para comerciales no tiene las mismas condiciones que una app instalada en terminales de almacén administrados por la empresa. Si una acción exige confirmar existencias, crédito o disponibilidad en tiempo real, la aplicación debe explicar por qué no puede completarla sin conexión en lugar de aceptar un resultado que el negocio no podrá cumplir.
Encola cambios y reintentos sin duplicar operaciones
Cada modificación local necesita un identificador estable, el usuario que la creó, una marca de versión y un estado de sincronización. La cola diferencia pendiente, en envío, aceptada, rechazada y pendiente de revisión. Marcar una operación como completada antes de recibir una confirmación fiable puede perderla; reenviarla sin reconocer intentos anteriores puede duplicar pedidos, cobros o movimientos. La interfaz debe permitir ver qué queda pendiente y evitar que el usuario repita manualmente una acción porque parece que el botón no respondió.
Los reintentos se diseñan según la semántica de la operación. RFC 9110 define como idempotente una petición cuyo efecto previsto es el mismo aunque se repita, y permite reintentar métodos idempotentes cuando la conexión se corta antes de recibir la respuesta. Muchas altas empresariales utilizan POST y no son idempotentes por defecto. En esos casos el cliente puede generar una clave única y el servidor conservar el resultado asociado, o puede consultar el estado antes de repetir. Cambiar el método HTTP sin cambiar el comportamiento del backend no resuelve el problema.
El orden también importa. Crear un cliente antes de sus pedidos, subir un documento antes de enlazarlo o cerrar una visita después de guardar sus tareas son dependencias que la cola debe conocer. Un fallo permanente por validación no debe reintentarse indefinidamente; se muestra al usuario con una explicación y se conserva lo necesario para corregirlo. Los fallos transitorios emplean espera progresiva y límites. Cuando vuelve la conectividad, varias colas no deberían competir hasta agotar batería, datos o capacidad de la API.
La sesión puede caducar mientras el dispositivo está desconectado. La app puede seguir permitiendo ciertas lecturas locales, pero no debería renovar silenciosamente permisos ni enviar cambios con una identidad que ya fue retirada. Se acuerda qué ocurre si el usuario cambia de puesto, se desactiva su cuenta o pierde acceso a una sede durante el corte. Al reconectar, autenticación y autorización se vuelven a comprobar antes de aplicar cada operación relevante; una cola creada con permiso no garantiza que ese permiso siga vigente horas después.
Resuelve conflictos con reglas del negocio y protege la copia local
Hay conflicto cuando el mismo dato cambia en dos lugares antes de reconciliarse. La regla de que gana la última escritura es sencilla, pero puede borrar una modificación válida si los relojes difieren o si dos personas editan campos distintos. Para algunas entidades se pueden combinar cambios por campo; para otras se conserva la versión del servidor y se presenta la alternativa a una persona responsable. Apple expone políticas y objetos específicos para detectar y resolver conflictos en Core Data, pero la elección de política sigue dependiendo del significado del dato.
Las reglas se escriben con ejemplos. Si dos técnicos cierran la misma orden, si cambia el precio mientras un comercial prepara el pedido o si una visita se cancela antes de recibir sus notas, el equipo debe decidir el resultado y la evidencia que se conserva. Las versiones y marcas de cambio permiten al servidor rechazar una actualización construida sobre un estado antiguo. Un rechazo necesita una salida comprensible: comparar, rehacer, solicitar aprobación o conservar como borrador, no simplemente mostrar un error genérico después de horas de trabajo.
Guardar información en el dispositivo añade obligaciones de seguridad y privacidad. Se minimizan campos, se usa el almacenamiento privado de la plataforma y se protege material sensible con las capacidades adecuadas del sistema. OWASP MASVS exige almacenamiento seguro y prevención de fugas, incluidas exposiciones involuntarias en copias, registros o ubicaciones públicas. Cifrar una base no evita que la aplicación muestre datos a un usuario ya revocado, por lo que también se definen bloqueo, caducidad, borrado remoto cuando la plataforma lo permita y limpieza al cerrar sesión.
Los registros técnicos no deben copiar datos completos para facilitar la depuración. Basta con identificadores, versiones, estados, tiempos y códigos de error cuando permiten reproducir el problema. Tokens, documentos, coordenadas o datos personales requieren un tratamiento específico. La retención local se ajusta a la operación: conservar años de historial en cada móvil aumenta exposición y dificulta migraciones sin mejorar la tarea diaria. La propuesta debe separar la caché necesaria de la información que solo pertenece al sistema central.
Prueba cortes reales, recuperación y soporte antes de desplegar
Las pruebas incluyen más que activar el modo avión y abrir una pantalla. Se corta la red antes, durante y después de cada operación; se cambia entre WiFi y datos; se cierra la app; se reinicia el dispositivo; se acumulan cambios durante horas; y se recupera conectividad con sesión válida y caducada. También se prueban poco espacio, archivos grandes, datos eliminados en el servidor, cambios simultáneos y versiones antiguas de la app. Cada escenario tiene un resultado esperado que negocio puede aceptar.
La reconciliación se comprueba en ambos sentidos. Se cuentan operaciones, se comparan importes y estados y se verifica que una acción aceptada no vuelve a la cola. Los indicadores útiles incluyen antigüedad de la última sincronización, pendientes por tipo, reintentos, rechazos, conflictos y tiempo de recuperación. No hace falta enviar contenido sensible para observar el sistema. Una alerta detecta colas detenidas o una versión que deja de sincronizar, mientras el soporte dispone de un identificador que permite investigar sin pedir al usuario capturas con datos de clientes.
El piloto utiliza dispositivos, cobertura y volumen representativos. Personal de campo comprueba mensajes, tiempos y recuperación; el equipo que recibe los datos valida que no falten ni se dupliquen operaciones. El despliegue gradual limita el impacto de una regla equivocada. También se prepara una actualización de esquema para datos locales existentes: publicar una nueva versión no puede borrar borradores pendientes ni interpretar con otro significado una cola creada por la versión anterior.
Élite Solutions Tech puede ayudar desde Murcia a definir y desarrollar aplicaciones empresariales para iOS y Android con funcionamiento conectado u offline. La propuesta concreta tareas disponibles sin red, datos locales, sincronización, conflictos, seguridad, matriz de pruebas y soporte; no presupone el modo offline por el mero hecho de crear una app. Para una primera valoración puedes explicar en el formulario de contacto quién usa la aplicación, dónde pierde cobertura y qué operaciones no pueden esperar, sin enviar credenciales ni datos reales de clientes.