Séparez les copies remplaçables du travail original
Imaginons un grossiste fictif en éclairage à Budapest préparant une application pour ses commerciaux. Catalogue public de produits téléchargé, devis client inachevé et préférence linguistique ont des rôles distincts. Le catalogue peut être téléchargé à nouveau. Un devis uniquement local peut contenir du travail inexistant ailleurs. Une préférence facilite l’usage.
Les recommandations d’Android sur la couche de données séparent les sources et définissent une source de référence. Traduisez cela en inventaire métier : propriétaire de chaque élément, emplacement de la donnée faisant autorité et existence d’une autre copie. Demandez au développeur d’identifier explicitement le travail conservé uniquement sur l’appareil.
Donnez une durée utile aux informations téléchargées
Pour le grossiste, convenez des détails nécessaires pendant les visites et du volume d’images à conserver. Garder toutes les images peut améliorer les consultations suivantes, mais occupe davantage de stockage. Un cache réduit exige plus de téléchargements. Choisissez une limite et un ordre de suppression adaptés au travail commercial.
Définissez quand actualiser les informations produit et quelles décisions exigent des données serveur à jour. L’équipe pourrait autoriser la consultation d’une fiche de lampe téléchargée, mais imposer une vérification actuelle avant confirmation de disponibilité. Inscrivez cette limite dans le cahier des charges. Supprimer une ancienne image ne doit pas effacer un devis inachevé.
Adaptez le nettoyage au compte et à l’élément
Firebase indique que le cache persistant web de Firestore n’est pas automatiquement vidé entre les sessions. Cet exemple propre au web justifie de vérifier le stockage de chaque plateforme, sans supposer qu’une fin de session efface les informations enregistrées.
Convenez séparément des effets de la déconnexion sur les catalogues publics copiés, les données clients propres au compte et les devis non envoyés. Avant toute suppression, précisez les pertes pour le commercial et les possibilités de récupération ailleurs. Tout travail inachevé conservé doit rester rattaché au compte initial. Le prochain utilisateur connecté ne doit pouvoir ni le voir ni l’envoyer.
Distinguez suppression d’une copie locale et suppression du dossier de l’entreprise sur le serveur. Formulez clairement ces actions et démontrez-les avec des comptes fictifs. Un seul libellé Effacer les données laisse trop de place aux interprétations.
Budgétez les changements des données stockées
La documentation Android de Room avertit qu’un repli sur une migration destructive peut supprimer les données des tables sans chemin de migration disponible. Demandez si la mise à jour proposée considère toutes les données locales comme jetables ou préserve le travail original.
Supposons l’ajout d’un champ nom de la pièce aux brouillons de devis. Convenez de l’affichage des anciens brouillons après mise à jour, notamment lorsque ce champ n’a jamais été renseigné. Reconstruire le catalogue téléchargé peut être acceptable ; perdre silencieusement le brouillon du commercial relève d’une autre décision métier. Faites démontrer les deux résultats avec un brouillon test d’une version antérieure.
Validez un bref accord sur le stockage
Conservez ces décisions avec les spécifications fonctionnelles et un responsable des changements futurs. L’accord doit préciser ce qui subsiste après chaque événement, avant les choix techniques.
- Listez séparément copies téléchargées, brouillons originaux et préférences.
- Précisez propriétaire, donnée faisant autorité et moyen de récupération disponible.
- Fixez limites de téléchargement, règles d’actualisation et ordre de suppression du cache.
- Simulez déconnexion et changement de compte avec du travail inachevé.
- Testez une mise à jour avec des données remplaçables et un ancien brouillon uniquement local.