feat: verbesserte Netzwerkfähigkeit und Chat-Test integriert
- **Discovery:** Unterstützung für Multi-Interface-Broadcast und manuelle IP-Eingabe. - **UI:** Chat-Test für Verbindungsprüfung hinzugefügt. - **ViewModel:** Datenübertragungslogik (Ping/Pong, Chat) implementiert. - **Workflow:** Windows-MSI-Build als separaten Job hinzugefügt. Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -1,20 +1,33 @@
|
||||
# ADR-0027: Netzwerk-Discovery & Interface-Binding
|
||||
|
||||
## Status
|
||||
In Prüfung (Wartet auf PoC)
|
||||
|
||||
Akzeptiert & Implementiert (05.05.2026)
|
||||
|
||||
## Kontext
|
||||
Desktop-Rechner auf Turnieren sind oft mit mehreren Netzwerken gleichzeitig verbunden (z.B. LAN für das Turnier-Netzwerk, WLAN für Internet-Hotspot). Automatische Discovery-Dienste (JmDNS) wählen ohne explizite Konfiguration oft das falsche Interface, wodurch sich Clients und Master nicht finden.
|
||||
|
||||
Desktop-Rechner auf Turnieren sind oft mit mehreren Netzwerken gleichzeitig verbunden (z.B. LAN für das
|
||||
Turnier-Netzwerk, WLAN für Internet-Hotspot). Automatische Discovery-Dienste (mDNS) wählen ohne explizite Konfiguration
|
||||
oft ein Interface, das für die anderen Teilnehmer nicht erreichbar ist (Bridging-Probleme zwischen LAN und WLAN). Zudem
|
||||
blockieren einige Router Multicast-Pakete zwischen WLAN und LAN-Segmenten.
|
||||
|
||||
## Entscheidung
|
||||
Wir führen ein explizites Netzwerk-Management für die Initialisierung ein.
|
||||
|
||||
1. **Interface-Selektion:** Der Benutzer muss bei der technischen Initialisierung explizit wählen, über welches Netzwerk-Interface (IP-Adresse/Adapter) die App kommunizieren soll. Die UI zeigt hierfür benutzerfreundliche Namen (WLAN, Ethernet) an.
|
||||
2. **Geführte Discovery:** Sobald ein Interface gewählt ist, startet ein "Radar-Modus". Dieser scannt aktiv via JmDNS nach vorhandenen Master-Geräten.
|
||||
3. **Adaptive Rolle:** Findet die Discovery einen Master, wird dem Benutzer die Rolle "Client" vorgeschlagen. Die UI bleibt jedoch flexibel für manuelle Rollenwechsel.
|
||||
4. **Fokus-Management:** Nach Auswahl der Rolle wird der Fokus automatisch in das erste relevante Eingabefeld (Gerätename) gesetzt, um einen reibungslosen Workflow zu ermöglichen.
|
||||
Wir führen ein robustes, mehrstufiges Netzwerk-Management für die Initialisierung ein:
|
||||
|
||||
1. **Multi-Interface Broadcast:** Der Master registriert seinen Dienst proaktiv auf **allen** verfügbaren
|
||||
Netzwerk-Interfaces (IPv4). Dies erhöht die Chance massiv, dass Clients in verschiedenen Segmenten (WLAN/LAN) den
|
||||
Master finden.
|
||||
2. **Interface-Selektion:** Der Benutzer kann weiterhin ein bevorzugtes Interface wählen. Die Master-Info-Card zeigt die
|
||||
Erreichbarkeit transparent an.
|
||||
3. **Manueller IP-Fallback:** Wenn mDNS fehlschlägt, kann die IP des Masters manuell eingegeben werden. Dies ist der "
|
||||
Ultima-Ratio"-Weg für restriktive Netzwerke.
|
||||
4. **Konnektivitäts-Check (Chat & Self-Test):** Nach dem Handshake wird ein Modal geöffnet, das einen automatischen
|
||||
Ping-Pong Test durchführt und einen Test-Chat bietet. Dies verifiziert die reale Datenübertragung (Serialisierung,
|
||||
WebSockets) noch vor Abschluss des Setups.
|
||||
|
||||
## Konsequenzen
|
||||
- Verhindert "Geistersuchen" im falschen Netzwerk.
|
||||
- Erhöht die Benutzerfreundlichkeit durch automatische Vorschläge.
|
||||
- Erfordert Zugriff auf System-Netzwerk-APIs in der Desktop-Shell.
|
||||
|
||||
- Deutlich höhere Stabilität in heterogenen Netzwerkumgebungen.
|
||||
- Transparenteres Feedback für den Anwender bei Verbindungsproblemen.
|
||||
- Der Chat dient als "Connectivity-Proof" für das Support-Personal vor Ort.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### Journal: 05.05.2026 - Build & Packaging Issues
|
||||
|
||||
**Status:** Verifiziert
|
||||
|
||||
**Problem:**
|
||||
Der User versuchte einen Windows-Installer (.msi) auf einem Linux-System zu bauen. Gradle meldete 'BUILD SUCCESSFUL',
|
||||
aber es wurde kein Artefakt erzeugt.
|
||||
|
||||
**Ursache:**
|
||||
Das Compose Multiplatform Plugin kann native Installer (MSI, DMG, DEB) nur auf dem jeweiligen Ziel-Betriebssystem bauen.
|
||||
Auf Linux wird der Task zwar angeboten, führt aber zu keinem Ergebnis, da die nativen Windows-Tools (WiX Toolset)
|
||||
fehlen.
|
||||
|
||||
**Lösung/Workaround:**
|
||||
|
||||
1. Für Linux wurde erfolgreich ein Paket erzeugt: .
|
||||
2. Für Windows (.msi) muss der Build zwingend auf einer Windows-Maschine ausgeführt werden.
|
||||
3. Empfehlung: Einrichtung einer Cross-Platform CI/CD Pipeline.
|
||||
|
||||
**Badge:** 🏗️ [Lead Architect] & 🐧 [DevOps Engineer]
|
||||
@@ -0,0 +1,42 @@
|
||||
# Journal-Eintrag: 05.05.2026 - Connectivity-Fix & Code-Qualität
|
||||
|
||||
## Kontext
|
||||
|
||||
Nach einem fehlgeschlagenen Hardware-Test am 30.04.2026 wurde die Netzwerk-Konnektivität zwischen LAN und WLAN als
|
||||
kritische Schwachstelle identifiziert. Zudem gab es erhebliche Mängel in der Code-Qualität (JVM-Leaks in KMP,
|
||||
Syntax-Fehler).
|
||||
|
||||
## Durchgeführte Arbeiten
|
||||
|
||||
### 1. 🧹 Code-Sanierung (Clean Code & KMP)
|
||||
|
||||
- **ViewModel Fix:** Sämtliche `java.*` und `System.*` Referenzen aus `commonMain` entfernt.
|
||||
- **Zeitstempel:** Nutzung der idiomatischen `kotlin.time.Clock` (Kotlin 2.3.20) statt `System.currentTimeMillis()`.
|
||||
- **Compose UI:** Behebung von Syntax-Fehlern in `DeviceInitializationScreen.kt` (LazyColumn Iteration und Imports).
|
||||
- **Typsicherheit:** Explizite Typisierung in UI-Komponenten zur Vermeidung von Destrukturierungsfehlern.
|
||||
|
||||
### 2. 📡 Netzwerk-Stabilität
|
||||
|
||||
- **Multi-Interface Discovery:** Der `JmDnsDiscoveryService` registriert Dienste nun auf allen verfügbaren
|
||||
IPv4-Interfaces gleichzeitig. Dies löst das Problem, dass Master-Geräte in LAN/WLAN-Mischumgebungen nicht gefunden
|
||||
werden.
|
||||
- **Manueller Fallback:** Einführung eines IP-Eingabefelds im Setup-Wizard für den Fall, dass mDNS durch Router
|
||||
blockiert wird.
|
||||
- **Master-Info-Card:** Anzeige der eigenen IP-Adresse auf dem Host-Gerät zur Erleichterung der manuellen Verbindung.
|
||||
|
||||
### 3. 💬 Interaktiver Connectivity-Check
|
||||
|
||||
- **Chat-Modal:** Implementierung eines Pop-ups nach dem Handshake.
|
||||
- **Self-Test:** Automatischer Ping-Pong Test beim Öffnen des Modals zur Verifizierung der WebSocket-Verbindung.
|
||||
- **Test-Chat:** Ermöglicht den manuellen Austausch von Nachrichten als definitiven Beweis für eine stabile
|
||||
Datenverbindung.
|
||||
|
||||
## Status: Verifiziert & Bereit für Hardware-Test
|
||||
|
||||
Alle identifizierten Kompilierungsfehler (einschließlich Koin-Modul Typkonflikte) wurden behoben. Der Code folgt den
|
||||
KMP-Standards für Kotlin 2.3.20. Die Architektur entspricht nun ADR-0027.
|
||||
|
||||
**🏗️ [Lead Architect]**
|
||||
**👷 [Backend Developer]**
|
||||
**🎨 [Frontend Expert]**
|
||||
**🧹 [Curator]**
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
type: Journal
|
||||
status: COMPLETED
|
||||
owner: Curator
|
||||
date: 2026-05-05
|
||||
---
|
||||
|
||||
# 🧹 [Curator] Journal: Frühjahrsputz in der Dokumentation
|
||||
|
||||
**Datum:** 5. Mai 2026
|
||||
|
||||
## 🎯 Zielsetzung
|
||||
|
||||
Bereinigung der Dokumentationsstruktur (`docs/`), Archivierung veralteter Chat-Verläufe und Berichte, sowie
|
||||
Konsolidierung von Assets und Event-Daten zur Wiederherstellung der Übersichtlichkeit.
|
||||
|
||||
## 🛠️ Durchgeführte Maßnahmen
|
||||
|
||||
### 1. Radikale Archivierung
|
||||
|
||||
- **`docs/temp/`**: Alle Dateien (viele veraltete Blueprints und Chat-Logs) wurden nach `docs/_archive/temp_2026-05-05/`
|
||||
verschoben.
|
||||
- **`docs/90_Reports/`**: Berichte, die älter als April 2026 sind, wurden in den Unterordner `_archive/` verschoben.
|
||||
- **`docs/99_Journal/`**: Das Journal war mit über 100 Einträgen überladen. Alle Einträge aus dem April 2026 (und
|
||||
früher) wurden nach `docs/99_Journal/_archive/` verschoben. Das Hauptverzeichnis ist nun bereit für die Einträge im
|
||||
Mai.
|
||||
|
||||
### 2. Strukturierung & Konsolidierung
|
||||
|
||||
- **Screenshots**: Das lose Verzeichnis `docs/ScreenShots/` wurde nach `docs/80_Assets/Screenshots/` verschoben, um es
|
||||
in die Asset-Hierarchie einzugliedern.
|
||||
- **Event-Daten**: Spezifische Turnierdaten (`Neumarkt2026`, `St-Poetlen-Hart-2026`) wurden unter
|
||||
`docs/03_Domain/Events/` gruppiert.
|
||||
- **Architektur-Bereinigung**: Das Verzeichnis `docs/01_Architecture/` wurde restrukturiert. Veraltete Roadmaps wurden
|
||||
archiviert, und aktive Dokumente wurden in Unterkategorien (`Concepts/`, `Specifications/`, `Roadmaps/`,
|
||||
`Checklists/`) sortiert.
|
||||
- **Redundanz-Eliminierung**: Veraltete/redundante Ordner (`docs/Bin/`, `docs/BilderSuDo/`) und das fälschlich angelegte
|
||||
Verzeichnis `mocode/` wurden entfernt. Ein verirrtes Journal-Fragment wurde ins Archiv überführt.
|
||||
|
||||
### 3. Integritäts-Check
|
||||
|
||||
- Die `MASTER_ROADMAP.md` wurde als zentrales Steuerungsdokument verifiziert und alle internen Links auf die neue
|
||||
Struktur angepasst.
|
||||
- Die Agenten-Richtlinien in `AGENTS.md` bleiben die Basis für alle weiteren Sessions.
|
||||
|
||||
## 📊 Status Quo
|
||||
|
||||
- **Dokumentations-Health:** ✅ GRÜN (Aufgeräumt)
|
||||
- **Archiv-Integrität:** ✅ Vorhanden
|
||||
- **Nächste Schritte:** Fokus zurück auf die fachliche Implementierung der Turnier-Hierarchie (Meilenstein 1 der
|
||||
Roadmap).
|
||||
|
||||
---
|
||||
*Unterzeichnet vom Curator am 05.05.2026*
|
||||
Reference in New Issue
Block a user