Speicher-Strategie

MistelMonitor setzt auf einen robusten Offline-First Ansatz, der verschiedene Speichertechnologien kombiniert, um Performance, Datensicherheit und Flexibilität zu gewährleisten.

1. Relationale Daten (SQLite)

Für die Kern-Daten der Anwendung nutzen wir SQLite (via sqflite). Dies ist notwendig, um die komplexen Beziehungen zwischen den Entitäten sowie geografische Abfragen performant abzubilden.

• Einsatzgebiet: Berichte, Events, Gruppen, Sektoren, Zonen, Depots.
• Warum SQLite?
  • Relationen: Ein Bericht gehört zu einem Event und einer Gruppe. Sektoren enthalten viele Bäume.
  • Geo-Daten: Wir speichern komplexe Polygone (Sektoren, Zonen) und führen einfache räumliche Abfragen durch.
  • Sicherheit: Transaktionssicherheit (ACID) verhindert Datenverlust bei Abstürzen.

Datenbank-Schema (Auszug)

Die zentrale Datei MistelMonitor.db enthält Tabellen wie:

• reports: Die eigentlichen Mistel-Meldungen (Baumart, Schweregrad, Geometrie).
• events: Definition von Aktionen (Zeitraum, Ort).
• sectors: Zugewiesene Arbeitsgebiete.
• images: Referenzen (Pfade) zu den Fotos im Dateisystem.

2. Einstellungen & State (SharedPreferences)

Für einfache Schlüssel-Wert-Paare nutzen wir SharedPreferences. Hier werden keine Geschäftsdaten gespeichert, sondern nur lokale Konfigurationen und temporäre Zustände.

• Einsatzgebiet:
  • User-Einstellungen: Gewählte Rolle (Scout/Admin), Spitzname, Theme-Präferenz.
  • Sync-Einstellungen: “Nur bei WLAN synchronisieren”, Backend-URL.
  • Session-State: Aktuell aktive Mission (um bei App-Neustart direkt dort weiterzumachen).
  • Tutorials: Flag, ob ein Intro bereits gezeigt wurde.

3. Binärdaten (Dateisystem)

Große Dateien wie Fotos und Audio-Notizen werden nicht in der Datenbank gespeichert, um diese schlank zu halten. Stattdessen liegen sie im geschützten Dateisystem der App (ApplicationDocumentsDirectory).

• Einsatzgebiet: Vorher-/Nachher-Fotos, Sprachmemos.
• Verknüpfung: In der SQLite-Datenbank (images Tabelle) wird nur der relative Pfad gespeichert (z.B. mistel_images/report_123_before.jpg).

Architektur-Übersicht

  graph TD
    User([Nutzer]) -->|Erstellt Bericht| Logic[Business Logic]
    
    subgraph "Lokaler Speicher"
        Logic -->|Speichert Daten| SQL[(SQLite DB)]
        Logic -->|Speichert Einstellungen| SP[[SharedPreferences]]
        Logic -->|Speichert Fotos| FS[Dateisystem]
    end

    SQL -.->|Referenziert Pfad| FS
    
    subgraph "Synchronisation"
        SQL <-->|JSON Data| API[SyncBox / Server]
        API <-->|SQLAlchemy| SDB[(Server DB)]
        FS <-->|Multipart Upload| API
    end

4. Server-Datenbank (SyncBox)

Die MistelBox (Backend) nutzt ebenfalls eine relationale Datenbank.

• Technologie: SQLAlchemy (ORM).
• Datenbank: Standardmäßig SQLite (mistel.db) für einfache Deployments (Raspberry Pi), kann aber auch mit PostgreSQL konfiguriert werden.
• Migrationen: Änderungen am Schema werden mit Alembic verwaltet.