Refactor code structure for improved readability and maintainability

docs/plan_diaryview.md

@@ -1,11 +1,15 @@
-# DiaryView Port Plan (statt direkter Komplett-Implementierung)
+# DiaryView Port: Umsetzungsstand Android
 
-## Entscheidung
-Die vollständige Rest-Portierung von `frontend/src/views/DiaryView.vue` in einem einzigen Durchlauf würde voraussichtlich **deutlich mehr als 40 Dateien** betreffen (UI-Module, Dialoge, Mapper/DTOs, Repository/Service/ViewModel-Erweiterungen, Socket-Handling, Strings, Tests, Doku).
+## Stand 2026-05-26
+Die priorisierten Funktionsblöcke A bis F sind in der nativen Android-Diary-Ansicht umgesetzt. Die Android-Oberflaeche bildet die Workflows mobilgerecht ab; sie kopiert nicht die Web-Anordnung pixelgenau.
 
-Daher wurde gemäß Vorgabe (`Wenn mehr nötig: /docs/plan_diaryview.md statt Änderungen`) **kein weiterer Code geändert**.
+- Plan: Haupt- und Gruppenaktivitaeten anlegen, bearbeiten, zuordnen, sortieren und loeschen; Zeitbloecke; Gruppenfilter und Bereitschaftsstatus.
+- Teilnehmer: Status/Gruppe, Testmitglied-Schnellanlage, Formular-Uebergabe, erweiterte Suche und letzte Teilnahmen.
+- Gruppen: Anlegen (auch mehrere), Umbenennen/Lead bearbeiten und bestaetigtes Loeschen.
+- Medien/Export: Galerie, Aktivitaetsbilder, Court-Drawing-Editor mit Schlagsequenzen; vorhandene Zeichnungen werden per Icon in einem Dialog angezeigt; Tages-PDF inklusive Gruppen-/Teilnehmerzuordnung.
+- Sicherheit/Livedaten: Loeschen eines Trainingstags nur leer und nach Bestaetigung; Diary-relevante Aktualisierungen bleiben in der vorhandenen Live-Aktualisierung.
 
-## 1) Analyse von `DiaryView.vue`
+## Web-Referenz
 
 ### Verwendete Components
 - `CourtDrawingRender`
@@ -34,8 +38,7 @@ Daher wurde gemäß Vorgabe (`Wenn mehr nötig: /docs/plan_diaryview.md statt Ä
   - `currentClub`
   - `currentClubName`
 
-### API-Aufrufe (relevant für Rest-Port)
-Bereits in Android teilweise umgesetzt, aber für Vollparität fehlen weiterhin größere Blöcke:
+### API-Aufrufe
 - Diary Core: `/diary/{clubId}` (GET/POST/PUT/DELETE)
 - Participants: `/participants/*`, `/participants/{dateId}/{memberId}/group`
 - Activities: `/activities/{dateId}`, `/activities/add`
@@ -56,45 +59,40 @@ Bereits in Android teilweise umgesetzt, aber für Vollparität fehlen weiterhin
 - Member: `member:changed`
 - Group: `group:changed`
 
-## 2) Warum >40 Dateien realistisch sind
-Für „möglichst 1:1 Web-Funktionalität“ müssen zusätzlich zu bestehendem Stand mindestens folgende Pakete ausgebaut werden:
-- Mehrere dedizierte Compose-Dialoge (Drawing, Notes, Tag-Historie, Activity-Stats, Accident, QuickAdd, Gallery, Image/Confirm/Info)
-- Umfangreiche VM-State-Modelle pro Dialog/Tab/Flow
-- Zusätzliche Repository-Modelle und Mapper für Group-Activities, Member-Activities, Accident, Gallery/Image-Modelle
-- Socket-Event-spezifische State-Synchronisation im Diary-Flow
-- Zusätzliche Strings/Testfälle für viele Spezialpfade
+## Mobile Abbildung
+Die Umsetzung bleibt bewusst in den vorhandenen Compose- und Shared-Bausteinen. Neue, eigenstaendige UI-Bausteine sind insbesondere `DiaryCourtDrawing.kt` sowie ausgelagerte Diary-Dialog-/Toolbar-Composables in `AppRoot.kt`. Die Shared-DTOs akzeptieren Drawing-Daten auch fuer eingebettete Planaktivitaeten.
 
-Damit ist die 40-Dateien-Grenze in einem „alles in einem Durchlauf“-Block nicht sinnvoll einhaltbar, ohne die geforderte 1:1-Funktionalität zu unterlaufen.
+## Umsetzungsbloecke
 
-## 3) Empfohlene Umsetzungsblöcke (priorisiert)
-
-### Block A: Training-Plan Vollständigkeit
+### Block A: Training-Plan Vollstaendigkeit - umgesetzt
 - Group-Activities (`/diary-date-activities/group*`)
 - Activity-Member-Zuordnung (`/diary-member-activities/*`)
 - Plan-Item Group-Update, Duration/DurationText vollständig
-- Drag&Drop-Reorder final
+- Reihenfolge per mobil geeigneten Hoch-/Runter-Aktionen
 
-### Block B: Teilnehmer- und Mitglieder-Dialoge
+### Block B: Teilnehmer- und Mitglieder-Dialoge - umgesetzt
 - MemberNotesDialog-Äquivalent (inkl. Tag-Zuordnung auf Member+Date)
 - QuickAddMemberDialog inkl. `clubmembers/set`
-- Tag-History und Activity-Stats Dialoge
+- Activity-Stats mit letzten Teilnahmen; die im Web-Template verbliebene `TagHistoryDialog`-Deklaration ist dort aus der sichtbaren Teilnehmeraktion nicht erreichbar (`openTagInfos` oeffnet die Statistik)
 
-### Block C: Gruppenverwaltung + Vorschlagslogik
+### Block C: Gruppenverwaltung + Vorschlagslogik - umgesetzt
 - Gruppen CRUD (`/group*`) inklusive Lead
 - New-Date Dialog mit TrainingGroup/TrainingTimes-Vorschlag
 
-### Block D: Bilder/Galerie + Export
+### Block D: Bilder/Galerie + Export - umgesetzt
 - MemberGalleryDialog + Bildaufrufe
 - ImageDialog
 - TrainingDay PDF-Export (oder Android-kompatible Alternative)
 
-### Block E: Accident + Drawing
+### Block E: Accident + Drawing - umgesetzt
 - AccidentFormDialog (`/accident*`)
-- CourtDrawingDialog/Render-Flow mit PredefinedActivity-Sync
+- CourtDrawingDialog/Render-Flow mit bis zu vier Folgeschlaegen, PredefinedActivity-Sync und Listeneintrag-Icon statt Inline-Zeichnung
 
-### Block F: Socket-Live-Updates
+### Block F: Socket-Live-Updates - umgesetzt
 - Nur Diary-relevante Event-Subsets robust in VM integrieren
 - Dokumentation in `/docs/socket_contract.md`
 
-## 4) Konkreter nächster Umsetzungsschritt
-Wenn du fortsetzen möchtest, starte mit **Block A** (Training-Plan Vollständigkeit), da er den größten funktionalen Mehrwert für den täglichen Diary-Betrieb liefert und auf dem bereits migrierten Stand aufsetzt.
+## Verifikation
+- Android-Compile: `./gradlew :composeApp:compileDebugKotlinAndroid`
+- Shared DTO Regression: `DiaryDrawingSerializationTest`
+- Manuelle Diary-Faelle: `mobile-app/REGRESSION_CHECKLIST.md`