a44fa0046a
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>
108 lines
4.6 KiB
Markdown
108 lines
4.6 KiB
Markdown
# 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é
|
||
|
||
1. **Modèle + catalogue en Foundation pur**, testés sur Linux — sans Mac.
|
||
2. **Endpoint serveur + éditeur web** (réutiliser `TileManager`).
|
||
3. **Push `WCSession`** et publication dans `ConnectivityManager`.
|
||
4. **Rendu `TabView`** dans `LiveWorkoutView`, avec le repli en dur.
|
||
5. 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.
|