You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
\caption{Die erstellte Dialoglandkarte zur bestehenden Version der iOS App zeigt die Navigationswege innerhalb der App, sowie die genutzten UI-Elemente.}\label{fig:swiftui}
11
+
\caption{Die erstellte Dialoglandkarte zur bestehenden Version der iOS App zeigt die Navigationswege innerhalb der App, sowie die genutzten UI-Elemente.}\label{fig:mindmap}
12
12
\end{figure}
13
13
14
-
Die in \Cref{fig:swiftui} gezeigte Dialoglandkarte suggeriert bereits die verschiedenen Gruppierungen von Ansichten, welche wir später zur Erstellung von neuen Packages heranziehen konnten. Zu sehen ist beispielsweise, dass die Spiel-Ansichten, der Einführungsassistent, oder bspw. auch die Kalender-Ansicht bereits gut voneinander separierbar sind. Die aufgezeichneten Navigationspfeile zwischen den Ansichten konnten genutzt werden, um die Datenflüsse hierbei vor der Erstellung des Konzeptes besser zu verstehen und die jeweils hierfür am Besten geeigneten Patterns zu finden.
14
+
Die in \Cref{fig:mindmap} gezeigte Dialoglandkarte suggeriert bereits die verschiedenen Gruppierungen von Ansichten, welche wir später zur Erstellung von neuen Packages heranziehen konnten. Zu sehen ist beispielsweise, dass die Spiel-Ansichten, der Einführungsassistent, oder bspw. auch die Kalender-Ansicht bereits gut voneinander separierbar sind. Die aufgezeichneten Navigationspfeile zwischen den Ansichten konnten genutzt werden, um die Datenflüsse hierbei vor der Erstellung des Konzeptes besser zu verstehen und die jeweils hierfür am Besten geeigneten Patterns zu finden.
15
15
16
16
\section{Struktur des Couchbase-Datenbank-Frameworks}
17
17
18
+
Die Persistierung der Applikationen kann über verschiedene Frameworks geschehen, iOS bietet standardmäßig bereits eine sehr rudimentäre Persitenzschnittstelle unter \texttt{UserDefaults}, auf Android analog hierzu \texttt{SharedPreferences}. Da jedoch nicht nur eine größere Anzahl an Daten persistiert werden müssen (Sponsoren, Spieldaten, Kalenderereignisse, Heatmap uvm.), sondern diese auch mit einem Server-Backend nach dem Offline-First-Prinzip synchronisiert werden sollen, kommen nur wenige fortgeschrittene Persistenz-Frameworks in Frage. Ehemals nutzten die Apps eine Realm-Datenbank, welche wegen externer Konditionen jedoch nicht mehr in Frage kam. Daher wurde ein Couchbase-Framework erstellt, inklusive eines Server-Backend-Systems, welches einen Synchronisationsservice und unter anderem auch einen Registrationsservice umfasst.
\caption{Eine Übersicht über das zu integrierende Couchbase-Framework. Über eine abstrahierende Wrapper-Programmierschnittstelle wird auf die Datenbank zugegriffen.}\label{fig:wrapper}
23
+
\end{figure}
24
+
25
+
Die Metastruktur des Frameworks ist in \Cref{fig:wrapper} gezeigt. Um die Nutzung von Couchbase zu vereinfachen, wurde das Framework in eine abstrahierende Wrapper-Programmierschnittstelle eingebunden, welche die wichtigsten CRUD-Operationen, On-Change-Listener und auch die Synchronisationskomponente (Replikator) bereitstellt.
\caption{Das Couchbase-Framework kapselt die Datenmodelle in voneinander separierte Repositories, auf denen unter anderem grundlegende CRUD-Operationen möglich sind.}\label{fig:repository}
30
+
\end{figure}
31
+
32
+
\Cref{fig:repository} illustriert, wie die Datenmodelle der Applikation geschrieben und gelesen werden können. Die Repository-Schnittstelle des jeweiligen Datenmodells bietet die dazugehörigen Funktionalitäten an.
\caption{Die Repository-Schnittstelle wird generisch durch das Datenmodell und das dazugehörige Repository erzeugt. Der Änderungsaufwand bei einer Änderung des Datenmodells ist somit sehr gering und neue Datenmodelle können ohne größeren Aufwand hinzugefügt werden.}\label{fig:generics}
37
+
\end{figure}
38
+
39
+
Wie in \Cref{fig:generics} gezeigt, werden die Repositories vom Framework generisch inferiert und anschließend in Form von standardisierte Schnittstellen bereitgestellt. Die diesen Schnittstellen zugrunde liegenden Datenbankabfragen müssen somit in der App nicht implementiert werden. Gleichzeitig kann das Datenbank-Backend bei Fortbestehen der Schnittstellen auch im Hintergrund ausgetauscht werden, ohne Änderungen in der App zu bedingen.
40
+
41
+
\section{Top-Level-Architektur und Muss-Kriterien}
42
+
43
+
Auf Grundlage der erstellten Dialoglandkarte sowie der bekannten Datenbankstruktur des Couchbase-Frameworks wurde ein Top-Level-Architektur-Modell (TLA) erstellt, um die Applikation in voneinander weitestgehend unabhängige Teilbereiche zu separieren.
\caption{Die TLA der Applikation im Überblick.}\label{fig:tla}
48
+
\end{figure}
49
+
50
+
Wie in \Cref{fig:tla} zu sehen, wurde die Applikation in 12 Komponenten unterteilt. Im folgenden werden die zu diesen Komponenten gehörenden Muss-Kriterien erläutert:
51
+
52
+
\begin{itemize}
53
+
\item\textbf{Twitter} stellt alle Feed-Funktionalitäten bereit, inklusive der Feed-Ansicht und der Möglichkeit, neue Tweets zu erstellen.
54
+
\item\textbf{Calendar} realisiert die Kalender-Ansicht des Veranstaltungsplans, inklusive der Detailansichten zu den jeweiligen Ereignissen, einer Möglichkeit, Ereignisse zu favorisieren, sowie nach bestimmten Ereigniskategorien zu filtern und zu suchen.
55
+
\item\textbf{Tutorial} stellt alle Funktionalitäten und Ansichten des Einführungsassistenten bereit, welcher die wesentlichsten Bestandteile der App kurz erläutert.
56
+
\item\textbf{Monitoring} kapselt die Crowd-Monitoring-Funktionalitäten des externen Crowd-Monitoring-Frameworks, sowie die Ansichten, die zur Erklärung und Steuerung dessen notwendig sind.
57
+
\item\textbf{Game} ist die funktionell mächtigste Komponente, da sie alle Ansichten und Funktionalitäten der Gamification beinhaltet, darunter die Spielerregistrierung, die Trophäen- und Errungenschaften-Ansichten, die Fortschrittsansicht, die Rangliste sowie die Eroberungs-Ansicht.
58
+
\item\textbf{Map} beinhaltet die Kartenansichten, darunter die Möglichkeiten der Auswahl bestimmter Etagen und Ansichtsoptionen wie die aktuellen Eroberungen oder die Anzeige des Besucheraufkommens über die Heatmap.
59
+
\item\textbf{Info} stellt wichtige informative Ansichten bereit, darunter die Danksagungen und Lizenzen, aber auch Link-Ansichten zu Datenschutzerklärung und Impressum.
60
+
\item\textbf{Home} dient als Verbinder zwischen verschiedenen Ansichten durch die Bereitstellung einer Home-Ansicht, auf der verschiedene Teilansichten und Links anderer Komponenten gezeigt werden.
61
+
\item\textbf{Scanner} realisiert die QR-Code-Scanner-Funktionalitäten, die benötigt werden, um Errungenschaften für das OUTPUT-Spiel freizuschalten.
62
+
\item\textbf{Sponsors} ist verantwortlich für die Bereitstellung von Ansichten zur Anzeige von Sponsoren in der Home-Ansicht.
63
+
\item\textbf{Database} stellt die zum Couchbase-Framework ergänzend benötigten Ansichten und Schnittstellen bereit.
64
+
\item\textbf{Common} stellt Komponenten und Erweiterungen bereit, die in der gesamten Applikation benötigt werden, beispielsweise eine modulare Card-Ansicht, die sich im UI (siehe Dialoglandkarte) häufig wiederfindet.
65
+
\end{itemize}
19
66
67
+
Diese TLA soll nachfolgend im Rahmen verschiedener Konzepte verfeinert und implementiert werden.
Eine Festlegung, die bereits vor der Reimplementation der Apps getroffen wurde, ist die Wahl von Swift als Hauptprogrammiersprache der zu erstellenden iOS App. Die Programmiersprache wurde 2014 von Apple veröffentlicht und ersetzt seitdem Objective-C als die von Apple empfohlene Objektorientierte Sprache zur Erstellung von Applikationen für das Apple-Ökosystem mit den Betriebssystemderivaten Mac OS, iOS und bspw. auch Watch OS (Apple Watch). In der aktuellen Version 5 setzt Swift vielseitig etablierte Konzepte aus modernen Programmiersprachen um und ist hierbei nach dem subjektiven Empfinden des Projektteams leicht verständlich, schnell zu erlernen, sowie sehr kompakt. Zusammen mit Swift 5 wurde SwiftUI als deklaratives UI-Framework 2019 veröffentlicht, ergänzend zum herkömmlichen Constraint-basierten Layouting über UIView(Controller) und XIB/Storyboard-Dateien. SwiftUI orientiert sich an Frameworks wie React, bei denen Ansichten im Code definiert werden können, wodurch die Erstellung und Modifikation von Ansichten direkt im Editor geschehen kann, ohne die Notwendigkeit von etwaiger Controller-Logik, die UI-Elemente mit Code-Elementen (z.B. über die Annotation @IBAction) verbindet. Dies vereinfacht den Implementationsprozess, bringt jedoch auch verschiedene neue Architektur- und Datenflusskonzepte mit sich, die zunächst verstanden werden müssen, um SwiftUI effektiv und zielorientiert nutzen zu können.
7
+
Eine Festlegung, die bereits vor der Reimplementation der Apps getroffen wurde, ist die Wahl von Swift als Hauptprogrammiersprache der zu erstellenden iOS App. Die Programmiersprache wurde 2014 von Apple veröffentlicht und ersetzt seitdem Objective-C als die von Apple empfohlene Objektorientierte Sprache zur Erstellung von Applikationen für das Apple-Ökosystem mit den Betriebssystemderivaten Mac OS, iOS und bspw. auch Watch OS (Apple Watch). In der aktuellen Version 5 setzt Swift vielseitig etablierte Konzepte aus modernen Programmiersprachen um und ist hierbei nach dem subjektiven Empfinden des Projektteams leicht verständlich, schnell zu erlernen, sowie sehr kompakt. Zusammen mit Swift 5 wurde SwiftUI als deklaratives UI-Framework 2019 veröffentlicht, ergänzend zum herkömmlichen Constraint-basierten Layouting über UIView(Controller) und XIB/Storyboard-Dateien. SwiftUI orientiert sich an Frameworks wie React, bei denen Ansichten im Code definiert werden können, wodurch die Erstellung und Modifikation von Ansichten direkt im Editor geschehen kann, ohne die Notwendigkeit von etwaiger Controller-Logik, die UI-Elemente mit Code-Elementen (z.B. über die Annotation \texttt{@IBAction}) verbindet. Dies vereinfacht den Implementationsprozess, bringt jedoch auch verschiedene neue Architektur- und Datenflusskonzepte mit sich, die zunächst verstanden werden müssen, um SwiftUI effektiv und zielorientiert nutzen zu können.
8
8
9
9
\section{Datenfluss- und Architekturpatterns in SwiftUI}
0 commit comments