Die dritte von fünf Technologien mobiler Anwendungen sind die Cross Compile Frameworks. Falls Sie die bisherigen Artikel der Blogreihe noch nicht gelesen haben, sollten Sie das auf jeden Fall nachholen. Im letzten Artikel haben wir uns zum Beispiel native Apps mit nicht-nativem Framework genauer angeschaut. Wie auch in den anderen Artikeln werden wir uns heute mit den Vor- und Nachteilen, den Risiken und Abhängigkeiten während der Entwicklung und auch das Know-How am Markt von Cross Compile Frameworks genauer anschauen. Zum Schluss werden der Entwicklungsaufwand und die Entwicklungskosten unter die Lupe genommen, bevor dann mit der Beispiel App abgeschlossen wird.
Blogreihe
Hier finden Sie die Auflistung der einzelnen Blogartikel, die zur Blogreihe gehören. Diese Agenda wird mit jedem neu veröffentlichten Artikel erweitert.
Cross Compile Frameworks
Cross Compile Frameworks
Ein Cross Compile Framework ist ein Framework, in dem man in einer systemfremden Sprache programmiert und diese wird dann so kompiliert, dass sie von dem Zielsystem genutzt werden kann. Dies wird entweder dadurch realisiert, dass der Code direkt in nativen Bytecode kompiliert wird oder in eine Zwischensprache, welche dann In-Time kompiliert wird. Die UI wird entweder unabhängig von den nativen Komponenten gezeichnet oder auch in die nativen Komponenten übersetzt. Cross Compile Apps werden genauso wie die anderen bisher vorgestellten Technologien in die App Stores geladen.
Vor- und Nachteile
Einer der großen Vorteile der Cross Compile Frameworks ist die einzelne Codebasis. Eine komplett einzelne Codebasis führt dazu, dass man nur mit einem einzelnen Team arbeitet. Ein weiterer Vorteil, der daraus resultiert ist, dass die Apps auf allen Plattformen gleich funktionieren. Die Versionen sind dadurch ebenfalls die gleichen und es hängt nicht eine Plattform hinter der anderen hinterher.
Ähnlich wie bei den nicht-nativen Frameworks ist der Zugriff auf native Features, wie Sensoren, nur über Plugins gegeben. Das bedeutet auch genauso, dass teilweise Sensoren noch nicht unterstützt werden und dann gegebenfalls auch wieder nativ entwickelt werden müssen. Obwohl die Anwendungen in quasi native Anwendungen übersetzt werden, sind Cross Compile Anwendungen typischerweise noch etwas langsamer als native Apps. Das liegt daran, dass der Code entweder In-Time kompiliert wird oder mit einer eigenen Engine läuft.
Risiken und Abhängigkeiten
Bei der Entwicklung mit Cross Compile Frameworks ist man stark abhängig von Third-Party-Modulen für die nativen Features. Die gleichen Probleme gab es auch schon bei den Apps mit nicht-nativen Framework. Es besteht zudem noch dieselbe Abhängigkeit zu den App Stores wie bereits bei den anderen Technologien.
Technologien und Markt Know-how
Beispiele für Cross Compile Frameworks sind Xamarin.Forms und Flutter. Xamarin.Forms ist ein von Microsoft entwickeltes Open-Source Framework, das auf .Net basiert und in C# geschrieben wird. Flutter ist ebenfalls ein Open-Source Framework, welches allerdings von Google entwickelt wird und in der ebenfalls von Google entwickelten Sprache Dart geschrieben wird.
Das Flutter-Framework funktioniert so, dass der in Dart geschriebene Code innerhalb einer eigenen Engine in der Dart Runtime läuft. Die UI wird anders als die bisherigen Technologien nicht durch die nativen UI Elemente dargestellt, sondern Flutter zeichnet mit einem eigenen Canvas die Elemente selbst. Da beide Frameworks Open-Source sind, haben sie jeweils ein Repository bei GitHub. Flutter hat dort 98.700 Sterne und Xamarin.Forms 4.700 Sterne.
Dieses Interesse an den Frameworks steht im Kontrast mit den Suchergebnissen bei den Joblistings. Auf Indeed werden für Flutter 179 Ergebnisse geliefert, während Xamarin 234 Ergebnisse liefert. Auf Stack Overflow liefern beide Frameworks nur etwas über 20 Ergebnisse. Diese Werte zeigen, dass obwohl Flutter ein sehr großes Interesse bei GitHub hat, es weniger oder genauso gefragt ist wie Xamarin. Xamarin scheint bei Usern nicht so beliebt zu sein wie Flutter.
Auch nach einer Statista Umfrage zeigt Flutter eine erhöhte Nutzung im Vergleich zum Vorjahr. So gaben 2019 noch 30% an Flutter zu nutzen und 2020 schon 39%. Flutter liegt mit diesen Werten auf Platz 2 der meist genutzten Cross-Plattform Frameworks, die in der Umfrage behandelt wurden.
Entwicklungsaufwand und -kosten
Der Entwicklungsaufwand ist bei weitem geringer als bei nativen Apps. Das kommt daher, dass nur eine App geschrieben werden muss, weil dieser Code dann für die jeweilige Plattform kompiliert werden kann. Dadurch dauert die Entwicklung bei einer vergleichbaren App nur noch ca. halb so lang wie bei nativen Apps. Das bedeutet gleichzeitig auch, dass die Kosten deutlich sinken. Es wird ähnlich wie bei den nicht-nativen Apps nur noch ein Team benötigt, wobei bei vielen nativen Features wieder Entwickler benötigt werden, die eventuell fehlende Plugins schreiben können.
Wie auch schon bei den nicht-nativen Frameworks sind die Entwickler für die Sprachen, die die Frameworks verwenden ein wenig günstiger als für native Sprachen. Mit $78k liegen Dart Entwickler knapp unter den JavaScript Entwicklern und C# Entwickler sind mit sogar nur $70k bei weitem günstiger.
Beispiel-App
Für die Beispiel-App wurde das Framework Flutter gewählt. Vorkenntnisse gab es wie bei der nativen Entwicklung seitens des Studenten keine. Bei der Entwicklung sind keine großartigen Probleme aufgetreten. Flutter bzw. Dart ließ sich schnell lernen, da die Dokumentationen sehr detailliert sind. Das Projekt wurde wie die anderen Projekte auch via IntelliJ initialisiert. In der App wurden alle Funktionalitäten erreicht. Third-Party-Plugins sind sehr einfach auf der Seite pub.dev zu finden. Bei der Entwicklung fiel stark das hot reloading von Flutter auf, was sehr schnell war.
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 | ++ | |
| Runde Progressbar | ++ | |
| Picker für die Zeit | ++ | |
| Play-Button | ++ | |
| Reset-Button | ++ | |
| Vibration | ++ | |
| Wecker-Ton | ++ | Über das Plugin FlutterRingtonePlayer |
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 Progressive
Web Apps schreibt.
