torsten/yourpart3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c13339f77160cdfb5405f5892128380b3ffb4694
yourpart3/android/NATIVE_ANDROID_APP_PLAN.md
Torsten Schulz (local) 1ab9407e79
All checks were successful
Deploy to production / deploy (push) Successful in 2m56s
Details
Refactor code structure for improved readability and maintainability; optimize performance across multiple modules.
2026-07-21 09:08:15 +02:00

41 KiB
Executable File
Raw Blame History

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

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:

  • Entscheiden, ob die native App unter /android/native angelegt wird.
  • Entscheiden, ob die Capacitor-App langfristig parallel gepflegt bleibt.
  • Native MVP-Funktionsumfang final freigeben.
  • Admin-Bereich aus MVP ausschliessen oder explizit aufnehmen.
  • Adult-/Erotikbereiche aus MVP ausschliessen oder explizit mit Compliance-Aufwand aufnehmen.
  • Minigames aus MVP ausschliessen oder als separaten Spike aufnehmen.
  • 3D-Charaktere aus MVP ausschliessen oder als separaten Spike aufnehmen.
  • Zielgeraete festlegen: kleine Phones, Tablets, Mindest-Android-Version.
  • 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.

  • 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

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.

  • 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: nein, nicht Teil des MVP.

  • 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.

  • 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.

  • 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

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.

  • 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

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.

  • 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

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.

  • 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

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.

  • 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

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.

  • 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

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.

  • 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.

  • Backend-/Daemon-Status light anzeigen.

10. Settings

  • Settings API-Vertraege erfassen: /api/settings/filter, /api/settings/update, /api/settings/account, /api/settings/set-account, /api/settings/visibilities.
  • 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

  • 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.

  • 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

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.

  • 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.

  • 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.

  • Galerie API-Vertraege erfassen.

  • Folder-Struktur nativ modellieren.

  • Bildliste mit Coil implementieren.

  • Bilddetail mit Vorschau sowie nativer Metadatenpflege fuer Titel und Sichtbarkeit implementieren.

  • Android Photo Picker fuer Upload implementieren.

  • Multipart Upload gegen den Backend-Vertrag automatisiert testen.

  • Bildbearbeitung aus Web-App bewerten: MVP nein. Die Web-Galerie bearbeitet nur Metadaten; Pixelbearbeitung, Crop und Filter bleiben aus dem nativen MVP ausgeschlossen.

  • Sichtbarkeiten laden und setzen.

  • Adult-Galerie aus MVP ausschliessen oder Compliance-Aufwand planen.

  • 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.

  • 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

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.

  • 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 bewusst verschieben.

  • Family View light implementieren.

  • Church/Reputation/Health/Nobility als Falukant-Vollausbau markieren.

  • Production/Storage/Sale/Director als Falukant-Vollausbau markieren.

  • 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

  • Filialdetail-Basis laden: Filiale, Produktion, Lager, Inventar, Director, Fahrzeuge und Transporte.
  • Produktion starten implementieren.
  • Lagerkapazität kaufen implementieren.
  • Einzelverkauf implementieren.
  • Gesamtes Inventar verkaufen implementieren.
  • Fahrzeuge gesammelt reparieren implementieren.
  • Director-Einkommen speichern implementieren.
  • Transport starten implementieren.
  • Branch Detail vollstaendig umsetzen: Upgrade, Steuerübersicht, Preisvergleich und Detaildarstellung vervollständigen.
  • Production Section vervollständigen: laufende Produktionen, Restzeit, Qualitäts-/Wetterdaten und Abbruchregeln.
  • Storage Section vervollständigen: Kapazität je Typ verkaufen und verfügbare Lagertypen auswählen.
  • Sale Section vervollständigen: Inventarpositionen auswählen, regionale Preise vergleichen und Verkauf bestätigen.
  • Director Info vervollständigen: Proposal, Einstellung, Wissens-/Lehrfluss und alle Einstellungen.
  • Transport Routes vervollständigen: Routen-Vorschau, Kapazitätsprüfung, Wachkosten und Transportstatus.

16.2 Bank und Historie

  • Bankübersicht und aktive Kredite laden.
  • Kreditaufnahme implementieren.
  • Bank vollstaendig umsetzen: Tilgung, Gebührenvorschau, Sperren und Schuldgefängnis-Aktionen.
  • Money History umsetzen: Filter, Pagination und Graphdaten.

16.3 Familie und Person

  • Family vollstaendig umsetzen: Partnerschaft, Geschenke, Erben, Kinder und Liebesbeziehungen.
  • Health umsetzen: Gesundheitsstatus und Aktivitäten mit Cooldown.
  • Reputation umsetzen: Aktionen, Partys und Fortschritt.
  • Church umsetzen: Taufe, Ämter, Bewerbungen und Entscheidungen.
  • Nobility umsetzen: Stand, Voraussetzungen und Aufstieg.
  • House umsetzen: Hauskauf, Renovierung, Personal und Haushaltsordnung.
  • Education umsetzen: Lernende, Inhalte und Schulaktionen.

16.4 Gesellschaft und Konflikt

  • Politics umsetzen: Übersicht, Ämter, Steuern, Ernennungen, Wahlen und Kandidaturen.
  • Underground umsetzen: Aktivitäten, Ziele, Angriffe und Raid-Regionen.

16.5 Qualität

  • 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: aktive Lektion und Antworten werden erst in Abschnitt 18 per Room synchronisiert.

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.

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

  • 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.

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

  • 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.
  • 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

  • Match3 Game als native Compose/Canvas Machbarkeit pruefen.
  • Spielbrett, Tile-Modell und Zuglogik definieren.
  • Touch-Steuerung fuer Auswahl und Tausch definieren.
  • Animationen und Aufloesung von Matches definieren.
  • 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

  • Taxi Game als native Canvas/OpenGL Machbarkeit pruefen.
  • Spielfeld, Fahrzeugzustand und Fahrphysik definieren.
  • Touch-Steuerung fuer Lenken, Beschleunigen und Bremsen definieren.
  • Auftrags-, Ziel- und Kollisionslogik definieren.
  • 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

  • WebView-Fallback fuer Minigames als Zwischenloesung bewerten.
  • Gemeinsame Minigame-Navigation und Lifecycle-Verhalten definieren.
  • Gemeinsames Persistenz- und Abbruchverhalten definieren.
  • 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

  • Entscheiden, ob Admin ueberhaupt in native App gehoert. - Ja, Admin gehört in die native App
  • 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.

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

  • 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.

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

  • 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.
  • Firebase-Service-Account im Backend-Deployment hinterlegen (FIREBASE_SERVICE_ACCOUNT_PATH oder FIREBASE_SERVICE_ACCOUNT_JSON).

25. Deep Links und OAuth

  • App Links Domain festlegen.
  • assetlinks.json planen.
  • Deep-Link-Struktur fuer Auth, Home, Social, Falukant, Vocab, Settings und Public Content definieren.
  • 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.
  • 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.

Reference in New Issue View Git Blame Copy Permalink