Hinweis beim Oeffnen, wenn eine neuere Fassung bereitliegt
Bisher gab es dafuer nur den schmalen Streifen der Hinweisleiste, der dauerhaft mitlaeuft und leicht uebersehen wird. Ein neuer Stand ist aber ein Ereignis und gehoert einmal nach vorn. Zwei Faelle, zwei Texte: liegt ein passendes OTA-Buendel bereit, traegt das Blatt den Knopf, der die App direkt erneuert (derselbe Weg wie in den Einstellungen). Fehlt eines, hat sich Natives geaendert - dann sagt es das und bietet keinen Knopf an, der nichts bewirken koennte. Nur nativ: im Browser und im Panel laedt jeder Aufruf den aktuellen Stand. Einmal je Fassung: die weggetippte Serverfassung wird gemerkt, erst eine andere bringt das Blatt zurueck. Die Entscheidung steckt in der reinen Funktion hinweisFaellig(), sechs Faelle getestet. 179/179 Tests gruen, tsc sauber.
This commit is contained in:
@@ -8690,3 +8690,40 @@ WebP sichern und noch einmal versuchen." — und auf der Platte entsteht **nicht
|
||||
|
||||
Verifiziert: 5/5 Backend-Tests (und ohne die Sperre nachweislich rot), `tsc --noEmit` sauber,
|
||||
173/173 App-Tests, Panel als Modul geparst, `audi_ha_test` auf `2026.9.3.3` sauber gestartet.
|
||||
|
||||
---
|
||||
|
||||
## AL. Popup beim Öffnen, wenn eine neuere Fassung bereitliegt (2026-09-03)
|
||||
|
||||
Wunsch des Besitzers: die App soll beim Start sagen, dass es eine neue Fassung gibt — so wie andere
|
||||
Apps es tun, nur ohne App Store. Es gab bisher nur den schmalen Streifen der `Hinweisleiste`
|
||||
("Diese App ist älter als der Server"), der dauerhaft mitläuft und deshalb leicht übersehen wird.
|
||||
|
||||
Neu: `companion-app/src/screens/Versionshinweis.tsx`, ein `ActionSheet`, eingehängt in `App.tsx`
|
||||
neben der bestehenden Leiste. Die beiden ersetzen einander **nicht** — ein neuer Stand ist ein
|
||||
Ereignis und gehört einmal nach vorn, danach übernimmt wieder der Streifen für den fortbestehenden
|
||||
Zustand.
|
||||
|
||||
**Zwei Fälle, zwei Texte, weil zwei verschiedene Dinge zu tun sind.** Liegt ein passendes OTA-Bündel
|
||||
bereit (`buendelPasst()`), kann die App sich selbst erneuern — dann trägt das Blatt den Knopf, der
|
||||
genau das auslöst, über denselben `buendelAnwenden()`-Weg wie der Knopf in den Einstellungen. Fehlt
|
||||
eines, hat sich Natives geändert und es hilft nur neu aufspielen; dann sagt das Blatt genau das und
|
||||
bietet keinen Knopf an, der nichts bewirken könnte.
|
||||
|
||||
**Nur nativ.** Im Browser und im HA-Panel lädt jeder Aufruf den aktuellen Stand — dort kann die App
|
||||
gar nicht veralten, dieselbe Begründung wie in `appVersion.ts`.
|
||||
|
||||
**Einmal je Fassung, nicht bei jedem Start.** Weggetippt wird die gesehene Serverfassung in
|
||||
`localStorage` gemerkt; erst eine *andere* bringt das Blatt zurück. Ohne das wäre es binnen einer
|
||||
Woche unsichtbar geworden. Die Entscheidung steckt in der reinen Funktion `hinweisFaellig()` und ist
|
||||
mit sechs Fällen getestet (`Versionshinweis.test.ts`) — ein Fehler dort hat genau zwei Ausprägungen,
|
||||
beide schlecht: eine Meldung bei jedem Start, die niemand mehr liest, oder ein Update, von dem nie
|
||||
jemand erfährt.
|
||||
|
||||
**Geerbte Ungenauigkeit, bewusst nicht angefasst:** der Vergleich ist reine Gleichheit (siehe
|
||||
`VERSIONIERUNG.md`), also meldet das Blatt auch dann "neue Version", wenn die App *neuer* ist als das
|
||||
Backend — etwa direkt nach einem Xcode-Bau, bevor die Integration nachgezogen wurde. Der
|
||||
Hinweisstreifen hat dieselbe Eigenschaft seit jeher. Sortierbar zu vergleichen wäre scheingenau; die
|
||||
Alternative wäre ein zweites Signal vom Backend, und das lohnt für diesen Randfall nicht.
|
||||
|
||||
Verifiziert: `tsc --noEmit` sauber, 179/179 Tests (6 neue).
|
||||
|
||||
Reference in New Issue
Block a user