Refactor code structure for improved readability and maintainability

ANDROID_KOTLIN_PLAN.md

@@ -131,8 +131,12 @@ Kurz: Ziel ist eine native Android-App mit Kotlin + Jetpack Compose, die die Web
  [x] 19. Accessibility: ContentDescription, Focus, Farben/Kontrast prüfen
  [ ] 20. Tests: Unit-Tests für ViewModels + UI-Tests mit Compose Testing
      - [x] Erste JVM-Unit-Tests für gemeinsame Formularvalidierung ergänzt
-     - [ ] ViewModel-Tests für Auth-/CMS-/Galerie-Flows ergänzen
+     - [x] ViewModel-Tests für Auth-/CMS-/Galerie-Flows ergänzen
      - [ ] Compose-UI-Tests für kritische Screens ergänzen
+     - [x] Hilt androidTest dependencies und `kspAndroidTest` konfiguriert
+     - [x] `HiltTestApplication` in `androidTest`-Manifest gesetzt
+     - [x] `LoginScreenTest` zu `@HiltAndroidTest` migriert und `HiltAndroidRule` hinzugefügt
+     - [x] `TestHiltModules.kt` für androidTest hinzugefügt (Test‑Bindings bereitgestellt)
  [x] 21. Performance: Bildoptimierung, LazyLists, Paging (falls große Daten)
  [ ] 22. Analytics: Firebase / Matomo Integration (je nach Datenschutz)
  [x] 23. Crash-Reporting: Sentry / Crashlytics integrieren
@@ -196,6 +200,27 @@ Kurz: Ziel ist eine native Android-App mit Kotlin + Jetpack Compose, die die Web
 - Produktion: `./gradlew :app:installProductionDebug` verwendet `https://harheimertc.de/` und die App-ID `de.harheimertc`.
 - Nur APKs erzeugen: `./gradlew :app:assembleLocalDebug :app:assembleInstantTestDebug :app:assembleProductionDebug`.
 
+8a) Aktueller Teststatus & Troubleshooting (Stand: 2026-05-28)
+
+- **Status:** `:app:assembleAndroidTest` läuft durch; `:app:connectedAndroidTest` ist derzeit instabil und schlägt bei Instrumentation-Läufen fehl.
+- **Beobachtete Probleme:**
+    - Kompilationsfehler in `LoginScreenTest.kt` wegen `HiltTestActivity` (Unresolved reference). Workaround: `createAndroidComposeRule<ComponentActivity>()` + `setContent{}` verwenden, damit `assembleAndroidTest` durchläuft.
+    - Laufzeit-/Device-Probleme bei `connectedAndroidTest`: `com.android.ddmlib.SyncException: Remote object doesn't exist!` und `DELETE_FAILED_INTERNAL_ERROR` beim Deinstallieren von Test-APKs.
+    - `AndroidTestLogcatPlugin` wirft `FileNotFoundException` für erwartete Log-/Crash-Dateien, weil Gradle/UTP manche Device-Artefakte nicht zuverlässig pulled.
+    - Einzelne Instrumentation-Tests (z. B. `CmsActivateResendTest`, `GalleryScreenTest`) zeigen Assertion-Fehlschläge — diese sollten isoliert reproduziert werden.
+- **Kurzfristige Empfehlungen (nicht ausführen):**
+    - Emulator neu starten und sicherstellen, dass keine veralteten Test-APKs installiert sind.
+    - Manuell: `adb uninstall` der Test-Pakete, dann frisches `adb install -r` des Test-APKs und gezielter Einzeltest via:
+
+        `adb shell am instrument -w -e class <test-class>#<testMethod> de.harheimertc.test/androidx.test.runner.AndroidJUnitRunner`
+
+        parallel `adb logcat -v time > /tmp/harheimertc_live_logcat.txt` laufen lassen, um vollständige Logs zu speichern.
+    - Falls UTP/ddmlib `SyncException` weiter auftritt: Gradle-Parallelität reduzieren, Test-Plugins (z. B. `AndroidTestLogcatPlugin`) temporär deaktivieren oder Tests in kleinere Gruppen splitten.
+- **Offene Test‑To‑Dos:**
+    - Reproduzierbaren Einzeltest-Run mit vollständigem `logcat` erfassen (derzeit vom Nutzer pausiert).
+    - Flaky Tests isolieren und Hilt/KSP-Setup prüfen, damit `HiltTestActivity`-Importe nicht mehr fehlschlagen.
+    - Langfristig: Tests aufteilen, flaky tests markieren und CI-Job für androidTests gegen UTP-Transient-Fehler härten.
+
 9) Dauerhaftes Android-Login: Architektur und Umsetzung
 - Stand der Umsetzung: Android-Logins erhalten ein ca. 15 Minuten gültiges JWT und eine serverseitig prüfbare Refresh-Sitzung; Access-Tokens mit Sitzungs-ID werden bei widerrufener Gerätesitzung abgelehnt. Web-Logins verwenden weiterhin das bisherige Cookie-JWT, bis ein browserseitiger Refresh-Flow ergänzt ist.
 - Ziel: Ein Benutzer bleibt auf einem bekannten Gerät angemeldet, ohne dass ein langfristig gültiges Bearer-JWT oder ein extrahierbares App-Secret verwendet wird.
@@ -224,3 +249,96 @@ Kurz: Ziel ist eine native Android-App mit Kotlin + Jetpack Compose, die die Web
 
 ---
 Datei: [ANDROID_KOTLIN_PLAN.md](ANDROID_KOTLIN_PLAN.md)
+
+**CMS-Verbesserungsplan (Analyse → Umsetzung)**
+
+Ziel: Alle `cms/*`-Screens von rudimentärem Status zu vollständigen, getesteten Admin-Tools weiterentwickeln. Fokus: Datenintegrität, Berechtigungen, bessere UI/UX, Offline-Verhalten und Tests.
+
+Kurzüberblick (3 Phasen):
+- Phase A — Analyse (1-2 Tage): Inventar aller CMS-Endpunkte, fehlende CRUD-Workflows identifizieren, Prioritäten setzen (News, Benutzer, Kontaktanfragen, Newsletter, Config). Ergebnis: Aufgabenliste mit Aufwandsschätzung.
+- Phase B — Implementierung MVP (1-2 Wochen): Kernfunktionen pro Bereich implementieren (News CRUD mit RichText-Vorschau, Benutzerliste + Rollen-Edit, Kontaktanfragen Detail & Antwort-Workflow, Newsletter-Gruppen-Management, Config-Editor inklusive Satzung-PDF-Feld). Unit- / Integrationstests für ViewModels.
+- Phase C — Harden, UX & Tests (1 Woche): Validierung, Fehlermeldungen, Offline-Caching (verschlüsselt für geschützte Daten), Compose-UI-Tests, Accessibility-, Performance-Feinschliff.
+
+Detaillierte Aufgaben (priorisiert):
+- A1: Audit `CmsViewModel`-State vs. Backend-Responses — fehlen Felder/Fehlerfälle? (bereits teilweise umgesetzt)
+- A2: Prüfen, ob API-Fehler (4xx/5xx) sauber an `FormMessages`/UI gemeldet werden — Standardisiere Fehlermeldungen.
+- A3: Prüfen, ob `NativeRichTextEditor` HTML speichert, das Web-Editor-kompatibel bleibt (Quill/HTML). Schreibe Roundtrip-Tests.
+- B1: News-Management
+    - B1.1: News-CRUD: Create/Update/Delete mit Vorschau (RichText-Preview) und Validierung (Titel Pflicht, Inhalt Mindestlänge)
+    - B1.2: Bulk-Aktionen: Sichtbar/Unsichtbar/ExpiresAt setzen
+    - B1.3: Unit-Tests für `NewsViewModel` + `CmsViewModel`-Integrationspfad
+- B2: Benutzer-Management
+    - B2.1: Rollen-Edit (admin/vorstand/trainer/newsletter) in `CmsBenutzerScreen` (Inline-Action oder Detail-Dialog)
+    - B2.2: Aktiv/Inaktiv Toggle + Resend-Invite (falls API unterstützt)
+    - B2.3: Tests: `CmsViewModel.users()` Verhalten bei Pagination/Leeren Listen
+- B3: Kontaktanfragen
+    - B3.1: Detailansicht mit Antwort-Option (falls Backend Mail-Sende-Endpunkt vorhanden)
+    - B3.2: Status-Filter (offen/beantwortet) und Bulk-Archiv
+- B4: Newsletter
+    - B4.1: Entwurf -> Senden Flow mit Preview (falls Backend zulässt)
+    - B4.2: Gruppenverwaltung (CRUD) + Subscribe/Unsubscribe-Preview
+- B5: Config / Seiten (Inhalte)
+    - B5.1: Sichern/Zurücksetzen von Seiteninhalten mit Undo-Hinweis
+    - B5.2: Satzung: PDF-Upload-Feld und native PDF-Viewer-Integration (falls serverseitig gespeichert)
+- B6: Diagnostics / Passwort-Reset-Diagnose
+    - B6.1: Detail-View mit exportierbaren Logs (bei Bedarf)
+- C1: Offline-/Caching-Strategie
+    - C1.1: Verschlüsseltes lokales Caching für CMS-Daten (EncryptedSharedPreferences/Room)
+    - C1.2: Sync-Strategie: lokale Änderungen buffernd senden, Konflikt-UI
+- C2: Tests & CI
+    - C2.1: ViewModel-Unit-Tests für alle CMS-Flows
+    - C2.2: Compose-UI-Tests für kritische Pfade (News erstellen, Benutzerrolle ändern, Config speichern)
+    - C2.3: androidTest Hilt-Stubs erweitern (falls nötig)
+
+Minor UX-Verbesserungen (parallel möglich):
+- konsistente Buttons/Labels (`Speichern` vs `Inhalt speichern`), Ladezustand-UI, einzeilige Success-/Error-Banner, Inline-Validierungen.
+
+Deliverables & Milestones:
+- M1 (nach Analyse): Priorisierte Aufgabenliste + Schätzung (mehrere PRs)
+- M2 (nach MVP-Implementierung): News + Benutzer + ContactRequests + Config Editor + Tests (smoke)
+- M3 (Final): Offline, UI-Tests, Accessibility, Performance
+
+Zeitplanung (empfohlen):
+- Analyse: 2 Arbeitstage
+- MVP-Implementierung: 7–10 Arbeitstage
+- Hardening + Tests: 3–5 Arbeitstage
+
+Wenn du willst, trage ich die einzelnen Subtickets in unserem lokalen Issue-Tracker (oder als separate TODOs) ein und beginne mit A1/A2.
+
+**TODO (zum Abhaken) — CMS-Implementierung**
+
+- [x] A1: Audit `CmsViewModel` vs Backend-Responses (Fehleraggregation implementiert)
+- [x] A2: Standardisiere API-Fehlerdarstellung in UI (`FormMessages` / globale Errors)
+- [x] A3: Roundtrip-Tests `NativeRichTextEditor` ↔ Backend-HTML (Kompatibilität / Quill)
+- [x] B1: News-Management
+    - [x] B1.1: News-CRUD (Create/Update/Delete) mit RichText-Vorschau
+    - [x] B1.2: Bulk-Aktionen (sichtbar/unsichtbar, expiresAt)
+    - [x] B1.3: Unit-Tests für `NewsViewModel`
+
+ - [x] B2: Benutzer-Management
+     - [x] B2.1: Rollen-Edit (Inline oder Detail-Dialog)
+     - [x] B2.2: Aktiv/Inaktiv Toggle, Resend-Invite
+     - [x] B2.3: Tests für Pagination/Leere Listen
+
+- [x] B3: Kontaktanfragen
+    - [x] B3.1: Detailansicht + Antwort-Option
+    - [x] B3.2: Status-Filter + Archiv
+
+- [ ] B4: Newsletter
+    - [ ] B4.1: Entwurf → Senden Flow mit Preview
+    - [ ] B4.2: Gruppenverwaltung (CRUD)
+
+- [ ] B5: Config / Seiten
+    - [ ] B5.1: Sichern/Zurücksetzen mit Undo
+    - [ ] B5.2: Satzung: PDF-Upload-Feld + native PDF-Viewer
+
+- [ ] B6: Diagnostics / Passwort-Reset-Diagnose (Export/Detail)
+
+- [ ] C1: Offline-/Caching-Strategie (verschlüsselt für geschützte CMS-Daten)
+- [ ] C2: Tests & CI
+    - [ ] C2.1: ViewModel-Unit-Tests für CMS-Flows (`CmsViewModel.load()` / `saveConfig()`)
+    - [ ] C2.2: Compose-UI-Tests für kritische Flows
+    - [ ] C2.3: androidTest Hilt-Stubs erweitern (falls nötig)
+
+Markiere die Items, wenn erledigt — ich kann die einzelnen Punkte jetzt in Branches/PRs umsetzen.
+