Entwicklung einer Android-Anwendung fürdas Classroom Response System StuReSy

Irmo Timmann11.02.2013

Bachelorarbeit

in der Arbeitsgruppe Sotwaretechnik (SWT)

im Wintersemester 2012/2013

Erstgutachter/in: Dr. Axel Schmolitzky (Universität Hamburg)Zweitgutachter/in: Prof. Dr. Heinz Züllighoven (Universität Hamburg)

Betreuung: Dr. Axel Schmolitzky

von: Irmo TimmannEmail: 9timmann@informatik.uni-hamburg.de

Studiengang: B.Sc. InformatikMatrikelnummer: 6112807

7. Fachsemester

Bachelorarbeit im Wintersemester 2012/2013Universität Hamburg

Fakultät für Mathematik, Informatik und NaturwissenschaftenFachbereich Informatik

Fachbereichsleiter: Prof. Dr. Ingrid Schirmer

Abstract

Der gewöhnliche Vorlesungsbetrieb an deutschen Hochschulen findet für Studenten ineinseitiger Richtung statt. Diese müssen das gesprochene und eventuell durch Folien unter-stützte Wort aufnehmen und verarbeiten. Der Inhalt wird oft nur oberflächlich verstanden.Abhilfe schafft der Peer Instruction Ansatz von Eric Mazur [Mazur, 1997], der Studentenmehr in die Vorlesung einbindet, fordert und den Lernerfolg erhöht. Dieser wurde vonWolf Posdorfer in dem prototypischen Audience Response System (ARS) StuReSy fürAb- und Umfragen an die Studenten umgesetzt [Posdorfer, 2012]. Diese Bachelorarbeitbeschreibt den Analyse- und Verbesserungsprozess zu einer nativen Android-Applikation,die auf mobilen Geräten läuft und das Softwareprojekt StuReSy unterstützt. Es wird be-leuchtet warum Android für dieses Projekt und zukünftige unter anderem universitäreProjekte in besonderem Maße geeignet ist und welche Besonderheiten bei der Entwick-lung beachtet werden müssen. Die genutzten Software-Konzepte und Bibliotheken werdenerläutert, sowie Implementationsdetails zu zwei Bereichen der Applikation näher erläu-tert. Abschließend werden die im Feldtest der prototypischen Android-Anwendung undder darauf folgenden Umfrage erhaltenen Rückmeldungen analysiert und interpretiert.

I

Inhaltsverzeichnis

1. Einleitung 11.1. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. Interaktive Vorlesungen Systeme 32.1. ARS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2. H-ITT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3. Student Response System (StuReSy) 43.1. Fragen erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2. Abstimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3. Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4. Zusatzfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.5. Analyse der Nutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4. Android 84.1. Wahl des Betriebssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.2. Android Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3. Dalvik Virtuell Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.4. Oberflächenkonzept Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.4.1. Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.4.2. Viewgroup und Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.4.3. Fragmente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.4.4. Intents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.4.5. ActionBar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.5. Fragmentierung von Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.5.1. Displaygröße und Auflösung . . . . . . . . . . . . . . . . . . . . . . . . . 174.5.2. Hardware-Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . 174.5.3. Betriebssystem-Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.5.4. Custom-Roms und herstellerspezifische Versionen . . . . . . . . . . . . . 194.5.5. Folgen für die Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.6. Netzwerkverbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.6.1. Multitasking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.7. Berechtigungssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5. Prototyping der mobilen StuReSy Anwendung 275.1. Verbesserungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2. Mock-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

II

6. Bibliotheken, Frameworks und genutzte Programme 336.1. ActionBarSherlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2. Application Crash Report for Android (ACRA) . . . . . . . . . . . . . . . . . . 336.3. ZXing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.4. JavaScript Object Notation (JSON) . . . . . . . . . . . . . . . . . . . . . . . . 346.5. Lizenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.6. Genutzte Programme und Vorlagen . . . . . . . . . . . . . . . . . . . . . . . . . 36

7. Implementation 377.1. Kryptographie und Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.1.1. Symmetrische Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . 377.1.2. Asymmetrische Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . 387.1.3. Hybride Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.1.4. Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.1.5. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.2. AsyncTask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.3. Benötigte Berechtigungen für StuReSy Android . . . . . . . . . . . . . . . . . . 47

7.3.1. WRITE_EXTERNAL_STORAGE . . . . . . . . . . . . . . . . . . . . 477.3.2. android.permission.INTERNET . . . . . . . . . . . . . . . . . . . . . . . 487.3.3. android.permission.READ_PHONE_STATE . . . . . . . . . . . . . . . 487.3.4. WiFi-Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.3.5. Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.3.6. ZXing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8. Feldtest und Befragung zum Nutzungsverhalten von StuReSy Android 538.1. Geräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8.1.1. Notebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.1.2. Tablet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.1.3. Smartphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.1.4. Internet Nutzung Mobil . . . . . . . . . . . . . . . . . . . . . . . . . . . 568.1.5. Technische Ausstattung . . . . . . . . . . . . . . . . . . . . . . . . . . . 568.1.6. Mobiles Surfverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568.1.7. Nutzung mobiler Applikation oder mobil angepasste Internetseite . . . . 57

8.2. Nutzung von StuReSy Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.2.1. Häufigkeit der Nutzung der Applikation . . . . . . . . . . . . . . . . . . 578.2.2. Nutzung spezieller Funktionen . . . . . . . . . . . . . . . . . . . . . . . 578.2.3. Vergleich mit nicht Android-Nutzern . . . . . . . . . . . . . . . . . . . . 58

8.3. Zufriedenheit mit Design und Funktionalität . . . . . . . . . . . . . . . . . . . . 598.3.1. Allgemeine Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

III

8.3.2. Funktionalität der Applikation . . . . . . . . . . . . . . . . . . . . . . . 618.3.3. Fehlende Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

9. Schluss 649.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

9.1.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649.1.2. ARS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649.1.3. StuReSy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649.1.4. Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649.1.5. Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659.1.6. Bibliotheken und Frameworks . . . . . . . . . . . . . . . . . . . . . . . . 659.1.7. Implementationsdetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659.1.8. Feldtest und Befragung . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

9.2. Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A. Anhang IXLiteratur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IXDigitale Version auf CDROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIEidesstattliche Erklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XII

IV

Abbildungsverzeichnis

1. iCue, Quelle: H-ITT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42. Fragengenerator StuReSy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53. Suchfenster StuReSy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64. Abstimmungsfenster StuReSy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65. Entwicklung des mobilen Internetzuganges . . . . . . . . . . . . . . . . . . . . . 86. Marktanteile Smartphone-Betriebssysteme . . . . . . . . . . . . . . . . . . . . . 97. Android-System-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108. Vergleich der Bedienung Smartphone und Tablet . . . . . . . . . . . . . . . . . 159. ActionBar Android 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610. Verteilung der Android-Versionen . . . . . . . . . . . . . . . . . . . . . . . . . . 1811. Sense, Quelle: HTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2012. Telekom Move, Quelle: Telekom . . . . . . . . . . . . . . . . . . . . . . . . . . . 2013. Oberflächenwahl ,Quelle: CyanogenMod . . . . . . . . . . . . . . . . . . . . . . 2114. Hauptfenster StuReSy Android Mock-Up . . . . . . . . . . . . . . . . . . . . . . 2915. Abstimmungsoberfläche StuReSy Android Mock-Up . . . . . . . . . . . . . . . 3016. Liste der Vorlesungen StuReSy Android Mock-Up . . . . . . . . . . . . . . . . . 3117. Liste der Vorlesungen optimiert für Tablets StuReSy Android Mock-Up . . . . 3118. MockFrageStellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3219. QR-Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3420. StuReSy Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5321. Verteilung der Smartphone-Betriebssysteme (Tabelle) . . . . . . . . . . . . . . . 5522. Verteilung der Smartphone-Betriebssysteme (Diagramm) . . . . . . . . . . . . . 5523. Zugriff auf das Internet über mobile Geräte . . . . . . . . . . . . . . . . . . . . 5624. Täglicher mobiler Internetzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . 5625. Präferenz zu nativer Applikation und mobiler Internetseite . . . . . . . . . . . . 5726. Nutzung der Android-Applikation bei Umfragen . . . . . . . . . . . . . . . . . . 5827. Nutzung der Vorlesungsdatenbank. Erstellt mit LimeSurvey. . . . . . . . . . . . 5828. Teilnahme der Web-Oberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . 5929. Anzahl der Nutzer, die mobil abgestimmt haben . . . . . . . . . . . . . . . . . . 5930. Zufriedenheit mit den UI-Elementen . . . . . . . . . . . . . . . . . . . . . . . . 6031. Zufriedenheit mit der Anordnung und Erreichbarkeit der UI-Elementen . . . . . 6032. Zufriedenheit mit der Darstellung der Texte . . . . . . . . . . . . . . . . . . . . 6133. Zufriedenheit mit der allgemeinen Übersicht in der Web-Oberfläche . . . . . . . 6134. Zufriedenheit mit der Funktionalität des Abstimmungsvorganges der Applikation 6235. Zufriedenheit mit der Möglichkeit alte Umfragen anzusehen . . . . . . . . . . . 6236. Wunsch nach der Funktion des Abspeicherns einer beantworteten Frage . . . . . 6337. Wunsch nach der automatischen Aktualisierung einer Vorlesung . . . . . . . . . 63

V

Tabellenverzeichnis

Listings

1. RSA-Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402. Private-Key Generierung RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423. Public-Key Generierung RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424. Codierung AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435. Erstellung der ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

VI

Abkürzungsverzeichnis

ACRA Application Crash Report forAndroid

AES Advanced Encryption StandardAGPL GNU Affero General Public

License (GPL)API Application Programming InterfaceARM Advanced RISC MachinesARS Audience Response SystemDES Data Encryption StandardDRM Digitale RechteverwaltungDVM Dalvik Virtual MachineDEX Dalvik Executable FormatEDGE Enhanced Data Rates for GSM

EvolutionGPL General Public LicenseGUI Graphical User InterfaceHTC High Tech Computer CorporationHTML Hyptertext Markup LanguageHTTP Hypertext Transfer ProtocolIBM International Business Machines

CorporationIDE Integrated Development

EnvironmentID IdentifikationsbezeichnungISDN Integrated Services Digital

NetworkJAR Java ArchiveJRE Java Runtime EnvironmentJSON JavaScript Object NotationJVM Java Virtual MachineLTE Long Term EvolutionLED LeuchtdiodeMAC Media-Access-ControlMVC Model View ControllerMB MegabyteNSA National Security Agency

NFC Near Field CommunicationGB GigabyteKbit KiloKbit/s Kbit pro SekundeMbit MegaMbit/s Mbit pro SekundeMHz MegahertzGHz GigahertzmicroSD micro Secure Digital Memory CardKilo 1.000Mega 1.000.000Giga 1.000.000.000GPS Global Positioning SystemOHA Open Handset AlliancePDF Portable Document FormatPHP P Hypertext PreprocessorQR Quick ResponseRAR Roschal ARchiveRISC Reduced Instruction Set ComputerRSA (Rivest, Shamir und AdlemanSDK Software Development KitSIM subscriber identity moduleSQL Structured Query LanguageSSH Secure ShellSWT Standard Widget ToolkitStuReSy Student Response SystemUI User InterfaceUMTS Universal Mobile

Telecommunications SystemURL Uniform Resource LocatorUSB Universal Serial BusUUID Universally Unique IdentifierVPN Virtual Private NetworkXML Extensible Markup LanguageWLAN Wireless Local Area Network

VII

1. Einleitung

Im Studienalltag eines Studenten nehmen Vorlesungen einen großen und wichtigen Teil ein.Im Allgemeinen sind diese Vorlesungen statisch und fordern von den Studenten eine hoheAufmerksamkeitsgabe, um das gesprochene Wort zusammen mit eventuell projizierten Foli-en semantisch zu verarbeiten und möglicherweise mit zu schreiben. Oftmals bleibt zumindestwährend der Vorlesung ein durchdringendes Nachvollziehen und eine intensivere Auseinander-setzung mit dem Thema seitens der Studierenden aus. Es wird sich auf eine reine Mitschriftund Ablage der Informationen konzentriert.Interaktive Vorlesungen können dabei helfen den Studenten Sachverhalte verständlicher und

schneller erlernbar zu übermitteln, sowie das Wissen später erfolgreicher abrufbar zu halten.Der Harvard-Professor Eric Mazur hat in den 1990er Jahren hierzu den Peer Instruction-Ansatz entwickelt [Mazur, 1997]. Untersucht wurde die Möglichkeit die Effektivität des Ler-nens zu steigern. Hierzu werden aus der großen Gruppe der Veranstaltungsteilnehmer kleinereGruppen gebildet. Diese diskutieren untereinander über eine vom Dozenten gestellte Frage-oder Problemstellung.Mit interaktiven Vorlesungen, Peer Instruction und agilen Methoden lassen sich insbeson-

dere auch im Bereich der Informatik Leistungssteigerungen im Lehrbereich erzielen [Simonu. a., 2010]. Während dieser Studie wurde das System in zwei Einführungsveranstaltungender Computertechnik erprobt. Die anfängliche, durchschnittliche Korrektheit der Antwortensteigerte sich von 44 - 47% auf 63 - 68% im Laufe des Tests. Die Teilnehmer waren nach derTestphase zu 78 - 87% positiv gegenüber dem Peer Instruction Konzept gestimmt. AndereFeldtests zeigen ähnliche Anstiege des Lernerfolges:

from 66 % in 1990 with traditional instruction to 72 % in 1991 with the intro-duction of PI

[Crouch u. Mazur, 2001, .]

Für eine erfolgreiche Umsetzung des Konzepts ist unter anderem eine besondere Vorberei-tung des Systems, der Fragen und der Motivation erforderlich.

1.1. Problemstellung

Ein mögliches Instrument zur interaktiven Gestaltung einer Vorlesung ist ein ARS. Dieses bautin seiner ursprünglichen Form darauf auf, dass Dozenten Fragen und Aufgaben auf einem Com-puterprogramm erstellen und über eine Projektionsfläche an die Studenten stellen. Diese kön-nen dann mit einem Tastendruck auf den Kopf eines Clicker genannten Gerätes unter anderemabstimmen welche Antwort richtig ist, welche Antwort ihre persönliche Meinung widerspiegeltoder auch welche Themen nochmal genauer vom Dozenten erläutert werden sollten [Bruff,2012]. Die Aufgaben, die vom Dozenten interaktiv an die Studenten gestellt werden, können

1

in ihrer Art und Zielsetzung deutlich variieren. Fragen können auf die einfache Wiedergabevon Wissen, auf Meinungsumfragen oder die Lösung von Aufgaben ausgerichtet sein. MeineBachelorarbeit wird auf der Software StuReSy von Wolf Posdorfer aufbauen, welche im Zugeder Bachelorarbeit Posdorfers erarbeitet wurde [Posdorfer, 2012]. Der Vorteil dieses Systemsist, dass es auch ohne spezielle Clicker-Geräte auskommt und von beliebigen internetfähigenGeräten benutzt werden kann. Die Abstimmung erfolgt über das Aufrufen einer bestimmtender Vorlesung zugehörigen Internetseite. Die Software befindet sich zur Zeit in der Entwick-lungsphase und entspricht einem Prototypen. Es gibt daher einige Funktionen die noch nichtfunktionieren, dazu zählt zum Beispiel die Anzeige und die korrekte Teilnahme der Nutzer.Es lassen sich mit wiederholten Aufrufen der Internetseite ohne tieferes Eingreifen Abstim-mungsergebnisse, durch mehrfache Übermittlung der gleichen Antwort, verfälschen.1 Durchdie sehr eingeschränkten Einsatzmöglichkeiten der Internetseite ist es für Nutzer schwierig dieAbstimmung durchzuführen. Es fehlen Anzeigen über die Frage und die Antwortmöglichkeiten.Die Folge ist ein nicht zufriedenstellendes Nutzererlebnis und eventuelle Falschabstimmungen,weil der Nutzer bei der Abstimmung den entsprechenden Knopf auf der Internetseite mit derAntwortmöglichkeit auf dem Beamer vergleichen muss, da er den Text auf der Internetseitenicht sieht.Das Software Projekt, dem meine Bachelorarbeit zugrunde liegt, ist eine mit StuReSy kom-

patible Nutzeranwendung zu entwickeln, die auf dem Android-Betriebssystem für Mobilgerätevon Google basiert. Es soll die Robustheit des Systems, die Funktionalität und die Bedienungverbessern. Android bietet sich als Plattform an, da ein großer Teil insbesondere der Infor-matik Studenten ein entsprechendes Smartphone besitzen und auch während der Vorlesungbei sich tragen. Die große Verbreitung von Android birgt Möglichkeiten und auch Risiken.Es gibt eine sehr große Anzahl verschiedener Geräte und Geräteklassen, Android befindetsich auf Tablet-PCs, MP3-Playern, Handys und Notebook-Alternativen. Durch diese Vielfaltgibt es viele potenzielle Nutzer, aber auch verschiedene Voraussetzungen an die Software,die Hardware zu unterstützen und dabei den Eigenheiten der Geräte gerecht zu werden. DieBildschirmgröße der Geräte reicht von einem bis über 12 Zoll. Daher könnte eine für 10 ZollTablet-PCs optimierte Anwendung auf Hardware mit kleinem Bildschirm nicht benutzbar sein.Die fertige Applikation sollte für möglichst viele verschiedenen Geräte- und Softwareversio-nen benutzbar sein und ein ansprechendes Nutzungserlebnis bieten. Um sicherzustellen, dassdie Applikation auf unterschiedlichen Geräten funktioniert, wird es einen Feldtest im Zuge desModuls Software Entwicklung 1 geben. Falls sich hierbei Probleme mit einzelnen Geräten oderGeräteklassen ergeben, wird die Software daraufhin angepasst, um die Robustheit zu steigern.

1Diese Sicherheitslücke wurde während meiner Arbeit an dem Projekt geschlossen.

2

2. Interaktive Vorlesungen Systeme

2.1. ARS

ARS bezeichnet ein System, mit welchem die Studierenden in Vorlesungen und Vorträgendurch die Interaktion der Teilnehmer mit dem Dozenten und über technische Hilfsmittel andem Vortrag aktiv teilhaben. Je nach Firma und Urprung wird diese durch den technischenFortschritt wieder auflebende, relativ junge Technik anders bezeichnet. Ab Ende der 1960erJahre wurde anfangs kabelgebunden, mittlerweile in der Regel über handliche Infrarot Geräteüber Fragen und Probleme abgestimmt.2 Die Zuhörer werden dadurch aktiv in den Vortrag miteingebunden und der Dozent kann auf die Ergebnisse reagieren. Falls bei einer Wissensfrage,die zunächst isoliert behandelt wurde, die Resultate zu einem bestimmten Prozentsatz nichtrichtig sind, kann die Frage nach einer kurzen Besprechung in Gruppen je zwei Studentenerneut gestellt werden. Hierbei ist zu beachten, dass der Anteil derer, die die Frage schonbeim ersten Mal gewusst haben nicht zu klein sein darf, da sonst die Besprechung unter denZuhörern eher für Verwirrung sorgen könnte. [Mazur, 1997] Allgemein werden die Zuhörerjedoch aktiv eingebunden, gefördert und erzielen bessere Ergebnisse.

2.2. H-ITT

An der Universität Hamburg wird ein ARS-System der Firma H-ITT eingesetzt. Zur Be-nutzung des Systems wurde eine Software und Clicker genannte Abstimmungsgeräte für dieStudenten gekauft. Das Modell iCue bietet nur die Grundfunktionalität, besitzt 13 Knöpfe,10 für die verschiedenen Antwortmöglichkeiten und 3 für die Navigation, sowie eine Zustands-lampe. Mit den Geräten ist es möglich Multiple Choice und Fragen mit wahr oder falsch zubeantworten. Die Lampe an der Vorderseite des Geräte gibt an, ob sich ein Gerät erfolgreich füreine Umfrage angemeldet hat.3 Die Universität Hamburg besitzt neben den knapp 770 iCueClickern auch noch über 500 Geräte des Modells iCue Pro.4 Diese zeichnen sich durch einDisplay, die Möglichkeit der Text- und Formeleingabe und den Hausaufgabenmodus aus. ImHausaufgabenmodus werden die Aufgaben zuhause bearbeitet und in der nächsten Vorlesungabgeschickt.

2Siehe: http://en.wikipedia.org/wiki/Audience_response3Siehe: http://www.h-itt.com/k-12/iCue.htm4Siehe: http://www.wiso.uni-hamburg.de/einrichtungen/elearning-buero/plattformen-werkzeuge/clicker/

3

[ ]

Abbildung 1: iCue, Quelle: H-ITT

3. StuReSy

StuReSy ist ein prototypisches ARS welches von Wolf Dietmar Posdorfer im Rahmen seinerBachelorarbeit konzeptioniert und entwickelt wurde.5 Es baut im Grundgedanken auf beste-hende Systeme auf und erweitert diese durch eine Weboberfläche, spezielle Fragegeneratorenoder auch Fragetypen. Durch ein eigenes Treiber und Plug-in-Management-System ist es mög-lich auch andere Geräte wie die Clicker der Firma H-ITT [Posdorfer, 2012, Kapitel 7.4] zurAbstimmung zu benutzen.

3.1. Fragen erstellen

StuReSy besitzt eine Dozenten- und eine Studentenoberfläche. In der Dozentenoberläche gibtes die Möglichkeit neue Fragen zu erstellen oder Fragenkataloge von vorherigen Fragen zuimportieren.In der Oberfläche auf Abbildung 2 wird ein neuer Fragensatz angelegt. Mit einem Klick

auf den Plus Knopf in der linken oberen Ecke wird eine neue Frage erstellt. Der Dozent hatdie Möglichkeit einen Fragetext und bis zu 10 Antwortmöglichkeiten anzugeben. Über dielinken Checkboxen wird eine Antwort als richtig markiert, die rechten Checkboxen aktivierenneue Antwortmöglichkeiten. Es ist bei Umfragen die ein Meinungsbild oder auch auf eineErfassung nicht verstandener Themengebiete der Studierenden abzielen, die Checkbox Kei-ne richtige Antwort zu aktivieren. Die Frage wird dann später nicht ausgewertet, sondern eswerden nur die Ergebnisse dargestellt. Die Schriftart der Fragen und Antworten, sowie eineAblaufdauer lässt sich einstellen. Läuft die Zeit beim Stellen einer Frage ab, können die Stu-

5Siehe: [Posdorfer, 2012]

4

[ ]

Abbildung 2: Fragengenerator StuReSy

denten nicht mehr abstimmen. In den Fragen und Antworten, lassen sich Hyptertext MarkupLanguage (HTML)-Befehle mit einbinden, um unter anderem Leerzeichen, fette oder kursiveSchreibweisen zu aktivieren. Ist die Eingabe der Texte und Einstellungen für alle Fragen er-folgt, lässt sich der Fragensatz abspeichern oder ein Neuer erstellen. Beim Abspeichern mussder Name der zugehörigen Vorlesung und der Titel des Fragesatzes angegeben werden. Dadurchlässt sich ein Fragesatz immer einer Vorlesung zuordnen und der Dozent kann verschiedeneFragesätze für eine Vorlesung erstellen.

3.2. Abstimmung

Über die Oberfläche Abstimmung kann der Dozent nach Auswahl des Fragenkatalogs eineFrage stellen. Hierbei werden die für die Abstimmung benötigten Daten an einen Webserviceübermittelt. Es wird ein PHP-Dokument aufgerufen, welches die Daten wie Fragen, Antwortenund weitere Einstellungen in die dahinter liegende MySQL Datenbank einträgt. Durch die inder PHP bereitgestellten Rest-API lassen sich mehrere verschiedene Funktionen aufrufen.

5

Hierbei sind die Zugriffsrechte der Aufrufenden zu beachten. Der Aufruf des Nutzers ist vondem des Dozenten entkoppelt, außerdem wird für eine Vorlesung ein Passwort gesetzt, umSicherheit gegenüber Änderungen zu haben. Zur Teilnahme wird in der vorliegenden Versionkeine Zugangsberechtigung benötigt. Die Abstimmung erfolgt über eine im Internet aufzuru-fende Internetseite. Es muss die Identifkationsummer der Vorlesung angegeben werden, umdie aktuell laufende Frage sehen zu können. Wird die Frage in der dahinter liegenden MySQL-Datenbank gefunden, erscheint der Text der Frage, eine Menge an Buttons, die der Anzahlan Antwortmöglichkeiten entspricht, ein Button der auf Knopfdruck die Antwort übermittelt,sowie ein Reload-Button (Abbildung 4) . Wird vom Dozent eine neue Frage gestartet, kannder Nutzer über Reload sich die neue Seite und die neue Frage anzeigen lassen.Auf den Buttons steht jeweils nur ein Buchstabe zur Orientierung, aber nicht der Fragentext.

Als Zusatzfunktion gibt es für den Dozenten die Möglichkeit einen Quick Response (QR)-Codezu erzeugen, der über einen HTML-Link direkt zur Vorlesung und Frage führt.Die Oberfläche bietet nur die Grundfunktionalität und darüber hinaus keine weiteren Funk-

tionen. Da die Antworttexte nicht mit angezeigt werden, müssen die Studenten den Button mitder Antwort, die über die Dozentenoberfläche per Beamer ausgestrahlt wird, abgleichen. Dar-aus können sich aus Unachtsamkeit falsche Abstimmungsergebnisse seitens der Studierendenergeben.

[ ]

Abbildung 3: Suchen einer Vorlesung mit StuReSy.

[ ]

Abbildung 4: Abstimmungsfenster StuReSy. Die Aufnahmen der Oberfläche wurden mit derStuReSy Beta6 erstellt

6

3.3. Authentifizierung

Die Authentifizierung erfolgt mittels eines Cookies. In dieser Textdatei wird unter anderemeine zufällig generierte Nutzeridentifikationsnummer gespeichert. Diese bleibt solange der Coo-kie gespeichert und aktiv ist, bestehen. Anhand der Identifikationsnummer kann im Gegensatzzur Media-Access-Control (MAC)-Adresse des Gerätes jedoch nicht die Identität eines Nutzerermittelt werden. Die Abstimmung erfolgt daher anonym. Zu jeder Umfrage wird in der Daten-bank die abgegebene Stimme, das Datum und die Nutzeridentifikationsnummer gespeichert.Startet der Dozenten die Auswertung, werden diese temporären Daten jedoch nach Erfassungund Auswertung der Abstimmungsergebnisse wieder gelöscht.

3.4. Zusatzfunktionen

StuReSy bietet die im oberen Abschnitt erwähnte Funktion, zusätzliche Abstimmungsgeräteunabhängig von einem Internetzugang einbinden zu können. Bisher konnte eine Abstimmungnur mit den H-ITT Clickern erfolgen. Es ist jedoch theoretisch möglich eine Schnittstelle fürweitere Geräte von anderen Herstellern einzubinden. Dies ist auch nötig, da viele Herstellervon Abstimmungssoftware eigene proprietäre Hardware benutzen, die dementsprechend nurmit der entsprechenden Software lauffähig ist. Zu beachten sind hier jedoch die Einschränkun-gen des Herstellers, da in den Allgemeinen Geschäftsbedingungen oftmals eine anderweitigeNutzung untersagt ist, beziehungsweise die Garantie der Geräte erlischt. In Zukünftigen Ver-sionen von StuReSy sind weitere Funktionen in der Planung. Es ist zum Beispiel denkbar,zu einer Frage ein Bild mit einem Liniendiagramm zu hinterlegen, mit der Frage an welcherKoordinate der Ordinatenabschnitt liegt. Dies würde jedoch möglicherweise die herkömm-liche Clicker Benutzung beeinträchtigen. In der Grundversion haben diese nämlich keinenBildschirm oder nur einen Schwarz-Weißen und Nutzer können das Bild daher nur über dieprojizierte Dozentenoberfläche sehen.

3.5. Analyse der Nutzeroberfläche

Die Abstimmungsoberfläche fällt in der jetzigen Version relativ schlicht aus. Antworttexte wer-den nicht angezeigt und bieten daher ein relativ hohes Potential für falsche Abstimmungen.Wird ein Notebook zur Abstimmung genutzt, müssen die Nutzer jedes Mal die Identifikations-nummer der Vorlesung benutzen. Der QR-Code ist zum Teil nicht effektiv benutzbar, da esin den mobilen Geräten nicht immer eine interne Kamera gibt, diese zu schlechte Aufnahmenzur Analyse eines Codes macht oder der Code über die Projektionsfläche nicht praktikabeldarstellbar ist.

7

4. Android

Android ist ein relativ junges mobiles Betriebssystem, welches erstmals im November 2007vorgestellt und im Oktober 2008 veröffentlicht wurde. Android wird von der Open HandsetAlliance (OHA) entwickelt. Das von Google initiierte und mit gegründete Konsortium OHAbesteht zur Zeit aus 84 Firmen und hat sich zum Ziel gesetzt, den Konsumenten innovativeund performante Software frei und offen zugänglich zu machen [Alliance, 2012].

4.1. Wahl des Betriebssystems

Studien zufolge wird die Anzahl der Nutzer des Internets über mobile Geräte bereits ab un-gefähr 2014 die der Desktop Computer Nutzer übersteigen6.

[ ]

Abbildung 5: Prognose der Entwicklung des Internetzuganges durch mobile Geräte. Quelle:Morgan Stanley Research

Daraus folgend ist eine Orientierung auf den mobilen Markt in Hinblick auf die Prognosensinnvoll.

6Siehe: http://mobilemetrics.de/2010/05/19/mobile-web-uberholt-desktop-web-in-5-jahren/

8

Android ist ein rasant wachsendes Betriebssystem für mobile Endgeräte. Es basiert auf Li-nux und Java. Durch die Nähe zum Ursprungsprojekt, welches auch auf Java basiert, ist esleichter Anpassungen vorzunehmen. Android ist ein quelloffenes Betriebssystem mit relativwenig Einschränkungen. Im Gegensatz zu iOS, dem mobilen Betriebssystem von Apple, ist esauf Android möglich Programme auch außerhalb der offiziellen Vertriebswege zu veröffentli-chen und gegebenenfalls zu verkaufen. Applikationen können daher direkt und ohne Umwegean die Kunden zu verteilen. Bei iOS gibt es nur die Möglichkeit über den App Store Appli-kationen zu beziehen. Diese werden vorher geprüft und müssen strengen Regeln, was unteranderem Effizienz, Design und Bedienung angeht, erfüllen. Nur über eine Modifikation desBetriebssystems bei dem die Garantie erlischt, kann diese Sperre umgangen werden. Die Ap-plikationen werden zum Teil nicht nachvollziehbar nicht zugelassen, obwohl sie alle Regelnerfüllen. Außerdem kann Apple per Fernzugriff bereits installierte Applikationen löschen.7

Android ist das im 3. Quartal 2012 mit Abstand am meisten verkaufte mobile Betriebssys-tem weltweit. Rund 75% der verkauften Geräte wurden mit Android ausgeliefert. iOS liegtabgeschlagen an 2. Stelle aber noch deutlich vor den anderen Betriebssystemen.8

[ ]

Abbildung 6: Weltweite Marktanteile von Smartphone Betriebssystemen 3.Q 2012 Autor: ID-Ccharts powered by iCharts

7Siehe: http://de.wikipedia.org/wiki/App_Store_(iOS)8Quelle: https://www.idc.com/getdoc.jsp?containerId=prUS23771812

9

[ ]

Abbildung 7: Android-System-Architektur. Quelle: http://commons.wikimedia.org/wiki/File:Android-System-Architecture.svg

Durch die enorm hohe Verbreitung ist eine Entwicklung von Applikation durch die potenziellsehr hohe Nutzerschicht attraktiv. Es können so deutlich mehr Nutzer angesprochen werden.

4.2. Android Systemarchitektur

Android basiert auf dem Linux Kernel 2.6 und seit der Android-Version 4.0 auch auf demLinux Kernel 3. Dieser bietet die Standard Treiber für Hardware Komponenten wie zumBeispiel: Bildschirmtreiber, WiFi-Treiber und Tastaturtreiber. Darüber hinaus wird im Kerneldas Speicher- und Prozessmanagement betrieben.9

4.3. Dalvik Virtuell Machine

Von der Android-Runtime aus wird zur Laufzeit für jede Applikation ein Prozess, sowie eineDalvik Virtual Machine (DVM) mit eigenem Heap und Stack gestartet, die von der herkömm-

9Schematischer Aufbau der Android-System-Architektur, siehe in Abbildung 7

10

lichen Java Virtual Machine (JVM) ein wenig abweicht.10 Die DVM verarbeitet Codes durchAnpassungen an die spezielle in den meisten Mobilsystemen verwendete Advanced RISC Ma-chines (ARM)-Technologie maschinennah und ist daher vergleichsweise schnell und effizient.Dies ist wichtig, da die DVM im Gegensatz zur JVM auf Hardware mit sehr beschränktemHauptarbeitsspeicher und eingeschränkter Prozessorleistung mit begrenzter Energiezufuhr lau-fen muss. Trotzdem wurde durch die OHA festgelegt, dass der Code der mit einer angepasstenVersion des normalen Java SDKs erstellt wurde, weiterhin ausführbar bleiben soll. Der JavaBytecode wird für die DVM in das Dalvik Executable Format (DEX)-Bytecodeformat kom-piliert. Dadurch lässt sich unter anderem ein wenig des Platzbedarfes durch zum Beispielmehrere Klassen in einer Datei einsparen. Auch ohne Komprimierung sind die DEX-Dateiendaher in der Regel kleiner als die entsprechenden Java Archive (JAR)-Archive. Der Ablaufbeim Starten eines Programmes mit der JVM geschieht in 3 Phasen.

• fetch – in dieser Phase wird der aktuell auszuführende Bytecode aus dem Stack geladen

• decode - Notwendige Operanden vom Operanden-Stack laden und den Befehl in Maschi-nencode und Funktionsaufrufe übersetzen.

• execute – Ausführung des Codes auf dem Prozessor.

Die DVM ist vom Aufbau der JVM ähnlich, basiert aber auf einem (virtuellem) Register-maschinenprinzip. Daher müssen Operanden in verschiedenen Registern abgelegt und wiedergeholt werden. Dieser Vorgang ist erstmal nicht schneller als bei der JVM. Bei einer Abbil-dung der virtuellen Register in reale Register lässt sich jedoch Zeit einsparen. Dadurch legt sichDVM jedoch auf eine Hauptarchitektur für Prozessoren fest, nämlich die ARM-Architektur.ARM-Prozessoren bieten 16 16-Bit Register, dass hat bei Methoden mit mehr als 16 Para-metern ein Platzproblem zur Folge. Sie passen nicht komplett in die Register. Normalerweisesind solche Methoden jedoch selten.Ein Effizienzvorteil ergibt sich durch die Nutzung von 2-Byte langen Opcodes in der DVM.

Es können also mit einem Aufruf doppelt so viele Bytes geladen werden. Dadurch verringertsich die Anzahl der Aufrufe und die Geschwindigkeit. Seit Android 2.2 wird Just-In-Time-Kompilierung unterstützt. Hierbei wird ein Teil des Programms zur Laufzeit in Maschinenco-de übersetzt. Diese Technik wird vor allem bei häufig gebrauchten Programmteilen benutzt,welche viel Prozessor und Ausführungszeit benötigen. Daher lohnt es sich diese Teile zu Kom-pilieren, Optimieren und zur Wiederverwendung abzuspeichern. Bei der Optimierung könnenzum Beispiel spezielle Funktionen des Prozessors effizient genutzt werden. In der DVM wirdein Garbage Collector unterstützt, der nach dem mark and sweep Prizip funktioniert. DerGarbage Collector ist jeweils nur im zugewiesenen Heap der Applikation tätig und gliedertsich in 2 Phasen auf.

10Quelle: [Nicola, 2009]

11

• Mark - Hierbei werden vom System aus alle Wurzelobjekte auf einen Stack gelegt. Vondiesem aus werden alle Objekte die erreicht werden markiert. Falls ein Objekt besuchtaber noch nicht markiert wurde, wird es markiert und alle Referenzen auf den Stackgeladen.

• Sweep - Alle nicht markierten Objekte und Speicherbereiche auf dem Heap werden durch-laufen und freigegeben.

In den Core Libraries stehen Bibliotheken für zum Beispiel den Dateizugriff, Datenstruk-turen, Grafikelemente und Netzwerkzugriff bereit. Auf diesem Fundament setzen die Androidspezifischen Frameworks auf. Der Activity- und der Window-Manager sind für die Darstellungder Fenster verantwortlich. Es gibt ein paar Bibliotheken, die effizienter in C/C++ kompiliertsind und rechenintensive Aufgaben übernehmen. Dazu zählen das Datenbanksystem SQLite,welches von den Applikationen zur Erstellung und Benutzung eigener lokaler Datenbankengenutzt wird, sowie das Media Framework, welches Grafikschnittstellen und Bibliotheken wieSGL und OpenGL zur Darstellung von Inhalten auf dem Bildschirm nutzt.

4.4. Oberflächenkonzept Android

Android setzt im Gegensatz zur gewöhnlichen Java Vorgehensweise auf ein eigenes Oberflä-chenkonzept. Swing oder SWT lassen sich nicht benutzen. Eine sichtbare Oberfläche bestehtaus mehreren Teilen, die ich im Folgenden vorstelle.11

4.4.1. Activity

In einer Activity werden die Oberflächen dargestellt und verwaltet. Jede sichtbare Oberflächewird von einer Activty dargestellt. Activities lassen sich verknüpfen und können von einan-der über Intents (4.4.4) aufgerufen werden. Der normale Programmablauf sieht in der Regeleine Haupt-Activtiy vor. Informationen über die Anwendung, Activites, die Berechtigungen(7.3) und Einstellungsparameter wie die Versionsnummer, werden in jedem Android-Projektin einem XML-Dokument, dem Android-Manifest, definiert. Die Haupt-Activtiy wird aus demManifest gelesen und beim Starten der Anwendung aktiviert. Von hier aus kann der Nutzerzu den verschiedenen Funktionen des Programms navigieren. Die Navigation geschieht durchdas Starten eines Intents, der eine andere Activity startet. Die zuvor aktivierte Activity wirddann pausiert und auf dem Back Stack abgelegt. Der Lebenszyklus von Activities kann re-lativ komplex werden und wird daher im Folgenden kurz skizziert. Eine Activity kann vierverschiedene Zustände annehmen:

• Laufend: Die Activity ist aktiviert, läuft im Vordergrund und nimmt Interaktionen desNutzers entgegen.

11[Komatineni u. MacLean, 2012, Kapitel 2 und 16 Seite 484-485], [Kuenneth, 2012, Kapitel 4 und 5] und[Allen, 2011, Part 2 insbesondere Kapitel 18]

12

• Pausiert: Die Activity wurde pausiert und der Zustand auf dem Stack gespeichert. DerZustand wird erreicht, wenn der Sperrbildschirm aktiviert wurde, eine andere Activityoder ein Dialog die Activity teilweise überdeckt. In diesem Zustand kann die Activitybei Engpässen im Speicher vom System sofort beendet werden.

• Gestoppt: Die Activity ist nicht mehr sichtbar, aktiv oder wird komplett von einer ande-ren Activity überdeckt. Der Zustand wird erreicht, wenn eine andere Activity gestartetwurde oder der Nutzer den Button für den Home Bildschirm drückt. Auch aus diesemZustand kann die Activity jederzeit beendet werden.

• Beendet/Zerstört: In diesen Zustand wird die Activity aus den obigen Gründen versetzt.Sie kann dann nicht mehr wiederhergestellt, sondern muss neu erzeugt werden.

Wurde eine Activtiy nicht zerstört, kann sie auch aus dem pausierten oder gestoppten Zustandwiederhergestellt werden, wenn der Nutzer mittels der Zurück Taste beispielsweise wieder aufdiese Activity navigiert oder den Dialog wegdrückt. Alle Zustände, Variablen usw. befindensich dann im vorherigen Zustand. Die Activity kann in diesen Zuständen jedoch jederzeitzerstört werden, im positiven Fall erhält die Activity vorher eine Nachricht, dass sie Beendetwird, im negativen nicht.Das System informiert die Activity in der Regel mit mehreren geschützten Methoden, die

überschrieben werden können, über ihren Zustand.

• onCreate(): Die Methode wird nur einmal aufgerufen, wenn die Activity erstellt wird. Inihr wird die GUI geladen, dargestellt und weitere Initialisierungen vorgenommen.

• onRestart(): Wird aufgerufen wenn eine vorher gestoppte Activity reaktiviert wird.

• onStart(): Wird nach onCreate() oder onRestart() aufgerufen.

• onResume(): Wird nach onStart() aufgerufen oder wenn eine vorher pausierte Acitvityreaktiviert wird.

• onPause(): Wird aufgerufen, wenn die Activity pausiert wird. Da das System Activitiesunbemerkt beenden kann, empfiehlt es sich den Zustand der Activity für diesen Fallpersistent zu sichern.

• onStop(): Wird bei einem stoppen der Activity nach einem Aufruf von onPause() aufge-rufen. OnPause() wird immer vor onStop() aufgerufen. Da Activites ohne Mitteilung impausierten Zustand jederzeit beendet werden können, sollte die Persistenz in onPause()sicher gestellt werden. Ein Aufruf von onStop() erfolgt in diesem Fall nicht.

• onDestroy(): Die Methode wird aufgerufen kurz bevor die Activity unwiderruflich zer-stört wird. Es ist der letzte der Activity bekannte Zustand und die letzte Möglichkeit

13

Daten zu sichern, aus denen die Activity neu erstellt werden kann. Auch diese Methodemuss nicht aufgerufen werden, wenn eine Activity beendet wird.

Die Nutzereingaben auf dem Bildschirm werden durch klicken eines Buttons oder ähnlichemvon der Activity entgegengenommen und verarbeitet. Die Activity verwaltetet alle OberflächenElemente, genannt Views, die in ihr dargestellt werden. Selbst erstellte Activities erben von derin der API definierten Java Klasse Activity. Es können dann einige Methoden überschriebenwerden, die das Verhalten betreffen, zum Beispiel was passieren soll, wenn die Activity beendetwird. In der Methode

1 public void onCreate(Bundle savedInstanceState)

wird der Activtiy eine Oberfläche zugewiesen. Dies geschieht über spezielle, vorher definierteXML-Dokumente mit Layout Informationen usw. oder auch zur Laufzeit mit Java Objekten.Es gibt neben der Standard-Activity auch noch spezielle durch die API bereit gestellte Ac-tivities. Häufig gebraucht wird die ListActivity, die eine Liste mit verschiedenen Elementendarstellt, mit denen interagiert werden kann. Die Elemente können über ein Cursor-Objektoder eine ArrayListe durch den Aufruf einer Methode in der onCreate Methode der Liste hin-zugefügt werden. Bei einem Klick auf ein Element wird in der Regel ein Intent zu einer anderenActivity gestartet, in dem Detailinformationen zu dem Listenelement angezeigt werden.

4.4.2. Viewgroup und Views

Eine Viewgroup bildet einen Container für Views, in dieser wird festgelegt, wie die View-elemente angeordnet sind, welches Layout und welche Größe sie haben. Eine View ist einOberflächenelement mit Eigenschaften wie Größe, Farbe und Verhalten. Ein Button ist eineView, die bei einem Klick eine definierte Methode in der Activity ausführen lässt. Einstellenlassen sich Eigenschaften, ob ein Button für eine andere Methode lange gedrückt werden kannoder ob der Button standardmäßig aktiviert sein soll.

4.4.3. Fragmente

Mit der API Version 11 und dem Erscheinen der ersten Android-Tablets wurde in Androiddas Konzept der Fragmente eingeführt. Ein Fragment ist eine Subeinheit einer Activity, dieeine eigene Klasse und ein eigenes Layout besitzen. Auf Grund der Bildschirmgröße führte inAPIs vor der Version 11 ein Klick auf ein Element in der Regel zu einem Übergang zu einerkomplett anderen Activity. Wollte man aus einer Liste ein Element genauer darstellen wurdeeine neue Activity erstellt, die eine Detailansicht bot. Mit mehr Platz und besserer Auflösungauf den Bildschirmen ist es jedoch möglich sowohl die Liste mit den Elementen, als auch dieDetailansicht auf einem Bildschirm darzustellen. Ein Klick auf ein Listenelement aktualisiertdie Detailansicht mit diesem Element.

14

[ ]

Abbildung 8: Schematischer Vergleich der Bedienung einer Tablet-GUI mit einerSmartphone-Version. Quelle: http://developer.android.com/guide/practices/tablets-and-handsets.html

Die Fragmente können über die Elternactivity mit einander kommunizieren, Daten austau-schen oder durch den Aufruf von Listenern aktiviert werden.

4.4.4. Intents

Über Intents wird die Kommunikation zwischen Activities, Services und anderen Applikatio-nen zur Laufzeit realisiert [Kuenneth, 2012, 4.2]. Sie können sowohl andere Applikationen überein eingetroffenes Ereignis informieren, als auch einen Auftrag mit Informationen zur Bearbei-tung senden. Ein Intent kann direkt eine bestimmte Applikation über den Namen und derenPaketnamen ansprechen oder aber über die Definition einer Kategorie mehrere verschiedeneApplikationen Ansprechen. Ist die Kategorie beispielsweise Audio, werden alle Applikationengelistet, die mit dieser Kategorie umgehen können. In den Applikationen werden dazu in derProjektdatei Intent-Filter festgelegt, in denen beschrieben wird auf welche Anfragen die Ap-plikation reagieren kann. Der Nutzer wählt dann aus, welche Applikation seiner Meinung nachdie Aufgabe am besten erfüllt und ein Lied oder ähnliches abspielt. Diese Intents werden im-plizite Intents genannt. Explizite Intents, mit Angabe des Paketnamens werden in der Regelnur für die interne Projekt-Kommunikation verwendet.

4.4.5. ActionBar

Eine ActionBar ist eine ab der Android-Version 3.0 eingeführte Navigationsleiste, die in denDesign und User Interface (UI)-Guidlines von Android eine zentrale Rolle einnimmt12. Diese

12Siehe: [Google, 2013a] und [Komatineni u. MacLean, 2012, Kapitel 10]

15

Guidlines sind im Gegensatz zu denen von Apple für iOS jedoch nur Richtlinien. Auch ohneeine ActionBar wird eine Applikation im Play Store zugelassen. Die Implementation ist somitnicht Pflicht, wird aber erwünscht.

[ ]

Abbildung 9: ActionBar unter Android 3.0, Quelle: http://developer.android.com/guide/topics/ui/actionbar.html

Die Abbildung 9 zeigt den Aufbau einer Action Bar. In der obersten Zeile ist die normaleStatusleiste von Android mit Uhrzeit, Akkustand usw. zu sehen. In der zweiten Zeile beginntdie Action Bar mit dem Icon des Programms, dem Titel der Applikation und rechts danebeneinem Action Item. Diese Action Item können mit vielfältigen Funktionen belegt werden undhaben ein dementsprechendes Aussehen. In diesem Fall ist es ein Kamera Button, um beieinem Klicken ein Bild aufzunehmen. Es gibt bereits eine bestimmte Anzahl von StandardAction Items. Dazu zählt auch die Klasse SearchView. Mit ihr ist es möglich, auf Knopfdruckein Eingabefeld in der ActionBar auszufahren und zum Beispiel in der Applikation nach Datenzu suchen. Diese Suche wird mit einer symbolischen Lupe als Icon belegt. Neben der Kamerasind auf dem Bild drei Punkte, auf der die Einstellungen der Applikation zugreifbar sind.Dieser Button wird dynamisch dann angezeigt, wenn das Gerät auf dem die Applikation läuft,keinen mechanischen Menüknopf besitzt oder fest angezeigt werden soll.In der 3. Zeile sind mehrere Tabs genannte Schaltflächen zur Navigation. Durch einen klick

auf diese, gelangt der Nutzer zu den wichtigsten Teilen der Applikation. Je nach Einstel-lungen ist es möglich die Action Bar ein wenig zu modifizieren. Die Tabs können auch alsDropdown-Liste zur Navigation dienen, mit einem Klick auf das Icon der Applikation kehrtder Nutzer zum Hauptbildschirm. Es kann jedoch auch auf die Navigationselemente in derLeiste verzichtet werden. Eine Action Bar wird immer in einer Activity eingebunden und istan deren Lebenszyklus gebunden. Das bedeutet, wird die Activity gewechselt oder beendet,wird auch die Action Bar geschlossen. In den einzelnen Tabs wird jeweils ein Fragment zurAnsicht geladen.Zusätzlich zu der Activity, die die Action Bar beherbergt, wird ein TabListener benötigt.

Für diesen gibt es bereits ein Interface. Es müssen mehrere Listener Methoden implementiertwerden, in denen definiert wird, was passiert wenn ein Tab angewählt, wieder angewähltoder abgewählt wird. Wird ein Tab ausgewählt, wird das zu diesem Tab gehörende Fragmentdem Fragment Manager, der alle Fragmente enthält und verwaltet, hinzugefügt, initialisiertund geladen. Wird ein anderer Tab und dessen Fragment ausgewählt, wird das vorher aktive

16

Fragment aus dem Fragment Manager entfernt. Eventuell muss die Oberfläche dann einmalneu gezeichnet werden, da sich sonst die Oberflächen der Fragmente überlagern können.

4.5. Fragmentierung von Android

Android wird von vielen verschiedenen Geräten und Gerätetypen mit unterschiedlicher Hard-und Software genutzt. Das erschwert die Entwicklung einer einzigen Applikation, die auf allenGeräten gleichmäßig optimal nutzbar sein soll.

4.5.1. Displaygröße und Auflösung

Android-Geräte haben abgesehen von einigen Exoten wie Android-Uhren und 13 Zoll Tabletsin der Regel Displaygrößen im Bereich von 2 bis knapp über 10 Zoll. Ein Graphical User In-terface (GUI), die auf einem Smartphone mit 4,7 Zoll und HD-Ready Auflösung dem Nutzereine komfortable Bedienung ermöglicht, kann mit einem 3 Zoll Display und 320 x 480 Pixelnschon gar nicht mehr benutzbar sein. View-Elemente mit fester oder nicht kleiner darstellbarerGröße, wie der Beschriftung eines Buttons, werden dann nur noch unvollständig dargestellt.Textfelder die zu lang sind, können andere Elemente verdrängen und nicht zum klicken er-reichbar verstecken. Ebenso sind für kleine Displaygrößen optimierte Oberflächen auf großenDisplays unansehnlich oder durch die kleine Darstellung unerreichbar.

4.5.2. Hardware-Voraussetzungen

Die Prozessor- und Grafikleistung unterscheidet sich bei unterschiedlichen Geräteklassen er-heblich von einander. Während die ersten Android-Geräte mit 528 MHz Einkernprozessoren,192 Megabyte (MB) Arbeitsspeicher und 3 Megapixel Kamera auskommen mussten 13, bietenaktuelle High-End Smartphones bereits mindestens 1,4 Gigahertz (GHz) Quadcore Prozesso-ren, 2 GB Ram und eine bis zu 12 Megapixel auflösende Kamera. Rechenintensive Aufgabenkönnen schwächere Geräte daher schnell überlasten, schnellere hingegen nicht beeinträchti-gen. Bei dem Versuch große Datenmengen zeitgleich im Speicher zu verarbeiten ist bei 192MB schnell der Speicher voll.Soll bei der Entwicklung nicht auf die Nutzungsmöglichkeit mit älteren Geräten verzichtet

werden, gilt dieser Geschwindigkeitsaspekt zu berücksichtigen. Für QR-Code-Scan Applika-tionen wird eine gute und genaue Kamera im Gerät benötigt, um auch bei etwas Entfernungdie feinen Raster noch genau analysieren zu können. Löst die Kamera das Bild nicht genaugenug auf, kann eine Applikation daher unbrauchbar für bestimmte Geräte werden. Daher soll-ten die dahinter stehenden Erkennungsalgorithmen auch mit leichter Unschärfe noch passableErgebnisse liefern können.

13http://de.wikipedia.org/wiki/HTC_Dream

17

Werden große Datenmengen über das Internet auf das Gerät übertragen, kann sich die Inter-netverbindung ohne Wireless Local Area Network (WLAN) als Engpass entwickeln. EnhancedData Rates for GSM Evolution (EDGE) als Übertragungsstandard bietet Übertragungsra-ten von maximal 220 Kbit pro Sekunde (Kbit/s), Universal Mobile Telecommunications Sys-tem (UMTS) hingegen schon 21 Mbit pro Sekunde (Mbit/s). Werden jetzt größere Daten-pakete versandt, ergeben sich unter Umständen lange Ladezeiten auf den Geräten. 14 Beieiner Liste mit vielen Elementen und Detailinformationen kann es für ein langsames Gerätschneller sein, für den Aufbau der Elemente erstmal nur die Grundinformationen wie Namenherunterzuladen und die Detailinformationen erst bei Bedarf nachzuladen. Mit einer schnellenInternetverbindung und einem großem Speicher, macht es jedoch keinen relevanten Unter-schied in der Benutzbarkeit, ob alle Information in einem Vorgang geladen werden oder nurin Teilen.

4.5.3. Betriebssystem-Version

Mittlerweile gibt es 11 größere Versionen des Android-Betriebssystems. Fast die Hälfte derNutzer haben laut den von Google bereitgestellten Erhebungen auf ihren Android-Gerätendas Betriebssystem 2.3.x Gingerbread installiert.

[ ]

Abbildung 10: Verteilung der Android-Versionen. Quelle http://developer.android.com/about/dashboards/index.html

14http://de.wikipedia.org/wiki/Universal_Mobile_Telecommunications_System

18

Diese Version ist veraltet und bietet nur eine eingeschränkte API an. Nur ein geringer Teilvon bis zu 33% nutzt jeweils die aktuellsten Versionen.15 Diese Tatsache liegt zu einem großenTeil an der Verteilungsstruktur für das Betriebssystem. Viele der Hersteller für Android-Gerätebietet auf ihren Geräten angepasste Software und Oberflächen für das Betriebssystem. 16

Erscheint eine neue Android-Version, ist es sehr aufwändig diese für alle angebotenen Geräte zuportieren, da hierfür Anpassung an die Hardware und Software vorgenommen werden müssten.Oftmals wird dieser Aufwand eingespart und in die Entwicklung neuer Geräte investiert, älterebleiben außen vor.Problematisch kann der geringere Funktionsumfang sein, falls bestimmte Funktionen unbe-

dingt für eine Applikation gebraucht werden. Hat ein Gerät nicht die richtige Version stürztdas Programm bei der Benutzung ab oder startet gar nicht erst. Entsprechende Programmewerden im Play Store gar nicht erst angezeigt. Das Oberflächenkonzept der neueren Versionenvon Android setzen zu einem großen Teil auf Programmierkonzepte beziehungsweise Klassen,die es auf alten Geräten gar nicht gibt. Daher muss entweder eine andere Oberfläche benutztwerden, was dann jedoch das Nutzererlebnis trübt, oder die fehlenden Objekte müssen ander-weitig nach programmiert werden. Google hat zu diesem Zweck bereits eine Bibliothek zurVerfügung gestellt, die jedoch die Benutzung erheblich komplizierter gestaltet. Um diesem einwenig entgegen zu wirken, gibt es auch noch andere nutzbare Bibliotheken, die zum Teil inspäteren Kapiteln vorgestellt werden (Siehe: ActionBarSherlock 6.1).

4.5.4. Custom-Roms und herstellerspezifische Versionen

Zusätzlich zu den offiziellen von Google vertriebenen Versionen, gibt es eine Fülle von durchNutzern selbst, anderen Firmen und Mobilfunkanbietern oder Geräteherstellern abgewandelteVersionen des ursprünglichen Android-Betriebssystems.

Hersteller und Mobilfunkanbieter: Android Gerätehersteller passen das Betriebssystem ne-ben hardwarebedingten Änderungen oftmals mit einer speziellen Oberfläche und Programmenan. Der taiwanische Hersteller High Tech Computer Corporation (HTC) stattet einen großenTeil seiner Geräte mit der HTC Sense Oberfläche aus. Diese unterscheidet sich von der nor-malen durch ein anderes Design, ein angepasstes Bedienkonzept und weitere Funktionen, wiebeispielsweise eine auf der Hauptoberfläche dargestellten Wetter Applikation, die das Wetterals Symbole darstellt (Abbildung: 11).17

15Siehe: 10. Die Daten wurden über die Downloadstatistiken im Play Store ermittelt. Über diesen lassen sichneue Applikationen herunterladen. Zum anmelden wird ein Google-Konto benötigt. Es nutzen also nicht alleBesitzer eines Android-Gerätes den Play-Store. http://developer.android.com/about/dashboards/index.html

16Siehe beispielsweise: http://www.htc.com/de/why-htc/personalization/?section=personalized17Siehe: http://www.htc.com/de/why-htc/personalization/?section=personalized

19

[ ]

Abbildung 11: Sense, Quelle: HTC

Darüber hinaus sind herstellerspezifische Programme, wie zum Beispiel ein spezielles Notiz-buch der Firma Samsung üblich. 18.Mobilfunkanbieter gehen ähnlich vor, um die Geräte von anderen abzuheben, einzigartiger,

für Kunden attraktiver und dem Unternehmen zugehöriger wirken zu lassen. Auf den Gerätendes Mobilfunkanbieters Telekom sind unter anderem bereits Programme für den Zugang zuInternetversandhäusern und dem Login zur Benutzung von WLAN-Hotspots der Telekomvorinstalliert. Die optische Gestaltung ist zum Teil an die Unternehmensfarben angelehnt(Abbildung: 12).19

[ ]

Abbildung 12: Telekom Move, Quelle: Telekom

18Siehe: http://www.samsung.com/de/consumer/mobile-device/mobilephones/smartphones/GT-I9300MBDDBT-spec

19http://www.t-mobile.de/handy-hilfe/0,23626,26974-_,00.html#/telekom/move/internet/wlan-verbindung-einrichten

20

Custom-Rom: Ein Custom-Rom basiert in der Regel auf dem frei verfügbaren und unterOpen Source stehenden Quellcode von Android. Dieser wird durch Eingriffe verschiedensterArt modifiziert. Das bekannteste Custom-Rom Projekt ist CyanogenMod20 und bietet für dieNutzer einige Vorteile.

[ ]

Abbildung 13: Oberflächenwahl ,Quelle: CyanogenMod

Durch die Nutzung des aktuellen Quellcodes erhalten Geräte frühzeitig eine Aktualisierung,auch wenn der Hersteller erst deutlich später oder gar nicht eine offizielle Aktualisierung fürdas Gerät vorsah. Dadurch haben die Nutzer auch die Vorteile der neuen Android-Version.Darüber hinaus sind die Geräte vom ursprünglichen Ballast des Herstellers (optische Anpas-sung, ungewünschte Applikationen...) befreit. CyanogenMod hat eine eigene personalisierbareOberfläche, Sperrbildschirme sowie unter anderem eine Applikation für den vereinfachten Zu-gang zu Virtual Private Network (VPN) Schnittstellen.Ein Custom-Rom lässt sich in der Regel nur nach einem Root-Vorgang installieren. Dieser

wird über ein Programm an einem Computer durchgeführt, an dem das Gerät per USB-Kabel angeschlossen ist. Der Nutzer wird darauf hin mit Root-Rechten ausgestattet, die ihmvielfältige, vorher nicht vorhandene Möglichkeiten erlauben in das System einzugreifen und einCustom-Rom zu installieren. Als Root-Nutzer ist es unter anderem möglich den Prozessor zuübertakten, Sicherungen des kompletten Systems vorzunehmen oder über eine Applikation aufdie Konsole zuzugreifen. Der Vorgang birgt jedoch Risiken. Bei falscher Custom-Rom erlischtdie Garantie und das Gerät kann unbenutzbar werden, wird der Prozessor zu stark übertaktet,

20http://www.cyanogenmod.org/about

21

kann dieser überhitzen und bleibende Schäden erhalten, die Grundfunktionalität ist eventuelleingeschränkt.

4.5.5. Folgen für die Entwicklung

Durch die Hard- und Software-Vielfalt wird besondere Sorgfalt vom Entwickler erfordert,damit die Anwendung auf möglichst vielen Geräten möglichst gut funktioniert. Dazu sollteumfassend getestet werden und auf einigen Geräte nicht vorhandene Funktionen, aber wich-tige Funktionen von Hand implementiert werden. Es sollte immer im Hinterkopf behaltenwerden, dass es angepasste Betriebssysteme gibt, auf denen sich eventuell die Applikationinsbesondere bei Custom-Roms anders verhält oder gar nicht funktioniert. Durch die erwei-terten Rechte ist es möglich auch auf Angebote zuzugreifen, für die das Gerät nicht gedacht istoder Änderungen an der Struktur einer Applikation durchzuführen. Dies geschieht beispiels-weise auf den normalerweise verborgenen Zugriff auf interne System-Datenbanken, die danngelöscht oder geändert werden 21. Die Android-Version des Bezahlfernsehens- und Streaming-Video-Anbieters sky schließt daher alle Geräte mit einem Root-Zugriff aus. Der Ausschlusshat Sicherheitsgründe, um die Nutzung der Kanäle ohne Berechtigung zu verhindern und diekorrekte Ausführung des DRMs sicherstellen zu können.22

4.6. Netzwerkverbindung

Die Netzwerkverbindung ist ein kritischer Teil in einer Android-Anwendung. Auf einem ge-wöhnlichen Desktop-Computer ist in Deutschland mittlerweile ein Breitbandinternetanschlussin über 30 Millionen Haushalten, also knapp 75% der Haushalte, der Standard. Zählt man dieSchmalbandanschlüsse wie zum Beispiel analoge Integrated Services Digital Network (ISDN)-Anschlüsse oder UMTS-Surfsticks23 dazu, liegt die Verbreitung von Haushalten mit Inter-netanschluss sogar bei ungefähr 79%. Geht man von 81% der Haushalte mit einem Desktop-Computer aus, besitzen nur knapp 2% gar keinen und nur 4% einen eventuell langsamen Inter-netanschluss. 24 Es ist daher davon auszugehen, dass wegen der geringen Anzahl der Desktop-Computer Nutzer, die über kein Internet verfügen, ein Programm welches im signifikantenMaße auf die Nutzung mit Internetdiensten angewiesen ist, trotzdem erfolgversprechend seinkann. Zudem ist der Anteil der Breitbandanschlüsse mit 96% sehr hoch. Eine schnelle In-ternetverbindung kann daher vorausgesetzt werden. Zudem sind heutige Desktop-Computerselbst im Einstiegsbereich relativ schnell und können auch komplexere Internet-Anwendungendarstellen.21Applikation zur Durchführung der Änderungen: https://play.google.com/store/apps/details?id=com.

speedsoftware.sqleditor&hl=de22Siehe: http://www.engadget.com/2012/02/20/sky-go-android/23USB-Sticks, die über einen Anschluss für subscriber identity module (SIM)-Karten und über eine UMTS-

Antenne zum schnellen mobilen Abruf von Internetdiensten verfügen.24[Bundesamt, 2012], weitere Statistiken zu finden auf: https://www.destatis.de/DE/Publikationen/Thematisch/

EinkommenKonsumLebensbedingungen/PrivateHaushalte/PrivateHaushalteIKT.html

22

Bei Smartphone Nutzern ergeben sich jedoch hinsichtlich der Geschwindigkeit des Gerätesund der Internetverbindung einige Probleme. Rund 72%25 der Smartphone Besitzer rufen In-ternetangebote über eine im Mobilfunkvertrag festgelegte Internetflatrate ab. Mit der Flatratekann prinzipiell unbegrenzt im Internet gesurft werden. Oftmals gibt es jedoch Datenverbin-dungsobergrenzen. Hat ein Nutzer beispielsweise mehr als 200 MB Datenvolumen verbraucht,wird die Zugriffsgeschwindigkeit auf das Internet auf EDGE-Geschwindigkeit heruntergestuft.Dadurch verringert sich die Geschwindigkeit dramatisch, von 21 Mbit/s auf im Idealfall 220Kbit/s beziehungsweise sogar auf oftmals 64 Kbit/s oder darunter im realen Einsatz.26 DerDownload eines Videos mit mehreren hundert MB wird dabei zu einer Geduldsprobe oderfunktioniert gar nicht erst. Es gibt noch einige weitere verschiedene Tarife bei deutschen Mo-bilfunkanbietern.

• Volumenflatrate: Es wird ein bestimmtes Datenvolumen zu einem Festpreis zur Verfü-gung gestellt. Alles was darüber hinaus geht wird in der Regel wie bei der Volumenab-rechnung behandelt.

• Zeitflatrate: Es wird eine bestimmte Anzahl von Minuten oder Stunden zu einem Fest-preis zur Verfügung gestellt. Wird das Internet darüber hinaus abgerufen, wird meistenwie bei der Zeitabrechnung weiter abgerechnet.

• Volumenabrechnung: Erfolgt keine Buchung einer spezielle Flatrate Option, wird je nachAnzahl der übertragenen MB ein bestimmter Betrag fällig.

• Zeitabrechnung: Es entstehen meist im Minutentakt zu einem bestimmten Preis Kosten,die der Nutzer zahlen muss.

• Flatrates: Bei den Flatrates gilt es neben den Volumenbegrenzungen noch zu bceach-ten, dass manche Geschwindigkeiten wie beispielsweise LTE27 oder Internetdienste wieInternet-Telefonie28 generell ausgeschlossen werden.

4.6.1. Multitasking

Die Anzahl der Nutzer, die nicht über eine Flatrate für das mobile Internet oder über einelangsamere Verbindung, bedingt auch durch Herabstufungen der Geschwindigkeit, verfügenist deutlich höher, als bei den Desktop-Computer Nutzern. Es ist also wünschenswert, dieAnzahl der übertragenen Daten möglichst klein zu halten und die Übertragung nur wenn nötig25Ermittelt über Befragung von 3.248 Personen durch: [Focus, 2012]26http://www.t-mobile.de/T-D1/cds/Shop/td1_cms_tarifdetailPopup/1,12260,3147,00.html„Ab einem Daten-

volumen von 200 MB wird die Bandbreite im jeweiligen Monat auf max. 64 KBit/s (Download)“27Neuer Mobilfunkübertragungsstandard, der deutlich schnellere Übertragungsraten in abgelegeneren Or-

ten und auch im Heimnetzwerk ermöglichen soll. Siehe auch: http://de.wikipedia.org/wiki/Long_Term_Evolution

28Die Telefonie über das Internet. Also wenn mindestens ein Gesprächspartner sein Gespräch über einenInternetdienstleister wie Skype über das Internet laufen lässt.

23

aufzubauen. Daher werden im StuReSy-Projekt die abzufragenden Daten möglichst einfachcodiert und klein gehalten. Falls eine Verbindung extrem schlecht und eine Frage inklusiveAntworten und eventuell einem Bild doch mal etwas größer ist, werden die Daten zudem ineinem eigenen Thread geladen. Dadurch bleibt der Main-Thread, auch UI-Thread gennant,weiterhin für Eingaben aktiv und nutzbar. Würde der Download über den UI-Thread erfolgen,blockiert die Oberfläche und ist solange nicht benutzbar, wie der Download läuft.Threads sind leichtgewichtige Prozesse, in denen unabhängig Rechenarbeiten ausgeführt

werden. Auch auf Geräten mit nur einem Prozessorkern gibt es Multitasking beziehungsweiseMultithreading, hierbei werden im Betriebssystem immer mehrere Threads gestartet und ver-schränkt abgearbeitet. Dadurch entsteht ein Verhalten, dass dem eines Systems mit mehrerenProzessorkernen gleicht. Theoretisch kann ein Prozessorkern nämlich nur eine Anweisung zurZeit ausführen. Das Betriebssystem verfügt über die Betriebsmittel und stellt sie den einzelnenThreads zur Verfügung. Einem Thread werden die Betriebsmittel beziehungsweise die Rechen-zeit daher mehrfach entzogen, einem anderen Thread und dann wieder dem ursprünglichenThread zugewiesen. Diese ineinander verschränkte Ausführung von Threads und Prozessengeschieht dauerhaft und für einen Thread so lange, bis dieser mit der Abarbeitung seinerAufgaben fertig ist.Dieses Konzept der Auslagerungen auf Threads ist auch in weiteren Bereichen sinnvoll, da

der UI-Thread nur über eine begrenzte Speicherzuweisung und Leistung verfügt. Daher wirdauch bei umfangreichen und rechenintensiven Aufgaben, wie dem dekodieren von AdvancedEncryption Standard (AES) kodierten Texten ein Thread zur Abarbeitung im Hintergrunderzeugt. Die Oberfläche bleibt bedienbar und kann die Ergebnisse unter anderem über Handler-Klassen erhalten und weiterverarbeiten. Android bietet in der API Klassen für Threads undHandler die geerbt und modifiziert werden können. Im Vergleich zu Java werden in Androidalle Applikationen in einer eigenen Laufzeitumgebung, die durch einen eigenen Linux-Prozessabgebildet wird, ausgeführt. Stürzt nun ein Thread oder die komplette Applikation ab, wirddie Systemfunktionalität dadurch nicht beeinträchtigt. Das Betriebssystem kann versuchendie Applikation wieder herzustellen und darauf zu warten, dass sie wieder reagiert. Falls bei-spielsweise ein Anruf auf das Smartphone eingeht, kann dieser angenommen werden, obwohldie Applikation im Vordergrund abgestürzt ist.In Java braucht ein Thread ein Objekt, dass das Interface Runnable implementiert. Im

Runnable-Objekt muss die run-Methode implementiert werden. Die eigentliche Ausführungder Anweisung geschieht in dieser Methode. Nach dem Start des Threads beziehungsweisedem darin laufenden Runnable-Objekt, wird unabhängig vom Main-Thread die Methode aus-geführt und abgearbeitet. Dieses Verhalten ist jedoch relativ anfällig für Fehler. Möchte manbeispielsweise in einem Thread ein Bild herunterladen und dann dem UI-Element ImageViewzuordnen, kann das nicht ohne weiteres im Thread mit dem Download geschehen. Es würdeeine CalledFromWrongThreadException geworfen werden, welche einen Absturz zur Folge hät-

24

te. Der Grund liegt in der Thread-Unsicherheit des Android-UI Konzeptes. Die UI darf nurvom UI-Thread bearbeitet werden, um Fehler zu vermeiden.Es gibt mehrere Möglichkeiten dieses Problem zu vermeiden. Mit jeweils eigenen Vor- und

Nachteilen.29

• Activity.runOnUiThread(Runnable) - Mit dieser Methode kann eine Anweisung auf demUI-Thread ausführt werden. Die Anweisung wird dann der Warteschlange des UI-Threadhinzugefügt oder sofort ausgeführt.

• View.post(Runnable) - Die runnable läuft nur für das UI-Element, aber auf dem UI-Thread.

• View.postDelayed(Runnable, long) - Gleiche Ausführung wie bei der oberen Methode,jedoch mit der Angabe einer Wartezeit, nach der die Anweisung ausgeführt werden soll.

• Handler - Ein Handler wird immer einem Thread und dessen Mitteilungswarteschlangezugewiesen. Mit diesem können Nachrichten vom Ausführungsthread zum UI-Threadweitergeleitet werden. Dieses Konzept wird unter anderem verwendet, wenn man einenStatusbalken aktualisieren möchte. Es wird beispielsweise in einem 2. Thread eine kom-plexe Berechnung oder das rekursive Durchsuchen von Ordnern durchgeführt und jenach dem wie weit die Berechnung fortgeschritten ist, wird der Balken aktualisiert.

Der Handler hat den Vorteil, dass er für mehr Zwecke genutzt werden kann, als die anderen.Soll wie im Eingangs erwähntem Beispiel ein Bild aus dem Internet herunterladen und danachdirekt anzeigt werden, müssen bei den ersten drei Methoden entweder mehrere Threads star-ten oder wieder Aufgaben auf dem UI-Thread ausführen. Da dies nicht erwünscht ist, kannmit Hilfe des Handler-Objektes ein Thread den Download überwachen und dem UI-Threaddann den erfolgreichen Download mitteilen. Der UI-Thread kümmert sich daraufhin selbst umdie korrekte Anzeige. Besondere Aufmerksamkeit gilt der korrekten Beendigung der Threads.Zwar gibt es die Methode Thread.stop diese ist aber deprecated, soll also nicht mehr benutztwerden. Das liegt an den Aktionen die durchgeführt werden, wenn die Methode aufgerufenwird. Der Thread wird zwar sofort gestoppt und alle seine Sperren freigegeben, dadurch kannes aber Probleme mit Objekten geben. Führt ein Thread komplexere Aktionen auf einemObjekt durch und alle Sperren werden sofort freigeben, kann sich das Objekt in einem inkon-sistenten oder nicht definiertem Zustand befinden. Auch eventuelle Zwischenergebnisse könnennicht beispielsweise auf der Konsole ausgegeben werden. Theoretisch kann die ThreadDeathAusnahme abgefangen werden und das Objekt in einen konsistenten Zustand zurück versetztwerden. Das ist aber nicht praktikabel, da zum einen vorher nicht klar ist, wann diese Aus-nahme auftreten wird und die Ausnahme zum anderen auch mehr als einmal auftreten kann.[Oracle, 2012]29http://android-developers.blogspot.de/2009/05/painless-threading.html

25

Die Benutzung ist jedoch umständlich, da die Rechenaufgaben beziehungsweise Netzwerk-zugriffe im Thread abgearbeitet werden und der Handler auf die Beendigung der Aufgabenwartet und die Ergebnisse der Klasse mitteilt, die den Thread gestartet hat. Damit Entwicklerdieses Verhalten nicht von Hand nach programmieren müssen, bietet die API die HilfsklasseAsyncTask (Siehe: 7.2). Mit der Klasse ist es relativ einfach möglich das gewünschte Verhaltenzu programmieren.30

4.7. Berechtigungssystem

In Android gibt es ein relativ ausgefeiltes und komplexes Berechtigungssystem. Berechtigun-gen werden benötigt, um auf bestimmte Teile und Funktionen der Soft- oder Hardware desGerätes als Entwickler zugreifen zu können. Diese Berechtigungen werden vom Entwicklervon den Nutzern eingefordert. Die Nutzer sehen diese Berechtigungen vor der Installationund können selbst entscheiden, ob sie dem Entwickler diesen Zugriff erlauben möchten. Ver-weigern die Nutzer die Annahme, kann die Applikation nicht installiert und benutzt werden.Kritische Berechtigungen sind Beispielsweise der Zugriff auf die Daten der im Gerät gespei-cherten Kontakte, da dadurch je nach Anwendung ungewollt Daten zur Spionage des Nutzersgesammelt werden können. Auch der Versand von Kurzmitteilungen sollte nur wenigen Ap-plikationen zugelassen werden, da Schadsoftware über diese Berechtigung teure Mitteilungenan Premium-Anbieter versenden kann. Es ist zum Teil auf Geräten mit Root-Zugriff möglichdie Berechtigungen auch nach der Installation mit Hilfe von speziellen Applikationen anzu-passen.31 Es kann jedoch in der Regel nicht garantiert werden, dass der Schutz komplettwirksam ist oder die komplette Funktionalität der einzuschränkenden Applikation erhaltenbleibt. Die in StuReSy Android benutzten Berechtigungen werden unter dem Abschnitt: 7.3näher erläutert.

30Quelle: [Gunasekera, 2012]31https://play.google.com/store/apps/details?id=com.lbe.security.lite

26

5. Prototyping der mobilen StuReSy Anwendung

Im folgenden werden die ersten Schritte der Entstehung der Android Applikation skizziert undGründe für bestimmte Entscheidungen genannt.

5.1. Verbesserungen

Ausgehend von Abschnitt 3.5, ergeben sich ein paar wichtige Punkte, in denen man die Ober-fläche besser gestalten und um Funktionen erweitern kann.

• Darstellung: Die Oberfläche ist sehr schlicht gehalten und lässt wichtige Informationenvermissen. Die Antworttexte sind nicht ersichtlich. Von den Nutzern wird also ein Ab-gleich der Buttons und der Projektionsfläche erwartet. Dies ist ein relativ komplexesUnterfangen, da die Konzentration zwischen der Leinwand und dem eigenen Bildschirmgewechselt werden muss. Dadurch können einige Fehlabstimmungen auftreten.

• Ablauf: Der Ablauf zur Darstellung einer Frage sollte vereinfacht werden. In der Appli-kation sollte also idealerweise der Scan-Vorgang gestartet und direkt die Abstimmunganzeigt werden. Die Suchfunktion sollte ebenfalls übernommen, angepasst werden undleichter zugänglich sein. Der Umweg über eine andere Seite nur zum Suchen ist zu ver-meiden.

• Sicherung der Vorlesungen: Ausgehend davon, dass das StuReSy-Projekt in jeder Art vonVorlesung benutzt werden kann, ist es sehr aufwändig, besonders bei dem Besuch meh-rerer StuReSy unterstützter Vorlesungen, wenn ein Nutzer sich die einzelnen Kennungenfür die Vorlesung merken muss. Es wäre einfacher, wenn stattdessen das Programm dieseAufgabe übernimmt und eine Übersicht mit allen zur Zeit besuchten Vorlesungen bie-tet. In dieser könnte der Nutzer auf eine Vorlesung klicken und es wird umgehend dieaktuelle Umfrage zu der Vorlesung angezeigt.

• Sicherung der bereits beantworteten Fragen: Zur besseren Nachbearbeitung der Vorle-sung ist eine Übersicht sinnvoll, in der alle bereits beantworteten Fragen zusammen mitder gegebenen Antwort angezeigt werden. Die Fragen können dann erneut durchdachtund ohne eine wiederholte Abfrage bearbeitet werden.

• Suchen oder Scannen von Vorlesungen: Der Scanvorgang ist zurzeit nur auf Smartphonesund Tablets einigermaßen möglich, allerdings wird dafür eine zusätzliche Applikationauf dem Gerät benötigt. Diese muss von den Nutzern selbst ausgesucht werden, mitschwankenden Ergebnissen in der Erkennung von QR-Codes. Außerdem ist es in derOberfläche nicht möglich direkt nach einer neuen Vorlesung zu suchen, falls bereits eineFrage geöffnet ist. Das Anwählen der Vorlesung sollte daher einfacher und intuitivervonstatten gehen.

27

• Benachrichtigung über neue Fragen: In der jetzigen Version muss der Nutzer selbst durchklicken des Reload -Buttons dafür sorgen, dass ihm die jeweils aktuelle Frage angezeigtwird. Sollte eine neue Frage vorliegen, ist eine Erinnerung denkbar, die auch dann er-scheint, wenn das StuReSy-Fenster zu dem Zeitpunkt gar nicht geöffnet ist. Der Nutzerkönnte auf die Benachrichtigung klicken und einen Lade- und Anzeigevorgang durchfüh-ren.

• Eigenständiges Nachladen neuer Fragen: Diese Funktion geht in eine ähnliche Richtungwie der obige Punkt. Ist die Oberfläche aktiv geöffnet könnte automatisch die jeweilsaktuelle Frage geladen und angezeigt werden. In dem Kontext sind mehrere Arten derRealisierung möglich: Die Frage wird in vorher definierten Zeitintervallen aktualisiertoder der Server sendet eine Benachrichtigung und der Client aktualisiert daraufhin au-tomatisch die Frage. Dabei ist zu beachten, dass der Nutzer deutlich informiert wird,dass eine neue Frage geladen wurde, um falsche Abstimmungen aufgrund des gleichenLayouts der Fragen zu vermeiden.

• Fragen stellen: Ähnlich wie die Twitter-Wall ist eine Funktion denkbar, in der NutzerFragen an den Dozenten übermittelt. Der Kurznachrichtendienst Twitter zeigt alle Fra-gen zu einem Account in einer Übersicht an. Der Dozent könnte Fragen dann analog ab-rufen, sich anschauen und beantworten. Erkennt der Dozent eine Regelmäßigkeit in denNachfragen, könnten bestimmte Teilgebiete, die offenbar noch nicht verstanden wurden,erneut thematisiert werden. Die Funktion bietet besonders für schüchterne Teilnehmerdie Möglichkeit aktiv an der Vorlesung teil zu nehmen.

5.2. Mock-Up

In diesem Abschnitt werden die ersten Mock-Ups zum StuReSy Android-Projekt vorgestelltund erläutert.Der Bildschirmausschnitt 14 zeigt die Hauptoberfläche von StuReSy Android. Im oberen

Teil sieht man eine ActionBar 4.4.5, die entsprechend der Google Guidlines gestaltet wurde.Es gibt mehre Objekte in der Leiste:

• Reload Button: Ein Button zur manuellen Aktualisierung der Vorlesung.

• Search Button: Ein Button, um anhand eines Suchbegriffes eine Vorlesung zu finden undan der Umfrage teilzunehmen.

• Settings Button: Öffnet die Einstellungen, um eine neue System-URL anzugeben in derdie Vorlesungsumfragen gesucht werden oder die Lizenzbestimmungen anzuzeigen.

• Scan Button: Führt per interner Kamera die Analyse eines QR-Codes mit Informationenzu einer Vorlesung durch.

28

[ ]

Abbildung 14: Hauptfenster StuReSy Android Mock-Up

Eine Übersicht über die Abstimmung für eine Frage ist in Abbildung 15 dargestellt. Es wirdauch die Möglichkeit gezeigt ein zu der Frage gehöriges Bild abzubilden. Oberhalb des Bildesist die zu beantwortende Frage, unterhalb die Antwortmöglichkeiten mit zugehörigen Radio-buttons und einer Bildlaufleiste für weitere nicht dargestellte Antwortmöglichkeiten. Mit demuntersten Knopf, wird die Antwort an den Server gesendet. Nach der Abstimmung erscheintein Informationsfenster, ob die Stimme erfolgreich eingetragen wurde. Werden rechenintensiveAufgaben oder solche, die eine Kommunikation mit einem Server beinhalten durchgeführt,zeigt eine drehende Fortschrittsanzeige an, dass die Applikation noch läuft und rechnet.Nach einem Klick auf den Tab Lectures (Abbildung: 16) erscheint eine Übersicht mit den

bisher besuchten Vorlesungen. Wird ein Element der Liste angeklickt, öffnet sich falls möglichdie aktuelle Frage.Wird ein Tablet quer bei einer Abstimmung gehalten, erscheint eine andere Ansicht (Abbil-

dung: 17). Da Tablets über größere Bildschirme und oft auch höhere Auflösungen als Smart-phones verfügen, passen in die ActionBar sowohl die ActionBar-Items, als auch die Tab-Navigationsleiste. Zusätzlich ist in der ActionBar Platz für einen weiteren direkten Scan But-ton. In der Tablet-Version werden mehrere Oberflächen miteinander verbunden. Durch dengroßen Platz ist es möglich, die ausgewählte Vorlesung bei Bedarf auf der linken Seite in der

29

[ ]

Abbildung 15: Abstimmungsoberfläche StuReSy Android Mock-Up

Liste der Vorlesungen anzeigen. In der rechten Hälfte des Bildschirmes wird die aktuelle Frageangezeigt. Dadurch gibt es einer bessere Übersicht und es kann leichter zwischen einzelnenVorlesungen gewechselt werden.Fragen an den Dozenten werden einfach in das Textfeld eingegeben und an den Server

gesendet (Abbildung: 18). Der Dozent kann dann darauf reagieren.

30

[ ]

Abbildung 16: Liste der Vorlesungen StuReSy Android Mock-Up

[ ]

Abbildung 17: Liste der Vorlesungen optimiert für Tablets StuReSy Android Mock-Up

31

[ ]

Abbildung 18: Frage stellen Oberfläche StuReSy Android Mock-UpDie Aufnahmen wurdenmit dem Programm WireframeSketcher Studio erstellt

32

6. Bibliotheken, Frameworks und genutzte Programme

In der Android-Version von StuReSy wird eine kleine Menge von externen Bibliotheken be-nutzt, die im Folgenden vorgestellt werden.

6.1. ActionBarSherlock

ActionBarSherlock spiegelt einen Teil der ab API 11 verfügbaren Methoden und Klassen, umeine einheitliche Benutzung und Verwendung des ActionBar Designpatterns zu ermöglichen.32

ActionBarSherlock bietet unter allen Android-Versionen das gleiche Nutzererlebnis, durch glei-che Funktionen, Benutzung und gleiches Aussehen. Die Benutzung ist relativ einfach, da fürGeräte ohne ActionBar diese nicht selbst programmiert werden muss und im Gegensatz zurKompatibilitätsbibliothek auf die gleiche Weise genutzt werden kann. Auch das Konzept derFragmente, die Navigation in Tabs und Klassen wie ListFragment werden unterstützt. DieActionBar lässt sich mit dem Framework deutlich leichter personalisieren, Farbe und Erschei-nungsbild lassen sich unkompliziert anpassen.

6.2. ACRA

Die ACRA33 Bibliothek stattet eine Applikation mit einem Fehlerverfolgungstool aus, welchesfür den Fall einer Java Ausnahmesituation Informationen wie den Stacktrace, die Hardware-und Softwareversionen und weiteres an den Entwickler sendet. Wird die Applikation über denPlay Store vertrieben, bietet Google auch ein eigenes Fehlerverfolgungstool an, welches nachvorheriger Bestätigung des Nutzers Abstürze übermittelt. Das Tool lässt sich aber nicht nut-zen, wenn man wie im Falle der StuReSy Android-Applikation die Applikation unabhängigvertreibt. ACRA lässt dem Programmierer die Wahl, ob die Nutzer die Entscheidungsfreiheithaben, über Abstürze zu berichten. Es können also bei jedem Absturz oder nach Rückfrageund Bestätigung des Nutzers die Reporte versendet werden. Der Nutzer kann über einen Ab-sturz auf verschiedene Arten informiert werden. Über Toast Notifications erscheint ein Fensterdirekt auf dem Bildschirm, es kann ein Dialog gestartet werden, die Statusleiste den Fehleranzeigen oder es wird nicht sichtbar ein Report über den Aufruf eines Internetskripts über-mittelt. Außerdem gibt es im Vergleich zu Googles Lösung mehr Einstellungsmöglichkeitenund Anzeigeoptionen. Es können Berichte auch ohne Absturz oder mehr Informationen als imNormalfall gesendet werden. Die Daten werden in ein Dokument des Programmierers auf derGoogle Docs Plattform eingetragen. Von dort können sie gesichtet, bearbeitet und exportiertwerden. Seit der Android-Version 4.1 wurde auch ein neues System zur Meldung von Abstür-zen durch Nutzer eingeführt. Nach einem Absturz kann der Nutzer automatisch einen Berichtversenden. Es werden ebenfalls Daten wie der Stack-Trace, System Informationen, wie Bei-

32Siehe: [Wharton, 2012]33 http://acra.ch/ Copyright 2012 Kevin Gaudin

33

spielsweise der Prozessstatus und seit 4.2 ein Bildschirmfoto der Applikation zum Zeitpunktdes Fehlers gesammelt. Diese können auf Nachfrage durch den Nutzer per E-Mail gesendetwerden. Außerdem ist es möglich manuell einen Bericht über die entsprechende Einstellungs-seite zu senden. Diese Informationen helfen dem Entwickler zum Teil sehr, jedoch gibt derNutzer dadurch eventuell ungewollt private Daten über sich Preis.

6.3. ZXing

ZXing ist eine Applikation, die genutzt wird, um QR-Codes auslesen zu können. Der zuvorvon StuReSy erzeugte QR-Code mit der URL und Vorlesungsinformationen wird beispiels-weise vor die Kameralinse des Gerätes gehalten und analysiert. Ein Algorithmus wertet dieInformationen aus und gibt eine URL zurück, die auf die Vorlesung verlinkt.

[ ]

Abbildung 19: QR-Code, Quelle: http://www.qrcode-generator.de/

Die drei großen Vierecke dienen zur Positionsbestimmung, das kleine zur Ausrichtung. Überdem linken unteren Viereck sind Informationen über die Versionsnummer, rechts neben demViereck über das Datenformat. Zusätzlich sind diverse Daten redundant codiert, um Fehler-korrekturen durchführen zu können. Die Größe des maximal zu codierenden Textes ist auchvon der Wahl des Zeichensatzes abhängig. Dieser wird auch im Code definiert, werden nurZahlen verwendet können beispielsweise die meisten Zeichen kodiert abgespeichert werden.Die einzelnen Zeichen des Textes werden mit Bitfolgen je nach Zeichensatz kodiert und dieletzten vier Zeichen sollen mit 0000 markiert werden.34

6.4. JSON

JSON ist ein Format um Daten auszutauschen und steht damit in Konkurrenz zu XML,welches in diesem Projekt auch genutzt wird. JSON ist relativ einfach gestaltet und kannauch von einem Menschen gelesen, geschrieben und geparst werden.35 Das Format basiertzum Teil auf der JavaScript Programmiersprache, ist davon jedoch unabhängig und kann alsTextdokument in nahezu jeder modernen Programmiersprache verarbeitet werden. Es werden

34Siehe: http://de.wikipedia.org/wiki/QR-Code35Siehe: [Group, 2012]

34

nur programmiersprachliche Konzepte verwendet, die mittlerweile zum Standard Repertoireauch anderer moderner Programmiersprachen gehören. Den Java Objekten folgend basiert einDokument aus einem Array, welches mit eckigen Klammern [] abgegrenzt wird.In diesem Array befinden sich mehrere verschiedene Komma separierte Werte.

• Objekt

• True oder False

• String

• Number

• Array

• Null

Jeder Wert in einem Array wird von geschweiften Klammern umgeben. Die Objekte habeneine ungeordnete Menge an Paaren, welche von Kommata separiert werden, aus einem StringBezeichner und einem Wert, getrennt von einem Doppelpunkt :. Strings werden zudem vonAnführungszeichen ““ eingeschlossen und können bis auf den leeren String und Backslash ausjedem Unicode kodierten Schriftzeichen bestehen. Aus einem Objekt lässt sich in Java eineHashMap aus String Namen und Werten konstruieren. Eine Number ähnelt der Entsprechungin Java. Im Vergleich zu XML ist JSON durch eine geringe Anzahl von Regeln und Werteneinfacher les- und verwendbarer. Zudem wird oftmals Overhead36 gespart, was besonders beiDatenübertragen mit mobilen Endgeräten wichtig sein kann. In XML können zudem Wer-te entweder als weitere Kindknoten oder Attribute definiert werden, wodurch eventuell dieÜbersicht und das Verständnis im Gegensatz zu JSON leiden kann. XML ist jedoch in Kon-zeption und Zweck deutlich mächtiger und vielseitiger einsetzbar als JSON. In PHP gibt esFunktionen um JSON Arrays dekodieren oder encodieren zu können. Für die Benutzung inJava sind normalerweise zusätzliche Klassen oder Bibliotheken notwendig. Die Android-APIbietet jedoch bereits mehrere entsprechende Klassen im Paket org.json. Aufgrund der leichten,intuitiven Verwendbarkeit und der guten Anbindung in PHP und Java, wird bei StuReSy zumTeil auf JSON gesetzt. Die weitere Nutzung wird im Kapitel 7 im Abschnitt 7.2 im Zuge derNetzwerkkommunikation auf Seite 44 näher erläutert.

6.5. Lizenzen

ActionBarSherlock und das ACRA Framework stehen unter der freien Apache-Lizenz 2.0. DieLizenz gestattet es die Software zu verwenden, modifizieren und zu vertreiben. Es müssenjedoch im Projekt eine Kopie der Lizenzbedingungen, die Namen der Urheber und Angaben

36Beispiel siehe: http://de.wikipedia.org/wiki/JavaScript_Object_Notation

35

zu Modifizierungen vorliegen. Programme die Software dieser Lizenz beinhalten, müssen nichtan den Urheber gemeldet werden und können einer anderen Lizenz als der Apache-Lizenz un-terliegen. Es ist daher aus den genanten Gründen keine Copyleft-Lizenz, da in einer solchenKlausel festgelegt ist, dass das aus Softwareprodukt die gleichen Lizenzen haben muss wiedie Lizenzen der benutzten Teile. Kommerzieller Vertrieb von unter Open-Source stehenderSoftware wird damit ausgeschlossen.37 Große Teile des Android-Betriebssystems stehen eben-falls unter der Apache-Lizenz. Ausnahmen sind der Betriebssystemkern und vorinstallierteAnwendungen.StuReSy steht unter der GNU Affero GPL (AGPL), dass bringt ein paar Einschränkungen

mit sich. Es ist eine Copyleft-Lizenz, daher ist es erforderlich, dass auch die Android-Versionvon StuReSy unter dieser Lizenz verteilt wird. AGPL ist für ein Client- und Server-basiertesSoftwareprojekt konzipiert. Im Zuge dessen müssen im Gegensatz zur GPL alle Quelltexteöffentlich zugreifbar sein und die Lizentz in jeder Quelltextdatei sichtbar sein38.

6.6. Genutzte Programme und Vorlagen

Im Folgenden werden kurz die zur Entwicklung der Android-Anwendung und Erstellung dieserBachelorarbeit verwendeten Programme und Vorlagen skizziert.

• Eclipse Indigo wurde zur Programmierung der Android-Anwendung genutzt.

• Das Android SDK wird zur Kompilierung und Ausführung des Codes gebraucht. Diesesbietet auch die grundsätzliche Vorlage für die Entwicklung einer Android-Anwendung.

• Für die Anwendung wurden kostenpflichtige Icons genutzt, die von Günther Bayer stam-men und unter einer royality-free Lizenz stehen. Diese Lizenz erlaubt unter gewissen Ein-schränkungen unbegrenzte Nutzung und kommerzielle Verarbeitung, ohne einen Verweisauf den Ersteller geben zu müssen. Die Kopierschutz- und ähnliche Rechte behält trotz-dem der Urheber.39

• Die Mock-Ups wurden mit der Testversion von WireFrameSketcher erstellt.

• TEXMaker wurde zur Erstellung und Ausführung der TEX-Dateien verwendet.

• Das Layout und die Vorlage dieser Bachelorarbeit stammt von Marius Fink, wurde fürden Fachbereich Informatik ITG an der Universität Hamburg entworfen und angepasst(http://www.mariusfink.org/index.php?link=latexvorlage).

• LimeSurvey wurde zur Erstellung der Umfrage und deren Auswertung genutzt.

• Zusätzlich kamen weitere übliche Text- und Bildbearbeitungsprogramme zum Einsatz.

37http://de.wikipedia.org/wiki/Copyleft und http://de.wikipedia.org/wiki/Apache-Lizenz38http://www.gnu.org/licenses/agpl-3.0.de.html39Siehe: http://www.androidicons.com/

36

7. Implementation

Im Zuge der Implementation des Projektes sind diverse zum Teil durch Google vorgegebeneEntwurfsmuster und Erfolgsmethoden zum Einsatz gekommen. Ein paar von diesen werdenin den folgenden Abschnitten näher erläutert.

7.1. Kryptographie und Verschlüsselung

Die Verschlüsselung ist ein wichtiger Teil der mobilen Applikation. Es werden grundsätzlichalle ausgehenden Aufrufe, also auch die Übermittlung der abgegebenen Stimme verschlüsselt.Der Text mit der ID des Nutzers und seiner Antwort werden daraufhin nicht im Klartextübertragen und können nur schwer rekonstruiert werden. In diesem Kapitel wird sich zu großenTeilen auf [Beutelspacher u. a., 2006, Kapitel 2], [Dankmeier, 2006, Kapitel 3 und 6] undteilweise auf [Gunasekera, 2012, Kapitel 5] bezogen.

7.1.1. Symmetrische Verschlüsselung

Bei der symmetrischen Verschlüsselung erhalten Sender und Empfänger jeweils den gleichennur ihnen bekannten geheimen Schlüssel. Mit diesem lässt sich eine Nachricht sowohl ver- alsauch entschlüsseln. Der Sender wendet mit Hilfe des Schlüssels einen Algorithmus auf denKlartext an. Aus diesem ergibt sich ein verschlüsselter und von Menschen nicht auf Anhiebzu lesender Text aus einer willkürlich anmutenden Kombination an Zeichen. Diese Nachrichterhält der Empfänger, der wiederum den gleichen Schlüssel mit dem zugehörigen Algorithmusauf die verschlüsselte Nachricht anwendet. Daraus ergibt sich wiederum der Klartext.Ein bekannter Verschlüsselungsalgorithmus ist der Data Encryption Standard (DES). Der

Algorithmus wurde als Auftrag der US-Regierung in den 70er Jahre von International BusinessMachines Corporation (IBM), der National Security Agency (NSA) und weiteren entwickelt.Bei der Verschlüsselung wird der Klartext in verschiedene 64-Bit große Blöcke zerlegt. JederBlock wird dann einzeln verschlüsselt. Der Schlüssel ist 64-Bit groß, wobei jedes 8. Bit als Pa-ritätsbit genutzt wird, um fehlerhafte Übertragungen an einem falschen Bit leichter erkennenzu können. Es ergibt sich ein effektiv 56-Bit großer Schlüssel. Die Blöcke werden allgemeinpermutiert und substituiert und durchlaufen 16 Runden, bevor die Teile zusammen gesetztwerden. In jedem Durchgang werden die zuvor noch einmal halbierten Blöcke unter anderemmit einem Teil des Schlüssels durch eine ausschließende Disjunktion verknüpft. Die Sicherheitder Verschlüsselung hängt von der Wahl des Schlüssels ab. Durch die geringe Schlüsselgrößewar es aber bereits ab 1998 möglich einen mit DES verschlüsselten Text in unter einer Wochezu entschlüsseln. Es wurden hierbei einfach alle möglichen Schlüssel der Reihe nach auspro-biert. Eingesetzt wird DES auch heute noch in Bankautomaten bei der Überprüfung der Karteund des PIN-Codes.

37

Um die Sicherheit des Verfahrens zu erhöhen, wird der DES als Tripple-DES benutzt, beidem der gesamte Algorithmus dreimalig durch laufen wird 40. Von den US-Behörden wird mitt-lerweile die Verschlüsselung AES verwendet. An symmetrischer Verschlüsselung allgemein istproblematisch, dass ein Schlüssel-Austausch stattfinden muss, bei dem der Schlüssel abgefan-gen und kompromittiert werden kann.

7.1.2. Asymmetrische Verschlüsselung

Die asymmetrische Verschlüsselung basiert im Gegensatz zur symmetrischen Verschlüsselungauf einem Konzept, in dem es einen privaten und einen öffentlichen Schlüssel gibt. Der Senderverschlüsselt seine Nachrichten mit dem öffentlichen Schlüssel des Empfängers. Diese Nachrichtkann vom Empfänger mit seinem privaten, nur ihm bekannten, Schlüssel entschlüsselt und derKlartext angezeigt werden. Der mit einem öffentlichen Schlüssel verschlüsselte Klartext kannim Idealfall nur mit dem privaten Schlüssel entschlüsselt werden.Dieses Konzept kann dann weiterentwickelt zur Authentifikation von Nutzern genutzt wer-

den. Es gibt dann insgesamt 2 Schlüssselpaare mit jeweils einem öffentlichen und einem pri-vaten Schlüssel. Der Nutzer besitzt seinen privaten Schlüssel und den öffentlichen Schlüsseldes Dienstes an dem der Nutzer zu authentifizieren ist. Der Dienst hat analog seinen priva-ten Schlüssel und den öffentlichen Schlüssel des Nutzers. Der Nutzer verschlüsselt den Textzuerst mit seinem privaten und dann mit dem öffentlichen Schlüssel des Dienstes. Der Dienstentschlüsselt analog zuerst mit seinem privaten und dann mit dem öffentlichen Schlüssel desNutzers. Nur wenn die richtigen Schlüssel angewandt wurden, erhält der Dienst den Klartextund kann sich sicher sein auch wirklich mit dem vorgegeben Nutzer zu kommunizieren.41

Anwendung findet die asymmetrische Verschlüsselung beispielsweise bei dem Netzwerkpro-tokoll Secure Shell (SSH), mit dessen Hilfe sich der Nutzer unter anderem auf entfernten Re-chensystemen authentifiziert und arbeitet, sowie bei dem (Rivest, Shamir und Adleman (RSA)-Verfahren. Die Erstellung der Schlüssel basiert auf dem Prinzip der Multiplikation zweiergroßer, ungleicher und zufälliger Primzahlen n = p ∗ q. Der öffentliche Schlüssel entsteht ausdem Ergebnis der Eulerfunktion φ und einer natürlichen zu φ(n) teilerfremden Zahl e.φ(n) = (p− 1) ∗ (q − 1)

Die Zahl d ist das multiplikative Inverse von e bezüglich φ(n) und stellt den geheimenSchlüssel dar. d ∗ e := 1 mod φ(n)Verschlüsselt und entschlüsselt wird mit den beiden folgenden Funktionen.

• Verschlüsselung: geheimtext := klartexte mod n

• Entschlüsselung: klartext := geheimtextd modn

40Siehe: http://de.wikipedia.org/wiki/Data_Encryption_Standard41Siehe: http://ddi.cs.uni-potsdam.de/Lehre/e-commerce/elBez2-5/page06.html

38

Nur aus N und e lässt sich der private Schlüssel d im Idealfall nicht berechnen. Das Verfahrenhat in der reinen Form jedoch ein paar Schwachstellen. So ist es bei hinreichend kleinem e undKlartext möglich die e-Wurzel aus dem verschlüsselten Text zu ziehen und so den Klartext zuerhalten. Das gilt genau dann, wenn geheimtext = klartexte < n ist.42

7.1.3. Hybride Verschlüsselung

Bei der hybriden Verschlüsselung wird sowohl die symmetrische, als auch die asymmetrischeVerschlüsselung angewandt. Es wird zunächst ein zufälliger symmetrischer Schlüssel generiert,der Session Key. Mit diesem Schlüssel wird symmetrisch die Nachricht verschlüsselt. An-schließend wird der Session Key asymmetrisch mit dem öffentlichen Schlüssel des Empfängersverschlüsselt und zusammen mit der verschlüsselten Nachricht übertragen. Der Empfängerentschlüsselt mit seinem privaten Schlüssel den Session Key und kann damit die Nachrichtsymmetrisch entschlüsseln.

7.1.4. Vergleich

Bei geeigneter Hardware-Unterstützung ist die symmetrische Verschlüsselung im Gegensatzzur asymmetrischen Verschlüsselung auch bei großen Datenmengen sehr schnell. Die asymme-trische Verschlüsselung ist daher nur bei kleinen Mengen praktikabel. Das liegt daran, dassdie asymmetrische Verschlüsselung auf der Berechnung von Primfaktoren beruht. Bei zu kleingewählten Primfaktoren kann mit Hilfe einer Primfaktoren Zerlegung und dem öffentlichenSchlüssel vergleichsweise schnell auf den privaten Schlüssel geschlossen werden. Die Prim-faktoren müssen daher dementsprechend groß sein. Die Berechnung großer Primzahlen undinsbesondere deren Zerlegung erfordert viel Rechenleistung.Der Schlüsselaustausch ein kritischer Punkt in symmetrischen Verschlüsselungsverfahren, da

bevor etwas verschlüsselt werden kann, der Schlüssel ausgetauscht werden muss. Bei diesemVorgang kann dieser kompromittiert werden und ist zwecklos. Der Schlüsselaustausch gestaltetsich in der asymmetrischer Verschlüsselung relativ unkompliziert, da nur der öffentliche, zurVerschlüsselung benutzte, Schlüssel übertragen wird. Dieser Vorgang ist unter den gegebenenEinschränkungen nicht sicherheitsrelevant. Hybride Methoden verbinden die Vorteile beiderVerfahren. Der vergleichsweise kleine Schlüssel des schnellen symmetrischen Verfahrens wirdnur verschlüsselt durch das langsame asymmetrische Verfahren übertragen.

7.1.5. Implementation

Für das StuReSy Android-Projekt wurden probehalber sowohl ein symmetrisches, als auch einasymmetrisches Verfahren implementiert. Im Einsatz ist zurzeit die symmetrische Variante.

42Siehe: http://de.wikipedia.org/wiki/RSA-Kryptosystem

39

Asymmetrische Verschlüsselung Die asymmetrische Verschlüsselung wurde durch RSA rea-lisiert.

Listing 1: RSA-Implementation

1

...

3

String test = "KorrekteAnfrage ," + map [0]. get("lecture") + ","

5 + map [0]. get("guid") + "," + map [0]. get("vote");

7 AssetManager manager = _fragment.getActivity ().getAssets

();

9 // Erstellt einen HttpClient und einen Post Header

HttpClient httpclient = new DefaultHttpClient ();

11 HttpPost httppost = new HttpPost(map [0]. get("url"));

try {

13

// Basierend zum Teil auf einer Vorlage von Joseph Wessner

http ://hdr.meetr.de/blog /2012/01/ rsa -mit -java -und -php

-teil -2-php -java/

15

//Liest den oeffentlichen Schluessel ein.

17

AssetFileDescriptor afd = manager.openFd("

serverPublicKey.der");

19 long size = afd.getLength ();

21 byte[] buffer = new byte[(int) size];

23

DataInputStream in = new DataInputStream(manager.open

("serverPublicKey.der"));

25

in.readFully(buffer);

27 in.close();

29 KeyFactory keyFactory = KeyFactory.getInstance("RSA")

;

40

RSAPublicKey publicKey = (RSAPublicKey) keyFactory

31 .generatePublic(new X509EncodedKeySpec(buffer

));

33 Cipher cipher = Cipher.getInstance("RSA/ECB/

PKCS1PADDING");

cipher.init(Cipher.ENCRYPT_MODE , publicKey);

35 // Verschluesselt den String mit Hilfe des Schluessels

und des Cipher Objekts.

byte[] encrypted = cipher.doFinal(test.getBytes ());

37

// Zur korrekten Uebertragung muss der String im

Base64 Html sicheren Format umgewandelt werden.

39 String encryptedText = Base64.encodeToString(

encrypted , Base64.URL\_SAFE)

.replace("==", "");

41

// Daten zur ArrayList hinzufuegen

43 ArrayList <NameValuePair > nameValuePairs = new

ArrayList <NameValuePair >(

5);

45

nameValuePairs.add(new BasicNameValuePair("mobile", "

android"));

47 nameValuePairs.add(new BasicNameValuePair("vote",

encryptedText));

49 httppost.setEntity(new UrlEncodedFormEntity(

nameValuePairs , "UTF -8"));

51

// Fuehrt den HTTP Post Auftrag aus und generiert aus

der Antwort einen Bolean , ob die Uebermittelung

geklappt hat.

53

HttpResponse response = httpclient.execute(httppost);

55 boolean result = Boolean.parseBoolean(EntityUtils.

toString(response.getEntity ()));

41

57 return String.valueOf(result);

} catch ...

Bevor der Nutzer die Applikation installiert wird bereits auf dem Server in einem Terminalein privater Schlüssel mit folgendem Befehl erstellt.

Listing 2: Private-Key Generierung RSA

1 openssl genrsa -out serverPrivateKey.pem 2048

Anhand des privaten Schlüssels wird analog ein öffentlicher Schlüssel erstellt. Dieser wird imProjektverzeichnis von StuReSy Android gespeichert und beim Installieren der Applikationauf alle Geräte übertragen. Der private Schlüssel bleibt im StuReSy Verzeichnis des Servers.

Listing 3: Public-Key Generierung RSA

1 openssl rsa -in serverPrivateKey.pem -pubout -outform DER -out

serverPublicKey.der

Wurde vom Nutzer der Senden Button betätigt, wird ein Objekt der Klasse PostAsync-Taks, die von AsyncTask 7.2 erbt, erstellt und die Abstimmungsinformationen übergeben. Inder Hauptmethode wird nun der öffentliche Schlüssel aus dem Applikationsverzeichnis ausge-lesen. Dazu wird zuerst mit einem Objekt der Klasse AssetFileDescriptor die komplette Größeausgelesen und ein Byte-Array mit dieser Größe erstellt. In das Byte-Array werden über einenDateninputstream die Daten geschrieben. Mit den Objekent KeyFactory und RSAPublicKeywird der öffentliche Schlüssel erstellt und sein Typ als öffentlicher RSA Schlüssel festgelegt.Wird der Schlüssel an ein Objekt Cipher, welches im Konstruktor mit den passenden Einstel-lung erstellt wurde, übergeben, kann daraus ein verschlüsseltes Byte-Array erstellt werden.Dieses muss allerdings noch mit der URL sicheren Variante von Base64 kodiert werden. Sonstkann der verschlüsselte Text nicht übergeben werden. Im Gegensatz zur normalen Java APIbietet die Android-API dafür bereits die Klasse Base64, die in diesem Fall auch genutzt wurde.

Symmetrische Verschlüsselung Zur symmetrischen Verschlüsselung wurde AES verwendet.AES ist der Nachfolger von DES und wird mittlerweile auf vielfältige Weise eingesetzt. Ver-wendung findet der Algorithmus unter anderem bei der Verschlüsselung von Roschal ARchi-ve (RAR) Dateiarchiven oder WLAN-Verbindungen. Die Schlüssel sind mit 128, 196 oder 256Bit ebenso wie die Klartext-Blöcke zwischen 128 und 256 Bit deutlich größer als bei DES.Je nach Größe des Schlüssels werden unterschiedlich viele Runden lang, mit Ausnahme der1. und der letzte Runde, die gleichen Operationen durchgeführt. Aus einem Teil der Blö-cke und des für die Runden aufgeteilten Schlüssels werden unter ausschließender DisjunktionVerknüpfungen vorgenommen. Die Entschlüsselung wird analog rückwärts durch geführt.Der Algorithmus gilt trotz Schwächen unter anderem in der Schlüsselaufteilung und Zusam-

mensetzung als relativ sicher. Trotz der Lücken würde ein solcher Angriff bei der Verwendung

42

einer Schlüssellänge von 256 Bit eine nicht praxisrelevante Zeit-Komplexität von 299, 5 undeine Daten-Komplexität von 277, 5 besitzen. 43

Listing 4: Codierung AES

1

String iv = "123456789 abcdefg";

3 IvParameterSpec ivspec = new IvParameterSpec(iv.

getBytes("UTF -8"));

5

7 SecretKeySpec keyspec = new SecretKeySpec("

abcdefghijklmnop".getBytes("UTF -8"), "AES");

Cipher cipher = Cipher.getInstance("AES/CBC/NoPadding

");;

9 byte[] encrypted;

11 cipher.init(Cipher.ENCRYPT_MODE , keyspec , ivspec);

encrypted = cipher.doFinal(padString(test).getBytes("

UTF -8"));

Diesmal ist der richtige Schlüssel bereits im Programmcode festgelegt und muss nicht erstaus dem Verzeichnis geladen werden. Der allgemeine Ablauf ist jedoch ähnlich. Wobei diesmalein Offsetwert iv angegeben wird, der verhindern soll, dass ähnliche Abschnitte auch einenähnlichen Output erzeugen. Es wird im Wesentlichen wieder auf die Cipher Klasse zugegriffen,die den verschlüsselten Text analog mit Hilfe der AES Einstellungen in ein Byte-Array lädt.Dieses Array muss ebenfalls wieder mit Base64 codiert werden.

Ausblick Zur Zeit wird in StuReSy Android nur die symmetrische Variante verwendet. InZukunft sollte ähnlich wie bereits angedeutet auf ein hybrides, asymmetrisches mit 2 Schlüsselnoder bereits anderweitig implementiertes Verfahren gesetzt werden. Empfehlen würde sich indiesem Kontext das offene Protokoll OAuth2, welches bereits in den APIs von Twitter oderFacebook Verwendung findet.44 Der Nutzer einer API muss sich bei erstmaliger Benutzungbeim Server registrieren und erhält zwei Schlüssel, einen Consumer Key und einen ConsumerSecret. Bei einer Anfrage an den Server wird der Consumer Key, ein Zeitstempel und weitereInformationen an den Server übermittelt. Bei einer erfolgreichen Übertragung bekommt derNutzer einen Request Token und ein Request Secret. Die Schlüssel werden mit einer OAuth-Signatur signiert und dienen nach weiteren Schritten der Verifikation und dem Austausch43Siehe:http://de.wikipedia.org/wiki/Advanced_Encryption_Standard und [Biryukov u. Khovratovich, 2009]44Siehe: [Hofmann, 2012]

43

oder Zugriff auf Daten. OAuth ist allgemein eher auf die Anmeldung mit einem Nutzer, derAnmeldenamen und -passwort besitzt, ausgelegt und damit in der Ursprungsform nur bedingtgeeignet.

7.2. AsyncTask

Die Benutzung der Klasse AsyncTask erfolgt über die Erweiterung der Superklasse, welche 4wichtige Methoden bietet.45

•1 protected void onPreExecute ()

Diese Methode läuft noch auf dem UI-Thread und wird genutzt, um die Ausführungvorzubereiten oder eine Fortschrittsanzeige zu initialisieren.

•1 protected Long doInBackground(URL... urls)

Diese Methode läuft in einem vorher automatisch im Hintergrund erstellten Thread,direkt nach Beendigung der obigen Methode. In dieser Methode werden komplexe Be-rechnungen ausgeführt oder wie in StuReSy eine Verbindung zu einem Internetserviceaufgebaut. Der Typ und die Anzahl der Parameter die der Methode übergeben werden,sind frei bestimmbar. Es ist also möglich mehrere Objekte vom Typ URL an die Me-thode zu übergeben und so beispielsweise den Download mehrerer Dateien zu starten.In dieser Methode kann auch die Methode protected final void publishProgress (Pro-gress... values) aufgerufen werden, um den Fortschritt mitzuteilen, wenn ein Downloadabgeschlossen wurde. Es wird dann onProgressUpdate(Progress... values) aufgerufen.

•1 protected void onProgressUpdate(Progress ... values)

Diese Methode wird auf dem UI-Thread aufgerufen und von einem Aufruf von publish-Progress (Progress... values) getriggert. Nach einer Aktualisierung des Status wird oft-mals eine Fortschrittanzeige aktualisiert, die dem Nutzer einen ungefähren Anhaltspunktliefert, wie lange die Berechnung noch andauern wird. Der Zeitpunkt der Ausführung istjedoch nicht genau bestimmt.

•1 protected void onPostExecute(Result result)

Die Methode wird wieder im UI-Thread ausgeführt und aufgerufen, wenn die Berech-nungen in doInBackground(URL... urls) abgeschlossen sind. Das vom Hintergrund be-rechnete Ergebnis wird als Parameter beliebigen Typs empfangen.

45Quellen: [Google, 2013c] und [Google, 2013b]

44

1 [caption=AsyncTask ]{AT}

// Aufbau der Verbindung und speichern der Antwort.

3 urlConnection = (HttpURLConnection) urls [0].

openConnection ();

InputStream in = new BufferedInputStream(

5 urlConnection.getInputStream ());

String antwortString = readStream(in);

7 in.close();

9

Map <String , String > map = new HashMap <String , String

>();

11 map.put("’url"’, urls [0]. toString ());

13 // Ueberpruefung , ob die Anfrage erfolgreich war und

ob Vorlesungsdaten gefunden wurden.

if (antwortString.equals ("’Anfrage nicht erfolgreich"

’)

15 \textbar\textbar !antwortString.contains("’

lecture"’))

return new HashMap <String , String >();

17

// War das Abrufen der Daten erfolgreich , liegt ein

JSONArray vor , aus dem zur einfacheren Benutzung

eine Map erstellt wird.

19 JSONArray jArray = new JSONArray(antwortString);

21 int i = 0;

23 for (i = 0; i < jArray.length (); i++) {

JSONObject json_data = jArray.getJSONObject(i);

25

// Da die allgemeinen Informationen ueber die

Vorlesung redundant gespeichert werden ,

brauchen sie nur beim ersten mal in der Map

gesichert werden ,

27 if (i == 0) {

45

map.put("’lecture"’, json_data.getString ("’

lecture"’));

29 map.put("’question"’, json_data.getString("’

question"’));

// Ueberpruefung , ob es ein Nutzerpasswort

zum Anmelden fuer eine Vorlesung gibt.

31 if (json_data.has("’userpassword"’))

map.put("’userpassword"’,

33 json_data.getString("’

userpassword"’));

35 map.put("’date"’, json_data.getString("’date

"));

37 }

39 map.put(" Answer" + (i + 1), json_data.getString ("

answertext "));

map.put(" AnswerVote" + (i + 1),

41 json_data.getString (" answernumber "));

43 }

//Zur einfacheren Benutzung wird die Anzahl der

Buttons in der Map gespeichert

45 map.put(" anzahlButt", String.valueOf ((i + 1)));

47 return map;

Der obere Quellcode zeigt einen Teil des Inhaltes der doInBackground Methode. Im erstenSchritt wird eine HTTP Verbindung zu der angegebenen URL aufgebaut und die Antwort desServers in einem String gesichert. Der Client übermittelt dem Server eine ID der Vorlesung.Diese Anfrage wird mittels eines PHP-Script verarbeitet. In der MySQL Datenbank auf demServer wird diese Vorlesung gesucht und falls sie gefunden wurde, in ein JSON-Array verpacktzurück geliefert. Nach Überprüfung des Strings kann aus jenem das JSON-Array konstruiertwerden. Dieses enthält die benötigten Daten in einzelnen JSON-Objekten. Jedes Objekt stellteine Antwortmöglichkeit dar. Zur einfacheren Bearbeitung werden diese Daten in einer Mapgespeichert und an das aufrufende Fragment übertragen.

46

7.3. Benötigte Berechtigungen für StuReSy Android

Im folgenden werden ich die für StuReSy Android wichtigen Berechtigungen vorstellen.

7.3.1. WRITE_EXTERNAL_STORAGE

android.permission.WRITE_EXTERNAL_STORAGE Für den Zugriff auf den externen Spei-cher des Gerätes, in der Regel eine micro Secure Digital Memory Card (microSD) Speicherkar-te, ist die obige Berechtigung erforderlich. Ohne diese können keine Dateien auf dem externenSpeicher abgelegt werden. Der Zugriff wird im Falle dieser Applikation für die zur Zeit nochnicht vollständig nutzbare Funktion der Abspeicherung und Anzeige von Bildern genutzt. Dader interne Speicher von Smartphones oft relativ knapp bemessen ist, sollten die möglicherwei-se großen Bilddateien auf dem externen Speicher abgelegt werden, um eventuell wichtigerenPlatz im internen Speicher frei zu lassen. Bei der Benutzung des externen Speichers sind einigeProbleme zu beachten und daher Vorsichtsmaßnahmen zu treffen. Die Anzahl der möglichenFehlerfälle ist groß, eine Auswahl bietet die folgende Liste46.

• Der externe Speicher ist in der Regel nicht nur vom System, sondern auch vom Nut-zer zugreifbar. Daher können durch den Nutzer oder andere Applikationen Änderungendurchgeführt werden, die die Nutzbarkeit der Applikation beeinträchtigen.

• Der Nutzer entfernt die Speicherkarte vor oder während des Betriebes oder bindet sieper Universal Serial Bus (USB)-Verbindung am Computer ein. Der Speicher ist in diesenFällen nicht zugreifbar.

• Das Gerät besitzt einen internen Speicher und eine microSD-Speicherkarte. Jedoch wirdunter Umständen eine Partition des internen Speichers auch als externee Speicher ein-gebunden und die Dateien daher trotzdem auf dem internen und nicht auf dem externenSpeicher gesichert.

Zur Vermeidung von Störfällen sollte daher immer vor der Benutzung des Speichers diestatische Methode

public static String getExternalStorageState ()

der Klasse Environment aufgerufen werden. Zurückgegeben wird eine konstantes String-Feldder Klasse Environment, welches den Zustand des externen Speichers beschreibt. MöglicheStrings wären beispielsweise:

• MEDIA_MOUNTED = “mounted“ der externe Speicher wurde korrekt eingebundenund es kann sowohl lesend, als auch schreibend zugegriffen werden.

46siehe: http://developer.android.com/guide/topics/data/data-storage.html

47

• MEDIA_BAD_REMOVAL = “bad_removal“ der externe Speicher wurde nicht korrektausgeworfen und dann entfernt.

• MEDIA_MOUNTED_READ_ONLY = “mounted_ro“ der externe Speicher wurde kor-rekt eingebunden, es kann aber nur lesend auf ihn zugegriffen werden.

7.3.2. android.permission.INTERNET

Für Zugriffe auf das Interne wird diese Berechtigung benötigt. Bei der Anfragen der Vorle-sungsdaten für eine Frage und beim Absenden einer Antwort wird auf das Internet zugegriffen.Sollte die Applikation abstürzen wird zudem durch das ACRA-Framework ein Bericht überdas Internet geschickt.

7.3.3. android.permission.READ_PHONE_STATE

Um Betrug bei der Abstimmung durch Manipulation von Identifikationsbezeichnung (ID)soder ähnlichem zu vermeiden, muss an jeden Teilnehmer bei der Abstimmung eine eindeutigeKennung vergeben werden. Versucht ein Nutzer mehrfach für die gleiche Frage abzustimmen,wird das Gerät beziehungsweise die Kennung rausgefiltert und der Abstimmungsvorgang warnicht erfolgreich. Zur eindeutigen Bestimmung und Identifizierung des Gerätes beziehungs-weise der Installation ist ein Zugriff auf den Telefonmanager notwendig. Das bedeutet nichtautomatisch, dass auf die Telefonnummmer zugegriffen wird. Aus diesen Daten wird eine ein-deutige ID erstellt und verschlüsselt ohne Rückschluss auf den Nutzer oder das Gerät aufeinen Server hoch geladen. Die Erstellung einer ID sollte ohne die spezielle Registrierung oderAnmeldung möglich sein. Außerdem sollte es eine komplett neue ID geben, wenn der Nutzersein Gerät komplett zurücksetzt und es zukünftig von jemand anderem genutzt wird. Möglichwäre eine Identifikation mit der Methode

1 public String getDeviceId ()

der Klasse TelephonyManager. Bei der Benutzung kann es jedoch zu unerwünschten Effektenkommen. Die DeviceId kann auf Grund von Fehlern in der Implementation einiger ältererGeräte unsinnige und gleichartige IDs auf unterschiedlichen Geräten zurück liefern.47 Tablet-Computer oder Multimediageräte mit Android ohne Telefonfunktion haben diese ID erst garnicht. Die ID bleibt auch bei mehrmaligem zurücksetzen des Gerätes gleich und ist daheralleine nicht geeignet. Settings.Secure.Android_ID wird bei der Zurücksetzung auf Werksein-stellung beim Starten des Gerätes neu gesetzt. Allerdings muss die Android_ID eines Gerätesnicht eindeutig sein, so gab es Hersteller, bei denen der Wert für mehrere Geräte gleich war.Besonders auf Geräten mit einer Android-Version vor 2.2 können die Werte zu dem wechselhaftsein. In der aktuellen fertigen Version von StuReSy wird die Kombination der vorangegangenenErläuterungen in folgender Weise genutzt:47siehe: http://android-developers.blogspot.de/2011/03/identifying-app-installations.html

48

Listing 5: Erstellung der ID

1 if(_deviceID == null)

synchronized (IdFactory.class) {

3 // Device ID des Geraetes aus dem TelephonyManager

extrahieren

TelephonyManager telephonyManager = ((

TelephonyManager)context.getSystemService(

Context.TELEPHONY_SERVICE));

5 String deviceId = telephonyManager.getDeviceId ()

;

7 // Android ID des Geraetes extrahieren

String androidId = Secure.getString(context.

getContentResolver (),

9 Secure.ANDROID_ID);

11 // Voranstellung des Buchstabens A, damit klar

ist , dass die ID von einem Android -Geraet

kommt.

_deviceID = "A";

13

// Ueberpruefungen , ob die IDs gueltig sind ,

falls ja werden sie gehasht und der ID

hinzugefuegt.

15 if(androidId != null)

_deviceID += androidId.hashCode ();

17 if(deviceId != null)

_deviceID += "." + deviceId.hashCode ();

19 //Zur Sicherheit und falls beide obige IDs nicht

verwendbar sind , wird ein zufaelliger String

hinzugefuegt.

_deviceID += UUID.randomUUID ();

21 }

Es wird zuerst die DeviceId und dann die ANDROID_ID erzeugt und auf Gültigkeit über-prüft. Sind die Strings gültig, werden sie mit Hilfe eines Hash-Algorithmus bearbeitet und derID für StuReSy hinzugefügt. Durch den Hash-Vorgang soll sichergestellt werden, dass aus-gehend von der ID unter keinen Umständen auf den Nutzer geschlossen werden kann. DerBuchstabe A am Anfang der ID bedeutet, dass die ID von einem Android-Gerät stammt. Da

49

wie im obigen Abschnitt ausgeführt, bei beiden Verfahren gleichartige oder ungültige Ergeb-nisse für bestimmte Software- und Hardwaretypen entstehen können, wird ein zufälliger Stringan das Ende der ID gehängt. Hierzu wird der Standard Universally Unique Identifier (UUID)genutzt, für den es eine Java-Klasse gibt. UUID ist ein universeller Standard zur Identifikati-on in Softwaresystemen. 16 Byte werden zur Kodierung mit Hilfe der „Leach-Salz“48 Variantegenutzt. Hierbei sind 122 Bits zufällig, 4 bezeichnen die genutzte Version und 2 für die Artder Gestaltung der UUID 49. Die Sicherheit lässt sich mit Hilfe der Wahrscheinlichkeitstheorieberechnen. Entscheidend ist die Wahrscheinlichkeit, dass mindestens 2 IDs gleich sind. Sind 2Werte gleich, treten unter Umständen ungewollte Komplikationen und Probleme auf. Habendadurch 2 Nutzer die gleiche ID kann der eine Abstimmen und der Versuch des anderen Nut-zers resultiert mit einer Nachricht des Servers, dass mit dieser ID beretis gewählt wurde. DerNutzer kann dann seine Stimme nicht mehr abgeben. Ausgehend vom Geburtstagsparadoxonergeben sich folgende Wahrscheinlichkeiten: 1 − e−

n2

2x Je mehr UUID erstellt werden, destohöher ist die Wahrscheinlichkeit, dass Duplikate erzeugt werden. Bei 68 719 476 736 Durchläu-fen, liegt die Wahrscheinlichkeit für Duplikate bei 0.00000000000004% das ist für diese Zwecke,mehr als ausreichend.50

7.3.4. WiFi-Status

• android.permission.ACCESS_WIFI_STATE

• android.permission.CHANGE_WIFI_STATE

Mit der ersten Berechtigung kann überprüft werden, ob das WLAN-Modul eingeschaltet ist.Diese Berechtigung wird für die Einstellungen der Applikation benötigt. Da nicht jeder Nutzerunbegrenzt kostenfreien mobilen Internetzugang hat, ist eine Einstellungsmöglichkeit sinnvoll,damit die Applikation nur auf das Internet zugreift, wenn sich das Gerät im WLAN befindet.Zum Ändern und Einschalten des WLAN-Zuganges wird die zweite Berechtigung benötigt.

7.3.5. Kamera

• android.permission.CAMERA

• android.hardware.camera

• android.hardware.camera.autofocus

48http://www.uddi.org/pubs/draft-leach-uuids-guids-01.txt49http://www.ics.uci.edu/~ejw/authoring/uuid-guid/draft-leach-uuids-guids-01.txt http://docs.oracle.com/

javase/6/docs/api/java/util/UUID.html50siehe: http://en.wikipedia.org/wiki/Universally_unique_identifier/#Random_UUID_probability_of_

duplicates

50

Das erste Element ist die Berechtigung für die allgemeine Nutzung der Kamera. Sie ist not-wendig, um QR-Codes von Vorlesungen scannen und die Fragen zu einer Vorlesung daraufhindarstellen zu können. Punkt zwei und drei sind für die Funktionalität nicht zwingend not-wendig. Es sind uses-feature-Elemente, die ebenfalls im Android-Manifest festgelegt werdenund mit deren Hilfe man bestimmte Geräte im Google Play Store von der Benutzung derApplikation ausschließen kann. In diesem Fall würde die Applikation für alle Android-Geräte,die keine Kamera haben, nicht in den Suchergebnissen auftauchen und ließe sich auch nichtüber den Play Store installieren. Ein Beispiel wäre das Nexus 7 Tablet. Dieses hat nur eineFrontkamera, daher funktioniert die Applikation nicht, da in der Regel von einer Rückkameraausgegangen wird. Da sich aber nach Angabe der GrundURL und der Abkürzung der Vorle-sung die Applikation trotzdem nutzen ließe, braucht man die Angaben nicht. Daher lässt sichdas Feld “android:required=false“ setzen. Dann erscheint die Applikation auch bei Geräten,die keine Kamera besitzen. Es wird jedoch angezeigt, dass die Applikation die angegebenenHardware-Funktionen benutzt.

7.3.6. ZXing

Für die QR-Code-Funktion zum Einlese ist das externe Programm ZXing erforderlich. Diefür diese Applikation erforderlichen Berechtigung, welche sich von den Obigen unterscheiden,werden im folgenden vorgestellt.

1. android.permission.VIBRATE

2. android.permission.FLASHLIGHT

3. android.permission.READ_CONTACTS

4. android.permission.WRITE_CONTACTS

5. com.android.browser.permission.READ_HISTORY_BOOKMARKS

1. Die Berechtigung ist erforderlich, um auf den Motor zuzugreifen, der die Vibrationenmit Hilfe einer Unwucht erzeugt.51

2. Die Berechtigung ist erforderlich, um auf das LED-Licht zugreifen zu können und imZuge einer Foto Aufnahme einen Blitz für erhöhte Helligkeit zu erzeugen.

3. Diese Berechtigung wird relativ kritisch gesehen, sobald sie von einer Applikation ge-nutzt wird. Mit ihr ist es nämlich möglich die Kontakte des Nutzers auszulesen undbei einer Schadapplikation an externe Server zu übermitteln.52 Der Nutzer bekommtin einem solchen Fall nichts von der Spionage mit. Falls doch bieten sich nur wenige

51Siehe: http://de.wikipedia.org/wiki/Vibrationsalarm52Siehe c’t 20/2010 http://www.heise.de/ct/artikel/Risiko-Smartphone-1074532.html

51

Möglichkeiten dem entgegen zu wirken, wie zum Beispiel die Applikation zu de- odereine andere Applikation zu installieren, welche die Kommunikation der Schadapplikati-on unterbindet.53. Im Falle von ZXing wird die Funktion benötigt, um eigene Kontaktemittels QR-Code an andere Smartphones zu über mitteln. Es geschieht kein Missbrauchder Daten seitens des Herstellers.

4. Berechtigung wird benötigt, um die zuvor als QR-Code exportierten Kontakte (sieheoben) auch in das Adressbuch einzupflegen.

5. Es können gespeicherte Lesezeichen ähnlich wie Kontakte als QR-Code exportiert wer-den.

53Siehe unter anderem folgende Applikation im Play Store:Lookout https://play.google.com/store/apps/details?id=com.lookout&hl=de

52

8. Feldtest und Befragung zum Nutzungsverhalten vonStuReSy Android

Im Zuge des Moduls Software-Entwicklung 1 wurde der Prototyp von StuReSy Android (Ab-bildung 20) mit einer kleinen Gruppe von 13 Studenten erstmals im Einsatz getestet.

[ ]

Abbildung 20: StuReSy Android. Erstellt im Android-Emulator.

Die Studenten haben sich freiwillig nach einer E-Mail Rundfrage gemeldet. Zu den Anfor-derungen der Teilnehmer zählten folgende:

1. Besitz eines Android-Smartphone oder Tablets.

53

2. Regelmäßige Rückmeldung über Fehler, Benutzbarkeit oder zum Beispiel Anregungenüber weitere Funktionen und Verbesserungen.

3. Falls möglich, viele und unterschiedliche Geräte und Betriebssystemversionen.

Am Ende haben sich 10 Nutzer mit 5 verschiedenen Android-Betriebssystemversionen von2.3. bis 4.1, darunter auch welche mit einem Custom-Rom gefunden, sowie 2 Tablet-Nutzer .Zum Ende des Moduls wurde unter allen Teilnehmern von SE-1 eine Umfrage durchgeführt.

Die Umfrage selbst wurde mit dem Open Source Tool LimeSurvey54 erstellt und ausgewertet.Abstimmen konnten die Nutzer im Internet über eine Internetseite, auf der LimeSurvey lief.Die Ergebnisse der Umfrage werden im folgenden präsentiert.Insgesamt haben 44 Studenten an der Umfrage teilgenommen, 4 sind aber nicht auswertbar

abgeschlossen und 5 weitere wurden nicht oder nur teilweise abgeschlossen, erscheinen daherzwar in der Gesamtübersicht, werden aber nicht in die Beurteilung eingeschlossen. Darausergeben sich effektiv auswertbare 33 Teilnehmer.55 Die interessantesten Ergebnisse werden imfolgenden vorgestellt.

8.1. Geräte

Die 2. Fragegruppe der Umfrage hat nach dem Besitz und der Benutzung von mobilen Gerätgefragt. Zu beachten ist, dass einige Fragen auf anderen basieren und nur angezeigt und ausge-wertet werden, wenn eine bestimmte Bedingung erfüllt wurde. In der Regel ist die Bedingung,dass der Umfrageteilnehmer ein bestimmtes Gerät besitzt.

8.1.1. Notebook

Mit 29 von von 33 Stimmen besitzt ein Großteil der Teilnehmer ein Notebook, von denennutzen mit rund 38 % aber nur knapp mehr als ein Drittel ihr Notebook auch währenddes Vorlesungsbetriebes. Die Anzahl ist also eher gering und spricht dafür, dass viele zurBenutzung von StuReSy mit dem Notebook ihr Gerät mit in die Universität nehmen oderzumindest entgegen ihrem bisherigem Nutzungsverhalten gebrauchen müssten.

8.1.2. Tablet

Die Tablet-Verbreitung ist mit unter 30% relativ gering. Jedoch benutzen von diesen Teil-nehmern 2/3 ihr Tablet auch in der Vorlesung. Es scheint also deutlich attraktiver zu seinein Tablet in die Vorlesung mitzunehmen und zu benutzen. Die Wahl des Betriebssystemist mit 2/3 für Android und 1/3 für iOS Geräte sehr deutlich. Andere zur Wahl stehendenBetriebsysteme wie Windows RT erhielten keine Stimmen.54Siehe: http://www.limesurvey.org/de und [von Craushaar, 2011]55Die komplette Datenbasis befindet sich sowohl in Portable Document Format (PDF), als auch Microsoft Excel

Dateiformat im Anhang auf der CD. Die Auswertungen sind im PDF-Format im Anhang oder werden inbesonderen Fällen als Bild eingebunden.

54

8.1.3. Smartphone

Klar über 90% der Befragten besitzen ein Smartphone. Ein Hinweis darauf, dass der mitStuReSy (Android) eingeschlagene Weg scheinbar richtig ist. Bei der Benutzung zeigt sich, dass84% ihr Smartphone während der Vorlesung zumindest kurzfristig benutzen. Die Smartphone-Betriebssysteme zeigen im Vergleich zu den Tablets eine erhöhte Diversität, die Ergebnissefallen trotzdem deutlich zugunsten Androids aus.

[ ]

Abbildung 21: Verteilung der Smartphone-Betriebssysteme. Erstellt mit LimeSurvey.

[ ]

Abbildung 22: Verteilung der Smartphone-Betriebssystem. Erstellt mit LimeSurvey.

Über 2/3 der Befragten nutzt Android, iOS nur knapp 20% und andere Betriebssystemewie WindowsPhone, dem mobilen Betriebssystem von Microsoft, sind zur Zeit in der breitenMasse nur Randerscheinungen. Die Betriebssystem Versionen sind relativ aktuell. Bereits überdie Hälfte nutzen die neuesten Versionen, nur ein Viertel deutlich veraltete56.

56Diese Ergebnisse können in deutlichem Zusammenhang mit der Art der Vorlesung und den Teilnehmern derUmfrage stehen und abweichen bei nicht Informatik Vorlesungen.

55

8.1.4. Internet Nutzung Mobil

Ein sehr großer Teil von fast 3/4 der Befragten besitzt eine Internetflatrate ohne oder mitEinschränkung nach einer bestimmten Volumenüberschreitung. Nur sehr wenige greifen garnicht oder nur über WLAN auf das Internet zu.

[ ]

Abbildung 23: Zugriff auf das Internet über mobile Geräte. Erstellt mit LimeSurvey.

8.1.5. Technische Ausstattung

Fast alle Geräte haben eine Kamera eingebaut und auch über die Hälfte ein Mobilgerät miteiner als groß einzustufenden Bildschirmdiagonale von über 3,5 Zoll.

8.1.6. Mobiles Surfverhalten

Mit Ausnahme zweier Antwortmöglichkeiten ist das Nutzungsverhalten relativ ausgeglichen.Es gibt aber trotzdem 1/4, die mehr als 5 Stunden mobil im Internet verbringt oder zumindestdurch dauerhaftes Abrufen von Mails oder ähnlichem im Internet erreichbar sind.

[ ]

Abbildung 24: Angabe wie lange pro Tag im mobilen Internet verbracht wird. Angabe inStunden. Erstellt mit LimeSurvey.

56

8.1.7. Nutzung mobiler Applikation oder mobil angepasste Internetseite

In diesem Zusammenhang ist eine mobile Applikation eine speziell auf das Betriebssystem zu-geschnittene Variante die installiert wird und eine mobile Internetseite wird über den Browseraufgerufen und ohne Installation benutzt. Eine große Mehrheit ist entweder indifferent oderpräferiert eine angepasste mobil Applikation. Nur vergleichsweise wenige benutzen eher diemobile Internetseiten Variante.

[ ]

Abbildung 25: Präferenz gegenüber einer nativen mobilen Applikation oder einer Internetseite.Erstellt mit LimeSurvey.

8.2. Nutzung von StuReSy Android

8.2.1. Häufigkeit der Nutzung der Applikation

Die Frage zielt darauf ab, wie häufig die StuReSy Android-Applikation genutzt wurde, wenneine Umfrage mit StuReSy durchgeführt wurde57. Es sind nur die Befragten relevant, die andem Feldtest teilgenommen und Android-Version getestet haben. Es wird deutlich, dass überdie Hälfte die Applikation häufig benutzt haben und rund ein 1/4 eher seltener.

8.2.2. Nutzung spezieller Funktionen

Die Funktionen zur Eintragung einer Vorlesung über den QR-Code oder das Suchfeld wurdennur selten genutzt. Nur wenige, kumuliert 29%, haben die Funktionen mehr als ein- oderzweimal genutzt. Dieses Verhalten ist zum Teil so erwünscht, da es nicht notwendig ist diegleiche Vorlesung mehrfach einzulesen, da über die Funktion der bereits besuchten Vorlesungenjederzeit eine Vorlesung geladen werden kann.Auffällig ist hierbei, dass auch die komfortablere Möglichkeit der Auswahl der bereits be-

suchten Vorlesung nur unregelmäßig genutzt wurde.

57In dieser Frage stehen: 1: nie genutzt 2: selten genutzt 3: ab und zu genutzt 4: häufig genutzt 5: immergenutzt

57

[ ]

Abbildung 26: Nutzung der Android-Applikation bei Umfragen. Erstellt mit LimeSurvey.

Nur rund 29% haben diese häufig benutzt, 14% selten und der Großteil von über 50% sogargar nicht. Dieser Umstand kann mehrere Gründe haben, eventuell haben die anderen Nutzerdie Funktion nicht gefunden oder wussten nicht, dass eine solche existiert.

[ ]

Abbildung 27: Nutzung der Vorlesungsdatenbank. Erstellt mit LimeSurvey.

Auch die Funktion der Nachbereitung bereits beantworteter Fragen wurde selten, nur von29% genutzt. Die notwendige Aktualisierung der Vorlesung wurde hingegen mit rund 85% fastimmer viel genutzt.

8.2.3. Vergleich mit nicht Android-Nutzern

Unter den Nutzern der Web-Oberfläche gibt es mit 9,09 % wenige, aber durchaus bemerkbareNutzer die selten oder gar nicht abgestimmt haben. Der Großteil hat jedoch regelmäßig undviel abgestimmt.Nur wenige haben viel oder ausschließlich mit ihrem Notebook abgestimmt. Das arithmeti-

sche Mittel für die Nutzung von Mobilgeräten, deren Nutzer zur Abstimmungen nicht auf die

58

[ ]

Abbildung 28: Teilnahme der Web-Oberfläche. Erstellt mit LimeSurvey.

Android-Applikation zugegriffen haben liegt bei 3,69. Im durchschnitt wird die Umfrage alsotrotzdem sehr häufig zu 3/4 % von einem mobilen Gerät durchgeführt.

[ ]

Abbildung 29: Anzahl derer, nicht die spezielle StuReSy Android-Applikaiton genutzt, abertrotzdem mit einem mobilen Gerät abgestimmt haben. Erstellt mit LimeSurvey.

8.3. Zufriedenheit mit Design und Funktionalität

Diese Fragegruppe erfragt die Zufriedenheit mit Designelementen und den Funktionen derApplikation und der Web-Oberfläche.58

8.3.1. Allgemeine Design

Allgemein sind die Nutzer der Applikation scheinbar relativ zufrieden mit der optischen Ge-staltung und Einbindung in das Betriebssystem.58Zur Auswahl stehende Kategorien: 1. Gar nicht zufrieden 2. Wenig zufrieden 3. Einigermaßen zufrieden 4.

Zufrieden 5. Sehr zufrieden

59

Bei der Größe und Gestaltung der UI-Elemente sind beispielsweise über die Hälfte (sehr)zufrieden. Die farbliche Gestaltung halten über über 70% für gut. Die Anordnung und Er-reichbarkeit der Elemente empfinden alle Befragten mindestens als gut.

[ ]

Abbildung 30: Zufriedenheit mit den UI-Elementen. Erstellt mit LimeSurvey.

[

.XU]�6WDWLVWLNHQ8PIUDJH��������8PIUDJH�]X�6WX5H6\��$QGURLG�

)HOG�=XVDPPHQIDVVXQJ�I¾U�'HVLJQ$SS�*UXQGEHGLHQHOHPHQWH�

6FK¦W]HQ�6LH�,KUH�=XIULHGHQKHLW�PLW�GHU�RSWLVFKHQ�*HVWDOWXQJ�GHU�$SSOLNDWLRQHLQ��>$QRUGQXQJ�XQG�(UUHLFKEDUNHLW�GHU�*UXQGHOHPHQWH�@

��������������������������6HLWH��������

]

Abbildung 31: Zufriedenheit mit der Anordnung und Erreichbarkeit der UI-Elementen. Er-stellt mit LimeSurvey.

Mehr Unzufriedenheit scheint nur bei der Anzeige der Texte zu bestehen, die offenbar aufkleinen Geräten nicht gut lesbar sind. Fast die Hälfte sind mit den Texten eher weniger zu-frieden.Die Applikation biete aber laut 71,4% eine gute Grundübersicht.

Web-Oberfläche Über die Hälfte der Befragten sind indifferent oder empfinden die allge-meine Übersicht der Web-Oberfläche als weniger gut.

60

[ ]

Abbildung 32: Zufriedenheit mit der Darstellung der Texte. Erstellt mit LimeSurvey.

[ ]

Abbildung 33: Zufriedenheit mit der allgemeinen Übersicht in der Web-Oberfläche. Erstelltmit LimeSurvey.

8.3.2. Funktionalität der Applikation

Mit dem wichtigsten Element der Applikation, dem Abstimmvorgang, sind mit 71,4% diemeisten Nutzer der Applikation sehr zufrieden. Ähnlich sieht die Verteilung beim Scannen desQR-Codes aus.Am unzufriedensten waren die Befragten mit der Funktion des Öffnens von zuvor gespei-

cherten Vorlesungen und Umfragen. Dies kann mit den im vorherigen Abschnitt vorliegendenDaten zu tun haben, wonach einige offenbar nicht wussten, dass es diese Funktionen gibt oderwie sie benutzt werden.

61

[ ]

Abbildung 34: Zufriedenheit mit der Funktionalität des Abstimmungsvorganges der Applika-tion. Erstellt mit LimeSurvey.

[ ]

Abbildung 35: Zufriedenheit mit der Möglichkeit alte Umfragen anzusehen. Erstellt mitLimeSurvey.

8.3.3. Fehlende Funktionen

In diesem Abschnitt wurde nach Funktionen gefragt, die nicht in der Web-Oberfläche oderauch der Applikation zu finden ist. Dabei wünscht sich ein Großteil (69,7%) der Befragten dieMöglichkeit vorherig beantwortete Fragen abzuspeichern oder ist sich noch nicht sicher.Mit knapp über 50% nicht ganz so deutlich, wünschen sich die Nutzer die Möglichleit einen

schnell zugriff zu bisher besuchten Vorlesungen in der Applikation zu erreichen. Da StuReSyzurzeit nur ein einem Modul genutzt wird, ist diese Frage und Funktion eventuell erst beimehreren Vorlesungen attraktiv.Der Wunsch nach einer automatischen Aktualisierung ist sehr deutlich und liegt Web- und

Android-Nutzer kumuliert bei ungefähr 81.2%

62

[ ]

Abbildung 36: Wunsch nach der Funktion des Abspeicherns einer beantworteten Frage. Er-stellt mit LimeSurvey.

[ ]

Abbildung 37: Wunsch nach der automatischen Aktualisierung einer Vorlesung. Erstellt mitLimeSurvey.

8.4. Zusammenfassung

Die hohe Verbreitung von Tablets und Smartphones, die auch in der Vorlesung benutzt werden,regelmäßig mit geringen Einschränkungen ins mobile Internet gehen und Android als Betriebs-system installiert haben, ist sehr hoch. Zusätzlich nutzen die Befragten lieber eigenständigeApplikation. Diese Umstände zeigen, dass die Wahl der Entwicklung einer Android-Applikationdurchaus die richtige war. Zusammengefasst scheinen einige Funktionen der Applikation gut zugefallen, auch wenn zum Beispiel der Schnellzugriff auf die Vorlesung weniger genutzt wurde.

63

9. Schluss

In dieser Bachelorarbeit wurde eine Motivation und ein Einblick in ARS-Systeme und dieEntwicklung einer solchen Anwendung für das mobile Betriebssystem Android gegeben. ImFolgenden werden alle Kapitel zusammengefasst, in einem Fazit analysiert und ein Ausblickfür das weitere Projekt gegeben.

9.1. Zusammenfassung

9.1.1. Einleitung

Die Einleitung gibt eine grundsätzliche Motivation für Peer Instruction und ARS-Systeme, zuder die Erhöhung der Aufmerksamkeit und der Lernleistung der Studenten während einer Vor-lesung zählt. Studien haben dies auch im Informatik-Kontext bestätigt. Die Problemstellungergibt sich aus dem Nutzererlebnis und den Verbesserungsmöglichkeiten des prototypischenARS StuReSy, in welchem die Nutzeroberfläche unter anderem wichtige Informationen ver-missen lässt.

9.1.2. ARS

In diesem Abschnitt wird die allgemeine Funktionsweise von ARS-Systemen, sowie das beste-hende System der Firma H-ITT erklärt und erläutert.

9.1.3. StuReSy

Als Grundlage dieser Bachelorarbeit wird insbesondere die Nutzeransicht von StuReSy ein-gehend untersucht. In dieser Analyse fallen ein paar Schwächen des Prototyps der Nutzeran-wendung auf. Antworttexte sind nicht einsehbar, die Aktualisierung erfolgt manuell und eineNutzung in verschiedenen Vorlesungen wäre umständlich.

9.1.4. Android

Oberflächenkonzept Android bietet sich als Entwicklungsplattform an, da in Zukunft deut-lich mehr Nutzer über mobile Geräte ins Internet gehen werden und schon im 3.Quartal 75%der ausgelieferten Geräte Android installiert hatten. Außerdem ist Android ein offenes Be-triebssystem, für welches sich durch die Nähe zu Java komfortabel Anwendungen entwickelnund testen lassen. Activities nehmen Eingabeinformationen entgegen und stellen die Oberflä-chen dar. In den Design Guidlines wird eine Action Bar, welche mehrere Zeilen mit schnellzugreifbaren Elementen darstellt, zur Navigation empfohlen. Fragmente sind wichtige Subacti-vities, die in den Tabs dargestellt werden und über Intent-Aufrufe miteinander kommunizieren.

64

Fragmentierung Die durch eine hohe Gerätevielfalt einhergehende Fragmentierung Androidserfordert besondere Aufmerksamkeit während der Entwicklung. Es muss unter anderem durchTests sichergestellt werden, dass die Anwendung auf möglichst vielen Geräten funktioniert undein vergleichbar gutes Nutzungserlebnis mit einer gleichen Oberfläche bietet. Eine Anwendungdie nur auf einem Teil der Geräte lauffähig oder auf bestimmten Geräten nicht praktikabelbedienbar ist, wurde weitestgehend vermieden.

Netzwerkverbindung Die Netzwerkverbindung ist ein kritischer Punkt für eine mobile An-wendung, da die Nutzer eventuell in Geschwindigkeit und Datenvolumen ihrer Internetnutzungeingeschränkt sind. Die Daten sollten daher so klein wie möglich sein und schnell übertragenwerden. Werden Daten heruntergeladen sollte dies in einem ausgelagerten Thread stattfinden,um den UI-Thread nicht zu blockieren und die weitere Benutzung der Anwendung und desSystems zu gewährleisten.

9.1.5. Prototyping

Anhand der Vorgaben in den Kapiteln 3 und 4 wurde eine weitere Analyse von Funktionenund der erwünschten Oberfläche vorgenommen und ein Mock-Up dieser Android-Oberflächeerstellt. Die Navigation erfolgt über die Action Bar, Funktionen wie Fragen an den Dozentenwerden gezeigt und auch die Sicherung der Vorlesung und spätere Auswahl einer gesichertenVorlesung werden dargestellt.

9.1.6. Bibliotheken und Frameworks

In der Applikation werden ein paar externe Bibliotheken verwendet, die in diesem Abschnittbeschrieben wurden. ActionBarSherlock bietet eine komfortable und mächtige Möglichkeit dasActionBar-Konzept auch in alten Android-Versionen zu nutzen, ACRA sendet umfangreicheund hilfreiche Informationen bei Abstürzen, ZXing vereinfacht die Kommunikation und denScan-Vorgang und JSON ist ein einfaches Dateiaustauschformat, welches bei der Serverkom-munikation genutzt wird.

9.1.7. Implementationsdetails

Kryptographie Die verschlüsselte Übertragung der Daten bei der Abstimmung ist für die-se Applikation essentiell wichtig, um Fälschungen auszuschließen. Dazu gibt es verschiedeneVerfahren, die jeweils ihre eignen Vor- und Nachteile haben. In dem für längere Texte geeig-neten symmetrischen Verfahren gibt es einen Schlüssel, der ausgetauscht werden muss unddabei kompromittiert werden kann. Die langsamen asymmetrischen Verfahren haben einenöffentlichen und einen privaten Schlüssel, dies erleichtert den Austausch. Jeder Teilnehmerbenutzt den öffentlichen Schlüssel zur Verschlüsselung und die Nachrichten können nur mitdem privaten entschlüsselt werden.

65

Beide Verfahren wurden exemplarisch implementiert, zur Zeit wird die symmetrische Varian-te benutzt. Diese ist auf mobilen Geräten mit Akku- und Leistungseinschränkungen effizienter.In Zukunft sollten in einem hybriden Verfahren beide Konzepte kombiniert werden.

AsyncTask Ein AsyncTask bietet eine einfache Möglichkeit ausgelagerte Aufgaben unabhän-gig vom UI-Thread auszuführen. Der AsyncTask informiert das Fragment über die Beendigungdes Downloads und verpackt die Daten zur Weiterverarbeitung. In Falle von StuReSy Androidwird der Download der Vorlesungsinformationen über einen AsyncTask realisiert.

Berechtigungen Die Applikation fordert vom Nutzer diverse Berechtigungen ein. Berech-tigungen werden erforderlich, wenn die Anwendung auf bestimmte Bereich der Hard- undSoftware zugreifen möchte. Die meisten dieser Zugriffserlaubnisse sind relativ unkritisch. Esgibt jedoch Ausnahmen. Die Berechtigung des Zugriffs auf den Telefon Manager des Gerätesist nur in begründeten Fällen sinnvoll, da mit dieser Berechtigung auch die Telefonnummerausgelesen und an externe Server übertragen werden kann. Ein ähnliches Problem ergibt sichbei der Berechtigung zum Auslesen und Schreiben von Kontakten, diese wird von ZXing zumQR-Code austauscht genutzt.

9.1.8. Feldtest und Befragung

Es wurde im Zuge des Moduls Software Entwicklung 1 ein Feldtest durchgeführt, in dem 13Studenten die Android-Applikation ausprobiert haben. Bei der anschließenden Befragung al-ler Studenten ergaben sich ein paar interessante Antworten. Über 90% der Befragten besitzenmindestens ein Mobilgerät, welches oftmals ein Android-Gerät ist und über eine mobile In-ternetflatrate verfügt. Zugleich werden die Geräte im Gegensatz zu Notebooks auch währendder Vorlesung regelmäßig genutzt und mobile Applikationen gegenüber mobilen Internetseitenpräferiert. Außerdem nutzen auch die StuReSy Teilnehmer ohne Zugang zur Android-Variantezu 75 % ein Tablet oder Smartphone zur Abstimmung. Diese Ergebnisse legen den Schlussnahe, dass die Entwicklung einer Android-Version die richtige Entscheidung war und mit einpaar weiteren Anpassungen die bereits gute Zufriedenheit mit der Applikation weiter erhöhtwerden kann.

9.2. Fazit und Ausblick

Android ist eine junge und aufstrebende mobile Plattform mit riesigem Aufstiegspotenzial.Sie bietet sowohl für die Nutzer, als auch Hersteller und Entwickler Vor- und Nachteile. All-gemein lassen sich jedoch vergleichsweise unkompliziert Android-Anwendung erstellen undtesten. StuReSy Android ist eine fast vollständig funktionierende Anwendung für das ARSStuReSy. Auch die Umfrageergebnisse im Zuge des Feldtestes legen ein gesteigertes Interes-se an Android und StuReSy Android nahe. Das Ziel eines einfach zu benutzenden mobilen

66

Clients, der Verbesserung in Nutzbarkeit, Komfort und Funktionen bietet ist damit erfüllt.Bereits jetzt besitzt ein Großteil der Studenten ein Android-Gerät, welches regelmäßig undbevorzugt mit nativen Anwendungen genutzt wird. Für zukünftige Versionen ließen sich jedochweitere Änderungen realisieren:

Anpassung der Verschlüsselung Die Verschlüsselung sollte dahin gehend angepasst werden,dass sie zum einen schnell und sicher funktioniert. Eine hybride Verschlüsselung oder einbestehendes System bieten sich zur künftigen Authentifikation an.

Automatische Aktualisierung der Vorlesung Denkbar wäre eine Server zu Client Kommu-nikation, in der der Server alle Nutzer informiert, wenn eine neue Umfrage gestartet wurdeund die Applikation daraufhin die Daten selbstständig aktualisiert.

Weitere Funktionen Weitere mögliche Funktionen sind: die Darstellung von Bildern zu Fra-gen, weitere Fragetypen (multiple Choice) oder auch die Möglichkeit Aufgaben und Fragengestellt zu bekommen, die der Student zu Hause bearbeitet, beantwortet und zur nächstenVorlesung abschickt. Außerdem muss die entsprechende Komponente des Dozenten zum stel-len einer Frage abschließend implementiert werden. In der Anwendung gibt es bereits eineKomponente, um Passwortabfragen für Vorlesungen zu ermöglichen, diese müsste auch ent-sprechend in der Version des Dozenten implementiert wurde. Vorlesungen können dann durchein Passwort geschützt werden.

Tablet-Optimierung Entsprechend der Mock-Ups ist eine Optimierung für Tablets und Ge-räte mit großen Displays wünschenswert. Die Nutzer könnten die Anwendung dann komforta-bler benutzen.

Weitere Möglichkeiten sich für eine Vorlesung einzutragen Es gibt eine Reihe weitererMöglichkeiten einen Nutzer für eine Vorlesung einzutragen, wie Ortsbestimmung via GPSoder mittels drahtloser Funktechnologie (Bluetooth oder NFC). Es Zuordnung des Nutzers zueiner Vorlesung. Alle Studenten die anwesend sind, erhalten die Möglichkeit teilzunehmen.

Umsetzung weiterer nativer Anwendungen Insbesondere die Entwicklung einer nativenAnwendung für iOS-Geräte könnte Erfolg haben, da es eine der mobilen Plattformen mit denmeisten Nutzern ist. Dies kam auch in der Befragung (8) zum Ausdruck.

67

A. Anhang

Literatur

[Allen 2011] Allen, G.: Beginning Android 4. Apress, 2011 (Apressus Series). http://books.google.de/books?id=ZlHR3nNTiXsC. – ISBN 9781430239840

[Alliance 2012] Alliance, Open H.: Android. http://www.openhandsetalliance.com/android_overview.html zuletzt abgerufen: 08.02.2013, 2012

[Beutelspacher u. a. 2006] Beutelspacher, Albrecht ; Schwenk, Jörg ; Wolfenstetter,Klaus-Dieter: Modern processing of cryptography. From RSA to zero-knowledge. (ModerneVerfahren der Kryptographie. Von RSA zu Zero-Knowledge.) 6th revised ed. Wiesbaden:Vieweg. x, 138 p. EUR21.90 , 2006

[Biryukov u. Khovratovich 2009] Biryukov, Alex ; Khovratovich, Dmitry: Related-keyCryptanalysis of the Full AES-192 and AES-256. Cryptology ePrint Archive, Report2009/317, 2009. – http://eprint.iacr.org/ zuletzt abgerufen: 08.02.2013

[Bruff 2012] Bruff, Derek: Classroom Response Systems ("Clickers"). 2012. – http://cft.vanderbilt.edu/teaching-guides/technology/clickers/ zuletzt abgerufen: 08.02.2013

[Bundesamt 2012] Bundesamt, Statistisches: P2 Internetnutzung und -aktivitäten. In: Pri-vate Haushalte in der Informationsgesellschaft (IKT) (2012)

[von Craushaar 2011] Craushaar, Constantin von: Unterlagen zur LimeSurvey Schulung.http://www.statistik.cc/limesurvey/ zuletzt abgerufen: 08.02.2013, 2011

[Crouch u. Mazur 2001] Crouch, Catherine H. ; Mazur, Eric: Peer Instruction: Ten yearsof experience and results. In: American Journal of Physics 69 (2001), Nr. 9, 970-977.http://dx.doi.org/10.1119/1.1374249. – DOI 10.1119/1.1374249

[Dankmeier 2006] Dankmeier, Wilfried: Basic course in coding theory. Cryptography, datacompression and error correction. (Grundkurs Codierung. Verschlüsselung, Kompression,Fehlerbeseitigung.) 3rd ed. Wiesbaden: Vieweg. xi, 393 p. EUR 29.90 , 2006

[Focus 2012] Focus, Tommorow: Tommorow Focus: Mobile Effects Studie 2012. http://www.bvdw.org/medien/tomorrow-focus-mobile-effects-studie-2012?media=4319 zuletzt abgerufen:08.02.2013, 2012

[Google 2013a] Google: ActionBar. http://developer.android.com/guide/topics/ui/actionbar.html zuletzt abgerufen: 08.02.2013, 2013

[Google 2013b] Google: AsyncTas. http://developer.android.com/reference/android/os/AsyncTask.html zuletzt abgerufen: 08.02.2013, 2013

IX

[Google 2013c] Google: Processes and Threads. http://developer.android.com/guide/components/processes-and-threads.html zuletzt abgerufen: 08.02.2013, 2013

[Group 2012] Group, JSON: Einführung in JSON. 2012. – http://json.org/json-de.html zuletztabgerufen: 08.02.2013

[Gunasekera 2012] Gunasekera, Sheran: Android Apps Security. 1st. Berkely, CA, USA :Apress, 2012. – ISBN 1430240628, 9781430240624

[Hofmann 2012] Hofmann, Bastian: So funktioniert OAuth2. In: PHP Magazin 4.2012(2012). – http://it-republik.de/php/artikel/So-funktioniert-OAuth2-5081.html zuletzt abgeru-fen: 08.02.2013

[Komatineni u. MacLean 2012] Komatineni, Satya ; MacLean, Dave: Pro Android 4. 1st.Berkely, CA, USA : Apress, 2012. – ISBN 1430239301, 9781430239307

[Kuenneth 2012] Kuenneth, Thomas: Android 4 Apps entwickeln mit dem AndroidSDK. Galileo Press GmbH, 2012 (Galileo Computing). http://books.google.de/books?id=j-BpuQAACAAJ. – ISBN 9783836219488

[Mazur 1997] Mazur, E.: Peer Instruction: A User’s Manual. Prentice Hall, 1997 (PrenticeHall Series in Educational Innovation). http://books.google.de/books?id=tjcbAQAAIAAJ. –ISBN 9780135654415

[Nicola 2009] Nicola, Carlo U.: Einblick in die Dalvik Virtual Machine. In: IMVS FokusReport 2009 (2009)

[Oracle 2012] Oracle: Thread API. http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Thread.html zuletzt abgerufen: 08.02.2013, 2012

[Posdorfer 2012] Posdorfer, Wolf D.: Prototyp einer Freien Software für interaktive Vorle-sungen mit Echtzeitabstimmungen, Universität Hamburg, Bachelorarbeit, 2012

[Simon u. a. 2010] Simon, Beth ; Kohanfars, Michael ; Lee, Jeff ; Tamayo, Karen ; Cutts,Quintin: Experience report: peer instruction in introductory computing. In: Proceedings ofthe 41st ACM technical symposium on Computer science education. New York, NY, USA :ACM, 2010 (SIGCSE ’10). – ISBN 978–1–4503–0006–3, 341–345

[Wharton 2012] Wharton, Jake: ActionBarSherlock. http://actionbarsherlock.com/ zuletztabgerufen: 08.02.2013, 2012

X

Digitale Version auf CDROM

Auf der CD befindet sich folgende Elemente:

• PDF-Version der Bachelorarbeit.

• Quellcode von StuReSy Android.

• Quellcode der RSA-Version von StuReSy Android.

• Umfrageergebnisse und Analyse der Umfrage im PDF, sowie Excel-Dateiformat.

Bachelorarbeits-CDROMVersion 1.0

XI

Eidesstattliche Erklärung

Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeitselbstständig und ohne fremde Hilfe verfasst und keine anderenals die angegebenen Quellen und Hilfsmittel verwendet habe.Alle Stellen, die wörtlich oder sinngemäß aus Veröffentlichungenentnommen wurden, sind als solche kenntlich gemacht.

Diese Versicherung bezieht sich auch auf alle in der Arbeit enthalte-nen Zeichnungen, Skizzen, bildlichen Darstellungen und dergleichen.

Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vor-gelegt und auch noch nicht veröffentlicht.

Des Weiteren bin ich mit einer Einstellung der Arbeit in dieBibliothek einverstanden.

Ort, Datum Unterschrift

XII