Ma sauvegarde a perdu toutes les photos

J'ai conçu un bouton de sauvegarde pour un suivi d'humeur hors ligne.

Elle exportait les données dans un fichier JSON. Les utilisateurs pouvaient l'enregistrer et le transférer sur un nouveau téléphone. Cela semblait parfait.

Ensuite, j'ai changé l'ID du package de l'application. J'ai tenté une nouvelle installation sur un nouvel appareil et j'ai restauré la sauvegarde.

Les entrées textuelles sont revenues. Toutes les photos avaient disparu.

J'ai réalisé mon erreur. La sauvegarde n'était pas une véritable sauvegarde. Ce n'était qu'une liste de pointeurs vers des fichiers qui n'existaient plus.

L'application stockait les photos sur le disque. La base de données contenait le chemin du fichier.

Le chemin ressemblait à ceci : file:///data/user/0/com.example.app/files/entry_media/image.jpg

Lorsque j'exportais le JSON, je ne sauvegardais que ce chemin. Sur le même appareil, l'importation fonctionne car les fichiers sont toujours présents.

Sur un nouvel appareil, ces chemins ne pointent vers rien. L'utilisateur voit des miniatures brisées et pense que l'application a supprimé ses souvenirs.

Si votre export ne contient que des chemins de fichiers, vous n'avez pas une sauvegarde portable. Vous avez une sauvegarde qui ne fonctionne que sur la machine qui n'en a pas besoin.

Une véritable sauvegarde doit contenir les données réelles.

J'ai modifié le processus. Désormais, l'exportation lit chaque photo et la convertit en une chaîne Base64 à l'intérieur du JSON.

Cette approche présente des compromis : • La taille du fichier augmente d'environ 33 % . • Les bibliothèques volumineuses nécessitent plus de mémoire lors de l'exportation.

J'ai privilégié l'exactitude à la taille du fichier. Une sauvegarde volumineuse est utile. Une sauvegarde minuscule qui perd toutes les images ne sert à rien.

J'ai également modifié ma façon de gérer les importations pour garantir la rapidité et la sécurité :

  1. Écrire d'abord toutes les photos sur le disque du nouvel appareil. Cela se fait en dehors de la transaction de la base de données pour maintenir la rapidité.
  2. Exécuter une seule transaction de base de données pour lier les nouveaux chemins locaux aux entrées.

J'ai également conçu le système pour qu'il gère les erreurs en douceur. Si une photo est manquante ou illisible, l'application l'ignore et passe à la suivante. Une image corrompue ne devrait pas faire planter toute la restauration.

Leçons apprises :

  • Testez de la bonne manière. Exportez sur un appareil, effacez-le, puis importez sur une installation propre. Réimporter sur le même appareil masque les bugs.
  • Transportez les octets. Si les données doivent survivre à un changement d'appareil, déplacez les données réelles, pas l'adresse.

Source : https://dev.to/diven_rastdus_c5af27d68f3/my-offline-apps-backup-lost-every-photo-on-a-new-phone-3d36