Préparer une application terrain aux coupures réseau
Définissez ce qui est conservé hors ligne et la manière de traiter les interventions modifiées lors de la reconnexion.
Définissez le travail autorisé hors ligne
Pour une saisie hors ligne, l’application doit distinguer l’enregistrement local de la transmission réussie au bureau. Décidez pour chaque tâche si lecture, brouillon ou clôture définitive sont possibles sans réseau. Une application n’a pas à autoriser toute écriture hors ligne pour rester utile en cas de coupure.
La documentation Android distingue les stratégies d’écriture et traite les conflits à la reconnexion. Le sens métier des états affichés est essentiel : un brouillon local n’est pas encore un enregistrement confirmé sur le serveur.
Exemple : conserver la note, clarifier l’annulation
Ce scénario est entièrement fictif. L’appareil connaît l’intervention AU-64 en version v7. Le spécialiste saisit une note de fin hors ligne. Entre-temps, la planification annule l’intervention sur le serveur, créant v8. Dans cet exemple, une clarification par une personne habilitée peut permettre d’ajouter la note sans revenir sur l’annulation de l’intervention.
Situation | État local | Comportement attendu |
|---|---|---|
Saisir une note hors ligne | Brouillon sur l’appareil | Afficher « Enregistré uniquement sur cet appareil » ; ne pas annoncer une clôture réussie. |
Fermer puis rouvrir l’application | Brouillon non envoyé | Dans le test de réouverture prévu, le brouillon reste disponible et modifiable. |
La connexion revient | Brouillon fondé sur un état ancien | Vérifier le nouvel état serveur, afficher le conflit et conserver la note ; ne pas écraser automatiquement l’annulation. |
Clarification habilitée et enregistrement serveur confirmé | Note ajoutée comme information complémentaire | Afficher la prise en compte ; l’intervention reste annulée. |
Il s’agit de résultats attendus, pas d’un compte rendu de tests effectués. Une icône réseau ou l’envoi d’une requête ne suffit pas pour le dernier état. Il faut confirmer que le serveur a réellement enregistré la modification prévue.
Vérifiez tout le retour vers le serveur
Conservez la version connue pour le rapprochement. Une heure d’appareil plus récente ne détermine pas seule quelle modification est correcte pour le métier. Définissez la règle de conflit et le rôle habilité à trancher les cas ouverts. Empêchez aussi qu’une nouvelle tentative crée plusieurs fois la même note.
Vérifiez les autorisations actuelles côté serveur au renvoi. OWASP demande de vérifier les droits à chaque requête. Une connexion antérieure n’autorise pas automatiquement toute modification ultérieure. Signalez clairement l’absence de connexion au compte ou un enregistrement refusé.
Convenez aussi des règles d’accès local et du comportement lors de la déconnexion du compte, du changement d’appareil ou de l’effacement des données. Incluez coupure, réouverture, conflit et nouvelle tentative dans l’essai. Cela distingue le travail préparé de celui enregistré définitivement.
Sources
Écrit par
- Katharina WeberRédactrice logiciels et technologieKatharina Weber s’occupe chez ASES des articles consacrés au développement logiciel. Elle traite des questions que se posent les entreprises lorsqu’elles choisissent un logiciel, développent de nouvelles applications ou modernisent leurs systèmes existants.
À lire aussi
Tous les articles
Développement logiciel avec ASES
Logiciels sur mesure, applications web et mobiles