Preparar una aplicación de campo para cortes de conexión
Defina qué se guarda sin conexión y cómo trata la aplicación los trabajos modificados al volver a conectarse.
Defina el trabajo permitido sin conexión
Ante una entrada sin conexión, la aplicación debe distinguir el registro local de la transmisión correcta a la oficina. Decida para cada tarea si se permite leer, crear un borrador o cerrar de forma definitiva sin red. Una aplicación no necesita permitir toda escritura sin conexión para seguir siendo útil durante cortes.
La documentación de Android distingue estrategias de escritura y trata conflictos al reconectar. Importa el significado de negocio de los estados mostrados: un borrador local aún no es almacenamiento confirmado en el servidor.
Ejemplo: conservar la nota y aclarar la cancelación
El escenario es completamente ficticio. El dispositivo conoce el trabajo AU-64 en versión v7. El especialista introduce una nota de finalización sin red. Mientras tanto, planificación cancela el trabajo en el servidor y crea v8. En este ejemplo, una aclaración autorizada puede permitir guardar la nota como información adicional sin revertir la cancelación.
Situación | Estado local | Comportamiento esperado |
|---|---|---|
Introducir una nota sin conexión | Borrador en el dispositivo | Mostrar «Guardado solo en este dispositivo»; no anunciar finalización correcta. |
Cerrar y volver a abrir la aplicación | Borrador no enviado | En la prueba de reapertura prevista, el borrador está disponible y es editable. |
Vuelve la conexión | Borrador basado en un estado antiguo | Revisar el estado cambiado del servidor, mostrar el conflicto y conservar la nota; no sobrescribir automáticamente la cancelación. |
Aclaración autorizada y almacenamiento confirmado | Nota aceptada como información adicional | Mostrar la aceptación; el trabajo sigue cancelado. |
Es una lista de resultados esperados, no un informe de pruebas ejecutadas. Un icono de red o enviar una petición no basta para el último estado. Se necesita confirmar que el servidor almacenó realmente el cambio previsto.
Compruebe todo el camino de vuelta
Conserve la versión conocida para conciliar. Una hora posterior del dispositivo no decide por sí sola qué cambio es correcto para el negocio. Defina la regla de conflicto y el rol autorizado para resolver casos pendientes. Evite también que un reintento cree varias veces la misma nota.
Compruebe los permisos actuales en el servidor al reenviar. OWASP pide verificar permisos en cada petición. Un inicio de sesión anterior no autoriza automáticamente todo cambio posterior. Muestre claramente la falta de sesión o el guardado rechazado.
Acuerde también reglas de acceso local y comportamiento al cerrar sesión, cambiar de dispositivo o borrar datos de la aplicación. Incluya desconexión, reapertura, conflicto y reintento en el ensayo. Así se distingue el trabajo preparado del aceptado como definitivo.
Fuentes
Escrito por
- Katharina WeberRedactora de software y tecnologíaKatharina Weber se encarga en ASES de los artículos sobre desarrollo de software. Escribe sobre las cuestiones que se plantean las empresas al elegir software, desarrollar nuevas aplicaciones y modernizar sus sistemas existentes.
Seguir leyendo
Todos los artículos
Desarrollo de software con ASES
Software a medida, aplicaciones web y móviles