Hybride Apps – die All-In-One-Lösung für Frontends
Die Benutzeroberfläche eines Systems und dessen Frontend-Lösungen sind die Schnittstelle zu dem Nutzer und dessen Endgerät. Kaum eine Komponente in einer Anwendung hat eine höhere Bedeutung für die Akzeptanz einer Software und damit den Erfolg oder Misserfolg dieser.
Seit knapp zehn Jahren dominieren Web-Anwendungen und mobile Apps. Fast scheint es so, als ob die üblichen Desktop-Anwendungen so weit ausgedient haben. Doch diese Vielzahl an Plattformen und Geräten stellt Entwickler auch vor ihre Herausforderungen. In diesem Artikel möchte ich darauf eingehen, wie das Konzept von hybriden Web-Apps hier eine allgemeine Codebasis schaffen und damit benutzerfreundliche Oberflächen auf mehrere Plattformen gleichzeitig gebaut werden können.
Historie und Komplexität der Benutzeroberflächen
Bevor wir jedoch einen genauen Blick darauf werfen, müssen wir uns ein paar Gedanken zu Benutzeroberflächen und deren Historie machen. Schauen wir zurück auf die Anfänge des User-Interface-Designs.
In den 70er und 80er Jahren dominierten Terminal-Eingaben und damit textbasierte Konsolen. Diese wurden rein über die Tastatur bedient und hatten meist ein plattformspezifisches Raster an Zeichen pro Zeile und Zeilen. Hier war das Thema Usability natürlich kein Thema – die Aufgabe musste erfüllt werden. Genauso simpel war die Varianz der Geräte und Plattformen.
Mit den grafischen Benutzeroberflächen der 90er Jahre kamen die Desktop-Anwendungen. Auch durch die große Verbreitung von Microsoft Windows hatten Entwickler kaum eine Variation an Endgeräten, Displaygrößen und Auflösungen, die sie unterstützen mussten. Anwendungen konnten so "Pixel für Pixel" designt werden und gingen so an die User. Von Skalierung oder anderen Themen war man relativ weit entfernt. Mehr als eine Handvoll Bildschirmauflösungen und Farbabstufungen, sowie die Bedienung mit Maus und Tastatur musste hier nicht bedacht werden.
In den 2000ern wurden immer mehr Business-Anwendungen als Web-Anwendungen umgesetzt. Damals jedoch waren die Technologien wie JavaScript und auch die Darstellungen via HTML/CSS noch ziemlich in den Kinderschuhen. Selbst für einfache User-Interfaces musste im Vergleich zu heute ein relativ hoher Aufwand betrieben werden. Diese Anwendungen wurden dabei noch zu einem großen Teil serverseitig gerendert, was natürlich auch dazu geführt hat, dass die Performance dieser Anwendungen weit hinter den Desktop-Anwendungen lag.
Seit Ende der 2000er Jahre und dem Aufkommen von Smartphones und Tablets, ist klar – die Welt geht mobil. Web-Anwendungen und mobile Apps für Smartphones und Tablets sind die Wahl, wenn es um moderne Frontend-Lösungen geht. Jahrelang war hier das übliche Vorgehen, eine Web- oder Desktop-Anwendung umzusetzen und parallel dazu für die vorherrschenden Plattformen iOS und Android native Apps umzusetzen.
Warum nicht dreimal entwickeln?
Durch diese Methode war es nicht selten so, dass zum einen Geschäftslogiken mehrfach umgesetzt werden mussten. Dies führt je nach Plattform immer wieder zu unterschiedlichen Funktionen und im schlechtesten Falle zu unterschiedlichem Verhalten. Zum anderen war der Aufbau des Know-hows in Unternehmen oder Softwarehäusern äußerst schwierig, da hierfür entsprechende Kompetenz für alle zu bedienenden Plattformen aufgebaut werden musste und dabei unterschiedliche Teams entstanden.
Seit Anfang der 2010er Jahren haben sich die Web-Frameworks stark entwickelt. Moderne Entwicklungsparadigmen wurden eingesetzt und die Funktionen browserübergreifend drastisch erweitert. Aus diesem Grunde entstanden zu jener Zeit die ersten Hybrid-App-Frameworks.
Was ist eine Hybrid-App?
Als Hybrid-App versteht man eine (Web-)Anwendung, welche mittels einer Codebasis auf mehreren Plattformen lauffähig ist und entsprechend der eingesetzten Plattform native Schnittstellen sowie ein möglichst natives Look-and-feel bietet. Um dies zu erreichen, wird hauptsächlich auf die Bausteine und Sprachen gesetzt, die jede Plattform unterstützt – HTML, CSS und JavaScript. Es werden demnach Web-Applikationen gebaut, die dann später als Progressive Web App (PWA), iOS-Anwendung, Android-Anwendung oder sogar als Desktop-Anwendung genutzt werden können. Man ermöglicht also, in einer Web-Anwendung auf native Schnittstellen wie z. B. das Dateisystem, Bluetooth, NFC usw. zuzugreifen und kann so eine Anwendung für sämtliche Plattformen designen und entwickeln.
Um diese native Funktionalität bereitstellen zu können, muss die Anwendung immer in einem entsprechenden Container bzw. Runtime laufen. Bei einer PWA ist das logischerweise der installierte Browser, bei einer iOS- oder Android-Anwendung muss eine native Applikation die Fassade der Web-Applikation übernehmen. Für diesen Fall steht das Framework Capacitor zur Verfügung [1]. Dieses Projekt stammt ursprünglich aus dem Apache-Cordova-Projekt und wurde nach Beendigung dessen als Capacitor fortgeführt und weiterentwickelt.
Ionic und Capacitor als Dream-Team
Um eine solche Anwendung umsetzen zu können, empfiehlt es sich, auf ein vollständiges Hybrid-App-Framework zurückzugreifen. Diese Web-Frameworks haben zum einen die Aufgabe, den Entwickler bei der Strukturierung und Architektur des Codes zu unterstützen, sowie die notwendigen Abhängigkeiten zu den jeweiligen Plattformen zu abstrahieren. Ebenfalls bieten diese Frameworks umfassende UI-Libraries an, um ein modernes und natives Look-and-feel umsetzen zu können.
Eines der bekanntesten Frameworks hierfür ist Ionic. Diese Bibliothek wurde ursprünglich als reines Angular-Framework entwickelt und ist eng mit Capacitor verzahnt (Capacitor wird von Ionic betrieben und entwickelt). Mittlerweile ist Ionic in seiner Struktur so abstrahiert worden, dass neben Angular nun auch React oder VueJS eingesetzt werden können. Hier sollte also jeder sein präferiertes Framework finden.
Die Hauptaufgabe von Ionic ist, die Darstellung und grundsätzliche UI-Komponenten bereitzustellen. Diese passen sich ebenfalls der gewünschten Plattform an und können auch individuell angepasst werden. Da man hier native Web-Anwendungen entwickelt und auf die vollen Funktionen von z. B. Angular und HTML, CSS und JavaScript/TypeScript zurückgreifen kann, können hochfunktionale und flexible Anwendungen gestaltet werden. In diesem Umfeld gibt es kaum eine Bibliothek, die es nicht gibt. Möchte man z. B. eine bestimmte 3rd-Party-Control eines anderen Anbieters nutzen, ist dies durch die Modularität natürlich kein Problem. Benötigt man bestimmte Bibliotheken, um spezialisierte Funktionen bereitstellen zu können? Sobald diese mindestens als JavaScript lauffähig sind, ist das auch kein Problem.
Hybride App für den Browser? Hier ein Selbstverständnis
Wie bereits erwähnt, baut man demnach reine Web-Anwendungen. Aus diesem Grund ist die Nutzung der Anwendung in einem Web-Browser auch kein Problem. Durch die statischen Client-Anwendungen kann so eine Anwendung auf einem einfachen Hosting oder CDN bereitgestellt werden. Viele Cloud-Anbieter bieten bereits eine vollständige Integration in GitLab oder GitHub an, wodurch die Anwendung automatisiert gebaut und auf dem Server bereitgestellt werden kann.
Mit Capacitor in die native Welt
Wie wir also sehen, übernimmt Ionic so gesehen, alles, was webbasiert geschieht, während Capacitor die native Runtime für die einzelnen Plattformen bietet. Capacitor baut hierbei tatsächlich native App-Projekte für iOS (XCode-Projekt) und Android (Android-Studio-Projekt) auf und arbeitet mit den nativen SDKs und Tools. Letzten Endes wird die Web-Applikation in ein vorgesehenes Verzeichnis kopiert, worauf sich die native Anwendung bezieht.
Um nun native Funktionalitäten bereitstellen zu können, stehen eine Vielzahl an Capacitor-Plugins zur Verfügung. Diese Plugins bestehen aus tatsächlich nativem Code für die einzelnen Plattformen, sowie eine Abstraktionsschicht für die JavaScript/TypeScript-Integration. Der Entwickler selbst nutzt demnach die APIs, welche für JavaScript und TypeScript (teilweise auch als Angular-Modul) zur Verfügung stehen, um mit den nativen Schnittstellen zu interagieren. In den nativen Projektvorlagen wird der tatsächliche native Code über Capacitor eingebracht. Dadurch koppelt Capacitor die API-Aufrufe mit den nativen Logiken für die jeweilige Plattform.
Hiermit kann eine Vielzahl an nativen Plugins verwendet werden, welche von einfachen Themen wie File-System-Zugriff, über Barcode-Scanner bis hin zu Zahlungen mit Zahlungs-Terminals, verschiedene Anwendungsfälle übernehmen.
Und was ist mit Desktop?
Aus der Erfahrung heraus zeigt sich, dass webbasierte und mobile Anwendungen vollkommen ausreichend sind. Die wenigsten Teams bauen hier noch eine weitere Desktop-Anwendung. Sollte dies aber z. B. aufgrund nativer Schnittstellen zwingend erforderlich sein, so kann Electron dafür verwendet werden. Electron ist das Pendant zu Capacitor, wenn es um Desktop-Apps für Windows, macOS oder Linux geht. Diverse Anwendungen, welche wir tagtäglich verwenden, werden als Electron-Anwendung ausgeführt. Hierzu zählen z. B. Microsoft Teams oder Visual Studio Code.
Ionic selbst unterstützt keine direkten Tools, um die eigene Anwendung mittels Electron-Anwendung lauffähig zu machen. Jedoch existieren zahlreiche Tutorials und Anleitungen, wie eine Electron-Umgebung aufgebaut werden kann. Immerhin handelt es sich schlussendlich um eine einfache, statische Web-Applikation, die über Electron gehostet werden soll.
Warum hybride Web-Apps und was ist mit anderen Cross-Plattform-Frameworks?
Neben dem nativen Web-Ansatz existieren auch andere Cross-Plattform-Bibliotheken, wie z. B. Xamarin. Der native Web-Ansatz hat entgegen den anderen Frameworks einige bedeutende Vorteile. Zum einen entwickelt man in der tatsächlich ausgeführten Programmiersprache (bis auf die Nutzung nativer Plugins) und man kann auf die komplette Welt von HTML, CSS und JavaScript/TypeScript zurückgreifen. Bedeutet, egal welche UI-Komponente nicht exakt meinen Wünschen entspricht – über CSS kann ich das Design feingranular ändern und meinen Vorstellungen anpassen. Mittels JavaScript und TypeScript steht eine unermessliche Zahl an Libraries und Schnittstellen zur Verfügung. Dadurch ist die Flexibilität und Langlebigkeit der eigenen Anwendung auf Jahre sichergestellt.
Die konkurrierenden Frameworks hingegen arbeiten oft mittels Konvertierung der Anwendung in nativen Code. Sprich, UI-Elemente, werden z. B. auf Basis von XAML definiert und dann nativ konvertiert. Demnach findet man sich bei den Features oft beim kleinsten gemeinsamen Nenner wieder. Auch die Anpassungsfähigkeit von 3rd-Party-Libraries ist dahingehend begrenzt und man ist auf die Implementierung des Lieferanten angewiesen.
Fazit
Wer nachhaltige App-Lösungen für seinen Anwendungsbereich umsetzen möchte, kommt um den hybriden Web-Ansatz kaum herum. Nicht nur bietet es sämtliche Freiheiten und Möglichkeiten aus der Webentwicklung. Auch das Know-how für diese Umgebungen existiert und ist allgemein bekannt. Ein Web-Entwickler kann so mit wenig Einarbeitung zu einem vollumfänglichen App-Entwickler werden. Dies spiegelt auch den Plattform-Gedanken wider, den viele Unternehmen bereits verfolgen – keine Insellösungen, sondern ganzheitliche Ökosysteme für sämtliche Produktreihen oder gar das gesamte Unternehmen.
