MABEA/ergebnisse/17_mobile_offline.md

Prompt 17 – Mobile und Offline-Nutzung

Bezug: 11_kontroll_ui, Karte 06_geraet_pc_mobil. Rein fachliches Konzept, keine Technologiewahl (folgt Prompt 19).

1. Ausgangslage

Rettungsdienst/KatS-Umfeld: wechselnde Fahrzeuge/Wachen, Netzabdeckung nicht durchgängig gesichert (Annahme aus Prompt 01). Kontrolle darf nicht an fehlendem Netz scheitern.

2. Bewertung: braucht V1 echtes Offline?

• Voll-Offline (mehrstündig, mit späterer Synchronisierung inkl. Konfliktlösung) ist komplex und erhöht MVP-Umfang erheblich (Grundprinzip: V1 klein halten).
• Praxisrelevanter Fall ist eher kurzzeitiger Netzausfall/-lücke während einer laufenden Kontrolle, nicht stundenlange Komplett-Offline-Nutzung ganzer Wachen.
• Entscheidung: V1 unterstützt robuste Kurzzeit-Unterbrechung (siehe 3.), aber KEIN vollwertiges Offline-Konzept mit Mehrgeräte-Konfliktlösung. Vollwertiges Offline = Roadmap (Prompt 24).

3. Konzept für V1 (Kurzzeit-Netzausfall)

• Eingaben in der Kontroll-UI (Prompt 11) werden lokal im Gerät zwischengespeichert, sobald eingegeben – nicht erst bei Übertragung an Server verworfen, wenn Verbindung kurz fehlt.
• Bei wiederhergestellter Verbindung: automatische Übertragung der zwischengespeicherten Eingaben, ohne dass Mitarbeiter erneut eintippen muss.
• Deutliche Statusanzeige in der UI: „nicht gespeichert/wird übertragen" vs. „gespeichert" je Position, damit Mitarbeiter erkennt, ob Eintrag schon serverseitig gesichert ist.
• Kontrolle kann nicht abgeschlossen werden (Prompt 16), solange nicht alle Positionen serverseitig bestätigt gespeichert sind – Abschluss-Button wartet/blockiert mit Hinweis, statt fälschlich „abgeschlossen" bei unvollständiger Übertragung zu melden.

4. Was V1 NICHT leisten muss

• Mehrstündige Offline-Nutzung ohne jede Verbindung.
• Bearbeitung derselben Kontrolle durch mehrere Geräte gleichzeitig mit Konfliktauflösung (ohnehin in Prompt 02 ausgeschlossen: eine Kontrolle = eine Person zu einem Zeitpunkt).
• Vollständige lokale Kopie des Materialstamms/aller Objekte für Offline-Betrieb.

5. Kennzeichnung nicht synchronisierter Daten

• Solange lokale Zwischenspeicherung nicht bestätigt an Server übertragen ist: eindeutiges visuelles Merkmal (z. B. Uhr-Symbol) an betroffenen Positionen/Kontrolle in der UI.
• Kein „stiller" Datenverlust: Verbindungsabbruch mitten in Eingabe darf Eingabe nicht kommentarlos verwerfen.

6. Roadmap-Erweiterung (Prompt 24)

• Echtes Offline-Modell (z. B. ganze Schicht ohne Netz arbeiten, spätere Synchronisierung mehrerer Geräte, Konfliktbehandlung bei parallelen Änderungen) als spätere Ausbaustufe, sobald reale Nutzung zeigt, ob Bedarf über Kurzzeit-Unterbrechung hinausgeht.
• Technisch möglicher Weg dahin (unverbindliche Notiz, Entscheidung erst Prompt 19): App (native oder PWA mit Service Worker) mit lokaler Datenhaltung auf dem Gerät, Synchronisierung bei wiederhergestellter Verbindung. Erfordert lokale Kopie relevanter Stammdaten (Materialstamm/Objekte des Nutzers) sowie Konfliktlösung bei paralleler Bearbeitung.

7. Erweiterung: Satelliten-Server bei längerem/vollständigem Internetausfall (Karte 13, Nutzerentscheidung)

Über die reine Kurzzeit-Unterbrechung (Punkt 3) hinaus wurde eine zweite, unabhängige Lösung für längere oder vollständige Trennung vom Hauptserver entschieden – relevant vor allem für KatS-Einsatzlagen (Zeltlager/Einsatzort ohne Internet) und Wachen mit dauerhaft schlechter Anbindung.

• Ansatz: Kein Client-seitiges Offline-Caching für diesen Fall, sondern ein Satelliten-Server – ein vollwertiger, kleiner Klon des Hauptservers (gleiche Software/API/Datenbank), der lokal am Einsatzort/an der Wache läuft.
• Autark-Dauer: bewusst nicht zeitlich begrenzt (kann Stunden bis mehrere Tage/unbestimmt sein) – kein System-Zwang zur Rücksynchronisation nach fester Frist.
• Mehrbenutzerfähigkeit: mehrere Mitarbeiter können gleichzeitig am selben Satelliten arbeiten, da dieser funktional wie ein eigener Hauptserver arbeitet (keine reine Cache-Lösung).
• Konfliktvermeidung statt Konfliktlösung: jedes Objekt ist während der Trennung exakt einem Server (Haupt- oder Satellit) fest zugeordnet und am jeweils anderen für Schreibzugriffe gesperrt. Dadurch entstehen strukturell keine Synchronisationskonflikte.
• Details, offene Punkte (Auslagerungs-Auslöser, Stammdaten-Vorbereitung des Satelliten, Hardware) siehe 13_satelliten_server.
• Abgrenzung zu Punkt 3: Kurzzeit-Pufferung im Browser bleibt für kurze Netzlücken während einer einzelnen Kontrolle; Satelliten-Server ist die Lösung für ganze Standorte/Einsatzorte über längere Zeiträume.

Referenzen

Bezug: 11_kontroll_ui Arbeitskarten: 06_geraet_pc_mobil, 13_satelliten_server