Diseñar aplicaciones móviles ante rupturas de continuidad

Un producto móvil debe diseñarse para una conectividad cambiante, respuestas tardías y sesiones que terminan sin previo aviso. No se trata únicamente de casos límite técnicos. Estas condiciones determinan si una acción resulta comprensible, si el trabajo sin terminar se conserva y si la interfaz puede explicar qué ocurrirá después.

La pregunta de diseño útil no es simplemente si una aplicación funciona sin conexión. Hay que determinar qué partes siguen disponibles, qué estado puede conservar el dispositivo y cómo se concilian las acciones locales cuando se reanuda la comunicación. Responder pronto a estas preguntas genera un modelo de producto más claro para el diseño, la ingeniería y las pruebas.

Diseñar para la continuidad, no para una conexión perfecta

Una solicitud que depende de la conexión puede fallar antes de empezar, mientras se procesa o después de que el sistema remoto la haya aceptado. Es posible que la interfaz no sepa cuál de estos casos se ha producido. Por tanto, los equipos de producto necesitan una política explícita para la incertidumbre, en lugar de un mensaje de error genérico que trate todas las interrupciones de la misma manera.

La continuidad consiste en preservar el significado de la tarea en esas condiciones. Una vista de lectura podría seguir funcionando con material almacenado, mientras que un flujo de envío podría conservar un borrador completado sin afirmar que se ha entregado. El comportamiento adecuado depende de las consecuencias del retraso, la duplicación y la información obsoleta.

Trazar el estado antes de diseñar las pantallas

El estado es la información necesaria para representar el producto en un momento concreto. El estado local se guarda en el dispositivo, mientras que el estado remoto se mantiene en otro lugar mediante un servicio controlado. Trazar ambos permite ver qué información puede mostrarse de inmediato, cuál requiere verificación y cuál puede volverse incoherente.

• Identifica la información que puede seguir siendo útil cuando ya no esté actualizada.
• Marca las acciones que no deben repetirse sin comprobar su resultado remoto.
• Separa los datos introducidos sin terminar de los registros confirmados y de los detalles temporales de la interfaz.
• Define qué debe conservarse tras cerrar una sesión, reiniciar o sufrir un fallo en una solicitud.

Un mapa de estados debe describir tanto las transiciones como las pantallas. Para cada acción importante, hay que preguntarse qué muestra la interfaz antes de la solicitud, durante la espera, después de la confirmación y tras un fallo ambiguo. Esta secuencia permite detectar los estados de recuperación ausentes antes de que se conviertan en decisiones de implementación dispersas.

Hacer comprensibles las acciones demoradas

La latencia es el tiempo transcurrido entre el inicio de una acción y la recepción de una respuesta utilizable. Durante ese intervalo, la interfaz debe comunicar si los datos introducidos se han aceptado localmente, si la confirmación remota está pendiente y si otra acción generaría un duplicado. Un indicador de carga por sí solo rara vez responde a estas preguntas sobre el producto.

1. Confirma de inmediato la recepción de la acción sin dar a entender que ha finalizado de forma remota.
2. Conserva los datos introducidos pertinentes mientras el resultado siga siendo incierto.
3. Muestra un estado pendiente estable cuando la espera pueda prolongarse más allá de la pantalla actual.
4. Ofrece la opción de reintentar solo cuando repetir la operación esté definido como seguro.
5. Sustituye el estado temporal por un resultado confirmado o recuperable.

Una política de reintentos también necesita soporte técnico. La idempotencia es una propiedad que permite volver a enviar la misma operación sin aplicar su efecto previsto más de una vez. Cuando el sistema controlado pueda admitir esta propiedad, un identificador de solicitud idempotente puede reducir la ambigüedad. Cuando no pueda admitirla, es posible que la interfaz necesite realizar una verificación antes de reintentar.

Conciliar la realidad local y la remota

La sincronización es el proceso de llevar el estado local y el remoto a una forma acordada. No consiste en una única acción de actualización. Un producto debe decidir qué lado tiene autoridad sobre cada campo, cómo se representan los cambios pendientes y qué sucede cuando ambos lados han cambiado durante la interrupción.

La resolución de conflictos es la política utilizada cuando los cambios contrapuestos no pueden combinarse automáticamente. Una preferencia inocua podría adoptar el último valor aceptado, mientras que el contenido editado podría requerir conservar ambas copias o solicitar una elección. La política debe ajustarse al significado de los datos, en lugar de aplicar una sola regla en todos los casos.

Conservar deliberadamente el trabajo interrumpido

Una sesión interrumpida puede dejar datos valiosos en la memoria, en el almacenamiento persistente del dispositivo o en ninguna parte. La persistencia consiste en almacenar información para que siga disponible después de que termine el proceso actual. Los equipos deben decidir qué merece conservarse, durante cuánto tiempo sigue siendo pertinente y cuándo su restauración podría inducir a error.

• Guarda los borradores en puntos significativos, no solo en el envío final.
• Distingue los datos restaurados de la información que ya se ha aceptado de forma remota.
• Evita conservar material sensible, salvo que sus condiciones de almacenamiento sean adecuadas.
• Elimina el trabajo pendiente obsoleto después de una confirmación clara o de un descarte deliberado.

La restauración debe incluir el contexto, no solo los valores sin procesar. Si una aplicación vuelve a abrir un formulario, quizá también deba explicar si los archivos adjuntos siguen disponibles, si es necesario comprobar la información dependiente y si un envío anterior continúa pendiente. Estas condiciones deben verificarse para la plataforma y el diseño de almacenamiento reales.

Probar recorridos en condiciones cambiantes

Una pantalla puede parecer correcta mientras el recorrido más amplio pierde datos o repite una acción. Por tanto, las pruebas deben variar la conectividad y los límites de la sesión durante una tarea. El objetivo es examinar las transiciones de estado del producto, incluidos los momentos en que la interfaz y el sistema remoto conocen temporalmente información diferente.

1. Inicia una acción con conexión y, después, interrumpe la comunicación antes de la confirmación.
2. Cierra la sesión mientras haya trabajo pendiente y vuelve a abrirla.
3. Repite una acción después de una respuesta ambigua y examina el resultado.
4. Cambia la misma información de forma local y remota antes de la sincronización.
5. Restaura la conectividad cuando el trabajo en cola ya no sea válido.

Estos escenarios resultan más útiles cuando los resultados esperados se documentan antes de la implementación. Para cada uno, hay que especificar qué se almacena, qué puede afirmar la interfaz, qué puede reintentarse y cómo vuelve el producto a un estado estable. La ejecución en segundo plano y el comportamiento del almacenamiento específicos de cada plataforma deben seguir siendo elementos que verificar, no suposiciones.

Elegir la política de fallos antes que el acabado

Un marco práctico comienza con cuatro decisiones: qué tareas siguen siendo útiles sin conexión, qué acciones requieren confirmación remota, qué trabajo local debe sobrevivir a una interrupción y cómo se concilian los estados en conflicto. Estas decisiones establecen los límites dentro de los cuales los detalles de la interfaz pueden diseñarse con honestidad.

La revisión final debe seguir recorridos completos, en lugar de pantallas de éxito aisladas. Sigue cada acción importante durante la espera, la desconexión, el cierre, la restauración, el reintento y el conflicto. Si cada transición tiene una persona responsable, un estado visible y una vía de recuperación, el uso sin conexión y la latencia se convierten en condiciones definidas del producto, en lugar de excepciones sin especificar.