Process de migration des données locales, phase de tests, différences entre les builds release et debug, …
Nous vous parlions il y a quelques temps de la toute nouvelle version de l’application faite avec Flutter, qui était en développement et bientôt disponible au publique.
C’est chose faite ! Nous avons pour l’instant lancé une publication progressive sur le Play Store et l’App Store (bientôt complète) !
Le but de cet article est d’expliquer comment nous avons fait la transition de notre version native (Android et iOS) à la version cross-platform Flutter.
Nous voulions par exemple garder certaines préférences de l’utilisateur afin d’assurer une transition “fluide”. Nous utilisons le plugin “SharedPreferences” sur Flutter pour stocker ces préférences. Malheureusement, ce plugin n’utilise pas le même fichier que notre version native. Nous avons donc dû écrire du code natif (Kotlin et Swift), spécifique à notre besoin pour pouvoir récupérer les anciennes préférences et les stocker dans les nouvelles.
Le fait de devoir migrer ces données nous a notamment permis de découvrir un bug dû à ProGuard sur les versions natives qui, heureusement, n’a pas été bloquant sur la migration. En effet, le modèle concernant certaines préférences était obfusquées. Les clés du JSON sauvegardé n’étaient donc plus identiques (ex: “app_startup” devenait “a”). Nous avons contourné ce problème en utilisant les valeurs offusquées pour migrer les données.
Au tout début du développement, Flutter était à la version 1.2.1, au fur et à mesure nous mettions Flutter à jour, pour aujourd’hui être à la version 1.6.3. Cela a notamment permis de corriger certains bugs, comme par exemple les minutes des TimePicker qui n’était pas sélectionnées automatiquement.
Il n’y a rien de pire que de publier une mise à jour qui rend inutilisable une application. C’est pourquoi, différentes phases de tests ont eu lieu avant la publication afin de nous assurer que la migration des données fonctionne correctement et qu’aucun bug n’est présent. Il y a eu dans un premier temps des BETA toutes les deux semaines, restreintes à quelques personnes, puis des Release Candidate toutes les semaines, avec un nombre d’utilisateurs un peu plus important. Cela nous a permis d’identifier des bugs restants et certains points à améliorer, que ce soit niveau UI ou UX. En complément, nous avons mis en place différents tests unitaires ainsi que des tests d’intégration afin d’assurer la pérennité de l’application et éviter d’éventuelles régressions dans les futures mise à jour.
Malgré le changement majeur de technologie et l’ajout de nombreuses nouvelles fonctionnalités, tous ces mécanismes nous ont permis de lancer cette nouvelle version tant attendue avec sérénité. Cette base solide va nous permettre de consolider notre cycle de développement et de proposer de nouvelles fonctionnalités toujours plus rapidement !
