Une perte de connexion ne devrait pas toujours signifier une perte de travail. Le fonctionnement hors connexion peut permettre d’accomplir une tâche sur un réseau peu fiable ou de conserver les données sur son appareil lorsque cela correspond à l’objectif du produit.
Commencez par la tâche qui doit continuer
« Fonctionne hors connexion » est trop vague pour constituer une exigence utile. Identifiez les actions précises qui doivent rester disponibles : créer un enregistrement, modifier une note, consulter un planning sauvegardé ou exporter des informations. Décidez ce qui peut attendre le retour de la connexion.
L’interface doit rendre ces limites compréhensibles. La personne doit savoir si une action a été enregistrée localement, envoyée vers un autre système ou nécessite encore son attention. Évitez de la laisser deviner à partir d’un indicateur de chargement.
Décidez où doivent se trouver les données
Le stockage local change les questions de maîtrise des données et de reprise. Existe-t-il une sauvegarde ? Que se passe-t-il si l’appareil est perdu ou remplacé ? La personne peut-elle exporter les données dans un format utilisable ailleurs ? Quelles copies restent après la désinstallation de l’application ?
Ces décisions doivent correspondre au comportement réel du produit et à sa notice de confidentialité. « Hors connexion » ne signifie pas automatiquement que toutes les fonctions évitent le réseau. Les cartes externes, le géocodage, les messages d’assistance ou les exports choisis par l’utilisateur peuvent créer des flux de données distincts.
Prévoyez la gestion des conflits
Si les données se synchronisent ensuite avec un serveur, deux appareils peuvent avoir modifié les mêmes informations. Le produit a besoin d’une règle pour choisir la version acceptée et d’un moyen clair de revenir d’un résultat inattendu.
Les doublons, les retards et les transferts interrompus méritent aussi de l’attention. Un appui répété ne doit pas créer silencieusement des opérations financières ou métier répétées. La solution précise dépend du modèle de données du produit et des systèmes concernés.
Expliquez les choix d’autorisation
Une fonction de localisation doit servir une action précise et se comporter de façon prévisible si l’autorisation est refusée. Une notification doit aider à comprendre une activité en cours. Les utilisateurs doivent comprendre les conséquences de leur choix sans connaître le fonctionnement interne d’Android.
Prévoyez le parcours avec autorisation refusée dans la conception. Si l’action reste possible manuellement, rendez ce chemin facile à trouver. Si la fonction ne peut pas fonctionner, expliquez la limite au moment pertinent.
Vérifiez les transitions
Ne vous limitez pas à un lancement sans réseau. Examinez la tâche lorsque la connexion disparaît pendant une action, revient après un délai ou change alors que l’application n’est plus visible. Pensez aux redémarrages de l’application, aux exports interrompus et à la correction d’un ancien enregistrement.
Les vérifications doivent suivre le parcours essentiel et ses risques. Une compilation réussie constitue un élément utile sur la compilation ; le comportement sur appareil exige ses propres preuves.