Files

Sylvain Bettinelli a44fa0046a Cadrage des vues d'entraînement au choix, et point d'étape du 21/08

Le chantier « écrans configurables façon WorkOutDoors » est cadré, rien n'est
codé. docs/watch-training-screens.md fixe l'analyse pour qu'une session
ultérieure n'ait pas à la refaire.

Ce qui a été établi :

- LiveWorkoutView a cinq métriques ÉCRITES EN DUR ; il n'existe aucune notion
  de champ, de page ni de configuration. Tout est à créer.
- Neuf champs sont disponibles sans aucune collecte nouvelle (dont allure, D+,
  précision GPS, étape du fractionné) ; FC moyenne, temps en zone, cadence,
  puissance et laps demandent du travail.
- Décision : la configuration s'édite côté WEB (TileManager existe déjà) et
  voyage par WCSession — donc changer ses écrans ne demandera aucun rebuild
  Xcode, comme pour la routine.
- Le modèle et le catalogue sont du Foundation pur : écrits et testés sur
  Linux, seul le rendu TabView exige le Mac. Ne pas commencer par le rendu.
- Deux contraintes tenues dès la conception : 1 Hz maximum et page visible
  seule (le CPU suspend l'app et arrête le GPS sans erreur), et espacement des
  mises à jour en luminance réduite.

COWORK gagne le point d'étape du 21/08 : build passé, correctif finishRoute, et
surtout le fait que les 4 vérifications au poignet ne sont PAS encore faites —
les logs du jour ne montrent que l'app iPhone.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-21 09:53:46 +00:00

4.6 KiB

Raw Blame History

Vues d'entraînement au choix sur la montre — cadrage du 2026-08-21

Chantier non commencé. Ce document fixe ce qui a été établi le 21/08 pour qu'une session ultérieure reprenne sans refaire l'analyse.

Objectif : des écrans de séance configurables façon WorkOutDoors — plusieurs pages, des champs au choix, un profil par sport.

Point de départ réel (vérifié, pas supposé)

LiveWorkoutView (ios/App/CoachWatch/ContentView.swift, ~l.392-441) est un ScrollView avec cinq métriques écrites en dur : FC + zone, calories, distance, vitesse km/h, durée — puis l'état iPhone et les boutons Pause / Terminer.

Il n'existe aujourd'hui aucune notion de champ, de page, ni de configuration. Tout est à créer.

Les quatre briques manquantes

1. Un catalogue de champs

Chaque métrique doit devenir une valeur identifiable (id stable, libellé, unité, couleur, formatage) et non une ligne de vue. C'est ce qui permet à une page de déclarer ["hr", "pace", "distance"] sans que la vue connaisse les champs à l'avance.

Disponibles immédiatement, aucune collecte nouvelle :

Champ	Source
FC + zone	`WorkoutManager.heartRate` + `ConnectivityManager.zones`
Calories	`WorkoutManager.activeEnergyKcal`
Distance	`WorkoutManager.distanceMeters`
Vitesse km/h	`WorkoutManager.speedKmh`
Durée	`WorkoutManager.elapsedSec`
Allure min/km	dérivée de `speedKmh` (rien à collecter)
D+ / D−	`LocationTracker.ascentMeters` / `descentMeters`
Précision GPS	`LocationTracker.horizontalAccuracy`
Étape du fractionné	`IntervalEngine`, dès qu'il est câblé (cf. COWORK)

Demandent du travail :

FC moyenne et temps passé par zone : rien ne les accumule aujourd'hui.
Cadence : non collectée sur la montre.
Puissance de course (runningPower, watchOS 9+).
Tours / laps : aucun HKWorkoutEvent posé aujourd'hui.

2. Un modèle de page

WorkoutScreenConfig { sport: String, pages: [WorkoutPage] }
WorkoutPage        { id: String, fields: [String] }

Rendu par un TabView paginé (défilement vertical + Digital Crown, watchOS 10+). 1 à 4 champs par page selon la taille d'écran — l'Ultra en tient davantage.

💡 Ce modèle est du Foundation pur : il s'écrit et se teste sur Linux (./tests-linux/run.sh), comme IntervalEngine et ses 17 tests. Seul le rendu SwiftUI exigera Xcode.

3. Où l'utilisateur choisit — décision prise le 21/08

La configuration s'édite côté web et se pousse à la montre. Pas d'écran de réglages sur la montre.

TileManager (long-press, drag, toggle) existe déjà côté web : le paradigme est là, éprouvé sur les tuiles.
Même chemin de transport que la routine et les zones : WCSession → ConnectivityManager.
Conséquence décisive : changer ses écrans ne demanderait aucun rebuild Xcode. C'est exactement ce qui rend la routine agréable aujourd'hui — « les blocs voyagent avec l'état, rien n'est codé en dur côté watchOS ».
Un profil par sport (course ≠ vélo ≠ renfo), comme WorkOutDoors.

⚠️ Repli obligatoire : sans configuration reçue, la montre affiche les cinq champs actuels. Jamais d'écran vide — la config peut ne pas être arrivée, et une séance ne s'interrompt pas pour ça.

4. Deux contraintes watchOS, à tenir dès la conception

Le CPU tue le GPS (piège n°4 documenté dans LocationTracker.swift) : watchOS suspend une app trop gourmande et les positions s'arrêtent sans aucune erreur. ⇒ rafraîchissement 1 Hz maximum, et ne recalculer que la page visible, jamais les quatre. Ne pas utiliser un Timer de vue.
Écran always-on : en luminance réduite (@Environment(\.isLuminanceReduced)), espacer les mises à jour, sinon la batterie fond sur une sortie longue.

Effort estimé

Lot	Estimation
Châssis (catalogue + modèle + config web + push + `TabView`)	~1 jour
Chaque métrique dérivée supplémentaire	30 min à 2 h
Always-on propre	½ jour

Ordre proposé

Modèle + catalogue en Foundation pur, testés sur Linux — sans Mac.
Endpoint serveur + éditeur web (réutiliser TileManager).
Push WCSession et publication dans ConnectivityManager.
Rendu TabView dans LiveWorkoutView, avec le repli en dur.
Métriques accumulées (FC moyenne, temps en zone) — chacune isolément.

⚠️ Ne pas commencer par le rendu : c'est la seule partie qui exige le Mac, et elle ne se juge qu'une fois les données au bon format.

4.6 KiB Raw Blame History Unescape Escape