Final changes

chapters/basics/state-management.tex

@@ -1,21 +1,16 @@
-\pagebreak
 \section{Zustandsverwaltung}
 
 Nachdem nun die Grundlagen des Flutter-Frameworks und die Details der Zustandsverwaltung der Widgets im letzten Kapitel erläutert wurden, kann jetzt die Zustandsverwaltung im Detail betrachtet werden.
 
 \citeauthor{flutterinaction} fasst den Komplex der Zustandsverwaltung in Flutter in seinem Standardwerk \textit{\citetitle{flutterinaction}} wie folgt zusammen:
 
-\begin{displayquote}[{\cite[Kap.8.1.2]{flutterinaction}}]
-    State management is a combination of passing data around the app, but also re-rendering pieces of your app at the right time. All the re-rendering in Flutter is dependent on the State object and its lifecycle. 
-\end{displayquote}
+\foreignblockcquote{american}[Kap.8.1.2]{flutterinaction}{State management is a combination of passing data around the app, but also re-rendering pieces of your app at the right time. All the re-rendering in Flutter is dependent on the State object and its lifecycle.}
 
 Daraus ergibt sich, dass die State-Klasse in der Zustandsverwaltung von Flutter eine wichtige Rolle spielt, und alle Ansätze dieses Konzept benutzen müssen, um in das Flutter-Framework integrierbar zu sein. \citeauthor{flutterinaction} beschreibt dabei die Aufgabe der Zustandsverwaltung eher auf einer Ebene des Datenflusses und des Ablaufs der Neu-Erstellung der Benutzeroberfläche.
 
 \citeauthor{managingstateinflutter} sieht die Zustandsverwaltung dabei eher auf einer eher ablaufszentrierten Sichtweise indem er die Aufgabe der Zustandsverwaltung wie folgt analysiert:
 
-\begin{displayquote}[{\cite[Kap.1]{managingstateinflutter}}]
-    State management is simply a technique, or multiple techniques, used to take care of the changes that occur in your application. 
-\end{displayquote}
+\foreignblockcquote{american}[Kap.1]{managingstateinflutter}{State management is simply a technique, or multiple techniques, used to take care of the changes that occur in your application.}
 
 Als Beispiele nennt er dabei, das Reagieren auf Interaktionen mit der Anwendung oder die Beibehaltung des Datenflusses über mehrere Screens hinweg.
 
@@ -179,7 +174,7 @@ class UserStore extends StateNotifier<User> {
 \end{lstlisting}
 
 
-Für die Zustandsklassen selber gibt Riverpod eine eigene Struktur vor. Die Zustandsklassen erben die generische Klasse \texttt{StateNotifier}. Dabei wird über das Generic festgelegt, welchen Datentyp der Zustand haben soll. Dieser Zustand wird dann der Klasse als vererbte Variable zur Verfügung gestellt. Bei Änderung des Zustands reicht es somit aus, den Inhalt dieser Variable neu zu setzen wie in \autoref{lst:StateNotifier} gezeigt wird. Die Benutzeroberfläche greift dabei ausschließlich auf die Zustands-Variable direkt zu. Die Zustandsklasse ist nur dafür zuständig, Methoden zur Änderung dieses Zustands zur Verfügung zu stellen.
+Für die Zustandsklassen selber gibt Riverpod eine eigene Struktur vor. Die Zustandsklassen erben die generische Klasse \texttt{StateNotifier}. Dabei wird über das Generic festgelegt, welchen Datentyp der Zustand haben soll. Dieser Zustand wird dann der Klasse als vererbte Variable zur Verfügung gestellt. Bei Änderung des Zustands reicht es somit aus, den Inhalt dieser Variable neu zu setzen wie in \autoref{lst:StateNotifier} gezeigt wird. Die Benutzeroberfläche greift dabei ausschließlich auf die Zustands-Variable direkt zu.\\ Die Zustandsklasse ist nur dafür zuständig, Methoden zur Änderung dieses Zustands zur Verfügung zu stellen.
 
 Riverpod akzeptiert neben diesen Zustandsklassen auch die im Provider-Kapitel (siehe \autoref{sec:provider}) vorgestellen Event-Emitter wie beispielsweise \texttt{ChangeNotifier}.
 
@@ -204,6 +199,7 @@ Bei \texttt{flutter\_riverpod} werden die bereits eingeführten Widget-Typen \te
 \label{sec:redux}
 Redux ist ein Zustandsverwaltungssystem, welches ursprünglich für React entwickelt worden ist. React ist eine JavaScript-Bibliothek zum Bauen von Benutzeroberflächen. Da React und Flutter ähnliche Techniken wie Widgets oder das State-Prinzip verwenden, lässt sich dieser Ansatz auf Flutter und Dart übertragen.
 
+\pagebreak
 Redux basiert auf drei grundlegenden Prinzipien:
 
 \blockcquote[Kap.1.3.2]{redux}{Single source of truth [...]

chapters/evaluation/bloc.tex

@@ -54,6 +54,7 @@ Ein weiterer betrachteter Aspekt beim Testen ist die Testbarkeit von Widgets, di
 
 Aufgrund der einfachen Testbarkeit der Geschäftslogik sowie des möglichen Austausches mit Platzhaltern für Widget-Tests wird die Testbarkeit mit \textquote{vollständig erfüllt} bewertet.
 
+\pagebreak
 \paragraph{\nameref*{sec:efficiency}} Nach der Ausführung der Teststrecke ergaben die Zähler folgendes Ergebnis: 
 \lstinputlisting[caption={Anzahl der Rendervorgänge bei BLoC}]{results/bloc/benchmarks.txt}
 

chapters/evaluation/inheritedwidget.tex

@@ -47,7 +47,7 @@ testWidgets('test cart store', (tester) async {
 Die Tests für Widgets, die den Zustand konsumieren auf der anderen Hand sind einfach umzusetzen, da die Geschäftslogik im besten Fall komplett von der Speicherung der emittierten Daten getrennt wird. So ist es möglich ein \texttt{Inherited\-Widget} ohne das dazugehörige \texttt{Stateful\-Widget} zu initialiseren und die benötigten Mock-Daten über den Konstruktor zu übergeben.
 
 Abschließend erfolgt hier die Bewertung mit \textquote{teilweise erfüllt}.
-
+\pagebreak
 \paragraph{\nameref*{sec:efficiency}} Nach der Ausführung der Teststrecke ergaben die Zähler folgendes Ergebnis: 
 \lstinputlisting[caption={Anzahl der Rendervorgänge bei InheritedWidget}]{results/inheritedwidget/benchmarks.txt}
 
@@ -65,9 +65,7 @@ Der letzte Faktor befasst sich mit der tiefen Verschachtlung von Widgets (engl.
 return UserStoreImplementation(
     child: ProductStoreImplementation(
       productService: productService,
-      child: CartStoreImplementation(
-        child: child,
-      ),
+      child: CartStoreImplementation(child: child),
     ),
 );
 \end{lstlisting}

chapters/intro/targets.tex

@@ -2,4 +2,4 @@
 
 Das übergeordnete Ziel dieser Ausarbeitung ist es, den für die Entwicklung von Flutter-Anwendungen oder bestimmten Anwendungsfällen am besten geeignete Ansatz für die Zustandsverwaltung zu finden. Im Detail soll dabei gezeigt werden, welche Lösungsansätze für welchen Anwendungsfall am besten, begründet geeignet sind.
 
-Zur Erreichung dieses übergeordneten Zieles ist es erforderlich, einige Zwischenziele zu definieren. Das Erste Ziele ist dabei, zu analysieren, welche Anforderungen aktuell an die Zustandsverwaltung in Flutter gestellt werden, um im nächsten Schritt geeignete Kriterien für die Bewertung von Lösungsansätzen zu finden. Dabei ist es auch ein Ziel, diese Bewertungsansätze möglichst objektiv definieren zu können, da die Auswahl von geeigneten Kriterien entscheidend ist für die Aussagekraft der Evaluation.
+Zur Erreichung dieses übergeordneten Zieles ist es erforderlich, einige Zwischenziele zu definieren. Das Erste Ziele ist dabei, zu analysieren, welche Anforderungen aktuell an die Zustandsverwaltung in Flutter gestellt werden, um im nächsten Schritt geeignete Kriterien für die Bewertung von Lösungsansätzen zu finden.\\ Dabei ist es auch ein Ziel, diese Bewertungsansätze möglichst objektiv definieren zu können, da die Auswahl von geeigneten Kriterien entscheidend ist für die Aussagekraft der Evaluation.