Final formatting changes
Reduce toc depth from two to one Remove abstract
This commit is contained in:
parent
ee874ac51e
commit
4188c15b4b
@ -156,7 +156,7 @@
|
||||
%\missingfigure[figwidth=6cm]{Testing a long text string}
|
||||
|
||||
%Tiefe des Inhaltsverzeichnisses
|
||||
\setcounter{tocdepth}{2}
|
||||
\setcounter{tocdepth}{1}
|
||||
|
||||
% Metadaten
|
||||
\author{Simon Kellner, Marcel Schwarz, Tobias Wieck, Tim Zieger}
|
||||
@ -166,27 +166,6 @@
|
||||
|
||||
\include{parts/titlepage}
|
||||
|
||||
\begin{abstract}
|
||||
{\huge Checkliste Lieferobjekte}
|
||||
|
||||
\begin{itemize}
|
||||
\item Ein Journal (z.B. Excel in Dropbox, Office 365, Google), in dem jedes Projektmitglied Tages- und Themenspezifisch seine geleisteten Arbeiten mit Aufwandsangabe listet. Z.b. "Hans 12.4 3 Std Backend Coding"- Das Journal muss zeitnah geführt werden und verfügbar sein. Ein unvollständiges Zeitjournal führt zur Abwertung in der Benotung.
|
||||
\item Projektdokumentation (*: ca. 15-25 Seiten, je nach Bilderdichte)
|
||||
\begin{itemize}
|
||||
\item Source Code und alle erstellten Dokumente
|
||||
\item Erläuterung des Designs (*)
|
||||
\item Einrichtung der Entwicklungsumgebung (*) \\
|
||||
(falls anwendbar, Standarddinge wie Eclipse, Android SDK müssen nicht detailliert erwähnt werden):
|
||||
\begin{itemize}
|
||||
\item Welche Frameworks wurden für die Entwicklung benutzt und was gab es bei der Konfiguration / Installation dieser Tools zu beachten?
|
||||
\item Wie wurden die Zielanwendungen erzeugt und z.B. auf ein Zielgerät oder Server übertragen und dort aktiviert?
|
||||
\end{itemize}
|
||||
\item Projektbericht: Wie sind Sie vorgegangen, was wollten Sie erreichen, was haben Sie gelernt, was gab es für Probleme, was haben Sie erreicht, wer hat was gemacht?
|
||||
\end{itemize}
|
||||
\item Datei mit der Präsentation
|
||||
\end{itemize}
|
||||
\end{abstract}
|
||||
|
||||
\tableofcontents
|
||||
|
||||
\listoffigures
|
||||
@ -208,12 +187,12 @@
|
||||
\chapter{Vollständiger Application Stack}
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{img/ApplicationStack}
|
||||
\includegraphics[width=0.9\linewidth]{img/ApplicationStack}
|
||||
\caption{Application Stack}
|
||||
\end{figure}
|
||||
Das Deployment von Geotime ist in drei große Schichten aufgeteilt. Zunächst wäre hier die Backend Schicht, die Schicht der Datenhaltung und der API. Dieser Teil der Anwendung braucht am meisten Schutz, da er der wichtigste ist und dort alle Daten gespeichert werden. Der Zugriff auf die Datenbank ist nur auf das Backend beschränkt. Um nun die Applikation zu Nutzen gibt es zwei Möglichkeiten: Eine Android App oder ein Webbrowser.
|
||||
Das Deployment von Geotime ist in drei große Schichten aufgeteilt. Zunächst wäre hier die Backend Schicht, die Schicht der Datenhaltung und der API. Dieser Teil der Anwendung braucht am meisten Schutz, da er der wichtigste ist und dort alle Daten gespeichert werden. Der Zugriff auf die Datenbank ist nur auf das Backend beschränkt. Um nun die Applikation zu Nutzen gibt es zwei Möglichkeiten: Eine Android App oder ein Webbrowser.\\
|
||||
|
||||
Die Android App implementiert die View Schicht selbst und fragt nur für Daten den Backend-Dienst an. Diese Anfragen gehen zunächst an den Server, der die App hostet und werden dann von dem darauf laufenden Docker Deamon an den entsprechenden Container weitergeleitet.
|
||||
Die Android App implementiert die View Schicht selbst und fragt nur für Daten den Backend-Dienst an. Diese Anfragen gehen zunächst an den Server, der die App hostet und werden dann von dem darauf laufenden Docker Deamon an den entsprechenden Container weitergeleitet.\\
|
||||
|
||||
Beim Zugriff über den Webbrowser funktioniert die Kommunikation geringfügig anders. Zunächst wird vom Client der nginx Container nach dem statischen Teil der Website gefragt, dieser lädt dann über ähnliche Anfragen wie in der Android App die Daten vom Backend. Das global gesprochene Protokoll ist hierbei immer HTTP.
|
||||
|
||||
@ -221,8 +200,7 @@ Beim Zugriff über den Webbrowser funktioniert die Kommunikation geringfügig an
|
||||
|
||||
\chapter{Projektfazit und Ausblick}
|
||||
Bei dem Projekt im Rahmen von Ubiquitous/Pervasive Computing konnten wir Bekanntes anwenden und Neues lernen. Wir alle konnten uns gut einbringen und zusammen auf unser gemeinsames Ziel hinarbeiten. Im Rückblick auf die vergangenen 5 Sprints lässt sich sagen, dass diese erfolgreich verlaufen sind. Die Verteilung der Aufgaben war gleichmäßig und funktionierte reibungslos. Die Idee des Projekts konnte vollständig umgesetzt werden, zudem konnten Anfangs nicht geplante Features umgesetzt werden. Hierzu zählen z.B.: Tagesübergreifende Time Records. Wir alle sind mit dem Ergebnis unserer Arbeit zufrieden und können das Projekt als erfolgreich bezeichnen.\\
|
||||
\\
|
||||
|
||||
Ebenso sehen wir ein großes Potential in der Weiterentwicklung unseres Endprodukts. Hier haben wir Ideen wie: Zuordnung der Benutzer in Gruppen, Benutzerprofile mit Daten über den Benutzer und dessen Tätigkeit oder auch Zuweisung von Kernarbeitszeit und Zeitrahmen um TimeTracking nur in einem festgelegten Zeitfenster zu erlauben. Mit ein paar Verbesserungen könnte unser Produkt von kleinen Unternehmen verwendet werden, die ein auf Vertrauen basiertes Zeitmeldesystem suchen.
|
||||
|
||||
|
||||
\end{document}
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
\chapter{Android-App}
|
||||
\section{Technologiebeschreibung}
|
||||
\subsection{Android SDK}
|
||||
Die Android-Entwicklung wurde, aufgrund der Ausgereiftheit und den Emulatoren, mit Android-Studio realisiert. Android-Studio verwaltet auch das SDK und unterstützt beim aktuell halten der Bibliotheken.
|
||||
Die Android-Entwicklung wurde, aufgrund der Ausgereiftheit und den Emulatoren, mit Android-Studio realisiert. Android-Studio verwaltet auch das SDK und unterstützt beim aktuell halten der Bibliotheken.\\
|
||||
|
||||
Das minimale API-Level, welches das Endgerät haben darf, wurde auf 23 "Marshmallow" festgelegt. Dadurch werden ca. 85\% der Geräte unterstützt und ist aktuell genug um gewisse Features, wie das neue Berechtigungssystem, zu unterstützen. Die Zielversion ist das aktuelle Android 10 mit API-Level 29. In dieser Version wurden erneut Berechtigungen geändert, wodurch im Code einige Anpassungen gemacht werden mussten (siehe: \ref{sec:Probleme})
|
||||
|
||||
@ -23,7 +23,7 @@
|
||||
|
||||
\section{Umsetzung}
|
||||
\subsection{Design der Activities}
|
||||
Insgesamt besitzt die App die vier Activities: Login, MainActivity, Register und Settings. Wobei die Register- und die Settings-Activity aus zeitlichen Gründen ohne Funktion sind. Sie haben auch noch die alten unschönen Eingabefelder, sind aber für die Funktion der gesamten Anwendung nicht sonderlich relevant, weshalb entschieden wurde, diese zu vernachlässigen und den Fokus auf die Funktionalität zu legen.
|
||||
Insgesamt besitzt die App die vier Activities: Login, MainActivity, Register und Settings. Wobei die Register- und die Settings-Activity aus zeitlichen Gründen ohne Funktion sind. Sie haben auch noch die alten unschönen Eingabefelder, sind aber für die Funktion der gesamten Anwendung nicht sonderlich relevant, weshalb entschieden wurde, diese zu vernachlässigen und den Fokus auf die Funktionalität zu legen.\\
|
||||
|
||||
Jeder Bildschirm hat eine Top-Bar auf der, je nachdem auf welchem Bildschirm man sich befindet, unterschiedliche Inhalte angezeigt werden. Beim Einloggen und Account erstellen wird außer dem Logo und dem Namen der App nichts angezeigt. In den Einstellungen erscheint anstatt des Logos ein Zurück-Button und auf dem Hauptbildschirm gibt es ein Menü zum Ausloggen und um zu den Einstellungen zu gelangen.
|
||||
\begin{figure}[H]
|
||||
@ -54,12 +54,12 @@
|
||||
\label{Abb:settings}
|
||||
\end{minipage}
|
||||
\end{figure}
|
||||
Wie zu erkennen ist lag, der Fokus der Implementierung deutlich auf der Main Activtiy, da sie auch das Wichtigste der App beinhaltet. Prominent ist dabei der 'START'-Knopf an der Unterseite, mit dem die Aufzeichnung gestartet werden kann (genaueres im Kapitel \ref{subsec:main}).
|
||||
Wie zu erkennen ist lag, der Fokus der Implementierung deutlich auf der Main Activtiy, da sie auch das Wichtigste der App beinhaltet. Prominent ist dabei der "START"-Knopf an der Unterseite, mit dem die Aufzeichnung gestartet werden kann (genaueres im Kapitel \ref{subsec:main}).
|
||||
|
||||
\subsection{Authentifizierung}
|
||||
Zur Authentifizierung benutzen wir JWT, welches bei jeder Anfrage ans Backend mit geschickt werden muss. Das Token erhält man beim Einloggen mit den richtigen Daten und muss persistiert werden, bis sich der Benutzer ausloggt. Dazu wird das Token im privaten Speicher der App gespeichert. In allen weiteren Activities kann dann auf den Speicher zugegriffen werden und das Token beim Erstellen des \verb|AuthenticationInterceptor|s mitgegeben werden. Beim Ausloggen wird einfach die Datei mit dem Token aus dem Speicher gelöscht.
|
||||
Zur Authentifizierung benutzen wir JWT, welches bei jeder Anfrage ans Backend mit geschickt werden muss. Das Token erhält man beim Einloggen mit den richtigen Daten und muss persistiert werden, bis sich der Benutzer ausloggt. Dazu wird das Token im privaten Speicher der App gespeichert. In allen weiteren Activities kann dann auf den Speicher zugegriffen werden und das Token beim Erstellen des "AuthenticationInterceptor"s mitgegeben werden. Beim Ausloggen wird einfach die Datei mit dem Token aus dem Speicher gelöscht.
|
||||
|
||||
Der \verb|AuthenticationInterceptor| ist Kind von der \verb|Interceptor|-Klasse aus der \verb|okhttp3|-Bibliothek, welche in Retrofit eingebunden ist. Mithilfe des Interceptors können REST-Aufrufen Header-Daten mitgegeben werden. In unserem Fall ist das das \verb|Authorization|-Feld mit dem Token.
|
||||
Der "AuthenticationInterceptor" ist Kind von der "Interceptor"-Klasse aus der "okhttp3"-Bibliothek, welche in Retrofit eingebunden ist. Mithilfe des Interceptors können REST-Aufrufen Header-Daten mitgegeben werden. In unserem Fall ist das das "Authorization"-Feld mit dem Token.
|
||||
\begin{lstlisting}[language=Kotlin,caption=AuthenticationInterceptor]
|
||||
class AuthenticationInterceptor(pToken: String) : Interceptor {
|
||||
private val token = pToken
|
||||
@ -89,7 +89,7 @@ val builder = Retrofit.Builder()
|
||||
val retrofit = builder.build()
|
||||
service = retrofit.create(GeofenceService::class.java)
|
||||
\end{lstlisting}
|
||||
Die Klasse \verb|GeofenceService| dient, wie oben beschrieben, zur Definition der Endpunkte in Form von Methodenaufrufen. Dort wird definiert, ob es ein \verb|POST|- oder \verb|GET|-Entpunkt ist, wie der Pfad lautet und was für Parameter mitgegeben werden.
|
||||
Die Klasse "GeofenceService" dient, wie oben beschrieben, zur Definition der Endpunkte in Form von Methodenaufrufen. Dort wird definiert, ob es ein "POST"- oder "GET"-Entpunkt ist, wie der Pfad lautet und was für Parameter mitgegeben werden.
|
||||
\begin{lstlisting}[language=Kotlin,caption=GeofenceService]
|
||||
@POST("/login")
|
||||
fun login(@Body login_data: ValuesUserLogin): Call<Void>
|
||||
@ -100,14 +100,14 @@ fun getUser(): Call<ValuesUser>
|
||||
@GET("accounts/search/findByUsername")
|
||||
fun getAccounts(@Query("username") username : String): Call<EmbeddedAccounts>
|
||||
\end{lstlisting}
|
||||
Der Rückgabewert der Methoden ist immer vom Typ \verb|Call|. Wenn aus dem Body Werte gelesen werden sollen, muss eine Art Skelett-Klasse angelegt werden mit den relevanten Feldern. Die Klasse \verb|ValuesUser| stellt Werte der Antwort bereit, wie z. B. den Vornamen.
|
||||
Der Rückgabewert der Methoden ist immer vom Typ "Call". Wenn aus dem Body Werte gelesen werden sollen, muss eine Art Skelett-Klasse angelegt werden mit den relevanten Feldern. Die Klasse "ValuesUser" stellt Werte der Antwort bereit, wie z. B. den Vornamen.
|
||||
\begin{lstlisting}[language=Kotlin,caption=ValuesUser]
|
||||
class ValuesUser(firstname: String) {
|
||||
@SerializedName("firstname")
|
||||
var firstname = firstname
|
||||
}
|
||||
\end{lstlisting}
|
||||
Der Aufruf der Methode erfolgt asynchron. Deshalb darf sich nicht auf das Ergebnis des Aufrufs direkt danach verlassen werden, sonst bekommt man eine Null-Pointer-Excetion. Die Methode \verb|enqueue| besitzt ein Callback-Objekt als Parameter, welches \verb|onResponse| und \verb|onFailure| überschreibt. Dort wird entsprechend definiert, was in den jeweiligen Fällen ausgeführt werden soll.
|
||||
Der Aufruf der Methode erfolgt asynchron. Deshalb darf sich nicht auf das Ergebnis des Aufrufs direkt danach verlassen werden, sonst bekommt man eine Null-Pointer-Excetion. Die Methode "enqueue" besitzt ein Callback-Objekt als Parameter, welches "onResponse" und "onFailure" überschreibt. Dort wird entsprechend definiert, was in den jeweiligen Fällen ausgeführt werden soll.
|
||||
\begin{lstlisting}[language=Kotlin,caption=Callback der "getUser" Funktion]
|
||||
val call = service.getUser()
|
||||
call.enqueue(object : Callback<ValuesUser> {
|
||||
@ -136,11 +136,11 @@ call.enqueue(object : Callback<ValuesUser> {
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Geofencing}\label{subsec:geofence}
|
||||
Die Geofencing-Funktion ist die zentrale Funktion für die App und auch für das gesamte Projekt. Deshalb war es wichtig, dass sie frühzeitig funktioniert.
|
||||
Die Geofencing-Funktion ist die zentrale Funktion für die App und auch für das gesamte Projekt. Deshalb war es wichtig, dass sie frühzeitig funktioniert.\\
|
||||
|
||||
Um die Position eines Gerätes zu bestimmen, bedarf es einer Berechtigung, die vom Benutzer bestätigt werden muss. Für Geräte mit API-Level 28 und niedriger muss dafür die \verb|ACCESS_FINE_LOCATION|-Berechtigung gesetzt werden und für API-Level 29 und höher \verb|ACCESS_BACKGROUND_LOCATION|.
|
||||
Um die Position eines Gerätes zu bestimmen, bedarf es einer Berechtigung, die vom Benutzer bestätigt werden muss. Für Geräte mit API-Level 28 und niedriger muss dafür die \linebreak "ACCESS\_FINE\_LOCATION"-Berechtigung gesetzt werden und für API-Level 29 und höher "ACCESS\_BACKGROUND\_LOCATION".\\
|
||||
|
||||
Der Geofence wird initialisiert, wenn für den Benutzer Geo-Daten gespeichert sind. Ist dies der Fall, so wird ein \verb|GeofencingClient| angelegt, dem dann der Geofence hinzugefügt wird. Der Geofence wird erzeugt mit den Parametern: Breitengrad, Längengrad, Radius, der Lebenszeit des Fence und den Übergangstypen. Die Typen sind in unserem Fall \verb|GEOFENCE_TRANSITION_ENTER| und \verb|GEOFENCE_TRANSITION_EXIT|, da wir immer reagieren wollen, wenn der Nutzer den Bereich verlässt oder betritt.
|
||||
Der Geofence wird initialisiert, wenn für den Benutzer Geo-Daten gespeichert sind. Ist dies der Fall, so wird ein "GeofencingClient" angelegt, dem dann der Geofence hinzugefügt wird. Der Geofence wird erzeugt mit den Parametern: Breitengrad, Längengrad, Radius, der Lebenszeit des Fence und den Übergangstypen. Die Typen sind in unserem Fall "GEOFENCE\_TRANSITION\_ENTER" und "GEOFENCE\_TRANSITION\_EXIT", da wir immer reagieren wollen, wenn der Nutzer den Bereich verlässt oder betritt.
|
||||
\begin{lstlisting}[language=Kotlin,caption=Anlegen des Geofencing Clients]
|
||||
geofencingClient = LocationServices.getGeofencingClient(this)
|
||||
geofence = Geofence.Builder().setRequestId("Geofence")
|
||||
@ -149,14 +149,14 @@ geofence = Geofence.Builder().setRequestId("Geofence")
|
||||
.setTransitionTypes(Geofence.GEOFENCE_TRANSITION_ENTER or Geofence.GEOFENCE_TRANSITION_EXIT)
|
||||
.build()
|
||||
\end{lstlisting}
|
||||
Um den Geofence-Client zu starten wird auf das Objekt die \verb|addGeofences|-Methode ausgeführt mit einem \verb|GeofencingRequest|-Objekt und einem \verb|PendingIntent|-Objekt als Parameter.
|
||||
Um den Geofence-Client zu starten wird auf das Objekt die "addGeofences"-Methode ausgeführt mit einem "GeofencingRequest"-Objekt und einem "PendingIntent"-Objekt als Parameter.
|
||||
\begin{lstlisting}[language=Kotlin,caption="addGeofences" Methode]
|
||||
geofencingClient.addGeofences(getGeofencingRequest(), geofencePendingIntent)?.run {
|
||||
addOnSuccessListener { ... }
|
||||
addOnFailureListener { ... }
|
||||
}
|
||||
\end{lstlisting}
|
||||
In der \verb|getGeofencingRequest|-Methode wird festgelegt, auf welches initiale Event reagiert werden soll und der oben erstellte Geofence wird hinzugefügt. Als initiales Event haben wir \verb|INITIAL_TRIGGER_ENTER| gewählt, da es ausgelöst wird, wenn man sich bereits im Bereich befindet und die App startet. Denn erst mit dem Eintrittsevent wird der Button zum Starten der Aufzeichnung freigeschaltet. Das \verb|geofencePendingIntent| definiert die BroadcastReceiver-Klasse, welche bei jedem Event aufgerufen wird.
|
||||
In der "getGeofencingRequest"-Methode wird festgelegt, auf welches initiale Event reagiert werden soll und der oben erstellte Geofence wird hinzugefügt. Als initiales Event haben wir "INITIAL\_TRIGGER\_ENTER" gewählt, da es ausgelöst wird, wenn man sich bereits im Bereich befindet und die App startet. Denn erst mit dem Eintrittsevent wird der Button zum Starten der Aufzeichnung freigeschaltet. Das "geofencePendingIntent" definiert die BroadcastReceiver-Klasse, welche bei jedem Event aufgerufen wird.
|
||||
\begin{lstlisting}[language=Kotlin,caption=Setzen der Geofence Trigger]
|
||||
private fun getGeofencingRequest(): GeofencingRequest {
|
||||
return GeofencingRequest.Builder().apply {
|
||||
@ -169,21 +169,21 @@ private val geofencePendingIntent: PendingIntent by lazy {
|
||||
PendingIntent.getBroadcast(this, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT)
|
||||
}
|
||||
\end{lstlisting}
|
||||
Die \verb|GeofenceBroadcastReceiver|-Klasse definiert, was bei den jeweiligen Events ausgeführt werden soll. In unserem Fall ist dies das Verändern einer boolean Shared-Prefrences-Variable, je nachdem ob der Bereich betreten oder verlassen wurde. Warum diese Art und Weise gewählt wurde lesen Sie in Kapitel \ref{sec:Probleme}. Das Code-Beispiel zeigt die Aktion beim Betreten des Bereichs.
|
||||
Die "GeofenceBroadcastReceiver"-Klasse definiert, was bei den jeweiligen Events ausgeführt werden soll. In unserem Fall ist dies das Verändern einer boolean Shared-Prefrences-Variable, je nachdem ob der Bereich betreten oder verlassen wurde. Warum diese Art und Weise gewählt wurde lesen Sie in Kapitel \ref{sec:Probleme}. Das Code-Beispiel zeigt die Aktion beim Betreten des Bereichs.
|
||||
\begin{lstlisting}[language=Kotlin,caption=Ändern der Shared-Preferences]
|
||||
context!!.getSharedPreferences("LOCATION", Context.MODE_PRIVATE)
|
||||
?.edit()
|
||||
?.putBoolean("ENABLED", true)
|
||||
?.apply()
|
||||
\end{lstlisting}
|
||||
In der \verb|MainActivity| wird ein Listener für diese Shared-Prefrences-Variable definiert. Je nachdem, zu welchem Wert sich die Variable ändert, wird der Start/Stopp-Button freigeschaltet oder gesperrt. Wenn der Benutzer den Bereich verlässt, aber noch aufzeichnet, wird dadurch die Aufzeichnung automatisch gestoppt und gespeichert.
|
||||
In der "MainActivity" wird ein Listener für diese Shared-Prefrences-Variable definiert. Je nachdem, zu welchem Wert sich die Variable ändert, wird der Start/Stopp-Button freigeschaltet oder gesperrt. Wenn der Benutzer den Bereich verlässt, aber noch aufzeichnet, wird dadurch die Aufzeichnung automatisch gestoppt und gespeichert.
|
||||
|
||||
\section{Funktionen der App}
|
||||
Wie oben beschrieben, besteht die Android-App aus vier Activities. Die Register- und Settings-Activity sind aus zeitlichen Gründen ohne Funktion und layouttechnisch nicht überarbeitet. Der Fokus lag stark auf der Main-Activity, die das Kernstück der App darstellt. Im Folgenden die Funktionalitäten der Activities Login und Main.
|
||||
\subsection{Login Screen}
|
||||
In der Abbildung \ref{Abb:login} ist der Login Screen zu sehen. Er besteht aus der Top-Action-Bar mit Logo und App-Name, den Eingabefeldern und zwei Buttons. Alle Komponenten sind aus der Material-Design-Bibliothek.
|
||||
|
||||
Zum Einloggen werden die Daten in die jeweiligen Felder eingegeben. Wenn ein Feld markiert ist, wird das ausgewählte Feld blau umrandet und der Hinweis wird auf die obere Linie verschoben. Das Passwortfeld zeigt nur kurz den eingegebenen Buchstaben an und wird dann zu einem '*', sodass das Passwort nicht offen lesbar ist.
|
||||
Zum Einloggen werden die Daten in die jeweiligen Felder eingegeben. Wenn ein Feld markiert ist, wird das ausgewählte Feld blau umrandet und der Hinweis wird auf die obere Linie verschoben. Das Passwortfeld zeigt nur kurz den eingegebenen Buchstaben an und wird dann zu einem "*", sodass das Passwort nicht offen lesbar ist.
|
||||
|
||||
Der Login-Button sendet die Daten an das Backend und prüft, ob die Daten korrekt sind. Wenn dies der Fall ist, enthält die Antwort das Token, welches in den privaten Speicher abgelegt wird, und die App wechselt zum Hauptbildschirm. War der Login nicht erfolgreich, wird dem Benutzer eine Pop-Up-Meldung angezeigt und nichts weiter unternommen. Mit dem Betätigen des Registrieren-Knopfes wird man auf die Register-Activity weitergeleitet.
|
||||
|
||||
@ -197,18 +197,17 @@ context!!.getSharedPreferences("LOCATION", Context.MODE_PRIVATE)
|
||||
\end{figure}
|
||||
Direkt unter der Top-Action-Bar wird der Benutzer mit dem Vornamen begrüßt (Abb.: \ref{Abb:main}).
|
||||
|
||||
In der Bedienfläche kann der Benutzer den Timetrack-Account auswählen und dessen Details ansehen, seine heutigen Arbeitszeiten ansehen und die Aufzeichnung starten oder stoppen.
|
||||
In der Bedienfläche kann der Benutzer den Timetrack-Account auswählen und dessen Details ansehen, seine heutigen Arbeitszeiten ansehen und die Aufzeichnung starten oder stoppen.\\
|
||||
|
||||
Die Auswahl des Accounts erfolgt über ein Dropdown-Menü. Bei Auswahl wird sofort die zugehörige Beschreibung und die Vergütung angezeigt. Wenn die Aufzeichnung am Laufen ist, wird das Dropdown-Menü ausgeblendet. Das verhindert, dass der Benutzer eine Aktivität für einen anderen Account stoppen kann, als für den, auf dem er sie gestartet hat. Ist für den Benutzer noch kein Account vorhanden, wird "None" im Menü angezeigt und die beiden Felder für Beschreibung und Vergütung werden ausgeblendet.
|
||||
Die Auswahl des Accounts erfolgt über ein Dropdown-Menü. Bei Auswahl wird sofort die zugehörige Beschreibung und die Vergütung angezeigt. Wenn die Aufzeichnung am Laufen ist, wird das Dropdown-Menü ausgeblendet. Das verhindert, dass der Benutzer eine Aktivität für einen anderen Account stoppen kann, als für den, auf dem er sie gestartet hat. Ist für den Benutzer noch kein Account vorhanden, wird "None" im Menü angezeigt und die beiden Felder für Beschreibung und Vergütung werden ausgeblendet.\\
|
||||
|
||||
Für die Anzeige der heutigen Arbeitszeiten haben wir eine RecyclerView verwendet. Das Layout dazu wird in einer extra XML-Datei definiert und mit Daten in einer Adapter-Klasse befüllt. Durch eine Backendabfrage bekommen wir die nötigen Daten dafür. Bei aktiver Aufzeichnung wird ein Element angezeigt mit der Startzeit und der Info, dass das Ende offen ist.
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.4\linewidth]{img/android/main_recording}
|
||||
\caption{Laufende Aufzeichnung}
|
||||
\label{Abb:menu}
|
||||
\end{figure}
|
||||
Der Start-Stop-Button schaltet die Aufzeichnung um, in dem ein Backend-Endpunkt angesprochen wird. In der App haben wir eine boolean-Variable \verb|running| definiert, welche speichert, ob die Aufzeichnung aktiv ist. Anhand ihr wird entschieden, wie der Start-Stop-Button aussieht und ob beim Verlassen des Geofence noch gestoppt werden muss. Der Button ist nicht auswählbar, wenn sich der Nutzer außerhalb seines Arbeitsplatzes befindet und zeigt dies auch an (Abb.: \ref{Abb:outside}). Ist der Nutzer dann im Bereich, wird "Start" angezeigt und der Button ist freigeschaltet. Während der Aufzeichnung trägt der Button die Schrift "Stop". Hat der Nutzer noch keine Geo-Daten für seinen Arbeitsplatz definiert, wird auch das auf dem Button angezeigt.
|
||||
Der Start-Stop-Button schaltet die Aufzeichnung um, in dem ein Backend-Endpunkt angesprochen wird. In der App haben wir eine boolean-Variable "running" definiert, welche speichert, ob die Aufzeichnung aktiv ist. Anhand ihr wird entschieden, wie der Start-Stop-Button aussieht und ob beim Verlassen des Geofence noch gestoppt werden muss. Der Button ist nicht auswählbar, wenn sich der Nutzer außerhalb seines Arbeitsplatzes befindet und zeigt dies auch an (Abb.: \ref{Abb:outside}). Ist der Nutzer dann im Bereich, wird "Start" angezeigt und der Button ist freigeschaltet. Während der Aufzeichnung trägt der Button die Schrift "Stop". Hat der Nutzer noch keine Geo-Daten für seinen Arbeitsplatz definiert, wird auch das auf dem Button angezeigt.
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.4\linewidth]{img/android/btn_outside}
|
||||
@ -235,15 +234,14 @@ context!!.getSharedPreferences("LOCATION", Context.MODE_PRIVATE)
|
||||
\centering
|
||||
\includegraphics[width=0.4\linewidth]{img/android/confirm_stop}
|
||||
\caption{Bestätigungs Dialog zum stoppen}
|
||||
\label{Abb:menu}
|
||||
\end{figure}
|
||||
|
||||
\section{Probleme und Lösungen}\label{sec:Probleme}
|
||||
Damit die App auch die aktuellste Android Version unterstützt, mussten einige zusätzliche Punkte berücksichtigt werden. Neben der Berechtigung aus Kapitel \ref{subsec:geofence} mussten in der \verb|build.gradle|-Datei Kompilierungsoptionen gesetzt werden.\\
|
||||
Damit die App auch die aktuellste Android Version unterstützt, mussten einige zusätzliche Punkte berücksichtigt werden. Neben der Berechtigung aus Kapitel \ref{subsec:geofence} mussten in der "build.gradle"-Datei Kompilierungsoptionen gesetzt werden.\\
|
||||
|
||||
Zu Beginn wollten wir alle Activities mit Fragments realisieren, sodass es nur eine Activity gibt und alles weitere Fragments sind. Allerdings war es schwieriger, zwischen den Fragments zu wechseln, als in den Tutorials beschrieben. Deshalb sind wir auf reine Activities umgestiegen. Zwischen diesen ist das Hin- und Herschalten deutlich einfacher, es besteht jedoch kein Zugriff auf Elemente der anderen Activities.\\
|
||||
|
||||
Das wurde aber erst dann problematisch, als wir aus der Klasse \verb|GeofenceBroadcastReceiver| eine Methode der \verb|MainActivity| zur Änderung der Oberfläche aufrufen wollten. Das hat den Grund, dass Android nicht sicher sagen kann, dass diese Activity gerade auch aktiv ist. Deshalb haben wir den Weg über die Shared-Preferences gewählt mit einem Listener in der \verb|MainActivity|.\\
|
||||
Das wurde aber erst dann problematisch, als wir aus der Klasse "GeofenceBroadcastReceiver" eine Methode der "MainActivity" zur Änderung der Oberfläche aufrufen wollten. Das hat den Grund, dass Android nicht sicher sagen kann, dass diese Activity gerade auch aktiv ist. Deshalb haben wir den Weg über die Shared-Preferences gewählt mit einem Listener in der "MainActivity".\\
|
||||
|
||||
Initial wollten wir das Token in einer Datenklasse abspeichern, welche beim Einloggen befüllt wird. Dazu müsste allerdings das Objekt oder die Referenz zu jeder anderen Activity übergeben werden. Eine andere Möglichkeit stellen erneut die Shared Preferences dar. Das wäre auch eine gute Lösung gewesen, welche wir aber zu spät entdeckt haben. Deshalb haben wir das Problem mit dem privaten Speicher gelöst. Er ist durch andere Apps und den Benutzer nicht einsehbar, bildet deshalb also kein Sicherheitsrisiko.\\
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
Es wurden im Projektverlauf auch noch diverse Erweiterungen des Frameworks genutzt.
|
||||
\begin{itemize}
|
||||
\item \textbf{org.springframework.boot:spring-boot-starter-web} bringt einen integrierten Tomcat Application Server mit und ermöglicht das Verarbeiten von Webanfragen.
|
||||
\item \textbf{org.springframework.boot:spring-boot-starter-actuator} wird genutzt, um Diagnose-Endpoints freizuschalten.
|
||||
\item \textbf{org.springframework.boot:spring-boot-starter-actuator} wird genutzt, um Endpoints für Diagnose freizuschalten.
|
||||
\item \textbf{org.springframework.boot:spring-boot-starter-data-jpa} bringt alle nötigen Abhängigkeiten, um mit der Java Persistence API Daten in einer Datenbank abzulegen.
|
||||
\item \textbf{org.springframework.boot:spring-boot-starter-data-rest} bietet Möglichkeiten, sehr leicht Datenbank Entitäten als HTTP REST Ressourcen bereitzustellen.
|
||||
\item \textbf{org.springframework.boot:spring-boot-starter-security} wird später zusammen mit der Authentifizierung über JWT genutzt.
|
||||
@ -106,13 +106,13 @@
|
||||
|
||||
\lstinputlisting[language=Java,linerange={14-27,38-41,47-58},caption=RecordRepository,label=code:record-repository]{../backend/src/main/java/de/hft/geotime/repositories/RecordRepository.java}
|
||||
|
||||
In diesem Repository befinden sich diverse verschiedene Methoden, wie Datenoperationen definiert werden können, ohne dass sie aktiv implementiert werden müssen. Es beginnt mit der Funktion "findAllByStartdateBetween". Dieser Name kann direkt als Java Hibernate Statement interpretiert werden und nimmt als Parameter zwei Datumsangaben entgegen und eine Page. Die zwei Datumsangaben werden aus dem Schlüsselwort "Between" abgeleitet. Damit es sich aber um echt vergleichbare Daten handelt, müssen diese nach einem bestimmten Schema geparsed werden. Dieses Schema ist in der "DateTimeFormat" Annotation angegeben. Als Rückgabe liefert diese Funktion dann eine Menge aller Einträge zwischen diesen Daten.
|
||||
In diesem Repository befinden sich diverse verschiedene Methoden, wie Datenoperationen definiert werden können, ohne dass sie aktiv implementiert werden müssen. Es beginnt mit der Funktion "findAllByStartdateBetween". Dieser Name kann direkt als Java Hibernate Statement interpretiert werden und nimmt als Parameter zwei Datumsangaben entgegen und eine Page. Die zwei Datumsangaben werden aus dem Schlüsselwort "Between" abgeleitet. Damit es sich aber um echt vergleichbare Daten handelt, müssen diese nach einem bestimmten Schema geparsed werden. Dieses Schema ist in der "DateTimeFormat" Annotation angegeben. Als Rückgabe liefert diese Funktion dann eine Menge aller Einträge zwischen diesen Daten.\\
|
||||
|
||||
Die nächste Funktion funktioniert nun ähnlich, nur dass dort über Eigenschaften mehrerer verlinkter Objekte gegangen werden kann. "findAllBy" ist wieder das selbe wie oben und zeigt an, dass eine Liste von Ergebnissen zurückgeliefert wird, aber "Account\_User\_Username" bedeutet nun folgendes: "Gehe zum Account des Records, dann zum User dieses Accounts und von diesem User dann den Username". Der gefundene Username wird dann mit dem Parameter der Funktion verglichen und die Ergebnisse entsprechend gefiltert. Weiter zeigt das "And" eine Verkettung eines weiteren Ausdrucks an. So können auch relativ komplexe Abfragen automatisch implementiert werden.
|
||||
Die nächste Funktion funktioniert nun ähnlich, nur dass dort über Eigenschaften mehrerer verlinkter Objekte gegangen werden kann. "findAllBy" ist wieder das selbe wie oben und zeigt an, dass eine Liste von Ergebnissen zurückgeliefert wird, aber "Account\_User\_Username" bedeutet nun folgendes: "Gehe zum Account des Records, dann zum User dieses Accounts und von diesem User dann den Username". Der gefundene Username wird dann mit dem Parameter der Funktion verglichen und die Ergebnisse entsprechend gefiltert. Weiter zeigt das "And" eine Verkettung eines weiteren Ausdrucks an. So können auch relativ komplexe Abfragen automatisch implementiert werden.\\
|
||||
|
||||
Reicht allerdings die obige Syntax nicht mehr aus, kann auch direkt eine Hibernate Abfrage über die "@Query" Annotation angegeben werden. Der Name der Funktion ist dann nicht mehr relevant für die Implementation, sondern nur noch für den Pfad, unter dem die Funktion später zu erreichen ist. Die Query an der "today" Funktion bietet nun die Möglichkeit, alle Einträge in der Records Tabelle für den aktuell anfragenden User zu bestimmen. Zusätzlich wird der Zeitraum noch auf den aktuellen Tag eingeschränkt, daher ergab sich auch der passende Name "today" für die Funktion. Der Nutzer wird automatisch über die "principal" Variable in der Abfrage eingefügt. Der Pricipal wird gesetzt, sobald der Authentication Filter den User erfolgreich eingeloggt hat. Weiter wird der aktuelle Tag über die Datenbankvariable "current\_date" abgefragt.
|
||||
Reicht allerdings die obige Syntax nicht mehr aus, kann auch direkt eine Hibernate Abfrage über die "@Query" Annotation angegeben werden. Der Name der Funktion ist dann nicht mehr relevant für die Implementation, sondern nur noch für den Pfad, unter dem die Funktion später zu erreichen ist. Die Query an der "today" Funktion bietet nun die Möglichkeit, alle Einträge in der Records Tabelle für den aktuell anfragenden User zu bestimmen. Zusätzlich wird der Zeitraum noch auf den aktuellen Tag eingeschränkt, daher ergab sich auch der passende Name "today" für die Funktion. Der Nutzer wird automatisch über die "principal" Variable in der Abfrage eingefügt. Der Pricipal wird gesetzt, sobald der Authentication Filter den User erfolgreich eingeloggt hat. Weiter wird der aktuelle Tag über die Datenbankvariable "current\_date" abgefragt.\\
|
||||
|
||||
Zuletzt kann auch nach Standard SQL Werten wie "null" oder "not null" gefragt werden. Zu sehen ist dies in der zuletzt dargestellten Funktion.
|
||||
Zuletzt kann auch nach Standard SQL Werten wie "null" oder "not null" gefragt werden. Zu sehen ist dies in der zuletzt dargestellten Funktion.\\
|
||||
|
||||
Die Datei ist nicht vollständig abgedruckt, sondern nur ausschnittsweise, um die Grundkonzepte zu erläutern.
|
||||
\subsection{Projections}
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
\chapter{Einleitung}
|
||||
Im Rahmen der Vorlesung Ubiquitous Computing ist eine Projektarbeit mit dem Thema der Allgegenwärtigkeit von Computern vorgesehen.
|
||||
Im Rahmen der Vorlesung Ubiquitous Computing ist eine Projektarbeit mit dem Thema der Allgegenwärtigkeit von Computern vorgesehen.\\
|
||||
|
||||
Dazu fanden wir uns als Gruppe zusammen und sammelten unsere Ideen für Projektthemen. Letztendlich setzte sich der Timetracker mit Geofence gegen eine Wetterstation und eine Augmented Reality App durch.
|
||||
Dazu fanden wir uns als Gruppe zusammen und sammelten unsere Ideen für Projektthemen. Letztendlich setzte sich der Timetracker mit Geofence gegen eine Wetterstation und eine Augmented Reality App durch.\\
|
||||
|
||||
Die Idee der Timetrack-Anwendung ist, dass ein Arbeitnehmer erst dann mit der Aufzeichnung seiner Arbeitszeit beginnen kann, wenn er sich am Arbeitsort befindet. Wenn er diesen verlässt, wird seine Aufzeichnung beendet. Dabei hat er mehrere Zeitkonten zur Auswahl, auf die er seine Arbeitszeit verbuchen kann.
|
||||
Die Idee der Timetrack-Anwendung ist, dass ein Arbeitnehmer erst dann mit der Aufzeichnung seiner Arbeitszeit beginnen kann, wenn er sich am Arbeitsort befindet. Wenn er diesen verlässt, wird seine Aufzeichnung beendet. Dabei hat er mehrere Zeitkonten zur Auswahl, auf die er seine Arbeitszeit verbuchen kann.\\
|
||||
|
||||
Das Projekt ist in drei Teile unterteilt: Backend, Web-Frontend und Android-App. Entsprechend dem Aufwand arbeiteten am Web-Frontend zwei Studenten, am Backend und der Android-App jeweils ein Student. Die Android-App soll lediglich die Basisfunktionalitäten bieten, wie Starten und Stoppen der Aufzeichnung für einen gewählten Account, wenn man sich am Arbeitsort befindet, sowie log in und log out. Im Web-Frontend sollen verschiedenste Statistiken angezeigt werden, sowie Adminfunktionaltäten, um Accounts zu editieren, neue Einträge hinzufügen, Geodaten für den Arbeitnehmer setzen und Benutzer löschen. Das Backend kommuniziert mit der Datenbank, sichert die Authentifizierung der Benutzer und stellt den Oberflächen Endpoints zur Verfügung.
|
||||
@ -32,7 +32,7 @@
|
||||
|
||||
\lstinputlisting[language=docker, caption=Dockerfile Backend]{../backend/Dockerfile}
|
||||
\lstinputlisting[language=docker, caption=Dockerfile Frontend]{../frontend/Dockerfile}
|
||||
\lstinputlisting[language=docker, caption=Dockerfile Android]{../android/Dockerfile}
|
||||
\lstinputlisting[language=docker, caption=Dockerfile Android, basicstyle={\footnotesize\ttfamily}]{../android/Dockerfile}
|
||||
|
||||
Zu erwähnen sind noch einige Besonderheiten. Da wir ein Programm entwickeln, was sich mit Zeiterfassung beschäftigt, ist es wichtig im Backend die Zeitzone des Images zu setzen, da sonst immer die UTC Zeitzone als Standard angenommen wird. Selbiges gilt auch für die SQL Datenbank, welche mit MariaDB umgesetzt ist.
|
||||
\section{Docker-Compose}
|
||||
|
||||
@ -5,7 +5,8 @@
|
||||
\subsection{Vuetify}
|
||||
Vuetify ist ein Designframework für Vue.js, dass viele Elemente wie Menüleisten, Buttons und Dialogfenster bereitstellt. Ein bekanntes äquivalentes Framwork ist Bootstrap. Das Designschema von Vuetify ist an Googles Material Design angelehnt. Nach Installation können die Elemente sehr einfach eingebunden und verwendet werden.
|
||||
\section{Farbschema und Designsprache}
|
||||
Wir haben uns für die, von Google entwickelte Designsprache, Material Design entschieden. Diese zeichnet sich durch ihre kartenartigen Flächen und dem Gestaltungsstil Flat Design aus. Verwendet werden auch viele Schatten um die materialistisch-physikalische Darstellung zu erzeugen.\\
|
||||
Wir haben uns für die, von Google entwickelte Designsprache, Material Design entschieden. Diese zeichnet sich durch ihre kartenartigen Flächen und dem Gestaltungsstil Flat Design aus. Verwendet werden auch viele Schatten um die materialistisch-physikalische Darstellung zu erzeugen.
|
||||
|
||||
In unserem eigens entwickelten Farbschema haben wir uns für ein dunkles Thema mit Blau als Hauptfarbe entschieden.
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@ -19,10 +20,9 @@
|
||||
\caption{Logo unserer Anwendung}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\section{Umsetzung}
|
||||
\subsection{Einarbeitung}
|
||||
Zur Einarbeitung haben wir den Vue JS Crash Course von Traversy Media genutzt. Dieser ist auf Youtube zu finden: \href{https://www.youtube.com/watch?v=Wy9q22isx3U&t=3007s}{https://www.youtube.com/watch?v=Wy9q22isx3U\&t=3007s}
|
||||
Zur Einarbeitung haben wir den Vue JS Crash Course von Traversy Media\footnote{\url{https://www.youtube.com/watch?v=Wy9q22isx3U}} genutzt. Dieser ist kostenlos auf YouTube zu finden.
|
||||
\subsection{Arbeit mit Dummy-Daten}
|
||||
Zur Erstellung der Listen und Diagramme haben wir häufig Dummy-Daten verwendet, um die Funktionalität im Frontend unabhängig vom Backend zu entwickeln. Die Dummy-Daten haben wir im jeweiligen Vue Component wie folgt angelegt.
|
||||
\begin{lstlisting}[language=JavaScript,caption=Dummy-Daten]
|
||||
@ -62,7 +62,7 @@ export default {
|
||||
</script>
|
||||
\end{lstlisting}
|
||||
Durch Verwendung der Dummy-Daten war es ebenso möglich Funktionsaufrufe zum Löschen oder Bearbeiten von Daten zu testen ohne persistente Veränderungen an den Daten auszulösen. Durch neu laden der Seite sind die Dummy-Daten wiederhergestellt. Bei der Erstellung der Diagramme waren die Dummy-Daten ebenfalls wichtig, so konnten Formatierungsfunktionen für die Zeitanzeige getestet werden. Ebenfalls konnte so die Optimale Größe und Anordnung der Diagramme bestimmt werden.\\
|
||||
\\
|
||||
|
||||
Durch die Verwendung von Dummy-Daten war der Umstieg auf die Live Daten nicht allzu schwer. Die Dummy-Daten konnten bei Anbindung an die Datenbank reibungslos durch Live-Daten aus der Datenbank ersetzt werden.
|
||||
|
||||
\subsection{Authentifizierung}
|
||||
@ -83,7 +83,7 @@ export default {
|
||||
xhttp.send(null);
|
||||
\end{lstlisting}
|
||||
\subsection{Ändern und Hinzufügen von Daten}
|
||||
Zum Ändern und Hinzufügen von Daten haben wir ebenfalls XMLHTTRequests genutzt. Zum Hinzufügen wurden Post Request gesendet, zum Ändern Patch Requests.
|
||||
Zum Ändern und Hinzufügen von Daten haben wir ebenfalls "XMLHTTP-Requests" genutzt. Zum Hinzufügen wurden Post Requests gesendet, zum Ändern Patch Requests.
|
||||
\begin{lstlisting}[language=JavaScript, caption=Post Request]
|
||||
xhttp.open("Post", baseUri + path, false);
|
||||
|
||||
@ -165,7 +165,6 @@ export default {
|
||||
},
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
Für die Kreisdiagramme war es notwendig alle Zeiteinträge abzuholen, die Zeiten zu Addieren und in die Datenfelder des Diagramms zu schreiben. Bei dem Kreisdiagramm das die Accounts darstellt war es notwendig die TimeTrack Accounts des Benutzers abzufragen und für jeden ein Feld der addierten Zeit anzulegen und den Lohn in einer Variable abzulegen.
|
||||
\begin{lstlisting}[language=JavaScript, caption=Zuordnung der Zeit zu den TimeTrack Accounts]
|
||||
for (let index = 0; index < records.length; index++){
|
||||
@ -179,15 +178,12 @@ export default {
|
||||
\end{lstlisting}
|
||||
|
||||
Ebenfalls war es notwendig eine Funktion zu erstellen, die den gesamten Lohn des jeweiligen Accounts nach den ermittelten Stunden berechnet.\\
|
||||
\\
|
||||
Bei den Säulendiagrammen müssen lediglich die nötigen Zeiteinträge beim zuständigen Endpoint angefragt werden. Dieser Endpoint liefert alle Einträge zwischen einem Startdatum und einem Enddatum. Hier wird immer das aktuelle Datum verwendet und die Zeitspanne entsprechend zurückgerechnet.
|
||||
\\
|
||||
|
||||
Bei den Säulendiagrammen müssen lediglich die nötigen Zeiteinträge beim zuständigen Endpoint angefragt werden. Dieser Endpoint liefert alle Einträge zwischen einem Startdatum und einem Enddatum. Hier wird immer das aktuelle Datum verwendet und die Zeitspanne entsprechend zurückgerechnet.\\
|
||||
|
||||
Um riesige Anfragen zu verhindern wird Paging verwendet um die Anfragen durchzuführen, das heißt es werden so oft 50 Einträge angefragt, bis die letzte Seite erreicht ist.
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Administrator Funktionalitäten}
|
||||
\subsection{Administrator Funktionalitäten}\label{subsection:frontend:admin}
|
||||
Ein Administrator hat die Möglichkeit zur vollen Nutzerverwaltung. Er kann Nutzer löschen, und bearbeiten. Als Bearbeitungsmöglichkeiten hat er die Accountverwaltung von Nutzern, das Setzen der Arbeitslocation für einen Nutzer und das Ändern des Namens.
|
||||
\section{Funktionen der Website}
|
||||
\subsection{Home}
|
||||
@ -233,7 +229,7 @@ export default {
|
||||
\end{figure}
|
||||
|
||||
\subsection{Admin}
|
||||
Die Admin Seite bietet einem die Möglichkeiten, welche in 5.3.7 beschrieben werden. Um die einzelnen Verwaltungsmöglichkeiten zu sehen, reicht es über den Stift zu hovern. Das linke Zeichen (rote Mülltonne) löscht den jeweiligen Nutzer, das mittlere (grün) Ist zum Ändern der Nutzerinformationen und der Position der Arbeitsstelle. Das rechte Zeichen (blau) führt einen zur Accountverwaltung für den jeweiligen Nutzer.
|
||||
Die Admin Seite bietet einem die Möglichkeiten, welche in \ref{subsection:frontend:admin} beschrieben werden. Um die einzelnen Verwaltungsmöglichkeiten zu sehen, reicht es über den Stift zu hovern. Das linke Zeichen (rote Mülltonne) löscht den jeweiligen Nutzer, das mittlere (grün) Ist zum Ändern der Nutzerinformationen und der Position der Arbeitsstelle. Das rechte Zeichen (blau) führt einen zur Accountverwaltung für den jeweiligen Nutzer.
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{img/frontend/admin.PNG}
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
\vspace{1cm}\\
|
||||
{\scshape\LARGE Studiengang Informatik \\ Ubiquitous Computing \\ Sommersemester 2020 \par}
|
||||
\vspace{2cm}
|
||||
{\Huge\bfseries GeoTime \par}
|
||||
{\Huge\bfseries Geo Timetracking \par}
|
||||
{\LARGE Timetracking auf Standortbasis \par}
|
||||
\vfill
|
||||
{\Large \textsc{von}}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user