Le fil rouge de ces corrections : des replis silencieux. Une exception
rattrapee, une image absente, un fichier local jamais rattache — rien ne
plantait, mais rien ne marchait non plus, et aucun message ne le disait.
Splash et loader
- assets/splash et assets/loader ne contenaient que des PNG 1x1
transparents. errorBuilder ne se declenche pas : le fichier est valide,
juste vide. Logo et loader etaient donc invisibles PARTOUT, splash comme
ecrans de chargement. assets/loader est supprime, kLoaderAsset avec.
- Le splash natif etait blanc (launch_background en @android:color/white,
theme Light) puis l'app basculait en sombre. Fond unifie sur #111111,
cote natif comme Dart, avec values-v31 : Android 12+ ignore
windowBackground et repart sur le theme sans ces attributs.
- Le loader et l'image principale viennent maintenant du manager
(Applications -> Mobile). InstanceImages les garde sur le device : le
splash s'affiche avant tout appel API, il ne peut lire qu'un cache.
Alimente au boot depuis instanceGetDetail, qui porte deja les
ApplicationInstances — aucun appel supplementaire.
- Ouvrir une section montrait une page blanche avec un loader au milieu.
SlideFromRightRoute devient non opaque et SectionPage garde un fond
transparent tant que la section n'est pas prete : le visiteur garde sous
les yeux l'ecran d'ou il vient.
Hors ligne
- L'audio d'un article ne repartait jamais du MP3 local : audioFile
n'etait jamais renseigne, le lecteur retombait toujours sur l'URL.
- L'image de titre d'un article passait par NetworkImage, donc une croix
rouge des que le reseau manque, alors que le fichier est sur le device.
- L'accueil ne gardait en base que order/gridSpan : une visite jamais
telechargee disparaissait de la grille hors ligne. La visite entiere est
desormais mise en cache, et une visite injoignable reste affichee,
ternie et non ouvrable, plutot qu'absente.
- L'etat reseau datait du premier chargement et n'etait jamais remesure.
WidgetsBindingObserver etait declare mais jamais enregistre : aucun
rappel n'arrivait. L'accueil se recharge au retour dans l'app et
remesure avant de refuser l'ouverture d'une visite.
Divers
- Le futur de getSectionDetail etait construit dans future:, donc relance
a chaque rebuild — chaque rotation d'ecran refaisait l'appel reseau.
- ImageCustomProvider listait le repertoire d'une visite non telechargee :
exception a chaque construction de chaque image, pour finir de toute
facon sur le reseau.
- Scanner un QR d'une autre visite empilait les ConfigurationPage.
pushAndRemoveUntil : une visite est une destination de premier niveau.
- Le scanner arrive sur l'accueil, en pastille de verre comme les autres
actions de cet ecran. ScannerBouton prend size et transparent, et garde
son apparence d'origine ailleurs.
- Le titre d'un article n'etait pas centre : customStylesBuilder ne
s'applique qu'aux elements, et un titre sans balise n'en a aucun.
- Le lecteur audio replie ne lancait pas la lecture au premier appui, il
ouvrait le panneau. Il lit, puis ouvre. En lecture auto il reste replie.
- Le dialogue de telechargement faisait la hauteur de l'ecran : un Center
prend toute la hauteur maximale que lui donne un AlertDialog.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ce commit boucle le travail en cours sur la branche (assistant lunettes Meta,
passage du lecteur audio flottant a un onglet, ajustements scanner / liste de
configurations / telechargement) et y ajoute le badge de version.
Le badge, en bas de la feuille Parametres, affiche « flavor . version . commit ».
Un APK pose sur une tablette du terrain n'etait rattachable a aucun commit
precis : la version du pubspec ne bougeait pas d'un build a l'autre et rien
n'indiquait le flavor reellement installe. kGitSha suit le meme schema que
kApiBaseUrl, injecte par --dart-define, et kFlavor expose le flavor deja calcule.
package_info_plus etait deja une dependance transitive ; il devient direct,
puisqu'il est desormais importe.
/!\ Un --dart-define modifie n'est PAS pris en compte sans `flutter clean` sur
ce projet : verifie a la sentinelle, le SHA restait absent de libapp.so tant que
le cache Dart n'etait pas vide. Un build de release destine au terrain doit donc
toujours passer par un clean, sinon le badge affiche le SHA du build precedent.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La prémisse du lot était périmée. Trois documents annonçaient un
`flutter build apk` en échec côté Gradle/NDK, revérifié le 11/08 : les
trois flavors (dev, mdlf, fortsaintheribert) construisent, exit 0.
La config Android de ce repo était déjà à niveau — Gradle 8.11.1, AGP
8.9.0, -Xmx4096M, enableJetifier=false, aucun forçage androidx.lifecycle.
Les dix crans du 12/08 ont amené tablet-app jusqu'à mymuseum ; il n'y
avait pas la même migration à refaire ici. Le repo qui a servi de modèle
au portage K2 n'avait pas de raison d'être en retard d'outillage sur
celui qui le copiait.
Restaient les deux avertissements du build :
- NDK 27.0.12077973 -> 28.2.13676358, réclamé nommément par speech_to_text
- Kotlin 2.1.0 -> 2.3.10, sous le seuil 2.2.20 annoncé comme rupture par
Flutter. C'est la version de tablet-app : un alignement, pas une
version neuve introduite dans le projet.
Six builds — les trois flavors avant, les trois après. APK de 382 à 349 Mo.
Non pris volontairement : Kotlin réglé, Flutter réclame Gradle 8.14.0 et
AGP 8.11.1. C'est du terrain neuf pour les deux repos (tablet-app est à
8.11.1/8.9.1, mêmes avertissements latents) — le faire ici seul désaligne
les deux apps au lieu de les aligner. À faire d'un bloc sur les deux, ou
pas du tout.
Débloque D0 / test-plan §21 sur device, donc la mesure des bugs offline
D2-D5 et la confirmation du volet visiteur de D1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
