Eingereicht von Peter Sonnleitner, BSc

Angefertigt am Institut für Wirtschaftsinformatik - Software Engineering

Beurteiler a. Univ.-Prof. Dipl.-Ing. Dr. Alois Stritzinger

August 2016

Entwicklung einer plattformübergreifenden mobilen Lernanwendung mit hybriden Technologien

Masterarbeit zur Erlangung des akademischen Grades Master of Science im Masterstudium Masterstudium Webwissenschaften (Studienzweig Web Engineering)

JOHANNES KEPLER UNIVERSITÄT LINZ Altenberger Straße 69 4040 Linz, Österreich www.jku.at DVR 0093696

Eidesstattliche Erklärung

Ich erkläre an Eides statt, dass ich die vorliegende Masterarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe.

Die vorliegende Masterarbeit ist mit dem elektronisch übermittelten Textdokument identisch.

Linz, 4. August 2016

______Peter Sonnleitner, BSc

4. August 2016 Peter Sonnleitner, BSc 2/79

Kurzfassung

Mobiles Lernen hat sich in den letzten Jahren zu einem wichtigen und relevanten Thema mit hohem Stellenwert im Bildungssektor entwickelt. Mobile Lernapplikationen müssen plattformunabhängig und für alle Anwender und Anwenderinnen verfügbar sein, damit auch wirklich uneingeschränkt auf den Lehrinhalt zugegriffen werden kann. Es gibt viele verschiedene Technologieansätze, mit denen so eine plattformübergreifende Lernanwendung umgesetzt werden kann. Die Auswahl einer geeigneten und richtigen Technologie für die Implementierung stellt große Herausforderungen dar, weil durch eine Fehlentscheidung ein Projekt sehr leicht scheitern kann und immense zusätzliche Kosten verursacht werden können. Das Ziel ist im ersten Schritt, ein Mobile-Learning-System zu entwerfen, welches Mobile Learning, Gamification und Microlearning miteinander verbindet und sehr einfach verwendet werden kann. Dieser Entwurf soll im Anschluss mit Hilfe von hybriden Technologien umgesetzt und implementiert werden. Um die Applikation technisch bestmöglich entwickeln zu können, soll ein Framework mit sehr hohem Zukunftspotential verwendet werden. Dazu werden relevante Auswahlkriterien definiert, die Frameworks bewertet und die zwei bestmöglichen Frameworks detailliert beschrieben und gegenübergestellt. Hauptziel ist es, festzustellen, mit welchen mobilen Technologien solche plattformübergreifenden mobilen Lernapplikationen am einfachsten und effizientesten entwickelt werden können. Das Endergebnis dieser Arbeit ist das Mobile-Learning-System „Examize“. Dieses besteht aus einer mobilen Lernanwendung, in welcher verschiedene Fragetypen, wie etwa Wahr-/Falsch- Aussagen, mit einfachen Wischgesten beantwortet werden können. Die Applikation verbindet Mobile Learning mit Gamification- und Microlearning-Ansätzen und ist per Schnittstelle mit einer Online-Plattform gekoppelt, auf welcher Lehrinhalte einfach bereitgestellt werden können. Um die mobile Applikation entwickeln zu können, wurden einige Frameworks gegenübergestellt und verglichen. Die Implementierung erfolgte mit Ionic und React Native, dabei handelt es sich um zwei hybride Frameworks mit unterschiedlichen Ansätzen, wobei beiden sehr hohes Zukunftspotential zugesprochen wird. Die Entwicklungsanforderungen der mobilen Lernanwendung haben sich mit beiden Frameworks effizient und einfach umsetzen lassen.

4. August 2016 Peter Sonnleitner, BSc 3/79

Abstract

In the last years, mobile learning has increasingly become a very important and relevant topic in the educational sector. Mobile learning applications must be platform-independent and available to all users so that access to the teaching content can be unhindered. There are many different technology approaches that can contribute to creating a platform-independent learning environment. It is challenging to find an appropriate and correct technology for the implementation thereof, because a wrong decision can easily lead to a project failing, leading to immense costs. The first goal is to create a mobile learning system that connects mobile learning, gamification and microlearning with one another and is very user-friendly. This design will be realized and implemented with the assistance of hybrid technologies. In order to best technically develop the application, a framework with high future potential should be used. To achieve this, relevant selection criteria will be defined, frameworks will be assessed and the two best possible frameworks will be described in detail and compared to one another. The main goal is to establish with which technology such cross-platform learning applications can be developed simplest and most efficiently. The end result of this thesis is the mobile learning system “Examize” which best fits these criteria. Examize consists of a mobile learning application in which different question types, such as true or false, can be answered by swiping. The application connects mobile learning with gamification and microlearning approaches and is coupled with an online platform on which teaching content can be accessed. In order to be able to develop the mobile application, some frameworks are compared and contrasted. The implementation took place with Ionic and React Native, two hybrid frameworks with different approaches, both of which possess a lot of future potential. The development requirements of the mobile learning application were easily and efficiently met by both frameworks.

4. August 2016 Peter Sonnleitner, BSc 4/79

Inhaltsverzeichnis

1. Einleitung ...... 8 1.1. Problemstellung und Motivation ...... 8 1.2. Zielsetzung ...... 9 1.3. Inhaltlicher Aufbau der Arbeit ...... 10 2. Grundlagen von Mobile Learning und Gamification ...... 11 2.1. Begriffsdefinitionen ...... 11 2.1.1. Mobile Learning ...... 11 2.1.2. Gamification...... 11 2.2. Mobile Learning ...... 11 2.2.1. Vorteile ...... 12 2.2.2. Nachteile ...... 12 2.2.3. Abgrenzung zu E-Learning ...... 12 2.2.4. Microlearning ...... 13 2.2.5. Fragenformate ...... 14 2.3. Gamification ...... 14 3. Konzeption vom Mobile-Learning-System „Examize“ ...... 16 3.1.1. Mobile Lernanwendung ...... 16 3.1.2. Online-Plattform ...... 19 4. Technische Grundlagen ...... 22 4.1. Begriffsdefinitionen ...... 22 4.1.1. App ...... 22 4.1.2. Mobile App ...... 22 4.2. Plattformunabhängigkeit ...... 22 4.3. Entwicklungsoptionen einer mobilen Applikation ...... 23 4.3.1. Native App ...... 24 4.3.2. Web App ...... 24 4.3.3. Hybrid App ...... 24 4.3.4. Gegenüberstellung ...... 24 4.4. Mobile Betriebssysteme ...... 25 4.4.1. Android ...... 25 4.4.2. iOS ...... 25 4.4.3. Windows 10 Mobile...... 25 4.4.4. Blackberry 10 ...... 25 4.4.5. Firefox OS ...... 25

4. August 2016 Peter Sonnleitner, BSc 5/79

4.4.6. Sonstige ...... 25 4.4.7. Verbreitung ...... 25 4.4.8. Unterschiede ...... 26 4.5. Hybride Entwicklungsoptionen ...... 26 4.5.1. Hybride Technologieansätze ...... 27 4.5.2. Hybride Frameworks ...... 29 5. Ausgewählte hybride Frameworks ...... 31 5.1. Auswahlkriterien ...... 31 5.2. Bewertung der Auswahlkriterien...... 31 5.3. Ionic ...... 33 5.3.1. Grundlegende Architektur ...... 33 5.3.2. AngularJS ...... 34 5.3.3. Apache Cordova ...... 35 5.3.4. Unterstütze Plattformen ...... 35 5.4. React Native ...... 36 5.4.1. Grundlegende Architektur ...... 37 5.4.2. Komponenten ...... 37 5.4.3. Asynchrone Ausführung ...... 38 5.4.4. Gestaltung von Elementen ...... 38 5.4.5. JSX ...... 38 5.4.6. ECMAScript ...... 39 5.4.7. Abgrenzung zu React (ReactJS) ...... 40 5.4.8. Unterstütze Plattformen ...... 40 6. Implementierung ...... 41 6.1. Online-Plattform ...... 42 6.1.1. Webserver ...... 42 6.1.2. Eingesetzte Web-Technologien ...... 42 6.1.3. Datenspeicherung ...... 43 6.2. REST-API ...... 44 6.2.1. Silex ...... 44 6.3. Mobile Lernanwendung ...... 46 6.3.1. Umsetzung mit Ionic ...... 46 6.3.2. Umsetzung mit React Native ...... 55 7. Vergleichsanalysen zwischen Ionic und React Native ...... 64 7.1. Einarbeitungsaufwand ...... 64 7.2. Realisierungsaufwand ...... 64

4. August 2016 Peter Sonnleitner, BSc 6/79

7.3. Wartungsaufwand ...... 65 7.4. Umsetzbarkeit der Anforderungen ...... 66 7.5. Speicherplatznutzung ...... 67 7.6. Arbeitsspeichernutzung ...... 68 7.7. Automatisierbarkeit (Build-Vorgang) ...... 68 7.8. User Experience und Performance ...... 69 7.9. Testbarkeit und Qualitätssicherung ...... 70 7.10. Fazit ...... 72 8. Zusammenfassung und Ausblick ...... 73 8.1. Zusammenfassung ...... 73 8.2. Ausblick ...... 74 9. Abbildungsverzeichnis ...... 75 10. Tabellenverzeichnis ...... 75 11. Code-Ausschnitte ...... 75 12. Literatur- und Quellverzeichnis ...... 77

4. August 2016 Peter Sonnleitner, BSc 7/79

1. Einleitung

Die ersten Schritte in Richtung Mobile Learning und damit das Fundament für die heutigen mobilen Lernanwendungen, wurden schon sehr früh gemacht. 1981 kam der erste kommerziell verfügbare tragbare Computer auf den Markt, nur zwei Jahre später wurde das erste kommerziell verfügbare Handy vorgestellt (Blümlein, 2013). Auch wenn prinzipiell mobiles Lernen mit diesen Geräten schon denkbar gewesen wäre, gab es noch entscheidende Probleme, zum einen war der Preis sehr hoch, die Geräte sehr schwer und die Akkulaufzeit viel zu kurz um eine sinnvolle Lernumgebung schaffen zu können, zum anderen waren diese Geräte für ganz andere Zwecke, als zum Lernen, konzipiert worden. Seither hat sich in der Technik aber viel getan, die Geräte wurden billiger, kompakter, leistungsfähiger und haben sich sehr stark verbreitet. Irgendwann kam die Idee auf, mobile Geräte in den Lehrprozess einzubinden, daraus entwickelte sich eine völlig neue Disziplin, heute als Mobile Learning bekannt. In den 1990er-Jahren wurden an Universitäten in Europa und Asien erste mobile Lernsysteme für Studenten entwickelt und evaluiert, jedoch waren diese Systeme nicht einmal ansatzweise mit heutigen Lösungen zu vergleichen. (Parzl & Bannert, 2013).

Innerhalb der letzten zehn Jahre hat mobiles Lernen sehr stark an Bedeutung gewonnen, vor allem getrieben durch den Wendepunkt im Smartphone-Markt, welcher 2007 (Mayer, 2012) mit der Einführung des ersten Apple iPhones begonnen hat und zu einer bis heute gigantischen Marktverbreitung von Smartphones führte. Getrieben durch diesen Smartphone-Hype, welcher die Industrie der mobilen Geräte revolutionierte (Mayer, 2012), wurde auch Mobile Learning eine immer relevantere Disziplin, und Lösungen dafür wurden erforderlich. Die steigende Verfügbarkeit von mobilen Technologien und Geräten führt folglich dazu, dass Mobile Learning ein sehr wichtiges Kriterium in der modernen Lehrumgebung wurde.

Das mobile Zeitalter, in dem wir uns derzeit befinden, führte in den letzten Jahren zu gigantischen Möglichkeiten quer durch verschiedene Branchen. Banktransaktionen werden von Hotelzimmern aus gemacht, Autos entwickeln sich zu selbstfahrenden Büros, Flugzeuge werden zu Entertainmentsystemen, und man könnte hier noch viele weitere Beispiele nennen. Die Technologie wäre so weit auch mobiles Lernen neu zu definieren, doch schaut man sich die aktuellen Lehreinrichtungen an, erkennt man, dass davon noch sehr wenig Gebrauch gemacht wird (Florence & Jeffrey, 2013). Hier gibt es verschiedene Problemstellungen, wobei in dieser Arbeit eine Lösung zu einer technischen Schwierigkeit bereitgestellt werden soll.

1.1. Problemstellung und Motivation

In jüngster Vergangenheit wurden sehr viele E-Learning und M-Learning-Projekte umgesetzt. Jedes dieser Projekte hat gezeigt, welche neuen Möglichkeiten mobile Technologien für das Lehren und Lernen bringen können. Diese Chancen gehen weit über die Grenzen von traditionellen Modellen hinaus, bei welchen Klassen von einem Lehrer oder einer Lehrerin geführt werden (Florence & Jeffrey, 2013). Als die ersten mobilen Lernanwendungen entwickelt wurden, war nicht bekannt, welche Probleme das alles mit sich bringen wird. Einige sind technische Probleme, wie etwa fehlende Kompatibilität zu allen modernen Betriebssystemen und Plattformen, andere sind pädagogisch relevant, wie man etwa den Lehrinhalt einfach auf den kleinen Bildschirm von mobilen Geräten bekommen kann oder der nicht zu unterschätzende Aufwand den traditionellen Lernstoff in mobile Lernsysteme zu integrieren. Außerdem ist die

4. August 2016 Peter Sonnleitner, BSc 8/79

Akzeptanz von Mobile Learning Systemen bei Lernenden oft nicht sehr hoch, wodurch einige Systeme bereits gescheitert sind. (Beutner & Pechuel, 2014)

Und genau für diese Problemstellungen soll eine Lösung angeboten werden. Für die technisch schwierige Aufgabe der Plattformunabhängigkeit gibt es in der heutigen Zeit einige interessante Entwicklungsoptionen. Ein plattformunabhängiges Programm zu schreiben, welches auf jeder Plattform ohne weitere Anpassungen ausgeführt werden kann, hat in der Geschichte der Softwareentwicklung immer wieder zu großen Problemen geführt (Heitkötter & Hanschke, 2012). Als der kommerzielle Computer-Markt richtig zu wachsen begann, wurden durch Microsoft, Apple und diverse andere Firmen bereits völlig unterschiedliche Betriebssysteme bereitgestellt, und es wurden dadurch viele Kompatibilitätsprobleme in der Softwareentwicklung geschaffen (Heitkötter & Hanschke, 2012). Immer wieder gab es Cross-Plattform-Ansätze, welche versuchten diese Probleme zu lösen, denn die Vorteile plattformunabhängiger Software liegen auf der Hand: kürzere Entwicklungszeiten, weniger Aufwand, mehr potenzielle Kunden, leichtere Instandhaltung. Für den durchschnittlichen Endanwender oder der durchschnittlichen Endanwenderin sind diese Kriterien aber völlig irrelevant, hier zählt Performance, Funktionalität, Design und Usability. Und genau an diesen Punkten scheitern oft die hybriden Ansätze (Ishizaka & Nemery, 2013).

In den letzten fünf Jahren machten mobile hybride Applikationen enorme Sprünge nach vorne und können vereinzelt bereits mit nativ entwickelten Anwendungen basierend auf Objective-C (iOS) oder Java (Android) konkurrieren. Entwickler und Entwicklerinnen, welche auf Basis von HTML5, CSS3 und JavaScript oder anderen plattformübergreifenden Technologien mobile Apps realisieren möchten, können auf reife und bewährte Frameworks zurückgreifen, die ein solides Fundament bieten und damit die Entwicklung beschleunigen können (Biswanger, 2016).

Informationen, Dienste und Daten sind unabhängig von Zeit und Ort immer und überall verfügbar. Der Zugriff auf Informationen findet immer öfter über mobile Endgeräte wie etwa Smartphones statt. Auch bei den Themen rund um das Lernen hat sich einiges verändert, so rückte E-Learning und in weiterer Folge Mobile Learning immer weiter in den Fokus. Mobile Lernapplikationen müssen plattformunabhängig und für alle Anwender und Anwenderinnen verfügbar sein, damit auch wirklich uneingeschränkt auf den Lehrinhalt zugegriffen werden kann. Es gibt viele verschiedene Technologieansätze mit denen so eine plattformübergreifende Lernanwendung umgesetzt werden kann. Die Auswahl einer geeigneten und richtigen Technologie für die Implementierung stellt eine große Herausforderung dar, weil durch eine Fehlentscheidung ein Projekt sehr leicht scheitern kann und immense zusätzliche Kosten verursacht werden können.

Plattformunabhängigkeit ist für ein Mobile-Learning-System besonders wichtig, da nur so sichergestellt werden kann, dass wirklich jeder auf die Lehrinhalte Zugriff hat (Kuszpa & Scherm, 2010). Diese Problemstellung der schwierigen, plattformübergreifenden Entwicklung einer mobilen Lernanwendung mit hybriden Technologien gilt es zu lösen.

1.2. Zielsetzung

Ziel ist es, ein Mobile-Learning-System zu entwerfen, welches am Smartphone einfach und effektiv bedient werden kann und Ansätze von Mobile Learning, Gamification und Microlearning miteinander vereint, damit bei Lernenden eine möglichst große Akzeptanz vom Lernsystem

4. August 2016 Peter Sonnleitner, BSc 9/79

geschaffen werden kann und dadurch eine Steigerung der Lernmotivation eintritt. Dieser Entwurf soll in weiterer Folge mit modernen plattformübergreifenden Technologien entwickelt werden, bestehend aus einer mobilen App und einer begleitenden Online-Plattform. Der Name von diesem Projekt lautet „Examize“, das gesamte System wird in der folgenden Arbeit als „Examize Mobile-Learning-System“ bezeichnet. Der Projektname wurde vom englischen Wort „examine“ abgeleitet, was im Deutschen einfach für „prüfen“ steht. Für die mobile Lernanwendung sollen Grundsätze von Mobile Learning mit Gamification- und Microlearning-Ansätzen vereint werden, und so eine zukunftsorientierte Lernapplikation geschaffen werden. Diese mobile App wird im Folgenden als „Examize App“ bezeichnet. Auf der begleitenden Online-Plattform, im Folgenden als „Examize-Plattform“ oder „Online-Plattform“ bezeichnet, sollen von Kursleitern oder Kursleiterinnen diverse Lehrinhalte für diese mobile Applikation mit einfachsten Mitteln bereitgestellt werden können. Die App soll plattformunabhängig installierbar sein und mit zukunftssicheren mobilen Frameworks entwickelt werden. Dafür sollen zwei Frameworks ausgewählt und gegenübergestellt werden, anschließend soll die hybride Applikation mit diesen implementiert und das Ergebnis präsentiert werden. Das technische Ziel dieser Arbeit ist es, zu ermitteln, mit welchem Framework so eine mobile Applikation einfach und effektiv entwickelt werden kann.

1.3. Inhaltlicher Aufbau der Arbeit

Der inhaltliche Aufbau der Arbeit gliedert sich in mehrere Hauptpunkte. Zu Beginn werden die Grundlagen von Mobile Learning und Gamification beschrieben und darauf aufbauend gemeinsam mit Microlearning interessante Aspekte für eine mobile Lernanwendung abgeleitet. Darauf folgend wird ein Entwurf vom Mobile-Learning-System spezifiziert, in welchem genau auf diese Punkte Bezug genommen und das gesamte System näher beschrieben wird. Dies gliedert sich in die Vorstellung von der mobilen Lernanwendung und der Online-Plattform, die dafür notwendigerweise zwingend implementiert werden muss.

Damit dieses System mit soliden Frameworks implementiert werden kann, werden einige technische Grundlagen beschrieben und theoretisch behandelt, dies bezieht sich vor allem auf die mobile App-Entwicklung, weil hier auch der Fokus von dieser Arbeit liegt. Es werden allgemeine Entwicklungsoptionen für eine mobile Applikation vorgestellt und hybride Technologieansätze genauer behandelt. Aus diesen Grundlagen werden Auswahlkriterien für hybride mobile Frameworks abgeleitet und zwei davon, nämlich Ionic und React Native, im darauf folgenden Kapitel näher beschrieben und genauer behandelt.

Die mobile Lernapplikation wird in weiterer Folge mit diesen Frameworks implementiert, dazu werden die ersten Schritte und ausgewählte Implementierungsaspekte von der Umsetzung mit beiden Frameworks beschrieben und diese, in darauf aufbauenden Vergleichsanalysen, gegenübergestellt. In diese Vergleichsanalysen, welche sich in Dimensionen wie Einarbeitungsaufwand, Speicherplatznutzung, Testbarkeit und viele weitere gliedern, fließen auch theoretische Aspekte mit ein und es wird daraus auch ein Fazit gezogen, mit welchem Framework sich so eine plattformübergreifende mobile Lernapplikation besser entwickeln lässt.

Am Ende gibt es noch eine kurze Zusammenfassung dieser Arbeit mit einem Ausblick, wie dieses Projekt fortgeführt oder erweitert werden könnte. Dazu werden einige interessante Ideen vorgestellt.

4. August 2016 Peter Sonnleitner, BSc 10/79

2. Grundlagen von Mobile Learning und Gamification

In diesem Kapitel werden die Grundlagen von Mobile Learning und Gamification beschrieben. Basierend auf diesen Grundlagen wird in weiterer Folge ein System entworfen, welches einige der in diesem Kapitel beschriebenen Mobile Learning und Gamification Ansätze verwendet. Dieses System wird unter Punkt 3 grundlegend spezifiziert.

2.1. Begriffsdefinitionen

Bevor auf die Begriffe Mobile Learning und Gamification näher eingegangen wird, werden diese in den folgenden Unterpunkten kurz definiert.

2.1.1. Mobile Learning Unter Mobile Learning, oft auch als M-Learning oder mLearning bezeichnet, versteht man vereinfacht ausgedrückt das Lehren und Lernen mit mobilen Infrastrukturen, Anwendungen oder Geräten, ganz unabhängig von Zeit und Ort des Geschehens. Dieser Begriff ist dem E-Learning zurechenbar und wurde auch davon abgeleitet. (Springer Fachmedien Wiesbaden GmbH, 2016)

2.1.2. Gamification Gamification, auch bekannt unter Gamifizierung und Spielifizierung, bedeutet in der Kurzerklärung eine Übertragung von spieltypischen Elementen und Vorgängen, wie etwa die Vergabe von Punkten im spielfremden Zusammenhang. Das Ziel davon ist, zum einen Motivationssteigerung, zum anderen eine Verhaltensänderung bei den Anwendern und Anwenderinnen zu erreichen. (Springer Fachmedien Wiesbaden GmbH, 2016)

2.2. Mobile Learning

Früher spielte sich das Lernen hauptsächlich zu Hause oder in einer Lehreinrichtung ab, dies hat sich in den letzten Jahren stark verändert. Durch E-Learning verlagerten sich Lernaktivitäten zum Computer, und vom Computer aus wanderte das Ganze auf die Smartphones und Tablets, und genau an diesem Punkt kommt Mobile Learning ins Spiel. Diese Techniken erlauben es, an jedem Ort und zu jeder Zeit zu lernen, dadurch können unter anderem diverse „Leerzeiten“ für den Wissensaufbau genutzt werden, zum Beispiel beim Warten auf die Straßenbahn. Aber auch andere interessante Ansätze bringt diese Form des Lernens mit sich, so können Kompetenzen nun auch situiert, etwa an historischen Plätzen oder Exkursionen, erworben werden. Lerninhalte können mit Hilfe von mobilen Endgeräten und zugehöriger Anwendungen schnell und einfach global verteilt werden. Im konkreten Fall werden unter M-Learning alle Systeme verstanden, welche es erlauben, mit mobilen Endgeräten auf verteilte Lehrbeiträge zuzugreifen. Unter einem mobilen Endgerät versteht man ein Multimediagerät, welches transportabel ist, zumindest Zeitweise ohne externe Stromversorgung auskommt und drahtlose Kommunikationsschnittstellen besitzt. (Springer Fachmedien Wiesbaden GmbH, 2016)

M-Learning entwickelte sich neben bereits etablierten E-Learning-Systemen zu einem wesentlicheren Aspekt im Bildungsbereich. Neuartige Entwürfe einer mobilen Lernanwendung dürfen nicht bei der Bereitstellung einer bestimmten Technologie enden, sondern müssen auch die Aspekte einer Ortsentkoppelung zwischen Lehrer und Lerner, sowie eine Zeitentkoppelung zwischen Content-Bereitstellung und Content-Konsum beachten, um so eine Lernsituation

4. August 2016 Peter Sonnleitner, BSc 11/79

schaffen zu können, welche ganz unabhängig von Zeit und Ort ist, und so eine lernprozessorientierte Unterstützung bieten kann (Ferscha, 2007). Die User und Userinnen einer Applikation müssen die Aufnahme der Lehrinhalte als Zeitvertreib empfinden und diesen Lernprozess, etwa beim Warten auf die Straßenbahn oder im Wartezimmer eines Arztes, interaktiv erleben (Walsdorf, 2014).

2.2.1. Vorteile Der Hype rund um Mobile Learning wurde in den letzten Jahren sehr groß und dieser Disziplin wird sehr großes Zukunftspotential zugesprochen. Vorteile gibt es sehr viele, einige werden in den folgenden Punkten kurz erläutert. (Stiftung Medien in der Bildung (SbR), 2016)

 Es kann an jedem beliebigen Ort zu jeder Zeit gelernt werden, dadurch können über den Tag verteilte Leerräume effektiv genutzt werden.  Der Lernstoff kann sehr leicht personalisiert und für Individuen angepasst werden. Unterschiedliche Lerntypen können mit verschiedenen Methoden lernen, etwa durch lesen, hören oder einer Kombination von beidem. Außerdem hat jede Person ein individuelles Lerntempo, durch Mobile Learning kann dieses Tempo und die Lernumgebung individuell festgelegt werden.  Das unmittelbare Abrufen von Informationen unterstützt einige Lernaspekte, hinzu zählen unter anderem das problem- und bedarfsorientierte Lernen.  Das gemeinschaftliche Lernen wird unterstützt, man kann von unterschiedlichen Orten gemeinsam auf den Lernstoff zugreifen und darüber diskutieren.  Der Inhalt, der in der mobilen Plattform vorgestellt wird, ist meist kompakt und prägnant, dadurch können sich Lernende den Lehrstoff leichter einprägen.  Lernende bevorzugen Methoden, die alltäglich neben diversen Aktivitäten durchgeführt werden können, dadurch entsteht eine automatisierte Lerngewohnheit.

2.2.2. Nachteile Mobile Learning darf nicht als Ersatz für bisherige Lernkonzepte gesehen werden. Es gibt einige Rahmenbedingungen, von denen es abhängt, ob ein mobiles Lernangebot in einer Lehrsituation sinnvoll ist und auch eingesetzt werden kann. Zu diesen Bedingungen zählt etwa, ob die Zielgruppe M-Learning akzeptiert oder das Lernziel durch mobile Methoden erreicht werden kann. Intensives Lehren oder Lernen mit komplexen Zusammenhängen ist mit Mobile Learning nur schwierig umsetzbar, da durch die kleinen Bildschirme meist nicht genügend Informationen dargestellt werden können, und durch die orts- und zeitunabhängige Lernumgebung die notwendige Konzentration oft nicht aufgebracht werden kann. Der ständige Lernzwang kann auch als Belastung empfunden werden, wenn er falsch interpretiert wird. (Stiftung Medien in der Bildung (SbR), 2016)

2.2.3. Abgrenzung zu E-Learning Eine eindeutige Abgrenzung zwischen E-Learning- und M-Learning-Anwendungen ist nicht möglich, da diese Begriffe miteinander verwandt sind und auch Verwurzelungen von Kerndisziplinen aufweisen. Eine klare Unterscheidung liegt jedoch unter anderem bei der technischen Sichtweise vor, so sind Mobile-Learning-Anwendungen typischerweise für den Einsatz unterwegs konzipiert worden, das bedeutet im konkreten Fall, für einen kleineren Bildschirm, für geringere Bandbreite und weniger Speicherplatz ausgelegt. E-Learning-

4. August 2016 Peter Sonnleitner, BSc 12/79

Applikationen sind eher für Computer und Laptops konzipiert, diese können teilweise durch mobile Lerntechnologien ersetzt werden, zum Beispiel durch mobile Apps. (Witt & Sieber, 2013) Diese Verdrängung von E-Learning durch Mobile Learning lässt sich auch in Google Trends gut visualisieren, so hat sich in den letzten Jahren das Interesse ganz klar hin zu Mobile Learning entwickelt. Man kann also erahnen, dass Mobile Learning auch in Zukunft immer weiter vorrücken wird und einen noch größeren Stellenwert einnehmen wird. In der Abbildung 1 wird das Interesse zwischen Mobile Learning und E-Learning im Laufe der Zeit in Google Trends gezeigt.

Abbildung 1: Mobile Learning (blau) und E-Learning (rot) in Google Trends

2.2.4. Microlearning Unter Microlearning, auch Mikrolernen, wird das Lernen in kleinen Schritten bezeichnet. Dabei wird der Lehrinhalt in viele kleine Lerneinheiten aufgeteilt, diese Einheiten sind auch unter „Micro-Contents“ bekannt. Unter dieser Bezeichnung wird nicht nur der Inhalt beschrieben, auch die Zeitspanne kann in kleine Einheiten unterteilt werden. Darunter versteht man vor allem die benötigte Zeit um ein bestimmtes Themengebiet zu erlernen. Die Dauer eines Lernprozesses, welcher unter Mikrolernen beschrieben wird, ist nicht eindeutig definiert und kann in einer großen Spanne ausgewählt werden, welche von wenigen Sekunden bis hin zu einigen Minuten reicht. (Baumgartner, 2013)

Der Microlearning-Prozess beinhaltet kurze Lernaktivitäten, welche den Lehrinhalt in kleinen Modulen gekapselt beinhalten und in kurzen Zeitspannen abgehandelt werden. Das Lernen findet nicht nur durch das Durchforsten von Theorie statt, sondern wird durch Antworten, Feedback, Verbesserungen und ähnlichen erreicht. Ein großer Vorteil hierbei ist, dass durch die kleinen Lerninhalte eine sofortige und direkte Kontrolle des Erfolges durchgeführt werden kann. Wurde das Lernziel eines Modules nicht erreicht, wird es einfach wiederholt. (Baumgartner, 2013).

Laut Baumgartner (2013) gibt es verschiedene Dimensionen des Micro-Lernens, die wichtigsten davon werden im Folgenden kurz erläutert.

 Zeit: Die einzelnen Lerneinheiten dauern nur einige Sekunden, maximal einige Minuten an.  Inhalt: Die Themen sind in kleinen Modulen aufgebaut, welche nur auf ein Thema beschränkt sind.

4. August 2016 Peter Sonnleitner, BSc 13/79

 Feedback: Der Lernerfolg wird unmittelbar kontrolliert und durch direktes Feedback begleitet.  Form: Die Strukturierung der Module ist einfach, in einzelnen Fragmenten oder Elementen aufgebaut.

2.2.5. Fragenformate Die Auswahl der gewählten Frageformate für das Mobile-Learning-System basiert auf einer Umfrage der Fernuniversität Hagen, welche an Unternehmen aus dem Bildungssektor durchgeführt wurde. Dabei wurden Mitarbeiter und Mitarbeiterinnen mit Erfahrungen und Expertenwissen im E-Learning oder M-Learning-Bereich befragt. Die Beantwortung der Fragen erfolgte anhand einer fünfstufigen Skala. Laut dieser Umfrage sind offene Fragen und Textaufgaben für mobile Lernanwendungen nicht geeignet, dies liegt auch an der schwierigen Bedienbarkeit und der mühsamen Texteingabe auf mobilen Geräten. Am sinnvollsten und effektivsten einsetzbar sind Wahr-/Falsch-Aussagen zusammen mit Multiple-Choice-Aufgaben, weil diese sehr einfach und schnell beantwortet werden können. Deshalb werden diese zwei Fragenformate auch für die mobile Lernanwendung verwendet.

Abbildung 2: Sinnvolle Lernformen vom Mobile Learning (Kuszpa & Scherm , 2010)

2.3. Gamification

Der Gamification-Begriff kommt aus dem Englischen und wird im Deutschen gerne auch als Spielifizierung oder Spielifikation bezeichnet. Konkret bedeutet der Begriff eine Übertragung von Elementen, welche typischerweise in Spielen Anwendung finden, in spielfremde Zusammenhänge. Dadurch kann unter anderem eine Motivationssteigerung bei diversen Aktivitäten erreicht werden. Dies kann mit verschiedenen Maßnahmen umgesetzt werden, Ziel ist es aber immer, dass man den Spaß an der Arbeit erhöht und dadurch das Verhalten von Menschen beeinflusst, also Motivation in verschiedenen Dimensionen aufbaut. Der Entwurf von Gamification-Ansätzen ist in der Theorie sehr einfach umzusetzen, zum Beispiel indem man Spielen bestimmte Elemente, wie etwa Punktesysteme, entnimmt und sie in anderen Umgebungen, wie etwa Lernanwendungen, einbaut. (Springer Fachmedien Wiesbaden GmbH, 2016)

4. August 2016 Peter Sonnleitner, BSc 14/79

Ziele und Eigenschaften dieser Disziplin sind die Motivation bei Anwendern und Anwenderinnen zu steigern, damit monotone Aufgaben leichter erfüllt werden können und eine Verhaltensänderung bewirkt werden kann. Aufgaben sollen ähnlich wie bei einem Spiel mit individuellen Leistungen erledigt werden (Tröger, 2016). Dieser Einsatz von Spielprinzipien zum Erzielen einer Verhaltensänderung ist nicht neu. Gamification-Ansätze werden schon lange in diversen Branchen eingesetzt, zum Beispiel gibt es diverse Treuepunkteaktionen in Supermärkten, was vergleichbar mit einem Punktesystem ist, und erst bei einer erreichten Mindestpunkteanzahl gibt es eine Belohnung. Dieser breite Anwendungsbereich wird immer größer, so findet Gamification mittlerweile auch bei Lehranwendungen Verwendung. (Gabriel, 2016)

Ob Gamification von Anwendern oder Anwenderinnen akzeptiert wird, hängt stark von deren Haltung gegenüber Spielen ab. Wird Gamification in einer Zielgruppe eingesetzt, in der nur ungerne gespielt wird, kann dieses Vorhaben auch schnell schief gehen. Außerdem müssen Gamification-Ansätze sinnvoll eingesetzt und in den Anwendungsprozess möglichst unauffällig integriert werden, sonst wirkt die Umsetzung unprofessionell und stößt auf geringe Akzeptanz bei den lernenden Personen. (Tröger, 2016)

Gamification beinhaltet einige spieltypische Elemente, einige davon sind laut Gabriel (2016) folgende:

 Sichtbarer Status: Der aktuelle Fortschritt ist immer klar ersichtlich. Dies kann etwa durch Punkte, Fortschrittsbalken oder Level dargestellt werden.  Rangliste: Durch eine Rangliste kommt es zum Wettbewerbsgedanken der wiederum zu Motivation führt, außerdem schafft er eine Vergleichsmöglichkeit zwischen Individuen.  Aufgaben: Bestimmte Aufgaben, oft auch als Quests bezeichnet, müssen innerhalb einer bestimmten Zeit erledigt werden.  Feedback: Durch Feedback kann dem Nutzer oder der Nutzerin mitgeteilt werden, ob eine bestimmte Aktion zum Erreichen des Zieles vorteilhaft war.  Stufenweise Informationen: Es werden nur jene Informationen dargestellt, welche für die aktuelle Aufgabe notwendig sind.  Zeitdruck: Durch feste Zeitvorgaben entsteht ein gewisser Druck, der dazu führt, dass man Lerneinheiten konzentrierter und produktiver erledigt.

Gamification ist am effektivsten, wenn Menschen durch gesetzte Anreize Aufgaben erledigen, welche sie ansonsten nur ungern durchführen würden. Um dieses Ziel langfristig zu erreichen, muss die sogenannte extrinsische Motivation durch intrinsische ersetzt werden. Das bedeutet, es soll erreicht werden, dass Aufgaben erledigt werden, weil eine Person das selbst möchte, und diese nicht durch Anerkennung und Erfolg von außen dazu gezwungen wird. (Tröger, 2016)

Wenn Gamification richtig eingesetzt wird, kann ein Nutzer oder eine Nutzerin an ein Lernprodukt gebunden werden und die regelmäßige Verwendung davon erreicht werden. Oft wird aber kritisiert, dass dadurch nur das gelernt wird, was für den Erfolg zwingend notwendig ist. Konkrete Lerninhalte werden laut diversen Studien folglich kaum vermittelt, dieses Problem ist aber nicht bei jedem System nachvollziehbar. (Tröger, 2016)

4. August 2016 Peter Sonnleitner, BSc 15/79

3. Konzeption vom Mobile-Learning-System „Examize“

Auf Basis der im 2. Kapitel beschriebenen theoretischen Grundlagen wurde ein System entworfen, welches Mobile Learning, Gamification und Microlearning miteinander verbindet. Dieses System trägt den Namen „Examize Mobile-Learning-System“ und wird in diesem Kapitel näher beschrieben. Dafür wurde ein Entwurf der mobilen Applikation und der Plattform angefertigt, welcher in weiterer Folge implementiert wird. Die Plattform wird mit bewährten Technologien entwickelt, mehr dazu unter Punkt 6.1. Die mobile Applikation wird mit zwei modernen hybriden Frameworks umgesetzt und diese anschließend, aufgrund der Implementierungserfahrung, gegenübergestellt. Ziel ist es, ein vollkommen funktionsfähiges System zu entwickeln welches soweit fortgeschritten ist, dass es in einem realen Experiment eingesetzt werden kann.

3.1.1. Mobile Lernanwendung Im Folgenden werden die Grundidee, der genaue Ablauf und der Entwurf von der mobilen Lernanwendung grundlegend spezifiziert.

Abbildung 3: Entwurf vom Splashscreen und vom Menü in der Examize-App

Die App muss sich auf einem echten Android- oder iOS-Gerät installieren lassen, dadurch kann sie zu jeder Zeit und an jedem Ort verwendet werden. Die technischen Grundbedingungen für eine mobile Lernapplikation sind mit diesen Kriterien in vollem Umfang erfüllt. Startet man die App, erscheint der Splashscreen, wie in Abbildung 3 links ersichtlich, dieser wird so lange

4. August 2016 Peter Sonnleitner, BSc 16/79

dargestellt bis die Applikation vollständig geladen und initialisiert wurde. Ein Splashscreen ist ein sogenannter Bootscreen oder Willkommensscreen, es handelt sich dabei einfach gesagt um eine Einleitungsseite, welche erscheint, wenn ein Computerprogramm geladen wird oder startet (Computer Hope, 2016). Sobald die App geladen ist, erscheint das Menü, wie in Abbildung 3 rechts ersichtlich. Dabei handelt es sich um den zentralen Navigationspunkt der Applikation, von hier aus ist alles Wesentliche leicht zu erreichen. Unter dem Punkt „Alle Kurse“ kann man sich alle Kurse anzeigen lassen, welche auf der Online-Plattform bereitgestellt werden. Wenn ein Kurs gestartet wird, wird dieser heruntergeladen und ist anschließend unter „Meine Kurse“ aufgelistet und auch offline verfügbar. Diese absolute Offlinefähigkeit ist ein wichtiges Kriterium, da nur so sichergestellt werden kann, dass wirklich an jedem Ort gelernt werden kann. Außerdem gibt es die Möglichkeit einen QR-Code zu scannen, dazu muss ein entsprechender Examize-QR-Code vorhanden sein, welcher auf der Plattform generiert werden kann. Wird so ein Barcode eingescannt, springt man direkt in die Modulübersicht eines Kurses und kann mit einem beliebigen Modul beginnen.

Abbildung 4: Entwurf der Kursübersicht und der Modulübersicht der Examize-App

Ein Kurs besteht aus verschiedenen Modulen, wobei zu jedem Modul verschiedene Fragen mit verschiedenen Fragenformaten definiert werden können. Im Grundsystem muss es möglich sein, die unter Punkt 2.2.5. beschriebenen, für Mobile Learning sinnvollsten Fragenformate, also Wahr-/Falsch-Aussagen und Multiple-Choice-Aufgaben, zu definierten. Weitere Fragenformate müssen einfach implementiert werden können, das System muss in diesem Hinblick also möglichst generisch gehalten werden.

4. August 2016 Peter Sonnleitner, BSc 17/79

In Abbildung 4 ist links die Kursliste zu sehen, dabei handelt es sich um eine Auflistung aller verfügbaren Kurse. Klickt man auf einen beliebigen Kurs, dann erscheint die Modulübersicht, welche in dieser Abbildung rechts dargestellt wird. Jeder Kurs besteht aus einer beliebigen Anzahl an Modulen, und jedes Modul besteht aus einer beliebigen Menge an Fragen, einem sogenannten Fragenpool. Die Fragen müssen so lange beantwortet und wiederholt werden, bis eine definierte Punkteanzahl erreicht wurde. Hier wurde zu den Gamification-Aspekten Punktevergabe und Fortschritt-Anzeige Bezug genommen. Erst wenn bei jedem Modul die definierte Mindestpunkteanzahl erreicht wurde, wurde ein Kurs bestanden. In der Modulübersicht erkennt man ein bestandenes Modul durch einen grünen Haken, welcher in weiterer Folge die Fortschrittsanzeige definiert. Bei der Aufteilung in Modulen wurde auf die Microlearning-Ansätze „Kurze Lerneinheiten“ und „Modulauftrennung“ Bezug genommen.

Abbildung 5: Entwurf der Darstellung einer Wahr-/Falsch-Aussage in der Examize-App In der Abbildung 5 ist eine Wahr-/Falsch-Aussage abgebildet. Diese Frage muss durch Wischen der Karte (mit der Aussage) nach links oder rechts beantwortet werden. Ein Wischen nach links bedeutet, die Aussage wird als falsch angesehen. Im Gegenteil dazu, bedeutet ein Wischen nach rechts, dass die Aussage als richtig angesehen wird. Wenn eine Frage richtig beantwortet wurde, erhält man dafür Punkte, wurde sie falsch beantwortet, erhält man Strafpunkte. Außerdem erscheint nach dem Beantworten einer Frage ein definiertes Feedback. Hier wurden einige Gamification-Ansätze eingearbeitet, zum Beispiel spieltypische Elemente durch die Wischkarten (Swipeable-Cards), einem Punktesystem, Zeitdruck durch die Zeitbegrenzung, stufenweise Information und sofortiges Feedback. Durch den roten Balken wird die verfügbare Zeit zur Beantwortung der Frage dargestellt, diese ist für jede Frage individuell festgelegt und innerhalb von dieser Zeit muss eine Frage

4. August 2016 Peter Sonnleitner, BSc 18/79

beantwortet werden. Ist das nicht möglich, wird die Frage nach Ablauf der Zeit als falsch gewertet und es erscheint die nächste Frage. Im Hintergrund werden alle Daten, welche durch die Beantwortung einer Frage generiert werden, gesammelt an die Plattform übertragen, dadurch erhält ein Kursbetreuer oder eine Kursbetreuerin sofortiges Feedback, etwa wie die Lernenden mit den definierten Fragen zurechtkommen. Dabei wurde ein weiterer Mobile- Learning-Ansatz eingearbeitet, nämlich einer direkten Verbindung zwischen Lernenden und Lehrenden.

3.1.2. Online-Plattform Die Online-Plattform richtet sich speziell an Lehrende, also etwa an Lehrer oder Lehrerinnen, welche Kurse auf der mobilen Lernanwendung anbieten möchten. Der Zugang zur Plattform ist beschränkt, damit nur qualifizierte Kursersteller oder Kurserstellerinnen die Möglichkeit haben, Kurse zu erstellen. Um Zugang zu erhalten, muss ein Registrierungsformular ausgefüllt werden und Zugangsdaten angefordert werden, sobald diese Daten durch die Plattformbetreiber oder Plattformbetreiberin geprüft und freigeschaltet wurden, kann man sich auf der Plattform anmelden. Durch den Login-Vorgang erhält man Zugriff auf die Kurs-Administration.

In der Kursübersicht können sich Lehrende einen Überblick über ihre eigenen erstellen Kurse verschaffen. Jeder Kurs besteht aus einem Titel, einer eindeutigen Kursidentifikationsnummer, einer Beschreibung und aus einer beliebigen Anzahl an Modulen, wobei für jedes Modul ein individueller Name festgelegt werden kann. Außerdem kann für jeden Kurs eingestellt werden, ob er öffentlich zugänglich ist oder nur mit entsprechenden Zugangsdaten der Zugriff darauf möglich ist. Zusätzlich können an dieser Stelle alle wichtigen Informationen zu Kursen verwaltet werden, diese können für die mobile Lernapplikation freigeschaltet werden, der Inhalt eines Kurses kann verändert werden und sie können bearbeitet und/oder gelöscht werden. Des Weiteren können Zugangsschlüssel für einen Kurs generiert werden. Für das Anlegen neuer Kurse gibt es keine Limitierung oder Vorgaben in Inhalt oder Menge. Die Lehrenden sind für die Qualität der Kurse selbst verantwortlich.

Abbildung 6: Entwurf der Kursübersicht auf der Examize-Plattform

4. August 2016 Peter Sonnleitner, BSc 19/79

Wenn ein Kurs als nicht öffentlich zugänglich eingestuft wurde, müssen entsprechende Zugangsschlüssel generiert und verteilt werden, damit Lehrende Zugriff auf den entsprechenden Lehrinhalt haben. Der Name von einem Zugangsschlüssel kann beliebig gewählt werden, es kann sich etwa um eine Matrikelnummer oder einen Namen handeln, das Passwort für jeden Schlüssel wird beliebig generiert. Zu jedem Zugangsschlüssel wird automatisch ein QR-Code generiert, welcher in der App mit einem Barcode-Scanner gescannt werden kann und Lernende somit sofort in den Kurs hineinspringen, ohne lange in der Navigation nach dem richtigen Kurs suchen zu müssen.

Abbildung 7: Entwurf der Zugangsschlüsselübersicht auf der Examize-Plattform

Für jedes Modul können in einem Inhaltseditor verschiedene Fragen mit verschiedenen Fragenformaten definiert werden. Diese werden im Kursinhalt gegliedert nach Modulen angezeigt und werden je nach Fragentyp unterschiedlich dargestellt. Bei einer Wahr-/Falsch- Aussage wird zum Beispiel die Aussage mit dem Status, ob sie richtig oder falsch ist, ausgegeben. In der Übersicht ist außerdem die Anzahl der Punkte ersichtlich und eine Frage kann bearbeitet oder gelöscht werden. Zu jeder Frage werden die Statistikdaten, welche von Lernenden mit der mobilen Lernapplikation generiert wurden, zusammengefasst und ausgegeben. So ist es für einen Kursersteller oder eine Kurserstellerin möglich, auf den ersten Blick zu erkennen, wie oft eine Frage richtig beantwortet wurde und wie lange die durchschnittliche Antwortdauer ist.

Abbildung 8: Entwurf der Darstellung eines Kursinhaltes auf der Examize-Plattform

4. August 2016 Peter Sonnleitner, BSc 20/79

Durch einen Klick auf die Statistikdaten, welche auf der Abbildung 8 rechts unten zu sehen sind (die blau, rot und gelben Kästchen), können die Statistikdaten im Detail betrachtet werden. Kursbetreuer und Kursbetreuerinnen erhalten somit Informationen, in welchem genauen Verlauf die Fragen beantwortet wurden und wie sich der Punkteverlauf entwickelt hat. Diese Daten können beliebig gefiltert werden, etwa durch einen entsprechenden Zugangsschlüssel oder einem Modul. Durch Zugangsschlüssel kann auch die Verbindung zu entsprechenden Individuen hergestellt werden, beispielsweise wenn eine Person einen Zugangsschlüssel mit einer Matrikelnummer erhält, können später die Statistikdaten nach dieser Matrikelnummer gefiltert werden. Dadurch können Lehrende auch persönliches Feedback geben, diese Verbindung lässt sich aber auch leicht anonymisieren, etwa durch die Verwendung von zufällig generierten Zugangstokens, welche sich nicht mit einer bestimmten Person assoziieren lassen. Damit Lehrende möglichst einfach und schnell Fragen definieren können und damit die Verwendung von dem System bessere Akzeptanz findet, wurde ein Editor entworfen, bei welchem der Fokus auf einfache Bedienbarkeit gesetzt wurde. Dieser ist in Abbildung 9 ersichtlich, so kann eine neue Aussage durch ein paar Klicks und Eingaben erstellt werden. Die Punkte für die richtige Antwort werden automatisch vorausgefüllt, die Zeit zur Beantwortung der Frage kann automatisch berechnet werden, und das Feedback ist optional. Im einfachsten Anwendungsfall muss nur eine einfache Wahr-/Falsch-Aussage mit dem Status, ob diese richtig oder falsch ist, definiert werden.

Abbildung 9: Entwurf vom Wahr-/Falsch-Aussage-Editor auf der Examize-Plattform Neben einem Inhaltseditor gibt es auch noch die Möglichkeit, Fragen direkt aus anderen Systemen zu importieren oder in andere Systeme zu exportieren. Diese Import-/Export-Funktion soll möglichst generisch gehalten werden, damit einfach neue Formate implementiert werden können. Im ersten Schritt werden die Formate für ein Moodle-XML-Format und für ein Examize- CSV-Format unterstützt, damit ist es beispielsweise möglich, Fragen direkt aus Moodle in dieses System zu importieren. Das ist insbesonders für die Migration von anderen Lernsystemen zur Examize-Anwendung wichtig, da somit der Umstellungsaufwand drastisch reduziert werden kann.

4. August 2016 Peter Sonnleitner, BSc 21/79

4. Technische Grundlagen

In diesem Kapitel werden die technischen Grundlagen für die mobile App-Entwicklung beschrieben. Basierend auf diesen Grundlagen werden in weiterer Folge hybride Frameworks für die Implementierung von der Mobile-Learning-Anwendung gegenübergestellt und ausgewählt.

4.1. Begriffsdefinitionen

Bevor auf die Entwicklungsoptionen einer mobilen App näher eingegangen wird, werden in diesem Unterkapitel diese Begriffe kurz definiert. 4.1.1. App Der Definitionsrahmen für den Begriff App ist im „Everything is an App“-Zeitalter sehr breit. Anfang der 2000er Jahre gab es für Applikationen viele verschiedene Begriffe, wie etwa „program“, „script“, „service“, oder „software“. Mit dem Beginn des Smartphone-Zeitalters, vor allem getrieben durch die Erscheinung vom ersten iPhone und der damit in Zusammengang stehenden Entstehung von dem iOS App Store (2008), sind diese Begriffe immer mehr zum Oberbegriff App verschmolzen. App ist einfach die Abkürzung für Applikation, auch bekannt unter Anwendungssoftware oder Anwendungsprogramm, und damit wurden in jüngster Vergangenheit hauptsächlich Computerprogramme bezeichnet, welche diverse Funktionalitäten, wie etwa Bildbearbeitung, bereitgestellt haben. Technisch gesehen ist eine Applikation eine Anwendung, welche das letzte Bindeglied zwischen dem einzelnen Nutzer oder der Nutzerin und all der Technik eines Multimediagerätes bildet. Seit Ende 2008 wird die Abkürzung App immer häufiger mit mobiler App gleichgesetzt, dabei handelt es sich einfach ausgedrückt um Anwendungssoftware für mobile Endgeräte, wie etwa Smartphones oder Tablets. (Mayer, 2012)

In dieser Arbeit wird unter dem Begriff App und Applikation immer auf eine mobile App referenziert, welche sich auf einem Smartphone auch installieren lässt.

4.1.2. Mobile App Unter einer mobilen App versteht man einfach ausgedrückt, ein kleines Computerprogramm, welches mit einem mobilen Endgerät, wie einem Smartphones oder einem Tablet, heruntergeladen und ausgeführt werden kann. (Mayer, 2012)

4.2. Plattformunabhängigkeit

Plattformunabhängigkeit bedeutet, dass eine App oder ein Programm die Grundeigenschaft besitzt, Kompatibilität mit verschiedensten Soft- und/oder Hardware-Konstellationen zu bieten. Eine Anwendung lässt sich plattformübergreifend ausführen, wenn sie plattformunabhängig ist. So ein Beispiel ist etwa, wenn ein Programm auf verschiedenen Betriebssystemen, wie etwa Windows, Linux oder Mac OS, ohne Einbußen auf den Funktionsumfang ausgeführt werden kann. Unter dem Grad der Plattformunabhängigkeit, auch bekannt unter Quellcode-Portabilität, versteht man, wie einfach es ist, eine App oder ein Programm mit anderen Plattformen kompatibel zu machen. Geschieht dies ohne Aufwand, dann ist von hundertprozentiger Portabilität zu sprechen. (Stiftung Medien in der Bildung, 2016)

4. August 2016 Peter Sonnleitner, BSc 22/79

Plattformunabhängigkeit in Bezug auf die Distribution von digitalen Lerninhalten hat eine sehr hohe Priorität, um sie wirklich jedem Nutzer und jeder Nutzerin, unabhängig von verwendeter Software und Hardware, zugänglich machen zu können. Diese Bedingungen gelten auch für mobile Applikationen, so ist jede mobile Plattform wie iOS, Android und Windows Mobile in Bezug auf die mobile App-Entwicklung sehr unterschiedlich. Hier gibt es viele Unterscheidungen, zum Beispiel beim benutzten SDK (Software Development Kit), den plattformabhängig definierten Interface-Richtlinien und den verwendeten Programmiersprachen. Und genau das stellt für viele Firmen ein Problem dar, denn die meisten Unternehmen die Apps entwickeln, wollen diese für alle Plattformen verfügbar machen, da nur so eine akzeptable Marktabdeckung erreicht werden kann. Hier gibt es die großen Player, wie etwa Facebook und Google, für welche es kein Problem ist, eine native App für jede Plattform zu entwickeln, weil bei diesen Giganten genug Ressourcen und Knowhow vorhanden sind. (Mayer, 2012) Für ein kleines Unternehmen, welches nicht allzu große Erfahrungen mit der Softwareentwicklung für verschiedene Plattformen hat, und auch nicht die nötigen Ressourcen aufwenden kann, ist dies aber bei weitem nicht zu erreichen. Hier muss eine plattformunabhängige Lösung geschaffen werden, um das Ziel einer bestmöglichen Marktabdeckung erreichen zu können. Das Ziel eines solchen Unternehmens ist es also, eine Cross-Plattform-Applikation zu entwickeln, wo auf die verschiedenen Differenzen der am meisten verbreiteten Plattformen kein Bezug genommen werden muss, und somit viel Zeit und Ressourcen gespart werden können. (Allen, Graupera, & Lundrigan, 2010) Um diese Ziele erreichen zu können, existieren unterschiedliche Möglichkeiten. Dazu wird in den folgenden Unterkapiteln näher Bezug genommen.

4.3. Entwicklungsoptionen einer mobilen Applikation

Mobile Applikationen wurden in Vergangenheit zumeist als native Apps entwickelt, in den vergangenen Jahren gab es hier aber einen starken Umbruch. Immer häufiger geht die Entscheidung bei den Entwicklungsoptionen zu einer hybriden App. Absehbar ist, dass hybride Apps in Zukunft ihren Marktanteil weiter steigern können, vor allem weil es um ein vielfaches günstiger ist für alle Plattformen zugleich zu entwickeln, außerdem besitzen Firmen oft nicht das nötige Knowhow um für die verschiedenen Plattformen zu entwickeln. Die HTML5- und JavaScript-Rendering-Engines der mobilen Browser sind bereits sehr gut und werden immer besser, deshalb nimmt die Performance von hybriden Apps auch ständig zu, außerdem gibt es bereits viele technische Ansätze, welche von der problematischen „WebView“ erst gar nicht Gebrauch machen. (Michaels, ross & cole, ltd., 2013) Es gibt in der mobilen App-Entwicklung verschiedene Entwicklungsoptionen. In der folgenden Auflistung werden alle derzeitig sinnvollen Optionen angeführt und deren Vorteile und Nachteile erläutert.

Abbildung 10: Grundlegende Architektur verschiedener App-Typen

4. August 2016 Peter Sonnleitner, BSc 23/79

4.3.1. Native App Native Apps sind eigenständige Anwendungen, die zum Beispiel in Java oder Objective-C programmiert sind und komplett für ein bestimmtes Betriebssystem zugeschnitten werden und dann auch nur auf diesem installiert werden können. Das führt zu deutlich höheren Entwicklungskosten. Der Vorteil der nativen Programmierung ist, dass Gerätekomponenten wie etwa das GPS-Modul, die Kamera oder das Mikrofon für die mobile Anwendung direkt benutzt werden können, und die native Darstellung um ein vielfaches perfomanter ist als etwa eine „WebView“. Dieser Zugriff auf die Hardware wirkt sich auch positiv auf die Benutzerfreundlichkeit aus, da diese Apps flüssiger laufen. (Michaels, ross & cole, ltd., 2013) 4.3.2. Web App HTML5-Apps oder sogenannte Web-Apps laufen im Prinzip auf allen Systemen welche moderne Browser unterstützen. Diese Apps werden mit HTML5, JavaScript und CSS erstellt und werden als mobile Webseiten von einem Browser auf einem Endgerät aufgerufen. Solch eine Entwicklung eignet sich vor allem für statische Inhalte wie Texte, Videos oder Bilder, aber auch einfache Geschäftslogik kann damit leicht dargestellt werden. Der wesentliche Vorteil ist, dass diese Apps plattformunabhängig einsetzbar sind. (Michaels, ross & cole, ltd., 2013) Die Portabilität einer Web-App ist sehr hoch, nach einer Statistik des Informationsdienstes "Business Insider" unterstützt auf der Android-Plattform Googles Chrome-Browser knapp 100% der Web-App-Features, direkt gefolgt von Firefox mit 93%. Im iOS-Bereich unterstützt Apples Safari immerhin 90% der verschiedenen Features vollständig. 4.3.3. Hybrid App Bei hybriden Apps existieren verschiedenste Technologieansätze, dazu wird unter Punkt 4.5.1. näher Bezug genommen. Einer dieser Ansätze ist es zum Beispiel, HTML5-basierte Webseiten mit einem nativen Grundgerüst zu einer hybriden Anwendung zu transformieren. Diese Methode vereint die Vorteile der beiden anderen Technologien, nämlich, dass eine Web-App in HTML5 und JavaScript entwickelt werden kann und Frameworks, wie Apache Cordova, sorgen dann dafür, dass diese Web-App den Anschein einer echten nativen App erweckt. (Michaels, ross & cole, ltd., 2013) 4.3.4. Gegenüberstellung

Native App Web App Hybrid App Programmiersprachen Objective-C, Java, HTML, CSS, Verschiedene C++,C#, … JavaScript Ansätze vorhanden Entwicklungsaufwand x Apps 1 App 1 App für x-Plattformen Verbreitung App Store Internet App Store Empfohlen für Spiele, grafisch stark Datengetriebene Plattformunabhängig fordernde Apps, B2B Apps, … installierbare Anwendungen, viele Anwendungen Kunden, … Vorteile Sehr performant, Geringe Plattformunabhängige grafisch Entwicklungskosten, Apps mit anspruchsvolle maximale Plattform- überschaubaren Darstellung möglich, unterstützung, Ressourcen und

4. August 2016 Peter Sonnleitner, BSc 24/79

der native Kontext Wartungen sehr Geringe Entwicklungs- kann vollständig einfach möglich, und Wartungskosten benutzt werden sofortige Updates

Nachteile Keine Portabilität App kann nicht Nativer Kontext kann möglich, hohe installiert werden, nicht vollständig Entwicklungs- und Offlinefähigkeit nur genutzt werden, Wartungskosten bedingt möglich, teilweise schlechtere schlechte Performance Performance Tabelle 1: Gegenüberstellung verschiedener Entwicklungsoptionen

4.4. Mobile Betriebssysteme

In diesem Unterkapitel werden die derzeitig am meisten verbreitetsten mobilen Betriebssysteme kurz erläutert und die grundlegenden Unterschiede aufgezeigt. 4.4.1. Android Android ist derzeit das am meisten verbreitete mobile Betriebssystem. Das Open-Source- Betriebssystem basiert auf einen Linux-Kernel und wird von Google entwickelt. (Agrawal, 2016) 4.4.2. iOS iOS ist derzeit das am zweitmeisten verbreitete mobile Betriebssystem. Auch wenn es von der Verbreitung bei weitem nicht an Android herankommt, so ist es dennoch das am meisten profitabelste OS, aufgrund der harten Preispolitik von Apple. Es ist Closed-Source und wird von Apple entwickelt. (Agrawal, 2016) 4.4.3. Windows 10 Mobile Windows 10 Mobile, früher auch unter Windows Phone bekannt, ist ein mobiles Betriebssystem von Microsoft. (Agrawal, 2016) 4.4.4. Blackberry 10 Blackberry 10 wird von Blackberry entwickelt. Es ist ein geschlossenes Betriebssystem, welches nur auf Geräten von dem Hersteller läuft. (Agrawal, 2016) 4.4.5. Firefox OS Firefox OS wird, genauso wie auch der Firefox-Browser, von Mozilla entwickelt. Es ist wie Android ein Open-Source-Betriebssystem, welches auf einem Android-Linux-Kernel basiert. (Agrawal, 2016) 4.4.6. Sonstige Es gibt noch eine Reihe von anderen mobilen Betriebssystemen, diese sind aber derzeit so wenig verbreitet, dass es nicht von Relevanz ist, sich als App-Entwickler über diese Gedanken zu machen. Dazu zählen unter anderem Sailfish OS, Tizen oder Ubuntu Touch OS. (Agrawal, 2016) 4.4.7. Verbreitung Es existieren verschiedene Statistiken von unterschiedlichen Quellen, welche über die Verbreitung und Verteilung der oben beschriebenen Betriebssysteme berichten. Diese Statistiken unterscheiden sich teilweise untereinander, so gibt es Abweichungen welche im

4. August 2016 Peter Sonnleitner, BSc 25/79

Bereich von bis zu zwei Prozentpunkten liegen. Die Tendenz ist aber bei allen sehr ähnlich, weshalb man diesen Statistiken durchaus Vertrauen schenken kann. Bei der folgenden Statistik kann man diese Tendenz sehr gut erkennen, so ist Android die am meisten verbreitete Plattform und wird in Zukunft, aller Voraussicht nach, auch weiterhin wachsen, weshalb die anderen Plattformen immer weiter zurück gedrängt werden. Durch die Entwicklung für Android, iOS und Windows Phone, kann bereits eine Marktabdeckung von 99,4% erreicht werden.

Abbildung 11: Marktabdeckung der mobilen Betriebssysteme in 2016. (Quelle: statista.com) 4.4.8. Unterschiede Bei den eben genannten Betriebssystemen gibt es sehr starke Unterschiede. Hierzu zählen unter anderem verschiedene Programmiersprachen, andere native APIs, eigene Entwicklungsumgebungen und verschiedene Interfacerichtlinien. Des Weiteren läuft die Distribution über den App Store anders und jedes Betriebssystem hat unterschiedliche Fähigkeiten, Stärken und Schwächen.

4.5. Hybride Entwicklungsoptionen

Jedes Jahr springen weitere Firmen auf den Zug der mobilen App-Entwicklung auf, um ihren Kunden einen einfacheren und schnelleren Service und weitere Produkte bereitstellen zu können. Kleine Unternehmen haben aber das Problem, dass es sehr hohe Kosten verursacht und viele Ressourcen benötigt werden, damit native Apps für alle Systeme entwickelt werden können. Jede weitere Funktion und jedes weitere Update müsste folglich für jede Plattform ausgerollt werden, was ein nicht zu bewältigender Aufwand für kleine Teams ist. Dies ist unter anderem ein Grund, weshalb hybride Entwicklungsoptionen immer gefragter werden. Bei diesen Ansätzen werden etwa Technologien wie HTML, CSS und JavaScript in native Apps eingebettet oder das Ganze mit neuartigen Technologieansätzen gelöst. (Hornor T. , 2016)

Hybride-Apps haben sehr viele Vorteile, es sind zum Beispiel keine besonderen Fähigkeiten oder Kenntnisse für verschiedene Plattformen notwendig. Eine App muss nur einmal entwickelt werden und es existiert folglich nur ein Quellcode, welcher mit der Hilfe von Technologieansätzen auf allen Plattformen ausgeführt werden kann. Support- und Dokumentationskosten können folglich eingespart werden, die App hat ein konsistentes,

4. August 2016 Peter Sonnleitner, BSc 26/79

plattformübergreifendes Design und es gibt keine Funktions- beziehungsweise Qualitätsunterscheidungen zwischen verschiedenen Plattformen. Besonders beim Outsourcen der Entwicklung für eine bestimmte Plattform kam es immer wieder zu starken Abweichungen zu der original Applikation, etwa wenn eine Android-App für iOS nachgebaut wurde. (Hornor T. , 2016) Dazu werden im folgenden Unterpunkt die derzeitig verfügbaren Technologieansätze vorstellt.

4.5.1. Hybride Technologieansätze In einer 2012 erschienen Analyse von VisionMobile wurden verschiedenste hybride Technologieansätze näher untersucht, gegenübergestellt und in unterschiedliche Kategorien aufgeteilt. Dadurch wurden folgende fünf Ansätze abgeleitet, in welche sich jede hybride App einteilen lässt. Auch wenn diese Aufgliederung bereits vier Jahre alt ist, und sich bei den Technologien einiges getan hat, so gibt es bei den derzeitig meist verbreitetsten Frameworks keines, welche sich nicht in diese Kategorien eingliedern lässt. Jede Technologie adressiert eine andere Zielgruppe, dies geht von „nicht Entwicklern“ bis hin zu „spezialisierten Entwicklern“, und auch ein anderes Anwendungsgebiet. Die Technologieansätze schließen sich prinzipiell nicht vollkommen gegenseitig aus, es gibt also durchaus Technologien und Tools, welche eine Kombination dieser Ansätze nutzen. (VisionMobile Ltd., 2012)

Es wurden folgende fünf verschiedene Technologieansätze abgeleitet:

 JavaScript-Frameworks  App-Generatoren  Native-WebView-Wrappers  Runtimes  Quellcodeübersetzer

4.5.1.1. JavaScript-Frameworks JavaScript-Frameworks sind ganz einfach formuliert Code-Bibliotheken, welche komplexe Entwicklungsschritte, wie das Behandeln von Touchscreen-Interaktionen oder plattformübergreifende Browser-Interfaces bieten. Angesprochen werden hauptsächlich Webentwickler und Webentwicklerinnen, welche bereits Erfahrung mit entsprechenden Technologien haben und plattformübergreifende Anwendungen entwickeln wollen, mit nativem Verhalten und Aussehen. (VisionMobile Ltd., 2012)

4.5.1.2. App-Generatoren App-Generatoren sind im Grunde einfache Designtools, welche es ohne Programmierkenntnisse erlauben, mobile Applikationen zu erstellen. Diese bestehen meist aus einer Visuellen- Entwicklungsumgebung, die entweder installiert wird oder in einer Cloud läuft, und vorlagenbasierte Komponenten beinhaltet, welche in die App hineingezogen werden können um den entsprechenden App-Code zu generieren. Im einfachsten Szenario sind das etwa Tools, welche es mit einfachen Schritten ermöglichen, etwa einen RSS-basierten News-Reader zu entwickeln. Im komplexesten Szenario können mit solchen Tools komplexe Prozesse einer Geschäftslogik umgesetzt werden, welche eine Integration in eine Cloud voraussetzen. Diese App-Generatoren erlauben es Personen, Apps zu erstellen, welche nicht über entsprechende Programmierkenntnisse verfügen. Es gibt aber auch Tools, die nur den Basiscode generieren, welcher dann von Entwicklern individuell angepasst werden kann. (VisionMobile Ltd., 2012)

4. August 2016 Peter Sonnleitner, BSc 27/79

4.5.1.3. Native-WebView-Wrappers Native-WebView-Wrappers, auch bekannt unter Web-to-native-wrappers, sind Lösungen, welche eine App, basierend auf HTML5, CSS und JavaScript, mit einem Nativen-Container umschließen, und somit eine nativ wirkende Applikation entsteht. Der Code wird mit Bibliotheken, welche APIs für den Zugriff auf native Funktionen ermöglichen, in eine native Applikation verpackt. Diese Apps werden mit Webtechnologien geschrieben und laufen innerhalb einer WebView, welche von der Plattform zur Verfügung gestellt wird. Im Hintergrund gibt es dazu zusätzliche Erweiterungen, welche es ermöglichen, mit Hilfe von JavaScript-APIs auf native Funktionen zuzugreifen, welche standardmäßig vom Browser nicht unterstützt werden, hierzu zählen etwa die Kamera oder der Kompass. (VisionMobile Ltd., 2012)

4.5.1.4. Runtimes Unter sogenannten Runtimes versteht man im Grunde eine Lautzeitumgebung, welche einen plattformübergreifenden Kompatibilitätslayer bietet, welcher direkt auf dem nativen System sitzt und speziell für dieses entwickelt wurde. Dieser schirmt eine App von den Unterschiedlichkeiten der verschiedenen Betriebssysteme durch bereitgestellte Schnittstellen ab, dadurch kann die gleiche App auf verschiedenen Plattformen ausgeführt werden, ohne von der performancekritischen WebView Gebrauch machen zu müssen. Solche Runtimes unterscheiden sich häufig in ihrer Komplexität und verwenden unterschiedliche Methoden wie Virtualisierung oder Interpretation. Für jede Plattform die unterstützt wird, muss diese Kompatibilitätsschicht mit den notwendigen Schnittstellen implementiert werden. Es gibt integrierte und selbstständig lauffähige Runtimes, wobei integrierte Runtimes bereits mit der kompilierten App ausgeliefert werden, dieser Ansatz wird etwa von Native Script oder React Native verwendet. Im Gegensatz dazu müssen selbstständig lauffähige Runtimes zusätzlich installiert werden, ein bekanntes Beispiel dafür ist Adobe AIR. (VisionMobile Ltd., 2012)

4.5.1.5. Quellcodeübersetzer Quellcodeübersetzer, auch bekannt unter Sourcecode-Translators, übersetzen den Quellcode in einen anderen Typ. Dieser übersetzte Quellcode kann verschiedene Formen aufweisen, es kann sich etwa um Bytecode, nativen Sprachcode oder Maschinencode handeln. Quellcodeübersetzer werden typischerweise in Kombination mit Runtimes verwendet und sind vor allem für Entwickler und Entwicklerinnen relevant, welche plattformunabhängige Applikationen mit einer komplexen Anforderungslogik und schwierigen Performanceanforderungen umsetzen wollen. (VisionMobile Ltd., 2012)

4.5.1.6. Entscheidungskriterium Bei der Auswahl einer Entwicklungsoption ist das erste Kriterium meistens, welche Plattformen bei dem Projekt unterstützt werden müssen. Sind mehr als eine Plattform für ein Projekt vorgesehen, geht die Wahl meistens zu einem hybriden Ansatz. Oftmals müssen Android und iOS unterstützt werden, aber auch Windows Mobile steht immer häufiger auf der Liste. Daher liegen die Hauptentscheidungspunkte meistens bei den verfügbaren Ressourcen und bei den Technologien, mit welchen die Entwickler oder Entwicklerinnen vertraut sind, da die Zeitressourcen, welche für das Lernen einer neuen Technologie aufgewendet werden müssten, so hoch sind, dass sich das für einzelne Projekte nur selten rentieren würde. Und natürlich fließen auch die Anforderungen von Endanwendern und Endanwenderinnen in die Entscheidungskriterien mit ein.

4. August 2016 Peter Sonnleitner, BSc 28/79

Die Verwendung einer unpassenden Technologie kann auf den ersten Blick durchaus den Eindruck vermitteln, dass damit massiv Kosten gespart werden können. Wenn aber die Applikation von den Endkunden nicht angenommen wird, weil sie die entsprechende Usererwartung, etwa durch schlechte Performance der WebView bei grafisch anfordernden Darstellungen, nicht erfüllen kann, dann sind all die Kosten, welche aufgewendet wurden, eigentlich verlorene Kosten. (VisionMobile Ltd., 2012)

4.5.2. Hybride Frameworks Im folgenden Unterpunkt werden die Grundlagen zu einigen hybriden Frameworks kurz erläutert, auf diese wird im Kapitel 5 bei den Auswahlkriterien für die Umsetzung der mobilen Lernanwendung mit einem bestimmten Framework Bezug genommen. Diese Liste ist bei weitem nicht vollständig, beinhaltet aber die derzeit bekanntesten Tools. Die Auswahl der hybriden Frameworks wurde auf Basis von den unter Punkt 5.2. beschriebenen Quellen getroffen. Allgemein wurden folgende Anforderungen an das Framework gestellt, damit es in die nähere Auswahl aufgenommen wurde:

 Es muss sich um ein hybrides mobiles Framework handeln, oder zumindest einen ähnlichen Ansatz verfolgen. Aus dem folgt auch, dass es möglich sein muss, damit eine App zu entwickeln, welche sich auf einem Android- und iOS-Gerät installieren lässt.  Die Umsetzbarkeit der „Examize-App“ muss erfüllbar sein. Hierbei ist zu erwähnen, dass in diesem Schritt nur eine oberflächliche Betrachtung des Frameworks vorgenommen wurde, daraus folgt, dass nicht gewährleistet werden kann, dass wirklich alle Anforderungen in vollem Umfang erfüllbar sind.

4.5.2.1. Appcelerator Titanium Appcelerator Titanium ist ein Open-Source-Framework zum Entwickeln von mobilen Applikationen auf Basis von HTML5, CSS und JavaScript. Es stellt eine vollkommene Umgebung zur Verfügung, welche es ohne Hilfe von zusätzlichen Tools erlaubt, native Apps für unterschiedliche Plattformen zu entwickeln. Es existieren hunderte von Modulen mit denen eine Anwendung sehr leicht erweitert werden kann. (Appcelerator Inc., 2016)

4.5.2.2. Intel XDK Mit Intel XDK können Apps mit einfacher HTML5-, CSS- und JavaScript-Entwicklung und entsprechender Cordova-Integration schnell für betriebssystemübergreifende App-Stores verfügbar gemacht werden. Der Workflow reicht vom Design-Entwurf bis hin zur Distribution für einen App-Store, dabei sind auch eine Reihe von Design-, Debug- und Build-Tools bereits integriert und es wird Kompatibilität mit vielen UI-Frameworks, wie etwa Bootstrap oder jQuery Mobile, geboten. (Intel Inc., 2016)

4.5.2.3. Ionic Ionic ist ein Open-Source-Framework, welches eine Bibliothek aus HTML-, CSS- und JavaScript-Komponenten zur Verfügung stellt. Es basiert auf AngularJS und stützt sich auf Cordova. Ionic ist eines der vielversprechendsten mobilen HTML5 Frameworks. Außerdem verfolgt es mit AngularJS den MVVM Ansatz der einige Vorteile bietet. Um der Konkurrenz nachzulegen oder eigene neuartige Features vorzustellen, wird das Framework regelmäßig mit Updates versorgt. (Hornor T. , 2016)

4. August 2016 Peter Sonnleitner, BSc 29/79

4.5.2.4. Mobile Angular UI Mobile Angular UI ist ein Open-Source-Framework, welches Bootstrap3 und AngularJS verwendet um interaktive mobile Applikationen zu bauen. Es ist ähnlich wie jQuery Mobile oder Sencha Touch aufgebaut und verwendet einen Web-to-native-wrapper um die Webapplikation in eine native App zu verpacken. (Arora, 2016)

4.5.2.5. Native Script Native Script ist ein quelloffenes JavaScript-Framework, welches den Runtime- Technologieansatz verwendet. Eines der wichtigsten Features von Native Script ist es, dass man die Applikationslogik nur einmal in JavaScript zu schreiben braucht, diese wird dann so transformiert, dass sie nativ auf einem Android, iOS oder Windows Phone Gerät ausgeführt werden kann. Die kompilierte Applikation startet in einer nativen Applikation ohne von einer WebView oder einem Browser Gebrauch zu machen und bietet daher sehr gute Performance. (Arora, 2016)

4.5.2.6. PhoneGap PhoneGap ist en Framework, welches auf Apache Cordova basiert und es ermöglicht, plattformübergreifende Applikationen für mobile Geräte auf Basis von JavaScript, HTML5 und CSS zu schreiben. Die entwickelten Apps sind hybride Anwendungen, welche in einer WebView dargestellt werden und somit auf einem modernen Smartphone ausgeführt werden können. Ursprünglich war Apache Cordova auch unter PhoneGap bekannt, es gab aber bei dieser Namensgebung rechtliche Probleme, weshalb dieses Projekt umbenannt wurde. (Adobe Systems Inc., 2016)

4.5.2.7. React Native Wie der Name bereits verrät, ist eine der Absichten von React Native, eine Umgebung für die Entwicklung von echten nativen Apps bereitzustellen, welche ganz ohne Browser und WebView auf einem Gerät ausgeführt werden können. Die Entwicklung der Applikation basiert komplett auf JavaScript und kann mit Hilfe von der React Native Libary trotzdem mit nativem UI dargestellt werden. Diese Libary ist relativ neu und nicht für Programmieranfänger geeignet, besitzt aber bereits eine große Community, wodurch viele Problemstellungen durch viele zusätzliche Plugins leicht gelöst werden können. (Bray & Holmes, 2015)

4.5.2.8. Sencha Touch Bei Sencha Touch handelt es sich um ein führendes Open-Source-Framework, welches die Entwicklung von mobilen Apps mit HTML, CSS und JavaScript für verschiedene Plattformen wie Android, Blackberry oder iOS erlaubt. Wie auch die meisten anderen Web-Frameworks, verwendet Sencha Touch Apache Cordova um die Webapplikation in einen nativen Container zu verpacken. (Arora, 2016)

4.5.2.9. Zusammenfassung Jedes Framework hat seine eigenen Vor- und Nachteile und ist für verschiedene Einsatzgebiete konzipiert. Die Entscheidung für ein Framework muss individuell abhängig vom zu implementierenden Projekt, dem verfügbaren Budget und der Erfahrung des Entwicklerteams getroffen werden. Es empfiehlt sich, viel Zeit in den Auswahlprozess der richtigen Umgebung zu stecken, weil damit die laufenden Projektkosten stark gesenkt werden können.

4. August 2016 Peter Sonnleitner, BSc 30/79

5. Ausgewählte hybride Frameworks

Wie unter dem Punkt 4.5.2. angeführt, sind in den letzten Jahren sehr viele mobile hybride Frameworks, mit verschiedenen Vor- und Nachteilen, entstanden und es werden jedes Jahr neue vorgestellt. Alle detailliert gegenüberzustellen und für diese Projektumsetzung in Betracht zu ziehen ist aufwandstechnisch nicht zurechenbar, aus diesem Grund wurden die folgenden Auswahlkriterien ausgearbeitet und definiert. Nach der Bewertung der einzelnen Frameworks zu jedem einzelnen Kriterium mit einer gewissen Punkteanzahl, ergab sich eine Quersumme (QS). Die zwei Frameworks mit der größten Punkteanzahl werden dann im Folge-Kapitel genauer untersucht und gegenübergestellt, und letztendlich die Examize-App damit implementiert und die Erkenntnisse daraus dokumentiert. Aus der resultierenden Quersumme lässt sich ein guter Richtwert ermitteln, mit welchem Framework sich das definierte Entwicklungsszenario gut umsetzen lässt. Das bedeutet nicht zwingend, dass es sich dabei um das „beste“ Framework handelt, viel mehr sagt es einfach aus, dass sichergestellt werden kann, dass die Implementierungsentscheidung mit einem Framework getroffen wird, welches sich im Nachhinein nicht als Fehler darstellt und auch Zukunftspotential besitzt. Die unter Punkt 4.5.2. getroffenen Auswahlkriterien für die hybriden Frameworks wurden hier nicht mehr beachtet, weil diese ohnehin von jedem Framework in der Auflistung erfüllbar sein müssen. Dies bedeutet im konkreten, jedes Framework in der Auflistung bietet den entsprechenden Funktionsumfang, welcher notwendig ist, um die mobile Lernapplikation in vollem Umfang für Android und iOS entwickeln zu können.

5.1. Auswahlkriterien

 Kriterium 1: Wie nativ ist das Verhalten und Aussehen einer implementieren App? (0-10)  Kriterium 2: Wie groß ist die Community die das Framework unterstützt? (0-10)  Kriterium 3: Wie gut ist die offizielle Dokumentation? (0-10)  Kriterium 4: Gibt es einen namhaften Unterstützer für das Projekt? (0,5)  Kriterium 5: Wie innovativ ist das Framework? (0-10)  Kriterium 6: Gibt es namhafte Firmen, die das Framework verwenden? (0,5)  Kriterium 7: Wie stark wird das Zukunftspotential eigenschätzt? (0-20)  Kriterium 8: Wie hoch ist die aktuelle Relevanz in „Google Trends“? (0-10)

Die Auswahlkriterien wurden bewusst sehr oberflächlich gewählt, weil eine objektive Bewertung komplexerer Kriterien und ein Gegenvergleich von Kernfeatures ohne Erfahrung mit dem jeweiligen Framework nur sehr schwer durchzuführen ist.

5.2. Bewertung der Auswahlkriterien

Für jedes der in Punkt 4.5.2. beschriebenen Frameworks wurden die einzelnen Auswahlkriterien innerhalb der definierten Punkteanzahl bewertet und eine Quersumme gebildet. Um die Bewertung der einzelnen Kriterien möglichst objektiv und repräsentativ durchführen zu können, wurde für jeden Punkt ein geschätzter Mittelwert von den Aussagen aus den folgenden Gegenüberstellungen ermittelt:

 http://t3n.de/news/hybride-app-entwicklung-frameworks-617199/  http://mobile-frameworks-comparison-chart.com/  http://tutorialzine.com/2015/10/comparing-the-top-frameworks-for-building-hybrid-mobile-apps/  http://noeticforce.com/best-hybrid-mobile-app-ui-frameworks-html5-js-css

4. August 2016 Peter Sonnleitner, BSc 31/79

 http://www.rswebsols.com/tutorials/software-tutorials/10-best-frameworks-creating-hybrid-mobile- apps  https://adtmag.com/blogs/dev-watch/2016/01/mobile-dev-trends.aspx  http://www.theiphoneappreview.com/2016/01/top-hybrid-mobile-app-development-frameworks-for- 2016/  http://www.htmlgoodies.com/html5/mobile/comparing-mobile-development-framework- types.html#fbid=XGkeXN618vo  https://software.intel.com/en-us/html5/hub/blogs/comparing-html5-mobile-ui-frameworks  http://www.gajotres.net/top-7-mobile-application-html5-frameworks/

Zusätzlich wurden die Frameworks auch in Google Trends gegenübergestellt. In der folgenden Grafik zeigt sich die „Interest over time“-Entwicklung von Google:

Abbildung 12: Gegenüberstellung der Frameworks in Google Trends (Top 5)

Aus den oben genannten Quellen ergaben sich folgende Bewertungen der Auswahlkriterien:

Framework K.1 K.2 K.3 K.4 K.5 K.6 K.7 K.8 Quersumme Appcelerator Titanium 8 9 7 5 6 5 15 2 57 Intel XDK 6 4 6 5 5 5 8 1 40 Ionic 8 10 9 5 7 5 18 7 69 Mobile Angular UI 4 4 6 5 4 5 10 1 39 Native Script 9 4 7 5 9 5 17 2 58 Onsen UI 6 3 8 5 5 5 6 1 39 PhoneGap 5 9 7 5 4 5 6 1 42 React Native 10 8 6 5 9 5 20 10 73 Sencha Touch 6 7 8 5 5 5 8 2 46 Tabelle 2: Bewertung der Auswahlkriterien von den verschiedenen Frameworks

Zieht man die ermittelte Quersumme in Betracht, dann sind Appcelerator Titanium, Ionic, Native Script und React Native derzeit die interessantesten Frameworks für die mobile App- Entwicklung. Die mobile Lernanwendung wird in weiterer Folge mit jenen zwei Frameworks entwickelt, welche in diesem Vergleich am besten abgeschnitten haben, nämlich Ionic und React Native. Dazu werden diese in den nachfolgenden Unterpunkten genauer beschrieben.

4. August 2016 Peter Sonnleitner, BSc 32/79

5.3. Ionic

Ionic ist ein sehr weit verbreitetes Open-Source-Framework für die mobile App-Entwicklung (Weiße, 2016). Dabei handelt es sich um ein Bündel von HTML5 und CSS3 UI-Elementen, welche es ermöglichen, eine Applikation mit dem Auftreten einer nativen mobilen Applikation zu gestalten. Das Framework setzt auf AngularJS, und darauf sind auch einige Kernkomponenten vom Framework aufgebaut. Auf der offiziellen Dokumentation wird darauf hingewiesen, dass AngularJS nicht verpflichtend eingesetzt werden muss, dies aber empfohlen wird, weil mit AngularJS sehr leicht browserbasierte Webseiten erstellt werden können und das gesamte Framework für AngularJS optimiert ist. Damit in Zusammenhang stehend ergibt sich auch einer der wichtigsten Vorteile, nämlich dass die UI-Komponenten nichts anderes als AngularJS- Direktiven sind. (Ionicframework, 2016)

Hybride Apps, welche mit dem Ionic Framework umgesetzt werden, sind nichts anderes als kleine Webseiten, welche in einer Browser-Shell innerhalb einer WebView am Gerät laufen. Da es sich um ein HTML5 Framework handelt, braucht es eine native Verpackung, einen sogenannten „Wrapper“, um als native App ausgeführt werden zu können, wie etwa Cordova oder PhoneGap. Dadurch kann auch auf native Funktionen zugegriffen werden, welche sonst direkt im Browser nicht verfügbar wären. Ionic basiert auf Apache Cordova, kann aber auch ohne dieser Abhängigkeit benutzt werden. Auf der offiziellen Dokumentationsseite wird aber mehrmals erwähnt wie viele Vorteile es bringt Cordova zu verwenden, weil dieses Framework auch in den Ionic-Tools verwurzelt ist. (Ionicframework, 2016)

Ionic ist im Grunde ein Front-End-UI-Framework, welches sich um das native Aussehen und Verhalten und die UI-Interaktion kümmert (Weiße, 2016). Die Oberfläche bietet ein schönes, natives Design, die Animationen laufen flüssig und viele native Funktionen werden standardmäßig unterstützt.

Anders wie viele alternative Frameworks setzt Ionic sehr stark auf native gestylte UI- und Layout-Elemente, was auch den Anschein erweckt, als würde es sich bei Ionic-Anwendungen um native Apps handeln, dies ist mitunter ein Grund, wieso sich das Ionic Framework immer größerer Beliebtheit erfreut. (Weiße, 2016)

Für Entwickler und Entwicklerinnen, welche bereits mit der Webentwicklung Erfahrung haben, ist die Struktur einer Ionic-Basisapplikation sehr leicht zu verstehen. Im Grunde ist so eine App, wie bereits erwähnt, eine einfache Webseite, welche im Browser läuft. Somit kann auch jede Form von HTML, CSS und JavaScript verwendet werden.

5.3.1. Grundlegende Architektur Die Architektur einer Ionic-Applikation ist im Grunde sehr einfach aufgebaut. Die eigentliche Web-App, welche mit dem Framework per HTML5, JavaScript und CSS umgesetzt wird und meistens auf AngularJS basiert, befindet sich in einem eigenen Basisordner, oft auch als Root- Ordner mit „www“ bezeichnet. Dieser wird von den typischen HTML- und JavaScript-Interpretern verarbeitet und entsprechend in einer nativen WebView gerendert. Dabei handelt es sich einfach gesagt um einen Browser, welcher auf der Plattform, zum Beispiel einem Android-Gerät, dargestellt wird. Darüber hinaus gibt es die Möglichkeit, mit Hilfe von Schnittstellen mit Cordova oder installierten Cordova-Plugins zu kommunizieren und dort eine gewünschte native

4. August 2016 Peter Sonnleitner, BSc 33/79

Komponente anzusprechen. Apache Cordova kommuniziert in weiterer Folge durch die zur Verfügung gestellten nativen APIs direkt mit der Plattform, wie etwa Android oder iOS.

Abbildung 13: Grundlegende Architektur vom Ionic Framework

5.3.2. AngularJS AngularJS, oder einfach Angular, ist ein strukturiertes Framework für clientseitige dynamische Single-Page-Applikationen. HTML kann als Template-Sprache verwendet werden und große Applikationen mit klar definierten und strukturierten Komponenten können einfach entwickelt und dynamisch dargestellt werden (Steyer & Softic, 2015). In den folgenden Unterpunkten werden einige Kernaspekte von diesem Framework kurz beschrieben.

5.3.2.1. Entwurfsmuster Angular verwendet das MVVM-Entwurfsmuster (Model-View-ViewModel), in der Literatur ist aber auch vom MVW-Entwurfsmuster (Model-View-Whatever) die Rede. Das klassische Model-View- Controller-Muster (MVC) besteht, wie der Name schon sagt, aus Model, View und Controller. Wenn man nun den Controller durch etwas anderes, also „Whatever“, ersetzt, entsteht der Model-View-Whatever-Ansatz. Angular verwendet statt dem Controller ein „ViewModel“, wodurch das MVVM-Entwurfsmuster entsteht. Dieses Paradigma dient vereinfacht zur Darstellung und Trennung von der Applikationslogik und dem Userinterface. (Steyer & Softic, 2015)

5.3.2.2. Applikationslogik Beim Angular-Framework wird die Applikationslogik innerhalb eines Controllers definiert, zusätzlich wird darin ein zugehöriges Model referenziert. Alle definierten Controller werden an Module gebunden, diese Module können innerhalb der Applikation gemeinsam mit Services durch Dependency-Injection an verschiedenen Stellen wiederverwendet werden. Die View wird dabei mit einem Model verbunden, wobei die Datenbindung immer bidirektional abgebildet wird, das bedeutet, Eingaben vom Benutzer werden auf das Model weitergereicht, und dynamische Änderungen innerhalb vom Model führen zu einer Änderung der View. (Steyer & Softic, 2015)

Die Geschäftslogik wird innerhalb von Angular-Anwendungen meistens in Services abgebildet, welche in AngularJS mit dem Singleton-Entwurfsmuster instanziiert werden. AngularJS stellt selbst bereits einige Services bereit, wie etwa den „$http“-Service. Services können aber auch selbst implementiert werden. (Steyer & Softic, 2015)

4. August 2016 Peter Sonnleitner, BSc 34/79

Die Funktionen und Daten eines Controllers werden an ein sogenanntes Scope-Objekt gekapselt, welches jeder Controller besitzt. Diese Objekte referenzieren das Applikationsmodell und sind hierarchisch angeordnet, vereinfacht kann gesagt werden, sie ahmen die DOM-Struktur nach. Variablen für das Rendering von Templates können damit bereitgestellt werden. In einem Template-Tag können nur Variablen verwendet werden, welche einem Scope-Objekt hinzugefügt wurden. Jedes Element in einer Angular-Anwendung braucht einen Scope, wenn es in einer View dynamisch ausgegeben werden soll. (Steyer & Softic, 2015)

5.3.2.3. Benutzerdefiniertes HTML Angular verwendet zum Darstellen sogenannte Direktiven, dabei handelt es sich um benutzerdefinierte eigene HTML-Elemente, welche in eine definierte HTML-Struktur konvertiert werden. Diese können in Angular sehr einfach erstellt werden, es gibt aber auch eine Reihe von vorgefertigten Direktiven, welche an einem speziellen Namensraum erkennbar sind. (Steyer & Softic, 2015)

Hello, {{item}}!

Code-Ausschnitt 1: Beispielhafte Verwendung von einer AngularJS-Listen-Direktive

5.3.2.4. Ausgabe von Variablen Mit doppelt geschwungenen Klammern können einfache JavaScript-Variablen innerhalb von statischem HTML-Code verwendet werden.

{{title}}

Code-Ausschnitt 2: Interpolation in AngularJS

Beide Ausdrücke vom Code-Ausschnitt 2 führen dazu, dass der Wert von der Variable „title“ ausgegeben wird. Der Vorteil von dem „ng-bind“-Ausdruck ist, dass dadurch verhindert wird, dass im Browser, wenn ein Fehler auftritt oder Angular die Applikation nicht schnell genug startet, das „{{title}}“-Template angezeigt wird.

5.3.3. Apache Cordova Ionic verwendet Apache Cordova, dabei handelt es sich um eine Sammlung von Geräte-APIs, welche den App-Entwicklern erlauben, von JavaScript aus auf native Funktionen vom Gerät zuzugreifen. Dazu zählen unter anderem die Kamera oder der Beschleunigungssensor, somit kann eine App mit einfachen Webtechnologien plattformübergreifend programmiert werden. Durch die Verwendung einer der zahlreichen Plugins, lässt sich im Grunde jede native Gerätekomponente verwenden. (Hornor T. , 2016)

5.3.4. Unterstütze Plattformen Ionic wird derzeit für Android ab der Version 4.1 (API 16) und für iOS ab der Version 7.0 unterstützt. Der Support für Windows Phone und Firefox OS befindet sich bereits im Meilensteinplan von Ionic. (Ionicframework, 2016)

4. August 2016 Peter Sonnleitner, BSc 35/79

5.4. React Native

Die meisten mobilen Frameworks, die in den letzten Jahren vorgestellt wurden, basieren auf HTML, CSS und JavaScript und werden dann mit einem sogenannten Web-to-Native-Wrapper, wie etwa Cordova oder Titanium, zu einer nativ wirkenden App gemacht. Mit Cordova können, mit Hilfe von APIs, zwar native Komponenten angesprochen werden, doch die App läuft trotzdem als Web-Applikation in der problematischen WebView. React verfolgt hier einen etwas anderen Ansatz. Die Applikationslogik wird in JavaScript geschrieben, aber das Applikations-UI ist völlig nativ und unabhängig davon. Es werden native Komponenten für die Darstellung verwendet, was dazu führt, dass Apps mit großartigem UI und vollkommenen nativen Auftreten und Verhalten gebaut werden können. Es gibt also nicht die typischen Schwachstellen, welche bei der Weboberfläche mit HTML5 auftreten, wie etwa die langsame Performance oder das nicht durchgängig native Design. (Bray & Holmes, 2015)

"React Native enables you to build world-class application experiences on native platforms using a consistent developer experience based on JavaScript and React. The focus of React Native is on developer efficiency across all the platforms you care about — learn once, write anywhere. Facebook uses React Native in multiple production apps and will continue investing in React Native.", (Facebook Inc., 2016). Mit diesen Worten beschreibt der Entwickler von dem Framework, nämlich Facebook, React Native.

Der Ansatz hinter React Native ist ein ähnlicher wie auch bei React. Einzelne native Bestandteile einer Applikation reagieren auf Veränderungen und werden, wie auch bei ReactJS, als JavaScript-Komponenten entwickelt. Die Idee hinter React Native ist jene, eine Applikation einmal zu entwickeln und auf allen Plattformen nativ ausführen zu können. Wenn man bereits Erfahrung mit ReactJS hat, wird man sich mit dem React Native Framework sehr schnell zurechtfinden und der Einarbeitungsaufwand kann gering gehalten werden.

Der Quellcode welcher auf Basis von React Native für verschiedene Plattformen produziert wird ist für einfache Applikationen exakt der gleiche, auch das Ansprechen von Schnittstellen funktioniert gleich, erst bei komplexeren Komponenten gibt es wirkliche Unterscheidungen. Selbiges gilt für das UI, dieses kann prinzipiell auch plattformübergreifend aufgebaut sein, aus konzeptioneller Sicht wird dies aber nicht empfohlen (Facebook Inc., 2016), da Nutzer an die speziellen Charakterzüge einer Plattform wie iOS oder Android gewöhnt sind und es durchaus sinnvoll ist ein eigenes Interface für jede Plattform zu realisieren. Aus diesem Grund heißt das Motto von React Native auch „Learn once, write anywhere“, damit wird der „Write once, run anywhere“-Ansatz, mit welchem sich viele anderen hybriden Frameworks auszeichnen, in Frage gestellt, und Facebook hebt mit React Native die hybride App-Entwicklung auf eine neue Ebene. (Bray & Holmes, 2015)

React Native Apps verhalten sich nativ, werden aber nicht mit nativen Programmiersprachen wie etwa Java oder Objective-C geschrieben, sondern mit JavaScript programmiert. Die Komponenten die dabei definiert werden, werden als sogenannte Native-Plattform-Widgets gerendert, dabei handelt es sich Beispielsweise um Interface-Komponenten wie ein Text-Feld, einen Button oder einen Listen-Eintrag. (Bray & Holmes, 2015)

Eines der besten Features von React Native ist es, dass das Erscheinungsbild der App einfach ein Abbild vom Zustand, dem sogenannten „state“ ist. Dies bedeutet für Entwickler und

4. August 2016 Peter Sonnleitner, BSc 36/79

Entwicklerinnen im konkreten, dass man sich nicht ständig um Veränderungen an der View kümmern muss, sondern dass man die View anhand von Input-Daten definiert und React Native die Veränderung der Darstellung dann intelligent regelt sobald sich der Zustand ändert. (Bray & Holmes, 2015)

Was für viele native Entwickler und Entwicklerinnen problematisch wirkt ist, dass die Applikation mit JavaScript entwickelt wird. Grundlegend kann diese Skriptsprache nicht so schnell ausgeführt werden wie nativer Code, aber React Native löst dieses Problem sehr souverän. Der JavaScript-Code wird in einem eigenen Thread ausgeführt, unabhängig von dem Main-UI- Thread, die Kommunikation zwischen diesen beiden Threads passiert asynchron. Das bedeutet im konkreten, dass selbst dann, wenn im JavaScript komplexe Logik verarbeitet wird, das UI trotzdem flüssige Animationen vorweisen wird. (Bray & Holmes, 2015)

5.4.1. Grundlegende Architektur Die grundlegende Architektur von React Native kann relativ simpel beschrieben werden. Die fertig entwickelte Applikation beinhaltet native Klassen, die React Native Libary und den eigentlichen Quellcode. Die JS- und JSX-Klassen werden von der React Native Libary interpretiert und kommunizieren per asynchronen API-Zugriff mit den nativen Klassen. Diese sind direkt mit der entsprechenden Plattform verbunden und werden dort gerendert.

Abbildung 14: Grundlegende Architektur vom React Native Framework

5.4.2. Komponenten React legt den Fokus auf die View einer Applikation. Wenn eine React Native App geschrieben wird, ist es vom Grundansatz der gleiche, als würde man React-Komponenten erstellen. Das sind kleine Codeteile, welche einen kleinen Teil der App genauer beschreiben. Anhand des folgenden Beispiels lässt sich das Grundprinzip gut erklären: const MenuButton = React.createClass({ propTypes: { title: React.PropTypes.string.isRequired, onPress: React.PropTypes.func.isRequired, }, render() { return (

4. August 2016 Peter Sonnleitner, BSc 37/79

{this.props.title} ); } });

Code-Ausschnitt 3: „MenuButton“-Komponente in React Native

Die „MenuButton“-Komponente hat zwei Data-Inputs, zum einen das „onPress“-Input, was nichts anderes als eine Callback-Funktion ist, welche ausgeführt wird, sobald der Button gedrückt wird. Zum anderen das „title“-Input, was einfach als Text innerhalb des Buttons angezeigt wird. Diese XML ähnliche Struktur wird von der „render“-Methode zurückgegeben und ist bekannt als JSX. „TouchableOpacity“ und „Text“ sind bereits existierende Komponenten welche von React Native bereitgestellt werden. Sobald eine Komponente erstellt wurde, kann sie überall in der Applikation mit konsistentem Verhalten und Styling wiederverwendet werden.

Das ist nur ein kleines Beispiel, aber es zeigt wie eine React Native App aufgebaut ist. Wenn man sich an diesen Grundaufbau hält, kann man Komponenten erstellen, welche in sich aufbauende Schichten repräsentieren. Es kann zum Beispiel eine „ButtonGroup“-Komponente erstellt werden, welche einzelne „MenuButtons“-Komponenten beinhaltet. Hier kommt man auch schon zum wesentlichen Vorteil von React Native, mit diesem Ansatz können nämlich komplexe Applikationen gebaut werden, welche aus einzelnen leicht verständlichen Komponenten bestehen, so bleibt der Code überschaubar und handlich (Bray & Holmes, 2015), dies erleichtert den Wartungsaufwand immens. Mit diesem Verfahren können auch die standardmäßigen Komponenten einer Plattform verwendet werden, also zum Beispiel „UITabBar“ bei iOS. Das wirkt sich vor allem positiv auf das konsistente Aussehen und Verhalten der App aus und erhöht die Qualität der Anwendung.

5.4.3. Asynchrone Ausführung Alle Operationen zwischen dem JavaScript-Applikationscode und den nativen Komponenten der Plattform werden asynchron ausgeführt. Die nativen Module können außerdem zusätzliche eigene Threads verwenden, welche wieder ganz unabhängig davon abgearbeitet werden. Das bedeutet, man kann zum Beispiel im Main-Thread per JavaScript eine Bildbearbeitung starten, diese läuft aber im Hintergrund in einem separaten Thread ab, und blockiert somit den Main- Thread nicht. Dies führt dazu, dass React Native Applikationen sehr flüssig laufen und immer sofort reagieren. (Bray & Holmes, 2015)

5.4.4. Gestaltung von Elementen Das Layout einer App und die Darstellung von verschiedenen Elementen basiert bei React Native auf dem Flexbox Layout-Modus. Das Problem bei vielen anderen Frameworks ist, dass sie eine eigene Layout-Definition verwenden, was meistens viel Einarbeitungs- und Anpassungsaufwand mit sich bringt. Die Flexbox-Unterstützung bei React Native bedeutet, dass man für Android und iOS exakt die gleichen Layout-Definitionen wie für das Web umsetzen kann. (Bray & Holmes, 2015) 5.4.5. JSX JSX ist eine JavaScript-Syntax-Erweiterung, welche am XML-Format angelehnt ist. Die objektorientierte Sprache wurde ursprünglich von DeNA als Forschungsprojekt entwickelt und hat folgende Charakteristiken (DeNA Co., Ltd. et al. , 2016):

4. August 2016 Peter Sonnleitner, BSc 38/79

 Statisch typisiert Statische Typisierung bedeutet, dass der Datentyp schon bei der Kompilierung festgelegt wird. Das kann zum Beispiel durch eine explizite Deklaration oder durch Typinferenz erfolgen.

 Performanter JSX führt während dem Kompilieren des Quellcodes in JavaScript-Syntax viele Optimierungen aus. Der generierte Code kann schneller ausgeführt werden als gleichwertiger Code, welcher direkt in JavaScript geschrieben wurde.

 Qualitativer Durch einige Eigenschaften von JSX, etwa durch die statische Typisierung, erhöht sich die Codequalität gegenüber herkömmlichen JavaScript-Code ganz von selbst, da zum Beispiel viele Fehler bereits bei der Entwicklung vermieden werden.

 Einfacher JSX bietet wie JAVA ein solides Klassensystem, was die Entwickler und Entwicklerinnen von dem primitiven Ansatz von JavaScript befreit. Der Einarbeitungsaufwand kann trotzdem relativ klein gehalten werden, weil Ausdrücke und Statements gleich wie in JavaScript aufgebaut sind.

In Kombination mit React oder React Native ist es nicht zwingend erforderlich mit JSX zu entwickeln, es wird aber von Facebook empfohlen, weil es eine prägnantere und einfachere Syntax besitzt und Baumstrukturen um ein vielfaches leichter und strukturierter definiert werden können. (Facebook Inc., 2016)

In dem Folgenden einfachen Beispiel zeigt sich die einfache Funktionsweise von JSX anhand einer kleinen Codetransformation von JSX zu nativen JavaScript-Code. var ExampleText; // Input (JSX): var app = ; // Output (JS): var app = React.createElement(ExampleText, {color:"black"});

Code-Ausschnitt 4: Beispielhafter JSX-Code

5.4.6. ECMAScript ECMAScript ist die standardisierte Version von JavaScript durch Ecma Internatonal. ECMA steht für „European Computer Manufacturers Association“ und Ziel ist es, eine international standardisierte Programmiersprache auf Basis von JavaScript sicherzustellen, welche sich in allen standardkonformen Plattformen identisch verhält. (Ecma International, 2016)

Seit dem Erscheinen von React 0.13 Beta 1 ist es möglich ECMAScript 6 für React Komponenten zu verwenden und dies wird auch offiziell von Facebook empfohlen (Facebook Inc., 2016). Bei der sechsten Edition von ES, die Kurzform von ECMAScript, wurden einige signifikante Syntaxerweiterungen gemacht, welche vor allem einen großen Vorteil bei komplexen Applikationen schaffen. Dazu zählen unter anderem Module und Klassen, Iteratoren und neue Schleifentypen, und auch noch sehr viele andere interessante Ansätze. Eine vollständige Auflistung aller Erweiterungen und die gesamte Dokumentation kann auf der offiziellen ECMA-Webseite nachgelesen werden. (Ecma International, 2016)

4. August 2016 Peter Sonnleitner, BSc 39/79

5.4.7. Abgrenzung zu React (ReactJS) React wurde eigentlich für den Einsatz auf Instagram und Facebook entwickelt, hat sich dann aber, angetrieben von Facebook, zu einer Open-Source JavaScript-Bibliothek entwickelt, welche typischerweise für Single-Page-Anwendungen im Webbereich verwendet wird. React Native unterscheidet sich im Einsatzgebiet grundlegend von React, da React Native ein mobiles Framework ist, welches das Erstellen von nativen Apps ermöglicht. Der Ansatz hinter React ist, dass speziell bei großen und komplexen Web-Applikationen Skalierbarkeit gewährleistet werden kann. React konkurriert mit Frameworks wie AngularJS, Bachbone.js und Ember.js, setzt sich aber vor allem in Bezug auf Geschwindigkeit und Performance von diesen Frameworks ab (Braun, 2016). Das Framework arbeitet mit einem virtuellen DOM und minimiert somit zeitaufwändige Zugriffe auf den realen DOM (Document Object Model). Nur Änderungen die wirklich notwendig sind werden synchronisiert und durchgeführt, was dazu führt, dass die ressourcenaufwendige Manipulation des DOM-Baumes um ein Vielfaches minimiert werden kann. Facebook spricht in der Dokumentation von einer „leichtgewichtigen Repräsentation des DOM“. (Braun, 2016) var div = React.createElement('div', null, 'Hello React!'); ReactDOM.render(div, document.getElementByTagName('body')[0]);

Code-Ausschnitt 5: Codeausschnitt einer React-Applikation

Die „createElement“-Methode funktioniert vom Grundansatz sehr ähnlich wie die DOM-Methode „document.createElement“, und erzeugt eine einfache HTML-Struktur. „ReactDOM.render()“ wird von React bereitgestellt und kümmert sich um die Darstellung.

Wie auch bei React Native, arbeiten Entwickler und Entwicklerinnen bei React meistens in JSX. Der JavaScript- Interpreter erzeugt und verwaltet eine virtuelle Kopie vom DOM, das sogenannte „React virtual DOM“. Dieser minimalisiert die Veränderungen und führt diese am echten DOM durch, das macht vor allem komplexe und datenintensive Applikationen performant, da nur die wirklich geänderten Daten synchronisiert werden müssen. (Braun, 2016)

5.4.8. Unterstütze Plattformen React Native wird derzeit für Android ab der Version 4.1 (API 16) und für iOS ab der Version 7.0 unterstützt. Facebook legt aber Wert darauf, die Kompatibilität von Apps, welche mit dem React Native Framework implementiert wurden, zu erweitern. Auf der F8 Konferenz im April 2016 gab Facebook bekannt, dass React Native ab sofort auch für Windows 10 UWP entwickelt wird. (Facebook Inc., 2016)

4. August 2016 Peter Sonnleitner, BSc 40/79

6. Implementierung

Für die Implementierung von dem Mobile-Learning-System „Examize“ sind die folgenden Hauptkomponenten von Relevanz, nämlich die Plattform, auf welcher die Kurse erstellt werden können, die App auf welcher die Kurse absolviert werden können und die Schnittstelle, welche diese zwei Komponenten miteinander verknüpft. Die folgende Abbildung 15 zeigt die Grundarchitektur von dem Mobile-Learning-System welches implementiert wurde. Die Beschreibung der Implementierung bezieht sich hauptsächlich auf die Umsetzung von der mobilen Lernapp mit hybriden Frameworks, weil das auch das Themengebiet der eigentlichen Arbeit ist. Aus diesem Grund wird die Umsetzung der Plattform und der Schnittstelle nur kurz erläutert, und die Hauptaufmerksamkeit auf die Implementierung der Examize-App gelenkt.

In der folgenden Grafik ist die Grundarchitektur von dem System dargestellt. Die Datenspeicherung findet in einer MySQL-Datenbank statt, welche zusammen mit dem Apache Webserver und PHP auf einem Server läuft. Der MySQL-Connector basiert auf PHP und stellt die Datenabfragen für die REST-API und der Examize-Plattform bereit. Die Examize-App kommuniziert per AJAX-Requests mit der REST-API. Mehr dazu in den jeweiligen Unterkapiteln.

Abbildung 15: Grundarchitektur vom Mobile-Learning-System „Examize“

4. August 2016 Peter Sonnleitner, BSc 41/79

6.1. Online-Plattform

In diesem Unterkapitel wird kurz auf das Grundsystem und die Implementierung der Examize- Plattform eingegangen. Diese Plattform basiert nicht auf mobilen Technologien, welche in dieser Arbeit eigentlich bearbeitet werden sollen, daher wird hier nur oberflächlich auf die Architektur und die eingesetzten Web-Technologien Bezug genommen.

6.1.1. Webserver Die Online-Plattform läuft auf einem Apache Webserver und wurde mit der Programmiersprache PHP entwickelt. PHP steht für „Hypertext Preprocessor“ und ist eine sehr weit verbreitete Open- Source-Skriptsprache, an einer Perl und C angelehnten Syntax, welche in der Webentwicklung sehr starken Gebrauch und Zuspruch findet. (The PHP Group, 2016) Bei Apache handelt es sich um einen freien Webserver, welcher derzeit weltweit am häufigsten eingesetzt wird. Wesentliche Vorteile dieses Webservers sind, dass er plattformunabhängig eingesetzt werden kann und modular aufgebaut ist – das bedeutet im konkreten, dass man für sehr viele verschiedene Anforderungen Module installieren kann. Für den dynamischen Aufbau einer Webseite in Zusammenhang mit PHP oder Perl ist dieser Webservice bestens geeignet. (The Apache Software Foundation, 2016)

6.1.2. Eingesetzte Web-Technologien Im Folgenden werden kurz die wichtigsten, für die Plattform eingesetzten, Web-Technologien erläutert.

6.1.2.1. Bootstrap Bootstrap ist ein Open-Source-Framework auf Basis von HTML, CSS und JavaScript. Laut der offiziellen Dokumentation ist Bootstrap das beliebteste Framework für die Entwicklung von anpassungsfähigen modernen Web-Projekten. Das Framework wird, wenn dies gewünscht ist, mit fertigem CSS ausgeliefert, kann aber auch mit den CSS-Präprozessoren Sass oder Less verwendet werden. Das Framework kann für alle Geräte verwendet werden und setzt auf den „Mobile First“-Ansatz. Mit Hilfe von sogenannten Media-Queries werden Anwendungen optisch, ohne Verwendung von doppeltem Code, für jedes Gerät richtig angepasst. Außerdem beinhaltet das Framework jede Menge an weiteren Komponenten, welche entweder auf CSS basieren, wie etwa das mächtige Grid-System, oder mit zusätzlicher Hilfe von JavaScript funktionieren, zum Beispiel das Karussell. (Twitter Inc., 2016)

6.1.2.2. jQuery jQuery ist ein plattformunabhängiges Open-Source-Framework auf Basis von JavaScript. Dabei stellt jQuery konkret eine umfangreiche Klassenbibliothek zur Verfügung, die den Zugriff auf den DOM-Baum (Document Object Model) sehr stark vereinfacht. Neben der allgemein weiten Verbreitung wird das Framework aufgrund der performanten Codierung sehr gerne eingesetzt. Der Programmieraufwand von JavaScript-Code kann durch die Verwendung von jQuery erheblich reduziert werden. (Steyer R. , 2011)

6.1.2.3. Handlebars Handlebars ist eine Open-Source-Template-Engine für JavaScript und kommt ohne Logik aus. Der Vorteil der Engine ist, dass sie sehr einfach verwendet werden kann und die Syntax sehr leicht zu verstehen ist. (Patel, 2014)

4. August 2016 Peter Sonnleitner, BSc 42/79

6.1.3. Datenspeicherung Die Datenspeicherung findet in einer MySQL-Datenbank mit der transaktionssicheren Storage- Engine InnoDB statt. Bei MySQL handelt es sich um das global am meisten verbreitete relationale Datenbankverwaltungssystem. Dieses System wird sehr häufig in Kombination mit Apache und PHP eingesetzt, weil es sich dabei um eine sehr solide und performante Grundkonfiguration für Webserver handelt. Es existiert eine Community- und Enterprise-Version, wobei sich diese nur marginal unterscheiden. Bei InnoDB handelt es sich um ein transaktionssicheres Speichersubsystem, welches für MySQL installiert werden kann, und unter anderem Fremdschlüssel und referenzielle Integrität gewährleistet. (Oracle Corporation and/or its affiliates, 2016)

In der Datenbank wurde das folgende relationale Datenbankschema erstellt:

Abbildung 16: Datenbankschema in UML modelliert

Ein kurzer Überblick über alle Tabellen mit einer kurzen Erklärung:

 „login_attempts“: In dieser Tabelle werden alle Login-Versuche mitgespeichert. Nach 30 ungültigen Versuchen mit einer beliebigen Email-Adresse wird das Login für eine Stunde gesperrt.  „users“: In dieser Tabelle werden alle Benutzer und Benutzerinnen der Plattform gespeichert.  „access_tokens“: In dieser Tabelle werden alle Zugangstoken für diverse Kurse gespeichert.  „courses“: In dieser Tabelle werden alle erstellten Kurse gespeichert.  „courses_contents“: In dieser Tabelle werden alle Inhalte eines Kurses gespeichert, das können Wahr-/Falsch-Aussagen oder andere Fragenformate sein.

4. August 2016 Peter Sonnleitner, BSc 43/79

 „courses_contents_statistics“: In dieser Tabelle werden die Statistikdaten für die Kursinhalte gespeichert.  „security_tokens“: Im Grundsystem kann jeder Tabelle ein Security-Token zugeordnet werden. Die Verknüpfung mit dieser Tabelle findet mit einem „table_name“ und „table_key“ statt. Der Security-Token steht in Zusammenhang mit der Rechteverwaltung, der Authentifizierung über die REST-API und zur Verhinderung von XSS und anderen Angriffsszenarien.  „app_statistics“: In dieser Tabelle werden weitere Statistikdaten, wie das Öffnen der App, Modul-Versuche und ähnliches gespeichert. Auch hier kann mit einer „table_name“- und „table_key“-Verknüpfung für jede Tabelle jede beliebige Statistik mitgespeichert werden.

6.2. REST-API

Damit die Examize-Mobile-Learning-App mit der serverseitigen Datenbank kommunizieren kann, wurde als Schnittstelle eine REST-API implementiert. Eine Schnittstelle, auch bekannt unter Interface oder API, ist im Grunde jener Teil eines Systems, welcher zur Kommunikation mit anderen Anwendungen erforderlich ist. REST ist die Abkürzung für Representional State Transfer und bezeichnet ein Programmierparadigma für Webservices. REST schreibt einen Dienst Eigenschaften vor, wobei nicht festgelegt ist, wie dieser genau umgesetzt werden muss, eher handelt es sich dabei um ein Rahmenwerk (Masse, 2011).

Der Architektur-Stil von REST besitzt einige Eigenschaften, die wichtigsten sind folgende:

 Client-Server: Die Kommunikation passiert immer vom Client aus, dieser sendet einen Request zum Server und bekommt eine entsprechende Antwort.  Ressourcen: Jeder Ressource kann mit einer einheitlich zugeordneten Adresse, einem sogenannten Endpunkt, adressiert werden.  Zustandslosigkeit: Die Kommunikation ist zustandslos, das bedeutet, dass jeder Request alle Informationen enthalten muss, welche notwendig sind, damit der Server die Anfrage verarbeiten kann. Dies ist insbesondere mit dem Vorteil verbunden, dass so ein Webservice sehr einfach skaliert werden kann.  Caching: HTTP-Caching wird verwendet, so muss zum Beispiel ein Client nicht mehrmals die gleiche GET-Anfrage für dieselbe Ressource senden.

6.2.1. Silex Die Schnittstelle wurde für das mobile Lernsystem mit Hilfe vom Silex-Framework implementiert und nach den „Best Practices“ aus dem Buch „REST API Design Rulebook“ von Masse (2011) umgesetzt. Silex ist ein sogenanntes Micro-Framework für die Programmiersprache PHP und basiert auf Symfony und Pimple. (SensioLabs Deutschland GmbH, 2016)

In der Examize-API gibt es mehrere Endpunkte, welche mit OPTIONS-, POST-, GET-, PUT- oder DELETE-Requests angefragt werden können und diverse Parameter, Header und/oder Daten verarbeiten können, und einen JSON-Response mit richtigem Statuscode und den angefragten Daten zurückgeben. Für das Login-Verfahren wird beispielsweise eine POST- Methode zur Verfügung gestellt, bei welcher man die Login-Daten mit einem POST-Request zum Server senden kann und im Erfolgsfall als Response einen entsprechenden Security-Token erhält, mit welchen man sich bei weiteren Requests authentifizieren muss.

4. August 2016 Peter Sonnleitner, BSc 44/79

API-Endpunkte mit dem Silex-Framework zu definieren ist extrem einfach. Im Code-Ausschnitt 6 wird eine neue Route definiert um alle Kurse zurückzugeben. Dafür wird einfach eine neue Silex-Applikation instanziiert und die entsprechende Route hinzugefügt.

$app = new Silex\Application();

/** * GET Route /api/v1/courses: Gibt alle Kurse als JSON-Array zurück */ $app->get($this->getMappingBaseUrl() . 'courses', function () { $courses = \CourseController::getAllCourses(); $ret = array(); foreach($courses as $course) { $ret[] = $course->toArray(); } return $this->getJsonSuccessResponse(\StatusCodes::HTTP_OK, $ret); });

$app->run();

Code-Ausschnitt 6: Silex GET-Route zum Aufrufen der Kursliste

Die in Code-Ausschnitt 6 definierte GET-Methode, für das Abrufen einer Kursliste, gibt den in Abbildung 17 sichtbaren Response zurück, wenn ein entsprechender GET-Request gesendet wird.

> GET https://www.appzone.one/api/examize/v1/courses

// Response 200 OK { "success": { "code": 200, "data": [ { "key": 20, "create_date": "2016-04-30 11:32:43", "change_date": "2016-06-17 22:24:53", "name": "Arbeits- und Organisationspsychologie", "id": "AOM_SS2016", "language": "de", "description": "Einführung in die Arbeits...", // Beschreibung gekürzt "is_public": false, "verified": false, "deleted": false, "activated": true, "downloads": 69, "version": 13, "module": 5, "module_names": [ "Modul Arbeitsanalyse", "Modul Führung", // weitere Module... ] }, // weitere Kurse... ] } }

Abbildung 17: JSON-Response von der REST-API

4. August 2016 Peter Sonnleitner, BSc 45/79

6.3. Mobile Lernanwendung

Die mobile Lernanwendung wurde in weiterer Folge mit dem Ionic und React Native Framework implementiert. Um einen optimalen Vergleich zwischen den beiden Entwicklungsoptionen bieten zu können, wurde die Implementierungs-Dokumentation in dieser Arbeit mit beiden Frameworks in der exakt gleichen Struktur angelegt.

6.3.1. Umsetzung mit Ionic In diesem Unterpunkt wird auf die Implementierung der Examize-App mit Ionic näher eingegangen. Es werden die ersten Schritte erläutert, die Basisapplikation implementiert und auf drei ausgewählte Implementierungsaspekte näher eingegangen. Exakt die gleichen Schritte werden unter Punkt 6.3.2. mit dem React Native Framework dargestellt.

6.3.1.1. Erste Schritte Im folgendem werden die ersten Schritte dargestellt, welche zu erledigen sind, um unter Windows mit Ionic eine App zu entwickeln.

Als erstes muss ein gewisses Basissetup, abhängig vom Betriebssystem, auf welchem entwickelt wird (Windows, Mac oder Linux), eingerichtet werden. Dieses Basissetup ist auf der offiziellen Ionic Webseite unter http://ionicframework.com/docs/guide/installation.html für alle Plattformen zu finden. Ionic verwendet Node.js, eine JavaScript-Laufzeitumgebung um den JavaScript-Code zu builden. Eine der wichtigsten Abhängigkeiten ist es also, Node.js zu installieren, auch wenn dies nicht zwingend notwendig ist. Es gibt durchaus andere Möglichkeiten um mit Ionic eine App zu entwickeln, diese werden aber offiziell vom Hersteller nicht empfohlen, da es dadurch zu sehr viel Mehraufwand kommen kann.

Ionic verwendet Cordova zum Verpacken der Web-App in eine native App, folglich muss dieses Framework installiert werden, dies kann mit folgendem einfachen Befehl erledigt werden: > npm install -g cordova

Nun muss auch Ionic installiert werden, was ebenfalls wieder mit einem einfachen Kommandozeilenausdruck erledigt werden kann: > npm install -g ionic

Ionic beinhaltet einen sehr einfachen Kommandozeilendienst, welcher es ermöglicht, Apps zu starten, zu builden oder zu verpacken. Dieser wird im nächsten Schritt verwendet, um ein neues Projekt anzulegen: > ionic start ExamizeApp blank Dieses Kommando erstellt ein neues leeres Ionic-Projekt mit dem Namen „ExamizeApp“. In dem Basisverzeichnis befindet sich ein Starterprojekt mit allen Abhängigkeiten und Grundkonfigurationen um ein App mit Ionic implementieren zu können.

Damit der „build“-Vorgang für ein Betriebssystem durchgeführt werden kann, müssen die gewünschten Plattformen, für welche die App später verfügbar sein soll, hinzugefügt werden. > ionic platform add ios > ionic platform add android

4. August 2016 Peter Sonnleitner, BSc 46/79

Wenn alle Schritte ohne Fehler durchgeführt wurden, kann die Basisapplikation zum Beispiel mit folgendem einfachen Kommando für Android erzeugt werden: > ionic build android Mit diesem Kommando wird eine „deployment“-APK-Datei erstellt, welche auf einem Android- Gerät installiert werden kann. Alternativ kann die App auch im Emulator, vorausgesetzt dieser ist auf dem Entwicklungscomputer richtig installiert und eingerichtet, gestartet werden. > ionic emulate ios

6.3.1.2. Die Basisapplikation Bei jeder Ionic-Applikation handelt es sich im Grunde um eine Webseite, daher ist es zwingend erforderlich, dass es eine Datei im Basisordner gibt, welche vom Browser als Startpunkt interpretiert werden kann. Es muss also eine „index.html“-Datei angelegt werden, welche zum Beispiel folgenden Inhalt aufweisen kann:

ExamizeApp

Code-Ausschnitt 7: HTML-Grundgerüst der Basisapplikation mit Ionic

Das Ionic-Core-JavaScript und die Ionic-AngularJS-Extension befinden sich im „ionic.bundle.js“ und diese müssen verpflichtend eingebunden werden. Das „cordova.js“-File muss immer als letztes eingebunden werden, hier muss beachtet werden, dass diese Datei im Filesystem nicht existiert und erst von Cordova am installierten Echtgerät oder im Emulator zur Verfügung gestellt wird.

Damit die App etwas darstellen kann, muss ein neues AngularJS-Modul erstellt werden und Angular auch mitgeteilt werden, dass dieses Modul beim Starten ausgeführt werden soll. Es wird ein neues File im Basisordner erstellt mit dem Namen „app.js“. Diese Datei muss in der „index.html“ eingebunden werden und es muss folgender Code eingefügt werden: angular.module('examizeModule', ['ionic', 'examize.controllers'])

Code-Ausschnitt 8: Moduldefinition vom „examizeModule“ mit AngularJS

Der Ansatz dieser Modulerstellung kommt von AngularJS, in diesem Schritt wird Angular mitgeteilt, dass das „ionic“-Modul inkludiert werden muss. In diesem Modul befindet sich der notwendige Ionic-Code, welcher für das grundlegende App-Verhalten zuständig ist. „angular.module“ ist eine globale Funktion um in Angular Module zu erstellen, zu registrieren oder zurückzugeben. „examizeModule“ ist der Name vom Modulbeispiel, und der zweite Parameter ist ein Array von allen Modul-Abhängigkeiten. In der gleichen Datei wird nun noch der AngularUI-Router definiert, welcher das Konzept von States verwendet. State steht für Zustand, und jeder Zustand muss hier mit einer URL, unter

4. August 2016 Peter Sonnleitner, BSc 47/79

welcher er erreichbar ist, definiert werden. Außerdem werden ein Controller, welcher den Inhalt regelt, und eine Template-URL, in welchem sich die View befindet, deklariert.

.config(function($stateProvider, $urlRouterProvider) { $stateProvider .state('menu', { url: '/menu', templateUrl: 'templates/menu.html', controller: 'MenuCtrl' }); $urlRouterProvider.otherwise('/menu'); });

Code-Ausschnitt 9: Konfiguration vom „StateProvider“ mit Ionic

Damit Angular mitgeteilt werden kann, welches Modul beim Starten ausgeführt werden soll, muss ein „ng-app“-Attribut zum Body-Tag hinzugefügt werden und das Grundlayout der App festgelegt werden. In folgendem Fall wird also zu Beginn das „examizeModule“ ausgeführt und es wird ein einfaches Basislayout mit einer Statusbar und einer View ausgegeben.

Code-Ausschnitt 10: Inhalt vom Body der Ionic Basisapplikation

Im nächsten Schritt muss der „Menu“-Controller festgelegt werden, der sich um die Darstellung des Menüs kümmert. In diesem Beispiel wird beim „$scope“-Objekt eine Variable „test“ definiert, welche einen einfach String beinhaltet, der später ausgegeben wird. angular.module('examizeModule .controllers', []) .controller('MenuCtrl', function($scope, Chats) { $scope.test = 'Examize Mobile Learning!'; });

Code-Ausschnitt 11: Definition vom „Menu“-Controller mit Ionic

Damit im Menü auch etwas dargestellt werden kann, muss das Template für das Menü definiert werden. Dazu wird eine neue Datei im „templates“-Verzeichnis erstellt, mit dem Namen „menu.html“, so wie das zuvor im „StateProvider“ festgelegt wurde. In dieser Datei befindet sich folgender Inhalt:

{{message}}

Code-Ausschnitt 12: Template für das Menü in der Ionic Basisapplikation

Mit dem Durchführen von diesem Schritt wurde alles Grundlegende für die Basisapplikation erledigt. Wird die App nun in einem Browser gestartet, wird das „examizeModule“ ausgeführt und vom „RouterProvider“ der „Menu“-Zustand festgelegt. Der „Menu“-Controller regelt die Darstellung vom Template, und es wird „Examize Mobile Learning!“ in der App ausgegeben.

4. August 2016 Peter Sonnleitner, BSc 48/79

6.3.1.3. Ausgewählte Implementierungsaspekte Im Folgenden werden drei ausgewählte Implementierungsaspekte von der mobilen Lernapplikation näher erläutert. Dabei handelt es sich um den Grundaufbau eines AJAX- Connectors, welcher die Kommunikation mit der REST-API durchführt. Den Swipeable-Cards, welche zur Darstellung von den Wahr-/Falsch-Aussagen verwendet werden, und dem Barcode- Scanner, welcher es ermöglicht QR-Codes einzuscannen. Genau die gleichen Aspekte werden später auch mit React Native unter dem Punkt 6.3.2.3. erläutert.

6.3.1.3.a. AJAX-Connector Für den AJAX-Connector wurde ein eigenes „ajax“-Service erstellt, dieses verwendet den „$http“-Service von AngularJS und ist grundlegend wie folgt aufgebaut: angular.module('examizeModule.services') .factory('$ajaxService', function($http) { var factory = {}; // ... return factory; });

Code-Ausschnitt 13: Definition vom „ajaxService“ mit Ionic

In diesem Service wird eine Variable mit dem Namen „factory“ erstellt, mit Hilfe dieser werden im Folgeschritt alle Funktionen erzeugt, welche von diesem Service später zur Verfügung gestellt werden sollen. Die definierten Funktionen können später in anderen Controllern und Services, in denen der „$ajaxService“ injiziert wird, verwendet werden.

Im folgenden Codeausschnitt befindet sich die Definition von der „getAllCourses“-Funktion, diese Methode wird später verwendet um alle Kurse über die REST-API abzurufen. In dieser wird ein GET-Ajax-Request definiert, der eine bestimmte URL aufruft und spezielle Header übergibt. Wenn der Request erfolgreich war, wird das „successCallback“ mit dem „response“- Objekt aufgerufen, im Fehlerfall der „errorCallback“ mit dem „error“-Objekt. factory.getAllCourses = function(successCallback, errorCallback){ var request = $http({ method: "GET", url: "https://www.appzone.one/api/examize/v1/courses", params: { }, headers: { 'Accept': 'application/json', 'Content-Type': 'application/json', 'Security-Token': '842b32f87cb63729053927562074e05536c60' } }); request.then(function(response) { successCallback(response); }, function(error) { errorCallback(error); } ); };

Code-Ausschnitt 14: „getAllCourses“-Funktion vom „ajaxService“

Das Grundprinzip ist für alle HTTP-Methoden, ganz egal ob GET, POST oder OPTIONS gleich. Im Folgenden wird eine Funktion mit dem Namen „postStatistics“ definiert, welche ein Statistik- Objekt per HTTP-POST an eine definierte Endpunkt-URL sendet.

4. August 2016 Peter Sonnleitner, BSc 49/79

factory.postStatistics = function(statisticsObj){ var request = $http( { method: "POST", url: "https://www.appzone.one/api/examize/v1/statistics", headers: { 'Content-Type': 'application/json' }, data: statisticsObj }); request.then(function(response) { console.log(response) }, function(error) { console.log(error) } ); };

Code-Ausschnitt 15: „postStatistics“-Funktion vom „ajaxService“

Diese zwei Funktionen können später in jedem Service und Controller ganz einfach verwendet werden. Dazu wird das „$ajaxService“ einfach per Dependency-Injection in den gewünschten Controller injiziert und kann dort dann einfach verwendet werden. Im folgenden Codeausschnitt wird die „getAllCourses“-Funktion im „course“-Controller aufgerufen. angular.module('examizeModule.controllers') .controller('course', function($scope, $ajaxService) { $ajaxService.getAllCourses(function(response) { console.log(response); }, function(error) { console.log(error); }); });

Code-Ausschnitt 16: Verwendung vom „ajaxService“ in einem fremden Controller

6.3.1.3.b. Swipeable-Cards Es existiert eine Reihe von Möglichkeiten um Swipeable-Cards mit Ionic und Angular zu implementieren. Das Grundziel dieser Arbeit ist es, eine mobile Lernanwendung möglichst effizient und einfach zu entwickeln, deshalb wurde für die Swipeable-Cards ein Plugin verwendet. Durch die große Community gibt es, für nahezu jede Anforderung, ein entsprechendes Plugin. Existiert für eine Problemstellung keines, dann führt das zu einer erheblichen Steigerung des Aufwandes, weil alles individuell implementiert werden muss.

Im ersten Schritt muss das „ionic-contrib-tinder-cards“-Plugin mit dem Paketverwaltungstool „bower“ installiert werden: > bower install ionic-contrib-tinder-cards

Sobald dieser Schritt abgeschlossen ist, müssen die installierten JavaScript-Dateien und CSS- Styles entsprechend eingebunden werden. Das wird vom Gulp-Task erledigt, deshalb müssen dort die Pfade für diese Dateien definiert werden. Konkret geht es um drei Dateien mit den Namen „ionic.tdcards.js“, „collide.js“ und „ionic.tdcards.css“.

Das „tinderCards“-Modul muss in der „app.js“ als Modulabhängigkeit hinzugefügt werden. angular.module('examizeModule', [ 'ionic', // ...

4. August 2016 Peter Sonnleitner, BSc 50/79

'ionic.contrib.ui.tinderCards' ]);

Code-Ausschnitt 17: Einfügen einer Modulabhängigkeit in Ionic

Nun kann die AngularJS-Direktive in einem Template verwendet werden, dafür wurde die HTML- Datei für die Wahr-/Falsch-Aussagen mit dem Code-Ausschnitt 18 erweitert. Es werden alle Karten angezeigt, welche sich im „cards“-Array befinden. Unter den Attributen „on-destroy“, „on- swipe-left“ und „on-swipe-right” wird dem Swipeable-Cards-Modul mitgeteilt, welche Funktion bei der entsprechenden Aktion ausgeführt werden soll.

{{card.statement}}

Code-Ausschnitt 18: AngularJS-Direktive zum Darstellen der Swipeable-Cards

Damit die Karten auch zum Leben erwachen, muss im Controller das „cards“-Array befüllt werden. Außerdem müssen die Funktionen, welche im Vorschritt bei den „on-destroy“, „on- swipe-left“ und „on-swipe-right” Attributen festgelegt wurden, definiert werden. angular.module('examizeModule.controllers') .controller('swipeableCardsController', function($scope) { $scope.cards = [ { statement: 'Das ist die erste Aussage. Diese Aussage ist richtig.', isRight: true }, { statement: 'Das ist die zweite Aussage. Diese Aussage ist falsch.', isRight: false } ];

$scope.cardDestroyed = function(index) { $scope.cards.splice(index, 1); };

$scope.cardSwipedRight = function(card) { if(card.isRight) { console.log('Richtig!'); } else { console.log('Falsch!'); } };

$scope.cardSwipedLeft = function(card) { if(!card.isRight) { console.log('Richtig!'); } else { console.log('Falsch!'); } }; });

Code-Ausschnitt 19: Verwendung der „SwipeableCards“ in einem Controller

Wird nun das oben definierte Template von Ionic dargestellt, befinden sich in der View zwei Karten, welche nach links und rechts gewischt werden können.

4. August 2016 Peter Sonnleitner, BSc 51/79

6.3.1.3.c. Barcode-Scanner Damit ein Barcode-Scanner mit dem Ionic Framework umgesetzt werden kann, muss ein entsprechendes Cordova-Plugin verwendet werden, da nur so auf die Kamera zugegriffen werden kann. Im ersten Schritt muss also ein Plugin installiert werden, welches die definierte Anforderung erfüllt. Dazu wurde das „phonegap-plugin-barcodescanner“-Plugin installiert: > cordova plugin add https://github.com/phonegap/phonegap-plugin-barcodescanner.git

Sobald die Installation abgeschlossen ist, wird in der App ein neues „barcodeScanner“-Service erstellt, welches von allen Controllern und Services global verwendet werden kann. Dieses Service stellt die Funktion „scanBarcode“ bereit. Wenn diese Methode aufgerufen wird, öffnet sich die Kameraview in der bekannten Barcode-Scanner-Optik, richtet man diese auf einen Barcode und wird dieser erkannt, werden die Daten einfach an die zuständige „successCallback“-Methode übergeben. angular.module('examizeModule.services') .factory('$barcodeScanner', function($scope, $cordovaBarcodeScanner) { var factory = {}; factory.scanBarcode = function(successCallback, errorCallback){ $cordovaBarcodeScanner .scan() .then(function(barcodeData) { successCallback(barcodeData); }, function(error) { errorCallback(error); }); }; return factory; });

Code-Ausschnitt 20: „barcodeScanner“-Service in der Examize-App

In der Examize-App wird dem Barcode-Scanner-Button mit dem „ng-click“-Event, was nichts anderes als ein Click-Observer ist, die „scanQrCode“-Funktion zugeordnet.

$scope.buttons.push({ name: $translate.instant('Scan QR-Code'), ng-click: 'scanQrCode()' });

Code-Ausschnitt 21: Hinzufügen eines Buttons zum Menü

Der folgende Codeausschnitt zeigt die Definition der „scanQrCode“-Methode, welche direkt auf das „$scope“-Objekt gebunden ist. Diese verwendet den „barcodeScanner“-Service und ruft bei diesem Service die oben definierte Funktion „scanBarcode“ auf.

$scope.scanQrCode = function() { $barcodeScanner.scanBarcode(function(barcodeData){ var url = barcodeData.text; $ionicLoading.show({ template: 'Bitte warten...' }); $coursesService.startCourseFromUrl(url); }, function(error){ $ionicLoading.show({ template: 'Bei dem Sannen vom QR-Code ist ein Fehler aufgetreten.', }); }); };

Code-Ausschnitt 22: Verwendung vom „barcodeScanner“-Service in einer Funktion

4. August 2016 Peter Sonnleitner, BSc 52/79

6.3.1.4. Unterstützende Technologien Bei der Implementierung von der Examize-App mit Ionic wurden einige Technologien verwendet, welche als Unterstützung für den Entwicklungsprozess dienten. An dieser Stelle wird kurz Bezug zu den interessantesten Tools genommen.

6.3.1.4.a. Gulp Gulp ist ein auf Node.js basierendes JavaScript-Build-System, welches öfters auch als Task- Runner bezeichnet wird. Dieses System ist für die Automatisierung von Prozessen sehr gut geeignet, weil diese sehr leicht und mit geringem Einarbeitungsaufwand programmierbar sind. Wird ein Gulp-Task gestartet, werden Prozesse in einer definierten Reihenfolge abgearbeitet und die Implementierungsphase wird dadurch stark beschleunigt. Gulp bietet aber noch eine Reihe von weiteren Features, zum Beispiel können Veränderungen am Quellcode überwacht werden. (Maynard, 2015)

Im Folgenden ist ein Teil von der „gulpfile.js“-Konfigurationsdatei beschrieben. Im ersten Schritt, müssen wie im Code-Ausschnitt 23 ersichtlich, die verwendeten Gulp-Plugins eingebunden werden. Damit diese eingebunden werden können, müssen sie zuvor als Abhängigkeiten installiert werden. var gulp = require('gulp'); var gutil = require('gulp-util'); var inject = require('gulp-inject'); var bower = require('bower'); var concat = require('gulp-concat'); var sass = require('gulp-sass'); var minifyCss = require('gulp-minify-css'); var rename = require('gulp-rename'); var sh = require('shelljs');

Code-Ausschnitt 23: Die benötigten Gulp-Plugins werden eingebunden

In weiterer Folge werden die Pfade für die Dateien, die verarbeitet werden sollen, festgelegt. Das kann mit Wildcards auch Verzeichnisübergreifend definiert werden. var paths = { sass: [ './scss/**/*.scss', './www/app/components/*/styles.scss' ], : [ './www/core/js/services.js', // ... './www/app/components/**/service.js' ] };

Code-Ausschnitt 24: Definition der Pfade von den JavaScript- und Sass-Dateien

Nun wird der eigentliche Task festgelegt. Unter dem Code-Ausschnitt 25 wird ein Gulp-Task dargestellt, welcher einige Aktionen mit Sass-Files durchführt. Diese werden zu CSS-Kompiliert, in eine Datei zusammengefasst und zusätzlich komprimiert. Am Ende wird die generierte CSS- Datei gespeichert und automatisch durch definierte Platzhalter in die Index-Datei eingebunden. gulp.task('sass', function(done) { gulp.src(paths.sass) .pipe(concat('ionic.css')) .pipe(sass({

4. August 2016 Peter Sonnleitner, BSc 53/79

errLogToConsole: true })) .pipe(minifyCss({ keepSpecialComments: 0 })) .pipe(inject(streamCss, { relative: true, starttag: '', endtag: '', })) .pipe(gulp.dest('./www/assets/css/')) .on('end', done); });

Code-Ausschnitt 25: Gulp-Task welcher einige Aktionen mit Sass-Files durchführt

6.3.1.4.b Node Package Manager Bei dem Node Package Manager, meistens einfach als „npm“ bezeichnet, handelt es sich um einen Paketmanager für die Laufzeitumgebung „node.js“. Jedes „npm“-Paket beinhaltet eine „package.json“-Datei, welche die relevanten Metadaten für das Projekt beinhaltet (Tilkov & Vinoski, 2010). Diese Daten werden verwendet, um „npm“ darüber zu informieren, um welches Projekt es sich handelt, beziehungsweise welche Abhängigkeiten es besitzt. Im Folgenden ist der Inhalt von dieser Paketdatei dargestellt:

{ "name": "ExamizeApp", "version": "1.0.3", "description": "Examize Mobile Learning App", "dependencies": { "gulp": "^3.5.6", "gulp-sass": "^2.0.0", "gulp-concat": "^2.2.0", "gulp-minify-css": "^0.3.0", "gulp-uglify": "^1.5.3", "gulp-rev": "^7.0.0", "gulp-rename": "^1.2.0" }, "devDependencies": { "bower": "^1.3.3", "gulp-inject": "^3.0.0", "gulp-minify-css": "^0.3.13", "gulp-sass": "^1.3.3", "gulp-util": "^2.2.14", "shelljs": "^0.3.0" }, "cordovaPlugins": [ "cordova-plugin-device", "cordova-plugin-console", "cordova-plugin-whitelist", "cordova-plugin-splashscreen", "com.ionic.keyboard" ], "cordovaPlatforms": [ "android", "iOS" ] }

Code-Ausschnitt 26: „package.json“ für die Ionic App

Unter dem Code-Ausschnitt 26 ist diese Konfiguration ersichtlich. Dabei werden einige Metadaten definiert, zum Beispiel, dass der Name vom Projekt „ExamizeApp“ lautet und es sich um die Version 1.0.3 handelt. Außerdem werden diverse Abhängigkeiten zu „gulp“, die installierten Cordova-Plugins und welche Plattformen für das Projekt relevant sind angegeben.

4. August 2016 Peter Sonnleitner, BSc 54/79

6.3.2. Umsetzung mit React Native In diesem Unterkapitel wird auf die Implementierung der Examize-App mit React Native näher eingegangen. Wie bereits in Punkt 6.3.1. erwähnt, wurden exakt die gleichen Schritte auch mit dem Ionic Framework durchgeführt.

6.3.2.1. Erste Schritte Im Folgenden werden die ersten Schritte dokumentiert, welche zu erledigen sind, um unter Windows mit React Native eine App zu entwickeln.

Im ersten Schritt muss ein gewisses Basissetup, abhängig vom Betriebssystem auf welchem entwickelt wird (Windows, Mac oder Linux) eingerichtet werden. Dieses Basissetup ist auf der React Native Webseite unter https://facebook.github.io/react-native/docs/getting- started.html#content für alle Plattformen zu finden. React Native verwendet, genauso wie auch Ionic, Node.js und von diesem Tool sollte auch unbedingt Gebrauch gemacht werden, da es ansonsten zu sehr viel Mehraufwand kommen kann.

Sobald diese Abhängigkeiten installiert wurden, kann mit den folgenden simplen Kommandozeilenausdrücken ein neues Projekt angelegt werden.

> npm install -g react-native-cli Mit Hilfe von dem Paketmanager „npm“ wird das Kommandozeileninterface „react-native-cli“ installiert. Dieser Schritt muss auf einer Entwicklungsplattform nur ein einziges Mal durchgeführt werden, danach können mit der React Native Libary, welche in diesem Schritt in Form einer Abhängigkeit ebenfalls installiert wurde, einfach neue Projekte angelegt werden.

> react-native init ExamizeApp Das „react-native init“-Kommando erstellt ein neues React Native Projekt mit dem angegebenen Namen, in diesem Fall „ExamizeApp“. In dem Basisverzeichnis befindet sich ein Starterprojekt mit allen Abhängigkeiten und Grundkonfigurationen um mit React Native ein Projekt zu implementieren.

> react-native run-android Im „ExamizeApp“-Verzeichnis kann mit diesem Kommando die App ganz einfach im Emulator oder am Android-Gerät gestartet werden.

Bevor mit dem nächsten Schritt fortgefahren wird, empfiehlt es sich, „Watchman“ zu installieren. „Watchman“ ist ein Dienst für die Datenüberwachung von Facebook, dieser erkennt Änderungen in Dateien und „rebuilded“ das Projekt sobald Änderungen erkannt wurden. Dieser lässt sich mit folgendem einfachen Kommando, vorausgesetzt man verwendet Brew, installieren: > brew install watchman

Wenn man das generierte Basisverzeichnis öffnet, gibt es darin ein „android“-, „ios-“, „node_modules“- und „res“-Verzeichnis, ein paar Konfigurationsdateien und eine Index-datei für Android und iOS. Im „node_modules“-Verzeichnis ist das gesamte React Native Framework untergebracht. Entscheidend für die Entwicklung sind die „index.android.js“ und die „index.ios.js“, welche den Startpunkt für die entsprechende Plattform setzen. Im „ios“- und „android“-Ordner sind der Java- und X-Code enthalten, um die Applikation auf den jeweiligen Betriebssystem ausführen zu können. Wenn man nun Beispielsweise das „index.android.js“-File

4. August 2016 Peter Sonnleitner, BSc 55/79

öffnet und ausführt, vorausgesetzt man hat einen Android-Emulator installiert oder ein echtes Android-Gerät angeschlossen, dann startet die App mit einem simplen „Welcome to React native!“-Screen. 6.3.2.2. Die Basisapplikation Einfache Anforderungen können mit React Native für Android und iOS mit dem exakt gleichen Code implementiert werden, deshalb wird im Folgenden nur noch vom Inhalt der Starterdatei für Android, nämlich „index.android.js“, gesprochen. Wie bereits im theoretischen Teil unter Punkt 5.4. erwähnt, gibt es erst bei komplexeren Anforderungen plattformabhängige Unterscheidungen im Quellcode.

Die erste Codezeile in der „index.android.js“ ist folgende:

'use strict';

Code-Ausschnitt 27: Aktivierung vom „Strengen Modus" in React Native

Das aktiviert den sogenannten „Strengen Modus“, dabei wird verbessertes Error-Handling aktiviert und einige nicht ideale JavaScript-Features werden deaktiviert. Ganz einfach gesagt, es macht JavaScript einfach besser. Im Grunde ist der „Strict Mode“ ein neues Feature im ECMAScript5, welcher es erlaubt eine Applikation sensibler auszuführen. Es werden mehr Exceptions geworfen und gewisse Aktionen einfach verhindert, außerdem bekommt der Entwickler oder die Entwicklerin viel mehr Informationen zu allen auftretenden Fehlern und Warnungen. Einfache Programmier- und Syntaxfehler, welche in normaler JavaScript- Umgebung ohne Probleme funktionieren würden, wie etwa ein zusätzliches Semikolon, verursachen hier einen Fehler. Es wird also auch die Qualität vom Quellcode verbessert, außerdem werden unsichere Aktionen, wie etwa der Zugriff auf globale Objekte oder die Verwendung von unsicheren Funktionen, zum Beispiel „eval“, verhindert.

Die nächste Codezeile lädt das React Native Basismodul und ordnet es der React-Variable zu. Generell verwendet React Native das gleiche Ladeverfahren wie auch Node.js mit der „require“- Funktion. var React = require('react-native');

Code-Ausschnitt 28: React Native Basismodul wird eingebunden

Nach diesem „require“-Statement wird ein einfacher Style definiert. Dieser wird später einem Text zugeordnet. var styles = React.StyleSheet.create({ title: { color: 'blue', fontSize: 25, backgroundColor: 'transparent', margin: 100 } });

Code-Ausschnitt 29: Style-Definition in React Native Im nächsten Schritt wird der eigentliche Code von der Komponente entwickelt, dazu wird der in Code-Ausschnitt 30 ersichtliche JavaScript-Code eingefügt. „ExamizeApp“ erbt hier von „React.Component“, das ist ein Standardverfahren um das React-UI zu bauen. Komponenten beinhalten unveränderbare Eigenschaften „props“, veränderbare „state“-Variablen und stellen

4. August 2016 Peter Sonnleitner, BSc 56/79

eine Methode für das Rendern zur Verfügung. Diese Beispielapplikation ist sehr einfach aufgebaut, deshalb wird nur eine einfache „render“-Methode benötigt. class ExamizeApp extends React.Component { render() { return React.createElement(React.Text, {style: styles.title}, "Examize!"); } }

Code-Ausschnitt 30: „ExamizeApp“-Komponente in React Native

Wie man in dem Codebeispiel am „class“-Schlüsselwort erkennen kann, wurde hier in JavaScript eine Klasse definiert. Typen, wie etwa Klassen, wurden in ECMAScript 6 eingeführt, nachdem sich JavaScript weiterentwickelt hat. Lange Zeit war es ein Problem, sicherzustellen, dass dieser JavaScript-Code auch abwärtskompatibel bleibt. ES6 wird also nicht auf jeder Plattform unterstützt, hier gibt es aber einige Tools, welche diese Syntax einfach in völlig konformes JavaScript übersetzen. Eines davon ist Babel. (Ecma International, 2016)

Babel ist ein JavaScript-Compiler, welcher Code mit neuen Standards in gängigen Quellcode übersetzt. Dieser Compiler wird von React Native standardmäßig genutzt, kann aber auch mit vielen anderen Plattformen und Frameworks verwendet werden.

Bevor die App ausgeführt werden kann, muss noch der Einstiegspunkt für die Applikation gesetzt werden und die Root-Komponente definiert werden, damit das React Native Framework auch weiß, welche Komponente es nach dem Starten darstellen soll.

React.AppRegistry.registerComponent('ExamizeApp', function() { return PropertyFinderApp });

Code-Ausschnitt 31: Einstiegspunkt der React Native Applikation wird definiert

Nun kann die App einfach im Emulator oder am echten Gerät ausgeführt werden. Der JavaScript-Code wird ausgeführt und eine native Oberfläche wird gerendert.

Der bisher dargestellte Code wurde nach allen Richtlinien von der React Native Dokumentation umgesetzt. Dieser Quellcode kann noch weiter vereinfacht werden, nämlich durch Verwendung von JSX. Auch wenn dieser Beispielcode noch sehr einfach zu lesen ist, so wird er mit komplexeren Strukturen immer unübersichtlicher, JSX schafft hier Abhilfe. Die „render“-Methode der Komponente muss einfach mit folgendem Code ersetzt werden, welcher HTML mit JavaScript vereint und damit die Grundidee von JSX repräsentiert. return Hello World (Again);

Code-Ausschnitt 32: Vereinfachter Javascript- und HTML-Code (JSX)

6.3.2.3. Ausgewählte Implementierungsaspekte Im Folgenden werden, wie dies unter Kapitel 6.3.1.3. bereits für Ionic gemacht wurde, drei ausgewählte Implementierungsaspekte näher betrachtet.

6.3.2.3.a. AJAX-Connector Es gibt verschiedene Möglichkeiten um in React Native einen AJAX-Request abzuhandeln, einer der einfachsten Wege ist Fetch. Fetch ist eine verbesserte Form von der Netzwerk-API und ist standardmäßig in React Native inkludiert.

4. August 2016 Peter Sonnleitner, BSc 57/79

Um alle Kurse aufzurufen, wurde eine Funktion „getAllCourses“ implementiert. Diese Funktion verwendet „fetch“, um einen Request abzusetzen. Wie man in folgendem Codeausschnitt erkennen kann, ist der „fetch“-Mechanismus eigentlich selbsterklärend und sehr einfach anzuwenden. getAllCourses: function() { fetch("https://www.appzone.one/api/examize/v1/courses", { method: "GET", headers: { 'Accept': 'application/json', 'Content-Type': 'application/json', 'Security-Token': '842b32f87cb63729053927562074e05536c60' }, }) .then((response) => response.json()) .then((responseData) => { console.log(responseData) }) .catch((error) => { console.log(error); }); },

Code-Ausschnitt 33: Aufbau eines GET-Fetch-Requests in React Native

Der Fetch-Methode wird ein definierter Routen-Endpunkt zusammen mit einem Konfigurationsobjekt übergeben, darin wird die Methode definiert und bestimmte Header gesetzt. Wie auch beim Ajax-Request unter AngularJS, kann hier angegeben werden, was im Erfolgs- oder Fehlerfall passieren soll. Zur vereinfachten Darstellung des Codes wurde hier die Logik entfernt und mit einem „console.log“-Statement ersetzt, welche das Response-Objekt ausgibt. Genauso einfach können auch Requests zu anderen HTTP-Methoden gemacht werden, wie etwa ein „POST“. Auch hier wird wieder ein Endpunkt zusammen mit dem Konfigurationsobjekt übergeben, mit dem Unterschied, dass zusätzlich auch noch ein Post-Body definiert wird, welcher der Methode als „statisticsObj“ übergeben wird. postStatistics: function(statisticsObj) { fetch("https://www.appzone.one/api/examize/v1/statistics", { method: "POST", headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(statisticsObj) }) .then((response) => response.json()) .then((responseData) => { console.log(responseData) }) .catch((error) => { console.warn(error); }); },

Code-Ausschnitt 34: Aufbau eines POST-Fetch-Requests in React Native

Diese definierten Funktionen können zum Beispiel in der „render“-Methode an diverse Elemente gebunden werden. In folgendem Beispiel wird etwa die „getAllCourses“-Funktion per „onPress“- Event, welches ausgeführt wird, sobald das Element gedrückt wird, einem Button hinzugefügt. Wenn beim Ausführen der Applikation der Button geklickt wird, dann werden alle verfügbaren Kurse geladen und in einer Liste angezeigt.

4. August 2016 Peter Sonnleitner, BSc 58/79

render: function() { return ( Alle Kurse anzeigen ); },

Code-Ausschnitt 35: Render-Methode für die Ausgabe eines Buttons

6.3.2.3.b. Swipeable-Cards Um unter React Native sogenannte „Swipeable Cards“ entwickeln zu können gibt es verschiedene Möglichkeiten. Eine davon ist, das „react-native-swipe-cards“-Plugin zu verwenden. Dafür muss dieses mit dem Node-Package-Manager installiert werden. > npm install --save react-native-swipe-cards

Im Folgeschritt muss ein neues Modul erstellt werden, zum Beispiel „SwipeableCards.js“. Dieses muss in dem Modul in dem man es verwenden möchte importiert werden. import SwipeableCards from './SwipeableCards.js'

Code-Ausschnitt 36: Import vom „SwipeableCards“-Modul in React Native

Die folgenden Schritte finden alle in der Komponente „SwipeableCards“ statt, welche in der eben erstellten Datei „SwipeableCards.js“ eingefügt werden.

'use strict'; import React, { Image, StyleSheet, Text, View } from 'react-native'; import SwipeCards from 'react-native-swipe-cards'; Code-Ausschnitt 37: Grundinhalt von der Swipeable-Cards-Komponente Es wird wieder der „Strenge Modus“ aktiviert und die verwendeten Basis-Komponenten werden zusammen mit dem eben installierten „react-native-swipe-cards“-Plugin importiert.

Nun müssen die Swipeable-Cards definiert werden. Diese werden in der eigentlichen Applikation von dem Ajax-Connector geladen und sind in einer viel komplexeren Architektur aufgebaut, zur vereinfachten Darstellung wurde dies entfernt und durch eine statische Deklaration ersetzt. const Cards = [ { statement: 'Das ist die erste Aussage. Diese Aussage ist richtig.', isRight: true }, { statement: 'Das ist die zweite Aussage. Diese Aussage ist falsch.', isRight: false } ]

Code-Ausschnitt 38: Statische Deklaration von der „Cards“-Variable

4. August 2016 Peter Sonnleitner, BSc 59/79

Die Applikationslogik befindet sich in der Definition der Klasse, welche im Code-Ausschnitt 39 stark vereinfacht dargestellt wird. Im diesem Codeausschnitt werden zwei Funktionen definiert, welche das Wischen der Karte nach Links oder Rechts behandeln, in diesem Fall „handleYup“ und „handleNope“. Die Karten werden von der Render-Methode ausgegeben, diese verwendet die „SwipeCards“-Komponente, welche von dem Plugin zur Verfügung gestellt wird. Die übergebenen Werte in dieser Komponente werden vom Plugin entsprechend behandelt und richtig dargestellt. export default React.createClass({ getInitialState() { return { cards: Cards } }, handleYup (card) { if(card.isRight) { console.log('Richtig!'); } else { console.log('Falsch!'); } }, handleNope (card) { if(!card.isRight) { console.log('Richtig!'); } else { console.log('Falsch!'); } }, render() { return ( } renderNoMoreCards={() => } handleYup={this.handleYup} handleNope={this.handleNope} /> ) } })

Code-Ausschnitt 39: Funktonsaufbau von der „SwipeableCards"-Komponente

Damit die Wahr-/Falsch-Aussagen optisch wie im Entwurf dargestellt werden, müssen sie entsprechend gestaltet werden. Dafür wird in folgendem Codeausschnitt mit Hilfe von Flexbox das Grunddesign definiert: const styles = StyleSheet.create({ card: { flex: 1, justifyContent: 'center', alignItems: 'center', width: 400, height: 400, } })

Code-Ausschnitt 40: Definition eines Styles in React Native

Die neu erstellte Komponente kann in der Anwendung global benutzt werden, mit der Bedingung, dass man sie entsprechend importieren muss. Die Verwendung ist sehr einfach und kann mit der bereits bekannten React Native Syntax leicht dargestellt werden.

Code-Ausschnitt 41: Verwendung der „SwipeableCards“-Komponente

4. August 2016 Peter Sonnleitner, BSc 60/79

6.3.2.3.c. Barcode-Scanner Um in React Native einen Barcode-Scanner umsetzen zu können, muss die Kamera verwendet werden. Folglich ist eine Implementierungsmöglichkeit, ein entsprechendes Kamera-Plugin zu installieren. Dazu muss folgender Befehl ausgeführt werden, welcher dieses Plugin zum Projekt hinzufügt:

> npm install react-native-camera --save

Im Folgeschritt wird ein neues Modul erstellt, zum Beispiel „BarcodeScanner.js“. Dieses muss in dem Modul in dem man es verwenden möchte importiert werden. import BarcodeScanner from './BarcodeScanner.js'

Code-Ausschnitt 42: Import vom „BarcodeScanner“-Modul in React Native

Die folgenden Schritte finden alle in der Komponente „BarcodeScanner“ statt. Der bereits bekannte „Strenge Modus“ wird wieder aktiviert und die benötigten Komponenten werden importiert.

'use strict'; var React = require("react-native"); var Camera = require("react-native-camera"); var { AppRegistry, StyleSheet, Text, View } = React;

Code-Ausschnitt 43: Grundinhalt von der Barcode-Scanner-Komponente

In der „getInitialState“-Funktion, welche eine Art Konstruktor ist und beim Erstellen des Objekts ausgeführt wird, werden die initialen Variablen definiert, welche später Verwendung finden. Es handelt sich quasi um eine Initialisierung des Grundzustandes in React Native. getInitialState: function() { return { typeOfCamera: Camera.constants.Type.back, scannerActive: true } }

Code-Ausschnitt 44: Initialisierung vom Grundzustand in React Native

Nun wird eine Funktion definiert, welche ausgeführt wird, sobald ein Barcode erkannt wird. Diese muss später an ein entsprechendes Event gekoppelt werden. Wenn diese Funktion ausgeführt wird, wird der Zustand, dass der Scanner aktiv ist auf falsch gesetzt und mit den Daten eine entsprechende Aktion ausgeführt, welche zur Vereinfachung durch eine Konsolenausgabe ersetzt wurde.

_onQrCodeDetected: function(e) { this.setState({scannerActive: false}); console.log(e.data); }

Code-Ausschnitt 45: „onQrCodeDetected“-Funktion in React Native

4. August 2016 Peter Sonnleitner, BSc 61/79

Die “renderScanner”-Funktion ist dafür zuständig die Kamera anzuzeigen. Sobald die „scannerActive“-Variable auf falsch gesetzt wird, verschwindet die Kamera und eine andere View, in diesem Fall eine leere, wird eingeblendet. Der Kamera wird außerdem die notwendige Information gegeben, dass sie beim Erkennen eines Barcodes, die „onQrCodeDetected“- Funktion ausführen soll. Wird beim Ausführen der Komponente ein Barcode erkannt, werden die Informationen davon in der Konsole ausgegeben. renderScanner: function() { if(this.state.scannerActive) { return ( onBarCodeRead={this._onQrCodeDetected} ); } else { return ( ); } }

Code-Ausschnitt 46: „renderScanner“-Funktion in React Native

Damit React Native auch weiß, wann es die „renderScanner“-Funktion ausführen soll, muss diese noch in der „render“-Funktion von der Komponente angehängt werden. render: function() { return ( this.renderScanner() ); }

Code-Ausschnitt 47: Rendern vom Barcode-Scanner

6.3.2.4. Unterstützende Technologien Bei der Implementierung der Examize-App mit React Native wurden einige Technologien verwendet, welche als Unterstützung für den Entwicklungsprozess dienten. Dabei wurde wie auch schon bei Ionic der Node Package Manager verwendet. Die Konfigurationsdatei ist jener vom Ionic-Projekt sehr ähnlich, mit dem Unterschied, dass es andere Abhängigkeiten gibt. Zusätzlich wurde bei der Entwicklung mit React Native noch Gradle verwendet, was im Folgenden kurz erläutert wird.

6.3.2.4.a. Gradle Gradle ist ein Tool, mit welchem man den Build-Prozess automatisieren kann. Der Vorteil davon ist, dass es sehr gut an die individuelle Benutzerumgebung angepasst werden kann und eigentlich jede Problemstellung damit umgesetzt werden kann, somit können auch komplexe Build-Vorgänge automatisiert werden, welche sich aber dennoch sehr schnell und kompakt durchführen lassen. (Muschko, 2014)

Um beim Google Play Store eine Applikation hochladen zu können, muss eine Android-App digital signiert werden. Dieser Schritt wurde für die mobile Lernapplikation mit Gradle in den Build-Prozess integriert und in weiterer Folge genauer beschrieben.

Im ersten Schritt muss mit dem Java-„keytool“ ein digitaler Schlüssel erzeugt werden, welcher mit einem einfachen Kommandozeilenausdruck generiert werden kann.

4. August 2016 Peter Sonnleitner, BSc 62/79

> $ keytool -genkey -v -keystore examizeApp.keystore -alias examizeApp -keyalg RSA - keysize 2048 -validity 10000

Die generierte Keystore-Datei muss in das Projektverzeichnis kopiert werden und in der „~/.gradle/gradle.properties“-Datei müssen globale Variablen definiert werden, welche später in der Gradle-Build-Datei verwendet werden. EXAMIZEAPP_RELEASE_STORE_FILE=examizeApp.keystore EXAMIZEAPP_RELEASE_KEY_ALIAS=examizeApp EXAMIZEAPP_RELEASE_STORE_PASSWORD=examizepassword EXAMIZEAPP_RELEASE_KEY_PASSWORD=examizepassword

Code-Ausschnitt 48: Inhalt von der „gradle.properties"-Datei

Das Buildsystem Gradle wird von React Native standardmäßig verwendet, deshalb existiert bereits ein „build.gradle“-File, in welches einfach weitere Build-Schritte inkludiert werden können. Unter Code-Ausschnitt 49 sind jene Schritte aufgelistet, welche in weiterer Folge hinzugefügt wurden. android { ... signingConfigs { release { storeFile file(EXAMIZEAPP_RELEASE_STORE_FILE) storePassword EXAMIZEAPP_RELEASE_STORE_PASSWORD keyAlias EXAMIZEAPP_RELEASE_KEY_ALIAS keyPassword EXAMIZEAPP_RELEASE_KEY_PASSWORD } } buildTypes { release { ... signingConfig signingConfigs.release } } }

Code-Ausschnitt 49: Konfiguration zum Signieren einer APK-Datei in Gradle

Wird im Android-Ordner des Projektverzeichnisses per Kommandozeile folgendes Statement ausgeführt, „baut“ Gradle das gesamte Projekt und signiert es auch sofort. Die fertige APK-Datei kann direkt in den Google Play Store hochgeladen und distribuiert werden.

> gradlew assembleRelease

4. August 2016 Peter Sonnleitner, BSc 63/79

7. Vergleichsanalysen zwischen Ionic und React Native

In diesem Kapitel werden Vergleichsanalysen zwischen dem Ionic und React Native Framework in verschiedenen Kategorien aufgestellt und näher erläutert, dabei wir auch immer wieder Bezug auf die entwickelte mobile Lernapplikation genommen. Daraus wird in weiterer Folge ein Fazit abgeleitet, welches Framework für die entwickelte App besser geeignet war. Um einen repräsentativen Vergleich der beiden Entwicklungsoptionen machen zu können, ist es notwendig, alle Ansichten der involvierten Rollen eines realen Projektes in den Vergleich miteinzubeziehen, hierzu zählen unter anderem der Entwickler oder die Entwicklerin, der User oder die Userin und natürlich auch der Auftraggeber oder die Auftraggeberin. Zu beachten ist allerdings, dass diese Rollen bei diesem Projekt nur virtuell existieren, da alle drei Rollen von der gleichen Person abgedeckt wurden. Im Folgenden werden Vergleichsdimensionen, welche verschiedenen Rollen zuordenbar sind, näher beschrieben.

7.1. Einarbeitungsaufwand

In vielen Artikeln wird auf den notwendigen Einarbeitungsaufwand von diversen Frameworks Bezug genommen. Kommt es in dieser Dimension zum Vergleich zwischen React beziehungsweise React Native und Ionic beziehungsweise AngularJS, dann gibt es eine durchgängig gleiche Meinung dazu, welche von Clemmons (2016) ganz gut beschrieben wird: „Angular is Easy. React is Hard.“.

Dies war auch jene Erkenntnis welche bei der Implementierung von der Examize-App gewonnen wurde. Ionic ist wesentlich einfacher zu verstehen, weil es auf Angular basiert und dieses Framework sehr leicht erlernt werden kann. Auch komplexere Applikationen können damit ohne großen Einarbeitungsaufwand sehr schnell und einfach umgesetzt werden.

Der Ansatz von React Native ist ein ganz anderer als man ihn von den meisten Frameworks kennt. Man benötigt sehr viel Zeit um mit dem komponentenartigen Grundaufbau bei der Entwicklung einer realen Anwendung zurechtzukommen, außerdem stößt man bei der Verwendung von JSX immer wieder auf diverse Probleme, da komplexe Strukturen teilweise einen vollkommen anderen Aufbau voraussetzen als man ihn von HTML kennt. Dieser Aufbau in Komponenten bringt aber auch einen Vorteil, nämlich dass React Code sehr einfach lesbar ist, und zwar auch für jene, die noch nie damit entwickelt haben (Anderson, 2016).

Hier gilt noch anzumerken, dass Entwickler und Entwicklerinnen, welche mit der Entwicklung von hybriden Apps beginnen, laut Clemmons (2016), zum Großteil bereits Erfahrung mit Technologien haben, welche vom Ionic Framework genutzt werden oder diesem sehr ähnlich sind. Jedoch hat fast niemand Erfahrung mit Technologien, welche vergleichbar mit dem React Native Framework sind. Hier wäre ein Vergleich oder eine Studie interessant, wie sich der Einarbeitungsaufwand und das Lernverhalten verändern würden, wenn man bei beiden Frameworks wirklich vollkommen ohne Vorwissen beginnen würde.

7.2. Realisierungsaufwand

Die ersten Schritte, welche vor dem Beginn eines Projektes gemacht werden müssen, waren bei beiden Frameworks sehr überschaubar und relativ einfach durchführbar, dazu zählen unter anderem die Installation von allen Abhängigkeiten und den Frameworks selbst. Die Dokumentation für Ionic ist, genau wie jene für React Native, qualitativ hochwertig, vollständig

4. August 2016 Peter Sonnleitner, BSc 64/79

und sehr strukturiert gehalten. Somit ist es möglich, unabhängig von der Entwicklungsplattform, ganz egal ob Windows, Linux oder Mac, sehr schnell eine lauffähige Basisapplikation entwickeln zu können. Hält man sich an die Vorgaben der Dokumentation, sind die ersten Schritte mit beiden Frameworks fehlerfrei durchführbar, stößt man dennoch auf ein Problem, findet man dank der jeweils großen Community sehr schnell die Lösung, ohne dabei selbst nach der Ursache suchen zu müssen.

Bevor mit der eigentlichen Realisierung begonnen wurde, wurden für beide Frameworks alle Abhängigkeiten richtig installiert und das Fundament der Ionic- und React-Native-Applikation, welches bei jeder Anwendung gleich ist, bereits umgesetzt. Außerdem wurden die vielen Tools, welche von beiden Frameworks bereitgestellt werden, wie etwa zum Builden, richtig eingerichtet und auch später bei der Implementierung verwendet. Diese Schritte vereinfachen das Entwickeln mit beiden Frameworks enorm und die Produktivität kann mit diesen Programmen um ein Vielfaches gesteigert werden.

Die Realisierung der Examize-App mit Ionic nahm etwa 60 Stunden Zeit in Anspruch, wogegen die Umsetzung mit React Native etwa 100 Stunden Zeit in Anspruch nahm. Mobile Applikationen können also mit Ionic wesentlich schneller und einfacher entwickelt werden als mit React Native. An dieser Stelle muss noch einmal erwähnt werden, dass das gesamte Basissetup, welches für jede weitere App gleich wäre, plus des Einarbeitungsaufwandes, nicht mitgerechnet wurde. Würde man diese Aufwendungen auch noch mitzählen, wäre der Realisierungsaufwand für die React Native App um etwa 150% höher als jener für die Ionic App.

Die Ressourcen, welche für eine Implementierung mit Ionic oder React Native aufgewendet werden müssen, lassen sich mit jeder weiteren Applikation stark reduzieren. Für die Realisierung mit dem Ionic Framework wurden etwa 80 Stunden Vorarbeit geleistet, hierzu zählen Einarbeitungsschritte in Ionic, Cordova und AngularJS, der Entwurf der Basisapplikation, der Installation von notwendigen und unterstützenden Tools und weitere Schritte wie erste Tests mit dem Framework. Die eigentliche Applikation benötigte wie oben erwähnt 60 Stunden. Das bedeutet konkret, es wurden gesamt 140 Stunden Zeitressourcen für die Examize-App mit Ionic aufgewendet. Jede weitere Anwendung mit ähnlichem Aufwand, könnte durch Erfahrung, das Wegfallen der Vorarbeiten und der Wiederverwendung von Quellcode, innerhalb von 30 bis 40 Stunden entwickelt werden. Ähnlich verhält sich das auch beim React Native Framework, wobei hier alle Zahlen etwas nach oben korrigiert werden müssten.

Die Erkenntnis in der Dimension des Realisierungsaufwandes lautet also, hybride Applikationen lassen sich mit Ionic schneller und einfacher als mit React Native entwickeln, jedoch die Ressourcen welche zur Realisierung einer Anwendung benötigt werden, können durch die Entwicklung von mehreren Applikationen mit demselben Framework sehr stark reduziert werden. Es empfiehlt sich also, bei der Entwicklung von mehreren Applikationen dasselbe Framework zu verwenden, und nicht ständig die Technologie zu wechseln.

7.3. Wartungsaufwand

Unter dem Wartungsaufwand versteht man laut Lehner (2016) in der modernen Softwareentwicklung all jene Tätigkeiten, welche vollzogen werden müssen, um nach der Umsetzung und der Einführung eines Systems die Benutzbarkeit und Verfügbarkeit sicherstellen

4. August 2016 Peter Sonnleitner, BSc 65/79

zu können und die Lebensdauer der Anwendung zu verlängern. Dazu zählen unter anderem die Beseitigung von Fehlern, der Optimierung der Performance und die Erweiterung der Funktionalität. All diese Kriterien verursachen Kosten, Ziel ist es, die laufenden Wartungskosten so gering wie möglich zu halten. (Lehner, 2016)

Applikationen können mit Ionic und React Native sehr modular aufgebaut werden, was sich sehr positiv auf den Wartungsaufwand auswirkt. Ionic besitzt dank dem Grundaufbau auf AngularJS eine gute Trennung von Präsentation und Geschäftslogik und erreicht somit eine direkte Steigerung von Produktivität und Wartbarkeit (Weiße, 2016) & (Gaßmann, 2016). Durch die Auftrennung in verschiedene Controller und Services und der Verwendung von Templates bleibt die Applikation überschaubar und kann sehr leicht erweitert werden.

Bei React Native kommt diese Modularität durch den komponentenartigen Grundaufbau noch stärker zur Geltung. Durch den schichtenartigen Komponentenaufbau können Erweiterungen auch hier sehr leicht durchgeführt werden. Ein weiterer Vorteil ist, dass der Code immer leicht lesbar bleibt, was sich zusätzlich positiv auf die Wartbarkeit auswirkt. (Eisenman, 2015) Wird die Applikation mit den Vorgaben vom jeweiligen Framework aufgebaut, und hält man sich an bewährte Entwurfsmuster, kann man mit React Native und Ionic den Wartungsaufwand sehr gering halten. Aus der Implementierungserfahrung mit den beiden Frameworks konnte bei dieser Dimension keine Erkenntnis gewonnen werden, welche ein Framework klar von dem anderen abheben würde. Dafür müsste man eine komplexere Applikation entwickeln, und an dieser entsprechende Erweiterungen durchführen.

Das Problem bei Systemen mit schlechter Wartbarkeit sind in den meisten Fällen nicht das Framework oder die verwendete Technologie selbst, sondern eher schlechte Codequalität oder allgemeine Entwurfsfehler (Lehner, 2016). Dies bedeutet im Konkreten, das Framework ist in Bezug auf den Wartungsaufwand weit weniger kritisch als es zum Beispiel ein schlecht implementierter Quellcode ist. Deshalb empfiehlt es sich auch, mehr Ressourcen in die Einarbeitungsphase zu stecken, da eine niedrige Codequalität und Entwurfsfehler langfristig viel höhere Kosten verursachen als eine lange Einarbeitungs- und Planungsphase.

7.4. Umsetzbarkeit der Anforderungen

Alle Anforderungen von der mobilen Lernapplikation haben sich mit beiden Frameworks ohne unvorhergesehene Schwierigkeiten umsetzen lassen. Das liegt unter anderem auch daran, dass sich beide Tools mit zahlreichen Plugins leicht erweitern lassen und eine sehr große Community besitzen, wodurch sehr viele zusätzliche Plugins und ähnliches verfügbar sind. Damit lässt sich der grundlegend gebotene Funktionsumfang schnell und einfach nach oben skalieren.

Damit die plattformübergreifende mobile Lernanwendung erstellt werden konnte, galt die Grundvoraussetzung, dass sich die vom Framework erstellte App auf einem echten Android und iOS-Gerät installieren lässt. Dies hat sich, wie erwartet, mit beiden Frameworks sehr einfach umsetzen lassen, da das natürlich ein Schlüsselkriterium für ein gutes hybrides Tool ist. Unter Punkt 6.3. bei den ausgewählten Implementierungsaspekten, wurden für beide Frameworks drei Komponenten der App näher beschrieben, dabei handelt es sich um den Barcode-Scanner, den Swipeable-Cards und den AJAX-Connector. Die Realisierung dieser Aspekte nahm mit dem React Native Framework etwas mehr Zeit in Anspruch und war etwas komplizierter, hat sich aber ansonsten relativ gleichwertig umsetzen lassen. Diese Feststellung

4. August 2016 Peter Sonnleitner, BSc 66/79

war auch bei allen anderen Implementierungsaspekten nachvollziehbar, zum Beispiel bei der Umsetzung der Mehrsprachigkeit der App. Ein Ziel war es, dass die entwickelte App leicht für andere Sprachen erweitert werden kann und die Übersetzungen an einem zentralen Punkt gewartet werden können, oder es einfache Prozesse zum Importieren oder Exportieren eines Sprachpaketes geben soll. Auch für diese Aufgabenstellung stellen beide Frameworks Plugins zur Verfügung, welche leicht installiert werden können, und diese Aufgaben genau der Zielsetzung entsprechend erfüllen. Die Anforderungen, welche diese mobilen Lernapplikation an die Frameworks gestellt hat, waren sicherlich weit unter den Komplexitätsgrenzen des jeweiligen Tools. Mit entsprechenden Plugins lassen sich auch viel schwierigere Anforderungen relativ einfach lösen, allgemein kann aber festgehalten werden, dass mit dem React Native Framework immer etwas mehr Zeitressourcen einkalkuliert werden müssen und die Umsetzung etwas komplexer ist.

7.5. Speicherplatznutzung

Laut einer aktuellen Statistik der Statista GmbH haben etwa 20% der Nutzer und Nutzerinnen von Smartphones mehr als 31 Apps auf ihrem Smartphone installiert und Probleme mit zu wenig verfügbaren Speicherplatz (Statista GmbH, 2016). Deshalb ist es besonders wichtig, die Dateigröße von Apps kompakt zu halten, um den Speicherbedarf zu reduzieren. Ein weiteres Argument für den Vorteil einer kleinen Installationsdatei ist, dass eine kleine App weniger Zeit zum Download benötigt und auch bei einer schlechteren Infrastruktur noch geladen werden kann.

Die Ionic-Applikation ist im Grunde nur eine Webseite, welche in einer nativen WebView dargestellt wird. Dabei wird die WebView verwendet, welche bereits im Betriebssystem (Android oder iOS) existiert. Der Speicherplatz der für die Applikation benötigt wird, ist also sehr gering, wobei einen Großteil der Paketgröße die Grafik-Ressourcen und das Cordova-Framework selbst ausmachen. Anders bei React Native, wo eine Brücke zwischen JavaScript und den nativen Komponenten erstellt muss, welche eine viel komplexere Architektur voraussetzt. Zusätzlich ist die React Native Libary um einiges größer als jene von Ionic.

Der nachfolgende Vergleich der Speicherplatznutzung der Examize-App wurde für die Android- Applikation gemacht. Laut der offiziellen Ionic und React Native Dokumentation liegen die Zahlen für iOS in einem vergleichbaren Bereich. In beiden Projektordnern befanden sich die exakt gleichen Grafikressourcen, diese können also für den Vergleich außer Betracht gezogen werden. Die Größe vom selbst implementierten Quellcode kann ebenso vernachlässigt werden, da dieser weniger als 0,1% der Dateigröße von der gesamten generierten APK-Datei beinhaltet. In den folgenden zwei Abbildungen sind die Dateigrößen zu erkennen:

Name Typ Größe android-debug.apk APK-Datei 4 075 KB android-debug-unaligned.apk APK-Datei 4 074 KB android-release.apk APK-Datei 3 938 KB android-release-unaligned.apk APK-Datei 3 938 KB

Abbildung 18: Auflistung der Build-Dateien (Android) von Ionic

4. August 2016 Peter Sonnleitner, BSc 67/79

Name Typ Größe app-debug.apk APK-Datei 9 469 KB app-debug-unaligned.apk APK-Datei 9 468 KB app-release.apk APK-Datei 9 631 KB app-release-unaligned.apk APK-Datei 9 631 KB Abbildung 19: Auflistung der Build-Dateien (Android) von React Native

Die Applikation ist mit React Native mehr als doppelt so groß wie mit Ionic. Auch wenn beide mit einer Datengröße von unter 10 Megabyte sehr kompakt sind, so ist dies ein dennoch nicht zu vernachlässigender Faktor. Die Speicherplatznutzung nach der Installation auf einem Android- Gerät ist für beide Applikationen im selben Verhältnis verteilt, wobei diese etwa das Doppelte der Installationsdatei ausmacht.

7.6. Arbeitsspeichernutzung

Die Arbeitsspeichernutzung wurde, ebenso wie die Speicherplatznutzung, auf einem Android- Gerät untersucht. Dafür wurde das ADB-Tool (Android Debug Bridge) verwendet, dabei handelt es sich um ein Entwicklertool für Android. Die Arbeitsspeichernutzung ist gerade für ältere oder technische schwache Android-Geräte relevant, da diese meistens nur über einen kleinen RAM verfügen, und dieser sorgfältig befüllt werden muss. Nur so kann gewährleistet werden, dass eine App auf allen Geräten flüssig läuft, da es beim Überlaufen vom RAM zu einem starken Performanceeinbruch kommt.

Für den Vergleich wurde die Ionic und React Native App gestartet und dann der folgende Kommandozeilenausdruck durchgeführt. > adb shell dumpsys meminfo

Dieses Kommando gibt alle Memory-Informationen der geöffneten Apps aus. Die Examize-App vom Ionic Framework benötigt etwa 85 Megabyte Arbeitsspeicher, wogegen die React Native App nur 50 Megabyte verbraucht. Daraus lässt sich schließen, dass die React Native App die Systemressourcen effektiver nutzt. Der Hauptgrund für die große Arbeitsspeichernutzung von der Ionic-App liegt an der WebView, diese benötigt für die Anzeige sehr viele Ressourcen, da für das Interpretieren vom HTML-Code und der Darstellung im Browser viel mehr Kapazitäten benötigt werden, als für die native Darstellung von Komponenten.

7.7. Automatisierbarkeit (Build-Vorgang)

Unter einem Build-Vorgang wird laut Breu & Matzner (2005) jener Vorgang bezeichnet, welcher ein fertiges Anwendungsprogramm erstellt. Dieser Prozess sollte soweit automatisiert sein, dass mit dem Starten dieses Vorganges automatisch eine lauffähige Version eines Programmes erstellt wird.

In der Kommandozeilenumgebung für Ionic ist bereits ein Build-Tool integriert, welches eine fertige Applikation für alle Plattformen bauen kann. Hier können verschiedene Tasks wie das generieren vom Icon und Splashscreen für alle Auflösungen, das Signieren und Komprimieren der fertigen Applikation und viele weitere Prozesse inkludiert werden. Außerdem verwendet Ionic, wie unter Punkt 6.3.1.4.a bereits erwähnt, das JavaScript-Build-System Gulp. Damit lassen sich Schritte wie das Zusammenführen und Komprimieren von JavaScript- und CSS-

4. August 2016 Peter Sonnleitner, BSc 68/79

Files, das Kompilieren von Sass-Dateien und ähnliches automatisieren. Das Ionic Framework hat diese Tools bereits standardmäßig vorkonfiguriert, es müssen also wenig Vorarbeiten geleistet werden um den Build-Prozess zu vereinfachen.

Bei React Native ist deutlich weniger vorkonfiguriert. Es existieren zwar Build-Prozesse, jedoch lassen sich diese nicht plattformübergreifend konfigurieren, so muss für den Android-Build etwa von Gradle Gebrauch gemacht werden. Außerdem sind nur die Basisprozesse eingebunden welche notwendig sind um eine APK zu generieren, alle anderen Schritte müssen aber manuell definiert werden. Die Automatisierbarkeit vom Build-Vorgang kann aber auch bei React Native auf das gleiche Level gehoben werden wie es auch bei Ionic der Fall ist, jedoch ist hier deutlich mehr Aufwand notwendig, was gerade bei kleinen Projekten problematisch ist.

Die Dauer vom Build-Vorgang ist ein eher unwichtiger Aspekt, weil dieser nur zum Erstellen einer fertigen APK-Datei ausgeführt wird. Für das Debuggen oder Testen ist dieser Schritt nicht zwingend notwendig. Unter Ionic dauert der Build-Prozess, wie in Abbildung 20 ersichtlich, etwa 30 bis 40 Sekunden, und ist damit viel schneller als bei React Native, wo er etwa 2 Minuten benötigt. Dieser Unterschied kommt unter anderem dadurch zustande, weil das React Native Framework viel mehr Arbeit für das Generieren der APK-Datei leisten muss. Bei der Ionic Anwendung hingegen, muss nur der Web-to-Native-Wrapper, welcher die WebView einbindet, generiert werden.

C:\projects\ionic\Examize>ionic build android –-release BUILD SUCCESSFUL Total time: 33.523 secs Abbildung 20: Build-Vorgang einer APK (release) mit Ionic

C:\projects\reactnative\ExamizeApp>gradlew assembleRelease BUILD SUCCESSFUL Total time: 1 mins 51.636 secs Abbildung 21: Build-Vorgang einer APK (release) mit React Native

Im direkten Vergleich kann mit Ionic der Build-Vorgang wesentlich schneller abgeschlossen werden. Die Zeiten variieren teilweise von Build zu Build, im Durchschnitt benötigt Ionic aber nur etwa ein Viertel der Zeit von React Native für diesen Vorgang.

7.8. User Experience und Performance

Eine Performancekennzahl, welche repräsentativ und leicht zu ermitteln ist, ist jene, welche das Starten der App abbildet. Der Sieger in dieser Dimension lautet ganz klar React Native. Beide Apps wurden auf einem Nexus 5x und einem Samsung Galaxy S5 zehn Mal gestartet, die Zeit wurde gestoppt und es wurde ein Durchschnittswert ermittelt. Die Zeiten zwischen den einzelnen Durchgängen waren sehr konstant und haben nur um einige Millisekunden variiert. Der Startvorgang von der React Native App dauerte im Durchschnitt 1,3 Sekunden, die Ionic App benötigte im Durchschnitt 3,2 Sekunden bis sie fertig geladen war. Das ist ein enormer Unterschied, und man merkt hier einfach das native Verhalten der React Native App und den langsamen Ladevorgang der WebView von der Cordova Applikation.

4. August 2016 Peter Sonnleitner, BSc 69/79

Weitere Performancevergleiche wurden beim allgemeinen Benutzen der App aufgestellt. Generell ist der Ablauf in der React Native App um einiges flüssiger und performanter, es gibt hier im Menü bei der Navigation absolut kein Ruckeln und auch das Wischen beim Beantworten der Fragen läuft vollkommen flüssig ab. Die Applikation wirkt vom Aussehen und vom Verhalten sehr nativ, was daran liegt, dass die Applikation ein natives UI besitzt und nur die Applikationslogik in JavaScript gehalten ist. Hier kann die Ionic App nicht mithalten, beim direkten Vergleich merkt man teils starke Performance-Unterschiede und die generelle User- Experience ist schlechter. Die WebView von Android und iOS hat sich in den letzten Jahren stark verbessert, jedoch kann die Performance noch nicht mit der nativen Darstellung mithalten, wobei die Unterschiede aber immer geringer werden. Die User Experience und Performance der Ionic Applikation liegt definitiv in einem akzeptablen Rahmen, den Unterschied merkt man wirklich erst im direkten Vergleich. Wer eine qualitativ hochwertige Applikation entwickeln will, sollte also lieber zu React Native greifen und kein Framework verwenden, welches die Applikation nur im Browser in einer WebView darstellt.

7.9. Testbarkeit und Qualitätssicherung

Unter Testbarkeit wird im Grunde verstanden, inwiefern ein Software-System oder dergleichen einen definierten Testkontext unterstützt. Dabei handelt es sich um keine intrinsische Eigenschaft, welche direkt gemessen werden kann, wie etwa die Anzahl der Code-Zeilen, sondern um eine extrinsische, also einer nicht direkt messbaren Eigenschaft. Je höher die Testbarkeit ist, desto geringer ist der Testaufwand (Schmitz, Bons, & van Megen, 2012). Da es sich bei diesem Vergleich in der modernen Softwareentwicklung um einen sehr relevanten und wichtigen Prozess handelt, wurden hier die möglichen Methoden genauer beschrieben.

Bei Ionic gibt es einige Wege eine Applikation zu testen, diese gliedern sich in manuelle und automatisierte Tests, wobei für die Qualitätssicherung eher die automatisierten von Bedeutung sind. Manuelles Testen kann direkt im Browser, auf einem Computer oder mobilen Gerät, erfolgen. Dafür kann die Index-Datei in einem beliebigen modernen Webbrowser geöffnet werden, die Applikation startet danach und die Testfälle können abgearbeitet werden. Die App kann aber auch im Simulator geöffnet werden oder auf einem echten Gerät installiert werden, auch hier können die manuellen Testfälle abgearbeitet werden.

Wesentlich interessanter als die manuellen Testfälle sind aber die automatisierten Tests. Auch hier gibt es für Ionic verschiedene Möglichkeiten, wobei die interessantesten Optionen im Folgenden näher erläutert werden.

 Unit-Tests Unit-Tests werden in der Softwareentwicklung dafür verwendet, um kleine Module einer Software zu testen. Der Hauptvorteil davon ist, dass diese sehr schnell und zuverlässig sind, weil sie immer nur kleine Teile vom Code testen und wenig externe Abhängigkeiten besitzen. Unit-Tests können für Ionic mit dem JavaScript-Testrunner-Karma umgesetzt werden. Einzelne Testfälle können sehr einfach erstellt werden und zum Gulp-Task hinzugefügt werden, somit werden sie bei jedem Build-Vorgang automatisch ausgeführt. (Biharisingh, 2016)

 Integrationstests Integrationstests eignen sich unter anderem dafür, um individuelle Einheiten einer Software, welche mit anderen Komponenten kommunizieren sollen, zu testen, und somit sicherzustellen,

4. August 2016 Peter Sonnleitner, BSc 70/79

dass diese wie erwartet funktionieren. Diese sind langsamer als Unit-Tests und aufgrund zahlreicher externer Abhängigkeiten auch nur bedingt zuverlässig durchführbar. Für Ionic können Integrationstests mit dem Capybara-Framework sehr einfach erstellt werden. (Biharisingh, 2016)

 UI Tests / End-To-End Tests Bei einem End-To-End-Test werden alle Komponenten eines Systems gemeinsam getestet, also der eigentliche Hauptanwendungsfall inklusive Datenbank und sonstiger Infrastruktur mit dem User-Interface. Auch diese können für das Ionic Framework mit Hilfe von Jasmine und Protractor sehr einfach erstellt werden. (Biharisingh, 2016)

Kurz zusammengefasst lassen sich also die Testfälle für eine Applikation basierend auf dem Ionic Framework sehr gut automatisieren.

Auch React Native stellt eine sehr gute Testumgebung für automatisiertes und manuelles Testen zur Verfügung. Wenn im Quellcode kleine Änderungen gemacht wurden, muss die App nicht neu kompiliert und gestartet werden, sondern die Änderungen werden direkt in der geöffneten Applikation durchgeführt. Dies erspart beim Testen extrem viel Zeit, da man so die App sehr einfach und in regelmäßigen Abständen debuggen und testen kann. Mit den Chrome Developer Tools kann vom Browser am Computer direkt auf die App, welche am Smartphone läuft, zugegriffen werden, es werden hier also die gesamten Vorteile schlagend, welche man von der Webentwicklung bereits kennt.

Aber wie auch bei Ionic sind die manuellen Tests eher uninteressant, da diese sowieso vom Entwickler- und Testteam durchgeführt werden müssen. Für automatisierte Tests gibt es für React Native verschiedene Möglichkeiten, wobei die interessantesten im Folgenden näher erläutert werden.

 Unit-Tests React Native verwendet das Build-Tool „Buck“ zum Ausführen von Unit-Tests, diese Tests werden lokal auf der Entwicklungsumgebung ausgeführt, dafür wird kein Emulator oder ein echtes Gerät benötigt. Unit-Tests können wie auch für Ionic sehr einfach erstellt werden.

 Integrationstests Wie auch bei den Unit-Tests, wird „Buck“ zum Ausführen von Integrationstests verwendet. Diese können aber nur im Emulator oder am echten Gerät ausgeführt werden und decken dort dann mehrere Komponenten ab, sie prüfen also, ob die Module und Komponenten, sowie auch Kernkomponenten von React Native, so funktionieren wie sie auch sollen.

 Snapshottests (nur iOS) Ein Snapshottest ist im Grunde ein erweiterter Integrationstest, dabei wird eine Komponente gerendert und dieser gerenderte Zustand wird mit einem Referenzbild verglichen (Facebook Inc., 2016). Snapshottests können mit Hilfe von der „FBSnapshotTestCase“-Bibliothek relativ einfach umgesetzt werden, und es kann damit, mit vergleichbar geringem Aufwand, ein komplexer Teil der Applikation getestet werden. Die Referenzbilder werden automatisch beim erstmaligen Ausführen vom Test generiert, müssen dann aber noch manuell auf Richtigkeit geprüft werden. Die Referenzbilder müssen nicht 1:1 dem gerenderten Abbild entsprechen, erst ab einer gewissen Abweichung wird der Test als fehlgeschlagen markiert.

4. August 2016 Peter Sonnleitner, BSc 71/79

7.10. Fazit

Durch die Entwicklungserfahrung und dem Gewichten aller Vergleichsanalysen kommt man zu dem Schluss, dass das Ionic Framework die bessere Möglichkeit ist, das definierte technische Ziel dieser Arbeit zu erreichen. Auch wenn prinzipiell das Endprodukt mit React Native qualitativ hochwertiger ist, weil die App nativer wirkt und flüssiger läuft, hat die Entwicklung mit Ionic viel weniger Zeitressourcen beansprucht und war viel einfacher. Zusätzlich ist der Grad der Plattformunabhängigkeit durch die Webtechnologien viel höher, diese Faktoren sind für das Erreichen der Zielsetzung stärker zu gewichten als der geringe Qualitätsunterschied. Ionic Apps können prinzipiell auf jedem Gerät ausgeführt werden, welches einen Browser unterstützt. Also theoretisch auch auf einem Fernseher und dergleichen, auch wenn es zu Funktionseinbußen kommen kann. Somit kann uneingeschränkter Zugriff auf die Lernapp gewährleistet werden. Wird an eine Applikation die Anforderung gestellt, eine optimale Performance und absolut natives Verhalten zu bieten, geht die Entscheidung zu React Native. Sollte eine Applikation möglichst einfach und schnell entwickelt werden, geht die Wahl zu Ionic. Die Auswahlkriterien umfassen somit hauptsächlich Faktoren wie verfügbare Zeit und Budget. Das Hauptziel dieser Arbeit war es, festzustellen, mit welchen mobilen Technologien solche plattformübergreifenden mobilen Lernapplikation am einfachsten und effizientesten entwickelt werden können. Und dieses Ziel konnte definitiv mit dem Ionic Framework zufriedenstellender erreicht werden. Mit React ist es einfacher, große Projekte und Teams zu managen, weil strengere Paradigmen und Designrichtlinien vorgegeben werden. Entwickler und Entwicklerinnen sind dadurch bei der Entwicklung eingeschränkter und müssen sich an die Vorgabe halten. Somit kann man die Arbeiten viel leichter in Teams aufteilen und trotzdem einen qualitativ gleichwertigen Quellcode entwickeln. Ganz anders bei Ionic, hier hat man die gewohnte Freiheit der HTML- und JavaScript-Entwicklung. Es gibt wenig bis keine Richtlinien, was in Teams auch zu sehr unterschiedlichen Implementierungsansätzen führen kann. Der Umgang mit dem Ionic Framework lässt sich sehr einfach erlernen und es ist prinzipiell sehr einfach, außerdem ist der Code auch bei komplexeren Features zum Großteil plattformunabhängig. Bei React Native kann man von diesem Vorteil nur bedingt Gebrauch machen, was sich auch bereits aus dem Motto von Facebook „learn once, write anywhere.“ ableiten lässt. Das bedeutet konkret, dass eine einfache Applikation, wie die mobile Lernanwendung, plattformunabhängig mit demselben Code entwickelt werden kann, es jedoch bei komplexeren und erweiterten Features zu Unterscheidungen zwischen der Android- und iOS-Entwicklung kommen kann. Bei komplexeren Projekten gibt es also auch unterschiedliche Quellcodes, was sich in weiterer Folge sehr stark auf den Realisierungsaufwand niederschlägt. Bei Ionic laufen die Applikationen in einer einfachen WebView. Das ist in der heutigen Zeit kein wirkliches Problem mehr, weil die Rendering-Engines auf modernen Smartphones schon sehr gut funktionieren, jedoch ist der Unterschied immer noch spürbar. Man kann allerdings davon ausgehen, dass dieser Unterschied von Jahr zu Jahr irrelevanter wird. Es ist also nur eine Frage der Zeit, bis man dieses Argument völlig vernachlässigen kann. Derzeit ist performancemäßig aber definitiv React Native zu empfehlen, weil dieses Framework einen anderen Ansatz verfolgt. Die Applikationslogik basiert auf JavaScript, die gerenderten UI-Komponenten sind aber vollkommen nativ. Das Problem bei Cordova Apps ist nicht die langsame Logik, sondern die Darstellung in der langsamen WebView. Man benötigt also mehr Einarbeitungs- und Realisierungsaufwand mit React Native, aber die Qualität von der entwickelten App ist ganz einfach höher, sie lässt sich folglich schneller und performanter ausführen. Ionic wird für kleinere Projekte empfohlen, für Kunden mit geringerem Budget und für Apps bei welchen Performance keine Rolle spielt. React Native empfiehlt sich mehr für Apps, bei welchen Performance ein Schlüsselkriterium ist oder das Budget höher ist.

4. August 2016 Peter Sonnleitner, BSc 72/79

8. Zusammenfassung und Ausblick

In diesem Kapitel wird die vorgestellte Arbeit kurz zusammengefasst und es werden im Anschluss noch offene Punkte für weitere Arbeiten vorgestellt.

8.1. Zusammenfassung

Ziel dieser Arbeit war es, ein Mobile Learning System zu entwerfen, welches Mobile Learning, Gamification und Microlearning miteinander verbindet und sehr einfach verwendet werden kann. Dieser Entwurf sollte im Anschluss mit Hilfe von hybriden Technologien umgesetzt und implementiert werden. Dafür sollte ein Framework mit sehr hohem Zukunftspotential verwendet werden.

Es wurden die theoretischen Hintergründe zu Mobile Learning, Gamification und Microlearning erläutert, welche bekannt sein müssen, damit eine sinnvolle mobile Lernanwendung entworfen werden kann. Auf Basis dieser Grundlagen wurde ein Lernsystem spezifiziert, welches den Namen „Examize Mobile Learning System“ trägt und aus einer mobilen Applikation und einer begleitenden Online-Plattform besteht.

Hauptziel dieser Arbeit war es, dieses System mit einem mobilen Framework zu implementieren. Dazu wurden die technischen Grundlagen erläutert, welche benötigt werden, damit der Entwurf umgesetzt werden kann. Auf Basis von diesen Grundlagen wurden hybride Frameworks ausgewählt, welchen starkes Zukunftspotential zugesprochen wird und diese anschließend gegenübergestellt. Dazu wurden die Grundlagen zu Ionic und React Native erläutert und die Grundarchitektur von diesen Frameworks beschrieben.

Das entworfene System wurde in weiterer Folge umgesetzt und implementiert. Die Online- Plattform wurde mit bewährten Technologien entwickelt, die mobilen Lernapplikationen wurden mit dem Ionic und React Native Framework implementiert.

Nach der Implementierung wurden diverse Vergleichsanalysen zwischen Ionic und React Native aufgestellt, in welchen die beiden Frameworks in verschiedenen Dimensionen gegenübergestellt wurden. Dabei kristallisierte sich heraus, dass sich beide Frameworks für die Umsetzung einer mobilen Lernanwendung sehr gut eignen, aber das Ionic Framework besser geeignet ist, weil Apps damit einfacher und schneller implementiert werden können, und Lernanwendungen typischerweise nicht wirklich unter der schwachen Performance der WebView leiden.

Mobile Learning Applikationen können mit hybriden Frameworks einfach, sinnvoll und effizient umgesetzt werden. Es gibt keine wirklichen Nachteile gegenüber einer nativen Applikation, weil typische Lernanwendungen nicht sehr anspruchsvolle grafische Darstellungen benötigen und typischerweise einfach gehaltene Applikationslogik besitzen. Anders wäre das bei Spielen und dergleichen, wo die Wahl wohl immer auf eine richtig native Anwendung fallen würde. In weiterer Folge wird es wohl immer native Applikationen geben, da diese für manche Anforderungen unerlässlich sind, wie etwa für komplexe 3D-Spiele. Doch die Verbreitung von hybriden Apps hat in den letzten Jahren stark zugenommen und in Zukunft werden sie sehr wahrscheinlich einen noch größeren Marktanteil einnehmen.

4. August 2016 Peter Sonnleitner, BSc 73/79

8.2. Ausblick

Aufbauend auf dieser Arbeit wären zukünftige Arbeiten in unterschiedlichen Bereichen möglich. Dazu zählen unter anderem die Erweiterung der mobilen Lernanwendung mit weiteren Features, die Erweiterung der mobilen Applikation für weitere Plattformen oder der Implementierung der Grundapplikation mit anderen Frameworks.

Das Mobile-Learning-System „Examize“ ist im Grunde ein überschaubares Projekt, welches die Grundzüge von Mobile Learning mit Hilfe einer Online-Plattform mit einfachen Mitteln auf das Smartphone bringt. Viele Features, welche für mobiles Lernen wünschenswert sein würden, fehlen in dieser Arbeit noch. So könnte der Lernprozess durch diverse Interaktionen zwischen den Lernenden, wie etwa Multiplayer-Funktionalitäten oder einer Social-Media-Einbindung, und weiteren Gamification-Ansätzen, wie etwa Ranglisten und dergleichen, noch viel interessanter und effizienter gestaltet werden. Basierend auf diesem System könnte ein komplexeres Lernsystem entwickelt werden, welches viele weitere Features bietet und damit wirklich in realen Umgebungen, wie etwa Schulen oder Universitäten, Einsatz finden könnte.

Eine andere Idee für eine zukünftige Arbeit wäre es, Analysen in Richtung Erweiterbarkeit für andere Plattformen aufzustellen. Die derzeitige Applikation ist nur für Android und iOS verfügbar. Ein Ziel könnte es sein, sie auch für andere Plattformen, wie etwa Blackberry oder Windows Phone, verfügbar zu machen. Hierdurch könnten interessante Erkenntnisse gewonnen werden, was es in der Realität bedeuten würde, die Applikation für weitere Plattformen verfügbar zu machen. Technisch gesehen könnte man theoretisch bis hin zur Entwicklung von einem eigenen React Native Renderer oder eigenen Cordova Plugins gehen.

Auch die Weiterentwicklung von React Native und Ionic darf nicht vernachlässigt werden. Ionic 2 ist bereits im Beta Status (Stand Juni 2016). Laut diversen Berichten in der Ionic-Community wurde das Ionic Framework in der zweiten Version stark weiterentwickelt und verbessert, was vor allem auch daran liegt, dass Ionic 2 auf Angular 2 basiert, und dieses Framework auch stark überarbeitet wurde. Nachdem Ionic in der ersten Version schon ein starkes Zugpferd in der mobilen App-Entwicklung ist, wäre eine mögliche zukünftige Untersuchung, eine mobile Lernanwendung mit Ionic 2 umzusetzen, sobald es eine Release-Version davon gibt.

Eine weiterer interessanter Ansatz ist es, React Native mit Angular zu kombinieren. Dazu gibt es einen React Native Renderer für AngularJS, welcher auf der Github-Seite von Angular gehostet ist. Dieser Ansatz vereint die Vorteile der beiden Frameworks, das bedeutet, es wird ein React Native Projekt entwickelt, in welchem eine Angular-Applikation läuft. Dieser Ansatz klingt sehr interessant und es wäre sicherlich möglich, diesen in einer weiteren Arbeit detaillierter zu behandeln.

Wie man bei diesen Punkten erkennen kann, gibt es in diesem Sektor in Zukunft sicherlich noch mehr als genug zu tun. Bei der Anzahl an mobilen Frameworks die jedes Jahr vorgestellt werden, wird einem bei derartigen Arbeiten nicht so schnell langweilig werden. Theoretisch ist es auch möglich, dass in naher Zukunft eine komplett neue Technologie erscheint, welche bisherige hybride Ansätze in den Schatten stellt. Wer sich mit diesem Themengebiet auseinandersetzen will, sollte sich ständig einen Überblick über aktuelle Technologien verschaffen. Das Thema rund um die hybride App-Entwicklung wird sicherlich noch lange interessant bleiben und einen immer wichtigeren Stellenwert einnehmen.

4. August 2016 Peter Sonnleitner, BSc 74/79

9. Abbildungsverzeichnis

Abbildung 1: Mobile Learning (blau) und E-Learning (rot) in Google Trends ...... 13 Abbildung 2: Sinnvolle Lernformen vom Mobile Learning (Kuszpa & Scherm , 2010) ...... 14 Abbildung 3: Entwurf vom Splashscreen und vom Menü in der Examize-App ...... 16 Abbildung 4: Entwurf der Kursübersicht und der Modulübersicht der Examize-App ...... 17 Abbildung 5: Entwurf der Darstellung einer Wahr-/Falsch-Aussage in der Examize-App ...... 18 Abbildung 6: Entwurf der Kursübersicht auf der Examize-Plattform ...... 19 Abbildung 7: Entwurf der Zugangsschlüsselübersicht auf der Examize-Plattform ...... 20 Abbildung 8: Entwurf der Darstellung eines Kursinhaltes auf der Examize-Plattform ...... 20 Abbildung 9: Entwurf vom Wahr-/Falsch-Aussage-Editor auf der Examize-Plattform ...... 21 Abbildung 10: Grundlegende Architektur verschiedener App-Typen ...... 23 Abbildung 11: Marktabdeckung der mobilen Betriebssysteme in 2016. (Quelle: statista.com) ...26 Abbildung 12: Gegenüberstellung der Frameworks in Google Trends (Top 5) ...... 32 Abbildung 13: Grundlegende Architektur vom Ionic Framework ...... 34 Abbildung 14: Grundlegende Architektur vom React Native Framework ...... 37 Abbildung 15: Grundarchitektur vom Mobile-Learning-System „Examize“ ...... 41 Abbildung 16: Datenbankschema in UML modelliert ...... 43 Abbildung 17: JSON-Response von der REST-API ...... 45 Abbildung 18: Auflistung der Build-Dateien (Android) von Ionic ...... 67 Abbildung 19: Auflistung der Build-Dateien (Android) von React Native ...... 68 Abbildung 20: Build-Vorgang einer APK (release) mit Ionic...... 69 Abbildung 21: Build-Vorgang einer APK (release) mit React Native ...... 69

10. Tabellenverzeichnis

Tabelle 1: Gegenüberstellung verschiedener Entwicklungsoptionen ...... 25 Tabelle 2: Bewertung der Auswahlkriterien von den verschiedenen Frameworks ...... 32

11. Code-Ausschnitte

Code-Ausschnitt 1: Beispielhafte Verwendung von einer AngularJS-Listen-Direktive ...... 35 Code-Ausschnitt 2: Interpolation in AngularJS ...... 35 Code-Ausschnitt 3: „MenuButton“-Komponente in React Native ...... 38 Code-Ausschnitt 4: Beispielhafter JSX-Code ...... 39 Code-Ausschnitt 5: Codeausschnitt einer React-Applikation ...... 40 Code-Ausschnitt 6: Silex GET-Route zum Aufrufen der Kursliste ...... 45 Code-Ausschnitt 7: HTML-Grundgerüst der Basisapplikation mit Ionic ...... 47 Code-Ausschnitt 8: Moduldefinition vom „examizeModule“ mit AngularJS ...... 47 Code-Ausschnitt 9: Konfiguration vom „StateProvider“ mit Ionic ...... 48 Code-Ausschnitt 10: Inhalt vom Body der Ionic Basisapplikation ...... 48 Code-Ausschnitt 11: Definition vom „Menu“-Controller mit Ionic ...... 48 Code-Ausschnitt 12: Template für das Menü in der Ionic Basisapplikation ...... 48 Code-Ausschnitt 13: Definition vom „ajaxService“ mit Ionic...... 49 Code-Ausschnitt 14: „getAllCourses“-Funktion vom „ajaxService“ ...... 49 Code-Ausschnitt 15: „postStatistics“-Funktion vom „ajaxService“...... 50 Code-Ausschnitt 16: Verwendung vom „ajaxService“ in einem fremden Controller ...... 50

4. August 2016 Peter Sonnleitner, BSc 75/79

Code-Ausschnitt 17: Einfügen einer Modulabhängigkeit in Ionic ...... 51 Code-Ausschnitt 18: AngularJS-Direktive zum Darstellen der Swipeable-Cards ...... 51 Code-Ausschnitt 19: Verwendung der „SwipeableCards“ in einem Controller ...... 51 Code-Ausschnitt 20: „barcodeScanner“-Service in der Examize-App ...... 52 Code-Ausschnitt 21: Hinzufügen eines Buttons zum Menü ...... 52 Code-Ausschnitt 22: Verwendung vom „barcodeScanner“-Service in einer Funktion ...... 52 Code-Ausschnitt 23: Die benötigten Gulp-Plugins werden eingebunden ...... 53 Code-Ausschnitt 24: Definition der Pfade von den JavaScript- und Sass-Dateien ...... 53 Code-Ausschnitt 25: Gulp-Task welcher einige Aktionen mit Sass-Files durchführt ...... 54 Code-Ausschnitt 26: „package.json“ für die Ionic App ...... 54 Code-Ausschnitt 27: Aktivierung vom „Strengen Modus" in React Native ...... 56 Code-Ausschnitt 28: React Native Basismodul wird eingebunden ...... 56 Code-Ausschnitt 29: Style-Definition in React Native ...... 56 Code-Ausschnitt 30: „ExamizeApp“-Komponente in React Native ...... 57 Code-Ausschnitt 31: Einstiegspunkt der React Native Applikation wird definiert ...... 57 Code-Ausschnitt 32: Vereinfachter Javascript- und HTML-Code (JSX) ...... 57 Code-Ausschnitt 33: Aufbau eines GET-Fetch-Requests in React Native ...... 58 Code-Ausschnitt 34: Aufbau eines POST-Fetch-Requests in React Native ...... 58 Code-Ausschnitt 35: Render-Methode für die Ausgabe eines Buttons ...... 59 Code-Ausschnitt 36: Import vom „SwipeableCards“-Modul in React Native ...... 59 Code-Ausschnitt 37: Grundinhalt von der Swipeable-Cards-Komponente...... 59 Code-Ausschnitt 38: Statische Deklaration von der „Cards“-Variable ...... 59 Code-Ausschnitt 39: Funktonsaufbau von der „SwipeableCards"-Komponente ...... 60 Code-Ausschnitt 40: Definition eines Styles in React Native ...... 60 Code-Ausschnitt 41: Verwendung der „SwipeableCards“-Komponente ...... 60 Code-Ausschnitt 42: Import vom „BarcodeScanner“-Modul in React Native ...... 61 Code-Ausschnitt 43: Grundinhalt von der Barcode-Scanner-Komponente ...... 61 Code-Ausschnitt 44: Initialisierung vom Grundzustand in React Native ...... 61 Code-Ausschnitt 45: „onQrCodeDetected“-Funktion in React Native ...... 61 Code-Ausschnitt 46: „renderScanner“-Funktion in React Native ...... 62 Code-Ausschnitt 47: Rendern vom Barcode-Scanner ...... 62 Code-Ausschnitt 48: Inhalt von der „gradle.properties"-Datei ...... 63 Code-Ausschnitt 49: Konfiguration zum Signieren einer APK-Datei in Gradle ...... 63

4. August 2016 Peter Sonnleitner, BSc 76/79

12. Literatur- und Quellverzeichnis

Adobe Systems Inc. (Aufgerufen am 1. April 2016). PhoneGap what’s in a name. Von http://phonegap.com/2012/03/19/phonegap-cordova-and-what%E2%80%99s-in-a-name/ abgerufen Agrawal, H. (Aufgerufen am 5. Juni 2016). Comparison Of Top Mobile OS. Von http://www.shoutmeloud.com/top-mobile-os-overview.html abgerufen Allen, S., Graupera, V., & Lundrigan, L. (2010). Pro smartphone cross-platform development: iPhone, blackberry, windows mobile and android development and distribution. Apress. Anderson, C. (Aufgerufen am 4. Juni 2016). Smashingmagazine. Von https://www.smashingmagazine.com/2016/04/consider-react-native-mobile-app/ abgerufen Appcelerator Inc. (Aufgerufen am 20. Juni 2016). Appcelerator. Von http://www.appcelerator.com/ abgerufen Arora, S. (Aufgerufen am 16. Februar 2016). 10 Best Hybrid Mobile App UI Frameworks: HTML5, CSS and JS. Von http://noeticforce.com/best-hybrid-mobile-app-ui-frameworks- html5-js-css abgerufen Banerjee, S. (Aufgerufen am 16. Februar 2016). 10 Best Frameworks for Creating Hybrid Mobile Apps. Von http://www.rswebsols.com/tutorials/software-tutorials/10-best-frameworks- creating-hybrid-mobile-apps abgerufen Baumgartner, P. (2013). Microlearning--Vier didaktische Herausforderungen. Gedankensplitter. Beutner, M., & Pechuel, R. (2014). Acceptance, Chances, and Problems of Mobile Learning in Vocational Education in Enterprises. Biharisingh, A. (Aufgerufen am 15. Februar 2016). How To Write Automated Tests For Your Ionic App. Von http://gonehybrid.com/how-to-write-automated-tests-for-your-ionic-app- part-1/ abgerufen Biswanger, G. (Aufgerufen am 20. Juni 2016). Cross-Plattform-Entwicklung mit HTML5 und JavaScript. Von https://entwickler.de/online/mobile/cross-plattform-entwicklung-mit- html5-und-javascript-163374.html abgerufen Blümlein, A. (2013). Von den technischen Grundlagen über die Vermarktung bis zur öffentlichen Wahrnehmung. Hamburg: Diplomica Verlag GmbH. Braun, H. (Aufgerufen am 20. Juni 2016). Facebooks JavaScript-Bibliothek React für datenlastige Websites. Von http://www.heise.de/ct/ausgabe/2016-2-Facebooks- JavaScript-Bibliothek-React-fuer-datenlastige-Websites-3057813.html abgerufen Bray, T., & Holmes, E. (2015). Getting Started with React Native. Packt Publishing Ltd. Breu, R., & Matzner, T. (2005). Software-Engineering: Objektorientierte Techniken, Methoden und Prozesse in der Praxis. München: Oldenbourg Verlag. Clemmons, E. (Aufgerufen am 25. Juni 2016). Angular is Easy. React is Hard. Von https://medium.com/@ericclemmons/angular-is-easy-react-is-hard- 6f55e360482c#.7a5s89m7r abgerufen Computer Hope. (Aufgerufen am 23. Mai 2016). Computerhope. Von http://www.computerhope.com/jargon/s/splashsc.htm abgerufen DeNA Co., Ltd. et al. . (Aufgerufen am 28. Mai 2016). JSX. Von https://jsx.github.io/ abgerufen Ecma International. (Aufgerufen am 1. Mai 2016). ECMAScript. Von http://www.ecmascript.org abgerufen Eisenman, B. (2015). Learning React Native: Building Native Mobile Apps with JavaScript. USA: O'Reilly Media Inc.

4. August 2016 Peter Sonnleitner, BSc 77/79

Facebook Inc. (Aufgerufen am 9. Mai 2016). React Native. Von http://www.reactnative.com abgerufen Falk, M. (Aufgerufen am 16. Februar 2016). Mobile Frameworks Comparison Chart. Von http://mobile-frameworks-comparison-chart.com/ abgerufen Ferscha, A. (2007). There must be innovation in the learning process - not just technological advances. Mobile Learning. Florence , M., & Jeffrey, E. (2013). Here and now mobile learning: An experimental study on the use of mobile technology. Computers & Education. Gabriel, S. (Aufgerufen am 19. Februar 2016). Gamification: Wie man mit Spieldesign-Prinzipien Schüler motiviert. Von https://www.schule.at/news/detail/gamification-wie-man-mit- spieledesign-prinzipien-schueler-motiviert.html abgerufen Gaßmann, J. (Aufgerufen am 24. April 2016). Ionic – Das neue Frontend-Framework zur Erstellung von Hybrid-Apps. Von http://www.flyacts.com/blog/ionic-das-frontend- framework/ abgerufen Heitkötter, H., & Hanschke, S. (2012). International Conference on Web Information Systems and Technologies. Springer. Hornor, T. (Aufgerufen am 12. Juni 2016). Hybrid-Apps entwickeln leicht gemacht: Top-Tools und Hilfsmittel . Von http://www.drweb.de/magazin/top-tools-und-hilfsmittel-fuer-hybrid- apps-57876/ abgerufen Hornor, T. (Aufgerufen am 29. Juni 2016). Hybrid-Apps entwickeln leicht gemacht: Top-Tools und Hilfsmittel . Von https://www.drweb.de/magazin/top-tools-und-hilfsmittel-fuer-hybrid- apps-57876/ abgerufen Intel Inc. (Aufgerufen am 19. April 2016). Intel® XDK. Von https://software.intel.com/de-de/intel- xdk abgerufen Ionicframework. (Aufgerufen am 13. Februar 2016). Ionicframework. Von http://ionicframework.com/docs/overview/ aufgerufen Ishizaka, A., & Nemery, P. (2013). Multi-criteria decision analysis: methods and software. John Wiley & Sons. Janschitz, M. (Aufgerufen am 16. Februar 2016). Hybride App-Entwicklung: 7,5 Frameworks, die du kennen solltest. Von http://t3n.de/news/hybride-app-entwicklung-frameworks-617199/ abgerufen Kuszpa , M., & Scherm , E. (2010). Mobile Learning - Modetrend oder wesentlicher Bestandteil lebenslangen Lernens? Fernuniverstität Hagen. Lehner, F. (Aufgerufen am 19. Juni 2016). Enzyklopaedie der Wirtschaftsinformatik. Von http://www.enzyklopaedie-der-wirtschaftsinformatik.de/lexikon/is- management/Systementwicklung/Hauptaktivitaten-der-Systementwicklung/Software- Wartung abgerufen Li, S. (Aufgerufen am 1. Februar 2016). React: Create maintainable, high-performance UI components. Von http://www.ibm.com/developerworks/library/wa-react-intro/ abgerufen Markov , D. (Aufgerufen am 16. Februar 2016). Comparing The Top Frameworks For Building Hybrid Mobile Apps. Von http://tutorialzine.com/2015/10/comparing-the-top-frameworks- for-building-hybrid-mobile-apps/ abgerufen Masse, M. (2011). REST API design rulebook. O'Reilly Media, Inc. Mayer, A. (2012). App-Economy: Millardenmarkt Mobile Business. München: Münchner Verlagsgruppe GmbH. Maynard, T. (Aufgerufen am 3. Mai 2016). Getting Started with Gulp. Packt Publishing Ltd. Von http://gulpjs.com/ abgerufen

4. August 2016 Peter Sonnleitner, BSc 78/79

Michaels, ross & cole, ltd. (2013). Native mobile apps: The wrong choice for business? Lombard, IL. Muschko, B. (2014). Gradle in action. Manning. Oracle Corporation and/or its affiliates. (Aufgerufen am 23. März 2016). mysql.com. Von https://www.mysql.com/ abgerufen Parzl, R., & Bannert, M. (2013). Mobile Learning – Begriff, Modelle, Forschung. Patel, S. (2014). Quick Handlebar Templating: JavaScript templating. Sandeep Kumar Patel. Resig, J. (Aufgerufen am 6. Juni 2016). ECMAScript 5 Strict Mode, JSON, and More. Von http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/ abgerufen Schmitz, P., Bons, H., & van Megen, R. (2012). Software-Qualitätssicherung - Testen im Software-Lebenszyklus. Braunschweig/Wiesbaden: Friedr Vieweg & Sohn. SensioLabs Deutschland GmbH. (Aufgerufen am 19. Jänner 2016). A PHP micro-framework standing on the shoulder of giants. Von http://silex.sensiolabs.org/ abgerufen Springer Fachmedien Wiesbaden GmbH. (Aufgerufen am 1. April 2016). Springer Gabler Wirtschaftslexikon . Von http://wirtschaftslexikon.gabler.de/Definition/mobile-learning.html abgerufen Statista GmbH. (Aufgerufen am 15. Juni 2016). Wie viele Apps haben Sie auf Ihrem Smartphone installiert? . Von http://de.statista.com/statistik/daten/studie/162374/umfrage/durchschnittliche-anzahl-von- apps-auf-dem-handy-in-deutschland/ abgerufen Steyer, M., & Softic, V. (2015). AngularJS: Moderne Webanwendungen und Single Page Applications mit JavaScript. O'Reilly. Steyer, R. (2011). jQuery: das JavaScript-Framework f{\"u}r interaktives Design. Pearson Deutschland GmbH. Stiftung Medien in der Bildung (SbR). (Aufgerufen am 10. Juni 2016). Mobile Learning (Mobiles Lernen). Von https://www.e-teaching.org/didaktik/gestaltung/mobilitaet abgerufen Stiftung Medien in der Bildung. (Aufgerufen am 19. Februar 2016). E-Teaching. Von https://www.e-teaching.org/projekt/nachhaltigkeit/plattform abgerufen The Apache Software Foundation. (Aufgerufen am 14. Juni 2016). apache.org. Von https://httpd.apache.org/ abgerufen The PHP Group. (Aufgerufen am 30. März 2016). PHP.net. Von http://php.net/manual/de/intro- whatis.php abgerufen TheiPhoneAppReview. (Aufgerufen am 16. Februar 2016). Top Hybrid Mobile App Development Frameworks for 2016. Von http://www.theiphoneappreview.com/2016/01/top-hybrid- mobile-app-development-frameworks-for-2016/ abgerufen Tilkov, S., & Vinoski, S. (2010). Node. js: Using JavaScript to build high-performance network programs. IEEE Internet Computing. Tröger, T. (Aufgerufen am 20. Juni 2016). Gamification: Spannung, Spiel und Arbeit. Von https://www.symeda.de/das-leben-ist-ein-grosses-spiel/ abgerufen Twitter Inc. (Aufgerufen am 19. Jänner 2016). Bootsrap. Von http://getbootstrap.com/ abgerufen VisionMobile Ltd. (Aufgerufen am 30. Mai 2016). Cross-Platform Developer Tools 2012. Von http://www.visionmobile.com/product/cross-platform-developer-tools-2012/ abgerufen Walsdorf, J. (2014). M-Learning: Lernen im mobilen Kontext an Hochschulen. Weiße, B. (2016). AngularJS & Ionic Framework: Hybride App-Entwicklung mit JavaScript und HTML5. Carl Hanser Verlag GmbH & Co. KG. Witt, C., & Sieber, A. (2013). Vom E-Learning zum Mobile Learning - wie Smartphones und Tablet PCs Lernen und Arbeit verbinden. Springer Verlag.

4. August 2016 Peter Sonnleitner, BSc 79/79