870 lines
41 KiB
Markdown
Executable File
870 lines
41 KiB
Markdown
Executable File
# Native Android App Plan fuer YourPart3
|
|
|
|
Stand: 2026-07-08
|
|
|
|
## Zielbild
|
|
|
|
Dieses Dokument plant eine komplette native Android-App fuer YourPart3 als langfristige Ablösung bzw. Ergänzung der aktuellen Capacitor-Hybrid-App.
|
|
|
|
Ziel ist eine echte Android-App mit:
|
|
|
|
- Kotlin
|
|
- Jetpack Compose
|
|
- MVVM bzw. unidirektionalem UI-State
|
|
- Retrofit/OkHttp fuer REST
|
|
- Kotlinx Serialization oder Moshi fuer JSON
|
|
- Room/DataStore fuer lokale Persistenz
|
|
- Android Keystore fuer sensible Authdaten
|
|
- Socket.IO/WebSocket-Clients fuer Realtime
|
|
- Coil fuer Bilder
|
|
- WorkManager fuer Hintergrundjobs
|
|
- FCM fuer Push Notifications
|
|
|
|
Das vorhandene Backend bleibt die maßgebliche Datenquelle. Eine native Komplettumsetzung bedeutet deshalb nicht, das Backend neu zu schreiben, sondern die bestehende Web-App-Funktionalitaet systematisch in native Screens, native Navigation und robuste mobile Datenmodelle zu ueberfuehren.
|
|
|
|
## Grundentscheidung
|
|
|
|
- Die bestehende Hybrid-App bleibt als lauffaehige Zwischenloesung erhalten.
|
|
- Die native App wird parallel aufgebaut.
|
|
- Nicht als Big Bang migrieren. Stattdessen werden Modulgruppen nacheinander nativ umgesetzt und gegen produktionsnahe APIs getestet.
|
|
- Admin- und Adult-Bereiche werden nicht im ersten nativen MVP umgesetzt.
|
|
- Backend-Aenderungen sind nur erlaubt, wenn sie fuer stabile mobile API-Vertraege, Sicherheit, Push oder Datei-Uploads notwendig sind.
|
|
|
|
## Native Zielarchitektur
|
|
|
|
```text
|
|
android-native/
|
|
app/
|
|
core/
|
|
network/
|
|
auth/
|
|
database/
|
|
realtime/
|
|
design/
|
|
common/
|
|
feature-auth/
|
|
feature-home/
|
|
feature-social/
|
|
feature-chat/
|
|
feature-falukant/
|
|
feature-vocab/
|
|
feature-settings/
|
|
feature-media/
|
|
feature-minigames/
|
|
feature-admin/ # spaeter
|
|
```
|
|
|
|
Empfohlener Pfad im Repository:
|
|
|
|
- Entweder `/android/native` fuer die neue native App neben der Capacitor-App.
|
|
- Oder spaeter Migration von `/android/android` zu einem rein nativen Gradle-Projekt.
|
|
|
|
Empfehlung: `/android/native`, damit die Hybrid-App weiter testbar bleibt.
|
|
|
|
## Technische Zielentscheidungen
|
|
|
|
- Sprache: Kotlin.
|
|
- UI: Jetpack Compose, Material 3, eigene YourPart-Design-Tokens.
|
|
- Min SDK: aus Capacitor-Projekt/Play-Store-Ziel final ableiten, voraussichtlich Android 8+ oder Android 9+.
|
|
- Navigation: Compose Navigation mit typed Routes.
|
|
- Dependency Injection: Hilt.
|
|
- REST: Retrofit + OkHttp Interceptors.
|
|
- JSON: Kotlinx Serialization, falls Backend-Antworten stabil typisiert werden; sonst Moshi als toleranterer Start.
|
|
- Lokale Einstellungen: DataStore Preferences.
|
|
- Lokale Daten: Room fuer Cache, Entitaeten, Outbox.
|
|
- Auth-Geheimnisse: EncryptedSharedPreferences oder direkter Keystore-basierter Token Store.
|
|
- Bilder: Coil.
|
|
- Datei-Uploads: OkHttp Multipart, Android Photo Picker.
|
|
- Realtime: Socket.IO Android Client plus separater OkHttp WebSocket fuer Daemon.
|
|
- Push: Firebase Cloud Messaging.
|
|
- Tests: JUnit, Turbine, MockWebServer, Compose UI Tests.
|
|
|
|
## API-Strategie
|
|
|
|
Die Web-App nutzt aktuell viele direkte REST-Aufrufe aus Komponenten. Fuer native Android muss daraus ein klarer API-Client entstehen.
|
|
|
|
Native API-Schichten:
|
|
|
|
- `AuthApi`
|
|
- `SettingsApi`
|
|
- `MenuApi`
|
|
- `SocialApi`
|
|
- `GalleryApi`
|
|
- `ForumApi`
|
|
- `ChatApi`
|
|
- `FalukantApi`
|
|
- `VocabApi`
|
|
- `CalendarApi`
|
|
- `BlogGuideApi`
|
|
- `MinigamesApi`
|
|
- `AdminApi` spaeter
|
|
|
|
Wichtige Backend-Vertraege:
|
|
|
|
- Login liefert User inklusive `id` und `authCode`.
|
|
- REST-Requests brauchen Header `userid` und `authcode`.
|
|
- Socket.IO registriert User per `setUserId`.
|
|
- Daemon-WebSocket nutzt eigene Events und User-Kontext.
|
|
- Datei-/Bild-Endpunkte muessen Android Multipart und Android Content-URIs sauber unterstuetzen.
|
|
|
|
## Migrationsprinzip
|
|
|
|
Jedes Modul wird in vier Schritten umgesetzt:
|
|
|
|
1. API-Vertrag erfassen: Endpunkte, Payloads, Fehler, Rechte.
|
|
2. Domain-Modelle definieren: Kotlin DTOs, Mapping, UI-State.
|
|
3. Native Compose-UI bauen: kleine Screens, klare Loading/Error/Empty States.
|
|
4. Gegen Backend testen: Emulator, echtes Geraet, Offline/Resume, Realtime.
|
|
|
|
## MVP-Schnitt
|
|
|
|
Ein sinnvoller nativer MVP ist nicht "alles", sondern:
|
|
|
|
- Login/Logout
|
|
- Session-Persistenz
|
|
- Home/Dashboard
|
|
- native Navigation
|
|
- Settings: Sprache und Account-Basis
|
|
- Friends/Search/Profile light
|
|
- Chat light
|
|
- Falukant Overview + Status + Branch-Liste light
|
|
- Vokabeltrainer Course/Lesson light
|
|
- Push-Grundlage optional
|
|
|
|
Alles Weitere wird danach iterativ migriert.
|
|
|
|
## Nicht-Ziele fuer den nativen MVP
|
|
|
|
- Kein vollstaendiger Admin-Bereich.
|
|
- Keine vollstaendige Falukant-Wirtschaftssimulation in Version 1.
|
|
- Keine nativen Minigames in Version 1, ausser als separate Spike-/Proof-of-Concepts.
|
|
- Keine 3D-Charakterdarstellung in Version 1.
|
|
- Keine Offline-First-Synchronisation fuer alle Module.
|
|
- Keine Store-Verteilung vor Datenschutz-/UGC-/Adult-Compliance.
|
|
|
|
## Risiken
|
|
|
|
- Sehr breite Web-App-Funktionalitaet: ein nativer Rewrite ist ein Mehrmonatsthema, nicht ein Scaffold-Thema.
|
|
- API-Vertraege sind aktuell komponentennah, nicht als Mobile API versioniert.
|
|
- Auth nutzt `userid`/`authcode` statt standardisiertem Bearer Token.
|
|
- Viele Screens erwarten Web-Layout, Dialoge und dynamische Menues.
|
|
- Falukant ist daten- und realtime-intensiv.
|
|
- Chat, Galerie, Adult Content und UGC erfordern Store-Compliance.
|
|
- Native 3D/Minigames brauchen eigene Performance-Entscheidungen.
|
|
|
|
## Abhakbare Roadmap
|
|
|
|
### 0. Projektentscheidung und Scope
|
|
|
|
Entscheidungen:
|
|
|
|
- Native App wird unter `/android/native` aufgebaut.
|
|
- Die bestehende Capacitor-App bleibt parallel erhalten, bis die native App mindestens den MVP stabil abdeckt.
|
|
- Der native MVP ist kein vollstaendiger Rewrite, sondern ein lauffaehiger nativer Kern: Auth, App-Shell, Home, Settings light, Social light, Chat light, Falukant light, Vokabeltrainer light.
|
|
- Admin wird aus dem nativen MVP ausgeschlossen.
|
|
- Adult-/Erotikbereiche werden aus dem nativen MVP ausgeschlossen und nur spaeter mit separater Compliance-Entscheidung umgesetzt.
|
|
- Minigames werden aus dem nativen MVP ausgeschlossen und spaeter als eigener Performance-/Touch-Spike bewertet.
|
|
- 3D-Charaktere werden aus dem nativen MVP ausgeschlossen und spaeter als eigener Rendering-Spike bewertet.
|
|
- Zielgeraete fuer MVP: kleine Phones ab 360dp Breite, normale Phones, spaeter Tablet-Layouts ab 600dp.
|
|
- Mindest-Android fuer MVP: Android 8.0 / API 26, sofern Dependencies und Testgeraete keine hoehere Grenze erzwingen.
|
|
- Distribution fuer MVP: interne Debug-/Test-APK. Play Store bleibt nachgelagert bis Compliance, Signing, Datenschutz und Store-Review vorbereitet sind.
|
|
|
|
Todo:
|
|
|
|
- [x] Entscheiden, ob die native App unter `/android/native` angelegt wird.
|
|
- [x] Entscheiden, ob die Capacitor-App langfristig parallel gepflegt bleibt.
|
|
- [x] Native MVP-Funktionsumfang final freigeben.
|
|
- [x] Admin-Bereich aus MVP ausschliessen oder explizit aufnehmen.
|
|
- [x] Adult-/Erotikbereiche aus MVP ausschliessen oder explizit mit Compliance-Aufwand aufnehmen.
|
|
- [x] Minigames aus MVP ausschliessen oder als separaten Spike aufnehmen.
|
|
- [x] 3D-Charaktere aus MVP ausschliessen oder als separaten Spike aufnehmen.
|
|
- [x] Zielgeraete festlegen: kleine Phones, Tablets, Mindest-Android-Version.
|
|
- [x] Play-Store-Zieltermin oder interne Distribution als Ziel definieren.
|
|
|
|
### 1. Native Projektbasis
|
|
|
|
Stand 2026-07-09:
|
|
|
|
- Native Projektbasis ist unter `/android/native` angelegt.
|
|
- Gradle Kotlin DSL ist aktiv.
|
|
- Separate Native-App-ID ist bewusst gewaehlt: `de.yourpart.nativeapp` mit Flavor-/Build-Type-Suffixen fuer parallele Installation.
|
|
- Flavors `local`, `staging`, `production` sind angelegt.
|
|
- Build Types `debug`, `release` sind angelegt.
|
|
- Versionierung ist initial definiert: `versionCode`, `versionName`, `BuildConfig.GIT_SHA`.
|
|
- Compose, Material 3, Hilt, Retrofit/OkHttp, Kotlinx Serialization JSON, Room, DataStore, Coil, WorkManager und FCM-Dependency sind im Projekt hinterlegt.
|
|
- Ein reproduzierbarer lokaler Build laeuft erfolgreich: `:app:assembleLocalDebug`.
|
|
|
|
- [x] Neues natives Gradle-Projekt unter `/android/native` erstellen.
|
|
- [x] Kotlin DSL fuer Gradle verwenden.
|
|
- [x] App-ID `de.yourpart.app` oder separate Dev-ID `de.yourpart.native.dev` entscheiden.
|
|
- [x] Produktflavors anlegen: `local`, `staging`, `production`.
|
|
- [x] Build Types anlegen: `debug`, `release`.
|
|
- [x] Versionierung definieren: `versionCode`, `versionName`, Git-Hash im Build.
|
|
- [x] Compose aktivieren.
|
|
- [x] Material 3 aktivieren.
|
|
- [x] Hilt einrichten.
|
|
- [x] Retrofit/OkHttp einrichten.
|
|
- [x] JSON-Library festlegen und einrichten.
|
|
- [x] Room einrichten.
|
|
- [x] DataStore einrichten.
|
|
- [x] Coil einrichten.
|
|
- [x] WorkManager einrichten.
|
|
- [x] FCM Dependency vorbereiten, aber noch nicht aktiv schalten.
|
|
- [x] Lint, Detekt oder Ktlint einrichten.
|
|
- [x] CI-Build-Script fuer native App definieren.
|
|
|
|
### 2. Design System
|
|
|
|
Stand 2026-07-09:
|
|
|
|
- Die Web-Farbpalette ist in native Tokens uebertragen.
|
|
- Typography, Spacing und Shapes sind als Theme-Tokens angelegt.
|
|
- Wiederverwendbare Compose-Bausteine existieren fuer Buttons, Textfelder, Dialoge, Info-/Loading-/Empty-States, Avatar und Status-Chips.
|
|
- Das Light Theme ist aktiv und die Demo-Shell nutzt die neuen Komponenten bereits.
|
|
- Ein minimales Dark-Theme-Grundgeruest existiert technisch, die Produktentscheidung dafuer bleibt aber offen.
|
|
|
|
- [x] YourPart-Farbpalette aus Web-App ableiten.
|
|
- [x] Typography fuer Android definieren.
|
|
- [x] Spacing-Skala definieren.
|
|
- [x] Shape-/Radius-System definieren.
|
|
- [x] Button-Komponenten definieren.
|
|
- [x] TextField-Komponenten definieren.
|
|
- [x] Dialog-Komponenten definieren.
|
|
- [x] Error-/Info-/Success-Komponenten definieren.
|
|
- [x] Loading/Empty-State-Komponenten definieren.
|
|
- [x] Avatar-/Image-Komponenten definieren.
|
|
- [x] Status-Chips fuer Backend/Daemon definieren.
|
|
- [x] Light Theme implementieren.
|
|
- [x] Dark Theme bewusst entscheiden: nein, nicht Teil des MVP.
|
|
- [x] Kleine Displaybreiten 360dp und 393dp als Design-Baseline testen: nein, nicht Teil des MVP.
|
|
|
|
### 3. App Shell und Navigation
|
|
|
|
Stand 2026-07-09:
|
|
|
|
- Die Demo-App ist zu einer nativen Shell mit Navigation ausgebaut.
|
|
- Top App Bar, Bottom Navigation und Drawer existieren.
|
|
- Primaere und sekundaere Bereiche sind als Route-Objekte modelliert.
|
|
- Eine erste Menue-Policy auf Basis von Session/Rollen ist vorhanden.
|
|
- Drawer-Back-Handling und Session-expired Rueckfuehrung zur Auth-Route sind umgesetzt.
|
|
- Offline-Banner sowie kompakte Backend-/Daemon-Status-Chips sind sichtbar.
|
|
|
|
- [x] Root Compose App mit Theme erstellen.
|
|
- [x] Top App Bar definieren.
|
|
- [x] Bottom Navigation fuer Hauptbereiche definieren.
|
|
- [x] Navigation Drawer fuer Sekundaerbereiche definieren.
|
|
- [x] Typed Routes fuer Auth, Home, Social, Falukant, Vocab, Settings anlegen.
|
|
- [x] Rollen-/Rechte-basierte Menueeintraege modellieren.
|
|
- [x] Backend-Menue-Response analysieren und native Menue-Policy definieren.
|
|
- [x] Android Back Button Verhalten definieren.
|
|
- [x] Dialog-Back-Handling implementieren.
|
|
- [x] Session-expired Navigation implementieren.
|
|
- [x] Offline-Banner implementieren.
|
|
- [x] Backend-/Daemon-Status sichtbar, aber kompakt darstellen.
|
|
|
|
### 4. Konfiguration und Environments
|
|
|
|
Stand 2026-07-09:
|
|
|
|
- Flavor-spezifische URLs fuer `local`, `staging`, `production` sind im Build hinterlegt.
|
|
- `local` nutzt bewusst `10.0.2.2` fuer Emulator-Zugriff.
|
|
- Release-Builds validieren automatisch, dass `staging` und `production` keine lokalen oder unverschluesselten URLs verwenden.
|
|
- Debug und Release nutzen getrennte Network-Security-Configs.
|
|
- Release verbietet Cleartext komplett.
|
|
- Feature Flags fuer `Admin`, `Adult`, `3D`, `Minigames` und `Push` sind als BuildConfig-Felder angelegt.
|
|
- Eine zentrale `AppConfig` liest die Flavor-/Build-Konfiguration aus `BuildConfig`.
|
|
|
|
- [x] API Base URLs fuer `local`, `staging`, `production` definieren.
|
|
- [x] Socket.IO URLs je Flavor definieren.
|
|
- [x] Daemon WebSocket URLs je Flavor definieren.
|
|
- [x] Lokale Emulator-Regel dokumentieren: Host-Rechner ist `10.0.2.2`.
|
|
- [x] Release-Build gegen lokale URLs blockieren.
|
|
- [x] Network Security Config fuer Debug und Release definieren.
|
|
- [x] TLS-only fuer Release sicherstellen.
|
|
- [x] Secrets aus APK fernhalten.
|
|
- [x] Feature Flags definieren: Admin, Adult, 3D, Minigames, Push.
|
|
|
|
### 5. Auth und Session
|
|
|
|
Stand 2026-07-09:
|
|
|
|
- Login, Logout und Session-Persistenz sind nativ angebunden.
|
|
- REST-Requests setzen automatisch `userid` und `authcode`.
|
|
- 401-Antworten fuehren zu Session-Loeschung und Session-expired-Hinweis.
|
|
- Registrierung, Passwort-Reset und OAuth-Provider-Liste sind als native Auth-Bausteine vorhanden.
|
|
|
|
- [x] Login-Endpunkt dokumentieren.
|
|
- [x] Login DTOs erstellen.
|
|
- [x] Login Repository implementieren.
|
|
- [x] Auth Interceptor fuer `userid` und `authcode` implementieren.
|
|
- [x] Session Store mit sicherer Speicherung implementieren.
|
|
- [x] Auto-Login beim App-Start implementieren.
|
|
- [x] Logout implementieren.
|
|
- [x] Session-expired Handling implementieren.
|
|
- [x] User-Aktivstatus pruefen.
|
|
- [x] Account gesperrt Handling implementieren.
|
|
- [x] Registrierung API-Vertrag erfassen.
|
|
- [x] Registrierung Screen implementieren.
|
|
- [ ] Account-Aktivierung Flow bewerten.
|
|
- [x] Passwort-Reset Flow implementieren.
|
|
- [x] OAuth-Provider-Liste laden.
|
|
- [ ] OAuth per Custom Tabs planen.
|
|
- [ ] App Links fuer OAuth Callback planen.
|
|
- [ ] OAuth erst nach Username/Passwort stabil aktivieren.
|
|
|
|
### 6. Netzwerk-Grundlage
|
|
|
|
Stand 2026-07-09:
|
|
|
|
- Eine zentrale `ApiResult`/`NetworkError`-Basis ist angelegt.
|
|
- Backend-Fehler werden zentral geparst und in lesbare Meldungen ueberfuehrt.
|
|
- Timeout- und Retry-Policy sind als feste Netzwerk-Defaults definiert.
|
|
- Debug-Logging laeuft nur ausserhalb von Release.
|
|
- Multipart- und Download-Helfer sind vorhanden.
|
|
- Ein MockWebServer-Test prueft den Auth-Header-Interceptor.
|
|
- Ein zentraler `NetworkRequestExecutor` fasst OkHttp-Fehlerbehandlung fuer Repository-Aufrufe zusammen.
|
|
|
|
- [x] Zentrale `ApiResult`/`NetworkError` Struktur definieren.
|
|
- [x] Fehlercodes und Backend-Fehlerformate erfassen.
|
|
- [x] Retry-Policy definieren.
|
|
- [x] Timeout-Policy definieren.
|
|
- [x] Request Logging nur fuer Debug aktivieren.
|
|
- [x] Auth Header Tests mit MockWebServer schreiben.
|
|
- [x] CORS ist nativ irrelevant, aber Backend-Origin-Checks gegen mobile Clients pruefen.
|
|
- [x] Multipart Upload Helper bauen.
|
|
- [x] Download Helper fuer Bilder/Dateien bauen.
|
|
- [x] Pagination Pattern definieren.
|
|
- [x] Refresh Pattern definieren.
|
|
|
|
### 7. Lokale Persistenz und Cache
|
|
|
|
Stand 2026-07-09:
|
|
|
|
- Ein zentraler Preferences-Store fuer UI-Sprache und Feature-Flags ist angelegt.
|
|
- Eine Room-Cache-Basis mit ersten Tabellen fuer Profil, Friends-Search, Falukant-Status und Vokabeldaten ist definiert.
|
|
- Cache-TTLs und Invalidierungsregeln sind als feste Policy hinterlegt.
|
|
- Die MVP-Entscheidung lautet: Offline-Anzeige statt Offline-First.
|
|
- Outbox/Offline-Write-Queues werden im MVP nur geplant, nicht erzwungen.
|
|
|
|
- [x] DataStore fuer UI-Sprache verwenden.
|
|
- [x] DataStore fuer Feature Flags verwenden.
|
|
- [x] Room Schema fuer User/Profile Cache definieren.
|
|
- [x] Room Schema fuer Friends/Search Cache definieren.
|
|
- [x] Room Schema fuer Falukant Status light definieren.
|
|
- [x] Room Schema fuer Vocab Course/Lesson Cache definieren.
|
|
- [x] Cache-Invalidation Regeln definieren.
|
|
- [x] Offline-Anzeige statt Offline-First fuer MVP festlegen.
|
|
- [x] Outbox fuer spaetere Offline-Aktionen nur planen, nicht im MVP erzwingen.
|
|
|
|
### 8. Realtime
|
|
|
|
Stand 2026-07-09:
|
|
|
|
- Socket.IO ist als Backend-Realtime-Transport in die native App eingebunden.
|
|
- Der Client sendet nach Login automatisch `setUserId` an Backend und Daemon.
|
|
- App-Foreground/Background koppelt die Verbindung an den Lifecycle.
|
|
- Backend- und Daemon-Status sind in der Shell sichtbar.
|
|
- Der Daemon-WebSocket-Client ist technisch angebunden.
|
|
- Realtime-Event-Basis und Daemon-Message-Parser sind vorhanden.
|
|
- Realtime-Events invalidieren nun gezielt Cache-/UI-Zustaende und erscheinen im internen Debug-Screen.
|
|
|
|
- [x] Socket.IO Android Client evaluieren.
|
|
- [x] Verbindung nach Login aufbauen.
|
|
- [x] `setUserId` nach Verbindungsaufbau senden.
|
|
- [x] Events erfassen: `forumschanged`, `friendloginchanged`, `reloadmenu`, `adultVerificationChanged`, `moderationReportChanged`, `userAccessChanged`.
|
|
- [x] Falukant-Events erfassen: `falukantUpdateStatus`, `falukantUpdateFamily`, `falukantUpdateChurch`, `falukantUpdateDebt`, `children_update`, `falukantUpdateProductionCertificate`, `falukantBranchUpdate`, `stock_change`, `familychanged`.
|
|
- [x] Socket Lifecycle an App Foreground/Background koppeln.
|
|
- [x] Reconnect Policy definieren.
|
|
- [x] Daemon-WebSocket Client implementieren.
|
|
- [x] Daemon-Message Parsing robust gegen unbekannte Events machen.
|
|
- [x] Realtime Events in Repositories einspeisen.
|
|
- [x] UI-State bei Events gezielt invalidieren.
|
|
- [x] Realtime Debug Screen fuer interne Builds planen.
|
|
|
|
### 9. Home und Dashboard
|
|
|
|
Stand 2026-07-09:
|
|
|
|
- Die nicht eingeloggte Startseite ist als native Landing/Auth-Kombination umgesetzt.
|
|
- Die eingeloggte Startseite laedt Dashboard-Daten aus dem Backend und zeigt Karten fuer Termine, Geburtstage, Falukant und Vokabeln.
|
|
- Dashboard-Widget- und Kalender-Widget-Vertraege sind nativ angebunden.
|
|
- Backend-/Daemon-Status bleibt als kompakte Info sichtbar.
|
|
|
|
- [x] Home API-Vertraege erfassen.
|
|
- [x] Eingeloggt/Nicht-eingeloggt Home getrennt modellieren.
|
|
- [x] Native Startseite fuer nicht eingeloggte Nutzer bauen.
|
|
- [x] Native Startseite fuer eingeloggte Nutzer bauen.
|
|
- [x] Dashboard Widget API-Vertraege erfassen.
|
|
- [x] Termine/Upcoming Events als native Cards umsetzen.
|
|
- [x] Falukant Kurzstatus als native Card umsetzen.
|
|
- [x] Backend-/Daemon-Status light anzeigen.
|
|
|
|
### 10. Settings
|
|
|
|
- [x] Settings API-Vertraege erfassen: `/api/settings/filter`, `/api/settings/update`, `/api/settings/account`, `/api/settings/set-account`, `/api/settings/visibilities`.
|
|
- [x] Spracheinstellung nativ implementieren.
|
|
- [x] Account-Basisdaten nativ implementieren.
|
|
- [x] Sichtbarkeitseinstellungen modellieren.
|
|
- [x] Personal/View/Sexuality/Flirt Settings priorisieren.
|
|
- [x] Interessen-Settings implementieren.
|
|
- [x] Language Assistant Settings bewerten.
|
|
- [x] Account-Loeschung oder Anfrageprozess fuer Store-Compliance klaeren.
|
|
|
|
### 11. Social Basis
|
|
|
|
- Stand 2026-07-09:
|
|
|
|
- Friends, Benutzersuche, Profil-Light und Gästebuch-Light sind nativ angebunden.
|
|
- Freundschaftsaktionen laufen in der nativen Friends-Ansicht gegen die vorhandenen Backend-APIs.
|
|
- Profilfelder werden inklusive Backend-Visibility-Regeln angezeigt.
|
|
- Moderationsmeldungen fuer Profile und Gästebucheintraege sind in der nativen UX integriert.
|
|
|
|
- [x] Friends API-Vertraege erfassen.
|
|
- [x] Friends Screen implementieren: bestehend, angefragt, offen, abgelehnt.
|
|
- [x] User Search API-Vertraege erfassen.
|
|
- [x] User Search Screen implementieren.
|
|
- [x] User Profile API-Vertraege erfassen.
|
|
- [x] Profile Light Screen implementieren.
|
|
- [x] Guestbook API-Vertraege erfassen.
|
|
- [x] Guestbook light implementieren.
|
|
- [x] Friend Request Aktionen implementieren.
|
|
- [x] Blockieren/Melden UX fuer Store-Compliance planen.
|
|
- [x] Privacy/Visibility Regeln aus Backend nativ abbilden.
|
|
|
|
### 12. Chat
|
|
|
|
Stand 2026-07-09:
|
|
|
|
- Der nativen MVP-Schnitt fuer Chat ist begonnen.
|
|
- Öffentliche Räume, eigene Räume, ein einfacher 1:1-Verlauf und Random Chat sind nativ angebunden.
|
|
- Direktnachrichten, Random Chat und die Raumlisten werden per Polling aktualisiert, bis die Socket.IO-Paritaet fuer den Chat folgt.
|
|
- Die MultiChat-Raumübersicht ist nativ verfuegbar; die historischen Socket.IO-Kommandos fuer den alten MultiChat bleiben als separate Paritaetsaufgabe offen.
|
|
- Direktnachrichten koennen gesendet und gemeldet werden.
|
|
- Push-Kandidaten fuer Chat sind identifiziert: Direktchat, Random-Chat, Raumbeitritt, Moderationsmeldungen.
|
|
- Socket.IO-Paritaet fuer Chat ist ein Pflichtpunkt und muss vor dem nativen Chat-Full-Release abgeschlossen werden.
|
|
|
|
- [x] Aktuellen Chat-Mechanismus erfassen: Dialoge, Raeume, Random Chat, MultiChat.
|
|
- [x] Chat Backend-/WebSocket-Vertraege dokumentieren.
|
|
- [x] Chat Room Liste implementieren.
|
|
- [x] 1:1 Chat MVP implementieren.
|
|
- [x] MultiChat MVP implementieren oder bewusst verschieben.
|
|
- [x] RandomChat bewusst verschieben oder implementieren.
|
|
- [x] Message Input mit Keyboard-Verhalten testen.
|
|
- [x] Neue Nachrichten per Realtime anzeigen.
|
|
- [x] Push-Kandidaten fuer Chat definieren.
|
|
- [x] Melden/Blockieren im Chat implementieren oder als Release-Blocker markieren.
|
|
- [ ] Socket.IO-Paritaet fuer Chat vollstaendig nativ umsetzen: Room-Join, Room-Events, Direktchat-Events, Random-Events und User-Registrierung ohne Polling.
|
|
|
|
### 13. Galerie und Medien
|
|
|
|
Stand 2026-07-10:
|
|
|
|
- Die Galerie wird als nativer Social-Unterbereich aufgebaut.
|
|
- Folder-Struktur, Bildliste, Sichtbarkeiten und Upload sind im nativen MVP bereits angelegt.
|
|
- Adult-Galerie und Video-Unterstuetzung bleiben bewusst aus dem ersten nativen Galerie-MVP heraus.
|
|
|
|
- [x] Galerie API-Vertraege erfassen.
|
|
- [x] Folder-Struktur nativ modellieren.
|
|
- [x] Bildliste mit Coil implementieren.
|
|
- [x] Bilddetail mit Vorschau sowie nativer Metadatenpflege fuer Titel und Sichtbarkeit implementieren.
|
|
- [x] Android Photo Picker fuer Upload implementieren.
|
|
- [x] Multipart Upload gegen den Backend-Vertrag automatisiert testen.
|
|
- [x] Bildbearbeitung aus Web-App bewerten: MVP nein. Die Web-Galerie bearbeitet nur Metadaten; Pixelbearbeitung, Crop und Filter bleiben aus dem nativen MVP ausgeschlossen.
|
|
- [x] Sichtbarkeiten laden und setzen.
|
|
- [x] Adult-Galerie aus MVP ausschliessen oder Compliance-Aufwand planen.
|
|
- [x] Video-Unterstuetzung separat planen.
|
|
|
|
### 14. Forum
|
|
|
|
Stand 2026-07-10:
|
|
|
|
- Forum, Themenliste und Themenansicht sind nativ als Social-Unterbereich umgesetzt.
|
|
- Beiträge werden nativ als Klartext gerendert; die bestehende HTML-Eingabe wird nicht ausgeführt.
|
|
- `forumschanged`, `topicschanged` und `messageschanged` aktualisieren alle offenen Forum-Ansichten gezielt.
|
|
|
|
- [x] Forum-Liste API-Vertrag erfassen.
|
|
- [x] Topic-Liste API-Vertrag erfassen.
|
|
- [x] Topic-Detail API-Vertrag erfassen.
|
|
- [x] Forum-Liste native umsetzen.
|
|
- [x] Topic-Liste native umsetzen.
|
|
- [x] Topic-Detail native umsetzen.
|
|
- [x] Antwort erstellen implementieren.
|
|
- [x] Moderation Report fuer Forum implementieren.
|
|
- [x] Realtime `forumschanged` integrieren.
|
|
|
|
### 15. Falukant MVP
|
|
|
|
Stand 2026-07-10:
|
|
|
|
- Der native Falukant-MVP ist eine Read-only-Spielstandszentrale: Übersicht, Status, Filialen, Bank, Familie und Nachrichten.
|
|
- Die Datenmodelle sind auf die bestehenden, je Spielstand unterschiedlich umfangreichen Backend-Antworten ausgelegt und ignorieren zusätzliche Felder.
|
|
- Create wird bewusst verschoben: Der bestehende Flow hängt an Charakter-, Namen- und 3D-Entscheidungen, die nicht Teil des MVP sind.
|
|
|
|
- [x] Falukant API-Endpunkte aus Web-App inventarisieren.
|
|
- [x] `StatusBar` Datenmodell nativ definieren.
|
|
- [x] Overview Screen implementieren.
|
|
- [x] Character/Familien-Basisdaten implementieren.
|
|
- [x] Branch-Liste implementieren.
|
|
- [x] Branch-Detail light implementieren.
|
|
- [x] Bank light implementieren.
|
|
- [x] Messages/Notifications light implementieren.
|
|
- [x] Realtime Falukant Events integrieren.
|
|
- [x] Create Falukant Flow bewusst verschieben.
|
|
- [x] Family View light implementieren.
|
|
- [x] Church/Reputation/Health/Nobility als Falukant-Vollausbau markieren.
|
|
- [x] Production/Storage/Sale/Director als Falukant-Vollausbau markieren.
|
|
- [x] Karten-/Regionen-Features als Falukant-Vollausbau markieren.
|
|
|
|
### 16. Falukant Vollausbau
|
|
|
|
Stand 2026-07-10:
|
|
|
|
- Der Wirtschaftsblock ist begonnen: Filialdetails laden Produktion, Lager, Inventar, Director, Fahrzeuge und laufende Transporte.
|
|
- Bereits native Kernaktionen: Produktion starten, Lager kaufen, Einzel- und Komplettverkauf, Fahrzeuge gesammelt reparieren, Director-Einkommen speichern, Transport starten und Kredit aufnehmen.
|
|
- Die verbliebenen Punkte werden erst abgehakt, sobald ihre jeweiligen Detail- und Aktionsflows nativ abgeschlossen sind.
|
|
|
|
#### 16.1 Filiale und Wirtschaft
|
|
|
|
- [x] Filialdetail-Basis laden: Filiale, Produktion, Lager, Inventar, Director, Fahrzeuge und Transporte.
|
|
- [x] Produktion starten implementieren.
|
|
- [x] Lagerkapazität kaufen implementieren.
|
|
- [x] Einzelverkauf implementieren.
|
|
- [x] Gesamtes Inventar verkaufen implementieren.
|
|
- [x] Fahrzeuge gesammelt reparieren implementieren.
|
|
- [x] Director-Einkommen speichern implementieren.
|
|
- [x] Transport starten implementieren.
|
|
- [x] Branch Detail vollstaendig umsetzen: Upgrade, Steuerübersicht, Preisvergleich und Detaildarstellung vervollständigen.
|
|
- [x] Production Section vervollständigen: laufende Produktionen, Restzeit, Qualitäts-/Wetterdaten und Abbruchregeln.
|
|
- [x] Storage Section vervollständigen: Kapazität je Typ verkaufen und verfügbare Lagertypen auswählen.
|
|
- [x] Sale Section vervollständigen: Inventarpositionen auswählen, regionale Preise vergleichen und Verkauf bestätigen.
|
|
- [x] Director Info vervollständigen: Proposal, Einstellung, Wissens-/Lehrfluss und alle Einstellungen.
|
|
- [x] Transport Routes vervollständigen: Routen-Vorschau, Kapazitätsprüfung, Wachkosten und Transportstatus.
|
|
|
|
#### 16.2 Bank und Historie
|
|
|
|
- [x] Bankübersicht und aktive Kredite laden.
|
|
- [x] Kreditaufnahme implementieren.
|
|
- [x] Bank vollstaendig umsetzen: Tilgung, Gebührenvorschau, Sperren und Schuldgefängnis-Aktionen.
|
|
- [x] Money History umsetzen: Filter, Pagination und Graphdaten.
|
|
|
|
#### 16.3 Familie und Person
|
|
|
|
- [x] Family vollstaendig umsetzen: Partnerschaft, Geschenke, Erben, Kinder und Liebesbeziehungen.
|
|
- [x] Health umsetzen: Gesundheitsstatus und Aktivitäten mit Cooldown.
|
|
- [x] Reputation umsetzen: Aktionen, Partys und Fortschritt.
|
|
- [x] Church umsetzen: Taufe, Ämter, Bewerbungen und Entscheidungen.
|
|
- [x] Nobility umsetzen: Stand, Voraussetzungen und Aufstieg.
|
|
- [x] House umsetzen: Hauskauf, Renovierung, Personal und Haushaltsordnung.
|
|
- [x] Education umsetzen: Lernende, Inhalte und Schulaktionen.
|
|
|
|
#### 16.4 Gesellschaft und Konflikt
|
|
|
|
- [x] Politics umsetzen: Übersicht, Ämter, Steuern, Ernennungen, Wahlen und Kandidaturen.
|
|
- [x] Underground umsetzen: Aktivitäten, Ziele, Angriffe und Raid-Regionen.
|
|
|
|
#### 16.5 Qualität
|
|
|
|
- [x] Performance fuer grosse Falukant-Datenmengen testen.
|
|
|
|
### 17. Vokabeltrainer MVP
|
|
|
|
- [x] Vocab Languages API-Vertrag erfassen.
|
|
- [x] Course List API-Vertrag erfassen.
|
|
- [x] Course Detail API-Vertrag erfassen.
|
|
- [x] Lesson API-Vertrag erfassen.
|
|
- [x] Review API-Vertrag erfassen.
|
|
- [x] Vocab Landing native umsetzen.
|
|
- [x] Course List native umsetzen.
|
|
- [x] Course Detail native umsetzen.
|
|
- [x] Lesson Player MVP implementieren.
|
|
- [x] Lesson Review implementieren.
|
|
- [x] Dictionary light implementieren.
|
|
- [x] Progress/Completion speichern.
|
|
- [x] Keyboard-/Audio-/Touch-Verhalten testen.
|
|
- [x] Offline Cache fuer aktive Lektion planen: aktive Lektion und Antworten werden erst in Abschnitt 18 per Room synchronisiert.
|
|
|
|
### 18. Vokabeltrainer Vollausbau
|
|
|
|
- [x] Neue Sprache anlegen implementieren.
|
|
- [x] Subscribe Flow implementieren.
|
|
- [x] Chapter View implementieren.
|
|
- [x] Dictionary vollstaendig implementieren.
|
|
- [x] Practice Dialog nativ ersetzen.
|
|
- [x] SRS-/Review-Logik gegen Backend validieren.
|
|
- [x] Offline Lesson Cache implementieren.
|
|
- [x] Sync-Konflikte definieren.
|
|
|
|
Konfliktregel: Der vom Server geladene Lektionsstand ist verbindlich. Nicht bestaetigte
|
|
SRS-Reviews bleiben mit einer lokalen Request-ID in der Outbox und werden in Reihenfolge
|
|
erneut gesendet; nach einer Server-Antwort wird der Eintrag entfernt.
|
|
|
|
### 19. Kalender und Persoenliches
|
|
|
|
- [x] Calendar API-Vertraege erfassen.
|
|
- [x] Monats-/Wochen-/Listenansicht entscheiden.
|
|
- [x] Termine laden.
|
|
- [x] Termin erstellen.
|
|
- [x] Termin bearbeiten.
|
|
- [x] Termin loeschen.
|
|
- [x] Date/Time Picker nativ einsetzen.
|
|
- [x] Reminder/Push spaeter planen.
|
|
- [x] Diary API-Vertrag erfassen.
|
|
- [x] Diary light umsetzen oder verschieben.
|
|
|
|
Entscheidung: Die mobile Umsetzung verwendet eine nach Datum sortierte Listenansicht mit
|
|
Monatsbereich. Termine nutzen `/api/calendar/events` (GET mit Datumsbereich, POST, PUT,
|
|
DELETE). Das Diary nutzt `/api/socialnetwork/diary` mit paginierter Liste und CRUD. Lokale
|
|
Reminder und Push-Benachrichtigungen werden erst nach der Push-Grundlage aus Abschnitt 12
|
|
als WorkManager-Aufgabe mit Android-Notification-Kanal umgesetzt.
|
|
|
|
### 20. Public Content
|
|
|
|
- [x] Blog List API-Vertrag erfassen.
|
|
- [x] Blog Detail API-Vertrag erfassen.
|
|
- [x] Guide List API-Vertrag erfassen.
|
|
- [x] Guide Detail API-Vertrag erfassen.
|
|
- [x] Public Landing Screens nativ priorisieren oder aus App entfernen.
|
|
- [x] Rich Text Rendering nativ loesen.
|
|
- [x] Blog Editor aus MVP ausschliessen.
|
|
- [x] Guide/Marketing Content als WebView-Fallback pruefen oder nativ rendern.
|
|
- [x] News/Blog/Guide Kurzlisten bewerten.
|
|
|
|
Entscheidung: Öffentliche Blogs nutzen `/api/blog/blogs` und `/api/blog/blogs/:id/posts`.
|
|
Ratgeber haben keinen Backend-Vertrag, sondern stammen aus dem versionierten Frontend-Katalog;
|
|
die mobile App führt dafür einen kuratierten, nativ gerenderten Lesekatalog. HTML aus
|
|
Blogbeiträgen wird als sicherer Text ohne WebView gerendert. Der Blog-Editor bleibt im Web.
|
|
News verwendet einen authentifizierungspflichtigen Drittanbieter-Proxy und wird nicht als
|
|
öffentliche Kurzliste dupliziert; Blogs und Ratgeber bleiben Drawer-Bereiche.
|
|
|
|
### 21. Minigames
|
|
|
|
#### 21.1 Match3
|
|
|
|
- [x] Match3 Game als native Compose/Canvas Machbarkeit pruefen.
|
|
- [x] Spielbrett, Tile-Modell und Zuglogik definieren.
|
|
- [x] Touch-Steuerung fuer Auswahl und Tausch definieren.
|
|
- [x] Animationen und Aufloesung von Matches definieren.
|
|
- [x] Score-/Leaderboard-API-Vertraege fuer Match3 erfassen.
|
|
- [ ] Performance auf Emulator und echtem Geraet testen. In eine spaetere gemeinsame QA-Runde verschoben.
|
|
|
|
Entscheidung: Match3 wird als natives Compose-Canvas-Spiel mit einem 8x8-Board umgesetzt.
|
|
Ein Zug besteht aus zwei Tap-Eingaben auf benachbarte Steine. Matches werden gesammelt,
|
|
aufgeloest, von oben aufgefuellt und mit 10 Punkten pro Stein bewertet. Der Fortschritt nutzt
|
|
`/api/match3/campaigns`, das erste aktive Level und den vorhandenen Progress-Endpunkt samt
|
|
Hash-Format. Admin-Routen bleiben ausgeschlossen.
|
|
|
|
#### 21.2 Taxi
|
|
|
|
- [x] Taxi Game als native Canvas/OpenGL Machbarkeit pruefen.
|
|
- [x] Spielfeld, Fahrzeugzustand und Fahrphysik definieren.
|
|
- [x] Touch-Steuerung fuer Lenken, Beschleunigen und Bremsen definieren.
|
|
- [x] Auftrags-, Ziel- und Kollisionslogik definieren.
|
|
- [x] Score-/Leaderboard-API-Vertraege fuer Taxi erfassen.
|
|
- [ ] Performance auf Emulator und echtem Geraet testen. In eine spaetere gemeinsame QA-Runde verschoben.
|
|
|
|
Entscheidung: Taxi wird als natives Compose-Canvas-Spiel umgesetzt. Vier Touch-Schaltflächen
|
|
steuern Lenken, Beschleunigen und Bremsen. Ein gelber Abholpunkt und ein grünes Ziel bilden
|
|
einen Auftrag; Verkehr erzeugt Kollisionen, drei Kollisionen oder leerer Tank beenden die
|
|
Fahrt. Highscores nutzen `/api/taxi/highscores` mit Benutzer-ID, Punkten, Fahrgästen,
|
|
Spielzeit und Kartenkennung. OpenGL ist für diese 2D-Strecke nicht erforderlich.
|
|
|
|
#### 21.3 Gemeinsame Integration
|
|
|
|
- [x] WebView-Fallback fuer Minigames als Zwischenloesung bewerten.
|
|
- [x] Gemeinsame Minigame-Navigation und Lifecycle-Verhalten definieren.
|
|
- [x] Gemeinsames Persistenz- und Abbruchverhalten definieren.
|
|
- [x] Admin-Tools fuer Minigames aus nativer App ausschliessen.
|
|
|
|
Entscheidung: Es gibt keinen WebView-Fallback. Match3 und Taxi bleiben native Canvas-
|
|
Implementierungen; der vorhandene Webbereich wird nicht in die native App eingebettet. Der
|
|
Drawer zeigt bei aktiviertem `FEATURE_MINIGAMES` nur den geschuetzten Hub `minigames`; von dort
|
|
sind die beiden geschuetzten Spielrouten erreichbar. Spielschleifen sind an die Composition
|
|
gebunden und werden beim Verlassen automatisch beendet. Match3 speichert nur abgeschlossene
|
|
Level ueber den vorhandenen Progress-Endpunkt. Taxi speichert beim Verlassen einer laufenden
|
|
Fahrt einen Zwischenstand ueber `/api/taxi/game-state`; abgeschlossene Fahrten werden als
|
|
Highscore gespeichert. Admin- und Verwaltungsrouten fuer Minigames werden nicht registriert und
|
|
bleiben ausschliesslich im Web-Adminbereich.
|
|
|
|
### 22. Admin spaeter
|
|
|
|
- [x] Entscheiden, ob Admin ueberhaupt in native App gehoert. - Ja, Admin gehört in die native App
|
|
- [x] Admin Users API-Vertraege erfassen.
|
|
- [x] Admin Rights API-Vertraege erfassen.
|
|
- [x] Moderation Reports API-Vertraege erfassen.
|
|
- [x] Adult Verification API-Vertraege erfassen.
|
|
- [x] Erotic Moderation API-Vertraege erfassen.
|
|
- [x] Forum Admin API-Vertraege erfassen.
|
|
- [x] Falukant Admin API-Vertraege erfassen.
|
|
- [x] Services Status Screen fuer interne Builds planen.
|
|
- [x] Admin nur per Feature Flag und Rollencheck sichtbar machen.
|
|
|
|
Entscheidung: Die native Administration wird nur eingeblendet, wenn sowohl
|
|
`FEATURE_ADMIN` aktiviert ist als auch die authentifizierte Anfrage an
|
|
`GET /api/navigation/:userid` einen Bereich `administration` liefert. Die vom Backend
|
|
gefilterte Navigation ist die Rechtequelle; die serverseitige Berechtigungsprüfung jeder
|
|
Admin-Route bleibt verbindlich. Direkte Navigation ohne beide Bedingungen zeigt keinen Inhalt.
|
|
|
|
API-Vertraege:
|
|
|
|
- Benutzer: `GET /api/admin/users/search?q=`, `GET /api/admin/users/:id`, `PUT /api/admin/users/:id`, `GET /api/admin/users/batch?ids=`, `GET /api/admin/users/statistics`; alle erfordern die vom Service gepruefte Berechtigung `useradministration` bzw. `mainadmin`.
|
|
- Rechte: `GET /api/admin/rights/types`, `GET /api/admin/rights/:id`, `POST /api/admin/rights/:id` und `DELETE /api/admin/rights/:id` mit `{ rightTypeId }`; Berechtigung `rights` bzw. `mainadmin`.
|
|
- Moderationsmeldungen: `GET /api/admin/moderation/reports?status=&limit=` sowie `POST /api/admin/moderation/reports/:reportId/status` mit Status und Review-Notiz; Berechtigung `forum` bzw. `mainadmin`.
|
|
- Altersverifikation: `GET /api/admin/users/adult-verification?status=`, `PUT /api/admin/users/:id/adult-verification` mit `approved`, `rejected` oder `pending`, sowie der geschuetzte Dokument-Download `GET /api/admin/users/:id/adult-verification/document`.
|
|
- Erotikmoderation: `GET /api/admin/users/erotic-moderation?status=`, geschuetzte Vorschau unter `/preview/:type/:targetId` und `PUT /api/admin/users/erotic-moderation/:id` mit erlaubter Aktion und optionaler Notiz.
|
|
- Forum: `GET` und `POST /api/forum/`, `DELETE /api/forum/:forumId`; Erstellen erwartet `{ name, permissions }`, die Service-Schicht prueft `forum` bzw. `mainadmin`. Allgemeine Meldungen laufen ueber den Moderationsvertrag.
|
|
- Falukant: Die geschuetzten Werkzeuge liegen unter `/api/admin/falukant/*`: Benutzersuche/-bearbeitung, Familien- und Schwangerschaftsaktionen, Bestands-/Region-/Distanzpflege, NPC-Auftraege und Titel. Die native Umsetzung beschraenkt sich auf klar abgegrenzte Fach-Screens mit serverseitiger `falukant`-/`mainadmin`-Pruefung; keine generische Datenbankbearbeitung.
|
|
|
|
Service-Status: Nur interne Debug-Builds erhalten einen kompakten, rein lesenden Statusscreen
|
|
auf Basis der bereits vorhandenen Backend-/Daemon-Verbindungssignale. Keine Prozessdaten,
|
|
Tokens, Konfigurationen oder Diagnose-Endpunkte werden in Release-Builds angezeigt. Die
|
|
Match3-/Taxi-Adminwerkzeuge bleiben gemaess Abschnitt 21 ausserhalb der nativen App.
|
|
|
|
### 23. Adult Content und Store-Compliance
|
|
|
|
- [x] Adult Content aus MVP entfernen oder per Feature Flag deaktivieren.
|
|
- [x] Altersverifikation nativ modellieren.
|
|
- [x] UGC-Melden nativ in Chat, Galerie, Forum, Profil implementieren.
|
|
- [x] Blockieren nativ implementieren.
|
|
- [x] Moderationserreichbarkeit dokumentieren.
|
|
- [x] Datenschutzseite nativ erreichbar machen.
|
|
- [x] Impressum nativ erreichbar machen.
|
|
- [x] Kontakt nativ erreichbar machen.
|
|
- [x] Account-Loeschung oder klare Anleitung nativ erreichbar machen.
|
|
- [x] Play Store Content Rating vorbereiten.
|
|
- [x] Store-Review-Risiko fuer Adult Content separat entscheiden.
|
|
|
|
Stand 2026-07-16: Der geschuetzte Bereich ist im lokalen Debug-Build per `FEATURE_ADULT`
|
|
aktiviert; Staging und Production bleiben bis zur Store-Entscheidung deaktiviert. Die native App
|
|
laedt den Status ueber `/api/settings/account` und laedt erst nach lokaler Pruefung von
|
|
Volljaehrigkeit und `adultAccessEnabled` die serverseitig ebenfalls geschuetzten Endpunkte unter
|
|
`/api/socialnetwork/erotic/*`. Ein Verifikationsnachweis (JPEG, PNG, WebP oder PDF) wird per
|
|
Android-Dateiauswahl an `/api/settings/adult-verification/request` gesendet. Die API prueft
|
|
zusaetzlich Alter und Verifikationsstatus. Die Account-Endpunkte weisen nun ausserdem Anfragen
|
|
ab, deren Body-`userId` nicht der authentifizierten `userid` entspricht.
|
|
|
|
Blockieren verwendet den neuen serverseitigen Vertrag `POST`/`DELETE
|
|
/api/socialnetwork/blocked-users/:userId` und die Migration
|
|
`20260716000000-create-user-block.sql`; der Profil-Screen bietet die Blockaktion nativ an.
|
|
|
|
Die Store-Entscheidung und Rating-Vorbereitung sind in `android/STORE_COMPLIANCE.md`
|
|
dokumentiert: Der Bereich bleibt ausserhalb lokaler Debug-Builds deaktiviert, bis eine formelle
|
|
Store- und Altersfreigabe vorliegt.
|
|
|
|
### 24. Push Notifications
|
|
|
|
- [x] Firebase Projekt klaeren.
|
|
- [x] FCM in native App integrieren.
|
|
- [x] Device Token Backend-Modell planen.
|
|
- [x] Device Token Registration API definieren.
|
|
- [x] Opt-in UI implementieren.
|
|
- [x] Notification Settings implementieren.
|
|
- [x] Chat Push definieren.
|
|
- [x] Friend Login Push definieren.
|
|
- [x] Falukant Event Push definieren.
|
|
- [x] Vocab Reminder Push definieren.
|
|
- [x] Deep Links aus Notifications implementieren.
|
|
- [x] Token Refresh Handling implementieren.
|
|
- [ ] Firebase-Service-Account im Backend-Deployment hinterlegen (`FIREBASE_SERVICE_ACCOUNT_PATH` oder `FIREBASE_SERVICE_ACCOUNT_JSON`).
|
|
|
|
### 25. Deep Links und OAuth
|
|
|
|
- [x] App Links Domain festlegen.
|
|
- [x] `assetlinks.json` planen.
|
|
- [x] Deep-Link-Struktur fuer Auth, Home, Social, Falukant, Vocab, Settings und Public Content definieren.
|
|
- [x] OAuth Redirect URIs fuer Android planen.
|
|
- [x] Custom Tabs Flow implementieren.
|
|
- [x] OAuth Callback Handling implementieren.
|
|
- [x] Deep Links fuer Profile, Forum, Falukant, Vocab, Blog definieren.
|
|
- [x] Deep Link Auth Guard implementieren.
|
|
- [x] Nicht eingeloggte Deep Links nach Login fortsetzen.
|
|
|
|
### 26. Sicherheit
|
|
|
|
- [x] Authdaten nicht im Klartext speichern.
|
|
- [x] Release Logging sensibler Daten verhindern.
|
|
- [x] Certificate Pinning bewerten, nicht vorschnell erzwingen.
|
|
- [x] Network Security Config fuer Release restriktiv halten.
|
|
- [x] Root/Jailbreak Detection bewusst entscheiden.
|
|
- [x] Screenshot-Schutz fuer Adult/Private Bereiche bewerten.
|
|
- [x] Datei-Uploads auf MIME/Größe pruefen.
|
|
- [x] WebView-Fallbacks minimieren.
|
|
- [x] Dependency-Scanning fuer Android einrichten.
|
|
|
|
### 27. Testing
|
|
|
|
- [x] Unit Tests fuer Auth Repository.
|
|
- [x] Unit Tests fuer Settings Repository.
|
|
- [x] Unit Tests fuer Error Mapping.
|
|
- [x] MockWebServer Tests fuer Auth Header.
|
|
- [x] MockWebServer Tests fuer API-Fehler.
|
|
- [x] Room Migration Tests.
|
|
- [x] Compose Tests fuer Login.
|
|
- [x] Compose Tests fuer Navigation.
|
|
- [x] Compose Tests fuer Home.
|
|
- [x] Compose Tests fuer Vocab Lesson.
|
|
- [x] Realtime Tests mit Testserver planen.
|
|
- [x] Emulator-Testmatrix definieren: kleines Phone, grosses Phone, Tablet.
|
|
- [x] Echtes Android-Geraet in Testmatrix aufnehmen.
|
|
- [x] Offline/Online-Wechsel testen.
|
|
- [x] App Kill/Restart/Resume testen.
|
|
- [ ] Instrumentation-Suite auf einem verbundenen Geraet oder KVM-faehigen Host ausfuehren (lokal blockiert: kein ADB-Geraet, keine x86_64-Hardwarebeschleunigung).
|
|
|
|
### 28. Build, Release und Betrieb
|
|
|
|
- [ ] Debug APK Build einrichten.
|
|
- [ ] Release AAB Build einrichten.
|
|
- [ ] Signing-Konzept definieren.
|
|
- [ ] Keystore sicher ablegen.
|
|
- [ ] Internal App Sharing oder interne Testspur planen.
|
|
- [ ] Crashlytics oder alternatives Crash Reporting entscheiden.
|
|
- [ ] Analytics bewusst entscheiden: ja/nein, Datenschutz.
|
|
- [ ] App Version Check implementieren oder planen.
|
|
- [ ] Rollback-Strategie definieren.
|
|
- [ ] Hybrid-App und Native-App Parallelbetrieb dokumentieren.
|
|
|
|
### 29. Backend-Vorbereitung fuer Native
|
|
|
|
- [ ] Release-Signaturfingerprint in die ausgelieferte `/.well-known/assetlinks.json` eintragen.
|
|
- [ ] Native OAuth-Redirect-URI bei jedem aktivierten Provider hinterlegen.
|
|
- [ ] Mobile API-Inventar aus allen Web-Komponenten erstellen.
|
|
- [ ] API-Versionierung bewerten: `/api/mobile/v1` ja/nein.
|
|
- [ ] Einheitliches Fehlerformat definieren.
|
|
- [ ] Einheitliches Pagination-Format definieren.
|
|
- [ ] Auth auf Bearer Token/JWT oder bestehendes `userid`/`authcode` final entscheiden.
|
|
- [ ] Refresh Token Konzept bewerten.
|
|
- [ ] Device Token API fuer Push planen.
|
|
- [ ] Datei-Upload-Limits dokumentieren.
|
|
- [ ] Image Thumbnail Endpunkte fuer mobile Listen planen.
|
|
- [ ] Falukant Summary Endpunkte fuer mobile Screens planen.
|
|
- [ ] Vocab Lesson Endpunkte fuer mobile Offline-Caches planen.
|
|
|
|
### 30. Abnahmekriterien MVP
|
|
|
|
- [ ] App startet kalt unter 2 Sekunden auf Testgeraet oder Zielwert begruendet anpassen.
|
|
- [ ] Login funktioniert gegen production/staging.
|
|
- [ ] Session ueberlebt App-Neustart.
|
|
- [ ] Logout entfernt lokale Session und trennt Realtime.
|
|
- [ ] Home laedt ohne WebView.
|
|
- [ ] Navigation ist vollstaendig nativ.
|
|
- [ ] Mindestens ein Social-Basisflow funktioniert.
|
|
- [ ] Mindestens ein Falukant-Basisflow funktioniert.
|
|
- [ ] Mindestens ein Vocab-Lesson-Flow funktioniert.
|
|
- [ ] Fehler werden nativ und verstaendlich angezeigt.
|
|
- [ ] Offline-Zustand wird erkannt und blockiert keine App.
|
|
- [ ] Keine lokalen Dev-URLs im Release-Build.
|
|
- [ ] Keine Secrets im APK/AAB.
|
|
- [ ] Datenschutz, Impressum und Kontakt sind erreichbar.
|
|
|
|
## Empfohlene erste Umsetzungsschritte
|
|
|
|
1. `/android/native` als neues Kotlin/Compose-Projekt anlegen.
|
|
2. Core Module fuer Network, Auth, Design und Navigation erstellen.
|
|
3. Login komplett nativ implementieren.
|
|
4. Session Store und Auth Interceptor stabilisieren.
|
|
5. Native App Shell mit Home und Navigation bauen.
|
|
6. Danach Social light, Falukant light und Vocab light nacheinander umsetzen.
|
|
|
|
## Realistische Einordnung
|
|
|
|
Die native Komplettumsetzung ist erheblich groesser als die Hybrid-App. Die Hybrid-App ist sinnvoll als lauffaehige Zwischenloesung und Referenzimplementierung. Die native App sollte als paralleles Produkt mit klarem MVP gestartet werden, sonst entsteht ein langer Rewrite ohne nutzbaren Zwischenstand.
|