Final changes

chapters/analyse/analyse.tex

@@ -77,7 +77,7 @@ Ausgehend von der Prüfung dieser Eigenschaften, wird eine Bewertung mit den Wer
 
 Die Effizienz eines Zustandsverwaltungssystemes lässt sich auch dadurch messen, wie effizient es das Neubauen von Widgets nach Veränderungen orchestriert. So sollte ein Widget nur dann neu gebaut werden, wenn dies durch eine das Widget betreffende Änderung des Zustands es verlangt. Andere Betrachtungen der Performance sind nur schwer zu messen, da sich andere Variablen wie die Architektur oder Verwendung innerhalb der Anwendung einen großen Einfluss darauf haben. 
 
-Geprüft werden soll dieses Verhalten an x verschiedenen Prüfstellen in der Anwendung, indem an diesen stellen Zähler eingesetzt werden, die zählen, wann das Widget neu gebaut wird. Dabei wird eine für alle Zustandsverwaltungssysteme gleiche automatische Teststrecke erstellt, welche sicherstellen soll, dass immer die exakt gleichen Bedienhandlungen vorgenommen werden. Damit lässt sich dann abschätzen, wie effizient die Zustandsverwaltungssysteme die Zustandsänderungen an die Widgets propagieren. Erstrebenswert hierbei ist es, ein möglichst geringen Wert bei den Zählern zu erreichen, wobei sichergestellt werden muss, dass dabei alle Systeme die Funktionalität richtig implementieren. 
+Geprüft werden soll dieses Verhalten an zwei verschiedenen Prüfstellen in der Anwendung, indem an diesen Stellen Zähler eingesetzt werden, die zählen, wann das Widget neu gebaut wird. Dabei wird eine für alle Zustandsverwaltungssysteme gleiche automatische Teststrecke erstellt, welche sicherstellen soll, dass immer die exakt gleichen Bedienhandlungen vorgenommen werden. Damit lässt sich dann abschätzen, wie effizient die Zustandsverwaltungssysteme die Zustandsänderungen an die Widgets propagieren. Erstrebenswert hierbei ist es, ein möglichst geringen Wert bei den Zählern zu erreichen, wobei sichergestellt werden muss, dass dabei alle Systeme die Funktionalität richtig implementieren. 
 
 \subsection{Komplexität / Wartbarkeit}
 \label{sec:complexity}

chapters/basics/flutter.tex

@@ -10,7 +10,7 @@ Neben Flutter existieren auch andere Cross-Plattform Werkzeuge, die das gleiche
 
 \subsection{Technischer Überblick}
 
-Dieser Abschnitt vermittelt die technischen Grundlagen für die Flutter Technologie. Flutter und die damit entwickelten Anwendungen werden mit der Dart-Programmiersprache entwickelt. Dart lässt sich dabei mit den bereits etablierten Programmiersprachen wie Java oder JavaScript vergleichen wie in \autoref{lst:dartExample} zu sehen ist und ist objektorientierte, optional statisch typisierte \autocite{dartTypes}.
+Dieser Abschnitt vermittelt die technischen Grundlagen für die Flutter Technologie. Flutter und die damit entwickelten Anwendungen werden mit der Dart-Programmiersprache entwickelt. Dart lässt sich dabei mit den bereits etablierten Programmiersprachen wie Java oder JavaScript vergleichen, wie in \autoref{lst:dartExample} zu sehen ist, und ist damit eine objektorientierte, optional statisch typisierte Programmiersprache\autocite{dartTypes}.
 
 \begin{lstlisting}[caption={Aufbau eines einfachen Flutter-Widgets in Dart}, label={lst:dartExample}]
 import 'package:flutter/material.dart';
@@ -44,7 +44,7 @@ Das Konzept des Widgets, welches bereits öfters bisher erwähnt worden ist, wir
 
 \subsection{Widgets}
 \label{sec:widgets}
-Eines der wichtigsten Bestandteile des Flutter-Frameworks sind die sogenannten Widgets. Der Satz \textcquote[Kap.1.9]{flutterinaction}{Everything is a widget} wird in der Literatur oft verwendet, und bringt zum Ausdruck, dass Flutter das Konzept des Widgets für viele Anwendungsfälle nutzt. So kann ein Widget diverser Aufgaben übernehmen wie beispielsweise das Rendern einer UI-Komponente, Animationen oder das Anordnen von anderen Widgets. Zur Darstellung der Benutzeroberfläche benutzen also Widgets Kompositionen von diversen Widgets. So lassen sich beispielsweise mit einer \texttt{Row}, wie im \autoref{lst:dartExample} zu sehen ist, mehrere Widgets nebeneinander anzeigen.
+Eines der wichtigsten Bestandteile des Flutter-Frameworks sind die sogenannten Widgets. Der Satz \textcquote[Kap.1.9]{flutterinaction}{Everything is a widget} wird in der Literatur oft verwendet, und bringt zum Ausdruck, dass Flutter das Konzept des Widgets für viele Anwendungsfälle nutzt. So kann ein Widget diverse Aufgaben übernehmen wie beispielsweise das Rendern einer UI-Komponente, Animationen oder das Anordnen von anderen Widgets. Zur Darstellung der Benutzeroberfläche benutzen also Widgets Kompositionen von diversen Widgets. So lassen sich beispielsweise mit einer \texttt{Row}, wie im \autoref{lst:dartExample} zu sehen ist, mehrere Widgets nebeneinander anzeigen.
 
 \begin{lstlisting}[caption={Vereinfachte Darstellung eines Widgets als Methode \cite{flutterinaction}}, label={lst:widgetFunction}]
 UI Widget(state)
@@ -54,9 +54,9 @@ Ein wichtiger Unterschied zu klassischen deklarativen UI-Frameworks ist, dass Wi
 
 In Flutter wird bei Widgets grundsätzlich zwischen \texttt{StatelessWidget} und \texttt{StatefulWidget} unterschieden.
 
-Ein \texttt{StatelessWidget} hat grundsätzlich keinen veränderbaren Zustand. Dies heißt, dass alle Klassenvariablen unveränderlich sein sollen. In Dart wird dies mit dem Modifikator \texttt{final} gekennzeichnet. Daraus wird impliziert, dass alle Informationen zum Zustand des Widgets aus den im Konstruktor übergebenen werten stammen müssen. Somit wird das Widget nur neu gebaut, wenn sich Änderungen an den Werten des Konstruktors durch Änderungen in der Hierarchie darüber liegenden Widgets ergeben. 
+Ein \texttt{StatelessWidget} hat grundsätzlich keinen veränderbaren Zustand. Dies heißt, dass alle Klassenvariablen unveränderlich sein sollen. In Dart wird dies mit dem Modifikator \texttt{final} gekennzeichnet. Daraus wird impliziert, dass alle Informationen zum Zustand des Widgets aus den im Konstruktor übergebenen Werten stammen müssen. Somit wird das Widget nur neu gebaut, wenn sich Änderungen an den Werten des Konstruktors durch Änderungen in der Hierarchie darüber liegenden Widgets ergeben. 
 
-Ein \texttt{StatefulWidget} auf der anderen Hand besteht aus zwei Klassen. Zum einen dem \texttt{StatefulWidget} zum anderen dem \texttt{State} dieses Widgets. Diese Widgets vereinen die Möglichkeiten eines \texttt{StatelessWidget} mit der Möglichkeit, den Zustand des Widgets selbstständig zu verändern. Dies wäre beispielsweise bei einem Zähler relevant, wenn der Zähler erhöhrt werden soll. Zustandsänderungen werden dabei über die, wie in \autoref{lst:stateful} gezeigte, \texttt{setState} Methode vorgenommen, damit auch die Änderung an das Framework kommuniziert wird. Intern wird dabei das Widget als \texttt{dirty} markiert, welches dazu führt, dass die Build-Methode des States erneut aufgerufen wird durch das Framework. Entscheidend ist dabei, dass der State persistent bleibt, auch wenn sich beispielsweise Konstruktor-Parameter der \texttt{StatefulWidget}-Klasse ändern.
+Ein \texttt{StatefulWidget} auf der anderen Hand besteht aus zwei Klassen. Zum einen dem \texttt{StatefulWidget} zum anderen dem \texttt{State} dieses Widgets. Diese Widgets vereinen die Möglichkeiten eines \texttt{StatelessWidget} mit der Möglichkeit, den Zustand des Widgets selbstständig zu verändern. Dies wäre beispielsweise bei einem Zähler relevant, wenn der Zähler erhöht werden soll. Zustandsänderungen werden dabei über die, wie in \autoref{lst:stateful} gezeigte, \texttt{setState} Methode vorgenommen, damit auch die Änderung an das Framework kommuniziert wird. Intern wird dabei das Widget als \texttt{dirty} markiert, welches dazu führt, dass die Build-Methode des States erneut aufgerufen wird durch das Framework. Entscheidend ist dabei, dass der State persistent bleibt, auch wenn sich beispielsweise Konstruktor-Parameter der \texttt{StatefulWidget}-Klasse ändern.
 
 
 \begin{lstlisting}[caption={StatefulWidget}, label={lst:stateful}]