8 Minuten Lesezeit

Multiplattform-Frameworks: Fazit


Durch Multiplattform-Frameworks ist es möglich, mit einer Codebasis mehrere Plattformen zu bedienen. In den zuvor veröffentlichten Artikeln wurden fünf Open Source Frameworks betrachtet: React Native (React Native, 2021), Flutter (Flutter, 2021), Ionic (Ionic, 2021), .NET MAUI (Microsoft, 2021) und Quasar (Quasar, 2021). Die vorangehenden Artikel dieser Serie sind unter den folgenden Links zu finden:

Diese Frameworks unterscheiden sich in den verwendeten Technologien und Funktionalitäten. Um sie jedoch vergleichen zu können, wurde mit jedem Framework ein ähnlicher Prototyp erstellt und für die Plattformen Windows und Android gebuildet. In diesem Beitrag werden als Erstes die zugrunde liegenden Technologien und unterstützten Plattformen der Frameworks präsentiert. Im Anschluss werden die Frameworks anhand der gemachten Erfahrungen beim Erstellen und Builden des Prototypen verglichen. Abschließend wird die Erweiterbarkeit der Frameworks betrachtet und es wird ein Fazit gezogen.

Technologien

Die Frameworks verwenden verschiedene Technologien. Jedoch haben sie gemeinsam, dass für das Builden einer Android-App Android Studio inklusive eines Android-SDKs (Android Studio, 2021) benötigt wird. Abgesehen davon können die Frameworks in zwei grundlegende Kategorien geteilt werden: die Verwendung von Webtechnologien und die von anderen Technologien.

Die Webtechnologien HTML, CSS und JavaScript finden bei den Frameworks React Native, Ionic und Quasar Anwendung. Die Frameworks unterscheiden sich in den verwendeten Frontendframeworks: Während React (React, 2021) von React Native und Vue (Vue, 2021) von Quasar verwendet wird, bietet Ionic eine Integrationen für Angular (Angular, 2021), React und Vue an. Ein weiterer Unterschied besteht beim Build für mobile Geräte: Das UI von Ionic und Quasar wird als WebView über Capacitor (Capacitor, 2021) eingebunden, während React Native einen eigenen Ansatz verwendet. Ähnliches sieht es beim Build für Desktop-Systeme aus: Quasar und Ionic verwenden Electron (Electron, 2021), um Desktop-Plattformen zu bedienen.

Einen anderen Ansatz wählen Flutter und MAUI: Flutter verwendet die Programmiersprache Dart zum Beschreiben des UIs. Der Code wird im Anschluss in nativen Code beziehungsweise eine native App kompiliert. MAUI verwendet einen ähnlichen Ansatz zum Beschreiben der GUI. Dabei haben beide Frameworks gemein, dass Styling in den Beschreibungen der GUIs als auch via CSS möglich ist. Der große Unterschied zwischen diesen beiden Frameworks besteht in den verwendeten Sprachen zur Beschreibung der GUI: Flutter verwendet dafür Dart und MAUI verwendet XAML oder C#.

Abgesehen von dieser Unterteilung bieten diese Frameworks eigene Komponenten an. Diese bietet vorgefertigte Funktionalitäten an und besitzen in der Regel ein Default Styling der Komponenten für die mobilen Zielplattformen. Zum Beispiel bietet Flutter Komponenten an, die nach den Guidelines des Material Designs gestylt sind.

Ein wesentlicher Unterschied zwischen MAUI und den anderen Frameworks: Wenn bei MAUI nativer Code benötigt wird, kann dieser in C# geschrieben werden. Bei den anderen Frameworks muss dieser native Code in der Sprache der Zielplattform geschrieben werden.

  Flutter Ionic MAUI React Native Quasar
Technologien Dart

HTML

JS

XAML

C#

HTML

JS

HTML

JS

Frontendframework

Angular

React

Vue

React Vue
Styling CSS

 

Inline

CSS CSS

 

Inline

CSS CSS

Tabelle 1: Die verwendeten Technologien der Frameworks.

Unterstütze Plattformen

Die betrachteten Frameworks können die folgenden Plattformen unterstützen: Android, iOS, macOS und Windows. Die mobilen Plattformen werden von allen Frameworks unterstützt. Im Kontrast dazu gibt es Unterschiede bei der Unterstützung für Desktopsysteme. Quasar und MAUI bieten out of the box eine Unterstützung für Desktop an. Bei Flutter ist dies ebenfalls der Fall, jedoch befindet sich diese Unterstützung aktuell noch in der Beta. Ausreißer sind Ionic und React Native. Bei beiden Frameworks müssen explizit extra Pakete installiert werden, um eine App für Desktop erstellen zu können.

 

Flutter Ionic MAUI React Native Quasar

macOS

X (Beta) Extra Paket x Extra Paket x
Windows X (Beta) Extra Paket x Extra Paket

x

Android x x x x

x

iOS x x x x

x

Tabelle 2: Die Frameworks und deren unterstützten Plattformen.

Prototypenerstellung

Um die fünf Frameworks besser kennenlernen und vergleichen zu können, wurde mit jedem Framework derselbe Prototyp erstellt. Dabei hat jedes Framework eine Art Hot Reload angeboten, um die Änderungen sofort beim Speichern sichtbar zu machen. MAUI geht sogar noch einen Schritt weiter und zeigt Änderungen vor dem Speichern an, nachdem aufgehört wurde zu tippen. Jedoch lief diese Art von Hot Reload instabil und ist wie die anderen MAUI-Tools regelmäßig abgestürzt.

Grundlegend war die Erstellung der Prototypen nicht weiter kompliziert. Es konnte jederzeit die Dokumentation des jeweiligen Frameworks verwendet werden. Dabei sind die Dokumentationen sehr nützlich, da diese teilweise ausführlich beschrieben sind. Eine Ausnahme ist MAUI, da keine Dokumentation für MAUI existierte. Somit musste sich an den Beispiel-Repos von MAUI auf Github sowie der Dokumentation von Xamarin bedient werden, um Dinge abzuleiten. Ein ergänzender Faktor für die Produktivität sind die verwendeten Technologien. Da Webtechnologien bekannt sind, konnten die Prototypen in Ionic, React Native und Quasar schneller erstellt werden als in den anderen beiden Frameworks. Flutter hatte die initiale Hürde, dass Dart erlernt werden muss. Jedoch ist es nicht weiter schwierig, die Basics von Dart zu erlernen, wenn schon mit typisierten Sprache gearbeitet wurde.

Das Erstellen der Seiten war bei allen Frameworks außer MAUI einfach. Es wurde eine Datei erstellt und später in den Router integriert. Quasar ging noch einen Schritt weiter und ermöglicht das Erstellen einer Seite oder im Allgemeinen eines Elementes, über eine CLI. MAUI ist eine Ausnahme in diesem Prozess. Beim Erstellen einer Seite über die GUI wurden Xamarin-Dateien erstellt. Es mussten nicht nur die Namespaces nach jedem Hinzufügen angepasst werden, sondern es mussten mehrere Hacks in der Konfigurationsdatei des Projektes vorgenommen werden, bis die Datei erkannt wurde.

Debugging

Ebenfalls wurde das Debugging während der Entwicklung untersucht. Für das (visuelle) Debugging konnte in den meisten Fällen ein Browser, ein Emulator oder ein über WLAN oder USB verbundenes Gerät verwendet werden. Eine Ausnahme bildet MAUI, welches weder im Browser noch per WLAN gedebuggt werden kann.

Das Debuggen des Codes bei Flutter, Ionic, React Native und Quasar ist an sich recht simpel: Entweder wird eine Webseite im Browser aufgerufen oder es wird ein Gerät mit dem Browser verbunden. Im Anschluss können die Devtools des Browsers verwendet werden. Eine Besonderheit beim Debuggen im Browser besteht bei Flutter: Ergänzend zu den Browser-Devtools bietet Flutter eigene Devtools in VS Code an. Im Bezug auf das Debugging über WLAN bietet React Native einen alternativen Ansatz: Wenn Expo verwendet wird, können auf dem Endgerät selbst Devtools, vor allem für das Layout, angezeigt werden. Ein Ausreißer beim Debugging ist aktuell MAUI: Es kann zwar das interface visuell gedebuggt werden, aber Tools, die mit den Devtools eines Browsers vergleichbar sind, gibt es nicht.

  Flutter Ionic MAUI React Native Quasar
Browser x x x x
Emulator x   (x) x x
Endgerät via USB x x (x) x x
Endgerät via WLAN x X (via Expo) x

Tabelle 3: Möglichkeiten zum Debugging mit den einzelnen Frameworks.

Aufwand zum Builden

Das Builden für Windows und Android hat je nach Framework unterschiedlich viel Aufwand benötigt. Am wenigsten Aufwand gab es bei MAUI. Dort musste nur eine Zeile in der Projekt-Datei angepasst und im Anschluss über die GUI der Build gestartet werden. Flutter hingegen hat ein bisschen mehr Aufwand benötigt: Während ein Build für Windows in wenigen Befehlen innerhalb der Kommandozeile durchgeführt wurde, musste für das Builden einer APK erst ein Keystore erstellt und in die Konfiguration integriert werden. Jedoch musste im Anschluss nur ein Befehl in die Kommandozeile zum Anstoßen des Builds eingegeben werden.

Die Frameworks, die mit Webtechnologien arbeiten, benötigten den größten Aufwand beim Builden. Bei Quasar war der Build für Windows in einem Befehl erledigt. Jedoch benötigte Quasar mehr Konfigurationsaufwand, um einen Build für Android zu erstellen. Umgekehrt lief es bei Ionic: Ionic konnte ohne größeren Aufwand über die Kommandozeile und der GUI von Android Studio eine APK erstellen. Für Windows hingegen mussten mehrere Pakete händisch installiert und konfiguriert werden. Gleichzeitig mussten die Typescript-Dateien manuell kompiliert und für den Build referenziert werden. Den größten Aufwand der webbasierten Frameworks gab es bei React Native. Dort musste neben der Integration eines Keystores manuell auf das Android SDK verwiesen werden. Gleichzeitig war die verwendete Gradle-Version nicht kompatibel mit der installierten Version von Java, sodass Java 15 installiert und darauf in der Konfigurationsdatei verwiesen werden musste. Beim Windows Build von React Native musste eine entsprechende Version des Windows 10 SDKs nachinstalliert werden. Jedoch ging das Builden danach relativ einfach über die GUI von Visual Studio.

Erweiterbarkeit

Die Frameworks können unterschiedlich erweitert werden, wobei über MAUI nichts bekannt ist. Bei Flutter können Dart-Pakete nachinstalliert und verwendet werden. Ähnlich ist es bei den webbasierten Frameworks, bei denen Pakete via NPM nach installiert werden können. Unter den zur Verfügung stehenden Paketen können auch Pakete sein, die den Zugriff auf die APIs des Endgerätes ermöglichen. Bei diesen Paketen ist jedoch zu beachten, dass nicht jedes Paket auf jedem Zielsystem läuft, sodass im Code ggf. Prüfungen auf die aktuelle Zielplattform getätigt werden müssen. Zusätzlich kann es auch vorkommen, dass keine Pakete mit der gewünschten Funktionalität vorhanden sind. In solch einem Fall muss die gewünschte native Funktionalität manuell in der Sprache der Zielsysteme geschrieben werden muss.

Fazit

Unabhängig vom gewählten Framework konnte ein Prototyp erstellt und für die definierten Zielplattformen gebuildet werden. Dabei ging die Erstellung des Prototypen bei den webbasierten Frameworks schneller als bei den nicht webbasierten. Im Kontrast dazu war der Buildprozess in Flutter und MAUI viel einfacher als bei den webbasierten Frameworks. Losgelöst von den verwendeten Technologien war die Dokumentation der Frameworks ausführlich. React Native und Quasar fallen in der Dokumentation positiv auf, da Beispiele zusätzlich in einem interaktiven Editor angeboten werden oder auf eine Seite mit interaktivem Editor verlinken. Negativ fiel im Punkt der Dokumentation MAUI auf, da diese noch nicht existierte.

Flutter, Ionic, React Native und Quasar sind problemlos in der Produktion einsetzbar. Insbesondere für mobile Geräte ist dies der Fall. Wenn jedoch ebenfalls Desktop-Geräte bedient werden sollen, dann sollte aktuell von Flutter abgesehen werden, da sich die Unterstützung für Desktop-Builds noch in der Beta befindet. MAUI hingegen sollte aktuell in keinem Fall für die Produktion eingesetzt werden, da es aktuell nur in einer Preview Version mit instabilen Tooling verfügbar ist.

Referenzen

Android Studio (2021). https://developer.android.com/studio/. (Stand: 15.10.2021).

Angular (2021). https://angular.io/. (Stand: 15.10.2021).

Capacitor (2021). https://capacitorjs.com/. (Stand: 15.10.2021).

Electron (2021). https://www.electronjs.org/. (Stand: 15.10.2021).

Flutter (2021). https://flutter.dev/. (Stand: 15.10.2021).

Ionic (2021). https://ionicframework.com/. (Stand: 15.10.2021).

Microsoft (2021). https://docs.microsoft.com/en-us/dotnet/maui/. (Stand: 15.10.2021).

React (2021). https://reactjs.org/. (Stand: 15.10.2021).

React Native (2021). https://reactnative.dev/. (Stand: 15.10.2021).

Quasar (2021). https://quasar.dev/. (Stand: 15.10.2021).

Vue (2021). https://vuejs.org/. (Stand: 15.10.2021).

 
Bild von Jeffrey Pluntke
Jeffrey Pluntke Jeffrey Pluntke hat 2021 ein Masterstudium der Medieninformatik abgeschlossen und ist seitdem bei der HanseVision als Entwickler tätig. Dort entwickelt er individuelle Softwarelösungen für die Kunden und bringt seine Expertise im Bereich Usability ein, um die Gebrauchstauglichkeit dieser Lösungen zu verbessern. Alle Artikel des Autors

Ähnliche Blog-Artikel

Mit unserem HanseVision Update sind Sie immer gut informiert über alle Themen rund um moderne Zusammenarbeit, kluge Köpfe, Lösungen und Tools, Referenzen und Aktionen.

Jetzt zum Newsletter anmelden
Updates & Aktionen
Versand alle 4-6 Wochen
Trends & aktuelle Entwicklungen