Watchdog, der virtuelle Begleiter. Konzeption und Implementierung einer Android-App für mehr Sicherheit auf dem Heimweg

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Verzeichnis der Codeauszüge

Abkürzungsverzeichnis

1 Einleitung
1.1 Zielsetzung der Arbe it
1.2 Realisierungsumfang
1.3 Aufbau der Arbeit

2 Grundlagen
2.1 Android Grundlagen
2.1.1 Java Entwicklung neu erfunden
2.1.2 Wichtige Komponenten in der Android-Entwicklung
2.1.3 Wichtige Dateien zum Aufbau einer apk
2.2 Vorstellung der Plattform
2.3 Einführung in Bluetooth Grundlagen Bluetooth Low Energy
2.3.1 Protocol Stack
2.4 Attribute Protocol (ATT)
2.5 Generic Attribute Profile (GATT)
2.6 Generic Access Profile (GAP)
2.7 Bluetooth in Android
2.8 Kommerzialisierungsstrategien
2.8.1 Kostenlose Apps / Werbung
2.8.2 Freemium / Abo-Modell
2.8.3 In-App-Käufe
2.8.4 Kostenpflichtige App

3 Hauptteil
3.1 Analyse
3.1.1 Beschreibung der App-Idee
3.1.2 Beschreibung der Anwendungsfälle
3.1.3 Beschreibung der Aktivitäten
3.1.4 Beschreibung der funktionalen Anforderungen
3.1.5 Anforderungen an den Bluetooth-Button
3.1.6 Beschreibung der Funktionen einer Ausbaustufe
3.1.7 Beschreibung der nicht-funktionalen Anforderungen
3.2 Vergleich mit bestehenden Lösungen/Arbeiten
3.2.1 KommGutHeim
3.2.2 Familonet
3.2.3 WayGuard
3.2.4 Glympse
3.2.5 Flic Bluetooth Button
3.2.6 Findulin
3.2.7 Pressy Button
3.2.8 IFTTT
3.3 Design
3.3.1 Wireframes und Screenflow Diagramm
3.3.2 Einfaches Activity Diagramm
3.3.3 V.BTTN - Einführung und Funktionsumfang
3.4 Implementierung
3.4.1 Implementierung der Datenbankstruktur
3.4.2 BT-spezifische Entwicklung
3.4.2.1 Initialisierung des Bluetooth-Service
3.4.2.2 Suche nach Bluetooth-Geräten
3.4.2.3 Verbindung des Bluetooth-Geräts
3.4.2.4 Kommunikation zwischen Button und App
3.4.2.5 Verwendung der Bluetooth SIG-Spezifikation
3.4.3 Automatisierte Ausführung von Events
3.5 Praktischer Einsatz und Bewertung
3.5.1 Verbindungsstabilität und -reichweite
3.5.2 Akku-Laufzeit und -verbrauch
3.5.3 Reaktionsgenauigkeit und -geschwindigkeit

4 Analyse der Kommerzialisierungsstrategien
4.1 Kostenkalkulation
4.2 Kostenfreies Modell (Werbung)
4.3 Freemium
4.4 In-App Käufe
4.5 Abo Modell
4.6 Kostenpflichtige App
4.7 Entscheidung

5 Ausblick

6 Zusammenfassung & Fazit

Quellenverzeichnis

Verzeichnis der Anhänge

Glossar

Abbildungsverzeichnis

Abbildung 1: BLE Protocol Stack [Gupta, S. 141]

Abbildung 2: GATT Profile Hierarchie [Bluetooth SIG 2016d]

Abbildung 3: App blitzer.de Free-Version (Herausgeber: Eifrig Media GmbH)

Abbildung 4: App blitzer.de Premium-Version (Herausgeber: Eifrig Media GmbH)

Abbildung 5: Abo-Modell der App Freeletics (Herausgeber: Freeletics)

Abbildung 6: In-App-Käufe in der App Once (Herausgeber: Once Dating AG)

Abbildung 7: Use Case Diagramm

Abbildung 8: Aktivitätsdiagramm "Startscreen"

Abbildung 9: Aktivitätsdiagramm "Heimweg antreten"

Abbildung 10: Aktivitätsdiagramm: "Gefahrenperson begleiten"

Abbildung 11: Aktivitätsdiagramm "Einstellungen verwalten"

Abbildung 12: Schablone zur Beschreibung der funktionalen Anforderungen nach [Creative Commons 2016c, S. 220]

Abbildung 13: Schablone für funktionale Anforderungen mit Bedingung nach [Creative Commons 2016c, S. 224]

Abbildung 14: Routenverfolgung in der App KommGutHeim

Abbildung 15: Familonet Praxistest

Abbildung 16: Wayguard Praxistest: Ansicht der Vertrauensperson

Abbildung 17: Wayguard Praxistest: Ansicht der Gefahrenperson

Abbildung 18: Glymps über App, Sicht des Glympse

Abbildung 19: Glympse Web Anwendung, Sicht des Beobachters

Abbildung 20: Flic App - Definition einer Notfall-SMS

Abbildung 21: Notfall-SMS von Flic mit Standortangabe

Abbildung 22: Definition eines Anrufs in der Pressy-App

Abbildung 23: Definition einer SMS mit der Pressy-App

Abbildung 24: Wireframe: Login Bildschirm

Abbildung 25: Wireframe: Home Bildschirm

Abbildung 26: Wireframe: Menü

Abbildung 27: Wireframe: Gefahrenperson: Vertrauensperson auswählen

Abbildung 28: Wireframe: Vertrauensperson: Gefahrenperson auswählen

Abbildung 29: Wireframe: Kontakte

Abbildung 30: Wireframe: Ziel definieren

Abbildung 31: Wireframe: Route festlegen

Abbildung 32: Wireframe: Zuhause definieren

Abbildung 33: Wireframe: Vertrauensperson: Guard

Abbildung 34: Wireframe Vertrauensperson: Heading Home

Abbildung 35: Wireframe: Kontakt anzeigen

Abbildung 36: Wireframe: Kontakt bearbeiten

Abbildung 37: Wireframe: Kontakt anlegen

Abbildung 38: Wireframe: Einstellungen, Bluetooth-Button nicht verbunden

Abbildung 39: Wireframe: Einstellungen, Bluetooth-Button verbunden

Abbildung 40: Wireframe: Nachrichten Einstellungen anzeigen

Abbildung 41: Wireframe: Nachrichten Einstellungen ändern

Abbildung 42: Wireframe: Button Einstellungen

Abbildung 43: Wireframe: Button verbinden

Abbildung 44: Screenflow Diagramm

Abbildung 45: Activity-Klassenmodell I

Abbildung 46: Activity-Klassenmodell II

Abbildung 47: V.BTTN in verschiedenen Modi

Abbildung 48: Beziehungen einiger Bluetooth-Klassen

Abbildung 49: Klassische Platzierung von Werbe-Bannern, unten

Abbildung 50: Klassische Platzierung von Werbe-Bannern, oben

Abbildung 51: Mittelgroßes Werbebanner

Abbildung 52: Großflächiges Werbebanner

Abbildung 53: Vollflächiges Werbebanner als Layer

Abbildung 54: Vollflächiges Werbebanner auf dem Lade-Screen

Tabellenverzeichnis

Tabelle 1: Bluetooth Power Classes [Hopkins & Antony 2003, S. 16]

Tabelle 2: Konfiguration und Kom patibilität der Bluetooth Spezifikationen (angelehnt an [Townsend 2014, S. 4])

Tabelle 3: Bluetooth Service - Battery Service

Tabelle 4: Bluetooth Services - Immediate Alert und Link Loss

Tabelle 5: Use Case "Konto verwalten"

Tabelle 6: Use Case "Heimweg antreten"

Tabelle 7: Use Case " Gefahrenperson mit App begleiten"

Tabelle 8: Use Case „Gefahrenperson ohne App begleiten“

Tabelle 9: Use Case "Kontakte verwalten"

Tabelle 10: Use Case "Einstellungen verwalten"

Tabelle 11: Funktionale Anforderungen "Einstellungen verwalten" (Ausschnitt)

Tabelle 12: Überführung Wireframes in Activities

Tabelle 13: Nutzung der Werte von Immediate Alert & Link Loss im V.BTTN [VSN Mobil 2014, S. 4]

Tabelle 14: VSN Services & UUIDs

Tabelle 15: Benachrichtigungswerte der Button-Events

Tabelle 16: Preis-Modell der Google Maps APIs [Creative Commons 2016g]

Tabelle 17: Credit Verbrauch pro API Anfrage

Tabelle 18: Nutzungsmodelle Firebase [Creative Commons 2016q]

Tabelle 19: Funktionale Anforderungen "Konto verwalten"

Tabelle 20: Funktionale Anforderungen "Heimweg antreten"

Tabelle 21: Funktionale Anforderungen "Gefahrenperson begleiten"

Tabelle 22: Funktionale Anforderungen "Kontakte verwalten"

Tabelle 23: Funktionale Anforderungen "Einstellungen verwalten"

Tabelle 24: Gegenüberstellung der Vor- und Nachteile der Kommerzialisierungsstrategienxxii Tabelle 25: Testergebnisse der Verbindungsreichweite

Tabelle 26: Testergebnisse der Reichweiten-Reaktionsfähigkeit

Tabelle 27: Testergebnisse der Reaktionsgeschwindigkeit von SMS und Anrufen

Tabelle 28: Testergebnisse des Akkuverbrauchs des Smartphones ohne Verbindung zum Bluetooth-Button

Tabelle 29: Testergebnisse des Energieverbrauchs von Smartphone und Bluetooth-Button bei bestehender Verbindung

Verzeichnis der Codeauszüge

Codeauszug 1: Beispiel: Schreiben und Lesen der SQLite Datenbank

Codeauszug 2: Bindung des Bluetooth-Service in der SettingsActivity

Codeauszug 3: onCreate() Methode der DeviceScanActivity

Codeauszug 4: Verbindung zum Bluetooth-Button in der Klasse SettingsActivity

Codeauszug 5: Verbindungsaufbau mit dem Bluetooth-Button in der Klasse Bluetooth­Service, Teil 1

Codeauszug 6: Auslösen einer Aktion mit dem Bluetooth-Button im Bluetooth-Service

Codeauszug 7: Ausführung des definierten Events in der Klasse SettingsActivity

Codeauszug 8: Abfrage des Batteriestatus im Bluetooth-Service

Codeauszug 9: Aufruf der Methode onCharacteristicRead() im Bluetooth-Service

Codeauszug 10: Auslösen des Button-Events im Bluetooth-Service

Codeauszug 11: Automatischer Versand einer SMS in der Klasse Events

Codeauszug 12: Automatisches Auslösen eines Anrufs in der Klasse Events

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Für Frauen hat sich in Deutschland in den vergangenen 60 Jahren viel verändert, insbesondere was gesellschaftliche und rechtliche Gleichstellung angeht. Der 1900 festgelegte Gehorsamsparagraf macht Frauen bis kurz nach dem zweiten Weltkrieg selbst in ihrem eigenen Eheleben mitbestimmungslos. Erst 1957 wird dieser Paragraf aufgelöst. 1958 erhalten Frauen mit dem Eintritt des Gleichberechtigungsgesetztes erstmals das Recht ohne Einwilligung des Ehemannes die Erwerbstätigkeit zu erlangen und ein Bankkonto zu eröffnen. Die völlige Aufhebung der rechtlichen Benachteiligung der Frau dauert schließlich noch bis 1977 [Florian Faderl, Frauke Hagemann, Katja Rieger 2014, S. 39]. Mit der zunehmenden rechtlichen und beruflichen Selbstständigkeit der Frau wird diese in den Folgejahren auch in ihrem Alltag selbstständiger. Als Folge davon bewegt sich die Frau zunehmend ohne ihren Ehegatten und damit ohne Begleitung durch die Öffentlichkeit. Bis heute hat sich die Selbstständigkeit der Frau stetig weiterentwickelt und führt letztendlich nicht nur dazu, dass sich diese in ihrem Alltag sondern beispielsweise auch nachts alleine in der Öffentlichkeit bewegt. Aus der polizeilichen Kriminalstatistik von 2015 geht hervor, dass die Opfer von versuchten und vollendeten „Straftaten, gegen die sexuelle Selbstbestim m ung unter Gewaltanwendung (...)“ in über 90% der Fälle weiblich waren [Bundesministerium des Innern 2016, S. 28]. Sehr starke öffentliche Aufmerksamkeit erregte das Thema zuletzt durch die zahlreichen sexuellen Übergriffe auf Frauen in der Silvesternacht 2015/2016 in mehreren deutschen Städten [Lena Kampf 2016]. Vermeiden ließe sich dieses Problem zum Beispiel, wenn sich Frauen nachts auf ihrem Heimweg von einer vertrauten Person abholen oder begleiten ließen. Doch nicht jede Frau kann und möchte diese Möglichkeit in Anspruch nehmen. Stattdessen wird eine Lösung benötigt, die ohne großen zusätzlichen Aufwand verwendet werden kann.

Daher befasst sich die vorliegende Masterarbeit mit der Entwicklung einer Smartphone Applikation - im Folgenden auch „Watchdog“ genannt - die einen Nutzer auf seinem Heimweg begleiten und ihm damit ein zusätzliches Maß an Sicherheit vermitteln soll.

Obwohl es nicht als menschlicher Begleiter gesehen werden kann, gehört das Smartphone heutzutage bei einem Großteil der Bevölkerung zum alltäglichen Gefährten. So besaßen 2015 89% der 14-29 Jährigen und 82% der 30-49 Jährigen in Deutschland ein Smartphone [Statista GmbH 2016, S. 36]. Gleichzeitig wird der Anteil der Smartphone-Besitzer nach aktuellen Prognosen in den kommenden Jahren weiter wachsen [eMarketer].

Parallel hierzu ist nicht nur der Anstieg des Smartphone-Absatzes zu beobachten, sondern auch der zunehmend generierte Umsatz mit dem Internet der Dinge („Internet of Tings“ - IoT). Während 2010 bereits 3,8 Milliarden Euro Umsatz generiert werden konnten, wurden für 2016 13,7 Milliarden Umsatz prognostiziert [comScore 2016]. Das IoT steht dabei für jegliche „smarte Geräte“, die durch ihre Technologien den Alltag erleichtern. Hierzu zählen nicht nur Smartphones und Tablets sondern auch Wearables und alle durch einen Prozessor, Sensoren und Netzwerktechnik ausgestatteten Alltagsgeräte. Eine wichtige Technologie im Bereich des IoT ist das Bluetooth Low Energy, welches für eine drahtlose Verbindung von verschiedenen Gadgets verwendet wird [Stefan von Gagern 2016].

Eine Verknüpfung der App Watchdog mit einem „smarten Gerät“ könnte für den Nutzer noch mehr Sicherheit bedeuten. Hinsichtlich der aktuellen Entwicklung, dass neben den zunehmenden Smartphone-Besitzern die Anzahl der Diebstähle dieser Geräte steigt [Mathias Brandt 2014], wäre es für den Nutzer von deutlichem Vorteil, wenn dieser die in der vorliegenden Arbeit zu entwickelnde App nutzen könnte, ohne dabei das Smartphone in der Hand halten zu müssen. Durch die Aufbewahrung des Smartphones in der Handtasche könnte einem solchen Diebstahl entgegengewirkt werden. Stattdessen kann ein „smartes Gerät“ direkt am Körper getragen werden, welches über Bluetooth mit der App verbunden ist und beispielsweise in einer Gefahrensituation Notrufe über eine App auf dem Smartphone auslösen kann.

1.1 Zielsetzung der Arbeit

Ziel dieser Arbeit ist es, einen Prototyp des Begleiters zu entwickeln, der als Smartphone App auf dem Heimweg ein Gefühl der Sicherheit vermittelt und in gefährlichen Situationen einen Notruf absetzen kann. Gleichzeitig bringt ein kleiner Bluetooth-Button die Lösung für das zuvor genannte Problem, dass ein Smartphone nachts nicht permanent für jeden sichtbar in Benutzung sein sollte. Wird das Gerät über Bluetooth mit dem Smartphone verbunden, können jegliche Notfall-Signale ausgesteuert werden, ohne dass das Telefon aus der Tasche geholt werden muss. Dabei stellt sich jedoch die Frage, an wen diese Notrufe ausgesteuert werden?

An diesem Punkt wird der virtuelle, technische Begleiter des Heimwegs durch einen wirklichen Begleiter - der Vertrauensperson - ergänzt. Hierfür muss die Vertrauensperson weder vor Ort sein, noch die Watchdog-App selbst installiert haben. Per SMS wird die Vertrauensperson in diesem Fall vom Nutzer der App über den aktuellen Status informiert und in Gefahrensituationen alarmiert. Hat die Vertrauensperson ebenfalls die App installiert, kann diese über die Übermittlung von GPS-Daten den Heimweg verfolgen.

1.2 Realisierungsumfang

Die vorliegende Arbeit wird im Hauptteil in zwei grundlegenden Komponenten bearbeitet, welche in ihrem Realisierungsumfang voneinander abzugrenzen sind:

Die erste Komponente besteht aus der Darstellung, Konzeption und Analyse der grundlegenden Idee der App. Dabei wird diese in ihrem vollen Umfang untersucht und bearbeitet. Es wird neben der Erläuterung der App eine mögliche Monetarisierung und Kommerzialisierung durch die Analyse verschiedener Geschäftsmodelle abgedeckt.

Die zweite Komponente besteht aus der tatsächlichen Entwicklung der App. Hierbei werden lediglich die Grundfunktionen umgesetzt, die für den zu erfüllenden Hauptanwendungsfall benötigt werden. Damit deckt das Ergebnis der App die Funktionen ab, die für eine Dem onstration und die Durchführung von Feldtests benötigt werden. Der dabei verwendete Bluetooth-Button wird nicht selbst entwickelt. Verwendet wird stattdessen ein bereits auf dem Markt erhältlicher Button, welcher durch eine offene Schnittstelle frei weiterentwickelt und somit in Verbindung mit Watchdog verwendet werden kann. Ergänzt wird die Entwicklung mit der Untersuchung der App auf ihre Tauglichkeit für den praktischen Einsatz. Ausgehend von den programmierten Grundfunktionen, die den Tauglichkeitstest bestehen, könnte in Zukunft das weitere Konzept umgesetzt und die App stetig um Funktionen erweitert werden.

Bei der Wahl der Technologie für eine App-Entwicklung stehen drei verschiedene Ansätze zur Verfügung: eine Web App, eine native oder eine hybride App. Bei Web Apps handelt es sich um Anwendungen, die im Internet Browser angezeigt werden. Diese müssen bei jeder Verwendung neu geladen werden und haben nur eingeschränkten Zugriff auf die Hardwarekomponenten des Smartphones, wie beispielsweise GPS [Petra Riepe 2015].

Der Unterschied zwischen einer nativen und einer hybriden App liegt darin, dass eine hybride App auf der Grundlage einer Codebasis für die drei Betriebssysteme Android, iOS und Windows entwickelt werden kann. Die Entwicklungstechnik basiert auf den Web Technologien HTML5 und CSS [Svanidze 2016]. Anschließend wird diese einmalige Entwicklung durch Frameworks¹ wie beispielsweise Ionic in eine für das Betriebssystem kompatible App transformiert.

Native Applikationen hingegen werden in der Programmiersprache eines Betriebssystem s entwickelt und können dadurch auf jegliche Hardware-Komponenten des Smartphones und den damit verbundenen Funktionen zugreifen [Pronschinske 2014]. Neben dem uneingeschränkten Zugriff auf die Hardwarekomponenten des Smartphones belasten native Apps die Hardware Ressourcen im geringeren Ausmaß und wirken sich daher positiv auf die Geschwindigkeit aus. Ebenso können sie dem vom Nutzer erwarteten Verhalten entsprechen: Sie starten direkt beim Öffnen und haben ein konsistentes Nutzungserlebnis [Mario Korf, Eugene Oksman 2016]. Dem Anwender soll die in dieser Arbeit entwickelte Applikation ein Gefühl von Sicherheit vermitteln. Dies wird zum einen über die im weiteren Verlauf der Arbeit erläuterten Funktionen erreicht. Zum anderen wird es durch Design und intuitive und schnelle Bedienbarkeit unterstützt. Insbesondere aufgrund der optimalen Bedienbarkeit fällt die Entscheidung der Entwicklungstechnologie daher auf eine native App.

Auf die Entscheidung für die Entwicklung einer nativen App, folgt die Wahl des zu entwickelnden Betriebssystems. Im Juni 2016 gehörten Android (79,2%) und iOS (14,2%) zu den Betriebssystemen für Smartphones mit dem höchsten Marktanteil [Kantar]. Des Weiteren unterscheidet sich die Entwicklung in Android hinsichtlich der Rahmenbedingungen stark von der Entwicklung einer iOS App: Das SDK (Software Development Kit) beider Plattformen ist kostenlos, wobei das SDK zur Entwicklung von iOS Apps ausschließlich auf einem Mac Book installiert werden kann. Zum Testen der iOS App wird im iOS SDK zunächst nur ein Simulator bereitgestellt. Für direkte Tests auf dem iPhone ist zusätzlich ein Apple Developer Account obligatorisch, welches 79 Euro im Jahr kostet [Apple Inc.]. Das Testen der Applikation ist bei Android hingegen kostenlos. Die einmalige Gebühr von 25 Dollar für das Developer Konto muss erst zur Veröffentlichung im Play Store gezahlt werden [Google].

Neben der gewünschten Verbreitung des gewählten Betriebssystems eignet sich die Entwicklung für Android ebenso aufgrund der genannten Faktoren hinsichtlich Kosten und Rahmenbedingungen besser für dieses Projekt.

Bei der Entwicklung der Android App wird als minimalem Android SDK-Level die Android Version 5.0 „Lollipop“ unterstützt. Zusammen mit der aktuellen Version 6.0 „Marshmallow“ machen diese eine derzeitige Verbreitung von 50,7% aller Android-Nutzer aus [Creative Commons 2016p]. Dabei wird als Ziel-SDK-Level die aktuelle Android Version 6.0 unterstützt. Zur Entwicklung dieser App wird als minimale SDK-Level 5.0 und damit die API Version 21 definiert, da in dieser Version die Technologie Bluetooth Low Energy erstmalig unterstützt wird [Creative Commons 2016t]. Diese Unterstützung ist für die Realisierung der Anwendungsfälle in dieser Arbeit notwendig. Als Ziel-SDK wurde die zum Projektstart aktuellste Android Version 6.0 gewählt, da in dieser ein neues Berechtigungskonzept veröffentlicht wurde, welches im weiteren Verlauf der Arbeit näher erläutert wird.

Für eine strukturierte Übersicht der behandelten Themen, wird der Aufbau der Arbeit im folgenden Kapitel kurz vorgestellt.

1.3 Aufbau der Arbeit

Das Entwicklungsprojekt der Applikation wird in zwei Arbeiten mit unterschiedlichen Schwerpunkten vorgestellt. In der vorliegenden Arbeit liegt der Fokus auf den Themenkomplex der Integration einer Schnittstelle zwischen Bluetooth Buttons und der App zur Mitteilung des Aufenthaltsorts und dem damit notwendigen Datenaustausch zwischen beiden Geräten. In der zweiten Arbeit „Watchdog, virtueller Begleiter - Konzeption und Implementierung einer Android App zur Mitteilung des Aufenthaltsortes sowie die Analyse von Kommerzialisierungsstrategien mit Schwerpunkt auf der Erhebung von Standortdaten und deren Übermittlung an Dritte“ von werden die Themen Lokalisierung und Datenübertragung von Standorten diskutiert. Hinsichtlich einiger übergeordneter Themen überschneiden sich beide Arbeiten und werden jeweils durch den themenspezifischen Teil ergänzt. Im Folgenden werden der Aufbau der Arbeiten und die Abgrenzung der gemeinsamen und spezifischen Teile erläutert.

Im ersten Teil beider Arbeiten werden die gleichen theoretischen Grundlagen zu Begriffen und Konzepten aus der Android-Entwicklung um individueller, themenspezifischer Theorie ergänzt. Durch die Vorstellung von möglichen Erlösstrategien beim Vertrieb der App wird in Kapitel 2.8 der theoretische Teil beider Arbeiten vervollständigt.

Als Basis zur Entwicklung der App wird in Kapitel 3.1 eine detaillierte Analyse der App hinsichtlich ihrer erforderlichen Funktionen und Anforderungen vorgenommen, welche im Kapitel 3.2 mit den bereits auf dem Markt existierenden Lösungen verglichen werden. Die identifizierten Anforderungen werden anschließend im Kapitel 3.3 durch die Ableitung von Wireframes und einem Klassenmodell für die konkrete Implementierung vorbereitet. Diese Ausarbeitung erfolgt übergreifend in beiden Arbeiten. Lediglich in der Definition der funktionalen Anforderungen erfolgen eine themenspezifische Ergänzung sowie die Herausarbeitung der Anforderungen des Bluetooth-Buttons in der vorliegenden Arbeit. Erst im folgenden Kapitel wird eine themenspezifische Erläuterung der jeweiligen Implementierung vorgenommen. Der Hauptteil wird anschließend mit der Bewertung des praktischen Einsatzes durch die Durchführung von Tests abgeschlossen.

In Kapitel 4 wird der mögliche Einsatz der unterschiedlichen Erlösmodelle auf die entwickelte App untersucht und diskutiert. Diese Analyse und die abschließende Bewertung erfolgen auf Basis der gesamten App und sind daher in beiden Arbeiten wiederzufinden.

In einem gemeinsamen Ausblick beider Arbeiten werden die behandelten Aspekte reflektiert und offene sowie zukünftige Themen hervorgehoben. Im Fokus liegen hier eine mögliche Ausgestaltung der App und die Berücksichtigung kommender Technologien. In beiden Arbeiten wird der Ausblick jeweils um eine themenspezifische Betrachtung ergänzt.

2 Grundlagen

In diesem Kapitel werden die Grundlagen und Konzepte erläutert, auf denen die Entwicklung der Applikation Watchdog basiert. Dabei wird einerseits die allgemeine Android Entwicklung vorgestellt, sowie andererseits themenspezifische Theorie vermittelt. Abschließend werden Kommerzialisierungsstrategien von Applikationen dargelegt, die in dem Kapitel 4 auf die Anwendung bezogen diskutiert werden.

2.1 Android Grundlagen

Android wurde 2003 von Andy Rubin und Nick Sears gegründet. Das Unternehmen hatte die Vision eines offenen Betriebssystems für mobile Geräte. Diese Vision teilte auch Larry Page, Gründer von Google, weshalb dieser das Unternehmen für 50 Millionen US-Dollar kaufte [Erdle 2013]. 2007 gründete Google das Konglomerat Open Handset Alliance, wodurch Android offiziell zu einem Open Source Projekt wurde [Gargenta & Nakamura 2014, S. 3 f.]. Die Open Handset Alliance besteht zurzeit aus 84 Unternehmen, die sich auf Netzbetreiber, Softwareunternehmen, Marketingunternehmen, Handelsindustrie und Gerätehersteller aufteilen. Die Vision ist dabei, durch Open Source eine einfache und gute Softwareentwicklung zu ermöglichen [Open Handset Alliance 2007]. Bereits im Jahr der Gründung erschien das Android SDK. Hierdurch konnte es jedem ermöglicht werden, Applikationen für Android Geräte zu entwickeln [Kaumanns & Siegenheim 2009, S. 290 f.].

Im folgenden Abschnitt wird zunächst auf die besondere Verwendung der Programmiersprache Java im Vergleich zur klassischen Programmierung in dieser Sprache eingegangen. Anschließend werden wichtige Begriffe und Wirkungsweisen vorgestellt. Diese und weitere Definitionen von Begriffen sind zusätzlich in dem angehängten Glossar aufgeführt.

2.1.1 Java Entwicklung neu erfunden

Android Anwendungen werden in der Regel in Java geschrieben, jedoch können nicht alle in Java vorhandenen Pakete und bekannte Prinzipien verwendet werden. Spezielle Klassen für mobile Geräte werden bei der Android Entwicklung über die Dalvik Virtual Machine zur Verfügung gestellt [Felker & Franken 2011, S. 30 f.]. In der klassischen Java-Entwicklung wird in Klassen programmiert, die eigenständig in der Applikation stehen. Im Gegensatz dazu werden in der Android Entwicklung Klassen² verwendet, die bereits auf der Entwicklungsmaschine zusammengefasst und in ein anderes Datei-Format überschrieben werden. Damit wird erreicht, dass bereits auf der Entwicklungsmaschine ein schnell interpretierbarer Code generiert wird, sodass das Ausführen auf einem Smartphone eine hohe Performance ermöglicht. Das dazu genutzte Datei-Format heißt dex, wobei dex für Dalvik Executable steht. Zur Ausführung auf dem Smartphone werden dex-Dateien durch weitere Dateien so lange angereichert, bis eine apk (android package) entsteht, die durch die Dalvik Virtual Machine auf dem Betriebssystem des Android-Gerätes ausgeführt werden kann [Creative Commons 2016r].

Im Unterschied zu Java Applikationen, die auf PCs oder Laptops laufen, müssen Android Applikationen auf Smartphones mit begrenzten Ressourcen auskommen. Dabei kann unter Umständen die Rechenkapazität den Einsatz von beliebig vielen Bibliotheken limitieren. Auch der Zugang zum Internet ist zu berücksichtigen, sowie dessen Geschwindigkeit und Stabilität. Weitere Gegebenheiten beeinflussen die Entwicklung, wie beispielsweise die Anzahl unterschiedlich großer, in ihrer Auflösung stark variierender Displays oder die Bedienung über einen Touchscreen. Zudem ist die Geschwindigkeit der Entwicklung beispielsweise neuer Technologien und Möglichkeiten zur Ressourcennutzung auf dem Smartphone sehr hoch, sodass Applikationen bei nicht entsprechender Wartung schnell veralten können.

2.1.2 Wichtige Komponenten in der Android-Entwicklung

Eine Android Applikation besteht in der Regel immer aus einer oder mehreren Activities. Eine Activity ist ein zusammengeführtes Konzept, bestehend aus einer ausführbaren Java-Datei und einem darstellenden XML-Layout. Die Activity folgt einem Lebenszyklus, welcher nicht allein über die Applikation selbst gesteuert, sondern wird zusätzlich durch das Betriebssystem oder andere Applikationen beeinflusst. Es können diverse Situationen auftreten, die bei der Entwicklung zu berücksichtigen sind. Zum Beispiel wird eine Activity zerstört, wenn sich die Bildschirmausrichtung ändert. So muss bei der Entwicklung bestimmter Activities eine Datensicherung bei einer möglichen Zerstörung der Activity berücksichtigt werden. Hierzu kann auf die unterschiedlichen Lebenszyklusphasen einer Activity zurückgegriffen werden. Folgende Zustände können über diesen zugänglich gemacht werden [Creative Commons 2016h]:

- Erzeugen einer Activity
- Starten einer Activity
- Zurückkehren zu einer bereits erzeugten und gestarteten Activity
- Neustart einer Activity
- Pausieren einer Activity (z.B. bei einem Bildschirmtimeout)
- Stoppen einer Activity
- Zerstören einer Activity

Die Darstellung kann neben einer Activity durch eine weitere verwandte Komponente entwickelt werden, dem Fragment. Das Fragment kann mit seinem eigenen Lebenszyklus nur innerhalb einer Activity aufgerufen werden und ist dadurch von ihr abhängig. So kann eine Activity aus einem oder mehreren Fragmenten bestehen [Creative Commons 2016i]. In dieser Arbeit werden Fragmente nur rudimentär eingesetzt, deswegen wird an dieser Stelle nicht näher darauf eingegangen. Der in diesem Zusammenhang zu erwähnende FragmentManager wird im Glossar erläutert.

Um Nachrichten und Aufgaben zwischen den verschiedenen Komponenten einer Applikation zu verteilen werden Intents genutzt. Einem Intent kann eine Aufgabe oder Nachricht, sowie ein Empfänger mitgegeben werden. Ist der Empfänger nicht spezifiziert, entscheidet ein Intent selbst, welche Applikation diese Aufgabe bewältigen kann [Lindow-Zechmeister 2012]. Der dazugehörige Begriff Bundle wird im Glossar definiert.

Aufgaben können innerhalb einer Applikation in den Hintergrund ausgelagert werden. Dies wird häufig mit Operationen gemacht, die wiederkehrend auftreten und/ oder keine Benutzeroberfläche benötigen. Ein Service wird dabei für langfristige Operationen genutzt. Er kann unabhängig eines Activity-Lebenszyklus innerhalb einer Applikation verwendet werden, wodurch die Gefahr vermieden wird, dass die Operation beispielsweise durch das System unter- oder abgebrochen wird. Zudem sind Services höher priorisiert als inaktive oder verdeckte Activities [Vogel 2016]. Kürzer laufende Aufgaben können über einen AsyncTask im Hintergrund ausgeführt werden. Sowohl der Service, als auch der AsyncTask laufen im Prozess der Applikationen, sodass diese einen direkten Einfluss auf die Performance der Applikation haben [Creative Commons 2016m]. Der weiterführende Begriff IntentService wird im Glossar definiert.

Daten können zu verschiedenen Zwecken auf unterschiedliche Wege lang- oder kurzfristig gespeichert werden. Der Zustand von View Objekten einer Activity wird automatisch in einem Bundle (auch Bundle Save Instance genannt) durch Android gespeichert. So gehen beispielsweise beim Ändern der Bildschirmausrichtung die Daten in einem EditText nicht verloren. Dieses Bundle kann bei Bedarf erweitert werden [Creative Commons 2016k]. Kleinere Mengen an Daten können über Key-Value Paare als SharedPreferences in einer Datei gespeichert werden. Diese Daten können anderen Applikationen auf dem Gerät zur Verfügung gestellt werden [Creative Commons 2016l]. Zum Speichern von größeren Mengen an Daten mit einer höheren Komplexität kann eine SQLiteDatabase genutzt werden. Diese wird im lokalen Speicher der Applikation abgelegt und kann nicht durch andere Applikationen ausgelesen werden. Das Datenbankschema wird dabei mit Hilfe einer Contract Klasse aufgesetzt. Sie definiert die Tabellen, Spalten und Felder der Datenbank. Zum Initialisieren und Verwalten der Datenbank kann eine SQLiteOpenHelper Klasse definiert werden. Der Vorteil der Nutzung eines SQLiteOpenHelpers liegt in seinen bereitstehenden Funktionen: Über diesen werden die langfristigen Operationen erst zu dem Zeitpunkt ausgeführt, zu dem sie von dem System gebraucht werden [Creative Commons 2016c]. Müssen Daten durch mehrere Applikationen abrufbar sein, wird dazu ein ContentProvider genutzt. Die genannten Begriffe sind im Glossar erläutert.

Ein wichtiges Konzept in der Android Entwicklung ist der Context, der globale Informationen über die Applikation und ihre Umgebung bereitstellt. Dabei ist beim Context auf verschiedenen Ebenen zu unterscheiden. Der ApplicationContext wird pro Applikation nur einmal instanziiert und gibt die Instanz der Applikation wieder. Dahingegen wird pro Instanz einer Komponente jeweils ein eigener Context erzeugt [Smith 2013]. Dabei gibt es unterschiedliche Methoden zum Aufrufen des Context. Die Herausforderung bei der Entwicklung liegt im Aufruf des richtigen Context an der richtigen Stelle [Muzaffar 31.02.2016].

Eine weitere wichtige Komponente in der Android-Entwicklung ist der BraodcastReceiver. Dieser wird in der vorliegenden Arbeit jedoch nicht verwendet, weswegen er an dieser Stelle nicht näher erläutert wird. Eine Erläuterung ist dennoch im Glossar nachzulesen.

2.1.3 Wichtige Dateien zum Aufbau einer apk

Wie eingangs erläutert werden Android Applikationen bereits auf ihrer Entwicklungsmaschine zu einer apk zusammengefasst. Dieser Aufbau-Prozess wird durch weitere Dateien innerhalb eines Projektes unterstützt. Im Folgenden werden zwei Dateien vorgestellt, welche bei der Entwicklung einer Applikation relevanten Einfluss auf das Vorgehen haben.

Das Android Manifest ist im Root-Verzeichnis eines Projektes zu finden und stellt eine der Dateien dar, die zur Erzeugung der apk mit den dex-Dateien zusammengeführt wird. Das Manifest strukturiert und beschreibt die Applikation selbst und die Bestandteile einer Applikation. Allgemein gesprochen umfasst das Manifest alle Informationen, die das Betriebssystem zur Installation der apk benötigt. Bei der Entwicklung spielt das Manifest eine elementare Rolle, da hier sowohl Activities, als auch Services und ContentProvider definiert werden müssen. Zudem werden hier die Berechtigungen (auch Permissions) definiert, die vom Nutzer bestätigt werden müssen [Creative Commons 2016a]. Dabei ist es seit der APK Version 23 nicht mehr ausreichend die Permissions im Manifest zu deklarieren. Stattdessen sind sogenannte Runtime Permissions zu implementieren, die beim Anwender abgefragt werden, sobald sie durch die App benötigt werden. Eine einmal gegebene Erlaubnis wird abgespeichert und muss nicht noch einmal abgefragt werden (Ausnahmen: manuelles Ändern der Zugriffsberechtigungen durch den Nutzer; Deinstallation). Runtime Permissions müssen neben der Erwähnung im Manifest, explizit durch die Applikation einzeln erfragt werden [nuuneoi 2015]. Die genannten Begriffe, sowie weitere in diesem Zusammenhang erwähnten Definitionen werden im Glossar definiert.

Zum Aufbau der apk wird in Android Gradel verwendet. Gradel automatisiert den Erstellungsprozess der apk, lässt aber eigene Konfigurationen zum Aufbau zu. Zum Konfigurieren müssen zwei build.gradel Dateien berücksichtigt werden: das Top Level Build File, genannt build.gradle (Project: Projektname), und das Module-Level File, genannt build.gradle (Module: App). In der Top-Level Datei werden die Konfigurationen implementiert, die für alle Module im Projekt ihre Gültigkeit besitzen. Das Module-Level File, jeweils abgelegt in einem Modul pro App, stellt eigene Konfigurationen je Modul auf und kann sowohl das Manifest als auch das Top Level Gradle überschreiben. Der Aufbau der apk kann unter anderem in folgenden Punkten konfiguriert werden [Creative Commons 2016r]:

- Product Flavors: Erzeugen verschiedener Varianten einer App. Beispielsweise bei der Erstellung einer kostenfreien Version mit beschränkten Funktionalitäten und einer kostenpflichtigen Version mit erweiterten Funktionalitäten.
- Dependencies: Hinzufügen von Packages und Repositories

Auf weitere Erläuterung der allgemeinen Android Architektur wird an dieser Stelle verzichtet. Es wird noch einmal auf das Glossar verwiesen, welches zu den bereits benannten Begriffen auch weitere zum Verständnis dieser Arbeit beitragende Begriffe umfasst. Dazu zählen unter anderem Adapter, ResultReceiver, PendingIntent und Handler. Werden im Folgenden Besonderheiten auftreten, die einer Erläuterung bedürfen, wird dies an der entsprechenden Stelle nachgeholt. Weiterhin wird auf den Android API Guide verwiesen, der umfangreich und detailliert die Strukturen und Wirkungsweisen von Android erläutert: https://developer.android.com/guide/index.html.

2.2 Vorstellung der Plattform

Die in diesem Kapitel vorgestellten Begriffe und Besonderheiten der Android-Entwicklung werden im folgenden Kapitel durch die Vermittlung von Grundlagen der Bluetooth­Entwicklung erweitert. Auf die in diesem Kapitel verm ittelten Aspekte basiert die in Kapitel 3.4 durchgeführte konkrete Implementierung der Bluetooth-speifischen Teile der Anwendung.

2.3 Einführung in Bluetooth Grundlagen

Die ersten Studien zu Bluetooth wurden bereits 1994 von Ericsson Mobile Communications durchgeführt, um eine Alternative für Kabelverbindung zwischen Handys und ihrem Zubehör zu finden [Bray & Sturm an 2002, S. 2]. Die Bluetooth-Spezifikation wurde nach Harald Blâtand (Blâtand ist die dänische wortwörtliche Übersetzung für Blauzahn) benannt: Einem dänischen König aus dem zehnten Jahrhundert, welcher den sich im Krieg befindlichen Fraktionen Dänemark, Norwegen und Schweden zur Vereinigung half. Als Analogie war das Ziel von Bluetooth die kabellose Verbindung und Zusammenarbeit von unterschiedlichen Produkten [Bluetooth SIG 2016b]. 1998 wurde dafür die Bluetooth Special Interest Group (SIG) gegründet; eine Gruppe von Unternehmen, welche gemeinsam die Bluetooth Entwicklung fördern und Spezifikationen definieren. Zum Gründungszeitpunkt in 1998 gehörten die Unternehmen Ericsson Mobile Communications AB, Intel Corp., IBM Corp., Toshiba Corp. und Nokia Mobile Phones zu den Kernunterstützern. Im Juli 1999 wurde Version 1.0 der Bluetooth Spezifikation veröffentlicht und bereits im Dezember des gleichen Jahres vergrößerte sich die Gruppe der Kernunterstützer um die Unternehmen Microsoft, Lucent, 3COM und Motorola [Bray & Sturman 2002, S. 2 f.].

Seit der Veröffentlichung wird Bluetooth stetig weiterentwickelt und kann für eine Vielzahl von Möglichkeiten eingesetzt werden. In der aktuellen Entwicklung konzentriert sich der Einsatz von Bluetooth jedoch auf zwei konkrete Anwendungsfälle: Einerseits wird Bluetooth dazu genutzt, zwei Endgeräte kabellos miteinander zu verbinden, wie beispielsweise ein Smartphone mit einem Headset oder ein Laptop mit einer kabellosen Maus. Der zweite Anwendungsfall beschränkt sich auf den direkten Austausch von Daten zwischen zwei Endgeräten (z.B. Bilder oder Anwendungsdaten) [Bluetooth SIG 2016b, S. 375].

Bluetooth ist dabei eine eigene N etzwerkstruktur und kann bis zu acht Geräte gleichzeitig in einem Piconetz miteinander verbinden. Ein Piconetz besteht aus einem Master und bis zu sieben Slaves. Besteht ein Netz bereits aus sieben Slaves, kann kein neues Mitglied mehr eingeladen werden [Hopkins & Antony 2003, S. 30 f.]. Dabei kann jedes Endgerät sowohl Master als auch Slave sein. Der Master eines Piconetz ist immer das Endgerät, das das Netz ursprünglich aufgebaut hat und besitzt die Kontrolle darüber, welches Gerät zu welchem Zeitpunkt Daten auf dem Kanal übertragen darf [Sauter 2015, S. 380].

Bei üblichen Bluetooth-Anwendungsfällen, wie beispielsweise die Verbindung eines Smartphones mit einem Headset, müssen sich die Geräte nah beieinander bzw. in einem Radius von 10 Metern befinden [Mednieks & Schulten 2013]. Die mögliche Entfernung der Geräte hängt dabei von der sog. Power Class der Endgeräte ab (s. Tabelle 1).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Bluetooth Power Classes [Hopkins & Antony 2003, S. 16]

Die Power Class eines Gerätes kann in der Regel über eine Faustregel bestimmt werden: Wenn das Gerät Batteriebetrieben oder lediglich Handgroß ist, so handelt es sich üblicherweise um die Power Class 2 oder 3. Zu der Power Class 1 kann ein Gerät gezählt werden, wenn es bspw. in der Hardware einer Anlage integriert ist, die über das Stromnetz betrieben wird [Hopkins & Antony 2003, S. 17].

Seit der damaligen Einführung von Bluetooth wurde die Spezifikation stetig weiterentwickelt und befindet sich aktuell in der Version 4, dem Bluetooth Low Energy. Diese Version soll im folgenden Kapitel näher beschrieben werden. Bluetooth Low Energy 2010 wurde mit der Bluetooth 4.0 Kernspezifikation Bluetooth Low Energy (BLE, auch bekannt als Bluetooth Smart) eingeführt, dessen Ziel es war ein Radio-Standard mit dem niedrigsten möglichen Energieverbrauch zu entwickeln. Diese Version zielt damit insbesondere auf Endgeräte ab, die eine lange Laufzeit haben oder durch ihre Größe beispielsweise nur durch eine Knopfbatterie betrieben werden können und daher stark vom Energieverbrauch abhängig sind.

Obwohl die aktuelle Bluetooth Spezifikation zwar sowohl das klassische Bluetooth als auch Bluetooth Low Energy abdeckt, sind beide Standards nicht direkt kompatibel zueinander. Dies bedeutet, dass Bluetooth Geräte basierend auf der Spezifikation <4.0 nicht mit BLE Geräten kommunizieren können.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Konfiguration und Kompatibilitätder Bluetooth Spezifikationen (angelehntan [Townsend 2014, S. 4])

Tabelle 2 beschreibt die verschiedenen Bluetooth-Typen und ihre Kompatibilität zueinander. Die Werte in den Zellen sagen dabei aus, ob die in der Spalte genannte Bluetooth Version mit der in der Zeile genannten Technologie kompatibel ist. Unterschieden wird dabei zwischen den kabellosen Technologien BR/EDR und BLE. BR/EDR (Basic Rate/Enhanced Data Rate) beschreibt die klassische Bluetooth Spezifikation, auch bekannt als Version 2.1 [Bluetooth SIG 2016c].³ BLE entspricht dem bereits genannten Low Energy-Standard seit der Bluetooth Version 4.0.

Unterschieden wird zusätzlich zwischen den Gerätetypen Single Mode und Dual Mode mit denen die Technologien verwendet werden können. Ein Dual Mode Gerät (auch bezeichnet als Bluetooth Smart Ready) unterstützt sowohl die BLE als auch BR/EDR und kann somit mit jedem Bluetooth-Gerät kommunizieren.

Ein Single Mode Gerät (BLE, Bluetooth Smart) hingegen implementiert den BLE-Standard und kann entsprechend mit anderen BLE-Geräten oder einem Dual-Mode Gerät kommunizieren. Eine Verbindung mit Geräten, die ausschließlich BR/EDR unterstützen, ist nicht möglich [Townsend 2014, S. 3 f.].

Neben dem Verständnis über die verschiedenen Bluetooth Versionen und deren Kompatibilität untereinander, ist es für die Entwicklung mit Bluetooth-Geräten wichtig zu verstehen, wie die Technologie funktioniert. Deshalb wird in den folgenden Abschnitten grundsätzliches Wissen zu der Technologie erläutert, welche im späteren Projektverlauf zum Verständnis benötigt werden.

2.3.1 Protocol Stack

Damit ein Computer, ein Smartphone, o.ä. mit einem Bluetooth-Gerät kommunizieren kann, wird der sogenannte Bluetooth Stack benötigt. Antony und Hopkins nennen an dieser Stelle den passenden Vergleich, dass ein Bluetooth-Gerät ohne Bluetooth Stack wie ein Computer ohne Betriebssystem wäre. Dieser ermöglicht zum einen die Kommunikation aber auch die Steuerung eines Bluetooth-Gerätes.

Abbildung 1 zeigt die Aufteilung des Bluetooth Protocol Stack in Host und Controller. Zwischen diesen beiden Schichten befindet sich das Host Controller Interface (HCI), welches dazu verwendet wird zwischen dem Endgerät (Host) und dem Bluetooth Chip (Controller) Daten und Anweisungen zu übertragen, welche i.d.R. physikalisch voneinander getrennt sind [Sauter 2015, S. 392]. Als oberste Instanz ist die Applikation abgebildet, welche auf den Protocol Stack zugreift und für den Nutzer einen Anwendungszweck erfüllt. Im weiteren Verlauf des Kapitels werden lediglich jene Protokolle genauer erläutert, welche im praktischen Teil der Arbeit benötigt werden. Informationen zu den restlichen Protokollen finden sich in den genannten Quellen von Antony und Hopkins und Townsend.

Abbildung in dieser Leseprobe nicht enthalten

2.4 Attribute Protocol (ATT)

Das Attribute Protocol (ATT) befindet sich oberhalb des L2CAP-Protocols, welches direkt mit dem HCI kommuniziert und für die Datenkonvertierung zum Austausch mit dem Controller verantwortlich ist.

Das Attribute Protocol ist ein Client-Server-Protokoll, welches auf den Attributen basiert, welche vom Bluetooth-Gerät für den Client bereitgestellt werden. Bei BLE ist ein Gerät entweder Client, Server oder sogar beides gleichzeitig - je nachdem, ob es sich um den Master oder den Slave handelt. Der Client kann Attribute entdecken, lesen und schreiben während der Server den Client zusätzlich aktiv über Attribute informieren kann [Gupta, S. 234 f.]. Für die Kommunikation zwischen Client und Server stehen dabei sechs Methoden zur Verfügung: Der Client fragt eine Information per Request beim Server an, welcher daraufhin mit einem Response reagiert. Einen neuen Wert kann der Server per Indication senden, woraufhin der Empfang vom Client mit einer Confirmation bestätigt wird. Ein Kommando kann der Client mit Command an den Server senden - der Server reagiert auf diesen ohne Response. Die Notification wird schließlich vom Server dazu verwendet, einen neuen Wert an den Client zu schicken ohne auf eine Antwort von diesem zu warten [Rudi Latuske 2013]. Im praktischen Einsatz dieser Arbeit werden davon lediglich Request/Response, Notification und Command-Methoden genutzt. Den Anwendungsfall, dass der Server eine Confirm ation vom Client erwartet, gibt es in dieser Arbeit nicht.

Attribute im Bluetooth Protocol Stack repräsentieren jegliche Art von Daten, die ein Bluetooth-Gerät an andere Geräte mitteilen möchte - beispielsweise den Gerätenamen oder Batteriestatus. Die Aufgabe des ATT Protokolls ist dabei, diese Daten zu erhalten oder zu senden und unterstützt gleichzeitig eine Möglichkeit zur Benachrichtigung, sodass ein verbundenes Gerät aktiv über Datenveränderungen informiert werden kann.

Ein Attribut besteht aus den drei Elementen: dem Typ, dem Handler, den Berechtigungen und dem konkreten Wert.

Der Typ legt die Art des Attributs fest und dient für den Client zum besseren Verständnis des Attributs. Ein Typ besteht dabei aus einem Universally Unique Identifier (UUID) - einem 16- oder 128-bit Wert, welcher über die Laufzeit eines Programms hinweg eindeutig ist. Ein Bluetooth-Gerät kann dabei von der Bluetooth SIG vordefinierte UUIDs implementieren oder eigene UUIDs bereitstellen.

Der Attribute Handler wird vom Client benötigt, um die Attribute des Servers zuordnen und auf diese zugreifen zu können, da jedes Attribut einem Handler zugewiesen ist. Beim Entfernen oder Hinzufügen eines Attributs auf dem Server darf dabei kein Handler verwendet werden, welcher zu jeglicher Zeit vom Client für ein anderes Attribut verwendet wurde. So kann der Client auf ein Attribut immer mit dem gleichen Handler zugreifen.

Bei den Berechtigungen wird unterschieden zwischen den Zugriffs-, den Authentifikations­und den Authorisierungsberechtigungen. Die Zugriffsberechtigungen definieren, ob ein Client ein Attribut Lesen und/oder Schreiben darf. Die Authentifikationsberechtigungen geben an, ob eine authentifizierte physikalische Verbindung für den Zugriff auf ein Attribut vorhanden sein muss. Die Authorisierungsberechtigung definiert schließlich, ob der Client für die Nutzung des Attributs allgemein zugelassen ist.

Zuletzt besteht ein Attribut aus dem eigentlichen Wert, welcher an den Client übertragen werden soll. Beispielsweise den tatsächlichen Batteriestatus des Bluetooth-Geräts [Gupta, S. 234 f.].

2.5 Generic Attribute Profile (GATT)

Das Generic Attribute Profile (GATT) basiert auf der ATT-Schicht und definiert einerseits die Rollen (Client und Server) der beteiligten Geräte: Der GATT Server speichert die Daten, welche über das Attribute Protocol transportiert werden und nimmt Anfragen und Anweisungen vom GATT Client an und beantwortet diese. Andererseits wird detailliert definiert wie die Daten, die über die BLE Verbindung übertragen werden sollen, formatiert und gepackt sein müssen und werden nach den Vorgaben des GATT gesendet [Townsend 2014, S. 51]. Zwei Bluetooth-Geräte können nur miteinander kommunizieren, wenn sie die gleichen Profile implementiert haben [VSN Mobil 2014, S. 2]. werden ausschließlich von Servern bereitgestellt und können gleichzeitig von mehreren Clients verwendet werden, welche selbst keine Services besitzen [Rudi Latuske 2013].

Ein Service fasst mehrere Attribute zusammen, die konzeptionell zusammengehören und gleichzeitig die Service Definition darstellen. Jede Service Definition beginnt mit einem einzigen Attribut, welcher den Beginn des Services kennzeichnet und stellt damit die Service Deklaration dar. Hierbei wird unterschieden zwischen einem primären und einem sekundären Service, wobei die primären Services einen konkreten Zweck für das Bluetooth Gerät erfüllen während sekundäre Services lediglich als Hilfsservices verwendet und von einem primären Service referenziert werden. In der Praxis kommen sekundäre Services selten zum Einsatz [Townsend 2014, S. 58].

Ein Service selbst besteht aus verschiedenen Characteristics, welche als sog. Behälter für Nutzerdaten verstanden werden können. Ein Characteristic besteht aus einer Deklaration, einem Wert und optional aus einem oder mehreren Descriptoren. Dabei ist jedes dieser Elemente analog zum Attribut des ATT aufgebaut und enthält einen Handler, einen Typ, einen Wert und die Berechtigungen.

Die Deklaration des Characteristics beinhaltet Metadaten über die aktuellen Nutzerdaten und definiert die übermittelten Informationen somit im Allgemeinen. Der Typ der Deklaration entspricht der UUID des Characteristics. Der Wert enthält die Eigenschaften des Characteristics und gibt an wie das Characteristic genutzt werden kann (z.B. ob es gelesen und geschrieben werden kann oder ob der Client vom Server benachrichtigt werden kann).

Die Definition des Wertes eines Characteristics beschreibt den tatsächlichen Wert, also die konkreten Nutzerdaten. Während die Berechtigungen der Deklaration eines Characteristics vom GATT selbst festgelegt werden, werden die Berechtigungen des Wertes von der höher liegenden Schicht des Protokolls bestimmt. Das hat den Vorteil, dass ein Client somit immer die vom Gerät bereitgestellten Services und Characteristics einsehen aber nicht unbedingt lesen oder schreiben kann. Diese Definition ist der höher liegenden Schicht überlassen.

Der optionale Descriptor dient zur Erweiterung des Characteristic Wertes, womit ein Characteristic auch mehrere Descriptoren enthalten kann. Beispielsweise kann ein Descriptor des Characteristics des Batteriestatus eine nutzerfreundliche Ergänzung des Wertes „93“ um einen Text „Prozent Akku“ beinhalten.

Wie im Abschnitt 2.4 bereits erwähnt, gibt es eine Reihe von Services, die durch die Bluetooth SIG definiert und bereitgestellt werden. Dazu gehört beispielsweise die Abfrage des Batteriestatus mit dem „Battery Service“ oder die Abfrage der Geräteinformationen mit dem „Device Information“-Service. Alle von der Bluetooth SIG bereitgestellten Services sind unter der URL https://www.bluetooth.com/specifications/gatt/services aufzurufen. Hierbei wird in der dritten Spalte eine „Assigned Number“ angegeben und entspricht der 16-Bit UUID. Aus dieser lässt sich die 128-Bit UUID ermitteln, indem der Platzhalter xxxx in der 128-Bit UUID 0000xxxx-0000-1000-8000-00805f9b34fb mit der 16-Bit UUID ersetzt wird [Gupta, S. 273 f.]. Je Service lassen sich auf deren Beschreibungsseite die benötigten Characteristics mit den entsprechenden UUIDs und ggf. benötigten Werten finden.

Der für Watchdog verwendete Bluetooth-Button implementiert folgende von der Bluetooth SIG bereitgestellten Services: Den Device Information Service, den Battery Service, den Immediate Alert Service und den Link Loss Service. Die in der Implementierung (vgl. Kapitel 3.4) verwendeten Services werden im Folgenden kurz erläutert.

Tabelle 3 beschreibt den Battery Service, welcher benötigt wird, um den Batteriestatus eines Bluetooth-Gerätes abfragen zu können. Das Characteristic „Battery Level“ enthält einen entsprechenden Wert von 0 bis 100, welche den prozentualen Batteriestatus beschreibt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Bluetooth Service - Battery Service

Der Immediate Alert Service löst einen Alarmton im Bluetooth-Gerät aus. Beim Link Loss Service wird dieser Alarmton ausgesteuert, sobald die Verbindung zum gekoppelten Gerät verloren geht. Beide Services nutzen dasselbe Characteristic mit der Assigned Number 0x2A06. Je nachdem mit welchem Wert das Characteristic geschrieben wird, können bei beiden Funktionen unterschiedliche Intensitäten des Alarmtons ausgelöst werden (vgl. Tabelle 4).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Bluetooth Services - Immediate Alert und Link Loss

Der im weiteren Verlauf der Arbeit verwendete Bluetooth-Button nutzt die Bedeutung dieser Werte je Service in einer eigens definierte Form, welche später in Kapitel 3.3.3 näher erläutert wird.

2.6 Generic Access Profile (GAP)

Das Generic Access Profie (GAP) definiert, wie zwei verschiedene Geräte miteinander in Verbindung treten und sich dabei verhalten sollen. Dabei wird von dem Profil definiert, wie Bluetooth spezifische Parameter (wie beispielsweise der Geräteadresse) dargestellt werden und welche Sicherheitsaspekte zu erfüllen und zu verwenden sind. Ebenso wird festgelegt, wie sich das Gerät bei der Suche nach weiteren Bluetooth-Geräten und beim Verbindungsaufbau zu verhalten hat. Es ist genau festgehalten, welche Aktionen und Nachrichten in welcher Reihenfolge von den Geräten zugeführt werden müssen. Gleichzeitig wird für den Nutzer eine hohe Bedienungsfreundlichkeit gesichert, da auch unterschiedliche Geräte in ihrem User Interface ähnlich zu bedienen sein werden [Sauter 2015, S. 411].

2.7 Bluetooth in Android

Da sich auch die meisten Android Geräte mit Bluetooth-Geräten verbinden können, bietet Android eine API an, um Bluetooth-Funktionalitäten verwenden zu können. Dabei unterstützt die API sowohl klassische Bluetooth-Geräte als auch Bluetooth Low Energy. Die API stellt auch die Möglichkeit zur Verfügung, dass es sich bei einer App sowohl um einen GATT Client oder einen GATT Server handeln kann [Creative Commons 2016e].

Zur allgemeinen Verwaltung aller Bluetooth-Funktionen des Smartphones gibt es den BluetoothManager, welcher als Bluetooth-Service im System vorhanden ist. Aus dem BluetoothManager lässt sich der BluetoothAdapter mit der Methode getAdapter() ableiten [Creative Commons 2016d].

Der BluetoothAdapter ermöglicht es, grundlegende Bluetooth-Funktionen nutzen zu können. Dazu gehört einerseits das Suchen nach weiteren Bluetooth-Geräten. Die Suche nach klassischen Bluetooth-Geräten wird durch den Aufruf der Methode startDiscovery() ausgelöst. Wird bei der Suche explizit nach Bluetooth Low Energy Geräten Ausschau gehalten, wird die Methode startLeScan(LeScanCallback) verwendet. Bei dem Rückgabeparameter handelt es sich hierbei um jene Bluetooth LE Geräte, die bei der Suche gefunden werden konnten [Creative Commons 2016f].

Um mit einem Bluetooth-Gerät kommunizieren zu können, wird die Android Klasse BluetoothGatt benötigt. Diese stellt die Schnittstelle zum in Kapitel 2.5 erläutertem Bluetooth GATT Profile. Die Klasse BluetoothGatt stellt eine Vielzahl von Methoden bereit, um mit dem Bluetooth-Gerät kommunizieren zu können. Hierzu gehören beispielsweise die Methoden connect() und disconnects, um die Verbindung zu dem Bluetooth-Gerät verwalten zu können. Ebenso können durch die Methode getServices() alle vom Bluetooth-Gerät bereitgestellten Services eingesehen sowie einzelne Services über getService(UUID uuid) durch die Übergabe der UUID als Parameter verwendet werden. Für spätere Erläuterungen in dieser Arbeit sind insbesondere auch die Methoden readCharacteristic() und writeCharacteristic() relevant, um mit dem gekoppelten Bluetooth-Gerät kommunizieren zu können [Creative Commons 2016j]. Die gesamte Liste der von der Android API bereitgestellten Methoden des GATT Profils können unter folgendem Link eingesehen werden: https://developer.android.com/reference/android/bluetooth/BluetoothGatt.html

Damit eine Applikation auf die Bluetooth-Funktion des Telefons zugreifen darf, muss vom Nutzer die Berechtigungen „BLUETOOTH“ und „ BLUETOOTH_ADMIN“ akzeptiert werden. Die Berechtigung BLUETOOTH erlaubt dem Smartphone sich mit bereits gefundenen Smartphones zu koppeln. BLUETOOTH_ADMIN erweitert diese Funktion um die Fähigkeit, Bluetooth-Geräte in der Umgebung auffinden zu dürfen [Creative Commons 2016n].

Ab der Android Version 6.0 wird für die Nutzung der Bluetooth-Funktionalität zusätzlich die Lokalisierungs-Berechtigung benötigt (ACCESS_COARSE_LOCATION), sodass auch diese freigegeben werden muss [Shweta Shetty 2016].

Mit diesem Abschnitt wird die Vermittlung der Grundlagen zur Bluetooth-Entwicklung abgeschlossen. Im folgenden Kapitel wird nun auf die Vorstellung verschiedener Kommerzialisierungsstrategien eingegangen, welche in Kapitel 4 mit praktischem Bezug erneut analysiert werden.

2.8 Kommerzialisierungsstrategien

Die bei der Entwicklung von Apps entstehenden Ausgaben, wie etwa Personalkosten, aber auch laufende Kosten, wie zum Beispiel die Mietgebühr eines Servers, müssen bestenfalls durch Einnahmen der App gedeckt werden. Dafür gibt es verschiedene Strategien zur Monetarisierung von Apps:

- Kostenlose App, die sich über Werbung finanziert
- Freemium (Kombination aus einer Free- und einer Premium-Version)
- In-App-Käufe (Kostenloser Download der App mit kostenpflichtigen Inhalten)
- Abo-Modell (monatlich, jährlich)
- Kostenpflichtige App

Die Wahl einer geeigneten Strategie zum Vertrieb einer App ist dabei nicht nur abhängig von der Applikation selbst. Gleichzeitig sollten auch das Marktumfeld und das Nutzerverhalten berücksichtigt werden. Sind Nutzer überhaupt bereit dazu, für eine App Geld auszugeben? In einer Studie zu dem Thema Paid Content-Nutzung gaben 35,8% der Befragten an im Google Play Store bereits für einen Service oder einen Inhalt gezahlt zu haben [HS Fresenius & DCI Institute 2016]. Eine weitere Studie aus dem Jahr 2015 ergab, dass 34,24% der mobilen Internetnutzer in Deutschland schon einmal eine kostenlose App heruntergeladen hätten, wobei nur 12,95% bereits eine kostenpflichtige App gekauft hätten [IfD Allensbach 2016]. Die Bereitschaft der Nutzer eine kostenlose App herunterzuladen ist demnach knapp dreimal höher, als für eine App Geld zu bezahlen. Damit eine schnelle und weite Verbreitung der App erzielt werden kann, eignet sich ein kostenfreier Download besser.

In den folgenden Abschnitten werden die eingangs genannten Strategien zur Monetarisierung von Apps vorgestellt und erläutert.

2.8.1 Kostenlose Apps / Werbung

Wie eingangs dargelegt, gestaltet sich die Verbreitung einer App, die kostenfrei zum Download angeboten wird, einfacher als bei einer kostenpflichtigen. Die entstehenden Kosten sind hierbei anderweitig zu decken. Eine weit verbreitete Strategie hierbei ist das Schalten von Werbebannern [ecommerce magazin 2011]. Dabei können die Banner möglichst prominent am unteren oder oberen Rand der App platziert werden. Alternativ dazu kann die Werbung in der Zeit angezeigt werden, in der die App im Hintergrund noch startet und der eigentliche „Startbildschirm“ angezeigt wird [IfD Allensbach 2016]. Über Affiliate Netzwerke werden diese Bannerflächen an möglichst passende Werbende vergeben. Die gängigste Verrechnungsmethode ist der Tausenderkontaktpreis. Hier erhält der Betreiber der Applikation einen Betrag, sobald die Werbung an 1.000 Nutzer sichtbar ausgespielt wurde (1.000 Ad Impressions). Eine weitere Verrechnungsmethode basiert auf der „Click -Through- Rate“. Dabei wird die Provision erst ausgezahlt, wenn ein Anwender das Banner geklickt hat [ecommerce magazin 2011]. Neben diesen Verrechnungsmodellen werden in der Praxis weitere Modelle eingesetzt, beispielsweise die Verrechnung auf Basis der Conversion Rate.

Der Inhalt der ausgesteuerten Werbeflächen sollte sich dabei möglichst optimal an den Interessen der Nutzer der App orientieren. Orientierung dazu geben einerseits gesammelte Nutzerdaten. Ein anderer Anhaltspunkt stellt der in der App angezeigte Content dar. Durch die Einbeziehung beider Quellen und daraus abgeleiteten passenden Werbeanzeigen soll eine möglichst hohe Relevanz für den Anwender geschaffen werden [ecommerce magazin 2011]. Besonders bei dem Verrechnungsmodell auf Basis der Click-Through-Rate ist dies zu berücksichtigen, da der Nutzer zum Klicken auf das Banner animiert werden soll.

2.8.2 Freemium / Abo-Modell

Die bereits genannte Hürde des Anwenders, direkt eine kostenpflichtige App herunterzuladen, kann dem potentiellen App-Käufer durch das Angebot der App in zweifacher Version im Play Store genommen werden: eine Free-Version und eine Premium­Version. Die Free-Version ist eine kostenfreie Version der App, welche lediglich einen reduzierten Funktionsumfang enthält. Hierdurch hat der Nutzer die Möglichkeit, alle grundlegenden Funktionen der App kennenzulernen und auszuprobieren. Alle weiteren Funktionen kann der dieser zwar einsehen, aber nicht benutzten. Hierdurch soll die Neugierde auf die Premium-Version bestenfalls geweckt werden. Eine Freischaltung dieser Funktionen erfolgt erst mit dem Kauf der Premium-Version bzw. durch das Einrichten eines Premium-Kontos. Der Name für diese Strategie leitet sich daher auch aus einem Wortspiel beider Strategien ab: Free und Premium vereinigt sich zu Freemium [Matzner 2011]. Die Herausforderung in dieser Strategie liegt darin, den Funktionsumfang der Free- gegenüber dem der Premium-Version richtig abzuwägen [Jakob von Pechmann 2011].

Ein Beispiel für das Angebot von zwei verschiedenen Varianten im Play Store ist die App blitzer.de. Wie in Abbildung 3 und Abbildung 4 abgebildet, werden im Play Store zwei Apps angeboten, welche zu unterschiedlichen Preisen zu erhalten sind und einen unterschiedlich viele Funktionen umfassen. Beispielsweise enthält die Premium-Version ein Widget-Modus, welcher in der Free-Version nicht verfügbar ist. Zudem wird in der Premium-Version keine Werbung ausgespielt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4:App blitzer.de Premium-Version (Herausgeber: Eifrig Media GmbH)

Ein weiteres Beispiel für dieses Verrechnungsmodell ist der Musikstreaming-Dienst Spotify.

Die App ist kostenfrei aus dem Play Store herunterzuladen und kann direkt genutzt werden.

Dabei werden beim Abspielen der Musik regelmäßig Werbespots eingespielt. Die Premiumversion hingegen ist werbefrei und liefert diverse zusätzliche Funktionen, wie das Hören von Musik im Offline Modus oder das Angebot einer höheren Soundqualität [Spotify AG 2016]. Die Preise der Premium-Version werden hierbei nach einem Abo-Modell berechnet. Bei einem Abo-Modell handelt es sich nicht um einen einmaligen Kauf der Premium-Version, sondern um das regelmäßige Zahlen einer Gebühr, wodurch die Premium-Funktionen für eine weitere Periode freigeschaltet werden. In einem monatlichen Abo werden dabei meist geringere Beträge abgebucht. Die Kündigungsfrist beläuft sich im Regelfall auf die Dauer der Abo-Periode. Damit sinkt die Hemmschwelle beim Nutzer, denn er muss sich nicht auf eine lange Bindung einlassen sondern kann das Abonnement nach kurzer Zeit bei Bedarf kündigen. Bei der Preisgestaltung ist eine Staffelung der Länge des Abonnements möglich. Dabei müssen Nutzer, die sich für eine kürzere Abo-Laufzeit entscheiden einen höheren Preis zahlen, als diejenigen, die ein langfristiges Abo abschließen. Mit dem niedrigeren Preis soll die lange Laufzeit des Abos attraktiver werden. Lange Abos lohnen sich für den Betreiber dabei deswegen, weil die Einnahmen langfristig gesichert sind. Ein Beispiel hierfür ist das Abo-Modell der Fitness App Freeletics Running (s. Abbildung 5).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Abo-Modell der App Freeletics (Herausgeber: Freeletics)

Die App ist auch hier in der ersten Version kostenfrei im Play Store verfügbar. In dieser Free­Version steht jedoch nur eine beschränkte Anzahl von Workouts zur Verfügung. Um auf alle Workouts zugreifen zu können und einen individuellen Trainingsplan zu erhalten, ist der Kauf der Premium-Version notwendig - hier „Coach“ genannt. Der Abschluss des Coaches erfolgt in einem Abo-Modell mit gestaffelten Preisen: Für eine längere Laufzeit des Abos wird eine geringere monatliche Gebühr fällig. Eine Kündigung dieses Abos ist nur in den gebuchten Zeitabständen möglich [Freeletics GmbH].

2.8.3 In-App-Käufe

Eine ähnliche Variante ist die Anreicherung der App durch I n-App-Käufe. Auch hier ist die Anwendung kostenfrei im Play Store verfügbar. Dafür kann der Anwender für meist geringe Beträge Funktionen und Content freischalten oder virtuelle Güter kaufen. Hier ist es demnach nicht möglich durch eine einmalige Zahlung den gesamten Inhalt zu erhalten. In- App-Käufe sind besonders verbreitet in der mobilen Spiele Branche. Sowohl die In-App­Währung, als auch virtuelle Zeit oder besondere Designs können hier per In-App-Kauf erworben werden [Matzner 2011]. Im Apple App Store wurden im Jahr 2014 für das iPhone 85% des Umsatzes durch kostenfreie Apps mit integrierten In-App-Verkäufen erwirtschaftet [Calinescu 2014].

Ein Beispiel aus einer weiteren Branche zur Nutzung der In-App-Käufe ist die Dating-App „Once“. Kostenfrei erhält ein Nutzer einen „Dating-Vorschlag“ pro Tag. Mit virtuellen Kronen, der In-App-Währung, kann der Anwender sich zusätzliche Vorschläge am Tag kaufen. Die Kronen können mit realem Geld erworben werden. Die Preisgestaltung der Kronen richtet sich nach einem gestaffelten Preismodell (s. Abbildung 6).

2.8.4 Kostenpflichtige App

Die letzte Variante ist die Strategie der kostenpflichtigen App. Die App kann nur gegen die Zahlung einer meist geringen Gebühr aus dem App-Store heruntergeladen werden. Zu beachten ist hierbei vor allem die Preiselastizität - im Jahr 2014 hat eine App im App Store durchschnittlich 1,95$ gekostet [Trefis.com 2016]. Das ist ein relativ kleiner Betrag, der pro Nutzer nur einmal erbracht wird. Im Umkehrschluss bedeutet dies aber auch, dass zur Kostendeckung eine hohe Verbreitung bzw. hoher Absatz der App erforderlich ist, da andernfalls eine Unterdeckung der Kosten zu befürchten ist. Zudem ist es schwierig über Einmalzahlung Fixkosten zu decken, die Nutzerunabhängig anfallen. Erschwert wird dieses Konzept durch die einleitend genannte Hürde des Anwenders, eine kostenpflichtige App herunterzuladen ohne diese im Voraus testen zu können. Dieses Modell empfiehlt sich daher generell eher bei Apps, die geringe Kosten in der Entwicklung verursacht haben und keine laufenden Kosten erzeugen.

3 Hauptteil

Der Hauptteil der vorliegenden Arbeit umfasst unter anderem die Bereiche Analyse, Design und Implementierung. Zunächst wird die App hinsichtlich ihrer Anforderungen und Funktionen untersucht. Anschließend werden diese mit Lösungen verglichen, die bereits auf dem Markt erhältlich sind, um einen Überblick über potentielle Wettbewerber zu geben. Das konzeptionelle Design dient zur endgültigen Vorbereitung der Implementierung, welche im Anschluss daran durchgeführt wird. Das Kapitel wird mit einem Test der entwickelten Komponente unter realen Bedingungen und einer Bewertung der Tauglichkeit abgeschlossen.

3.1 Analyse

Der Analyseteil des Hauptteils dient zur detaillierten Ausarbeitung der App-Idee inklusiver der zu erfüllenden Anwendungsfälle sowie der Darstellung der Aktivitäten und funktionalen Anforderungen. Hieraus leiten sich die Anforderungen an den verwendeten Bluetooth-Button ab. Abgeschlossen wird das Kapitel durch die Erweiterung der Funktionen um eine mögliche zukünftige Ausbaustufe sowie der Herausarbeitung von nicht-funktionalen Anforderungen.

3.1.1 Beschreibung der App-Idee

Watchdog ist eine Anwendung für Android Smartphones, die eine sog. „Gefahrenperson“ auf ihrem Heimweg begleitet und ein Gefühl von Sicherheit vermitteln soll. Eine Gefahrenperson ist ein Anwender der App, welcher sich auf einen sicheren Heimweg begeben möchte. Dabei wird sie von der sog. „Vertrauensperson“ begleitet, welche die GPS-Koordinaten empfängt und zum Beobachten der Route berechtigt ist. Gleichzeitig wird sie über eine mögliche Notsituation per SMS oder Anruf informiert.

Die Vertrauensperson kann aus den bereits bestehenden Kontakten im Adressbuch gewählt werden oder durch die Angabe von Name und Telefonnummer schnell hinzugefügt werden. Anschließend wird die Adresse - in der Regel das eigene zu Hause - definiert, um die Route des Heimwegs festlegen zu können. Hat die Vertrauensperson die Watchdog-App ebenfalls installiert, kann sie die Gefahrenperson virtuell über ein GPS-Tracking auf ihrem Heimweg begleiten und beobachten, ob die angegebene Route weiterhin eingehalten oder der Weg verlassen wird. Erreicht die Gefahrenperson das angegebene Ziel, wird die Vertrauensperson über eine automatische Nachricht über das Ereignis informiert.

Zusätzlich können von der Gefahrenperson vordefinierte Nachrichten auch manuell per Knopfdruck an die Vertrauensperson gesendet werden - insbesondere die Nachrichten, die die Vertrauensperson über den aktuellen Status informieren. Hierzu gibt es einerseits eine Notfall-Nachricht, die der Vertrauensperson mitteilt, dass eine mögliche Gefahr besteht.

Andererseits eine „mir geht es gut“-Nachricht, welche einen positiven Status vermittelt (um ggf. auch eine irrtümlich abgesendete Notfall-Nachricht zu revidieren). Beide Nachrichten enthalten neben dem individuell definierbaren Text auch die aktuellen GPS-Koordinaten der Gefahrenperson. Diese dienen als zusätzliche Information, um die Sicherheit der Gefahrenperson zu erhöhen. Hat die Vertrauensperson die App nicht installiert, kann die Route nicht verfolgt werden. Trotzdem kann diese Person als Vertrauensperson definiert und per SMS-Nachrichten über den aktuellen Status und die GPS-Koordinaten informiert werden.

Neben dem Versenden von Nachrichten hat die Gefahrenperson die Möglichkeit, über die Watchdog-App einen Notruf an die definierte Vertrauensperson abzusetzen, sodass diese direkt kontaktiert werden kann.

Watchdog berücksichtigt dabei gleichzeitig die Tatsache, dass es in bestimmten Situationen nicht hilfreich ist, das Smartphone die gesamte Zeit über in der Hand zu halten. Besonders auf leeren Straßen kann das ein zusätzlicher Anreiz sein, überfallen zu werden und möchte von Watchdog nicht provoziert werden. Aus diesem Grund ist Watchdog mit einem Bluetooth-Button kompatibel, der beispielsweise in der Hand gehalten oder um den Hals getragen werden kann, sodass Aktionen in der App unauffällig ausgelöst werden können. Hierfür bietet der Button die Möglichkeit, zwei verschiedene Aktionen auszusteuern. Eine Aktion kann auf das kurze Drücken des Buttons gelegt werden, eine weitere Aktion auf das lange Drücken des Buttons.

Diese Aktionen können in der Watchdog-App im Voraus vom Nutzer selbst definiert werden.

Bei der Konfiguration des Buttons kann aus folgenden Funktionen gewählt werden:

- Senden der Notfall-Nachricht an die Vertrauensperson
- Senden der „mir geht es gut“-Nachricht an die Vertrauensperson
- Absetzen eines Notrufs an die Vertrauensperson
- Auslösen eines 20-Sekündigen Alarms im Button

Beispielsweise kann über das kurze Drücken des Buttons eine Notfall-Nachricht ausgelöst und diese über das lange Drücken des Buttons wieder revidiert werden, falls diese versehentlich von der Gefahrenperson ausgelöst wurde. Die Kombination der Aktion­Konfiguration steht dem Nutzer zur freien Verfügung.

Eine Batterieanzeige informiert zu jeder Zeit über den aktuellen Batteriestatus des Buttons, um eine Ausfall des Buttons zu vermeiden. Diese Anzeige kann vom Nutzer regelmäßig aktualisiert und eingesehen werden. Eine manuelle Batterieanzeige ist an dieser Stelle deswegen vorgesehen, damit diese Anfrage im Button nur bei Bedarf durchgeführt und die Batterie durch die regelmäßige Statusabfrage nicht unnötig beansprucht wird. Wird die Verbindung zwischen Button und Smartphone getrennt, gibt der Button ein hörbares Signal von sich, um den Nutzer auf die Verbindungstrennung aufmerksam zu machen.

Für eine genauere Analyse werden im folgenden Abschnitt aus der grundlegenden Beschreibung der Funktionen konkrete Anwendungsfälle definiert.

3.1.2 Beschreibung der Anwendungsfälle

Bei der Identifikation der Anwendungsfälle (Use Cases) geht es in erster Linie darum, die Aufgaben zu definieren, die die zu entwickelnde Software erfüllen soll. Dabei handelt es sich um komplette Prozesse, die von der App abgedeckt werden und nicht um Teilprozesse. Die einzelnen Prozesse haben einen Anfang und liefern ein eindeutiges Ergebnis [Creative Commons 2016r, S. 63]. In diesem Abschnitt werden zunächst alle Use Cases in einem Use Case Diagramm definiert, um hiermit eine Übersicht über alle abgedeckten Anwendungsfälle der App zu vermitteln. Anschließend wird jeder Use Case in einer detaillierten Anwendungsfallbeschreibung analysiert. Als Vorlage der Dokumentation der Use Cases wird die von Stephan Kleuker beschriebene Schablone [Stephan Kleuker 2013, S. 68] zur Beschreibung von Use Cases verwendet. Dabei wird diese an die Anforderungen der Applikation Watchdog modifiziert.

In Abbildung 7 sind die Haupt-Anwendungsfälle aufgezeigt, die die App Watchdog erfüllt. Insbesondere ist hier zu beachten, dass die Use Cases „Heimweg antreten“ und „Gefahrenperson begleiten“ in einer <<include>>-Beziehung zur Verwaltung des Kontos stehen. Das ist darin begründet, dass ein Nutzer mit seinem Google-Konto in der App angemeldet sein muss, um die genannten Anwendungsfälle nutzen zu können.

Um die Grundfunktion der App verwenden zu können - den Heimweg anzutreten oder eine Gefahrenperson zu beobachten - muss sich ein Nutzer der App mit seinem Google-Konto anmelden. Zudem kann sich der Anwender wieder ausloggen oder sein Konto komplett löschen. Dieser Anwendungsfall ist in Tabelle 5 abgebildet.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Use Case "Konto verwalten"

Der Kernanwendungsfall und damit der wichtigste von Watchdog ist der, dass eine Gefahrenperson ihren Heimweg antritt. Tabelle 6 beschreibt diesen Use Case im Detail.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Use Case "Heimwegantreten"

Damit der im Voraus erläuterte Anwendungsfall 02 erfüllt werden kann, ist dieser von der Existenz einer Vertrauensperson abhängig. In Tabelle 7 ist der dazugehörige Use Case erläutert, dass eine Vertrauensperson die Gefahrenperson begleiten möchte. Hierbei sind die verschiedenen Abläufe je nach gegebener Bedingung zu beachten: Hat die Vertrauensperson die App selbst auf dem Smartphone installiert, können von dieser mehr Prozessschritte durchgeführt werden, als wenn die Person die App nicht installiert hat. Der Unterschied dieser Bedingung wird durch die Aufteilung der Anwendungsfälle in den Anwendungsfall 03A „Gefahrenperson mit App begleiten“ (vgl. Tabelle 7) und 03B „Gefahrenperson ohne App begleiten“ (vgl. Tabelle 8) aufgeteilt und differenziert betrachtet.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7: Use Case" Gefahren person mit App begleiten"

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 8: Use Case „Gefahrenperson ohne App begleiten“

[...]

---

¹ Framewo rks werden in der Softwareproduktion als Programmiergerüste verwendet [Creative Commons 2016k]. Weitere Beispiele für hybride Frameworks sind unter http://t3n.de/news/hybride- app-entwicklung-frameworks-617199/ aufgeführt und werden an dieser Stelle aufgrund der Irrelevanz nicht weiter diskutiert.

² Diese sind in der Android Entwicklung in der Regel mit anderen Begriffen belegt und werden im weiteren Verlauf des Kapitels näher erläutert.

³ Auf diese Version wird an dieser Stelle nicht näher eingegangen, weitere Informationen können unter https://www.bluetooth.com/what-is-bluetooth-technology/bluetooth-technology-basics/br-edr eingesehen werden.