Eine Cross-Platform-Anwendung soll dabei wie oben schon genannt Entwicklungsaufwand und langfristige Wartungskosten reduzieren, während eine vollnative Anwendung besser auf die Anforderungen des jeweiligen Betriebssystems zugeschnitten werden kann.

In der Praxis ist insbesondere die Menge der Androidtelefonen keine homogene Masse. Es gibt inzwischen eine riesige Fülle an herstellerspezifischen Funktionen und Eigenheiten in stark herstellerabhängig konfigurierten Androidversionen auf den Mobiltelefonen und Tablets der unterschiedlichen Hersteller. Dies führt dazu, dass das oben genannte konkrete Zuschneiden auf das Betriebssystem häufig nur auf dem kleinsten gemeinsamen Nenner funktioniert und keineswegs alles so standardisiert ist, wie initial erwartet.

Wenn man sich nun also dafür entschieden hat, eine spezifische App mit einem Cross-Platform-Framework zu entwickeln, gibt es neben React Native noch weitere Frameworks mit teils großer Beliebtheit, wie etwa Ionic, Flutter, NativeScript oder Xamarin. Hier ergibt sich gleich die erste Kategorisierung: Programmiersprache des Quellcodes.

Während React Native-, Ionic- und NativeScript-Anwendungen mit JavaScript oder TypeScript entwickelt werden, wird bei Flutter die Sprache Dart und bei Xamarin C# auf .NET-Basis verwendet. Im Vergleich zu Dart und C# haben JavaScript und TypeScript mit Abstand die höchste Popularität [1] [2], weswegen es allgemein mehr Inhalte dazu zu finden gibt (siehe Abbildung 2).

Somit bleiben zum direkten Vergleich mit React Native noch Ionic und NativeScript. Von den dreien hat React-Native die höchste Popularität auf GitHub, Stackoverflow und Hackernews, gefolgt von Ionic. Schlusslicht ist NativeScript

Ionic verwendet statt nativer UI-Elemente eine WebView und setzt Apache Cordova für den nativen Hardwarezugriff ein. Darunter leidet in der Praxis die Performance ein wenig. Komplexe UIs wie 3D-Modelle oder Spiele sind mit Ionic nur schwierig umsetzbar.

NativeScript gibt die gesamte API der entsprechenden nativen Plattform frei und erlaubt damit eine noch engmaschigere Integration mit dem Betriebssystem. Dafür ist die Community etwas kleiner was in weniger Beispielen und Problemlösungen auf Stackoverflow resultiert.

React Native sticht durch seine gute Performance dank Virtual DOM und der geringen Einstiegshürde für neue Entwickler hervor. Dabei hilft auch die Hot-Reloading Funktionalität, dank der die Iterationszeit massiv verkürzt werden kann. Wie auch bei React (nicht-native), können hier Änderungen am Quellcode direkt in der Anwendung reflektiert werden; Es ist keine erneute vollständige Kompilation und Installation erforderlich. Ein einfaches Speichern der angepassten Datei genügt. Des Weiteren ist React Native recht leichtgewichtig. Kontrapunkt davon ist, dass selbst für einfache Anwendungen unter Umständen bereits weitere Bibliotheken eingebunden werden müssen.

Hier die genannten und weitere Erkenntnisse einmal tabellarisch zusammengefasst:

Anschließend sollte sich neben einigen Command-Line-Fenstern der Androidemulator öffnen, auf dem dann die soeben erstellte Anwendung installiert und gestartet wird, sobald alles fertig gebaut ist.

Aber was wurde da jetzt genau ausgeführt?

Nach einem kurzen Blick in das vom Befehl in Schritt 4 neu erstellten Verzeichnisses sehen wir einige Dateien und Ordner:

ShowcaseApp/
├── android/: Quellcode und Buildconfig für die native Android-App.
├── ios/: Quellcode und Buildconfig für die native iOS-App als XCode-Projekt.
├── node_modules/: Abhängigkeiten für dieses Projekt.
├── App.tsx: Primäre View der Anwendung, referenziert aus der index.js.
├── app.json: Metainformationen wie Name der Anwendung und Version.
├── index.js: Haupteinstiegspunkt der React-Native App.
├── package.json: Definition der Abhängigkeiten für dieses Projekt.
└── tsconfig.json: Compiler- und Linterkonfigurationen für Typescript.

Ändern wir nun im ersten Schritt den angezeigten Text und die Hintergrundfarbe. Dazu müssen wir die primäre View bearbeiten, also die App.tsx. Diese sieht momentan wie folgt aus:

Sie teilt sich grob in drei Blöcke. Oben stehen die zu importierenden Abhängigkeiten. In unserem Fall sin des nur die Standardabhängigkeiten React, sowie StyleSheet, Text und View aus dem Package react-native.

Im zweiten Block mit der Funktion sehen wir, dass hier eine function namens App exportiert wird. Dieser Export bedeutet, dass diese Funktion von außerhalb dieser tsx-Datei sichtbar und aufrufbar ist. Sie gibt ein Element vom Typ View (oben importiert) zurück und assoziiert in HTML-Notation den im dritten Block definierten Style. Innerhalb dieses View-Elementes ist ein Text-Element geschachtelt, welches den in Abbildung 3 auf dem Emulator angezeigten Text enthält.

Im dritten Block folgt die CSS-artige Inlinestyledefinition. Es gibt also eine Art Style-Selektor container mit den angegebenen Eigenschaften. Diese wird wie beschrieben in Block zwei obendrüber an das View-Element angehängt. Üblicherweise werden die Styles in React Native immer in dieser Form definiert und nicht in CSS-Dateien ausgelagert. Mit der richtigen Progammbibliothek ließe sich das natürlich ändern.

Zusammenfassend haben wir also eine View mit einem Text darin, welche mit einem CSS-artigen Inlinestyle gestyled ist.

Testweise könnte man jetzt den Text wie folgt ändern:

<Text>Open up App.tsx to start working on your app!</Text> 🡆 <Text>Hallo Welt Test 123</Text>

und den Style:

backgroundColor: '#fff', 🡆 backgroundColor: '#d3fccf',

Nach dem Speichern der veränderten App.tsx sollte sich die App auf dem Emulator nach einem Moment automatisch wie folgt aktualisieren:

Sofern die automatische Aktualisierung einmal nicht funktioniert, kann auch manuell aktualisiert werden, indem im entsprechenden Konsolenfenster die Taste r gedrückt wird.

Der Hintergrund ist jetzt grün und der Text wie angepasst. Wunderbar! Da Android-Apps auch häufig mit Java entwickelt werden, stellt sich hier die Frage, ob sich diese eher funktionale Schreibweise der Anwendungsdefinition auch objektorientierter mit Klassen wie in Java abbilden lässt. Das würde den Umstieg von Android-Entwicklern, die Java verwenden wohl signifikant erleichtern. Die Antwort auf die Frage lautet: Ja, es geht auch mit Klassen. Sogar relativ leicht.

Oben hatten wir unsere Anwendung ja als einzelne Funktion definiert, die zurückgegeben wird. Alternativ können in React und React Native auch Klassen verwendet werden.

Ersetzen wir also unsere Funktion durch eine Klasse:

Imports und die Styledefinition bleiben wie gehabt. Statt einer Funktion wird nun jedoch eine Klasse App zurückgegeben, welche von React.Component erbt. Auf die beiden any-Typen in den spitzen Klammern wird im nächsten Schritt eingegangen.

Nach der Klassendefinition folgt in der dritten Zeile der Konstruktor. Der Konstruktor ist in diesem Fall eher unspektakulär, da der übergebenen Wert bloß an den Superkonstruktor durchgereicht wird. In diesem Fall wäre dieser Konstruktor sogar optional, da genau dieses Verhalten auch vom impliziten Standardkonstruktor so durchgeführt wird.

Schließlich folgt die render-Methode, welche den identischen Inhalt zur App-Methode aus dem vorherigen Codebeispiel enthält.

Nun stellt sich die Frage, welchen Mehrwert das Ganze mit der Klasse nun bringt, da das Resultat das gleiche ist wie mit der App-Funktion von oben. Es gibt nur mehr Overhead. Die Antwort lautet: Das richtige Tool für den richtigen Job. In diesem Beispiel war die Klasse komplett stateless, daher böte sich eine Implementierung ohne explizite class nur über die Funktion an. Anders sieht es im folgenden Beispiel aus.

Hier fügen wir in die bestehende Anwendung ein Textfeld und eine Schaltfläche hinzu. Sobald die Schaltfläche gedrückt wird, soll der initiale "Hallo Welt"-Text durch den Text im Textfeld ersetzt werden. Dadurch wird die Anwendung zustandsbehaftet. Da die weiteren Beispiele im Artikel auf diese Basis aufbauen, soll in dieses Textfeld kein beliebiger Text, sondern ein Standort eingeben werden.

Beginnen wir wieder mit den Imports:

Dieses Mal werden also neben dem Text und dem View offenbar noch weitere Elemente aus dem react-native-package importiert. Spannend!

Wie versprochen soll das Beispiel nun einen internen state haben. Dafür wird zunächst einmal definiert, wie dieser denn aussehen soll. Dies geschieht anhand eines Interfaces:

Das Interface spezifiziert wie ein dazugehöriges Objekt auszusehen hat, enthält selbst aber nur diese Metainformation und keine tatsächlichen Daten. in diesem Fall gibt es also ein Attribut vom Typ string namens locationText, welches den angezeigten Ort bereithält. Dazu gibt es noch ein optionales Attribut editedLocationText, welches den geänderten Text beinhalten soll. Objekte in TypeScipt sind zwar semistrukturell definiert, lassen sich per Cast aber üblicherweise ohne Plausibilitätscheck duck-typen. Fehlende Attribute, die im Cast-Ziel vorhanden sein müssen, sind dann beim Zugriff wie zu erwarten undefined.

Weiter mit der Klassendefinition:

Es fällt auf, dass im Kontrast zum oberen Beispiel die Klasse nicht länger die beiden Typen any-any in den spitzen Klammern, sondern any-AppState beinhaltet. Der vordere der beiden Parameter ist der Typ der sogenannten Properties. Dies sind quasi Eingabeparameter für die Klasse, die dann in den Konstruktor weitergereicht werden. Der zweite Parameter ist unsere State-Definition von oben. Im Konstruktor wird der State auch gleich mit dem location Text-Wert Hallo Welt! initialisiert, welcher im vorherigen Beispiel noch im Virtual-DOM fest einprogrammiert war.

Dank Typescript lässt sich hier für den State auch ausschließlich locationText (und natürlich optional editedLocation) setzen, und dafür auch nur string-Werte.

Als nächstes die überarbeitete render-Methode, welche innerhalb der Klasse, etwa unterhalb des Konstruktors vor die finale schließende Klammer eingefügt wird:

Anstatt des hartkodierten Wertes erhält das Text-Element nun seinen Wert aus dem lokalen State locationText. Zusätzlich gibt es hier den erwähnten TextInput mit einem Platzhaltertext und einem onChange-Handler, der aktiv wird sobald sich der eingegebene Text ändert. Die aufzurufende Funktion this.onLocationTextChange muss natürlich noch erstellt werden. Sie bekommt in bekannter Lambda-Schreibweise ein string-Argument übergeben, welches den aktualisierten Text enthält.

Schließlich folgt noch die Schaltfläche mit der Aufschrift "Übernehmen", welche beim Klicken die Methode this.saveLocation() aufrufen soll.

Fehlen noch die beiden Methoden zum Ändern und Speichern des aktualisierten Textes:

Diese beiden Methoden müssen sich auch innerhalb der Klasse befinden. Die Methode saveLocation gibt zunächst den aktuell geänderten Wert auf der Konsole mittels String-Template aus. Anschließend wird der State der Anwendungs-Klasse aktualisiert, indem der locationText auf den Wert der editierten Location gesetzt wird. Letztere wird anschließend geleert.

Als Resultat der State-Aktualisierung wird umgehend ein partieller Render der Oberfläche ausgelöst, wodurch das Textelement den neuen Text anzeigt und das Eingabefeld geleert wird.

Die zweite Methode erhält den vom Event-Handler abgefangenen neuen Wert für den Text des Eingabefeldes und legt diesen im State-Feld editedLocationText ab.

Wie bei der oberen Methode wird auch hier ein Render aufgrund der Zustandsaktualisierung ausgelöst. Allerdings wird dabei nur das virtuelle DOM von React aktualisiert und nicht die tatsächliche Oberfläche der Android-App neugezeichnet, da es ja nur eine Änderung am internen State gab, der nicht in einer geänderten Oberfläche resultiert.

Die aktualisierte Version der App sieht wie folgt aus:

Natürlich ließe sich der State auch mit dem funktionalen Ansatz des vorherigen Kapitels realisieren.

Um den Mehrwert einer nativen App gegenüber einer Progressive Web App auch zu realisieren, sollen nun einige native-only Funktionen, wie die Geo-Location und eine Push-Notification verwendet werden.

Da Geo Location seit React Native .60 nicht mehr bei den initialen Plattformbibliotheken dabei ist, muss hierfür ein extra Modul [9] installiert werden: npm install @react-native-community/geolocation --save. Es macht Sinn, dafür kurz den Emulator und den automatischen Reloadprozess zu beenden, da es sonst zu Dateilocks kommen kann und die Modulinstallation nicht erfolgreich abgeschlossen werden kann.

Das neue Modul wird dann beim Starten via npx react-native run-android automatisch vom React Native CLI gelinked.

Um den Standort in der App selbst auszulesen, anstatt sich auf den Benutzer zu verlassen, wird die saveLocation-Methode wie folgt abgeändert:

Außerdem muss der Import von der oben hinzugefügten Abhängigkeit eingefügt werden:

Wie im oberen Snippet ersichtlich, wird via Geolocation.getCurrentPosition(callback, error, config) der aktuelle Standort ausgelesen. Zurück kommt ein Objekt der Form

Hieraus wird im Success-Callback die Latitude und Longitude ausgelesen und an den neuen anzuzeigenden locationText angehängt. Dieser wird dann gleich per State-Update weitergegeben.

Im Fehlerfall wird eine Meldung auf der Konsole ausgegeben.

Beim ersten Starten bzw. Reloaden der Anwendung taucht nun nach dem Klick auf den "Übernehmen"-Button die Berechtigungsabfrage in Abbildung 6 auf.

Nachdem die Berechtigungsanfrage akzeptiert wurde, wird sofern alles funktioniert hat nun der im Emulator eingestellte Standort ausgegeben (siehe Abbildung 7).

Eine Berechtigungsanforderung über einen Eintrag in der android/app/src/main/AndroidManifest.xml-Datei, welche sicherlich den meisten Androidentwicklern bekannt ist, ist hier nicht erforderlich. Der Grund dafür ist, dass das von uns ganz oben verwendete React-Native Template bereits alle Berechtigungen anfordert. Die Idee ist hierbei, diese nach Abschluss der der Entwicklungsarbeit entsprechend den Anforderungen zu stutzen. Für die iOS-App sieht dies ähnlich aus. Hier muss unter Umständen die Info.plist-Datei angepasst werden.

Neben der Geolocation gibt es noch weitere spannende native-only Funktionen. Zum Beispiel das Versenden von Push-Notifications. Das schauen wir uns als nächstes an.

Da die Konfiguration von Remote Push-Notifications über Firebase oder Apple Push Notification services den Rahmen dieses Artikels etwas sprengen würde, beschränken wir uns hier auf lokale Push-Benachrichtigungen. Da diese Funktionalität von React-Native nicht direkt mitgeliefert ist, wird erneut eine Programmbibliothek [10] installiert (npm install --save react-native-push-notification) sowie die dazugehörigen Typescript-Typen (npm install --save @types/react-native-push-notification).

Anschließend wird die saveLocation-Methode ein letztes Mal erweitert:

Natürlich muss PushNotification auch importiert werden:

Die Methode PushNotification.localNotification(…​) in Zeile 7 wird nun mit dem gleichen Wert wie die State-Aktualisierung aufgerufen. In unserem Fall ist dies auch der einzige Parameter. Die Methode akzeptiert jedoch noch über 20 weitere, optionale Parameter zum Konfigurieren unterschiedlichster Eigenschaften der Push-Notification. Die gesamte Dokumentation kann der README-Datei im GitHub Repository [10] entnommen werden.

So sieht unsere Push-Notification aus:

Damit haben wir nun eine kleine Multi-Platform-App gebaut, welche neben einigen Basiselementen auch den Standort auslesen und Push-Benachrichtigungen verschicken kann. Dies Funktionalitäten blieben einer Progressive Web App dagegen verwehrt.

Steffen Jacobs (M.Sc) hat Wirtschaftsinformatik an der Universität Mannheim studiert und ist als Consultant und Software-Entwickler tätig. In seiner Freizeit engagiert er sich im OpenSource Umfeld.