Prototypische GUI-Implementierung einer Cross-Plattform-App

Inhaltsverzeichnis

Abkurzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

2 Grundlagen
2.1 Mobile Endgerate
2.2 iOS vs. Android
2.3 Vorgehensmodelle
2.4 App-Typen

3 Entwicklung eines Prototyps
3.1 Analyse und Planungsphase
3.1.1 Relevanz und Zielsetzung
3.1.2 Anforderungen an den Prototypen
3.1.3 Auswahl eines Vorgehensmodells
3.1.4 Festlegung der Entwicklungsinfrastruktur
3.2 Konzept
3.3 Implementierung und Test
3.4 Ergebnis

4 Fazit

Anhang

Literatur- und Quellenverzeichnis

Abkurzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1 - Wasserfallmodell zur Entwicklung der App

Abbildung 2 - Architektur des Frameworks React Native

Abbildung 3 - Darstellung der Secondhand-App mittels eines Wireframes

Abbildung 4 - Startseite und Facebook-Login

Abbildung 5 - Hauptseite

Abbildung 6 - Seite zurSuche von Produkten

Abbildung 7 - Nachrichtendienst

Abbildung 8 - Profilseite - Ubersicht

Abbildung 9 - Profilseite mit weiteren Funktionen

Abbildung 10 - Profilseite mit Bewertungen

Tabellenverzeichnis

Tabelle 1 - Herkommliche Entwicklungsinfrastruktur iOS und Android

Tabelle 2 -Testgerate und Ergebnis

1 Einleitung

Der Einsatz von mobilen Endgeraten wie Smartphones Oder Tablets hat das Denken und Handel der gesamten Welt revolutioniert. Diese Gerate dienen nicht nur als Kommunikationsmedium, sondern unterstutzten z.B. den Alltag in Form einer Navi­gation, dienen als Instrument zur Unterhaltung und zum Austausch von Informatio- nen, konnen beispielsweise aber auch zur Steuerung von heimischen Heizungsan- lagen Oder Sicherheitskameras eingesetzt werden.¹ Das Smartphone ist in der heu- tigen Zeit ein nicht mehr wegzudenkender Bestandteil des Alltags und wird als das personlichste Endgerat angesehen. Dieses Endgerat begleitet den Anwender uber den gesamten Tag hinweg und ist stets griffbereit. Dabei bietet es den Zugriff auf eine Vielzahl von mobilen Applikationen (kurz: App). Eine hohe Prioritat weisen dabei in einer zunehmend vernetzten Welt Messanger-Dienste und soziale Netzwerke auf, die von jedem Standort und zu jeder Zeit eine Kommunikation mit Arbeitskollegen, Freunden Oder Unternehmen ermoglichen. Smartphones und Apps werden nahezu in alien Lebenssituationen eingesetzt, beim Check-in am Flughafen, bei der Bestel- lung eines Taxis Oder beispielsweise beim Buchen eines Zimmers, fur eine Ge- schaftsreise. Mit diesen Beispielen wird verdeutlicht, dass diese Technologien nicht nur unser Internetverhalten geandert haben, sondern auch einen immensen Einfluss auf unser Verhalten im Alltag ausuben.²

Apps haben sich mit der wachsenden Beliebtheit von Smartphones als wichtiger Be­standteil der Software-lndustrie etabliert. Mittlerweile gibt es eine unzahlige Anzahl an Apps die auf dem Markt angeboten werden.³ Ein Entwickler muss zur Entwicklung von Apps mehrere Programmiersprachen kennen, urn diese auf unterschiedlichen Plattformen und Betriebssystemen bereitstellen zu konnen.⁴ Dies stellt Anwen- dungsentwickler in dem stark umkampften Markt, vor verschiedene Herausforderun- gen. Jede Plattform hat seine eigene native Anwendungsentwicklungs-lnfrastruktur, die den Umgang mit der Plattform und den Hardwarefunktionen des mobilen Endge- rates ermoglichen. Das groftte Problem fur Anwendungsentwickler ist somit die je- weilige App auf alien gangigen Plattformen bereit zu stellen und dabei den hohen Anforderungen der Endanwender zu entsprechen. Der Ansatz eine App fur jede Plattform spezifisch zu entwickeln ist damit stets mit einem hoheren Kosten- und Zeitaufwand verbunden, da die Anwendung und der dazugehorige Quellcode sepa- rat zu Entwickeln und Warten sind. Wenn eine Anwendung auf verschiedenen Platt- formen angeboten werden soil ist dies also nur mit einem entsprechenden Aufwand moglich. Ein moglicher Ansatz um diesen Herausforderungen entgegen zu wirken stellt die Methode der Cross-Plattform-Entwicklung dar, die es ermoglicht eine An­wendung mit demselben Quellcode auf verschiedenen Plattformen einzusetzen.⁵

In diesem Zusammenhang behandelt diese Arbeit die Thematik der plattformuber- greifenden Softwareentwicklung. Der Schwerpunkt wird auf die Implementierung ei­ner grafischen Benutzerschnittstelle (kurz: GUI aus dem englischen Graphical User Interface) gelegt. Zur Unterstutzung dieser Arbeit werden die wissenschaftlichen Me­thoden Literaturanalyse mit den Phasen Literaturrecherche und Literaturauswertung und das Prototyping herangezogen. Mit der Einleitung zusammen wird diese Arbeit in vier Hauptkapitel aufgeteilt. Das zweite Kapitel dient zur Erlauterung von theoreti- schen Grundlagen im Kontext der mobilen Softwareentwicklung. Im dritten Kapitel wird die prototypische Entwicklung einer Cross-Plattform-App dargestellt. Abschlie- Rend wird im letzten Kapitel das Ergebnis dieser Arbeit zusammengefasst.

2 Grundlagen

2.1 Mobile Endgerate

Im Zeitraum der achtziger Jahre begann die Entwicklung von mobilen Endgeraten. Mit der Zeit nahm der Einsatz dieser Gerate im privaten und auch im beruflichen Alltag zu. Es wurden immer mehr digitale Anwendungsfelder geschaffen, z.B. mittels Anwendungen fur Terminplanungen, digitale Notizen Oder fur E-Mails. Mittlerweile stellen mobile Endgerate einen kompakten und leistungsfahigen Computer dar, des­sen Infrastruktur dem eines Personal Computers (kurz: PC) entspricht. Jedoch er- halten mobile Endgerate, im Vergleich zu stationaren Geraten zusatzliche Hardware- komponenten.⁶ Damit ubersteigt die Vielfalt von Anwendungsfeldern im mobilen Segment die Anzahl der im nicht mobilen Segment. Dies wird deutlich, wenn die Bereiche der technischen Infrastruktur, Interaktion und des Einsatzkontextes von mobilen und nicht mobilen Anwendungen verglichen werden. Die technische Infra­struktur beschreibt die Berucksichtigung von unterstutzten Betriebssystemen und Geraten. Ein besonderer Aspekt im mobilen Segment sind die Leistungsunter- schiede der Endgerate, die auf dem Markt angeboten werden, deren Rechenleistun- gen, Bildschirmgroften und Auflosungen variieren. Einen weiteren Unterschied stel­len die Moglichkeiten der Interaktion zwischen Endanwender mit mobilen und nicht mobilen Geraten dar. Bei PCs werden zur Interaktion standardmaftig eine Tastatur, Maus und ein Monitor eingesetzt. Fur mobile Endgerate stehen Bildschirme zur Ver- fugung die dafur beruhrungsempfindlich sind, woruber unter anderem auch die Soft- ware-Tastatur bedient wird. Die Einheiten Kamera, Bluetooth, Mikrophon Oder Hel- ligkeitssensor sind nur einige von vielen Funktionen die ein mobiles Endgerat nutzt. Daher haben mobile Anwendungen eine groftere Auswahl an Moglichkeiten, urn mit ihrer Umwelt zu interagieren. Ein weiterer Unterschied wird im Rahmen der Anwen­dungsfelder deutlich. Mobile Anwendungen werden an unterschiedlichen Standorten eingesetzt, an denen sich Parameter aus der Umwelt, wie Lichtverhaltnisse, Ge- rauschkulisse, Signalstarke des Mobilfunknetzes Oder Temperatur unterscheiden. Diese Parameter konnen durch die Sensoren der Endgerate gemessen, bearbeitet und zur Interaktion mit dem Anwender eingesetzt werden. Es ist beispielsweise mog- lich den physischen Oder psychischen Zustand eines Anwenders zu ermitteln, indem der Puls gemessen wird Oder mittels der Kamera eine Mimik aufgenommen und be- wertet wird.⁷

2.2 iOS vs. Android

Ein Betriebssystem stellt die Software-Einheit eines Gerates dar. Praktisch in alien Geraten des alltaglichen Lebens befindet sich ein Betriebssystem. Typische Bei- spiele hierfur sind z. B. das Auto, die Kaffeemaschine, die Waschmaschine aber auch das Smartphone. Die Hauptaufgaben eines Betriebssystems werden durch die Pro- zess- und Speicherverwaltung, die Steuerung von Ein- und Ausgaben, das Manage­ment des Stromverbrauchs und dem Aspekt der Sicherheit abgedeckt. Damit dient ein Betriebssystem zur Verwaltung von alien Hardware-Komponenten eines Gera­tes, sowie zur Entlastung des Endanwenders durch die Ubernahme von standari- sierten Funktionen.⁸ Auf einem Betriebssystem konnen mehrere Prozesse gleichzei- tig laufen. Als Prozess wird ein laufendes Programm mit seinen Daten und dem Zu­stand verstanden. Das Betriebssystem hat die Aufgabe die nebenlaufige Abarbei- tung der Prozessaufgaben zu organisieren. Dabei verteilt es die benotigte Rechen- leistung eines Prozessors auf die einzelnen Prozesse. Jedem Prozess wird auf ei­nem Rechner ein Bereich im Hauptspeicher zugeordnet. Durch das Betriebssystem wird verhindert, das Prozesse auf die Speicherbereiche anderer Prozesse zugreifen. Zusatzlich muss die Heterogenitat der unterschiedlichen Gerate zur Ein- und Aus- gabe von Informationen uber das Betriebssystem gesteuert werden. Da Smartpho­nes und Tablets mobil eingesetzt werden, benotigen sie eine Batterie. Dem entspre- chend muss das Betriebssystem einen effizienten Umgang mit der Akkuleistung pfle- gen z.B. durch das Ausschalten des Displays Oder die Heruntertaktung des Prozes­sors. Eine App wird auf mobile Endgerate uber das Internet, aus beispielsweise App­les App Store Oder dem Google Play Store bezogen und installiert. Da Apps poten- tiell Schaden anrichten konnen wird derZugriff auf die Ressourcen des mobilen End- gerates durch das Betriebssystem eingeschrankt. Die gangigen Betriebssysteme im mobilen Segment werden durch Android, iOS und Windows vertreten, wobei der Markt vom zuerst und dem zweit genannten Betriebssystem dominiert wird.⁹ Im Ja- nuar 2019 erzielte Android weltweit einen Marktanteil von 74,5 % und iOS deckte den Markt mit 22,9 % ab.¹⁰ Die beiden Marktfuhrer stellen unterschiedliche Werk- zeuge zur Verfugung damit Anwendungsentwickler Apps fur die jeweiligen Plattfor- men entwickeln konnen. Die Unterschiede beider Betriebssysteme sind so graft, dass zur Entwicklung einer App fur das jeweilige Zielsystem eine andere Entwick- lungsinfrastruktur eingesetzt werden muss.¹¹

Die folgende Tabelle stellt die grundlegenden Unterschiede der herkommlichen Va- rianten zur Entwicklung von Apps fur Android und iOS dar:

Tabelle 1 - Herkommliche Entwicklungsinfrastruktur iOS und Android

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Entnommen aus Behrends (2018), S. 2.

2.3 Vorgehensmodelle

Ein Softwareprodukt hat das Ziel eine Losung fur einen bestimmten Anwendungsfall bereitzustellen. Der Lebenszyklus einer Software erstreckt sich dabei uber die Initi- alisierung einer Idee, der Planung, Implementierung und Einfuhrung, uber Weiter- entwicklung Oder eine Wartung bis zu einer moglichen Abschaffung der Software.¹² In diesem Zusammenhang wurde das Themenfeld Software-Engineering, uberZeit und Generationen hinweg, durch unterschiedliche Anwendungsfelder wie Groftrech- neranwendungen, Client-/Server-Anwendungen Oder Web-Applikationen weiterent- wickelt. Eigenschaften des Software-Engineerings die in diesem Zuge entstanden sind, lassen sich auch auf mobile Apps ubertragen.¹³ So verschieden wie die Idee, Ausgangssituation Oder der Anwendungsfall einer App sein kann, so Vielfaltig kann auch die Herangehensweise zur Entwicklung derApp sein. Daher gibt es im Umfeld der Softwareentwicklung eine Vielzahl von Vorgehensmodellen.¹⁴ Ein Vorgehens- modell wird als Instrument der Softwareentwicklung definiert, das zur Planung, Um- setzung und Kontrolle der jeweiligen Aktivitaten in einem Projekt eingesetzt wird. Dabei bestehen diese Modelle aus mehreren aufeinander folgenden Phasen, die in einer festgelegten Reihenfolge aufeinander aufbauen. Bei Vorgehensmodellen wird zwischen klassischen, modemen und agilen Methoden unterschieden.¹⁵ Die Gruppe der klassischen Vorgehensmodelle werden durch das Wasserfall- und Schleifenmo- delle abgebildet. Mit dieser sequenziellen Vorgehensweise wird das Ziel verfolgt, Softwareprojekte effektiverzu planen, zu organisieren und zu kontrollieren.¹⁶ Im Ver- gleich zu klassischen Modellen bieten moderne Vorgehensmodelle einen flexibleren Umgang mit auftreten Anderungen, eine bessere Transparenz der Ergebnisse im Projekt und eine intensivere Einbindung des Endanwenders an.¹⁷ Agile Modelle der Softwareentwicklung versuchen ein Projekt durch die systematische Verhinderung von Ressourcenverschwendungen zu optimieren. Aktivitaten die keinen Nutzen fur den Projektfortschritt haben werden dadurch vermieden und somit der Nutzen fur den Endanwenderfokussiert. Im Gegensatz zu klassischen Modellen werden in agi­len Vorgehensmodellen kurze Iterationen in der Softwareentwicklung genutzt. Damit wird das Ziel verfolgt dem Endanwender nach jeder Iteration ein greifbares Ergebnis vorzustellen, z.B. in Form einer lauffahigen Software, urn auf mogliche Anderungen in den Anforderungen effektiv zu reagieren.¹⁸

2.4 App-Typen

Die Entwicklung von mobilen Apps kann in vier verschiedene Kategorien unterteilt werden, dazu zahlt die Native-, Hybride-, Web- und Cross-Plattform-Entwicklung. Native Apps sind zur Verwendung auf bestimmten Plattformen zugeschnitten. Der native Ansatz bietet derjeweiligen App einen vollstandigen und performanten Zugriff auf alle Geratefunktionen der Zielplattform. Die Entwicklungskosten sind jedoch hoch und die Entwicklung zeitaufwandig, da fur jede Zielplattform eine eigene An- wendung entwickelt werden muss. Web Apps sind Webanwendungen die fur mobile Anwender entwickelt wurden. Bei diesem Ansatz wird die Applikation uber den Brow­ser des jeweiligen Endgerates geladen und nicht wie bei dem nativen Ansatz direkt auf das Gerat installiert. Auf die Anwendung kann somit uber jedes Smartphone Oder jedem Computer zugegriffen werden. Die hybride Entwicklung ist eine Kombination der Nativen- und Web-Entwicklung. Mittels einer Hybrid-App werden somit die Vor- teile der beiden vorangehenden Methoden kombiniert. Eine Hybrid-App kann auf un- terschiedlichen Plattformen genutzt werden und gleichzeitig auf die spezifischen und nativen Geratefunktionen, der jeweiligen Plattform zugreifen.¹⁹ Beim Ansatz der Cross-Plattform-Entwicklung wird ein Quellcode erstellt. Dieser Quellcode wird mit­tels eines Cross-Compilers in eine native Sprache ubersetzt. Durch die Ubersetzung entsteht fur die Zielplattform ein ausfuhrbarer Code. Damit kann ein Quellcode auf vielen verschiedenen Zielsystemen genutzt werden. Dieser Ansatz ist jedoch von der Effizienz und Zuverlassigkeit des eingesetzten Cross-Compilers abhangig.²⁰

3 Entwicklung eines Prototyps

3.1 Analyse und Planungsphase

Die Entwicklung einer Software ist mit einem aufwendigen Verfahren verknupft, das eine durchdachte Planungs- und Analysephase benotigt. Die Analysephase hat die Aufgabe, die relevante Problemstellung zu identifizieren, dazu Losungsansatze zu erstellen und daraus die kunftigen Funktionen einer Software abzuleiten. Die Pla­nungsphase verfolgt das Ziel die Struktur und den Umfang der Softwareentwicklung zu ermitteln.²¹ Die folgenden Unterkapitel des Kapitels 3.1 sollen auf folgende Fra- gestellungen eingehen:

- Welcher Anwendungsfall wird bearbeitet?
- Wie sehen die App-Anforderungen aus?
- Welches Vorgehensmodell zur Softwareentwicklung wird eingesetzt?
- Welche Entwicklungsinfrastruktur wird eingesetzt?

3.1.1 Relevanz und Zielsetzung

Im Einzelhandel und in der Konsumguterindustrie musste sich der Markt standig neuen Veranderung stellen und den dadurch entstandenen Trends folgen. Das Kon- sumverhalten der Kunden wurde durch die digitale Transformation beeinflusst. Das hat z.B. dazu gefuhrt, dass Kunden vor einem stationaren Kauf von Produkten, uber Online-Kanale Recherchen durchfuhren. Auf deranderen Seite probieren und prufen die Konsumenten Produkte stationar, bevor ein Online-Kauf getatigt wird. Mittler- weile ermoglicht der Einsatz von Smartphones und Apps Unternehmen, unabhangig von Zeit und Ort, personalisiert mit Kunden in Kontakt zu treten und dadurch ein neues Einkaufserlebnis zu schaffen.²² In diesem Zusammenhang erwarten Konsu­menten ein wohlfuhlendes und reibungsloses Kundenerlebnis von der Erkennung des Bedarfs uber die Beschaffung von Informationen und der Kaufabwicklung bis hin zu Servicedienstleistungen. Der allgegenwartige Einsatz von Smartphones und der stetig wachsende Online-Markt verlangt damit die standardmaftige Einfuhrung von Apps im Einzelhandel und in der Konsumguterindustrie.²³ In dieser Branche hat der Secondhand Markt einen neuen Aufschwung erlebt. Die Idee, gebrauchte Guterwei- terzuverkaufen und zu kaufen, ist ein bekannter Prozess, der z.B. in Flohmarkten ewig gelebt wird. Durch den digitalen Wandel gibt es mittlerweile weitere Moglichkei- ten gebrauchte Produkte uber Online-Plattformen wie Ebay zu verkaufen Oder zu erwerben.²⁴ In den folgenden Kapiteln wird vor diesem Hintergrund eine prototypi- sche App fur die Secondhand Modebranche entwickelt.

3.1.2 Anforderungen an den Prototypen

In der Modebranche legen Konsumenten besonderen Wert auf Produktbewertun- gen. Dabei sind haufig die Produkterfahrungen von Bekannten und Freunden aus- schlaggebend fur eine Kaufentscheidung. Daher sind soziale Netzwerke in diesem Segment ein wichtiger Ansatzpunkt.²⁵ Um die Wahrscheinlichkeit der Akzeptanz ei- ner App zu steigern mussen Entwickler, das am Markt gegebene Portfolio an Apps und das Kundenverhalten berucksichtigen, damit die App auch tatsachlich von den Kunden genutzt wird. Die Registrierung und Anmeldung, sowie die Angabe von per­sonlichen Daten werden z.B. vereinfacht, wenn Nutzer ihre Facebook, Google Oder Twitter Konten mit einer App verknupfen konnen.²⁶ Aus diesem Grund wird dem Pro- totyp vorausgesetzt, im Anmeldeformular soziale Netzwerke zu berucksichtigen. Zu- satzlich soil dem Nutzer die Moglichkeit geboten werden, ein individuelles Profil mit Zusatzinformationen zu gestalten, urn den Aspekt der sozialen Netzwerke einflieften zu lassen. Eine Umfrage unter Online-Shoppern in Deutschland im Jahr 2018 uber die Chancen und Herausforderungen von Shopping-Apps hat ergeben, dass App- Nutzer hohen Wert auf einen schnellen Zugang auf App-lnhalte, eine schnelle Be- dienbarkeit und eine einfache Navigation innerhalb der App legen.²⁷ Daher soil eine ubersichtliche Benutzeroberflache mit einer effektiven Navigationsfunktion imple- mentiert werden. DaderSmartphone-Marktvon den Betriebssystemen iOS und And­roid dominiert wird, wie aus dem Kapitel 2.2 zu entnehmen ist, soil die zu entwi- ckelnde App auf beiden Plattformen nutzbar sein.

3.1.3 Auswahl eines Vorgehensmodells

Die Auswahl eines geeigneten Vorgehensmodells hangt von den Projektanforderun- gen ab. Wenn das Projekt vorrausschauend keine wechselnden Anforderungen auf- weisen wird, empfiehlt sich ein sequenzielles vorgehen. Bei Projekten mit vielen Va­riable^ die sich andern konnen werden agile Vorgehensmodelle als zielfuhrend ge- sehen.²⁸ Die Anforderungen an diese App wurden im vorangehenden Kapitel defi- niert und werde bis zum Abschluss der Arbeit festgesetzt. Daher wird im Rahmen dieser Arbeit das Wasserfallmodell zur Unterstutzung der App-Entwicklung einge­setzt. Das Wasserfallmodell wurde im Jahr 1970 durch einen Artikel von W. Royce publik. Dieses Vorgehensmodell lasst sich immer dann anwenden, wenn alle Anfor­derungen zu Beginn des Projektes bekannt sind und wenn keine Anderung in Aus- sicht ist. Die einzelnen Phasen werden wahrend der Softwareentwicklung sequentiell ausgefuhrt.²⁹ Das Wasserfallmodell wird im Wesentlichen in die Softwareentwick- lungsprozesse Planung, Konzeption, Implementierung, Test und Wartung aufgeteilt. Nachdem eines dieser Prozesse erfolgreich abgeschlossen wurde, kann daraufhin der Ubergang in die nachste Phase stattfinden.³⁰ Die einzelnen Phasen in diesem Modell konnen nicht gleichzeitig erfolgen und auch nicht ubersprungen werden. Stellt sich beispielsweise in der Phase Implementierung heraus, dass einige Spezifikatio- nen nicht wie gewunscht realisierbar sind, erfolgt der Rucksprung von der Implemen- tierungsphase in die Konzeptphase.³¹

Die folgende Grafik stellt das Wasserfallmodell dar, das fur die prototypische Ent­wicklung in dieser Arbeit eingesetzt wurde:

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Ernst et al. (2016), S. 759.

Abbildung 1 -Wasserfallmodell zur Entwicklung der App

3.1.4 Festlegung der Entwicklungsinfrastruktur

Vor dem Hintergrund der zuvor genannten Anforderungen an die App, wird in dieser Arbeit React Native zur Entwicklung der Cross-Plattform-App eingesetzt. Bei React Native handelt es sich um ein Framework zur plattformubergreifenden Softwareent­wicklung nativer Apps. Es wurde im Jahr 2015 von Facebook fur iOS Projekte ein- gefuhrt. Daraufhin wurde im selben Jahr auch Android als Zielplattform unterstutzt. Seit der Einfuhrung von React Native ist eine grofte Gemeinschaft von Programmie- ren und Unternehmen zusammengewachsen, die die Weiterentwicklung dieses Frameworks vorantreiben. Dieses Framework reduziert den Aufwand bei der Pro- grammierung von nativen Apps. Es ermoglicht Entwicklern mit einer Codebasis, plattformubergreifend fur iOS und Android Apps zu entwickeln. Dieses Framework generiert dabei effiziente Apps mit nativen Elementen der jeweiligen Betriebssys- teme. Dies wirkt sich auf den Wiedererkennungswert und die Performance einer App positiv aus. Bei Bedarf ermoglicht React Native auch die Implementierung von nati- vem Code, um beispielsweise Bestandteile bereits vorhandener nativer Projekte in einem neuen Projekt einzubauen. Auf der anderen Seite konnen in bereits beste- hende native iOS und Android Projekten React Native Komponenten integriert wer- den. Damit konnen z.B. neu geplante Funktionen in den jeweiligen Apps, prototy- pisch mittels React Native plattformubergreifend umgesetzt werden. Viele bekannte Apps wurden auf Basis von React Native entwickelt, dazu zahlen z.B. Airbnb, Insta­gram und Uber. Der Quellcode einer in React Native entwickelten App basiert auf der Programmiersprache JavaScript.³²

Die nachfolgende Auflistung und die darauffolgende Grafik soil nun die Architektur und Funktionsweise des Frameworks React Native darstellen:³³

- Bridge: Zur Kommunikation zwischen der JavaScript Umgebung und den na- tiven Elementen derZielplattformen, werden Nachrichten mittels einer Bridge ausgetauscht. Dazu enthalt die Bridge Informationen uber native Module, so­dass der Anwendungscode der JavaScript Umgebung als plattformubergrei- fende Komponente eingesetzt werden kann. Wenn beispielsweise im Ja­vaScript ein View-Element eingesetzt wird, wird in der iOS-Umgebung ein Ul- View-Objekt erzeugt und in der Android-Umgebung fuhrt dies zur Verwen- dung der Komponente android.widget.View.
- JavaScript Laufzeitumgebung: Apps die auf Basis von React Native entwi- ckelt wurden, greifen zur Laufzeit einer App auf die nativen Elemente der je- weiligen Plattform zu. Um dies zu ermoglichen muss auf derZielplattform eine Laufzeitumgebung fur JavaScript vorhanden sein. Dafur liefert React Native fur Android eine JavaScript-Umgebung mit und in iOS ist grundlegend eine Umgebung namens JavaScriptCore vorhanden. Damit lassen sich auf jeder App die nativen Elemente derZielplattform darstellen. Dabei werden zur Ver- wendung der nativen Elemente Anweisungen der JavaScript Umgebung uber die Bridge an die Zielplattform gesendet.
- Native-Module: Es konnen verschiedene Aktivitaten in den nativen Modulen der App erfolgen. Diese Aktivitaten, z.B. das Antippen eines Elements auf der GUI, muss dann zur Verarbeitung an die JavaScript Umgebung weitergeleitet werden, damit die gewunschte Aktion z.B. das Versenden einer E-Mail erfol­gen kann.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Behrends (2018), S. 5.

Abbildung 2 - Architektur des Frameworks React Native

3.2 Konzept

In dieser Phase wurde das Ziel verfolgt ein grafisches Konzept zu erstellen, um den Funktionsumfang der App darzustellen. Zur Darstellung wurde auf die Methode Wireframe zuruckgegriffen. Bei Wireframes handelt es sich um eine zweidimensio- nale konzeptionelle Darstellung eines Software-Projektes. Es verfolgt das Ziel die Strukturen eines digitalen Produktes in einem fruhen Stadium des Entwicklungspro- zesses zu verdeutlichen. Es dient als Grundgerust, um einen Prototyp effizient zu entwickeln. An dieser Stelle wird die Prioritat nicht auf detaillierte grafische Elemente gelegt, vielmehr steht die Darstellung der Funktionalitat und die Navigation eines digitalen Produktes im Vordergrund.³⁴ Dabei wurde die App konzeptionell in die funf Bereiche Login, Startseite, Suche, Nachrichten und das personliche Profil aufgeteilt.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Abbildung 3 - Darstellung der Secondhand-App mittels eines Wireframes

3.3 Implementierung und Test

Auf Grundlage der zuvor genannten Anforderungen aus der Analyse-, Planungs- und Konzeptphase, wurde der Prototyp entwickelt. Dazu wurde im Rahmen dieser Arbeit die Entwicklungsumgebung Visiual Studio eingesetzt. Nachdem die Entwicklungs- umgebung aufgesetzt wurde, wurde die Benutzeroberflache, die aus der Abbildung 3 abzuleiten ist umgesetzt. Dabei wurde der Fokus aufdie Moglichkeit zur Authenti- fizierung mittels Konten gangiger sozialer Netzwerke, eine schnelle Navigation zwi- schen den einzelnen Benutzeroberflachen und eine ubersichtliche Ansicht gelegt. Abschlieftend wurde in der Testphase die Darstellung des Prototyps auf verschiede- nen Endgeraten uberpruft. Dazu wurden zwei physische und ein virtuelles Gerat ein­gesetzt.

Die folgende Tabelle stellt die Eigenschaften der Testgerate und das Ergebnis der Testphase auf:

Tabelle 2 - Testgerate und Ergebnis

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

[...]

---

¹ Vgl. Lenz (2018), S. 1.

² Vgl. Rieber (2017), S. 1f.

³ Vgl. Raj, Tolety (2012), S. 625.

⁴ Vgl. Bin Al Abid, Karim (2017), S. 1.

⁵ Vgl. Raj, Tolety (2012), S. 625.

⁶ Vgl. BSI (2006), S. 5.

⁷ Vgl. Barton et al. (2016), S. 95f.

⁸ Vgl. Ernst et al. (2016), S. 301.

⁹ Vgl. Ernst et al. (2016), S. 303ff.

¹⁰ Vgl. Statista (2019).

¹¹ Vgl. Behrends (2018), S. 1f.

¹² Vgl. Aichele, Schonberger (2014), S. 253f.

¹³ Vgl. Barton et al. (2016), S. 95.

¹⁴ Vgl. Aichele, Schonberger (2014), S. 134.

¹⁵ Ebd., S. 138ff.

¹⁶ Ebd., S. 140f.

¹⁷ Ebd., S. 143f.

¹⁸ Ebd., S. 146f.

¹⁹ Vgl. Yassine et al. (2018), S. 141f.

²⁰ Vgl. Raj, Tolety (2012), S. 627.

²¹ Vgl. Aichele, Schonberger (2014), S. 253f.

²² Vgl. Capgemini (2017), S. 4ff.

²³ Vgl. Ebd., S. 23f.

²⁴ Vgl. Arnold (2018).

²⁵ Vgl. Capgemini (2017), S. 10.

²⁶ Vgl. Capgemini (2017), S. 26.

²⁷ Vgl. Schachinger, Linsser (2018), S. 18f.

²⁸ Vgl. Aichele, Schonberger (2014), S. 137f.

²⁹ Vgl. Ernst et al. (2016), S. 759.

³⁰ Vgl. Aichele, Schonberger (2014), S. 140ff.

³¹ Vgl. Timinger (2017), S. 38f.

³² Vgl. Behrends (2018), S. Iff.

³³ Vgl. Behrends (2018), S. 4ff.

³⁴ Vgl. Wiesche et al. (2018), S. 347ff.