Die Wetter‑App als Paket integrieren: Herausforderungen, Stolpersteine und die finale Lösung

Die Integration der Wettervorhersage‑App in die Gebäudedaten‑App war einer der anspruchsvollsten Schritte des gesamten Projekts. Obwohl beide Apps modular aufgebaut sind, war es keineswegs trivial, die Wetter‑App als vollständiges, eigenständiges Paket in die Visualisierung einzubinden. Dieser Artikel dokumentiert den gesamten Prozess — inklusive der Probleme, die unterwegs aufgetreten sind, und der Lösungen, die letztlich zu einer stabilen, sauberen Integration geführt haben.

Damit dient dieser Artikel als technischer Erfahrungsbericht, als Dokumentation und als Referenz für alle, die ähnliche Projekte planen.

Ziel der Integration

Die Wetter‑App sollte:

  • unverändert in die Gebäudedaten‑App übernommen werden
  • als eigenes Modul funktionieren
  • keine Konflikte mit bestehenden Screens, KV‑Layouts oder Services verursachen
  • über den Startscreen erreichbar sein
  • denselben ScreenManager nutzen
  • keine Änderungen am bestehenden Gebäudedaten‑Code erzwingen

Kurz:
Die Wetter‑App sollte sich wie ein Plug‑in verhalten.

Ausgangssituation

Die Wetter‑App war ein eigenständiges Projekt mit:

  • eigenem ForecastScreen
  • eigenem weatherapp/‑Paket
  • eigenen Services (WeatherReader, WeatherApiClient, WeatherParser)
  • eigener KV‑Datei (visualizer.kv)
  • eigenem Icon‑Downloader
  • eigener Konfiguration (settings.py)

Die Gebäudedaten‑App hatte:

  • eine klare Screen‑Struktur
  • einen zentralen AppState
  • eigene KV‑Layouts
  • eigene Services
  • eine SQLite‑Datenbank
  • eine lineare Navigation

Beide Projekte mussten zusammengeführt werden, ohne dass eines das andere beschädigt.

Die größten Herausforderungen

1. Paketstruktur und Import‑Pfadprobleme

Die Wetter‑App war ursprünglich ein Standalone‑Projekt.
Beim Einbinden in die Gebäudedaten‑App traten typische Python‑Importprobleme auf:

  • relative Importe funktionierten nicht mehr
  • KV‑Dateien wurden nicht gefunden
  • Services konnten ihre Module nicht mehr auflösen
  • der Icon‑Downloader suchte Pfade relativ zum falschen Arbeitsverzeichnis

Lösung:
Die Wetter‑App wurde als vollständiges Paket weatherapp/ in das Projekt kopiert.
Alle Importe wurden auf absolute Paketpfade umgestellt:

from weatherapp.services.weather_reader import WeatherReader

Damit war das Paket stabil eingebunden.

2. KV‑Dateien und Kivy‑Suchpfade

Kivy lädt .kv‑Dateien standardmäßig relativ zum Arbeitsverzeichnis.
Das führte zu:

  • „File not found“
  • „ParserException“
  • fehlenden Widgets

Lösung:
Alle KV‑Dateien wurden über absolute Pfade geladen:

KV_PATH = Path(__file__).resolve().parent.parent / "ui" / "visualizer.kv"
Builder.load_file(str(KV_PATH))

Damit war die Wetter‑UI unabhängig vom Startverzeichnis.

3. Konflikte im ScreenManager

Beide Apps hatten:

  • eigene Screens
  • eigene Navigationslogik
  • eigene Back‑Navigation

Die Wetter‑App durfte:

  • nicht den AppState der Gebäudedaten‑App verändern
  • nicht die Navigation der Gebäudedaten‑App überschreiben
  • nicht eigene ScreenManager erzeugen

Lösung:
Der ForecastScreen wurde als zusätzlicher Screen in den bestehenden ScreenManager eingefügt:

weather_settings = Settings()
sm.add_widget(ForecastScreen(settings=weather_settings, name="weather"))

Damit war die Wetter‑App vollständig integriert, ohne eigene Navigation.

4. Ressourcen‑Pfadprobleme (Icons, Diagramme)

Die Wetter‑App lädt Icons dynamisch herunter.
Dabei traten Probleme auf:

  • falsche Speicherpfade
  • fehlende Schreibrechte
  • Icons wurden im falschen Ordner abgelegt
  • Diagramme wurden nicht gefunden

Lösung:
Ein zentraler assets/‑Ordner wurde definiert, und alle Pfade wurden vereinheitlicht.

5. Kivy‑Namenskonflikte

Beide Apps hatten Widgets mit ähnlichen IDs:

  • header
  • content
  • scroll

Das führte zu:

  • „Duplicate id“
  • „Widget not found“
  • UI‑Fehlern

Lösung:
Die Wetter‑App erhielt eindeutige ID‑Präfixe, z. B.:

  • weather_header
  • weather_scroll
  • weather_icon_box

Damit waren alle Konflikte beseitigt.

Die finale Integration

Nach allen Anpassungen bestand die Integration aus nur einer einzigen Zeile in app.py:

sm.add_widget(ForecastScreen(settings=weather_settings, name="weather"))

Aber der Weg dahin war deutlich länger — und genau deshalb ist dieser Artikel wichtig.

Was dieser Artikel dokumentiert

Dieser Artikel fasst zusammen:

  • warum die Integration nicht trivial war
  • welche Probleme auftraten
  • wie sie gelöst wurden
  • wie die Wetter‑App heute als Paket funktioniert
  • wie du ähnliche Module in Zukunft integrieren kannst

Nächste Schritte

Wenn du lernen willst, wie man schlussendlich ein Modul aus der App macht, schau dir diesen Artikel an

Veröffentlicht in Uncategorized.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mit der Nutzung dieses Formulars erklärst du dich mit der Speicherung und Verarbeitung deiner Daten durch die Website einverstanden.