Blomios
917777e18b
Regroupe l'état de travail en cours réalisé dans un même worktree sur plusieurs tickets/sprints (#85, #136, #145, #155-160, #162-164), mélangeant des tickets QA et inProgress. Ne constitue pas une feature terminée : commit de sauvegarde avant triage/split par ticket en branches feature/* dédiées. Exclut les dossiers d'environnement de build locaux et le heap dump parasite (.gitignore mis à jour). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.4 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||
|---|---|---|---|---|---|
| #127 | 9 |
|
1785216992076 |
#127 — Avis UX bref (2026-07-27)
Pas une question de conception : le comportement attendu ne fait aucun doute (l'utilisateur doit retrouver l'écran d'exécution exact, pas le launcher, après ré-allumage par mouvement de poignet). C'est un bug de cycle de vie Wear OS (probable absence de gestion Ambient Mode / activité tuée au lieu d'assombrie). Recommandation : implémenter le mode Ambient (écran assombri, app conservée) plutôt que laisser le système détruire l'activité ; au réveil, restituer l'état exact sans flash de chargement. Prêt pour implémentation directe (Architect/DevFrontend), aucun arbitrage UX supplémentaire nécessaire.
Cadrage technique Architect (2026-07-27)
Root cause confirmée dans le code réel : watch_app/android/app/src/main/kotlin/com/gametime/watch/MainActivity.kt est une FlutterActivity nue, sans aucune gestion Ambient (AmbientModeSupport/AmbientLifecycleObserver absents), et le manifest (watch_app/android/app/src/main/AndroidManifest.xml) ne déclare aucune capability ambient. Sans ambient mode, Wear OS détruit l'activité à l'extinction de l'écran plutôt que de la conserver assombrie ; au réveil (mouvement de poignet), le système relance le launcher/watch face au lieu de restaurer l'app — exactement le symptôme rapporté.
Contrat technique
- Dépendance :
androidx.wear:wear-ambientdanswatch_app/android/app/build.gradle.kts(actuellement seule dépendance wear présente :play-services-wearable:19.0.0, sans rapport avec l'ambient). MainActivitydoit implémenterAmbientModeSupport.AmbientCallbackProvideret appelerAmbientModeSupport.attach(this)dansonCreate— cela maintient l'activité en vie (assombrie) à l'extinction de l'écran, au lieu de la laisser être détruite par le système.- Aucune reconstruction d'état nécessaire au réveil : l'architecture existante s'y prête déjà —
WatchWearDataLayerAdapter._nativeChannel.connectionEventsdéclencheemitCurrentProjection()surisReachable/requestsResync, et le_ensureProjectionRefreshLooprepublie toutes les 2s (cf. audit #126 dans ce même lot d'audit). Tant que l'activité Flutter reste résidente pendant l'ambient (au lieu d'être tuée), l'état affiché au réveil est déjà à jour sans code de restauration supplémentaire à écrire. - Ne pas suivre la voie
ExerciseClient/mode "exercise" système (déjà écarté par le cadrage #124 pour la collecte capteurs, même raison ici : GameTime ne doit pas déclarer un second concept de session au niveau OS). - Vigilance batterie : en ambient, limiter les rebuilds au strict nécessaire (le
Timer.periodic(1s)déjà présent danswatch_session_screen.dartpour l'interpolation locale des chronos peut continuer sans changement — c'est unsetStateléger, pas un accès réseau/capteur).
Tests
Non testable en sandbox (cycle de vie Android natif, cohérent avec la contrainte déjà connue pour les autres services natifs watch, cf. gametime-watch-companion-implementation) — validation manuelle on-device requise : écran éteint puis rallumé par mouvement de poignet pendant une séance active, vérifier que l'app reste au premier plan sur l'écran d'exécution exact (pas de flash de chargement, pas de retour au launcher).
Prêt pour implémentation directe, aucun arbitrage supplémentaire nécessaire.