626 lines
24 KiB
Markdown
626 lines
24 KiB
Markdown
# 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
|
|
|
|
- [ ] Neues natives Gradle-Projekt unter `/android/native` erstellen.
|
|
- [ ] Kotlin DSL fuer Gradle verwenden.
|
|
- [ ] App-ID `de.yourpart.app` oder separate Dev-ID `de.yourpart.native.dev` entscheiden.
|
|
- [ ] Produktflavors anlegen: `local`, `staging`, `production`.
|
|
- [ ] Build Types anlegen: `debug`, `release`.
|
|
- [ ] Versionierung definieren: `versionCode`, `versionName`, Git-Hash im Build.
|
|
- [ ] Compose aktivieren.
|
|
- [ ] Material 3 aktivieren.
|
|
- [ ] Hilt einrichten.
|
|
- [ ] Retrofit/OkHttp einrichten.
|
|
- [ ] JSON-Library festlegen und einrichten.
|
|
- [ ] Room einrichten.
|
|
- [ ] DataStore einrichten.
|
|
- [ ] Coil einrichten.
|
|
- [ ] WorkManager einrichten.
|
|
- [ ] FCM Dependency vorbereiten, aber noch nicht aktiv schalten.
|
|
- [ ] Lint, Detekt oder Ktlint einrichten.
|
|
- [ ] CI-Build-Script fuer native App definieren.
|
|
|
|
### 2. Design System
|
|
|
|
- [ ] YourPart-Farbpalette aus Web-App ableiten.
|
|
- [ ] Typography fuer Android definieren.
|
|
- [ ] Spacing-Skala definieren.
|
|
- [ ] Shape-/Radius-System definieren.
|
|
- [ ] Button-Komponenten definieren.
|
|
- [ ] TextField-Komponenten definieren.
|
|
- [ ] Dialog-Komponenten definieren.
|
|
- [ ] Error-/Info-/Success-Komponenten definieren.
|
|
- [ ] Loading/Empty-State-Komponenten definieren.
|
|
- [ ] Avatar-/Image-Komponenten definieren.
|
|
- [ ] Status-Chips fuer Backend/Daemon definieren.
|
|
- [ ] Light Theme implementieren.
|
|
- [ ] Dark Theme bewusst entscheiden: sofort, spaeter oder nicht.
|
|
- [ ] Kleine Displaybreiten 360dp und 393dp als Design-Baseline testen.
|
|
|
|
### 3. App Shell und Navigation
|
|
|
|
- [ ] Root Compose App mit Theme erstellen.
|
|
- [ ] Top App Bar definieren.
|
|
- [ ] Bottom Navigation fuer Hauptbereiche definieren.
|
|
- [ ] Navigation Drawer fuer Sekundaerbereiche definieren.
|
|
- [ ] Typed Routes fuer Auth, Home, Social, Falukant, Vocab, Settings anlegen.
|
|
- [ ] Rollen-/Rechte-basierte Menueeintraege modellieren.
|
|
- [ ] Backend-Menue-Response analysieren und native Menue-Policy definieren.
|
|
- [ ] Deep-Link-Struktur definieren.
|
|
- [ ] Android Back Button Verhalten definieren.
|
|
- [ ] Dialog-Back-Handling implementieren.
|
|
- [ ] Session-expired Navigation implementieren.
|
|
- [ ] Offline-Banner implementieren.
|
|
- [ ] Backend-/Daemon-Status sichtbar, aber kompakt darstellen.
|
|
|
|
### 4. Konfiguration und Environments
|
|
|
|
- [ ] API Base URLs fuer `local`, `staging`, `production` definieren.
|
|
- [ ] Socket.IO URLs je Flavor definieren.
|
|
- [ ] Daemon WebSocket URLs je Flavor definieren.
|
|
- [ ] Lokale Emulator-Regel dokumentieren: Host-Rechner ist `10.0.2.2`.
|
|
- [ ] Release-Build gegen lokale URLs blockieren.
|
|
- [ ] Network Security Config fuer Debug und Release definieren.
|
|
- [ ] TLS-only fuer Release sicherstellen.
|
|
- [ ] Secrets aus APK fernhalten.
|
|
- [ ] Feature Flags definieren: Admin, Adult, 3D, Minigames, Push.
|
|
|
|
### 5. Auth und Session
|
|
|
|
- [ ] Login-Endpunkt dokumentieren.
|
|
- [ ] Login DTOs erstellen.
|
|
- [ ] Login Repository implementieren.
|
|
- [ ] Auth Interceptor fuer `userid` und `authcode` implementieren.
|
|
- [ ] Session Store mit sicherer Speicherung implementieren.
|
|
- [ ] Auto-Login beim App-Start implementieren.
|
|
- [ ] Logout implementieren.
|
|
- [ ] Session-expired Handling implementieren.
|
|
- [ ] User-Aktivstatus pruefen.
|
|
- [ ] Account gesperrt Handling implementieren.
|
|
- [ ] Registrierung API-Vertrag erfassen.
|
|
- [ ] Registrierung Screen implementieren.
|
|
- [ ] Account-Aktivierung Flow bewerten.
|
|
- [ ] Passwort-Reset Flow implementieren.
|
|
- [ ] 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
|
|
|
|
- [ ] Zentrale `ApiResult`/`NetworkError` Struktur definieren.
|
|
- [ ] Fehlercodes und Backend-Fehlerformate erfassen.
|
|
- [ ] Retry-Policy definieren.
|
|
- [ ] Timeout-Policy definieren.
|
|
- [ ] Request Logging nur fuer Debug aktivieren.
|
|
- [ ] Auth Header Tests mit MockWebServer schreiben.
|
|
- [ ] CORS ist nativ irrelevant, aber Backend-Origin-Checks gegen mobile Clients pruefen.
|
|
- [ ] Multipart Upload Helper bauen.
|
|
- [ ] Download Helper fuer Bilder/Dateien bauen.
|
|
- [ ] Pagination Pattern definieren.
|
|
- [ ] Refresh Pattern definieren.
|
|
|
|
### 7. Lokale Persistenz und Cache
|
|
|
|
- [ ] DataStore fuer UI-Sprache verwenden.
|
|
- [ ] DataStore fuer Feature Flags verwenden.
|
|
- [ ] Room Schema fuer User/Profile Cache definieren.
|
|
- [ ] Room Schema fuer Friends/Search Cache definieren.
|
|
- [ ] Room Schema fuer Falukant Status light definieren.
|
|
- [ ] Room Schema fuer Vocab Course/Lesson Cache definieren.
|
|
- [ ] Cache-Invalidation Regeln definieren.
|
|
- [ ] Offline-Anzeige statt Offline-First fuer MVP festlegen.
|
|
- [ ] Outbox fuer spaetere Offline-Aktionen nur planen, nicht im MVP erzwingen.
|
|
|
|
### 8. Realtime
|
|
|
|
- [ ] Socket.IO Android Client evaluieren.
|
|
- [ ] Verbindung nach Login aufbauen.
|
|
- [ ] `setUserId` nach Verbindungsaufbau senden.
|
|
- [ ] Events erfassen: `forumschanged`, `friendloginchanged`, `reloadmenu`, `adultVerificationChanged`, `moderationReportChanged`, `userAccessChanged`.
|
|
- [ ] Falukant-Events erfassen: `falukantUpdateStatus`, `falukantUpdateFamily`, `falukantUpdateChurch`, `falukantUpdateDebt`, `children_update`, `falukantUpdateProductionCertificate`, `falukantBranchUpdate`, `stock_change`, `familychanged`.
|
|
- [ ] Socket Lifecycle an App Foreground/Background koppeln.
|
|
- [ ] Reconnect Policy definieren.
|
|
- [ ] Daemon-WebSocket Client implementieren.
|
|
- [ ] Daemon-Message Parsing robust gegen unbekannte Events machen.
|
|
- [ ] Realtime Events in Repositories einspeisen.
|
|
- [ ] UI-State bei Events gezielt invalidieren.
|
|
- [ ] Realtime Debug Screen fuer interne Builds planen.
|
|
|
|
### 9. Home und Dashboard
|
|
|
|
- [ ] Home API-Vertraege erfassen.
|
|
- [ ] Eingeloggt/Nicht-eingeloggt Home getrennt modellieren.
|
|
- [ ] Native Startseite fuer nicht eingeloggte Nutzer bauen.
|
|
- [ ] Native Startseite fuer eingeloggte Nutzer bauen.
|
|
- [ ] Dashboard Widget API-Vertraege erfassen.
|
|
- [ ] Termine/Upcoming Events als native Cards umsetzen.
|
|
- [ ] Falukant Kurzstatus als native Card umsetzen.
|
|
- [ ] News/Blog/Guide Kurzlisten bewerten.
|
|
- [ ] Backend-/Daemon-Status light anzeigen.
|
|
|
|
### 10. Settings
|
|
|
|
- [ ] Settings API-Vertraege erfassen: `/api/settings/filter`, `/api/settings/update`, `/api/settings/account`.
|
|
- [ ] Spracheinstellung nativ implementieren.
|
|
- [ ] Account-Basisdaten nativ implementieren.
|
|
- [ ] Sichtbarkeitseinstellungen modellieren.
|
|
- [ ] Personal/View/Sexuality/Flirt Settings priorisieren.
|
|
- [ ] Interessen-Settings implementieren.
|
|
- [ ] Language Assistant Settings bewerten.
|
|
- [ ] Account-Loeschung oder Anfrageprozess fuer Store-Compliance klaeren.
|
|
|
|
### 11. Social Basis
|
|
|
|
- [ ] Friends API-Vertraege erfassen.
|
|
- [ ] Friends Screen implementieren: bestehend, angefragt, offen, abgelehnt.
|
|
- [ ] User Search API-Vertraege erfassen.
|
|
- [ ] User Search Screen implementieren.
|
|
- [ ] User Profile API-Vertraege erfassen.
|
|
- [ ] Profile Light Screen implementieren.
|
|
- [ ] Guestbook API-Vertraege erfassen.
|
|
- [ ] Guestbook light implementieren.
|
|
- [ ] Friend Request Aktionen implementieren.
|
|
- [ ] Blockieren/Melden UX fuer Store-Compliance planen.
|
|
- [ ] Privacy/Visibility Regeln aus Backend nativ abbilden.
|
|
|
|
### 12. Chat
|
|
|
|
- [ ] Aktuellen Chat-Mechanismus erfassen: Dialoge, Raeume, Random Chat, MultiChat.
|
|
- [ ] Chat Backend-/WebSocket-Vertraege dokumentieren.
|
|
- [ ] Chat Room Liste implementieren.
|
|
- [ ] 1:1 Chat MVP implementieren.
|
|
- [ ] MultiChat MVP implementieren oder bewusst verschieben.
|
|
- [ ] RandomChat bewusst verschieben oder implementieren.
|
|
- [ ] Message Input mit Keyboard-Verhalten testen.
|
|
- [ ] Neue Nachrichten per Realtime anzeigen.
|
|
- [ ] Push-Kandidaten fuer Chat definieren.
|
|
- [ ] Melden/Blockieren im Chat implementieren oder als Release-Blocker markieren.
|
|
|
|
### 13. Galerie und Medien
|
|
|
|
- [ ] Galerie API-Vertraege erfassen.
|
|
- [ ] Folder-Struktur nativ modellieren.
|
|
- [ ] Bildliste mit Coil implementieren.
|
|
- [ ] Bilddetail implementieren.
|
|
- [ ] Android Photo Picker fuer Upload implementieren.
|
|
- [ ] Multipart Upload testen.
|
|
- [ ] Bildbearbeitung aus Web-App bewerten: MVP ja/nein.
|
|
- [ ] Sichtbarkeiten laden und setzen.
|
|
- [ ] Adult-Galerie aus MVP ausschliessen oder Compliance-Aufwand planen.
|
|
- [ ] Video-Unterstuetzung separat planen.
|
|
|
|
### 14. Forum
|
|
|
|
- [ ] Forum-Liste API-Vertrag erfassen.
|
|
- [ ] Topic-Liste API-Vertrag erfassen.
|
|
- [ ] Topic-Detail API-Vertrag erfassen.
|
|
- [ ] Forum-Liste native umsetzen.
|
|
- [ ] Topic-Liste native umsetzen.
|
|
- [ ] Topic-Detail native umsetzen.
|
|
- [ ] Antwort erstellen implementieren.
|
|
- [ ] Moderation Report fuer Forum implementieren.
|
|
- [ ] Realtime `forumschanged` integrieren.
|
|
|
|
### 15. Falukant MVP
|
|
|
|
- [ ] Falukant API-Endpunkte aus Web-App inventarisieren.
|
|
- [ ] `StatusBar` Datenmodell nativ definieren.
|
|
- [ ] Overview Screen implementieren.
|
|
- [ ] Character/Familien-Basisdaten implementieren.
|
|
- [ ] Branch-Liste implementieren.
|
|
- [ ] Branch-Detail light implementieren.
|
|
- [ ] Bank light implementieren.
|
|
- [ ] Messages/Notifications light implementieren.
|
|
- [ ] Realtime Falukant Events integrieren.
|
|
- [ ] Create Falukant Flow implementieren oder bewusst verschieben.
|
|
- [ ] Family View light implementieren.
|
|
- [ ] Church/Reputation/Health/Nobility als spaetere Phase markieren.
|
|
- [ ] Production/Storage/Sale/Director als spaetere Phase markieren.
|
|
- [ ] Karten-/Regionen-Features als spaetere Phase markieren.
|
|
|
|
### 16. Falukant Vollausbau
|
|
|
|
- [ ] Branch Detail vollstaendig umsetzen.
|
|
- [ ] Production Section umsetzen.
|
|
- [ ] Storage Section umsetzen.
|
|
- [ ] Sale Section umsetzen.
|
|
- [ ] Director Info umsetzen.
|
|
- [ ] Transport Routes umsetzen.
|
|
- [ ] Bank vollstaendig umsetzen.
|
|
- [ ] Family vollstaendig umsetzen.
|
|
- [ ] Health umsetzen.
|
|
- [ ] Reputation umsetzen.
|
|
- [ ] Church umsetzen.
|
|
- [ ] Nobility umsetzen.
|
|
- [ ] Politics umsetzen.
|
|
- [ ] Underground umsetzen.
|
|
- [ ] House umsetzen.
|
|
- [ ] Education umsetzen.
|
|
- [ ] Money History umsetzen.
|
|
- [ ] Performance fuer grosse Falukant-Datenmengen testen.
|
|
|
|
### 17. Vokabeltrainer MVP
|
|
|
|
- [ ] Vocab Languages API-Vertrag erfassen.
|
|
- [ ] Course List API-Vertrag erfassen.
|
|
- [ ] Course Detail API-Vertrag erfassen.
|
|
- [ ] Lesson API-Vertrag erfassen.
|
|
- [ ] Review API-Vertrag erfassen.
|
|
- [ ] Vocab Landing native umsetzen.
|
|
- [ ] Course List native umsetzen.
|
|
- [ ] Course Detail native umsetzen.
|
|
- [ ] Lesson Player MVP implementieren.
|
|
- [ ] Lesson Review implementieren.
|
|
- [ ] Dictionary light implementieren.
|
|
- [ ] Progress/Completion speichern.
|
|
- [ ] Keyboard-/Audio-/Touch-Verhalten testen.
|
|
- [ ] Offline Cache fuer aktive Lektion planen.
|
|
|
|
### 18. Vokabeltrainer Vollausbau
|
|
|
|
- [ ] Neue Sprache anlegen implementieren.
|
|
- [ ] Subscribe Flow implementieren.
|
|
- [ ] Chapter View implementieren.
|
|
- [ ] Dictionary vollstaendig implementieren.
|
|
- [ ] Practice Dialog nativ ersetzen.
|
|
- [ ] SRS-/Review-Logik gegen Backend validieren.
|
|
- [ ] Offline Lesson Cache implementieren.
|
|
- [ ] Sync-Konflikte definieren.
|
|
|
|
### 19. Kalender und Persoenliches
|
|
|
|
- [ ] Calendar API-Vertraege erfassen.
|
|
- [ ] Monats-/Wochen-/Listenansicht entscheiden.
|
|
- [ ] Termine laden.
|
|
- [ ] Termin erstellen.
|
|
- [ ] Termin bearbeiten.
|
|
- [ ] Termin loeschen.
|
|
- [ ] Date/Time Picker nativ einsetzen.
|
|
- [ ] Reminder/Push spaeter planen.
|
|
- [ ] Diary API-Vertrag erfassen.
|
|
- [ ] Diary light umsetzen oder verschieben.
|
|
|
|
### 20. Public Content
|
|
|
|
- [ ] Blog List API-Vertrag erfassen.
|
|
- [ ] Blog Detail API-Vertrag erfassen.
|
|
- [ ] Guide List API-Vertrag erfassen.
|
|
- [ ] Guide Detail API-Vertrag erfassen.
|
|
- [ ] Public Landing Screens nativ priorisieren oder aus App entfernen.
|
|
- [ ] Rich Text Rendering nativ loesen.
|
|
- [ ] Blog Editor aus MVP ausschliessen.
|
|
- [ ] Guide/Marketing Content als WebView-Fallback pruefen oder nativ rendern.
|
|
|
|
### 21. Minigames
|
|
|
|
- [ ] Match3 Game als native Compose/Canvas Machbarkeit pruefen.
|
|
- [ ] Taxi Game als native Canvas/OpenGL Machbarkeit pruefen.
|
|
- [ ] WebView-Fallback fuer Minigames als Zwischenloesung bewerten.
|
|
- [ ] Touch-Steuerung definieren.
|
|
- [ ] Performance auf Emulator und echtem Geraet testen.
|
|
- [ ] Leaderboard/Score API-Vertraege erfassen.
|
|
- [ ] Admin-Tools fuer Minigames aus nativer App ausschliessen.
|
|
|
|
### 22. Admin spaeter
|
|
|
|
- [ ] Entscheiden, ob Admin ueberhaupt in native App gehoert.
|
|
- [ ] Admin Users API-Vertraege erfassen.
|
|
- [ ] Admin Rights API-Vertraege erfassen.
|
|
- [ ] Moderation Reports API-Vertraege erfassen.
|
|
- [ ] Adult Verification API-Vertraege erfassen.
|
|
- [ ] Erotic Moderation API-Vertraege erfassen.
|
|
- [ ] Forum Admin API-Vertraege erfassen.
|
|
- [ ] Falukant Admin API-Vertraege erfassen.
|
|
- [ ] Services Status Screen fuer interne Builds planen.
|
|
- [ ] Admin nur per Feature Flag und Rollencheck sichtbar machen.
|
|
|
|
### 23. Adult Content und Store-Compliance
|
|
|
|
- [ ] Adult Content aus MVP entfernen oder per Feature Flag deaktivieren.
|
|
- [ ] Altersverifikation nativ modellieren.
|
|
- [ ] UGC-Melden nativ in Chat, Galerie, Forum, Profil implementieren.
|
|
- [ ] Blockieren nativ implementieren.
|
|
- [ ] Moderationserreichbarkeit dokumentieren.
|
|
- [ ] Datenschutzseite nativ erreichbar machen.
|
|
- [ ] Impressum nativ erreichbar machen.
|
|
- [ ] Kontakt nativ erreichbar machen.
|
|
- [ ] Account-Loeschung oder klare Anleitung nativ erreichbar machen.
|
|
- [ ] Play Store Content Rating vorbereiten.
|
|
- [ ] Store-Review-Risiko fuer Adult Content separat entscheiden.
|
|
|
|
### 24. Push Notifications
|
|
|
|
- [ ] Firebase Projekt klaeren.
|
|
- [ ] FCM in native App integrieren.
|
|
- [ ] Device Token Backend-Modell planen.
|
|
- [ ] Device Token Registration API definieren.
|
|
- [ ] Opt-in UI implementieren.
|
|
- [ ] Notification Settings implementieren.
|
|
- [ ] Chat Push definieren.
|
|
- [ ] Friend Login Push definieren.
|
|
- [ ] Falukant Event Push definieren.
|
|
- [ ] Vocab Reminder Push definieren.
|
|
- [ ] Deep Links aus Notifications implementieren.
|
|
- [ ] Token Refresh Handling implementieren.
|
|
|
|
### 25. Deep Links und OAuth
|
|
|
|
- [ ] App Links Domain festlegen.
|
|
- [ ] `assetlinks.json` planen.
|
|
- [ ] OAuth Redirect URIs fuer Android planen.
|
|
- [ ] Custom Tabs Flow implementieren.
|
|
- [ ] OAuth Callback Handling implementieren.
|
|
- [ ] Deep Links fuer Profile, Forum, Falukant, Vocab, Blog definieren.
|
|
- [ ] Deep Link Auth Guard implementieren.
|
|
- [ ] Nicht eingeloggte Deep Links nach Login fortsetzen.
|
|
|
|
### 26. Sicherheit
|
|
|
|
- [ ] Authdaten nicht im Klartext speichern.
|
|
- [ ] Release Logging sensibler Daten verhindern.
|
|
- [ ] Certificate Pinning bewerten, nicht vorschnell erzwingen.
|
|
- [ ] Network Security Config fuer Release restriktiv halten.
|
|
- [ ] Root/Jailbreak Detection bewusst entscheiden.
|
|
- [ ] Screenshot-Schutz fuer Adult/Private Bereiche bewerten.
|
|
- [ ] Datei-Uploads auf MIME/Größe pruefen.
|
|
- [ ] WebView-Fallbacks minimieren.
|
|
- [ ] Dependency-Scanning fuer Android einrichten.
|
|
|
|
### 27. Testing
|
|
|
|
- [ ] Unit Tests fuer Auth Repository.
|
|
- [ ] Unit Tests fuer Settings Repository.
|
|
- [ ] Unit Tests fuer Error Mapping.
|
|
- [ ] MockWebServer Tests fuer Auth Header.
|
|
- [ ] MockWebServer Tests fuer API-Fehler.
|
|
- [ ] Room Migration Tests.
|
|
- [ ] Compose Tests fuer Login.
|
|
- [ ] Compose Tests fuer Navigation.
|
|
- [ ] Compose Tests fuer Home.
|
|
- [ ] Compose Tests fuer Vocab Lesson.
|
|
- [ ] Realtime Tests mit Testserver planen.
|
|
- [ ] Emulator-Testmatrix definieren: kleines Phone, grosses Phone, Tablet.
|
|
- [ ] Echtes Android-Geraet in Testmatrix aufnehmen.
|
|
- [ ] Offline/Online-Wechsel testen.
|
|
- [ ] App Kill/Restart/Resume testen.
|
|
|
|
### 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
|
|
|
|
- [ ] 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.
|