Die dritte von fünf Technologien mobiler Anwendungen, die wir in dieser Blogreihe betrachten, 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.
Die Blogreihe „Technologien mobiler Anwendungen"
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
Überblick: Cross Compile Frameworks
Ein Cross Compile Framework ist ein Framework, das Code in einer systemfremden Sprache so kompiliert, dass der Code dann von dem Zielsystem genutzt werden kann. Entweder wird der Code direkt in nativen Bytecode kompiliert, oder er wird in eine Zwischensprache umgewandelt, welche dann In-Time kompiliert wird.
Die UI (User Interface = Benutzeroberfläche) wird entweder unabhängig von den nativen Komponenten gezeichnet oder auch in die nativen Komponenten übersetzt. Cross Compile Apps können genauso wie andere Technologien, z.B. PWAs und hybride Apps für Android und iOS in App Stores bereitgestellt werden.
Vor- und Nachteile von Cross Compile Frameworks
Einer der großen Vorteile der Cross Compile Frameworks ist, dass die komplett alleinstehende Codebasis dazu führt, dass man nur mit einem einzelnen Team arbeitet. Die entstehende App kann auf mehreren Betriebssystemen wie Android und iOS eingesetzt werden.
Ein weiterer Vorteil, der daraus resultiert ist, dass die Apps auf allen Plattformen gleich funktionieren und in der gleichen Version mit dem gleichen Funktionsumfang und Inhalt bereitstehen.
Ähnlich wie bei den Apps mit 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 gegebenenfalls auch wieder nativ entwickelt werden müssen. Obwohl die Apps in quasi native mobile 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 von Cross Compile Frameworks
Bei der Entwicklung mit Cross Compile Frameworks ist man stark abhängig von Third-Party-Modulen für die nativen Features. Die gleichen Probleme bestehen auch bei Apps mit nicht-nativen Framework. Diese Abhängigkeit sollte im Hinterkopf behalten werden, bringt jedoch keine negativen Folgen für die App und ihre Entwicklung mit sich. Kontaktieren Sie uns gerne bezüglich Ihres App-Projekts, um eine Einschätzung über die Vorteile und Umsetzbarkeit für Ihre App zu erhalten.
Technologien und Markt Know-how
Ein bekanntes Beispiel für ein Cross Compile Framework ist Flutter. Flutter ist ein Open-Source Framework, von Google entwickelt und in der ebenfalls von Google entwickelten Sprache Dart geschrieben.
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. Flutter ist mit eines der bekanntesten und am weitesten verbreiteten mobile Frameworks überhaupt.
Entwicklungsaufwand und -kosten
Der Entwicklungsaufwand mit Cross Compile Frameworks ist bei weitem geringer als bei nativen Apps, da nur eine App entwickelt werden muss, deren Code für mehrere Plattformen 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 Entwickler-Team mit entsprechender Spezialisierung auf mobile Apps benötigt.
| 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 doch gerne auf Linkedin. Im nächsten Artikel schauen wir uns an, wie man Progressive Web Apps entwickelt.
Sie haben eine Produktidee für eine App und sind sich unsicher, welcher Technologie für Sie die Beste ist? Dann kontaktieren Sie uns gerne für ein unverbindliches Erstgespräch.
