Sin conexión

Qué debe seguir funcionando

La tercera fila merece un aviso: si tu arranque valida el testigo contra el servidor y trata un fallo de red como sesión inválida, cada vez que el usuario abra la aplicación sin conexión le pedirás credenciales — que además no puede introducir, porque tampoco hay red. Es un fallo real y frecuente, y se evita distinguiendo «el servidor dice que no» de «no he podido preguntar».

Detectar el estado

Y aquí está la parte contraintuitiva: la mayoría de las formas de detectar conexión mienten.

La conclusión práctica: no consultes el estado, dedúcelo. El estado de conexión de tu aplicación es una consecuencia de cómo van tus peticiones, no un dato que haya que ir a buscar. Y el aviso del sistema sirve para una cosa útil: reintentar antes cuando dice que ha vuelto.

Encolar lo que no se puede hacer

Para lo que el usuario hace y hay que enviar:

• Aceptar la acción localmente y guardarla en una cola persistente. El usuario ve su cambio hecho; el envío es un detalle de implementación.
• Reintentar con espera creciente: unos segundos, luego más, hasta un máximo. Reintentar cada segundo con la red caída gasta batería para nada.
• Y que las acciones sean idempotentes o lleven un identificador único, para que reenviar una que sí llegó no la duplique. Es lo mismo del nivel 44.4.

Y decidir qué pasa si una acción encolada falla definitivamente cuando vuelve la red — porque el servidor la rechaza. Ése es el caso que hay que diseñar y que casi nadie diseña.

Comunicarlo

Tres reglas de trato al usuario:

• Un indicador discreto y permanente es mejor que un aviso por cada fallo. Una franja pequeña que diga «sin conexión» y desaparezca al volver.
• No bloquees lo que sí funciona. Un diálogo modal de error de red sobre una aplicación que podría seguir trabajando es la peor respuesta posible.
• Y distingue «sin conexión» de «el servidor da error», porque el usuario puede hacer algo con lo primero y nada con lo segundo.