# Mobile App Restart (KMP) – Plan

Ziel: Eine **wirklich native** Mobile App (Android + iOS) mit **gemeinsamem Shared-Code** (Kotlin Multiplatform) und nativer UI.

Wichtiger Befund aus dem Repo: Die Auth ist **token-basiert (JWT)**, nicht Cookie-Session:
- `POST /api/auth/login` → `{ token }`
- Token wird bei Requests als Header `authcode: <token>` (Web-Standard) gesendet.
- Alternativ akzeptiert das Backend auch `Authorization: Bearer <token>` (Middleware).

## 1) Ziel-Architektur

### Module
- `mobile-app/shared/`
  - Domain/UseCases
  - API Client (Ktor)
  - Token Storage Abstraktion
  - Repositories
  - (später) Offline Cache
- `mobile-app/androidApp/` (oder bestehend: `composeApp` Android target)
  - Android UI (Jetpack Compose)
  - Android-spezifische Implementierungen (Secure storage, logging)
- `mobile-app/iosApp/`
  - iOS UI (SwiftUI) **oder** Compose Multiplatform UI
  - iOS-spezifische Implementierungen (Keychain, logging)

### UI-Strategie (2 sinnvolle Wege)
**A) Native UI je Plattform (Compose + SwiftUI)** (empfohlen für “wirklich native”)
- Shared: Logik/Netzwerk/State
- Android UI: Compose
- iOS UI: SwiftUI

**B) Gemeinsame UI mit Compose Multiplatform**
- Shared: UI + Logik
- Android/iOS nutzen die gleiche Compose-UI
- Weniger UI-Duplizierung, aber iOS “native feel” erfordert extra Pflege.

Empfehlung: Start mit **A**, da iOS dann maximal “native” ist; Shared bleibt groß genug, dass der doppelte UI-Aufwand beherrschbar bleibt.

## 2) Networking & Auth (Shared)

### Endpunkte (v1)
- Login: `POST /api/auth/login`
- Logout: `POST /api/auth/logout` (Token wird serverseitig invalidiert)
- Session Check: `GET /api/session/status` (auth erforderlich)

### Request-Regeln
- Header `authcode` auf **jedem** API Request setzen (wie Web).
- Globales Handling:
  - 401 → Token löschen, UI zurück zu Login.
  - Timeouts/Netzfehler → kein Auto-Logout.

### Implementierungsvorschlag
- Ktor Client:
  - `ContentNegotiation` + Kotlinx Serialization
  - `HttpTimeout`
  - DefaultRequest: `url(baseUrl)`, `header("authcode", token)`
- Token Storage:
  - Interface im `shared`
  - Android: EncryptedSharedPreferences oder Jetpack Security
  - iOS: Keychain

Aktueller Stand im Repo:
- `TokenStorage` + Android/iOS Implementierungen liegen in `mobile-app/shared/src/**/de/tt_tagebuch/shared/state/*TokenStorage*`.

## 3) Parity-Plan (“wie Webapp”, aber in Wellen)
“Komplett wie Webapp” wird als **Feature-Parität** umgesetzt, nicht als Big-Bang.

### Release 1 (Must-have)
- Auth: Login/Logout/Passwort reset (wenn benötigt)
- Club-Kontext: Verein wählen, Berechtigungen/Access Requests
- Tagebuch: Liste/Detail/CRUD + Filter/Suche
- Mitglieder: Liste/Detail + Filter/Suche

### Parity-Wellen
Welle A: Training Stats, Personal Settings  
Welle B: Approvals, Club Settings, Member Transfer  
Welle C: Team Management, Permissions, Logs  
Welle D: Orders + Billing  
Welle E: Tournaments + Schedule + CourtDrawingTool + PDF/Exports + Upload/Crop  

Jede Welle: API-Gaps schließen → UI → Tests → Release.

## 4) i18n-Strategie (Single Source of Truth)
Quelle bleibt `frontend/src/i18n/locales/de.json`.

Option 1 (empfohlen): **Generator**
- Script generiert:
  - `shared`-Resources (Keys/Strings) oder
  - Android `strings.xml` + iOS `.strings`
- Vorteil: Keys bleiben identisch, kein Drift.

Option 2: JSON direkt in App laden
- Einfacher Start, aber weniger “platform idiomatic”.

## 5) Repo/Build Setup
- Gradle Wrapper (`mobile-app/gradlew`) für reproduzierbare Builds.
  - CI (später):
    - Android: `./gradlew :androidApp:assembleDebug`
    - iOS: Xcode build (oder Fastlane)

## 6) Definition of Done (pro Feature)
- API Requests laufen stabil (Retry/Timeout ok)
- 401 führt zuverlässig zu Logout
- i18n Keys vorhanden (Generator/Checks)
- Android: Emulator + Device Smoke
- iOS: Simulator Smoke
