Allround-Blog

ein buntes Themenspektrum

Deine Flutter Wetter-App: Schritt für Schritt – Teil 6

Teil 6: Grünland im Blick – Die Grünlandtemperatursumme (GTS) berechnen und anzeigen

Hallo und herzlich willkommen zum sechsten und vorerst letzten Teil unserer Kernserie zur Flutter Wetter-App!

In den vorherigen Teilen haben wir eine Menge geschafft: von der Anzeige der aktuellen Temperatur über die Adresssuche bis hin zur Visualisierung des Temperaturverlaufs als Diagramm. Unsere App wird immer nützlicher!

Heute krönen wir das Ganze mit einer Spezialfunktion: der Berechnung und Anzeige der Grünlandtemperatursumme (GTS). Dieser agrarmeteorologische Wert ist besonders für Landwirte und Gärtner interessant, da er Aufschluss über den Vegetationsbeginn im Frühjahr gibt. Aber auch für Naturinteressierte ist es eine spannende Ergänzung.

Das Ziel für heute:

  • Wir verstehen, was die Grünlandtemperatursumme ist und wie sie berechnet wird.
  • Wir lernen, wie man historische Wetterdaten von einem anderen Endpunkt der Open-Meteo API (der Archiv-API) abruft.
  • Wir implementieren die Berechnungslogik für die GTS, inklusive der Monatsfaktoren.
  • Wir integrieren einen Caching-Mechanismus, um nicht bei jedem App-Start die gesamten historischen Daten neu laden zu müssen.
  • Wir erstellen ein neues Widget, um die GTS ansprechend darzustellen.

Warum GTS?

Die GTS ist ein gutes Beispiel dafür, wie man mit Flutter und externen APIs auch spezifischere, fachliche Anforderungen umsetzen kann. Es erfordert Datenabruf, Datenverarbeitung und eine klare Logik.

Schritt 1: Den Code für Teil 6 holen

Wie immer findest du den Code für diesen Teil im Git-Repository.

  1. Öffne ein Terminal in deinem Projektordner (flutter_weather_app_blog).
  2. Sichere lokale Änderungen, falls vorhanden.
  3. Wechsle zum main-Branch und aktualisiere:
    git checkout main
    git pull origin main

  4. Checke den Code-Stand für Teil 6 aus: (Tag-Name ggf. anpassen)
    git checkout part6-gts-calculation

  5. Abhängigkeiten holen & Code generieren:
    flutter pub get

    dart run build_runner build --delete-conflicting-outputs

Öffne das Projekt in VS Code.

Schritt 2: Was ist die Grünlandtemperatursumme (GTS)?

Die GTS ist die Summe der positiven Tagesmitteltemperaturen (oberhalb von 0°C), die ab Jahresbeginn anfallen. Dabei werden die Werte im Januar mit dem Faktor 0,5 und im Februar mit 0,75 gewichtet. Ab März zählt jeder positive Tagesmittelwert voll (Faktor 1,0). Ein bestimmter Schwellenwert der GTS (oft um 200 °Cd – Grad Celsius Tage) signalisiert den nachhaltigen Beginn der Vegetationsperiode.

Berechnung: GTS = Σ (Tagesmittel – 0°C) * Monatsfaktor (Nur für Tage mit Tagesmittel > 0°C)

Schritt 3: Die Datenquelle – Open-Meteo Archiv-API

Um die GTS zu berechnen, benötigen wir die täglichen Durchschnittstemperaturen seit dem 1. Januar des aktuellen Jahres. Die normale Forecast-API von Open-Meteo liefert historische Daten nur für einen begrenzten Zeitraum (z.B. die letzten 7-90 Tage). Für längere historische Zeitreihen bietet Open-Meteo eine separate Archiv-API.

  • Neue API-Endpunkte (lib/src/core/constants/app_constants.dart):
    • Wir haben Konstanten für die Basis-URL und den Endpunkt der Archiv-API hinzugefügt:
      static const String openMeteoArchiveApiBaseUrl = 'archive-api.open-meteo.com';
      static const String openMeteoArchiveEndpoint = '/v1/archive';

  • Parameter für GTS (lib/src/core/constants/app_constants.dart):
    • Ebenfalls neu sind die Konstanten für die GTS-Berechnung selbst:
      static const double gtsBaseTemperature = 0.0;
      static const Map<int, double> gtsMonthlyFactors = {1: 0.5, 2: 0.75};
      static const int gtsLocationCachePrecision = 2; // Für Caching

Schritt 4: Datenmodelle für historische Daten (data Layer Models)

Die Archiv-API liefert tägliche Daten in einer ähnlichen, aber doch eigenen Struktur. Daher brauchen wir neue Modelle:

  • lib/src/features/weather/data/models/daily_units_model.dart (NEU): Analog zum HourlyUnitsModel, aber für tägliche Daten (z.B. Einheit für temperature_2m_mean).
  • lib/src/features/weather/data/models/daily_data_model.dart (NEU): Bildet das daily-Objekt der Archiv-API ab. Enthält Listen für time (Datum-Strings) und temperature_2m_mean (tägliche Durchschnittstemperaturen). Die fromJson-Methode parst diese in DateTime– und double-Listen.
  • lib/src/features/weather/data/models/historical_response_model.dart (NEU): Das Gesamtmodell für die Antwort der Archiv-API, analog zum ForecastResponseModel.

Schritt 5: API-Service erweitern (data Layer Datasource)

Der WeatherApiService (lib/src/features/weather/data/datasources/weather_api_service.dart) wurde um eine Methode zum Abruf der historischen Daten erweitert:

  • getHistoricalDailyTemperatures (NEUE Methode):
    • Nimmt latitude, longitude, startDate und endDate als Parameter.
    • Baut die URL für den Archiv-API-Endpunkt (aus AppConstants).
    • Fordert daily=temperature_2m_mean an.
    • Parst die JSON-Antwort mithilfe des neuen HistoricalResponseModel.
    • Enthält robustes Error-Handling, ähnlich wie getForecastWeather.

Schritt 6: Der GTS-Berechnungsservice (application Layer)

Die eigentliche Logik zur Berechnung der GTS und das Caching der dafür benötigten Daten haben wir in einen neuen Service ausgelagert:

  • lib/src/features/weather/application/gts_calculator_service.dart (NEU):
    • Riverpod Provider: Wird über @riverpod bereitgestellt (gtsCalculatorServiceProvider) und bekommt den WeatherApiService injiziert.
    • Caching: Implementiert einen einfachen In-Memory-Cache (_historicalDataCache, _forecastForGtsCache).
      • _getLocationCacheKey: Erstellt einen eindeutigen Schlüssel für den Cache basierend auf gerundeten Koordinaten (um Ungenauigkeiten durch GPS zu minimieren).
      • Vor einem API-Aufruf wird geprüft, ob gültige Daten im Cache vorhanden sind (_cacheDuration).
    • calculateGtsForLocation(LocationInfo location) Methode:
      1. Cache-Prüfung: Versucht, historische Tagesmittelwerte aus dem Cache zu laden.
      2. API-Abruf (historisch): Wenn nicht im Cache, ruft es _apiService.getHistoricalDailyTemperatures auf, um die Tagesmittelwerte vom 1. Januar bis gestern zu holen. Speichert das Ergebnis im Cache.
      3. Datenaufbereitung: Die erhaltenen Daten werden in einer Map<DateTime, double> (Datum -> Temperatur) gespeichert.
      4. Forecast-Ergänzung (Lücke füllen): Die Archiv-API liefert oft Daten nur bis zum Vortag. Wenn die letzten Tage des aktuellen Jahres fehlen, um bis „gestern“ zu kommen (z.B. weil die Archivdaten noch nicht aktualisiert sind), versucht der Service, diese Lücke mit stündlichen Daten aus der Forecast-API zu füllen.
        • Dafür wird _apiService.getForecastWeather mit past_days (um die Lücke abzudecken) und forecast_days: 0 aufgerufen.
        • Aus den stündlichen Forecast-Daten werden dann Tagesmittelwerte für die fehlenden Tage berechnet und zu den dailyAverages hinzugefügt. Auch diese Forecast-Daten werden gecacht.
      5. GTS-Summation: Iteriert durch alle Tage des aktuellen Jahres (bis gestern) in der dailyAverages-Map.
        • Wenn die Tagesmitteltemperatur > gtsBaseTemperature (0°C) ist:
        • Der entsprechende gtsMonthlyFactor (Jan: 0.5, Feb: 0.75, sonst 1.0) wird angewendet.
        • Der Beitrag des Tages (Tagesmittel - Basis) * Faktor wird zur Gesamtsumme addiert.
      6. Gibt die berechnete gtsSum zurück.
    • Fehlerbehandlung: Wirft GtsCalculationException bei Problemen.

Schritt 7: Datenmodell und Repository anpassen (domain & data Layer)

  • WeatherData Entität (lib/src/features/weather/domain/entities/weather_data.dart):
    • Wurde um das Feld final double greenlandTemperatureSum; erweitert.
    • Die empty und copyWith Methoden wurden angepasst.
  • WeatherRepositoryImpl (lib/src/features/weather/data/repositories/weather_repository_impl.dart):
    • Abhängigkeit: Bekommt jetzt den GtsCalculatorService über den Konstruktor injiziert (dank Riverpod).
    • getWeatherForLocation-Methode:
      • Startet den Aufruf von _apiService.getForecastWeather() (für aktuelle und stündliche Daten) und _gtsCalculatorService.calculateGtsForLocation() parallel mit Futures.
      • Wartet mit await auf beide Ergebnisse.
      • Fängt Fehler von calculateGtsForLocation ab und gibt in diesem Fall double.nan für die GTS zurück, damit der Rest der Wetterdaten trotzdem angezeigt werden kann.
      • Fügt den erhaltenen gtsValue beim Erstellen des WeatherData-Objekts hinzu.
      • Kann jetzt auch GtsCalculationException fangen und in GtsFailure umwandeln.

Schritt 8: Anzeige der GTS (presentation Layer)

  • lib/src/features/weather/presentation/widgets/gts_display.dart (NEU):
    • Ein neues StatelessWidget, das den gtsValue als Parameter erhält.
    • Stellt die GTS in einer Card ansprechend dar, inklusive Icon und Einheit (°Cd).
    • Zeigt „–“ an, wenn der gtsValue double.nan ist (also ein Fehler bei der Berechnung auftrat).
  • lib/src/features/weather/presentation/screens/weather_screen.dart:
    • In der _buildSuccessContent-Methode wird nun das neue GtsDisplay-Widget hinzugefügt und bekommt data.greenlandTemperatureSum übergeben. Es wird zwischen der aktuellen Temperaturanzeige und dem Diagramm platziert.

Schritt 9: Änderungen am State Management (application Layer)

Überraschenderweise sind hier keine Änderungen im WeatherState oder WeatherNotifier direkt nötig!

  • Der WeatherState verwendet bereits das WeatherData-Objekt, das nun das greenlandTemperatureSum-Feld enthält.
  • Der WeatherNotifier ruft das WeatherRepository auf, das nun ein WeatherData-Objekt mit befüllter GTS zurückliefert. Der Notifier reicht dieses Objekt einfach an den State weiter.

Das ist ein weiterer Beleg für die Vorteile einer guten Entkopplung: Die UI und der State-Notifier müssen die Details der GTS-Berechnung nicht kennen.

Schritt 10: Ausführen und Testen!

Starte die App (F5):

  1. Lade das Wetter für einen Ort (GPS oder Suche).
  2. Unter der aktuellen Temperatur und vor dem Diagramm sollte nun eine neue Karte mit der Grünlandtemperatursumme erscheinen.
  3. Beobachte die Logs: Du solltest sehen, wie der GtsCalculatorService arbeitet, historische und ggf. Forecast-Daten für die Ergänzung abruft. Beim zweiten Laden für denselben Ort (innerhalb der Cache-Dauer) sollten die Daten schneller aus dem Cache kommen.
  4. Vergleich (optional): Wenn du Zugang zu offiziellen GTS-Werten für deinen Ort hast, kannst du versuchen, die Ergebnisse zu vergleichen. Beachte, dass es leichte Abweichungen geben kann, je nach genauer Datenquelle und Methodik der offiziellen Stellen.

Fazit und Abschluss der Kernserie

Herzlichen Glückwunsch! Du hast die Grünlandtemperatursumme erfolgreich in deine Wetter-App integriert. Damit haben wir alle Kernfunktionen umgesetzt, die wir uns am Anfang vorgenommen hatten.

In diesem Teil hast du gelernt:

  • Wie man Daten von einem anderen API-Endpunkt (Archiv-API) abruft.
  • Wie man historische Daten verarbeitet.
  • Wie man eine spezifische fachliche Berechnung (GTS mit Monatsfaktoren) implementiert.
  • Wie man einen einfachen In-Memory-Cache erstellt und nutzt, um API-Anfragen zu reduzieren.
  • Wie man Daten aus verschiedenen Quellen (historisch, Forecast) kombiniert, um ein vollständiges Bild zu erhalten.
  • Wie eine gut strukturierte App das Hinzufügen komplexer Logik erleichtert, ohne dass alle Teile der App angepasst werden müssen.

Unsere Wetter-App ist nun ein ziemlich umfassendes Projekt, das viele Aspekte der Flutter-Entwicklung abdeckt. Du hast eine solide Grundlage geschaffen, auf der du aufbauen und weitere Ideen umsetzen kannst!

Wie geht es weiter?

Das war das Ende der geplanten Kernfunktionen. Aber eine App ist selten „fertig“. Mögliche nächste Schritte könnten sein:

  • UI-Verfeinerungen: Icons für Wetterbedingungen, schönere Übergänge, Anpassung an verschiedene Bildschirmgrößen.
  • Weitere Wetterdaten: Windgeschwindigkeit, Luftfeuchtigkeit, Sonnenaufgang/-untergang.
  • Einstellungen: Wahl der Temperatureinheit (Celsius/Fahrenheit), Anpassung der Diagramm-Optik.
  • Caching verbessern: Persistenter Cache (z.B. mit shared_preferences oder einer lokalen Datenbank).
  • Testing vertiefen: Mehr Unit-, Widget- und Integration-Tests schreiben.
  • Fehler-Reporting: Integration eines Dienstes wie Sentry oder Firebase Crashlytics.
  • Deployment: Die App für den Google Play Store vorbereiten und veröffentlichen.

Ich hoffe, diese Serie hat dir Spaß gemacht und dir geholfen, Flutter und die App-Entwicklung besser zu verstehen. Nutze das Gelernte als Sprungbrett für deine eigenen Projekte!

Vielen Dank fürs Mitmachen und viel Erfolg bei deinen zukünftigen Flutter-Abenteuern!


Weiterführende Ressourcen & Vertiefung

  1. Open-Meteo Archiv API:
  2. Grünlandtemperatursumme (GTS):
    • Agrarmeteorologische Informationen: Suche nach „Grünlandtemperatursumme Erklärung“ oder „GTS Landwirtschaft“, um mehr über die Bedeutung und Berechnungsmethoden zu erfahren (z.B. von Wetterdiensten oder landwirtschaftlichen Portalen).
  3. Caching-Strategien in Flutter:
    • Einfaches In-Memory Caching: Wie wir es implementiert haben, ist ein guter Start.
    • shared_preferences: https://pub.dev/packages/shared_preferences – Für das Speichern einfacher Schlüssel-Wert-Paare (kleine Datenmengen, die auch nach App-Neustart erhalten bleiben).
    • Lokale Datenbanken (z.B. sqflite): https://pub.dev/packages/sqflite – Für komplexere, strukturierte Daten, die persistent gespeichert werden sollen.
  4. Parallele Ausführung mit Future:

Deine Flutter Wetter-App: Schritt für Schritt – Teil 5

Teil 5: Kurven zeichnen – Temperaturverläufe mit Diagrammen visualisieren

Hallo und herzlich willkommen zurück!

In Teil 4 haben wir unserer Wetter-App eine wichtige Funktion spendiert: die Adresssuche. Nun können wir das aktuelle Wetter nicht nur für unseren GPS-Standort, sondern für jeden beliebigen Ort abfragen. Das ist schon ziemlich cool!

Aber oft sagt ein Bild mehr als tausend Worte – oder in unserem Fall, eine einzelne Temperaturzahl. Wie hat sich die Temperatur entwickelt? Was erwartet uns in den nächsten Tagen? Um diese Fragen zu beantworten, werden wir heute ein Liniendiagramm in unsere App integrieren, das den Temperaturverlauf der letzten 7 Tage und eine Prognose für die nächsten 7 Tage anzeigt.

Das Ziel für heute:

  • Wir untersuchen den Code für Teil 5 aus unserem Repository.
  • Wir lernen das fl_chart-Paket kennen, ein mächtiges Werkzeug zur Erstellung von Diagrammen in Flutter.
  • Wir passen unsere Datenabfrage an, um auch stündliche Temperaturdaten von Open-Meteo zu erhalten.
  • Wir sehen, wie diese Daten in eine für das Diagramm geeignete Form gebracht werden.
  • Wir bauen ein neues Widget (TemperatureChart), das die Daten visualisiert, inklusive Achsenbeschriftung, geglätteter Linie und interaktiven Tooltips.

Warum Diagramme?

Diagramme sind ein hervorragendes Mittel, um Trends und Muster in Daten schnell erfassbar zu machen. Ein Blick auf die Temperaturkurve gibt uns ein viel besseres Gefühl für das Wetter als nur die aktuelle Zahl. Für unser Lernprojekt ist es außerdem eine tolle Gelegenheit, uns mit Datenvisualisierung in Flutter auseinanderzusetzen.

Schritt 1: Den Code für Teil 5 holen

Der Code für diesen Beitrag ist wie gewohnt im Git-Repository vorbereitet.

  1. Öffne ein Terminal in deinem Projektordner (flutter_weather_app_blog).
  2. Stelle sicher, dass du keine ungespeicherten Änderungen hast.
  3. Wechsle zum main-Branch und aktualisiere:
    git checkout main
    git pull origin main
  4. Checke den Code-Stand für Teil 5 aus: (Tag-Name ggf. anpassen)
    git checkout part5-temperature-chart
    (Denke an die ‚detached HEAD‘-Meldung.)
  5. Ganz wichtig: Abhängigkeiten holen & Code generieren:
    flutter pub get
    dart run build_runner build --delete-conflicting-outputs
    (Wir haben das fl_chart-Paket hinzugefügt und einige Datenmodelle erweitert.)

Öffne das Projekt nun in VS Code. Auf den ersten Blick sieht die App vielleicht noch nicht viel anders aus, aber unter der Haube hat sich einiges getan, um die Diagrammdarstellung vorzubereiten und zu implementieren.

Schritt 2: Die neue Werkzeugkiste – Das fl_chart-Paket

Um Diagramme zu zeichnen, ohne das Rad neu erfinden zu müssen, verwenden wir ein beliebtes Flutter-Paket namens fl_chart.

  • pubspec.yaml: In dieser Datei findest du unter dependencies: den neuen Eintrag:
    dependencies:
    # ... andere Pakete ...
    fl_chart: ^0.68.0 # Version prüfen

    fl_chart ist sehr vielseitig und unterstützt verschiedene Diagrammtypen (Linien-, Balken-, Kreisdiagramme etc.). Wir konzentrieren uns auf Liniendiagramme.

Schritt 3: Mehr Daten von der API – Stündliche Temperaturen

Unser Diagramm soll einen Verlauf über 14 Tage zeigen (7 Vergangenheit, 7 Zukunft). Dafür brauchen wir detailliertere Daten als nur die aktuelle Temperatur.

  • WeatherApiService (lib/src/features/weather/data/datasources/weather_api_service.dart):
    • Die Methode getCurrentWeather wurde umbenannt zu getForecastWeather, da sie jetzt mehr als nur die aktuellen Daten liefert.
    • Entscheidende Änderung in den queryParameters:
      // Ausschnitt aus getForecastWeather in WeatherApiService
      final queryParameters = {
      // ... latitude, longitude, current_weather ...
      'hourly': 'temperature_2m', // NEU: Fordert stündliche Temperaturdaten an
      'past_days': pastDays.toString(), // NEU: z.B. 7
      'forecast_days': forecastDays.toString(), // NEU: z.B. 7
      // ... timezone ...
      };

      Wir fordern jetzt explizit hourly=temperature_2m an und spezifizieren über past_days und forecast_days den gewünschten Zeitraum. Open-Meteo liefert uns dann eine lange Liste von Zeitstempeln und den dazugehörigen Temperaturen im 2-Meter-Höhenintervall.

Schritt 4: Die neuen Datenstrukturen (data Layer Models)

Die API liefert die stündlichen Daten in einer spezifischen Struktur. Wir brauchen neue Dart-Klassen (Models), um diese abzubilden:

  • lib/src/features/weather/data/models/hourly_units_model.dart (NEU):
    • Open-Meteo sendet ein separates Objekt hourly_units, das die Einheiten für die stündlichen Werte angibt (z.B. "time": "iso8601", "temperature_2m": "°C"). Diese kleine Klasse bildet das ab.
  • lib/src/features/weather/data/models/hourly_data_model.dart (NEU):
    • Das ist das Herzstück der neuen API-Daten. Es bildet das hourly-Objekt aus der API-Antwort ab, das typischerweise zwei Listen enthält:
      • time: Eine Liste von Zeitstempel-Strings (z.B. "2023-10-27T10:00").
      • temperature_2m: Eine Liste von Temperaturwerten (Zahlen).
    • Die fromJson-Methode in dieser Klasse ist wichtig: Sie nimmt die rohen Listen aus dem JSON, parst die Zeitstempel-Strings mit unserem DateFormatter.tryParseApiDateTime in DateTime-Objekte und wandelt die Temperaturwerte in double um. Sie stellt auch sicher, dass beide Listen die gleiche Länge haben und behandelt fehlerhafte oder fehlende Werte (z.B. indem sie double.nan für ungültige Temperaturen verwendet).
  • lib/src/features/weather/data/models/forecast_response_model.dart (GEÄNDERT):
    • Unser Haupt-Antwortmodell wurde erweitert, um die neuen HourlyUnitsModel und HourlyDataModel aufzunehmen:
      // Ausschnitt aus ForecastResponseModel
      class ForecastResponseModel {
      // ... bestehende Felder ...
      final CurrentWeatherModel? currentWeather;
      final HourlyUnitsModel? hourlyUnits; // NEU
      final HourlyDataModel? hourly; // NEU

      // Konstruktor und toJson angepasst...

      factory ForecastResponseModel.fromJson(Map json) {
      // ... bestehendes Parsing ...
      final units = json.containsKey('hourly_units') /* ... */ ? HourlyUnitsModel.fromJson(json['hourly_units']) : null;
      final data = json.containsKey('hourly') /* ... */ ? HourlyDataModel.fromJson(json['hourly']) : null;
      return ForecastResponseModel(
      // ...
      hourlyUnits: units,
      hourly: data,
      );
      }
      }

Schritt 5: Die App-internen Daten (domain Layer Entities)

Unsere App-Logik und UI sollten nicht direkt mit den API-spezifischen Models arbeiten. Wir brauchen eine saubere, app-interne Repräsentation der Daten.

  • lib/src/features/weather/domain/entities/chart_point.dart (NEU):
    • Eine sehr einfache Klasse, die einen einzelnen Punkt im Diagramm repräsentiert:
      class ChartPoint extends Equatable {
      final DateTime time; // X-Wert
      final double temperature; // Y-Wert
      // ... Konstruktor, props ...
      }

  • lib/src/features/weather/domain/entities/weather_data.dart (GEÄNDERT/ERSETZT):
    • Diese Entität, die bisher nur CurrentWeatherData hieß und nur die aktuelle Temperatur enthielt, wurde nun zur zentralen WeatherData-Klasse.
    • Sie enthält jetzt zusätzlich eine Liste von ChartPoint-Objekten für den Temperaturverlauf:
      // Ausschnitt aus WeatherData
      class WeatherData extends Equatable {
      final double currentTemperature;
      final DateTime? lastUpdatedTime;
      final List hourlyForecast; // NEU

      // Konstruktor, props, empty, copyWith angepasst...
      }

    • (Die alte current_weather_data.dart kann gelöscht werden, wenn sie nicht mehr referenziert wird.)

Schritt 6: Datenaufbereitung im Repository (data Layer)

Das WeatherRepositoryImpl (lib/src/features/weather/data/repositories/weather_repository_impl.dart) ist dafür zuständig, die Rohdaten vom WeatherApiService zu holen und sie in unsere App-internen WeatherData-Entität umzuwandeln.

  • getWeatherForLocation-Methode (GEÄNDERT):
    • Ruft jetzt _apiService.getForecastWeather() auf (die umbenannte Methode, die auch stündliche Daten holt).
    • Nachdem die aktuelle Temperatur extrahiert wurde, iteriert es durch die time– und temperature_2m-Listen aus dem forecastResponse.hourly-Objekt.
    • Für jedes gültige Zeit/Temperatur-Paar wird ein ChartPoint-Objekt erstellt und der hourlyPoints-Liste hinzugefügt. Ungültige Temperaturen (NaN) werden übersprungen.
    • Am Ende wird das WeatherData-Objekt mit currentTemperature, lastUpdatedTime und der hourlyForecast-Liste erstellt und zurückgegeben.
    • Das Interface WeatherRepository (domain/repositories/weather_repository.dart) wurde natürlich angepasst, sodass getWeatherForLocation jetzt Future&lt;Either> zurückgibt.

Schritt 7: State Management (application Layer)

Die Änderungen im WeatherState und WeatherNotifier sind minimal, da unsere Architektur gut vorbereitet war.

  • lib/src/features/weather/application/weather_state.dart (GEÄNDERT):
    • Das Feld currentWeatherData wurde durch weatherData (vom Typ WeatherData, unserer neuen, umfassenderen Entität) ersetzt.
    • Die initial() und copyWith() Methoden wurden entsprechend angepasst.
  • lib/src/features/weather/application/weather_notifier.dart (MINIMAL GEÄNDERT):
    • Die Methode _fetchWeatherDataAndUpdateState nimmt nun WeatherData vom Repository entgegen und speichert es im weatherData-Feld des WeatherState. Die Logik an sich bleibt gleich, da das Repository die Hauptarbeit der Datenumwandlung übernimmt.

Schritt 8: Das Diagramm-Widget (presentation Layer)

Jetzt kommt der spannende Teil – die Visualisierung!

  • lib/src/features/weather/presentation/widgets/temperature_chart.dart (NEU):

    • Dies ist ein neues StatelessWidget, das die chartData (eine List) als Parameter erwartet.
    • Kernstück: LineChart von fl_chart:
      • LineChartData: Konfiguriert das gesamte Diagramm.
      • lineBarsData: Definiert die Linien. Wir haben eine LineChartBarData.
        • spots: Hier werden unsere ChartPoint-Objekte in FlSpot-Objekte umgewandelt, die fl_chart versteht (FlSpot(zeit_als_double, temperatur)).
        • isCurved: true: Macht die Linie schön weich.
        • color, barWidth: Aussehen der Linie.
        • dotData: FlDotData(show: false): Wir zeigen keine einzelnen Punkte auf der Linie an.
        • belowBarData: Füllt den Bereich unter der Linie mit einem Farbverlauf (optional, aber schick).
      • titlesData: Konfiguriert die Achsenbeschriftungen.
        • bottomTitles: Für die X-Achse (Zeit). getTitlesWidget ist eine Funktion, die für jeden Achsenpunkt ein Widget zurückgibt. Wir formatieren hier den Zeitstempel mit unserem DateFormatter.formatChartAxisDay (z.B. „Mo 15.07.“) und zeigen nur alle paar Tage ein Label, um Überlappung zu vermeiden. Die SideTitleWidget(meta: meta, ...) Konstruktion ist hier wichtig.
        • leftTitles: Für die Y-Achse (Temperatur). Zeigt Temperaturwerte in sinnvollen Intervallen (z.B. alle 5 Grad).
      • gridData: Zeichnet das Hintergrundgitter.
      • borderData: Zeichnet einen Rahmen um das Diagramm.
      • lineTouchData: Ermöglicht Interaktion.
        • touchTooltipData: Konfiguriert die Tooltips, die erscheinen, wenn man auf die Linie tippt. getTooltipItems erstellt den Inhalt des Tooltips (Datum, Uhrzeit, Temperatur). getTooltipColor (früher tooltipBgColor) setzt die Hintergrundfarbe des Tooltips.
      • minY, maxY: Bestimmen den sichtbaren Bereich der Y-Achse. Wir berechnen diese dynamisch aus den Daten und fügen etwas Puffer hinzu.
    • Deutsche Tageskürzel: In lib/main.dart haben wir initializeDateFormatting('de_DE', null); hinzugefügt. Dadurch verwendet DateFormat im DateFormatter standardmäßig deutsche Formate, also auch „Mo, Di, Mi…“ für die Tageskürzel in der X-Achsen-Beschriftung.
  • lib/src/features/weather/presentation/screens/weather_screen.dart (GEÄNDERT):

    • _buildSuccessContent (NEUE Hilfsmethode): Um den _buildContent-Switch übersichtlich zu halten, wurde der Code, der bei WeatherStatus.success angezeigt wird, in diese neue Methode ausgelagert.
    • Innerhalb von _buildSuccessContent wird nun zusätzlich zum CurrentTemperatureDisplay auch das TemperatureChart-Widget hinzugefügt. Es bekommt data.hourlyForecast (wobei data hier das WeatherData-Objekt aus dem State ist) übergeben.
    • Die gesamte Erfolgsansicht ist in eine ListView gewickelt, damit der Inhalt scrollbar wird, falls er nicht auf den Bildschirm passt (was mit dem Diagramm nun der Fall sein kann).

Schritt 9: Ausführen und Bestaunen!

Starte die App (F5):

  1. Lasse das Wetter für deinen aktuellen Standort oder einen gesuchten Ort laden.
  2. Unter der aktuellen Temperatur solltest du nun ein Liniendiagramm sehen!
  3. Interaktion: Tippe auf verschiedene Punkte der Linie. Ein Tooltip sollte mit dem genauen Datum, der Uhrzeit und der Temperatur für diesen Punkt erscheinen.
  4. Verlauf: Die Linie sollte die Temperatur der letzten 7 Tage (Vergangenheit) und der nächsten 7 Tage (Prognose) darstellen.
  5. Achsen: Die X-Achse sollte Tage anzeigen (z.B. „Heute“, „Morgen“, „Mi 17.07.“), die Y-Achse die Temperaturskala.

Was haben wir gelernt?

  • Wie man ein externes Paket (fl_chart) für komplexe UI-Elemente einbindet.
  • Wie man API-Anfragen anpasst, um mehr Daten (stündliche Werte) zu erhalten.
  • Wie man Datenmodelle und Entitäten erweitert, um neue Informationen zu speichern.
  • Wie man Rohdaten von einer API für die Darstellung in einem Diagramm aufbereitet (Mapping zu ChartPoint und FlSpot).
  • Die Grundlagen der Konfiguration eines LineChart mit fl_chart, inklusive:
    • Datenpunkte (spots)
    • Aussehen der Linie (LineChartBarData)
    • Achsenbeschriftung (titlesData, SideTitleWidget)
    • Gitternetz (gridData)
    • Interaktive Tooltips (lineTouchData)
  • Wie man die UI strukturert (ListView), um auch größere Inhalte scrollbar zu machen.
  • Die Wichtigkeit der deutschen Locale-Initialisierung für korrekte Datumsformate.

Ausblick auf Teil 6:

Unsere App wird immer funktionaler und sieht auch noch besser aus! Im nächsten und vorerst letzten Teil dieser Kernserie implementieren wir unsere Spezialfunktion: die Berechnung und Anzeige der Grünlandtemperatursumme (GTS). Dafür müssen wir historische Tagesmittelwerte von einer anderen Open-Meteo API abrufen und eine spezifische Berechnungslogik umsetzen.

Das wird noch einmal spannend und zeigt, wie man mit Flutter auch komplexere fachliche Anforderungen umsetzen kann. Bleib dran!


Weiterführende Ressourcen & Vertiefung

In diesem Teil haben wir einige neue Konzepte und Werkzeuge kennengelernt. Hier sind Links, falls du tiefer eintauchen möchtest:

  1. fl_chart Paket:
  2. Datenmodellierung & JSON Parsing in Dart:
  3. Datum & Zeit Formatierung (intl Paket):
  4. Flutter State Management (Riverpod):
    • Offizielle Riverpod Dokumentation: https://riverpod.dev/ – Die beste Quelle, um Riverpod von Grund auf zu lernen oder spezifische Konzepte wie StateNotifierProvider, ref.watch und ref.read nachzuschlagen.
  5. Flutter Layout Grundlagen (ListView, Column, SizedBox):

Deine Flutter Wetter-App: Schritt für Schritt – Teil 4

Teil 4: Mehr Orte, mehr Möglichkeiten – Adresssuche hinzufügen

Hallo und willkommen zurück zu unserer Flutter-Wetter-App-Serie!

Im letzten Teil haben wir einen riesigen Schritt gemacht: Wir haben die Standard-Demo-App durch unsere eigene ersetzt, eine solide Architektur aufgebaut und die aktuelle Temperatur für unseren GPS-Standort angezeigt. Dabei haben wir viel über eine saubere Architektur, State Management mit Riverpod und Fehlerbehandlung gelernt.

Doch eine Wetter-App ist erst richtig nützlich, wenn wir das Wetter für beliebige Orte nachschlagen können. Genau das packen wir heute an! Wir erweitern unsere App um eine Adresssuche.

Das Ziel für heute:

  • Wir untersuchen den Code für Teil 4 aus unserem Repository.
  • Wir verstehen, wie das Suchfeld zur Benutzeroberfläche hinzugefügt wurde.
  • Wir lernen Geocoding: Wie eine Adresse („München“) in Koordinaten (Latitude/Longitude) umgewandelt wird.
  • Wir verfolgen, wie die App-Logik und Datenbeschaffung angepasst wurden, um Wetterdaten für gesuchte Orte abzurufen.
  • Wir sehen, wie Fehler bei der Suche (z.B. „Adresse nicht gefunden“) behandelt werden.

Warum dieser Schritt wichtig ist:

Dieser Teil zeigt, wie eine gut geplante Architektur Früchte trägt. Wir müssen nicht alles neu erfinden, sondern können auf unserem bestehenden Fundament aufbauen und gezielt Erweiterungen hinzufügen. Außerdem lernen wir eine weitere wichtige Funktion vieler Apps kennen: die Verarbeitung von Benutzereingaben und die Umwandlung von Text in geografische Daten.

Schritt 1: Den Code für Teil 4 holen

Der gesamte Code für diesen Beitrag ist wieder im Git-Repository vorbereitet.

1. Öffne ein Terminal in deinem Projektordner (flutter_weather_app_blog).

2. Stelle sicher, dass du keine lokalen Änderungen hast, die du behalten willst (ggf. git stash).

3. Wechsle zum main-Branch (um sicher vom letzten stabilen Punkt auszugehen):

git checkout main
git pull origin main

4. Checke den Code-Stand für Teil 4 aus:

git checkout part4-address-search

(Zur Erinnerung: Die ‚detached HEAD‘-Meldung ist normal und bedeutet, dass du einen spezifischen Punkt in der Projekthistorie betrachtest.)

5. Ganz wichtig: Abhängigkeiten holen & Code generieren: Wir haben eine neue Bibliothek hinzugefügt und Code geändert, der generiert werden muss. Führe diese beiden Befehle aus:

flutter pub get
dart run build_runner build --delete-conflicting-outputs

Öffne das Projekt jetzt in VS Code. Lass uns die Neuerungen erkunden!

Schritt 2: Was ist neu? Der Überblick

Wenn du die App jetzt startest (F5 in VS Code), wirst du sofort die Änderungen sehen:

  • Ein Suchfeld ist oben erschienen.
  • Ein „Mein Standort“-Button (ein kleines Fadenkreuz-Icon) befindet sich nun oben rechts in der AppBar.

Unter der Oberfläche sind die wesentlichen Anpassungen:

  • Neues Paket: Wir nutzen das geocoding-Paket.
  • UI-Anpassungen: Der Hauptbildschirm (WeatherScreen) wurde umgebaut, um das Suchfeld und den neuen Button zu integrieren. Ein neues Widget (SearchBarWidget) wurde erstellt.
  • Geocoding-Logik: Neue Funktionen im LocationService und WeatherRepository wandeln Adressen in Koordinaten um.
  • State Management Update: Der WeatherNotifier kann nun Suchanfragen verarbeiten.
  • Intelligentere Refresh-Funktion: Aktualisiert jetzt immer den zuletzt angezeigten Ort.
  • Erweiterte Fehlerbehandlung: Erkennt und meldet Fehler bei der Adresssuche.

Schritt 3: Die neue Zutat – Das geocoding-Paket

Wie wird aus dem Text „Hamburg“ ein Paar von Koordinaten (Breitengrad, Längengrad), das unsere Wetter-API versteht? Durch Geocoding.

  • pubspec.yaml: In dieser Datei (dem „Rezeptbuch“ unserer App) haben wir eine neue Zutat hinzugefügt:
dependencies:
# … andere Pakete …
geocoding: ^3.0.0 # Version prüfen

Dieses Paket erlaubt uns, die eingebauten Geocoding-Funktionen von Android zu verwenden. Der Befehl flutter pub get hat dieses Paket heruntergeladen und für unser Projekt verfügbar gemacht.

Schritt 4: Die Benutzeroberfläche (presentation) – Ein Platz für die Suche

Schauen wir uns an, wie die Benutzeroberfläche in lib/src/features/weather/presentation/ angepasst wurde.

widgets/search_bar.dart (NEU):

Um den Code aufgeräumt zu halten, haben wir ein eigenes Widget für die Suchleiste erstellt. Es ist ein einfaches TextField, aber schön verpackt mit einem Such-Icon (prefixIcon), einem Senden-Icon (suffixIcon) und abgerundeten Ecken (InputDecoration).

Wichtige Parameter:

  • controller: Ein TextEditingController, um den Text im Feld zu steuern.
  • onSearch: Eine Funktion, die aufgerufen wird, wenn der Nutzer auf das Senden-Icon tippt oder auf der Tastatur „Suchen“ auswählt.
  • isLoading: Ein bool, um das Feld und den Button zu deaktivieren, während die App Daten lädt.
// lib/src/features/weather/presentation/widgets/search_bar.dart
import 'package:flutter/material.dart';</li>
</ul>
</li>
</ul>
class SearchBarWidget extends StatelessWidget {
final TextEditingController controller;
final Function(String) onSearch;
final bool isLoading;
final String hintText;

const SearchBarWidget({ /* … Konstruktor … */ });

@override
Widget build(BuildContext context) {
return TextField(
controller: controller,
enabled: !isLoading, // Deaktivieren bei Ladevorgang
decoration: InputDecoration(
hintText: hintText,
prefixIcon: const Icon(Icons.search),
// … weitere Styling-Details …
suffixIcon: isLoading
? /* Ladeindikator */
: IconButton(
icon: const Icon(Icons.send),
onPressed: isLoading ? null : () => onSearch(controller.text),
),
),
textInputAction: TextInputAction.search,
onSubmitted: isLoading ? null : onSearch, // Suche auch bei Enter
);
}
}

screens/weather_screen.dart: Hier passieren mehrere Dinge:

  • Controller Management: Im _WeatherScreenState wird ein TextEditingController erstellt:
final TextEditingController _searchController = TextEditingController();
  • Ganz wichtig: Controller speichern Ressourcen und müssen freigegeben werden, wenn das Widget zerstört wird. Das geschieht in der dispose-Methode:
@override
void dispose() {
_searchController.dispose(); // Controller aufräumen!
super.dispose();
}
  • Layout Anpassung: Die build-Methode des Screens enthält jetzt eine Column. Das erste Kind dieser Column ist ein Padding, das unser neues SearchBarWidget enthält. Darunter folgen der LocationHeader und der Expanded-Bereich für den Hauptinhalt (Wetteranzeige oder Fehler).
// lib/src/features/weather/presentation/screens/weather_screen.dart (Ausschnitt build)
@override
Widget build(BuildContext context) {
final weatherState = ref.watch(weatherNotifierProvider);
final weatherNotifier = ref.read(weatherNotifierProvider.notifier);

return Scaffold(
appBar: AppBar( /* … mit Buttons … <em>/ ),
body: Column( // NEU: Column für vertikale Anordnung
children: [
// Suchleiste oben
Padding(
padding: const EdgeInsets.all(12.0),
child: SearchBarWidget(
controller: _searchController,
isLoading: weatherState.status == WeatherStatus.loading,
onSearch: (query) { // Was passiert bei Suche?
if (query.trim().isNotEmpty) {
_log.info('Screen: Suche ausgelöst für "$query"');
FocusScope.of(context).unfocus(); // Tastatur weg
// Aktion im Notifier auslösen!
weatherNotifier.fetchWeatherForAddress(query);
} else {
_showSnackbar("Bitte einen Ort oder eine Adresse eingeben.");
}
},
),
),
// Ort anzeigen
Padding(
padding: const EdgeInsets.symmetric(horizontal: 16.0, vertical: 4.0),
child: LocationHeader( /</em> … <em>/ ),
),
// Restlicher Inhalt (nimmt verfügbaren Platz ein)
Expanded(
child: RefreshIndicator( /</em> … */ ),
),
],
),
);
}
  • Neue AppBar-Aktion: Der „Mein Standort“-Button (IconButton mit Icons.my_location) wurde zur AppBar hinzugefügt. Sein onPressed ruft einfach weatherNotifier.fetchWeatherForCurrentLocation(), die Methode, die wir schon aus Teil 3 kennen.
  • Fehlerbehandlung: Das _buildErrorWidget wurde angepasst. Es prüft nun zusätzlich, ob der failure vom Typ GeocodingFailure ist. Wenn ja, zeigt es eine spezifische Meldung (z.B. „Adresse ‚XYZ‘ konnte nicht gefunden werden.“) und ein passendes Icon (Icons.wrong_location_outlined). Da der Nutzer in diesem Fall eine neue, korrekte Suche starten muss, gibt es hier keinen „Erneut versuchen“-Button.

Schritt 5: Die Datenbeschaffung (core, data, domain) – Adresse zu Koordinaten

Das ist das technische Herzstück der neuen Funktion. Wie kommen wir von „Paris“ zu Längen- und Breitengrad?

  1. LocationService (lib/src/core/location/location_service.dart):
    • Dieser Service ist nun der Experte für alle Standort-bezogenen Aufgaben. Er hat die neue Methode getCoordinatesFromAddress bekommen.
    • Wie sie funktioniert: Sie nutzt intern die Funktion locationFromAddress aus dem geocoding-Paket. Dieses Paket kommuniziert mit den nativen Diensten von Android, um die Koordinaten zu ermitteln.
    • Fehlerbehandlung: Wenn das geocoding-Paket die Adresse nicht kennt, wirft es eine NoResultFoundException. Unser LocationService fängt diesen spezifischen Fehler und wirft stattdessen unsere eigene, definierte GeocodingException. Das ist wichtig, damit der Rest unserer App nicht die Interna des geocoding-Pakets kennen muss. Andere Fehler (z.B. Netzwerkprobleme während des Geocodings) werden ebenfalls als GeocodingException gefangen.
    • Reverse Geocoding: Die Methode getAddressFromCoordinates, die wir in Teil 3 nur als Platzhalter hatten, ist jetzt auch implementiert. Sie nutzt placemarkFromCoordinates aus dem geocoding-Paket, um aus Koordinaten wieder eine lesbare Adresse zu machen. Das wird genutzt, um den Anzeigenamen im LocationHeader potenziell zu verbessern (z.B. aus Koordinaten wird „Berlin, Deutschland“).
  2. Fehlerklassen (lib/src/core/error/):
    • Wir haben GeocodingException (für technische Geocoding-Fehler) und GeocodingFailure (die abstraktere Form für unsere App-Logik) hinzugefügt.
  3. WeatherRepository (Interface & Implementierung):
    • Das Interface (domain/repositories/weather_repository.dart) wurde um die Methode getCoordinatesForAddress erweitert – unser Repository muss diese Fähigkeit nun anbieten.
    • Die Implementierung (data/repositories/weather_repository_impl.dart) erfüllt diesen Vertrag:
      • Die getCoordinatesForAddress-Methode ruft _locationService.getCoordinatesFromAddress auf.
      • Sie fängt die GeocodingException vom Service.
      • Sie gibt das Ergebnis als Either zurück: Left(GeocodingFailure(...)) im Fehlerfall oder Right(LocationInfo(...)) bei Erfolg.
      • Wichtig: Bei Erfolg versucht sie noch, den displayName des LocationInfo-Objekts durch einen Aufruf von getLocationDisplayName (also Reverse Geocoding) zu verfeinern, bevor sie das Ergebnis zurückgibt.

Schritt 6: Die Logik (application) – Suche und Wetter verknüpfen

Der WeatherNotifier (lib/src/features/weather/application/weather_notifier.dart) dirigiert das Zusammenspiel.

  • Neue Methode fetchWeatherForAddress:
    • Das ist die Reaktion auf die Nutzereingabe im Suchfeld.
    • Sie prüft, ob überhaupt etwas eingegeben wurde und ob gerade schon geladen wird.
    • Sie setzt den state auf loading.
    • Kernschritt 1: Sie ruft _weatherRepository.getCoordinatesForAddress(address) auf.
    • Kernschritt 2: Sie wertet das zurückgegebene Either aus:
      • Bei Left(failure) (z.B. GeocodingFailure): Der state wird auf failure gesetzt, die UI zeigt den Fehler.
      • Bei Right(locationInfo) (Koordinaten erfolgreich gefunden): Jetzt kommt der Clou! Sie ruft die bereits vorhandene Methode _fetchWeatherDataAndUpdateState(locationInfo) auf. Diese Methode weiß, wie man Wetterdaten für ein LocationInfo-Objekt holt – egal, ob dieses vom GPS oder vom Geocoding kam. Das ist Wiederverwendung dank guter Architektur!
  • Angepasste Methode refreshWeatherData:
    • Diese Methode wurde intelligenter. Zuvor hat sie einfach immer den GPS-Standort neu geladen.
    • Jetzt: Sie schaut sich den state.selectedLocation an (der ja nach einer erfolgreichen Suche den gesuchten Ort enthält). Sie ruft dann _fetchWeatherDataAndUpdateState für genau diesen gespeicherten Ort auf. Damit funktioniert der Refresh-Button und Pull-to-Refresh immer für den Ort, den der Nutzer gerade sieht.

Schritt 7: Der Datenfluss bei der Suche (Zusammenfassung)

Lass uns den Weg einer Suche nachvollziehen:

  1. Eingabe: Nutzer tippt „Rom“ ein und drückt Senden (WeatherScreen).
  2. Aktion: onSearch ruft notifier.fetchWeatherForAddress("Rom").
  3. Laden: Notifier setzt state auf loading (UI zeigt Ladekreis).
  4. Koordinaten holen: Notifier ruft repo.getCoordinatesForAddress("Rom").
  5. Geocoding: Repo ruft service.getCoordinatesFromAddress("Rom"). Service ruft geocoding-Paket, bekommt Koordinaten für Rom.
  6. Reverse Geocoding: Repo ruft service.getAddressFromCoordinates(...), bekommt vielleicht „Rom, Latium, Italien“ zurück.
  7. Erfolg (Koordinaten): Repo gibt Right(LocationInfo(..., displayName: "Rom, Latium, Italien")) an Notifier zurück.
  8. Wetter holen: Notifier erhält locationInfo_Rom und ruft _fetchWeatherDataAndUpdateState(locationInfo_Rom).
  9. API-Anfrage: Notifier ruft repo.getWeatherForLocation(locationInfo_Rom). Repo ruft apiService.getCurrentWeather(...) mit Rom-Koordinaten.
  10. API-Antwort: ApiService holt Daten von Open-Meteo, parst sie.
  11. Erfolg (Wetter): Repo gibt Right(weatherData_Rom) an Notifier zurück.
  12. Finaler State: Notifier setzt state auf success mit weatherData_Rom und locationInfo_Rom.
  13. Anzeige: WeatherScreen wird neu gebaut und zeigt „Rom, Latium, Italien“ und die aktuelle Temperatur für Rom an.

Schritt 8: Ausführen und Experimentieren!

Starte die App (F5) und spiele damit herum:

  • Suche verschiedene Städte, Länder, Sehenswürdigkeiten.
  • Suche nach ungültigen Adressen.
  • Wechsle zwischen Suchergebnissen und deinem GPS-Standort über den „Mein Standort“-Button.
  • Teste die Refresh-Funktion für gesuchte Orte.
  • Beobachte die Log-Ausgaben in der „DEBUG CONSOLE“ in VS Code, um den Fluss nachzuvollziehen.

Fazit und Ausblick

Wir haben unserer App eine wichtige Funktion hinzugefügt und dabei gesehen, wie unsere Architektur uns geholfen hat, Code wiederzuverwenden und die Änderungen sauber zu integrieren. Du hast gelernt:

  • Wie man eine neue Bibliothek (geocoding) einbindet und nutzt.
  • Wie der Prozess von der Adresseingabe bis zur Koordinate funktioniert (Geocoding).
  • Wie man die App-Logik im Notifier erweitert, um neue Benutzeraktionen zu behandeln.
  • Wie man bestehende Komponenten (wie die Wetterabfrage) für neue Szenarien wiederverwendet.
  • Wie man die Refresh-Logik an den aktuellen App-Zustand anpasst.

Unsere App ist jetzt deutlich flexibler. Aber reine Zahlen und Texte sind oft nicht genug, um Wettertrends zu erfassen. Im nächsten Teil (Teil 5) wird es grafisch: Wir holen uns stündliche Temperaturdaten von der API und visualisieren den Verlauf der letzten 7 Tage und die Prognose für die nächsten 7 Tage in einem interaktiven Liniendiagramm!

Das wird die App optisch aufwerten und noch informativer machen. Bleib neugierig!


Weiterführende Ressourcen & Vertiefung (für Teil 4)

In diesem Teil haben wir die App interaktiver gemacht und Geocoding eingeführt.

  1. Geocoding:
    • geocoding Paket: https://pub.dev/packages/geocoding – Die Dokumentation zum verwendeten Paket.
    • Konzept Geocoding/Reverse Geocoding (Allgemein): Suche online nach diesen Begriffen, um das grundlegende Konzept besser zu verstehen (z.B. auf Wikipedia oder GIS-Seiten).
  2. Flutter UI – Eingabefelder:
  3. Architektur & Refactoring:
    • (Die Links aus Teil 3 zur Architektur sind weiterhin relevant) – Betrachte, wie die bestehende Struktur das Hinzufügen der Suchfunktion erleichtert hat, ohne große Umbauten an der Wetterabfrage selbst vornehmen zu müssen.

Deine Flutter Wetter-App: Schritt für Schritt – Teil 3

Teil 3: Der erste Meilenstein: Aktuelle Temperatur am aktuellen Ort – Den Code verstehen

Hallo und willkommen zurück zur Serie!

In Teil 2 haben wir unsere Werkzeuge geschärft und die Flutter-Entwicklungsumgebung auf deinem Windows-PC eingerichtet. Wir haben sogar die Standard-Flutter-App zum Laufen gebracht. Super!

Heute tauchen wir endlich in den eigentlichen Code unserer Wetter-App ein. Wir überspringen das manuelle Tippen jedes Zeichens und konzentrieren uns stattdessen darauf, den Code für unseren ersten Meilenstein zu verstehen: Die App soll die aktuelle Temperatur für deinen aktuellen GPS-Standort anzeigen.

Das Ziel für heute:

  • Wir schauen uns den vorbereiteten Code für Teil 3 an (den du aus einem Repository herunterladen kannst).
  • Wir zerlegen die Projektstruktur und verstehen, welche Datei wo hingehört und warum.
  • Wir verfolgen den Datenfluss: Wie kommt die Temperatur vom Internet auf deinen Bildschirm?
  • Wir beleuchten die wichtigsten Konzepte: Architektur, State Management mit Riverpod, Fehlerbehandlung und mehr.

Warum dieser Ansatz?

Eine App zu bauen ist wie ein Haus zu bauen. Man könnte einfach loslegen, aber ein guter Architekt plant zuerst. Wir haben den Code für diesen ersten Schritt bereits nach einem bewährten Plan (einer „sauberen Architektur“) strukturiert. Indem wir diesen fertigen, aber einfachen Code untersuchen, lernst du nicht nur, wie man eine Funktion implementiert, sondern auch, wie man Code organisiert, damit er später leicht erweitert, getestet und gewartet werden kann. Das ist entscheidend, um selbst gute Apps zu schreiben!

Schritt 1: Den Code holen

Der gesamte Code für diesen Teil der Serie ist in einem Git-Repository vorbereitet.

  1. Repository klonen (falls noch nicht geschehen):
    Öffne eine Eingabeaufforderung oder ein Terminal und navigiere zu dem Ordner, in dem du deine Projekte speichern möchtest (z.B. C:\dev\flutter_projekte\). Führe dann folgenden Befehl aus:
    git clone https://github.com/hschewe/flutter_weather_app_blog.git
    Wechsle in das neu erstellte Verzeichnis:
    bash cd flutter_weather_app_blog
  2. Den richtigen Stand auschecken: Für jeden Teil der Serie gibt es einen Git-Tag. Um den Code-Stand für Teil 3 zu bekommen, führe aus:
    git checkout part3-current-temp-gps.
    (Git meldet möglicherweise, dass du dich in einem ‚detached HEAD‘-Zustand befindest. Das ist normal und bedeutet, du schaust dir einen spezifischen Punkt in der Vergangenheit an. Du kannst den den Code untersuchen, ausführen und sogar temporäre Änderungen vornehmen. Wenn du zur normalen Entwicklung zurückkehren willst, kannst du einfach wieder den main-Branch auschecken (git checkout main)).
  3. Projekt in VS Code öffnen: Öffne VS Code und wähle File > Open Folder... und navigiere zum flutter_weather_app_blog-Ordner.
  4. Abhängigkeiten installieren: Öffne ein Terminal in VS Code (Terminal > New Terminal) und führe aus:
    flutter pub get
  5. Code generieren: Da wir Riverpod mit Code-Generierung verwenden, müssen wir diesen Schritt ausführen:
    dart run build_runner build --delete-conflicting-outputs
    Dieser Befehl liest spezielle Anmerkungen (@riverpod) im Code und erstellt automatisch benötigte Hilfsdateien (die auf .g.dart enden).

Jetzt ist der Code bereit zur Untersuchung!

Schritt 2: Der große Überblick – Die Architektur

Bevor wir in einzelne Dateien schauen, betrachten wir den Bauplan. Unsere App folgt einer Schichtenarchitektur, inspiriert von „Clean Architecture“. Stell dir vor, wir bauen Schichten wie bei einer Zwiebel:

+-------------------------------------------------+
| Presentation (UI) Layer                         | <--- Das, was der Nutzer sieht (Widgets, Screens)
|    - Widgets                                    |      Interagiert mit dem Application Layer
|    - Screens                                    |
|    - State Management (Notifier/Provider)       |
+-------------------------------------------------+
      ^                                      | Dependency Rule
      | Calls                                | (Innere Schichten kennen Äußere nicht)
+-------------------------------------------------+
| Application / Domain Layer                      | <--- Die Logik der App
|    - State Notifier (Logik-Orchestrierung)      |      Definiert, WAS die App tut
|    - Repository Interface (Datenvertrag)        |      Kennt nur Entities
|    - Entities (App-Datenstrukturen)             |
+-------------------------------------------------+
      ^                                      |
      | Implements / Calls                   |
+-------------------------------------------------+
| Data Layer                                      | <--- Datenbeschaffung & -speicherung
|    - Repository Implementation                  |      Implementiert den Vertrag
|    - Data Sources (API, GPS, DB)                |      Spricht mit der Außenwelt
|    - Models (API/DB-Datenstrukturen)            |
+-------------------------------------------------+
      ^ Depends on                             ^ Depends on
      |                                        |
+-------------------------------------------------+
| Core Layer                                      | <--- App-übergreifende Helfer
|    - Utils (Logger, Formatter)                  |      Von allen Schichten nutzbar
|    - Error Handling                             |
|    - Networking Client                          |
+-------------------------------------------------+
  • Core: Enthält grundlegende Helferlein, die überall gebraucht werden könnten (wie unser Logger).
  • Data: Kümmert sich darum, woher die Daten kommen (API, GPS) und wie sie technisch abgefragt werden. Kennt die genaue Struktur der externen Daten.
  • Domain/Application: Das Herzstück. Definiert, welche Daten die App braucht (Entities) und welche Operationen möglich sind (Repository Interface), aber nicht, wie sie beschafft werden. Hier sitzt auch die Logik, die auf Nutzeraktionen reagiert (Notifier). Diese Schicht sollte unabhängig von UI-Details oder spezifischen Datenbanken/APIs sein.
  • Presentation (UI): Zeigt die Daten an (Screens, Widgets) und nimmt Nutzereingaben entgegen. Sie spricht nur mit dem Application Layer (über den Notifier), um Daten zu bekommen oder Aktionen auszulösen.

Die goldene Regel: Abhängigkeiten zeigen immer nach innen! Die UI kennt die Application/Domain Layer, aber nicht die Data Layer. Die Domain Layer kennt niemanden außerhalb (außer Core). Das macht das System flexibel und testbar.

Schritt 3: Ein Rundgang durch die Ordner (lib/src/)

Schauen wir uns an, wie diese Architektur in unserer Ordnerstruktur abgebildet ist:

  • lib/main.dart: Der allererste Startpunkt. Initialisiert das Logging, WidgetsFlutterBinding (wichtig für Plugins) und startet die App innerhalb einer ProviderScope (notwendig für Riverpod).
  • lib/app.dart: Enthält das MaterialApp-Widget, das die grundlegende Struktur, das Theme (Aussehen) und die Startseite (WeatherScreen) unserer App definiert.
  • lib/src/core/: Unser Fundament.
    • error/: Enthält exceptions.dart (spezifische technische Fehler wie NetworkException) und failure.dart (abstraktere Fehler wie NetworkFailure, die die Logik verstehen kann). Diese Trennung hilft, Fehler sauber zu behandeln.
    • location/: location_service.dart kapselt die Interaktion mit dem geolocator-Paket. Alle GPS- und Berechtigungs-Anfragen laufen hierüber. Wird über Riverpod bereitgestellt (locationServiceProvider).
    • networking/: http_client.dart stellt eine globale Instanz des http.Client bereit (über httpClientProvider). Das macht es einfach, ihn in Tests durch einen Mock zu ersetzen.
    • utils/: Enthält Helfer wie logger.dart (für strukturierte Logs) und date_formatter.dart (um z.B. die Uhrzeit anzuzeigen).
    • constants/: app_constants.dart sammelt zentrale Konstanten (hier erstmal nur myLocationLabel).
  • lib/src/features/weather/: Alles, was mit der Wetterfunktion zu tun hat.
    • data/: Datenbeschaffung.
      • models/: current_weather_model.dart, forecast_response_model.dart. Diese Dart-Klassen spiegeln exakt die Struktur des JSON wider, das wir von der Open-Meteo API bekommen. Sie enthalten fromJson-Methoden, um JSON in Dart-Objekte umzuwandeln.
      • datasources/: weather_api_service.dart. Spricht über den http.Client mit der Open-Meteo API (getCurrentWeather-Methode). Parst die JSON-Antwort mithilfe der Models und wirft spezifische Exceptions (ApiException, NetworkException, DataParsingException). Wird über Riverpod bereitgestellt (weatherApiServiceProvider).
      • repositories/: weather_repository_impl.dart. Die konkrete Implementierung unseres Datenvertrags. Diese Klasse kennt den WeatherApiService und den LocationService. Sie ruft deren Methoden auf, fängt deren Exceptions ab und wandelt sie in Failures um (z.B. wird NetworkException zu NetworkFailure). Sie wandelt auch die API-Models in die App-internen Entities um. Wird über Riverpod bereitgestellt (weatherRepositoryProvider).
    • domain/: Das Kernstück der App-Logik.
      • entities/: location_info.dart, current_weather_data.dart. Einfache Dart-Klassen, die die Daten repräsentieren, wie sie die App intern benötigt, unabhängig von der API. Nutzen Equatable für einfache Vergleiche.
      • repositories/: weather_repository.dart. Das ist nur ein „Interface“ (abstrakte Klasse). Es definiert, was man mit Wetterdaten tun können muss (z.B. getWeatherForLocation, getCurrentLocationCoordinates), aber nicht wie. Das ist der Vertrag, den die WeatherRepositoryImpl erfüllen muss.
    • application/: Die Orchestrierung.
      • weather_state.dart: Definiert, wie der Zustand des Wetter-Features aussieht: ein enum WeatherStatus (initial, loading, success, failure), die eigentlichen CurrentWeatherData, der selectedLocation und ein optionales Failure-Objekt. Nutzt Equatable und copyWith.
      • weather_notifier.dart: Die Steuerzentrale. Ein StateNotifier, der den WeatherState hält und aktualisiert. Er bekommt das WeatherRepository übergeben (Dependency Injection durch Riverpod). Enthält die Logik für fetchWeatherForCurrentLocation und refreshWeatherData. Er ruft Methoden im Repository auf, behandelt das Either<Failure, Success>-Ergebnis und aktualisiert den state entsprechend.
    • presentation/: Die Benutzeroberfläche.
      • providers/: weather_providers.dart. Definiert den weatherNotifierProvider, der den WeatherNotifier erstellt und der UI zur Verfügung stellt.
      • widgets/: Kleine, wiederverwendbare UI-Teile. location_header.dart zeigt den Ortsnamen, current_temperature_display.dart zeigt die Temperatur und Zeit. Sie bekommen ihre Daten von außen übergeben.
      • screens/: weather_screen.dart. Der Hauptbildschirm. Ein ConsumerStatefulWidget, das über ref.watch(weatherNotifierProvider) den aktuellen WeatherState bekommt. Basierend auf dem status im State, zeigt es entweder einen Ladeindikator, die Wetter-Widgets oder eine Fehlermeldung (_buildErrorWidget). Es nutzt ref.read(weatherNotifierProvider.notifier) um Aktionen im Notifier auszulösen (initiales Laden, Refresh). Der RefreshIndicator ermöglicht Pull-to-Refresh. Der AnimatedSwitcher sorgt für weiche Übergänge.

Schritt 4: Den Datenfluss verstehen

Wie hängt das alles zusammen, wenn die App startet?

  1. Start (main.dart -> app.dart -> WeatherScreen): Die App wird initialisiert, ProviderScope wird erstellt. WeatherScreen wird angezeigt.
  2. Initial Load (WeatherScreen.initState): Der Screen merkt, dass er neu ist (initialState.status == WeatherStatus.initial) und triggert über ref.read(weatherNotifierProvider.notifier).fetchWeatherForCurrentLocation() den Ladevorgang im Notifier.
  3. Loading State (WeatherNotifier): Der Notifier setzt sofort seinen state auf status: WeatherStatus.loading.
  4. UI Reaction (WeatherScreen): Da der Screen via ref.watch auf den State hört, wird er neu gebaut und zeigt jetzt (im _buildContent) einen Ladeindikator an.
  5. Get Coordinates (WeatherNotifier -> WeatherRepository -> LocationService):
    • Notifier ruft _weatherRepository.getCurrentLocationCoordinates() auf.
    • Das Repo (WeatherRepositoryImpl) ruft _locationService.getCurrentPosition() auf.
    • Der LocationService interagiert mit dem geolocator, fragt ggf. nach Berechtigungen und holt die Position.
    • Wenn erfolgreich, gibt der Service die Position zurück. Wenn ein Fehler auftritt (z.B. Berechtigung verweigert), wirft er eine LocationException.
    • Das Repo fängt die Exception, wandelt sie ggf. in eine Failure (PermissionFailure, LocationFailure) um und gibt Left(failure) zurück. Bei Erfolg erstellt es LocationInfo und gibt Right(locationInfo) zurück.
  6. Handle Coordinates Result (WeatherNotifier):
    • Der Notifier erhält das Either. Bei Left(failure) setzt er den state auf status: WeatherStatus.failure mit dem failure-Objekt -> Die UI zeigt die Fehlermeldung.
    • Bei Right(locationInfo) geht es weiter. Der Notifier versucht noch, den Namen via _weatherRepository.getLocationDisplayName zu holen (was in Teil 3 noch nicht viel tut) und ruft dann _fetchWeatherDataAndUpdateState(finalLocationInfo) auf.
  7. Get Weather Data (WeatherNotifier -> WeatherRepository -> WeatherApiService):
    • Notifier ruft _weatherRepository.getWeatherForLocation(locationInfo) auf.
    • Das Repo (WeatherRepositoryImpl) ruft _apiService.getCurrentWeather(...) auf.
    • Der WeatherApiService baut die URL, macht den http.get-Aufruf, parst das JSON in ForecastResponseModel, extrahiert CurrentWeatherModel. Bei Fehlern (Netzwerk, API-Status, Parsing) wirft er NetworkException, ApiException, DataParsingException.
    • Das Repo fängt diese Exceptions, wandelt sie in Failures (NetworkFailure, ServerFailure) um und gibt Left(failure) zurück. Bei Erfolg wandelt es CurrentWeatherModel in CurrentWeatherData (unser App-Entity) um und gibt Right(weatherData) zurück.
  8. Handle Weather Result (WeatherNotifier):
    • Der Notifier erhält das Either. Bei Left(failure) setzt er den state auf status: WeatherStatus.failure mit dem failure-Objekt -> Die UI zeigt die Fehlermeldung.
    • Bei Right(weatherData) setzt er den state auf status: WeatherStatus.success, speichert weatherData und locationInfo im State und löscht den Fehler (clearError: true).
  9. UI Reaction (WeatherScreen): Der Screen hört wieder auf die State-Änderung (ref.watch). Er wird neu gebaut, _buildContent erkennt WeatherStatus.success und zeigt jetzt LocationHeader und CurrentTemperatureDisplay mit den Daten aus dem state an.

Schritt 5: Schlüsselkonzepte im Code

  • Riverpod für State Management & Dependency Injection:
    • ProviderScope (in main.dart): Macht Provider global verfügbar.
    • @riverpod / ...Provider (z.B. in location_service.dart, weather_repository_impl.dart): Definiert, wie eine Instanz eines Service oder Repositories erstellt wird. Riverpod kümmert sich darum, dass nur eine Instanz erstellt und wiederverwendet wird. Das ist Dependency Injection: Komponenten bekommen ihre Abhängigkeiten (wie den http.Client oder den LocationService) „injiziert“, statt sie selbst zu erstellen.
    • StateNotifierProvider (weather_providers.dart): Ein spezieller Provider für unseren WeatherNotifier, der dessen Zustand (WeatherState) verwaltet.
    • ConsumerWidget / ConsumerStatefulWidget (WeatherScreen): Widgets, die auf Provider „hören“ können.
    • ref.watch() (im build von WeatherScreen): Liest den Wert eines Providers und baut das Widget neu, wenn sich der Wert (hier der WeatherState) ändert.
    • ref.read() (im initState oder in Callbacks wie onPressed von WeatherScreen): Liest den Wert eines Providers einmalig, ohne auf Änderungen zu hören. Wird verwendet, um Methoden im Notifier aufzurufen.
  • Fehlerbehandlung (Either, Failure, Exception):
    • Services (LocationService, WeatherApiService) werfen spezifische Exceptions bei technischen Problemen.
    • Das Repository (WeatherRepositoryImpl) fängt diese Exceptions und wandelt sie in allgemeinere Failures um. Es gibt das Ergebnis als Either<Failure, Success> zurück – ein klarer Weg, um Erfolg oder Misserfolg zu signalisieren, ohne Exceptions durch die ganze App zu werfen.
    • Der Notifier (WeatherNotifier) behandelt das Either-Ergebnis und aktualisiert den WeatherState entsprechend (status: WeatherStatus.failure oder success).
    • Die UI (WeatherScreen) reagiert auf den status und das error-Feld im State und zeigt die passende Ansicht.
  • Asynchronität (Future, async, await): Netzwerk- und GPS-Anfragen dauern eine Weile. Future repräsentiert einen Wert, der irgendwann verfügbar sein wird. async markiert eine Funktion, die await verwenden kann. await pausiert die Ausführung der Funktion, bis der Future abgeschlossen ist, ohne die gesamte App zu blockieren. Wir sehen das intensiv im Notifier, Repository und den Services.
  • Immutability & Equatable: Der WeatherState wird nie direkt geändert. Stattdessen wird mit copyWith eine neue Instanz mit den geänderten Werten erstellt. Das macht den Zustandsfluss vorhersagbar. Equatable hilft Riverpod (und uns beim Testen), effizient zu erkennen, ob sich der Zustand wirklich geändert hat, indem es Objekte anhand ihrer Eigenschaften vergleicht, nicht nur anhand ihrer Speicheradresse.

Schritt 6: Ausführen und Experimentieren!

Jetzt, wo du eine Vorstellung davon hast, wie der Code aufgebaut ist und funktioniert:

  1. Starte die App: Wähle dein Gerät in VS Code und drücke F5.
  2. Beobachte: Verfolge die Log-Ausgaben im „DEBUG CONSOLE“-Fenster von VS Code. Du solltest die Meldungen von AppLogger aus den verschiedenen Schichten sehen.
  3. Experimentiere:
    • Ändere Texte in den Widgets.
    • Setze Haltepunkte (Breakpoints) in VS Code (klicke links neben die Zeilennummer) in verschiedenen Methoden (z.B. im Notifier, im Repo, im Service) und starte die App im Debug-Modus (F5). Steppe durch den Code (F10, F11), um den Fluss live zu sehen.
    • Simuliere Fehler: Wirf testweise eine Exception im WeatherApiService oder gib Left(NetworkFailure()) im Repository zurück, um zu sehen, wie die Fehlerbehandlung in der UI greift.

Zusammenfassung und Nächste Schritte

Das war ein tiefer Einblick in den Code unseres ersten Meilensteins! Du hast gesehen, wie wir mit einer klaren Architektur und Werkzeugen wie Riverpod eine skalierbare und testbare Grundlage geschaffen haben, auch für eine zunächst einfache Funktion. Du verstehst jetzt (hoffentlich!) besser:

  • Die Aufteilung in Schichten (Presentation, Domain/Application, Data, Core).
  • Die Verantwortlichkeiten der einzelnen Komponenten (Widgets, Notifier, Repositories, Services).
  • Den Daten- und Kontrollfluss durch die App.
  • Die Grundprinzipien von State Management, Fehlerbehandlung und Asynchronität in Flutter.

Im nächsten Teil (Teil 4) bauen wir darauf auf und machen die App interaktiver: Wir fügen die Adresssuche hinzu!

Bleib dran und viel Spaß beim Erkunden des Codes!


Weiterführende Ressourcen & Vertiefung (für Teil 3)

Dieser Teil hat viele grundlegende Konzepte der Flutter-Entwicklung eingeführt. Hier sind Links zum Vertiefen:

  1. Projektstruktur & Architektur:
    • Flutter App architecture samples (GitHub): https://github.com/flutter/samples/tree/main/experimental/context_menus (Beispielhaft, es gibt viele Ansätze) – Oft komplex, aber gibt Ideen. Unsere Struktur ist eine vereinfachte Form, die oft als „Feature-First“ mit Schichtentrennung bezeichnet wird.
    • Clean Architecture in Flutter (Artikel/Videos): Suche nach „Clean Architecture Flutter“ für verschiedene Interpretationen und Erklärungen (z.B. von Reso Coder, Vandad Nahavandipoor).
  2. Flutter Pakete (Dependencies):
  3. State Management (Riverpod):
  4. Dart Grundlagen:
  5. Android Spezifika:

Deine Flutter Wetter-App: Schritt für Schritt – Teil 2

Teil 2: Das Fundament legen – Deine Flutter-Entwicklungsumgebung unter Windows einrichten

Hallo zurück zu unserer Flutter-Wetter-App-Serie!

In Teil 1 haben wir uns angesehen, was wir bauen wollen – eine Wetter-App mit aktuellen Daten, Verlauf, Prognose und sogar der Grünlandtemperatursumme – und warum eine Wetter-App ein großartiges Lernprojekt ist. Bevor wir jedoch die erste Zeile Code für unsere App schreiben können, brauchen wir das richtige Werkzeug und eine eingerichtete Werkstatt.

Genau das ist das Ziel dieses zweiten Teils: Wir legen heute das Fundament und richten deine Entwicklungsumgebung auf deinem Windows-Rechner ein. Keine Sorge, das klingt vielleicht erstmal nach viel, aber es ist ein einmaliger Prozess. Wir gehen alles Schritt für Schritt durch!

Was wir heute tun:

  1. Flutter SDK installieren: Das Herzstück, das alle nötigen Werkzeuge und Bibliotheken für Flutter enthält.
  2. Android Studio installieren: Auch wenn wir hauptsächlich mit VS Code arbeiten, brauchen wir Android Studio für wichtige Android-spezifische Werkzeuge (SDK, Emulator).
  3. flutter doctor ausführen: Unser Diagnose-Tool, das prüft, ob alles korrekt eingerichtet ist.
  4. Ein Testgerät einrichten: Entweder einen Emulator (ein virtuelles Handy) oder dein echtes Android-Smartphone vorbereiten.
  5. Visual Studio Code (VS Code) konfigurieren: Unseren bevorzugten Code-Editor mit den nötigen Flutter-Erweiterungen ausstatten.
  6. Das erste Flutter-Projekt erstellen und starten: Sicherstellen, dass die Standard-App läuft und unsere Umgebung bereit ist.

Los geht’s!

Schritt 1: Flutter SDK installieren

Das Flutter SDK (Software Development Kit) ist eine Sammlung von Werkzeugen, die es uns ermöglichen, Flutter-Anwendungen zu entwickeln und zu kompilieren.

  1. Download: Gehe zur offiziellen Flutter-Installationsseite für Windows: https://docs.flutter.dev/get-started/install/windows
    • Lade die neueste stabile Version des Flutter SDK als ZIP-Datei herunter (suche nach dem blauen Button „Download the latest stable release of the Flutter SDK“).
  2. Entpacken: Erstelle einen Ordner direkt auf deinem Laufwerk C: (oder einem anderen Laufwerk, wenn du möchtest), zum Beispiel C:\flutter\. Wichtig: Entpacke das Flutter SDK nicht in Ordner wie C:\Program Files\ oder C:\Program Files (x86)\, da diese oft spezielle Berechtigungen erfordern, die zu Problemen führen können.
    • Entpacke den Inhalt der heruntergeladenen ZIP-Datei in den neu erstellten C:\flutter\ Ordner. Du solltest jetzt einen Pfad wie C:\flutter\bin haben.
  3. PATH-Umgebungsvariable aktualisieren: Damit dein Computer weiß, wo er die Flutter-Befehle finden kann, müssen wir den Pfad zum bin-Ordner von Flutter zur sogenannten PATH-Umgebungsvariable hinzufügen.
    • Gib „Umgebungsvariablen“ in die Windows-Suche ein und wähle „Systemumgebungsvariablen bearbeiten“.
    • Klicke im neuen Fenster unten auf den Button „Umgebungsvariablen…“.
    • Suche im oberen Bereich („Benutzervariablen für [Dein Benutzername]“) die Variable Path. Wähle sie aus und klicke auf „Bearbeiten…“. (Wenn sie nicht existiert, klicke auf „Neu…“.)
    • Klicke auf „Neu“ und füge den vollständigen Pfad zu deinem Flutter bin-Ordner hinzu: C:\flutter\bin (passe dies an, falls du Flutter woanders entpackt hast).
    • Bestätige alle offenen Fenster mit „OK“.
    • Wichtig: Damit die Änderung wirksam wird, musst du alle bereits geöffneten Kommandozeilenfenster (Eingabeaufforderung oder PowerShell) schließen und neu öffnen. Manchmal ist sogar ein Neustart des PCs nötig.
  4. Überprüfung: Öffne eine neue Eingabeaufforderung (cmd) oder PowerShell und gib den Befehl ein:
    bash flutter --version
    Wenn alles geklappt hat, sollte Flutter dir nun seine Version und weitere Informationen anzeigen. Herzlichen Glückwunsch, Flutter ist installiert!

Schritt 2: Android Studio installieren (für Android SDK & Co.)

Auch wenn wir VS Code zum Schreiben unseres Codes verwenden, ist Android Studio unerlässlich, da es das Android SDK, die Build-Tools und den Emulator-Manager mitbringt.

  1. Download: Lade Android Studio von der offiziellen Seite herunter: https://developer.android.com/studio
  2. Installation: Führe die heruntergeladene .exe-Datei aus und folge dem Installationsassistenten. Wähle die Standardeinstellungen („Standard“ oder „Recommended“). Android Studio wird das neueste Android SDK, die SDK Platform-Tools und die SDK Build-Tools herunterladen und installieren.
    • Merke dir den Installationsort des Android SDKs. Normalerweise ist das so etwas wie C:\Users\DEIN_BENUTZERNAME\AppData\Local\Android\Sdk. Du findest ihn auch später in Android Studio unter File > Settings > Languages & Frameworks > Android SDK.
  3. Android Studio starten: Starte Android Studio nach der Installation. Es wird eventuell noch einige Komponenten herunterladen.
  4. (Optional, aber empfohlen) Flutter und Dart Plugins: Auch wenn wir VS Code nutzen, installieren wir die Flutter- und Dart-Plugins in Android Studio. Das hilft flutter doctor bei der Erkennung und kann nützlich sein, falls du doch mal eine Funktion von Android Studio brauchst.
    • Gehe in Android Studio zu File > Settings > Plugins.
    • Suche im „Marketplace“-Tab nach „Flutter“ und klicke auf „Install“. Akzeptiere die Installation des Dart-Plugins, wenn du dazu aufgefordert wirst.
    • Starte Android Studio neu, wenn du dazu aufgefordert wirst.
  5. Android SDK Command-line Tools: Stelle sicher, dass diese installiert sind.
    • Gehe in Android Studio zu File > Settings > Languages & Frameworks > Android SDK.
    • Wähle den Tab „SDK Tools“.
    • Setze einen Haken bei „Android SDK Command-line Tools (latest)“.
    • Klicke auf „Apply“ oder „OK“, um sie zu installieren.
  6. Android-Lizenzen akzeptieren: Flutter muss sicherstellen, dass du die Lizenzen für das Android SDK akzeptiert hast. Öffne eine neue Eingabeaufforderung oder PowerShell und führe aus:
    bash flutter doctor --android-licenses
    Lies die Lizenzbedingungen durch und gib bei jeder Abfrage y (für yes) ein, um sie zu akzeptieren.

Schritt 3: flutter doctor – Der Gesundheitscheck

Jetzt ist es Zeit für einen Check-up! flutter doctor ist ein Befehl, der deine Umgebung überprüft und dir sagt, ob alles für die Flutter-Entwicklung bereit ist oder ob noch etwas fehlt.

Öffne eine neue Eingabeaufforderung oder PowerShell und führe aus:

flutter doctor

Du wirst eine Ausgabe ähnlich dieser sehen (kann bei dir leicht abweichen):

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.x.x, on Microsoft Windows [Version ...], locale de-DE)
[✓] Android toolchain - develop for Android devices (Android SDK version 3x.x.x)
[✓] Chrome (visualize Flutter web apps with Chrome)
[!] Visual Studio - develop for Windows (Visual Studio not installed)  <-- Ignorieren, wenn du nur für Android entwickelst
[✓] Android Studio (version 202x.x.x)
[✓] VS Code (version 1.x.x)
[✓] Connected device (1 available)                                  <-- Oder 'No devices available'
[✓] Network resources

* No issues found!
  • Was bedeutet das?
    • [✓] (Haken): Alles in Ordnung für diese Komponente!
    • [!] (Ausrufezeichen): Es gibt ein Problem oder eine Empfehlung. Lies die Meldung genau durch, flutter doctor gibt oft Hinweise zur Lösung. (Das Visual Studio für Windows-Entwicklung kannst du ignorieren, wenn du nur für Android entwickelst).
    • [✗] (Kreuz): Etwas Wichtiges fehlt oder ist falsch konfiguriert.
    • [?] (Fragezeichen): Etwas konnte nicht überprüft werden.
  • Ziel: Wir wollen Haken bei Flutter, Android toolchain, Android Studio (oder zumindest, dass es erkannt wird) und später bei VS Code und Connected device.
  • Keine Panik: Wenn nicht sofort alles grün ist, ist das normal! Lies die Meldungen von flutter doctor und folge den Anweisungen. Oft fehlt nur ein kleiner Schritt oder ein Neustart.

Schritt 4: Ein Testgerät einrichten

Um deine App zu sehen und zu testen, brauchst du ein Android-Gerät. Du hast zwei Möglichkeiten:

Option A: Android Emulator (Virtuelles Gerät)

Ein Emulator simuliert ein Android-Gerät auf deinem Computer.

  1. AVD Manager öffnen: Klicke auf dem Willkommensbildschirm auf More Actions -> Virtual Device Manager (oder wenn ein Projekt offen ist: Tools -> Device Manager).
  2. Gerät erstellen: Klicke auf „Create device“.
    • Wähle eine Hardware aus (z.B. „Pixel 6“ oder eine ähnliche, aktuelle Geräteklasse). Klicke „Next“.
    • Wähle ein System-Image aus (eine Android-Version). Lade eines herunter, falls noch keines vorhanden ist (empfohlen: eine relativ aktuelle API-Version, z.B. API 33 oder 34). Klicke „Next“.
    • Gib dem virtuellen Gerät (AVD) einen Namen und klicke auf „Finish“.
  3. Emulator starten: Wähle dein neu erstelltes Gerät im Device Manager aus und klicke auf das Play-Symbol (▶️) in der „Actions“-Spalte, um es zu starten. Es kann einen Moment dauern, bis der Emulator hochgefahren ist.
    • Performance-Hinweis: Emulatoren können auf manchen Rechnern langsam sein. Stelle sicher, dass die Hardware-Virtualisierung (Intel HAXM oder AMD Hypervisor / Windows Hypervisor Platform) in deinem BIOS/UEFI aktiviert ist und in Android Studio konfiguriert wurde (passiert oft automatisch).

Option B: Physisches Android-Gerät (Dein Smartphone)

Du kannst auch dein eigenes Android-Handy zum Testen verwenden.

  1. Entwickleroptionen aktivieren: Gehe auf deinem Handy zu Einstellungen > Über das Telefon. Tippe dort mehrmals schnell hintereinander auf die „Build-Nummer“, bis eine Meldung erscheint wie „Du bist jetzt Entwickler!“.
  2. USB-Debugging aktivieren: Gehe zurück zu den Einstellungen. Suche nach dem neuen Menüpunkt Entwickleroptionen (manchmal unter System > Erweitert). Aktiviere dort die Option USB-Debugging. Bestätige die Warnmeldung.
  3. USB-Treiber (falls nötig): Verbinde dein Handy per USB-Kabel mit dem Computer. Windows versucht normalerweise, die richtigen Treiber automatisch zu installieren. Falls dein Gerät nicht erkannt wird, suche auf der Website des Handy-Herstellers nach spezifischen „OEM USB Drivers“ für dein Modell und installiere sie.
  4. Verbindung autorisieren: Wenn du dein Handy zum ersten Mal mit aktiviertem USB-Debugging verbindest, erscheint auf dem Handy eine Meldung „USB-Debugging zulassen?“. Setze einen Haken bei „Von diesem Computer immer zulassen“ und tippe auf „OK“ oder „Zulassen“.

Überprüfung: Egal ob Emulator oder echtes Gerät, öffne eine neue Eingabeaufforderung und führe aus:

flutter devices

Dein verbundenes Gerät oder der laufende Emulator sollte nun in der Liste erscheinen! flutter doctor sollte jetzt auch einen Haken bei Connected device zeigen.

Schritt 5: Visual Studio Code (VS Code) einrichten

VS Code ist unser bevorzugter Editor zum Schreiben des Flutter-Codes.

  1. Download & Installation: Lade VS Code herunter und installiere es: https://code.visualstudio.com/ . Die Installation ist unkompliziert.
  2. Flutter Extension installieren:
    • Starte VS Code.
    • Klicke auf das Extensions-Symbol in der linken Seitenleiste (sieht aus wie vier Quadrate).
    • Suche nach „Flutter“.
    • Wähle die offizielle Extension von „Dart Code“ aus und klicke auf „Install“. Diese Extension installiert automatisch auch die notwendige „Dart“-Extension.
    • Starte VS Code neu, wenn du dazu aufgefordert wirst.

Schritt 6: Das erste Flutter-Projekt erstellen und starten

Endlich! Zeit, unser erstes (Standard-)Flutter-Projekt zu erstellen und zu sehen, ob alles funktioniert.

  1. Projekt erstellen:
    • Öffne VS Code.
    • Öffne die Command Palette mit Strg+Shift+P (oder Ctrl+Shift+P).
    • Tippe „Flutter: New Project“ und wähle die Option aus.
    • Wähle „Application“.
    • Wähle einen Ordner auf deinem Computer, wo das Projekt gespeichert werden soll (z.B. C:\dev\flutter_projekte\).
    • Gib einen Namen für dein Projekt ein. Wichtig: Der Name muss klein geschrieben sein und darf nur Buchstaben, Zahlen und Unterstriche enthalten (z.B. flutter_weather_app_blog). Drücke Enter.
    • VS Code erstellt nun die Projektstruktur und lädt eventuell noch benötigte Pakete herunter. Das kann einen Moment dauern.
  2. Gerät auswählen: Stelle sicher, dass dein Emulator läuft oder dein Handy verbunden und erkannt ist. In der unteren rechten Ecke der VS Code Statusleiste solltest du nun dein Gerät auswählen können (klicke auf den Gerätenamen oder „No Device“).
  3. App starten:
    • Öffne die Datei lib/main.dart. Das ist der Einstiegspunkt der App.
    • Drücke F5 oder gehe im Menü auf Run > Start Debugging.
    • Flutter wird nun die App kompilieren und auf deinem ausgewählten Gerät installieren und starten. Der erste Start kann etwas länger dauern.
  4. Erfolg! Du solltest nun die Flutter-Standard-Demo-App sehen (die mit dem Zähler und dem blauen Button). Wenn du auf den Button tippst, erhöht sich der Zähler.

Wenn etwas nicht klappt (Troubleshooting):

  • flutter Befehl nicht gefunden: Überprüfe nochmal genau die PATH-Variable (Schritt 1.3). Hast du den richtigen Pfad (C:\flutter\bin) hinzugefügt? Hast du die Eingabeaufforderung/VS Code neu gestartet? Manchmal hilft ein PC-Neustart.
  • flutter doctor zeigt Fehler bei Android toolchain: Stelle sicher, dass Android Studio korrekt installiert ist, die Command-line Tools vorhanden sind (Schritt 2.5) und du die Lizenzen akzeptiert hast (Schritt 2.6). Manchmal muss man Flutter explizit sagen, wo das SDK liegt: flutter config --android-sdk C:\Users\DEIN_BENUTZERNAME\AppData\Local\Android\Sdk (Pfad anpassen).
  • Emulator startet nicht oder ist sehr langsam: Überprüfe die Virtualisierungs-Einstellungen im BIOS/UEFI deines PCs und stelle sicher, dass HAXM/Hypervisor installiert und aktiviert ist (Android Studio hilft dabei oft). Gib dem Emulator ggf. mehr RAM in den AVD-Einstellungen (aber nicht zu viel!).
  • Echtes Gerät wird nicht erkannt: USB-Debugging aktiviert? Verbindung autorisiert? Richtige USB-Treiber installiert? Probiere ein anderes USB-Kabel oder einen anderen USB-Port.
  • Weitere Hilfe: Die offizielle Flutter-Dokumentation (https://docs.flutter.dev/get-started/install/windows) ist sehr detailliert und eine großartige Ressource bei Problemen.

Geschafft! Was kommt als Nächstes?

Puh, das war der aufwendigste, aber notwendige Teil! Du hast jetzt eine voll funktionsfähige Flutter-Entwicklungsumgebung auf deinem Windows-Rechner. Dein Werkzeugkasten ist bereit!

Herzlichen Glückwunsch zu diesem wichtigen Meilenstein! 🎉

Im nächsten Teil (Teil 3) wird es richtig spannend: Wir werfen den Demo-Code raus und beginnen mit der Entwicklung unserer Wetter-App. Wir werden:

  • Die Projektstruktur und Architektur anlegen (Services, Repository, State Management mit Riverpod).
  • Den aktuellen GPS-Standort des Geräts abfragen.
  • Unsere erste API-Anfrage an Open-Meteo senden, um die aktuelle Temperatur zu bekommen.
  • Die Temperatur auf dem Bildschirm anzeigen.
  • Erklären, warum wir von Anfang an auf eine solide Architektur setzen.

Bleib dran, es geht jetzt richtig los mit dem Code!


Weiterführende Ressourcen & Vertiefung (für Teil 2)

Die Einrichtung der Entwicklungsumgebung ist ein entscheidender Schritt. Hier sind Links zu den offiziellen Anleitungen und wichtigen Werkzeugen:

  1. Flutter SDK Installation (Windows):
  2. Android Studio & Android SDK:
  3. flutter doctor:
  4. Android-Geräte für Tests einrichten:
  5. Visual Studio Code & Flutter Extension:

Deine Flutter Wetter-App: Schritt für Schritt: Teil 1

Teil 1: Startschuss zur Flutter Wetter-App – Was wir bauen und warum

Hallo und herzlich willkommen zu unserer neuen Blog-Serie! Du wolltest schon immer mal eine eigene App entwickeln, bist neugierig auf Flutter und Dart oder suchst ein praktisches Projekt, um deine Kenntnisse zu vertiefen? Dann bist du hier genau richtig!

In dieser Serie nehmen wir dich an die Hand und entwickeln gemeinsam, Schritt für Schritt, eine Wetter-App für Android. Wir nutzen dafür das moderne Framework Flutter mit der Programmiersprache Dart und entwickeln unter Windows mit dem beliebten Editor Visual Studio Code (VS Code).

Warum diese Serie?

Es gibt unzählige Tutorials und Dokumentationen da draußen. Warum also noch eine Serie? Unser Ziel ist es, zwei Fliegen mit einer Klappe zu schlagen:

  1. Flutter & Dart praxisnah lernen: Statt trockener Theorie wollen wir direkt in die Entwicklung einsteigen und Konzepte wie Widgets, State Management, API-Anfragen und die Nutzung von Geräte-Features (wie GPS) an einem konkreten Beispiel erlernen.
  2. Eine sinnvolle App erstellen: Am Ende soll nicht nur Code stehen, sondern eine tatsächlich nutzbare Wetter-App, die interessante Informationen liefert – über das typische „Hello World“ hinaus.

Diese Serie richtet sich sowohl an Einsteiger, die ihre erste App bauen wollen, als auch an Entwickler, die vielleicht von anderen Plattformen kommen und Flutter kennenlernen möchten.

Das Zielprojekt: Unsere Wetter-App

Was genau wollen wir bauen? Eine Wetter-App, die folgende Funktionen bieten soll:

  1. Aktuelle Temperatur: Zuerst ganz einfach: Die App soll die momentane Temperatur für einen bestimmten Ort anzeigen können. Als Datenquelle nutzen wir die kostenlose und umfangreiche API von open-meteo.com.
  2. Flexible Ortswahl: Später soll es möglich sein, entweder den aktuellen Standort des Geräts per GPS zu verwenden oder eine beliebige Adresse einzugeben, für die das Wetter angezeigt werden soll.
  3. Temperaturverlauf als Diagramm: Wir wollen nicht nur den aktuellen Wert sehen, sondern auch ein Liniendiagramm, das die Temperaturentwicklung der letzten Woche zeigt und eine Prognose für die kommende Woche gibt.
  4. Spezialfunktion: Grünlandtemperatursumme (GTS): Für Landwirte, Gärtner oder einfach nur Interessierte wollen wir die aktuelle Grünlandtemperatursumme für den gewählten Ort berechnen und anzeigen. Dies ist ein agrarmeteorologischer Wert, der den Vegetationsbeginn im Frühjahr anzeigt.

Warum eine Wetter-App?

Eine Wetter-App ist ein ideales Lernprojekt, weil sie viele typische Aspekte der App-Entwicklung abdeckt:

  • Benutzeroberfläche (UI): Gestaltung ansprechender Ansichten zur Darstellung von Daten.
  • Netzwerkkommunikation: Abrufen von Daten von einer externen API (Application Programming Interface).
  • Datenverarbeitung: Umwandlung der API-Antworten in ein nutzbares Format.
  • Geräte-Integration: Zugriff auf den Standort des Geräts (GPS).
  • Datenvisualisierung: Darstellung von Daten in Diagrammen.
  • State Management: Verwalten des Zustands der App (z.B. welcher Ort ist gewählt, welche Daten sind geladen).

Der Technologie-Stack: Womit arbeiten wir?

  • Flutter: Googles UI-Toolkit zur Erstellung von nativ kompilierten Anwendungen für Mobilgeräte, Web und Desktop aus einer einzigen Codebasis.
  • Dart: Die objektorientierte Programmiersprache hinter Flutter.
  • Visual Studio Code (VS Code): Ein kostenloser, plattformübergreifender und sehr beliebter Code-Editor mit hervorragender Flutter/Dart-Unterstützung.
  • Windows: Unser Entwicklungsbetriebssystem.
  • Open-Meteo.com API: Unsere Quelle für Wetterdaten. Kostenlos, keine Registrierung nötig und sehr umfangreich.
  • Diverse Flutter Packages: Wir werden verschiedene „Bibliotheken“ (Packages) nutzen, um uns Arbeit abzunehmen, z.B. für HTTP-Anfragen (http), Standortbestimmung (geolocator, geocoding), Diagramme (fl_chart) und mehr.
    (Wir werden diese nach und nach in der Serie einführen und erklären)

Der Weg: Unsere Blog-Serie

Wir werden das Projekt in logische Schritte unterteilen, wobei jeder Blog-Post einen oder mehrere dieser Schritte abdeckt:

  1. (Dieser Post): Einführung und Zieldefinition.
  2. Teil 2: Das Fundament legen – Deine Flutter-Entwicklungsumgebung unter Windows einrichten.
  3. Teil 3: Der erste Meilenstein: Aktuelle Temperatur am aktuellen Ort – Wir bauen die Kernarchitektur (Services, Repository, State Management mit Riverpod), holen die GPS-Position, fragen die Open-Meteo API nach der aktuellen Temperatur und zeigen diese an. Hier erklären wir, warum eine gute Struktur von Anfang an wichtig ist.
  4. Teil 4: Mehr Orte, mehr Möglichkeiten – Adresseingabe hinzufügen und zwischen Standorten wechseln.
  5. Teil 5: Kurven zeichnen – Temperaturverläufe mit Diagrammen visualisieren.
  6. Teil 6: Grünland im Blick – Die Grünlandtemperatursumme berechnen und anzeigen.
  7. (Eventuell weitere Teile für z.B. Code-Optimierung, Testing-Vertiefung, UI-Verfeinerung)

Jeder Teil enthält detaillierte Anleitungen, Code-Snippets und Erklärungen, sodass du dem Prozess gut folgen kannst.
Wir legen von Anfang an Wert auf eine saubere und testbare Code-Struktur, wie sie auch in professionellen Projekten verwendet wird – selbst wenn die erste Funktion noch einfach erscheint.

Bist du bereit?

Wir hoffen, diese Einführung hat dein Interesse geweckt! Im nächsten Teil machen wir unsere Hände schmutzig und richten die notwendige Software auf deinem Windows-Rechner ein, damit wir mit der eigentlichen Entwicklung starten können.

Bleib dran und begleite uns auf der Reise zur fertigen Flutter Wetter-App!


Weiterführende Ressourcen & Vertiefung (für Teil 1)

In diesem ersten Teil haben wir das Projekt vorgestellt und die Technologien benannt. Hier sind einige Links, um einen ersten Eindruck zu bekommen:

  1. Flutter:
  2. Dart:
  3. Visual Studio Code (VS Code):
  4. Open-Meteo API:
    • Offizielle Webseite: https://open-meteo.com/ – Hier kannst du sehen, welche Wetterdaten verfügbar sind und die API-Dokumentation erkunden (das machen wir später genauer).

Freie Wetterdaten nutzen: Anwendungen und praktische Tipps

Einleitung Freie Wetterdaten sind eine wertvolle Ressource für Entwickler, Forscher, Landwirte, Outdoor-Enthusiasten und viele mehr. Dank offener APIs und frei zugänglicher Wetterdatensätze lassen sich präzise Analysen durchführen, innovative Anwendungen entwickeln und fundierte Entscheidungen treffen. In diesem Artikel zeigen wir Ihnen, wozu Sie frei verfügbare Wetterdaten nutzen können und wie Sie diese praktisch einsetzen.

Wozu lassen sich Wetterdaten nutzen?

  1. Landwirtschaft und Gartenbau: Durch genaue Messwerte zu Temperatur, Niederschlag und Bodenfeuchte können Landwirte die Bewässerung optimieren, Ernteausfälle reduzieren und Schädlinge besser kontrollieren.
  2. Smart Home & IoT: Wetterdaten können in Smart-Home-Systeme integriert werden, um beispielsweise automatische Rollläden zu steuern oder Heizsysteme zu optimieren.
  3. Reise- und Freizeitplanung: Outdoor-Aktivitäten wie Wandern, Segeln oder Camping lassen sich anhand lokaler Wetterbedingungen sicherer gestalten.
  4. Umwelt- und Klimaforschung: Langfristige Messdaten helfen Wissenschaftlern, Klimatrends zu analysieren und Umweltveränderungen zu untersuchen.
  5. Energiebranche: Solar- und Windkraftanlagen können durch Messwerte zu Sonneneinstrahlung und Windgeschwindigkeit effizienter gesteuert werden.
  6. App-Entwicklung: Entwickler können Wetterdaten in ihre Apps und Websites integrieren, um nützliche Funktionen wie Wetterwarnungen oder personalisierte Analysen bereitzustellen.
  7. Lokale Wetterstationen & Community-Projekte: Bürgerwissenschaftler und Wetterenthusiasten können mit lokalen Wetterstationen präzisere, hyperlokale Daten erfassen und teilen.

Wie kommt man an freie Wetterdaten? Es gibt zahlreiche Plattformen und Anbieter, die frei verfügbare Messwerte bereitstellen. Hier eine umfangreiche Liste mit deutschsprachigen und internationalen Quellen:

Die meisten dieser Anbieter stellen eine API zur Verfügung, mit der Nutzer Messwerte in ihre Anwendungen integrieren können.

Praktische Umsetzung: Ein Beispiel mit DWD Open Data Um Messwerte von Wetterstationen des DWD abzurufen, können Sie die Open-Data-Schnittstelle des DWD nutzen. Ein Beispiel für den Abruf der aktuellen Temperaturmessungen aus Deutschland mit Python:

import requests

URL = "https://opendata.dwd.de/climate_environment/CDC/observations_germany/climate/hourly/air_temperature/recent/stundenwerte_TU_00433_akt.zip"
response = requests.get(URL)

if response.status_code == 200:
    with open("stundenwerte_TU_00433_akt.zip", "wb") as file:
        file.write(response.content)
    print("Daten erfolgreich heruntergeladen.")
else:
    print("Fehler beim Abrufen der Messwerte. Bitte überprüfen Sie die URL oder die Stations-ID.")

Zusätzliche Umsetzung: Wetterdaten für eine Wohnadresse bestimmen Falls Sie Wetterdaten für eine spezifische Adresse benötigen, können Sie OpenStreetMap zur Geokodierung nutzen, um die Koordinaten zu bestimmen, und anschließend mit Open-Meteo oder anderen Diensten die nächstgelegene Wetterstation abfragen.

Beispiel 1: Aktuelle Wetterdaten für eine Adresse

import requests

def get_current_weather(address):
    geo_url = "https://nominatim.openstreetmap.org/search"
    params = {"q": address, "format": "json", "limit": 1}
    headers = {"User-Agent": "Wetterdaten-Skript/1.0 (kontakt@example.com)"}
    geo_response = requests.get(geo_url, params=params, headers=headers).json()

    if geo_response:
        lat, lon = geo_response[0]["lat"], geo_response[0]["lon"]
        weather_url = f"https://api.open-meteo.com/v1/forecast?latitude={lat}&longitude={lon}&current_weather=true"
        weather_response = requests.get(weather_url).json()
        print(f"Aktuelles Wetter für {address}: {weather_response['current_weather']}")
    else:
        print("Fehler beim Abrufen der Geodaten.")

get_current_weather("Kurfürstendamm 1, 10115 Berlin, Deutschland")

Beispiel 2: Historische Wetterdaten für eine Adresse und einen Zeitraum

def get_historical_weather(address, start_date, end_date):
    geo_url = "https://nominatim.openstreetmap.org/search"
    params = {"q": address, "format": "json", "limit": 1}
    headers = {"User-Agent": "Wetterdaten-Skript/1.0 (kontakt@example.com)"}
    geo_response = requests.get(geo_url, params=params, headers=headers).json()

    if geo_response:
        lat, lon = geo_response[0]["lat"], geo_response[0]["lon"]
        weather_url = f"https://archive-api.open-meteo.com/v1/archive?latitude={lat}&longitude={lon}&start_date={start_date}&end_date={end_date}&daily=temperature_2m_max,temperature_2m_min"
        weather_response = requests.get(weather_url).json()
        print(f"Historische Wetterdaten für {address} vom {start_date} bis {end_date}: {weather_response}")
    else:
        print("Fehler beim Abrufen der Geodaten.")

get_historical_weather("Marienplatz, 80331 München, Deutschland", "2024-03-01", "2024-03-10")

Beispiel 3: aktuelle Temperatur mit Höhenangabe

import requests

# Schritt 1: Koordinaten für die Adresse abrufen
address = "Marienplatz, München, Deutschland"
geo_url = "https://nominatim.openstreetmap.org/search"
params = {
    "q": address,
    "format": "json",
    "limit": 1
}
headers = {
    "User-Agent": "Wetterdaten-Skript/1.0 (kontakt@example.com)"
}
geo_response = requests.get(geo_url, params=params, headers=headers).json()

if geo_response:
    lat = geo_response[0]["lat"]
    lon = geo_response[0]["lon"]
    print(f"Koordinaten für {address}: {lat}, {lon}")

    # Schritt 2: Wetterdaten für die Koordinaten abrufen
    weather_url = f"https://api.open-meteo.com/v1/forecast?latitude={lat}&longitude={lon}&current_weather=true"
    weather_response = requests.get(weather_url).json()

    if "elevation" in weather_response:
        ele = weather_response["elevation"]
        print(f"Höhe für {address}: {ele} m")
    
    if "current_weather" in weather_response:
        print(f"Aktuelle Temperatur: {weather_response['current_weather']['temperature']}°C")
    else:
        print("Keine Wetterdaten verfügbar.")
else:
    print("Fehler beim Abrufen der Geodaten.")
    

Fazit Frei verfügbare Wetterdaten eröffnen eine Vielzahl an Möglichkeiten, sei es für die persönliche Nutzung, wissenschaftliche Forschung oder kommerzielle Anwendungen. Neben großen Wetterdiensten bieten auch Community-Projekte hyperlokale Wetterdaten an, die besonders für detaillierte Analysen nützlich sind. Durch einfache API-Abfragen lassen sich Messwerte von Wetterstationen in bestehende Systeme integrieren und vielseitig nutzen. Probieren Sie es aus und entdecken Sie die Potenziale freier Wetterdaten für Ihre eigenen Projekte!

Morgens oder abends duschen? Finde deine perfekte Duschroutine!

Gehörst du auch zu denjenigen, die sich fragen, wann der beste Zeitpunkt für eine erfrischende Dusche ist? Ob du nun morgens unter die Brause springst, um wach und munter in den Tag zu starten, oder abends die Anspannung des Tages mit warmem Wasser abspülst – Duschen ist für viele ein tägliches Ritual für Hygiene und Wohlbefinden. Doch wann ist der ideale Zeitpunkt für dich? Die Antwort ist nicht allgemeingültig und hängt ganz von deinen persönlichen Bedürfnissen, Vorlieben und Gewohnheiten ab. Lass uns gemeinsam die Vor- und Nachteile der Morgendusche und der Abenddusche beleuchten und dir wertvolle Tipps für ein gesundes und nachhaltiges Duscherlebnis geben.

Die Morgendusche: Dein Frischekick für den Start in den Tag

Für viele ist die Dusche am Morgen der perfekte Wachmacher. Das kühle Nass, besonders bei etwas niedrigerer Temperatur, kann wahre Wunder wirken, um dich energiegeladen und fit zu fühlen. Kühleres Wasser setzt Adrenalin frei, was deine Aufmerksamkeit und Konzentration verbessern kann. Zudem wird die Blutzirkulation angeregt, was sowohl Körper als auch Geist belebt.

Ein weiterer Pluspunkt der Morgendusche ist, dass du damit Schweiß und Talg abwäschst, die sich während der Nacht auf deiner Haut angesammelt haben können. Das ist besonders vorteilhaft für Menschen, die nachts stark schwitzen. Auch bei fettigen Haaren kann eine morgendliche Reinigung helfen, überschüssigen Talg zu entfernen und das Haar den ganzen Tag frisch aussehen zu lassen. Einige berichten sogar, dass sie unter der Morgendusche besonders klare Gedanken fassen und kreative Ideen entwickeln.

Allerdings hat die Morgendusche auch ihre Kehrseite. Oft ist die Zeit am Morgen begrenzt, und eine ausgiebige Duschroutine passt möglicherweise nicht in den straffen Zeitplan. Zudem kann häufiges Duschen mit heißem Wasser, auch am Morgen, die Haut austrocknen und reizen, insbesondere wenn du zu trockener oder empfindlicher Haut neigst. Es gibt auch Hinweise aus der Forschung, dass kalte Duschen am Morgen auf nüchternen Magen möglicherweise zur Bildung eines schädlichen Nervengifts führen könnten, da die antioxidativen Reserven des Körpers zu dieser Zeit möglicherweise geringer sind.

Die Abenddusche: Entspannung und Reinigung für eine erholsame Nacht

Die Dusche am Abend wird oft als ein wohltuendes Ritual empfunden, um den Tag hinter sich zu lassen. Sie befreit die Haut effektiv von Schweiß, Schmutz, Make-up und Umweltverschmutzungen, die sich im Laufe des Tages angesammelt haben. Das warme Wasser wirkt beruhigend auf angespannte Muskeln und kann helfen, Stress abzubauen. Eine warme Dusche vor dem Schlafengehen kann sogar die Schlafqualität verbessern, da sie den Körper entspannt und möglicherweise die Körpertemperatur leicht senkt, was dem Körper signalisiert, dass es Zeit zum Schlafen ist.

Besonders Menschen mit trockener und empfindlicher Haut profitieren oft von einer abendlichen Dusche, da sich die natürliche Schutzbarriere der Haut über Nacht ohne die Reibung enger Kleidung besser regenerieren kann. Auch Pflegeprodukte haben über Nacht mehr Zeit, in die Haut einzuziehen. Die Abenddusche ist zudem ein idealer Zeitpunkt für die Rasur, da sich die Haut über Nacht erholen kann und eventuelle Rötungen bis zum nächsten Morgen abklingen. Allergiker können ebenfalls von einer abendlichen Dusche profitieren, da sie Pollen und andere Allergene von Haut und Haaren spült, die sich tagsüber angesammelt haben.

Ein möglicher Nachteil der Abenddusche ist, dass sehr lange oder heiße Bäder auch hier zu trockener Haut führen können. Zudem vermissen manche Menschen das belebende Gefühl einer Morgendusche und fühlen sich nach dem Aufwachen möglicherweise nicht ganz so frisch.

Individuelle Bedürfnisse und Hauttypen: Was ist für dich das Richtige?

Die beste Zeit und Art zu duschen hängt stark von deinem Hauttyp und deinen individuellen Bedürfnissen ab.

  • Trockene Haut: Hier wird oft eine Abenddusche mit lauwarmem Wasser empfohlen, damit sich die Feuchtigkeitsbarriere der Haut über Nacht erholen kann. Verwende milde, feuchtigkeitsspendende Reinigungsmittel und vermeide heißes Wasser sowie lange Duschgänge.
  • Fettige Haut: Für fettige Haut kann eine Morgendusche vorteilhafter sein, um überschüssigen Talg abzuwaschen, der sich über Nacht gebildet hat. Auch hier ist lauwarmes Wasser empfehlenswert, um ein Austrocknen zu vermeiden, was paradoxerweise zu einer erhöhten Talgproduktion führen kann.
  • Empfindliche Haut: Bei empfindlicher Haut wird oft eine Abenddusche mit lauwarmem Wasser empfohlen, um Reizungen zu minimieren. Wähle parfümfreie und milde Reinigungsmittel.
  • Allergien: Wenn du unter Allergien leidest, kann eine abendliche Dusche helfen, Allergene wie Pollen von deiner Haut und deinen Haaren zu entfernen.
  • Nächtliches Schwitzen: Bei starkem nächtlichem Schwitzen kann eine Morgendusche angenehmer sein, um dich frisch für den Tag zu fühlen.

Berücksichtige auch deinen Lebensstil. Benötigst du morgens einen Frischekick, oder legst du mehr Wert auf Entspannung am Abend? Wie aktiv bist du und wie stark schwitzt du? Probiere verschiedene Routinen aus, um herauszufinden, was für dich am besten funktioniert. Es gibt keine allgemeingültige Antwort.

Tipps für ein optimales Duscherlebnis

Unabhängig davon, wann du duschst, gibt es einige wichtige Punkte zu beachten, um deine Haut zu schonen und gleichzeitig nachhaltig mit Wasser umzugehen:

  • Wassertemperatur: Dusche mit lauwarmem Wasser (32-38°C) und vermeide zu heißes Wasser.
  • Dauer: Halte deine Duschen kurz, idealerweise zwischen 5 und 10 Minuten.
  • Reinigungsmittel: Verwende milde, pH-neutrale Duschgele oder Syndets anstelle von aggressiven Seifen. Nutze sie nur an den Körperstellen, wo es wirklich notwendig ist.
  • Häufigkeit: Dusche nicht zu oft. Alle zwei oder drei Tage können für die grundlegende Hygiene ausreichen, es sei denn, du bist stark verschwitzt oder schmutzig. Tägliches Duschen ist in Ordnung, aber vermeide es, mehrmals täglich zu duschen.
  • Nach dem Duschen: Tupfe deine Haut sanft trocken und trage eine feuchtigkeitsspendende Lotion auf, besonders wenn du trockene Haut hast.
  • Haare waschen: Wasche deine Haare nicht jeden Tag, um ein Austrocknen der Kopfhaut zu vermeiden.
  • Nachhaltigkeit: Achte auf einen geringen Wasserverbrauch und erwäge die Anschaffung eines Sparduschkopfes. Reduziere den Wasserdruck und seife nur die notwendigen Bereiche ein. Ein herkömmlicher Duschkopf verbraucht etwa 15 Liter pro Minute, während ein Sparduschkopf nur etwa 8 Liter benötigt.

Fazit: Finde deine ideale Duschroutine

Ob du dich nun für die belebende Morgendusche oder die entspannende Abenddusche entscheidest, ist letztendlich eine sehr persönliche Angelegenheit. Beide Zeitpunkte haben ihre Vor- und Nachteile. Achte auf die Signale deiner Haut und berücksichtige deine individuellen Bedürfnisse. Experimentiere mit verschiedenen Routinen und finde heraus, was sich für dich am besten anfühlt und optimal in deinen Alltag passt. So wird deine tägliche Dusche zu einem Wohlfühlmoment, der deiner Haut guttut und gleichzeitig die Umwelt schont.

Weiterführende Links


Frühling auf der Alb: Die Grünlandtemperatursumme als Kompass für Imker

Der Frühling auf der Schwäbischen Alb ist eine besondere Zeit. Nach oft langen und manchmal rauen Wintern erwacht die Natur sichtbar zu neuem Leben. Für uns Imkerinnen und Imker bedeutet das den Start in die aktivste Phase des Bienenjahres. Doch wann ist der richtige Zeitpunkt für welche Maßnahmen am Bienenstand? Wann lösen sich die Wintertrauben auf? Wann beginnt der erste große Polleneintrag? Ein wertvoller Indikator, der uns hier Orientierung gibt, ist die Grünlandtemperatursumme (GTS).

Was ist die Grünlandtemperatursumme (GTS)?

Die Grünlandtemperatursumme, oft auch einfach GTS genannt, ist eine Kenngröße aus der Agrarmeteorologie. Sie beschreibt den kumulierten Wärmeeffekt auf das Pflanzenwachstum im Frühjahr. Vereinfacht gesagt, werden ab dem 1. Januar eines Jahres alle positiven Tagesmitteltemperaturen (der Durchschnitt aus Höchst- und Tiefsttemperatur eines Tages) aufsummiert. Liegt die Tagesmitteltemperatur unter 0°C, wird für diesen Tag 0°C zur Summe addiert.

Ein wichtiger Schwellenwert ist dabei die 200-Grad-Marke. Das Erreichen dieser Summe wird oft als der phänologische Vegetationsbeginn angesehen – der Zeitpunkt, ab dem das Gras auf den Wiesen nachhaltig zu wachsen beginnt.

Warum ist die GTS für Imker auf der Schwäbischen Alb relevant?

Die Entwicklung der Bienenvölker im Frühjahr ist stark temperaturabhängig. Die GTS gibt uns Imkern einen relativ verlässlichen Anhaltspunkt, wann bestimmte Entwicklungsstadien bei den Bienen und in der Natur erreicht werden – oft genauer als der reine Kalendertag, gerade in einer Region wie der Schwäbischen Alb, wo das Frühjahr aufgrund der Höhenlage oft etwas später einsetzt als im Tal.

  • Erste Ausflüge & Reinigungsflug: Schon vor Erreichen der 200-Grad-Marke, an sonnigen Tagen mit Temperaturen über ca. 10-12°C, finden erste kurze Ausflüge und der wichtige Reinigungsflug statt.
  • Beginn des Polleneintrags: Das Erreichen der 200-Grad-Marke korreliert oft gut mit dem Beginn der Blüte wichtiger früher Pollenspender wie Salweide und Hasel. Dieser erste massive Polleneintrag ist der Startschuss für die Königin, die Eilage deutlich zu erhöhen und das Brutnest massiv zu erweitern.
  • Volksentwicklung: Die steigende GTS signalisiert uns, dass die Völker nun verstärkt brüten und wachsen. Dies ist entscheidend für die Planung von Maßnahmen wie:
    • Kontrolle der Futterreserven (Brut kostet viel Energie!)
    • Erste kurze Durchsicht bei geeignetem Wetter (über 15°C, windstill)
    • Gegebenenfalls Erweiterung des Brutraums
  • Trachtbeginn: Spätere GTS-Werte können Hinweise auf den Blühbeginn wichtiger Trachten wie Obstblüte (Kirsche, Apfel auf den Streuobstwiesen der Alb!) oder später Raps geben. Das hilft bei der Entscheidung, wann die Honigräume aufgesetzt werden müssen.

Wo finde ich aktuelle GTS-Werte für die Schwäbische Alb?

Die GTS ist kein statischer Wert, sondern entwickelt sich täglich weiter. Aktuelle Werte und Prognosen sind daher Gold wert. Hier gibt es verschiedene Quellen:

  • Agrarmeteorologische Dienste: Landesanstalten oder Wetterdienste (z.B. DWD, LAZBW) bieten oft regionale Agrarwetterdaten an, manchmal inklusive der GTS für verschiedene Stationen.
  • Lokale Wetterstationen: Private oder halböffentliche Wetterstationen in der Region können ebenfalls zur Berechnung herangezogen werden.
  • Imkerliche Plattformen und Netzwerke: Hier kommt auch beelot.de ins Spiel. Solche Plattformen bündeln oft relevante Informationen für Imker, darunter Wetterdaten, Trachtbeobachtungen und phänologische Daten aus der Community. Es lohnt sich, auf solchen Portalen nach regionalen Daten oder Erfahrungswerten von Kollegen aus der Schwäbischen Alb zu suchen oder diese selbst beizusteuern. Sie können eine wertvolle Ergänzung zu den offiziellen Wetterdaten sein, da sie oft sehr standortnah sind.

Fazit: Die GTS als nützlicher Helfer

Die Grünlandtemperatursumme ist kein Allheilmittel und ersetzt nicht die genaue Beobachtung am Bienenstand und in der Natur. Aber sie ist ein wertvolles Werkzeug, um die Entwicklung im Frühjahr besser einzuschätzen und imkerliche Maßnahmen auf der Schwäbischen Alb besser zu planen. Gerade weil das Wetter hier manchmal seine eigenen Regeln hat, hilft uns die GTS, den tatsächlichen biologischen Startpunkt des Frühlings zu erkennen.

Nutzt die verfügbaren Daten, tauscht euch mit Imkerkollegen aus (vielleicht ja über Plattformen wie beelot.de) und beobachtet eure Bienen und die erwachende Natur auf unserer schönen Alb. Ich wünsche euch allen einen guten Start in die Bienensaison 2025!


Wie nutzt ihr die Grünlandtemperatursumme oder andere Indikatoren für eure Imkerei auf der Schwäbischen Alb? Teilt eure Erfahrungen gerne in den Kommentaren!

Weiter führende Links:

Installation von Paperless-ngx auf dem Raspberry Pi

Im heutigen Beitrag zeige ich dir, wie du Paperless-ngx auf deinem Raspberry Pi installieren und deine bestehende Installation von einem Windows-Rechner umziehen kannst. Wir gehen Schritt für Schritt durch die nötigen Vorbereitungen, die Docker-Installation und die Migration deiner Daten. Außerdem erkläre ich, wie du Speicherorte und Backup-Optionen so konfigurierst, dass deine Dokumente jederzeit sicher abrufbar sind.

Was ist Paperless-ngx?

Paperless-ngx ist eine Open-Source-Lösung zur digitalen Dokumentenverwaltung, die speziell dafür entwickelt wurde, Papierdokumente zu scannen, zu organisieren und einfach durchsuchbar zu machen. Mit Paperless-ngx kannst du deine digitalen Dateien zentral speichern, kategorisieren und dank der OCR-Funktion auch durchsuchen.

1. Vorbereitung des Raspberry Pi

Für die Installation nutzen wir einen Raspberry Pi 4 mit mindestens 4 GB RAM. Du benötigst außerdem eine aktuelle Version von Raspberry Pi OS (es reicht auch Raspberry Pi OS Lite, da wir keinen Desktop brauchen) sowie Zugriff auf den Pi via SSH.

Schritte zur Vorbereitung:

  1. Raspberry Pi OS installieren: Lade Raspberry Pi OS herunter und installiere es auf deiner SD-Karte. Am einfachsten geht das über das Raspberry Pi Imager tool
  2. SSH aktivieren: Erstelle eine leere Datei mit dem Namen ssh auf der Boot-Partition der SD-Karte. So kannst du den Pi später über SSH ansteuern.
  3. Updates durchführen:
    sudo apt update && sudo apt upgrade -y

2. Docker und Docker Compose installieren

Da Paperless-ngx in Containern läuft, benötigen wir Docker und Docker Compose.

Docker Installation:

  1. Installiere Docker:
    url -fsSL https://get.Docker.com -o get-Docker.sh && chmod +x get-Docker.sh<br>sudo ./get-Docker.sh

  2. Füge deinen Nutzer zur Docker-Gruppe hinzu:
    sudo usermod -aG docker $USER

  3. Starte den Docker-Dienst:
    sudo systemctl enable docker<br>sudo systemctl start docker

Docker Compose installieren:

sudo apt install docker-compose -y

3. Paperless-ngx Container einrichten

Erstelle ein Verzeichnis für die Paperless-ngx-Konfiguration:

mkdir ~/paperless-ngx && cd ~/paperless-ngx

Erstelle dann eine docker-compose.yml-Datei, die die Paperless-ngx-Container beschreibt.

Beispiel für die docker-compose.yml:

 services:
broker:
image: docker.io/library/redis:7
restart: unless-stopped
volumes:
- redisdata:/data
webserver:
image: ghcr.io/paperless-ngx/paperless-ngx:latest
restart: unless-stopped
depends_on:
- broker
- gotenberg
- tika
ports:
- "8000:8000"
volumes:
- /home/pi/paperless-ngx/data:/usr/src/paperless/data
- /home/pi/paperless-ngx/media:/usr/src/paperless/media
- /home/pi/paperless-ngx/export:/usr/src/paperless/export
- /home/pi/paperless-ngx/consume:/usr/src/paperless/consume
env_file: docker-compose.env
environment:
PAPERLESS_SECRET_KEY: "DeinGeheimerSchluessel"
PAPERLESS_REDIS: redis://broker:6379
PAPERLESS_TIKA_ENABLED: 1
PAPERLESS_TIKA_GOTENBERG_ENDPOINT: http://gotenberg:3000
PAPERLESS_TIKA_ENDPOINT: http://tika:9998
PAPERLESS_OCR_LANGUAGE: deu+eng
PAPERLESS_ACCOUNT_SESSION_REMEMBER: "True"
PAPERLESS_OCR_USER_ARGS: '{"invalidate_digital_signatures": true}'
PAPERLESS_FILENAME_FORMAT: '{{created_year}}/{{correspondent}}/{{title}}'
gotenberg:
image: docker.io/gotenberg/gotenberg:8.7
restart: unless-stopped
command:
- "gotenberg"
- "--chromium-disable-javascript=true"
- "--chromium-allow-list=file:///tmp/.*"

tika:
image: docker.io/apache/tika:latest
restart: unless-stopped

volumes:
data:
media:
redisdata:

Die volumes werden mit /home/pi/paperless-ngx auf dem Raspi zugreifbar und sind nicht nur im Docker-Image vorhanden. So kann man das consume-Verzeichnis freigeben und Dokumente dort aus dem Netzwerk plazieren. Über das export-Verzeichnis lässt sich das backup steuern

4. Migration der bestehenden Paperless-ngx-Daten vom Windows-Rechner

Falls du bereits eine Installation von Paperless-ngx auf deinem Windows-Rechner genutzt hast, möchtest du deine bestehenden Daten und Einstellungen auf den Pi übertragen.

Schritte zur Migration:

  1. Daten exportieren: Kopiere die Verzeichnisse data und media von deinem Windows-System auf den Raspberry Pi.
    scp -r /path/to/your/data pi@your-pi-ip:~/paperless/data<br>scp -r /path/to/your/media pi@your-pi-ip:~/paperless/media

  2. Container starten:
    docker-compose up -d

Paperless-ngx sollte nun mit deinen bisherigen Dokumenten und Metadaten starten.

5. Speicherorte und Backup-Optionen konfigurieren

Die Daten- und Medienverzeichnisse sind in der docker-compose.yml-Datei definiert. Um regelmäßige Backups zu gewährleisten, kannst du entweder die Ordner regelmäßig auf eine externe Festplatte oder in die Cloud kopieren.

Einrichtung von Backups

Eine einfache Möglichkeit, ein Backup zu erstellen, ist die Nutzung eines Cronjobs:

crontab -e

Füge den folgenden Eintrag hinzu, um täglich um Mitternacht ein Backup zu erstellen:

0 0 * * * tar -czvf ~/backups/paperless_backup_$(date +\%F).tar.gz ~/paperless

Fazit

Nach diesen Schritten sollte deine Paperless-ngx-Installation auf dem Raspberry Pi einsatzbereit sein und alle deine bestehenden Daten enthalten. Indem du regelmäßige Backups einrichtest und Speicherorte sorgfältig konfigurierst, kannst du sicherstellen, dass deine Dokumente stets geschützt sind.

Viel Erfolg bei der Einrichtung, und viel Freude mit deiner digitalen Dokumentenverwaltung!

« Ältere Beiträge

© 2025 Allround-Blog

Theme von Anders NorénHoch ↑