Add conclustion

chapters/basics/state-management.tex

@@ -24,6 +24,7 @@ Beide Sichtweisen haben gemein, dass die Grundaufgabe der Zustandsverwaltung die
 Nachdem nun eingeführt wurde, was unter einer Zustandsverwaltung in Flutter zu verstehen ist, werden nun mögliche bestehende Ansätze für eine Zustandsverwaltung skizziert, um im weiteren Verlauf der Ausarbeitung im Analyse- und Evaluationskapitel diese eingehender zu untersuchen.
 
 \subsection{Auswahl}
+\label{sec:section}
 
 Zur Auswahl der zu evaluierenden Lösungsansätze wird die Aufzählung von Zustandsverwaltungs-Ansätzen aus der Flutter-Dokumentation \autocite{flutterStateManagement} als Grundlage verwendet. In dieser Aufzählung werden die Zustandsverwaltungssysteme Provider, Riverpod, setState, InheritedWidget \& -Model, Redux, Fish-Redux, BLoC / RX, GetIt, MobX, Flutter Commands, Binder, GetX, states\_rebuilder und Triple Pattern genannt. 
 

chapters/conclusion/conclusion.tex

@@ -1,7 +1,27 @@
 \chapter{Fazit}
 
-Ausblick:
+Zum Schluss der Ausarbeitung, werden die Ergebnisse der Evaluation nochmals zusammengefasst und analysiert, inwiefern mit der Evaluation das Ziel der Ausarbeitung erreicht werden konnte. Darauf aufbauend wird eine Empfehlung für verschiedene Anwendungsfälle gegeben. Am Ende folgt ein Ausblick, welche Aspekte der Ausarbeitung in Zukunft noch erweitert werden könnten.
 
-Austausch der MI-Metrik
-Erweiterung um andere Statemanagement-Systeme
-Vergleich mit React?
+Mit der Evaluation konnten bis auf das setState-Konzept alle Zustandsverwaltungssysteme evaluiert werden. Die Bewertungskriterien haben sich dabei größtenteils als aussagekräftig erwiesen. Lediglich der \acl{mi} konnte keine wirklich aussagekräftigen Ergebnisse bieten, da die Ergebnisse alle sehr nah aneinander liegen und so keine Differenzierung zwischen den einzelnen Systemen erfolgt ist. Die Metrik der Effizienz hingegen zeigt relativ aufschlussreich, welche Systeme effizient mit dem Neu-Erstellen von Widgets umgehen und welche nicht. Die qualitativen Bewertungen können zusätzlich einen detaillierten Einblick in die Umsetzung verschiedener Zustandssysteme bieten.
+
+Bei den Zustandsverwaltungssystemen selbst haben sich in der Evaluation besonders die Bibliotheken Riverpod und MobX mit guten Ergebnissen in den qualitativen Bewertungen sowohl in der quantitativen Bewertung der Effizienz gezeigt. Riverpod bietet dabei mehr Freiräume bei der Strukturgestaltung der Zustände während MobX hier eine klare Struktur vorgibt.
+
+Somit hat sich auch gezeigt, dass Riverpod eine sinnvolle Weiterentwicklung von Provider ist, welches in der Evaluation mehrere Schwachstellen wie beispielsweise in der Skalierbarkeit aufwies.
+
+BLoC und InheritedWidget konnten zwar die Anforderungen an die Beispielanwendung umsetzen, erwiesen sich allerdings ohne besondere Optimierung als wenig effizient und hatten Einschränkungen in der Lesbarkeit und Verständlichkeit. 
+
+ReduX als besonders im React-Ökosystem oft verwendeter Ansatz zur Zustandsverwaltung, konnte auf Flutter nicht überzeugen, da hier besonders der zentrale Zustand zu einem Problem wird, da dieser für die in der Evaluation schlechtesten Effizienz-Werte und eine negative Bewertung bei der Skalierbarkeit verantwortlich ist.
+
+Zusammenfassend lässt sich sagen, dass durch die Evaluation ein umfassender Überblick über die Funktionsweise der verschiedenen Zustandsverwaltungssysteme gegeben werden konnte, und eine in großen Teilen aussagekräftige Bewertung der Zustandssysteme vorgenommen werden konnte. Zudem konnte Anforderungen und Probleme bei der Zustandsverwaltung in Flutter entwickelt und dargestellt werden.
+
+\section{Empfehlungen}
+
+Für große Anwendungen mit verschiedenen Komponenten und vielen Zuständen, wird MobX empfohlen, da hier besonders auch im Vergleich zu Riverpod eine bessere Strukturbestimmung der Anwendung gewährleistet werden kann und die Bibliothek auch die Verwaltung und Koppelung großer Mengen an Zuständen ermöglichen kann.
+
+Für mittelgroße Anwendungen, empfiehlt sich die Nutzung von Riverpod, da hier besonders die Vielseitigkeit der Bibliothek die Integration von verschiedenen Ansätzen erleichtert und das Merkmal der Strukturbestimmung hier eine nicht so große Relevanz haben dürfte.
+
+Für kleine Anwendungen empfiehlt sich entweder die Nutzung von InheritedWidgets, wenn beispielsweise auf die Einbindung weitere Bibliotheken verzichtet werden kann oder die Verwendung von Provider, da hier die Probleme mit der Skalierbarkeit und Lesbarkeit von ProxyProvidern nicht stark ins Gewicht fallen sollten. 
+
+\section{Ausblick}
+
+Für weitergehende Untersuchungen bieten sich mehrere Aspekte an. Zum einen ist die Ersetzung der \ac{mi}-Metrik durch eine aussagekräftigere Metrik empfehlenswert, um so auch die Anforderung der Komplexität / Wartbarkeit in der Evaluation aussagekräftig bewerten zu können. Zum anderen bietet sich die Erweiterung der Evaluation um andere, alternative Zustandsverwaltungssysteme, die in dieser Ausarbeitung nicht untersucht werden konnten (vgl. \autoref{sec:section}), um ein vollständigeres Bild über die Zustandsverwaltungssysteme für Flutter zu bekommen. Ein weiterer untersuchentwerter Aspekt könnte der Vergleich mit der Zustandsverwaltung von React sein, um mögliche Unterschiede darzustellen.