Offline- und Read-Only-Modus Richtlinie¶

Grundsatz¶

Beim Erstellen oder Refactoring von Systemen muss immer geprüft werden, ob ein Offline- oder Read-Only-Modus sinnvoll ist. Besonders wichtig ist dies, wenn das System in einen Kontext eingebunden wird, der bereits Offline-Betrieb untersützt.

Ein System, das ohne Netzwerk abstürzt oder unbenutzbar wird, ist ein Fehler im Design.

Wann ist ein Offline-Modus relevant?¶

Das System greift auf Cloud-Dienste zu (z.B. GitHub API, S3, R2)
Das System synchronisiert Daten zwischen lokalem und entferntem Speicher
Das System zeigt Inhalte an, die aus dem Netzwerk geladen werden

Wann ist ein Read-Only-Modus relevant?¶

Das System bearbeitet Daten, die mit einem Cloud-Dienst synchronisiert werden
Schreiboperationen ohne Netzwerk könnten zu Datenverlust oder Konflikten führen
Das System kann dem Nutzer trotzdem lokal gespeicherte Daten anzeigen

Netzwerkstatus prüfen¶

Der aktuelle Netzwerkstatus wird über AppState verwaltet:

from src.shared_services.state.app_state import AppState

state = AppState.instance()

# Einmalig prüfen
if state.is_network_connected:
    # Online-Logik
else:
    # Offline-Logik

# Reaktiv auf Änderungen reagieren
state.network_status_changed.connect(self._on_network_changed)

def _on_network_changed(self, connected: bool) -> None:
    if connected:
        # Wieder online
    else:
        # Offline-Modus aktivieren

Checkliste bei neuem System / Refactoring¶

[ ] Funktioniert das System ohne Netzwerk oder geht es in einen sinnvollen Fallback?
[ ] Werden dem Nutzer klare Hinweise angezeigt, wenn Funktionen offline nicht verfügbar sind?
[ ] Werden lokal verfügbare Daten weiterhin angezeigt (Read-Only)?
[ ] Wird der network_status_changed Signal genutzt, um auf Statusänderungen zu reagieren?