diff --git a/arbeitskacheln/23_flutter_begleitapp.md b/arbeitskacheln/23_flutter_begleitapp.md index 78dc5d7..f6ebb0d 100644 --- a/arbeitskacheln/23_flutter_begleitapp.md +++ b/arbeitskacheln/23_flutter_begleitapp.md @@ -51,7 +51,7 @@ Build-Host, kein Dauerbetrieb der App dort (App läuft auf Endgeräten). Store-Veröffentlichung (Sideload/interner Test-Build reicht für die Sondierung). - **DoD:** ✅ **Prototyp läuft, iterativ über den ursprünglichen Scope hinaus - gewachsen (2026-09-10, v0.1.0 → v0.5.0)** — Ergebnis noch nicht formal + gewachsen (2026-09-10, v0.1.0 → v0.6.0)** — Ergebnis noch nicht formal bewertet (keine Grundsatzentscheidung Ergänzung-vs-Ablösung-PWA getroffen), aber der Prototyp selbst ist weit über "ein Screen QR-Scan" hinausgewachsen: - **v0.1.0** — Basis-Scope: Login-Screen (JWT), QR-Scan-Screen gegen @@ -66,6 +66,23 @@ Build-Host, kein Dauerbetrieb der App dort (App läuft auf Endgeräten). Fortschrittsbalken + `open_filex`-Installationsprompt) statt externen Browser zu öffnen, dafür `REQUEST_INSTALL_PACKAGES`-Permission ergänzt. - **v0.5.0** — ℹ️-Icon im Scan-Screen zeigt Versions-/Build-Nummer per Dialog. + - **v0.6.0 (2026-09-10):** Zugangsdaten-Persistenz — `flutter_secure_storage` + (Android Keystore) statt der bis dahin GAR NICHT vorhandenen Token- + Persistenz (Token wurde nur als Konstruktor-Parameter durchgereicht, bei + jedem App-Neustart erneuter Login nötig). Token wird jetzt immer + gespeichert, Benutzername/Passwort optional per Checkbox auf dem + Login-Screen (Default an, abwählbar). App-Start überspringt den + Login-Screen bei vorhandenem Token; bei 401 (abgelaufener Token) beim + Objekt-Abruf versucht die App automatisch einen Re-Login mit den + gespeicherten Zugangsdaten, bevor sie zurück zum Login-Screen fällt. + Abmelden-Icon (Logout) ergänzt, löscht Token UND Zugangsdaten. + `flutter_secure_storage: ^9.2.2` kollidierte mit `package_info_plus` + (win32-Versionskonflikt) — auf `^11.1.0` gehoben. Stale + `test/widget_test.dart` (Default-Scaffold, referenzierte nicht mehr + existente `MyApp`-Klasse) durch echten Smoke-Test ersetzt, inkl. + MethodChannel-Mock für `flutter_secure_storage` im Widget-Test. + `flutter analyze` + `flutter test`: beide grün auf dem Build-Server vor + dem APK-Build. - Build- und Deploy-Weg etabliert: Build auf `192.168.1.236` (`flutter build apk --release --target-platform android-arm64`), APK+ `version.json` liegen auf `mabea.perlbach-edv.de` unter einem eigenen @@ -73,31 +90,36 @@ Build-Host, kein Dauerbetrieb der App dort (App läuft auf Endgeräten). — ein normaler Frontend-Deploy mit `rsync --delete` hätte den Ordner sonst gelöscht, real passiert und behoben). Download-Link im Portal nur für Administrator sichtbar (`AdminPage.tsx`). + - **2026-09-10:** `/opt/flutter-projects` auf `192.168.1.236` lag auf dem + Root-Volume — nach `/mnt/projekte/flutter` (eigener ZFS-Mount, mehr + Platz) verschoben, `/opt/flutter-projects` ist jetzt ein Symlink dorthin. + Bestehende Build-Befehle/Pfade bleiben unverändert gültig. - **Ergebnis der eigentlichen Sondierungsfrage (native Kamera vs. PWA) noch nicht ausgewertet** — dafür bräuchte es einen bewussten Vergleichstest unter Feldbedingungen, nicht nur "die App existiert und funktioniert". Diese Bewertung steht weiterhin aus, unabhängig vom App-Reifegrad. - - **Korrektur 2026-09-10:** entgegen der ursprünglichen Notiz hier liegt der - Code inzwischen DOCH im MABEA-Git-Repo (`flutter_app/`, getrackt) — der - separate Build-Server (`/opt/flutter-projects/mabea_scan_prototyp/`) wird - weiterhin fürs eigentliche APK-Bauen genutzt, ist aber nicht mehr die - einzige Quelle. Kein lokales Flutter/Dart-SDK in dieser Entwicklungs- - umgebung verfügbar — Änderungen hier werden per `ast`-artiger manueller - Code-Review statt automatisiertem `flutter analyze`/`flutter test` - verifiziert, echte CI-Prüfung fehlt für dieses Verzeichnis noch. - - **Zugangsdaten-Persistenz (Nutzer-Vorgabe 2026-09-10):** Login-Token + - optional Benutzername/Passwort jetzt über `flutter_secure_storage` - (verschlüsselter Android-Keystore/iOS-Keychain) statt der bisherigen - `shared_preferences` (Klartext) — löst zwei Dinge: (1) sicherer Speicher - für das ohnehin schon persistierte Token, (2) NEU: automatischer - Re-Login mit gespeicherten Zugangsdaten bei abgelaufenem Token (`ApiClient - .versucheAutoRelogin()`, greift transparent bei jeder 401-Antwort in - `request()`), damit die App auch nach Ablauf der 8h-Token-Gültigkeit ohne - erneute manuelle Eingabe weiterläuft, sobald wieder eine Verbindung - besteht. Speichern der Zugangsdaten ist eine bewusste Checkbox auf dem - Login-Screen (Default an, abwählbar) — kein stiller Zwang, Passwort auf - dem Gerät abzulegen. Ein Abwählen löscht auch bereits gespeicherte - Zugangsdaten (kein wirkungsloses nachträgliches Opt-out). + - Code lebt weiterhin auf dem separaten Build-Server + (`/opt/flutter-projects/mabea_scan_prototyp/`, Projektname + `mabea_scan_prototyp`, reine `lib/main.dart`), **nicht** im MABEA-Git-Repo + — dieser Kachel-Eintrag bleibt die einzige Dokumentation davon. + - **Verwechslungs-Notiz 2026-09-10:** im MABEA-Repo existiert zusätzlich ein + `flutter_app/`-Verzeichnis (Projektname `mabea_app`, mit Login-Screen/ + Offline-Queue/Kontroll-Screen) — das ist ein GETRENNTES, mit diesem + FLUT-001-Prototyp NICHT verbundenes Scaffold, vermutlich aus einer + früheren Session entstanden und nie an den Build-/Deploy-Prozess + angeschlossen. Nicht verwechseln: Änderungen an `flutter_app/` im Repo + haben KEINE Wirkung auf die tatsächlich gebaute/verteilte APK, die + weiterhin ausschließlich aus `mabea_scan_prototyp` auf dem Build-Server + entsteht. + - **Zugangsdaten-Persistenz (Nutzer-Vorgabe 2026-09-10):** `main.dart` hatte + bis dahin GAR KEINE Token-Persistenz (Token nur als Konstruktor-Parameter + von `LoginScreen` zu `ScanScreen` durchgereicht, bei jedem App-Neustart + erneuter Login nötig). Ergänzt: `flutter_secure_storage` (Android + Keystore/iOS Keychain) für Token + optional Benutzername/Passwort + (Checkbox auf dem Login-Screen, Default an, abwählbar — löscht dabei auch + bereits gespeicherte Zugangsdaten). Automatischer Re-Login bei + abgelaufenem Token (401 beim Objekt-Abruf), App-Start überspringt den + Login-Screen, wenn ein gültiger Token gespeichert ist. ## FLUT-002 — voller Kontroll-Workflow in der App (nicht beauftragt, nur Frage beantwortet)