## Architektur Flutter gibt Entwicklern eine große Freiheit bei der Auswahl der Architektur für ihre Anwendungen. Es gibt keine festen Regeln oder Vorschriften zur Ordnerstruktur oder anderen Konventionen bezüglich der Architektur. Als Architektur für die Demo Anwendung der Fallstudie wurde eine drei-schichtige Architektur gewählt. Eine Schichtenarchitektur ist nicht nur Teil der Architektur von Flutter selbst, sondern ist auch eine bewährte Architektur für die Entwicklung von Flutter Anwendungen, sowie auch generell in der Software Entwicklung. Die drei Schichten der Architektur sind die Präsentationsschicht, die Geschäftsschicht und die Datenzugriffsschicht. In der Präsentationsschicht wird die Benutzeroberfläche mit den Flutter Widgets erstellt. Die Geschäftsschicht ist für die Implementierung der Geschäftslogik verantwortlich und die Datenzugriffsschicht für den Zugriff auf die Datenbank und die Datenverarbeitung [@hajianFlutterEngineering2024, 219]. Die drei Schichten sind voneinander unabhängig und kommunizieren nur jeweils mit der nächstliegenden Schicht wie in Abbildung \ref{schichten} dargestellt. \begin{figure}[ht] \centering \caption{3-Schichtenarchitektur der Flutter Anwendung} \label{schichten} \end{figure} ```{=latex} \begin{center} ``` ```{.mermaid loc=assets/mermaid caption="3-Schichtenarchitektur der Flutter Anwendung" #fig:reference-name} flowchart TD A[Präsentationsschicht] <--> B B[Geschäftslogikschicht] <--> C C[Datenzugriffsschicht] ``` ```{=latex} \end{center} ``` \begin{figure}[ht] \centering \end{figure} ## Ordner Konventionen Für die 3-Schichtenarchitektur wurde eine Feature-First Ordnerstruktur gewählt. Die Ordnerstruktur der fertigen Anwendung ist in Abbildung \ref{ordnerstruktur} dargestellt. \begin{figure}[ht] \caption{Die Ordnerstruktur der Flutter eLinux Anwendung} \label{ordnerstruktur} \centering \begin{minipage}{7cm} \dirtree{% .1 lib/. .2 common. .2 constants. .2 features. .3 benchmark. .3 home. .3 material\char`\_demo. .3 matrix\char`\_rgb. .3 news\char`\_api. .3 settings. .3 system\char`\_resources. .2 app.dart. .2 main.dart. } \end{minipage} \end{figure} Im Hauptverzeichnis der Anwendung befinden sich die Ordner `common`, `constants`, `features` und die Dateien `app.dart` und `main.dart`. Der Einstiegspunkt der Anwendung ist die `main.dart` Datei, diese wird von Dart aufgerufen und startet die `MaterialApp` welche in der `app.dart` Datei definiert ist. Die `common` und `constants` Ordner enthalten allgemeine Klassen und Konstanten, die in der gesamten Anwendung verwendet werden. Der `features` Ordner enthält die einzelnen Features der Anwendung als Unterordner. Jedes Feature ist hierbei eines der verschiedenen Fenster, welches die Demo App besitzt und welche zuvor in den Anforderungen beschrieben worden sind. Innerhalb jedes Features wird die 3-Schichtenarchitektur umgesetzt mit den Ordnern `presentation`, `business` und `data`. Nicht alle Features benötigen dabei alle Schichten, je nach Komplexität des Features. Diese Struktur ermöglicht es, dass jedes Fenster der Demo Anwendung modular und unabhängig von den anderen Fenstern entwickelt wurde und der Code für ein Feature an einem Ort zu finden ist. Dadurch wird die Wartbarkeit und Erweiterbarkeit der Anwendung verbessert und der Code ist leichter zu verstehen. Für die Demo App ist dies besonders wichtig, da die Anwendung als Einstiegspunkt so später umstrukturiert werden kann für andere Anwendungen, die auf der Demo App aufbauen. ## Riverpod Riverpod ist ein einfaches, aber leistungsstarkes State-Management-Tool für Flutter. Es wurde entwickelt, um die Verwaltung des Zustands in Flutter-Anwendungen zu vereinfachen [@rousseletRrousselGitRiverpod2024]. In dem Projekt wurde Riverpod genutzt, um die Zustandsverwaltung der Anwendung zwischen der Prästentations- und Geschäftsschicht zu verwalten. In der Präsentationsschicht werden die Provider genutzt, um den Zustand von diesen auszulesen und in der Geschäftsschicht werden die Provider mithilfe des Riverpod Generators generiert. Der Riverpod Generator ist ein Code-Generator, der mit Riverpod verwendet wird, um die Provider und anderen Boilerplate-Code automatisch zu generieren. Genutzt wird der Generator mit der Definition "@riverpod" am Anfang einer Klasse oder Funktion. Mit dem Paket "_riverpod_annotation_" werden dabei Hinweise im Code Editor angezeigt, die zeigen, ob der Code für den Generator korrekt ist oder nicht. Das Projekt ist so konfiguriert, dass "_riverpod_annotation_" aktiviert ist. Generierte Dart Dateien enden mit "_.g.dart_".