¿Qué debe hacer una aplicación móvil cuando se pierde la conexión?
Planea qué guarda tu aplicación móvil sin conexión, qué necesita confirmación del servidor y cómo maneja reintentos, ediciones en conflicto y la pérdida de conexión.
Por Noe Guerrero III
Una aplicación móvil debe conservar el trabajo que pueda guardar de forma segura, explicar qué no ha llegado al servidor y darle al usuario una manera clara de terminar después. Algunas acciones pueden continuar sin conexión. Otras necesitan una respuesta en vivo antes de que la aplicación pueda decir honestamente que están completas.
Esa distinción pertenece al alcance del proyecto, antes de que alguien apruebe las pantallas.
Imagina una cuadrilla de servicio en Rio Grande Valley que usa una aplicación para registrar notas y fotos de los trabajos. Un trabajador pierde la conexión a la mitad de una actualización. ¿Debe seguir escribiendo? ¿Puede cerrar la aplicación? ¿La oficina verá la actualización dos veces cuando vuelva la conexión? Son preguntas de planeación para una aplicación hipotética, pero las respuestas forman una lista útil de aceptación para una real.
Decide qué acciones pueden esperar
Empieza por las tareas que la gente realmente necesita terminar. “Funciona sin conexión” es demasiado amplio para servir como requisito.
La guía de arquitectura de Android que prioriza el uso sin conexión distingue entre leer datos locales y escribir cambios, y describe estrategias distintas para cambios que requieren una conexión o que pueden guardarse para sincronizarse después. Admitir la lectura sin conexión no significa automáticamente que todas las acciones puedan ocurrir sin conexión.
Para nuestra aplicación de ejemplo de la cuadrilla, yo empezaría con este plan:
| Tarea | Sin conexión | Cuando vuelve la conexión |
|---|---|---|
| Ver un trabajo descargado anteriormente | Mostrar la copia guardada y cuándo se actualizó | Actualizarla y señalar cambios relevantes |
| Escribir una nota del trabajo | Guardar un borrador local y mostrar su estado pendiente | Enviarla y confirmar que el servidor la recibió |
| Agregar una foto | Mantenerla en la lista de cargas pendientes de la aplicación si el guardado local tiene éxito | Cargarla y mostrar cualquier falla restante |
| Confirmar una cita recién asignada | Permitir que el trabajador prepare una solicitud sin afirmar que está confirmada | Comprobar la disponibilidad actual y devolver el resultado real |
Son comportamientos propuestos, no funciones que todas las aplicaciones ya tienen. Acuérdalos con el desarrollador, incluido lo que pasa cuando el teléfono no puede guardar otro archivo. Si falla el almacenamiento local, la aplicación no debe mostrar un tranquilizador mensaje de “Guardado”.
Dale un significado preciso a “guardado”
Hay al menos dos lugares donde podría existir una actualización: en el dispositivo y en el servidor. La oficina no puede depender de una nota que todavía está únicamente en el teléfono de un trabajador.
Usa palabras que indiquen en qué estado se encuentra la persona. Por ejemplo:
Guardado en este dispositivo — pendiente de envío. La aplicación conservó el trabajo localmente, pero el equipo no lo ha recibido.
Recibido por el servidor. La transferencia terminó; cualquier paso separado de aprobación o procesamiento todavía necesita su propio estado.
Necesita tu atención. Explica el obstáculo y la siguiente acción, como volver a iniciar sesión o corregir un campo rechazado.
Haz que los elementos pendientes sean fáciles de encontrar después de que el usuario salga de la pantalla. Un aviso temporal no ayuda mucho cuando alguien revisa la aplicación una hora después.
Para una aplicación web, la guía del W3C sobre mensajes de estado explica cómo deben estar disponibles los cambios de estado para las tecnologías de asistencia sin requerir el foco. Incluye ese comportamiento en la revisión; un mensaje visible de sincronización por sí solo no te dice qué anuncia un lector de pantalla.
Haz seguros los reintentos antes de agregar un botón Reintentar
La falta de respuesta no demuestra que no pasó nada. El servidor podría aceptar una nota justo antes de que falle la conexión y dejar al teléfono sin saber el resultado. Enviar otra vez la misma acción como una solicitud completamente nueva podría crear un duplicado.
Pregunta al desarrollador cómo reconoce el servidor otro intento de la misma acción. El término técnico es idempotencia: repetir una operación no debe repetir su efecto previsto. Un identificador estable para la operación original puede ayudar al servidor a reconocer un reintento, siempre que el servidor realmente implemente ese comportamiento.
La documentación de la API de Stripe ofrece un ejemplo concreto de claves de idempotencia utilizadas para reintentar solicitudes de manera segura. Es un ejemplo de un contrato del servidor, no una función que se transfiere automáticamente a tu aplicación personalizada. Tu desarrollador necesita definir qué acciones la admiten y cuánto dura la protección contra duplicados.
Para la aplicación de la cuadrilla, un requisito útil de aceptación es: los intentos repetidos de enviar una nota producen un solo registro en la oficina. Prueba una respuesta perdida además de una interrupción completa. Desactivar el botón después de un toque no resuelve una solicitud cuyo resultado se desconoce.
Decide qué pasa cuando dos personas cambian el mismo trabajo
Supón que un trabajador edita la descripción de un trabajo sin conexión mientras la oficina cambia esa descripción en línea. Cuando el teléfono vuelve a conectarse, ¿qué versión debe permanecer?
No hay una respuesta que funcione para todos los campos. Mi preferencia para este ejemplo sería conservar las notas agregadas por separado como entradas separadas y señalar para revisión las ediciones en conflicto de una descripción existente. Reemplazar todo el registro del trabajo sin mostrar el conflicto haría difícil confiar en el resultado.
Escribe esa decisión en el alcance con palabras sencillas: conservar ambas versiones, elegir una autoridad acordada o pedir a una persona que resuelva la diferencia. El desarrollador puede elegir después un diseño de sincronización que respalde la regla. No dejes que una configuración predeterminada decida silenciosamente de quién desaparece el trabajo.
Decide también cómo reconocerá la gente la información antigua. Una ficha de trabajo descargada debe tener una hora visible de “última actualización”. Si una decisión específica requiere información actual, la aplicación debe explicar por qué la copia guardada no basta.
Prueba también el regreso de la conexión
Una demostración en modo avión es un comienzo. No muestra si la oficina finalmente recibe el resultado correcto.
Usa cuentas de prueba y registros desechables, y después recorre esta secuencia en los dispositivos que utilizará tu equipo:
Descarga un trabajo mientras tengas conexión. Desconéctate, vuelve a abrirlo y comprueba qué sigue disponible.
Agrega una nota y una foto. Cierra y vuelve a abrir la aplicación para comprobar si se conserva el guardado local prometido.
Vuelve a conectarte. Compara el estado del teléfono con el registro que realmente recibe la oficina.
Pide al desarrollador que simule una respuesta perdida del servidor y repite la acción. Revisa si hay duplicados.
Desconecta otra vez el primer dispositivo. Edita el mismo campo ahí y en un segundo dispositivo conectado; después vuelve a conectar el primero. Verifica la regla acordada para los conflictos.
Prueba una sesión vencida y una carga fallida. La aplicación debe explicar el siguiente paso y manejar el trabajo guardado según la política acordada.
Si el producto se ejecuta en un navegador, comprueba ahí su comportamiento específico de recuperación. MDN actualmente indica que la API de sincronización en segundo plano tiene disponibilidad limitada en navegadores. No prometas que todos los teléfonos enviarán el trabajo pendiente después de cerrar el navegador. Define y prueba la alternativa, como volver a abrir la aplicación para reanudar una transferencia.
Registra el resultado esperado junto al observado. Una captura de un mensaje de éxito no basta si el servidor tiene dos notas o ninguna foto.
Incluye las reglas sin conexión en la estimación
Antes de aprobar el desarrollo, pide las tareas admitidas sin conexión, el significado de cada estado de guardado, las reglas de reintento y conflicto y los dispositivos incluidos en las pruebas. Incluye una política para el trabajo almacenado localmente cuando alguien cierre sesión o cambie de cuenta. Eso le da al equipo algo concreto que construir y a ti algo concreto que revisar.
No necesitas que todas las funciones trabajen sin conexión. Necesitas que las tareas importantes se comporten de forma predecible y que la aplicación sea honesta cuando no pueda terminar.
Nuestra lista de verificación para lanzar una aplicación empresarial cubre la revisión general del lanzamiento. Si estás definiendo una herramienta interna nueva o una aplicación para clientes, nuestros servicios de desarrollo de software son un lugar para iniciar esa conversación.