Cómo resolver cambios sin conexión al reconectar una app

Un formulario móvil puede guardarse correctamente sin conexión y, al reconectarse, sobrescribir el trabajo de otra persona. Imagina que un empleado de campo modifica una nota mientras alguien en la oficina cambia la misma solicitud. Ambos cambios pueden ser válidos. La aplicación necesita una regla para combinarlos, rechazar uno o pedir que alguien decida.

Conviene acordar esas reglas antes de aceptar la función sin conexión. Una revisión útil deja una política breve de conflictos y una prueba repetible con dos dispositivos, con resultados comprensibles para el empleado y la oficina.

Empieza con un registro y los cambios que compiten

Elige un proceso real, pero utiliza registros ficticios en un entorno de pruebas. En una solicitud hipotética de servicio, enumera los campos que puede modificar el trabajador: notas de inspección, fotografías, hora de llegada, información de contacto y estado de finalización. Identifica cuáles también puede cambiar la oficina.

Anota la última versión que recibió cada dispositivo. Ese será el punto de partida compartido. La guía de Android sobre aplicaciones sin conexión explica que los cambios locales pueden entrar en conflicto con los datos de la red y que resolverlos suele requerir información de versiones. La política concreta sigue siendo una decisión del producto.

No trates toda la solicitud como un único valor indivisible salvo que esa sea la intención del negocio. Cambiar una nota no debería reemplazar automáticamente una asignación independiente realizada por la oficina.

Elige una regla para cada tipo de información

• Observaciones que se añaden: considera conservar notas separadas con autor y referencia del registro, en lugar de reemplazar un párrafo compartido.
• Datos modificables: si dos personas cambian el mismo teléfono, conserva ambas propuestas y envía la discrepancia a un responsable autorizado.
• Estados controlados: define transiciones válidas. Un cambio antiguo a “en curso” no debería reabrir silenciosamente una solicitud cancelada.
• Archivos adjuntos: distingue una descripción guardada de un archivo cargado correctamente. Muestra por separado las cargas pendientes o fallidas.

Una preferencia sencilla podría admitir que prevalezca la última escritura. Una aprobación de finalización puede necesitar una comprobación más estricta. Pregunta qué consecuencias tendría perder un valor anterior válido antes de elegir la alternativa técnica más fácil. Define quién resuelve las discrepancias y qué ocurre si esa persona no está disponible.

Haz comprensible el estado pendiente

Distingue “guardado en este dispositivo”, “pendiente de sincronizar”, “aceptado por el servidor” y “requiere revisión”. Una marca verde genérica puede hacer pensar al empleado que la oficina ya recibió información que solo existe en su teléfono.

Para el teléfono en disputa, un mensaje útil podría decir: “El contacto cambió mientras estabas sin conexión. Tu número propuesto está guardado para revisión”. Ofrece una acción clara sin mostrar información de otro cliente. El usuario no debería pulsar Guardar repetidamente para averiguar si existe el cambio.

Decide si puede continuar con otras tareas. Un desacuerdo sobre una nota no exige necesariamente bloquear todas las solicitudes, pero una autorización en disputa podría obligar a detener la acción afectada.

Ensaya la reconexión

1. Crea una solicitud ficticia y abre la misma versión inicial en dos dispositivos.
2. Desconecta el dispositivo de campo. Modifica localmente una nota y el teléfono de contacto.
3. En el dispositivo conectado, cambia ese teléfono y cancela la solicitud.
4. Reconecta el dispositivo de campo y observa el registro, los cambios pendientes y los mensajes en ambas pantallas.
5. Interrumpe la sincronización, vuelve a abrir la aplicación y reconecta otra vez. Comprueba que el cambio pendiente siga identificado y que las notas aceptadas no se multipliquen.
6. Resuelve el conflicto del teléfono con el rol autorizado y actualiza ambas vistas.

Incluye un dispositivo con el reloj incorrecto y un usuario cuyo acceso se haya retirado mientras estaba sin conexión. El resultado esperado debe proceder de la política acordada, no del cambio que llegue al final. Comprueba los permisos al sincronizar, además de hacerlo cuando se abre el formulario.

Acepta el proceso con evidencia

Guarda una ficha con las versiones iniciales, los cambios realizados, el resultado esperado, el observado, la versión de la aplicación y el responsable de la prueba. Verifica que la cancelación siga vigente, que la nota se conserve según la política, que la propuesta rechazada pueda revisarse y que ambas pantallas coincidan tras resolverla.

Pide a alguien de operaciones que explique cada estado visible sin ayuda del desarrollador. Si no puede saber si el cambio llegó a la oficina, la interfaz necesita ajustes. Estas comprobaciones describen un ejercicio hipotético, no resultados de un cliente de Dynelink.

Contacta con Dynelink para convertir un proceso móvil sin conexión en reglas de conflicto, mensajes y casos de aceptación concretos antes de la siguiente versión.