In meinem letzten Artikel dieser Blogreihe habe ich Ihnen die nativen Apps vorgestellt. Falls Sie den Artikel noch nicht gelesen haben, sollten Sie dies unbedingt tun. Daran anknüpfend möchte ich Ihnen in diesem Artikel "native Apps" mit nicht-nativen Framework vorstellen. Wie auch im vorangegangenen Artikel schauen wir uns zunächst Vor- und Nachteile der Technologie an. Anschließend schauen wir auf die Risiken und Abhängigkeiten während der Entwicklung und auch auf das am Know-How am Markt, sowie die verfügbaren Frameworks. Zum Schluss betrachten wir noch die Entwicklungskosten und den Entwicklungsaufwand, bevor ich Ihnen schließlich die Ergebnisse meiner Beispiel-App vorstelle.
Blogreihe
Hier finden Sie die Auflistung der einzelnen Blogartikel die zur Blogreihe gehören. Diese Agenda wird mit jedem neu veröffentlichtem Artikel erweitert.
Native Apps mit nicht-nativen Framework
Native Apps mit nicht-nativen Framework
Eine native App mit nicht-nativen Framework bezeichnet eine App, die mit einem Framework geschrieben wird, welches nicht die Systemsprache verwendet, aber so übersetzt wird, dass die Anwendung die nativen Komponenten verwendet. Unter der Haube wird das so realisiert, dass die Anwendung selbst in einer Runtime läuft und mit Hilfe einer Bridge mit den nativen Elementen kommuniziert.
Die Anwendung wird ähnlich wie bei den nativen Apps für genau eine Plattform entwickelt, allerdings können einige Teile der Anwendung für die andere Plattform wiederverwendet werden. Dadurch spart man sich im Vergleich zu nativen Apps etwas Arbeitsaufwand. Anwendungen können bzw. müssen teilweise in dem nativen Code geschrieben werden, um beispielsweise weitere Komponenten zu schreiben, die das Framework nicht besitzt oder um Sensoren anzusteuern, für die das Framework noch keine eingebaute Kompatibilität hat.
Vor- und Nachteile
Wohl der größte Vorteil, den nicht-native Frameworks im Vergleich zu nativen Apps bieten, ist die Wiederverwendbarkeit des Quellcodes. Dadurch spart man sich Zeit und Geld in der Entwicklung. Die Wiederverwendbarkeit resultiert auch aus der „learn once, write everywhere“ Philosophie, welche die Frameworks verfolgen. Egal für welche Plattform entwickelt wird, die Programmiersprache ist dieselbe; meistens JavaScript.
Ein weiterer Vorteil ist, dass man das gleiche Look & Feel hat wie mit nativen Apps. Dadurch sehen die App Komponenten genauso aus wie bei nativen Apps und die Nutzer sind vertraut mit den UI-Komponenten. Ein großer Nachteil der nicht-nativen Frameworks ist allerdings die Sensorunterstützung. Das Verwenden von Sensoren ist mit nicht-nativen Frameworks nur über Plugins möglich, die entweder selbst in nativen Code geschrieben werden müssen oder bereits von anderen Entwicklern geschrieben wurden. Da die App in einer Runtime läuft und nur über eine Bridge mit den nativen Komponenten kommuniziert, kann die Anwendung nur Single-Threaded laufen. Es ist also nicht möglich mit solchen Anwendungen mehrere parallellaufende Threads zu benutzen. Dabei geht es allerdings nur um die physischen Threads. Asynchrone Aufgaben mit sogenannten Promises sind in der JavaScript Runtime von beispielsweise ReactNative durchaus möglich.
Bei der Entwicklung einer App mit nicht-nativen Framework ist es auf Grund der Runtime auch möglich ein hot reloading zu benutzten. Hot reloading ist ein Feature, welches dazu führt, dass geänderter Code sofort in der Applikation angezeigt wird, ohne, dass diese neugestartet werden muss. Apps mit nicht-nativen Frameworks werden genauso wie native Apps im plattformspezifischen App Store zur Verfügung gestellt, wodurch auch die gleichen Vor- und Nachteile entstehen wie bereits bei den nativen Apps.
Risiken und Abhängigkeiten
Bei der Entwicklung von Apps mit nicht-nativen Framework ist man stark abhängig von den Third-Party Modulen, welche die Nutzung von Sensoren möglich machen. Da diese Module nicht von den Framework Entwicklern selbst geschrieben wurden, könnte es passieren, dass ein Modul bei neueren Versionen nicht aktualisiert wird oder sich die Geräteschnittstelle ändert und das Modul dadurch unbrauchbar wird. Ein großes Risiko bei der Entwicklung ist die Tatsache, dass die Module in nativen Code geschrieben werden müssen. Wenn es noch kein entsprechendes Modul gibt, braucht man native Entwickler, um ein entsprechendes Modul anzufertigen.
Technologien und Markt Know-how
Große Beispiele für nicht-native Frameworks sind React Native und NativeScript. Beide Frameworks basieren auf der Programmiersprache JavaScript. React Native ist ein von Facebook entwickeltes Open-Source Framework, welches die gleiche Syntax verwendet wie das ebenfalls von Facebook entwickelte JavaScript Framework React, welches in der Web-Entwicklung verwendet wird. NativeScript ist ebenfalls ein Open-Source Projekt, das von Progress ins Leben gerufen wurde. NativeScript bietet zusätzlich zu purem JavaScript auch die Möglichkeit die Web-Frameworks Angular oder Vue.js zu benutzen.
Aus einer Statista Umfrage geht hervor, dass React Native bei den fast 20.000 Befragten Software Entwicklern, mit 42% eine große Beliebtheit erfährt. Dies blieb von 2019 auf 2020 gleich. NativeScript erzielte in der Umfrage allerdings nur 11%, welche bis 2020 auf 9% sanken. Auch in den Joblistings erhält ReactNative mit 357 zu 40 Suchergebnissen bei Indeed und 71 zu 1 Suchergebnissen bei Stack Overflow deutlich mehr als NativeScript. Da beide Frameworks Open-Source sind, besitzen sie ein Repository auf GitHub. Das Repository von React Native erzielt auf GitHub 89.500 Sterne, während NativeScript nur 18.900 Sterne besitzt. Das zeigt, dass beide Frameworks recht beliebt sind, wobei ReactNative deutlich beliebter oder bekannter zu sein scheint als NativeScript.
Entwicklungsaufwand und -kosten
Der Entwicklungsaufwand einer App mit nicht-nativen Framework ist bei einer vergleichbaren App geringer als bei der nativen Entwicklung. Das liegt daran, dass man sowohl für Android als auch iOS mit nur einem Development-Team entwickeln kann, da man nur mit einer Sprache für beide Plattformen schreiben kann. Auch die Wiederverwendbarkeit von Code-Teilen führt zu einer Reduzierung der Entwicklungsdauer. Wenn man eine Anwendung mit vielen nativen Features plant, benötigt man sehr wahrscheinlich trotzdem noch weiterhin Entwickler, die nativ entwickeln können, da die Module wie bereits beschrieben in nativem Code geschrieben werden.
Dadurch, dass für beide Plattformen mit einer Sprache geschrieben werden kann, kommt man theoretisch mit einem Entwicklerteam aus. Die Entwicklungszeit pro Anwendung ist in der Regel zwar kürzer, allerdings wird man für beide Apps mehr Zeit benötigen, als wenn man zwei native Entwicklerteams parallel entwickeln lässt. Da beide hier vorgestellten Frameworks auch JavaScript basieren, kann man auch die Gehälter von JavaScript Entwicklern mit den Gehältern von nativen Entwicklern vergleichen. Bei den Gehältern erkennt man, dass JavaScript Entwickler mit ca. $80k im Jahr im Durchschnitt günstiger sind als Swift oder Kotlin Entwickler, welche jeweils ca. $90k kosten. Aufgrund der code-ähnlichen Anwendungen sind auch die Wartungskosten entsprechend geringer als bei nativen Apps.
Beispiel-App
Für die Beispiel-App wurde das Framework ReactNative gewählt. Die App wurde ebenfalls wie die native App für die Zielplattform Android entwickelt. Bei der Entwicklung traten allerdings mehr Probleme auf als bei der nativen Entwicklung. Vorkenntnisse gab es hier von Seiten des Studenten nur in der Hinsicht, dass zuvor bereits mit dem Web-Framework React entwickelt wurde.
eines leeren Projektes wurde die Projekterstellung von IntelliJ genutzt. Die Verwendung eines physischen Gerätes zum Debuggen und Previewen der App war deutlich komplizierter als bei der nativen Entwicklung und hat dementsprechend mehr Zeit gekostet. Die Dokumentation des Frameworks und auch von Third-Party-Modulen sind sehr mager gewesen, wodurch die Verwendung von Third-Party-Modulen deutlich erschwert wurde.
Auffällig war bei der Entwicklung auch, dass sehr viele Standard-Komponenten, wie sie bei der nativen Entwicklung zu finden waren, nicht vorhanden waren oder nur durch weitere Third-Party-Libraries implementiert wurden. Angenehm war bei der Entwicklung im Kontrast zu der nativen Entwicklung allerdings das hot reloading der App. Dadurch musste die App nicht immer wieder neugestartet werden, wenn Änderungen gemacht wurden, sondern diese waren beinahe sofort sichtbar.
Aufgrund der recht großen Hürden musste die Entwicklung nach den geplanten sechs Stunden abgebrochen werden, weil ein erfolgreicher Abschluss des Projektes innerhalb einer annehmbaren Zeit nicht realistisch schien. Grund dafür waren vor allem fehlende Komponenten, deren Erstellung zu lange gedauert hätte. Der Eindruck dieser Beispielentwicklung ist, dass ReactNative für kleine Projekte einen zu großen Aufwand bietet, aber vor allem durch die Wiederverwendbarkeit einzelner Komponenten bei größeren Projekten wahrscheinlich einen besseren Eindruck hinterlassen würde.
Hier nochmal der Erfüllungsgrad der einzelnen Features in einer Tabelle.
++: Feature ist vollständig umgesetzt
+-: Feature ist nur teilweise umgesetzt
--: Feature ist gar nicht umgesetzt
| Anforderung | Erfüllt | Anmerkung |
|---|---|---|
| Uhr | +- | Logik fehlt |
| Runde Progressbar | +- | Logik fehlt |
| Picker für die Zeit | +- | Dialog mit 3 Textfeldern, weil NumberPicker nicht verfügbar sind |
| Play-Button | +- | Logik fehlt |
| Reset-Button | +- | Logik fehlt |
| Vibration | -- | |
| Wecker-Ton | -- |
Wenn Sie die nächsten Artikel der Blogreihe "Technologien mobiler Anwendungen" nicht verpassen wollen, dann folgen Sie newcubator auf den Social Media Kanälen und schauen Sie regelmäßig auf unserer Blogseite vorbei. Im nächsten Artikel schauen wir uns an, wie man mobile Apps mit Cross Compile Frameworks schreibt.
