07.12.2015

Hybride Web-Applikationen - das Beste aus allen Welten f√ľr die Entwicklung von mobilen Apps

Die Entwickler von mobilen Applikationen stehen vor einem Dilemma. Die Landschaft der Mobilger√§te ist stark fragmentiert und ver√§ndert sich schnell. Um sicherzugehen, dass ein m√∂glichst gro√üer Bereich des Markts abgedeckt wird, m√ľssen Applikationen mehrere Betriebssystem-Umgebungen unterst√ľtzen - zum Beispiel Android, iOS und BlackBerry OS. Jedoch haben diese Umgebungen verschiedene Architekturen und Anwendungs-Programmierschnittstellen (APIs), und das macht es schwer, ein einziges St√ľck Source-Code sauber so zum Kompilieren zu bringen, dass es auf verschiedenen Ger√§ten l√§uft.



Autor: Tuukka Ahoniemi, The Qt Company


Die Entwicklung nativer Anwendungen mit Sprachen wie C++ und Objective-C liefert die beste Performance und Integration mit dem Host-Betriebssystem, doch sie erfordert Aufwand und Kosten. Das Entwicklungsteam muss die detaillierte Architektur des Betriebssystems verstehen und seine spezifischen APIs sowie seine Programmiersprache verwenden. √úber die Unterschiede hinaus, wie APIs angeboten werden, kann sich auch das Design der gesamten Architektur einer Applikation f√ľr ein Betriebssystem unterscheiden.



Große Leistung ist mit großem Portier-Aufwand verbunden

Das bedeutet, dass es nicht notwendigerweise praktikabel ist, zum Portieren lediglich den Applikations-Code mit einem anderen Satz von APIs zu replizieren, sondern er muss vielmehr komplett neu designt werden. Das macht es nat√ľrlich noch schwieriger, ein konsistentes Verhalten √ľber die vielf√§ltigen Zielsysteme zu unterst√ľtzen, da alle Bugfixes und neuen Features f√ľr alle Ziel-Plattformen unterschiedlich entwickelt, implementiert und Programmfehler stets neu bereinigt werden m√ľssen.


Selbst bei einer einzigen Plattform ziehen Updates des Betriebssystems häufige Modifikationen der Applikation nach sich, um neue User-Interface-Techniken nutzen sowie die bisherige Optik und Haptik (das "Look-and-Feel") der nativen Apps der Plattform beibehalten zu können.


Bei einer Applikation im nativen Code m√ľssen die Entwickler sorgf√§ltig auf m√∂gliche √Ąnderungen der zugrundeliegenden APIs achten, die sie verwendet haben, um sicherzustellen, dass jedes nachfolgende Update weder die Performance beeintr√§chtigt noch Fehler einf√ľhrt. Dazu braucht man irgendeine Methode, um die Details des zugrundeliegenden Betriebssystems zu abstrahieren, damit eine einzige Codebasis √ľber mehrere Ziele hinweg laufen kann.


Es haben Versuche stattgefunden, um eine plattform√ľbergreifende Portierbarkeit f√ľr Applikationen auf der Sprachebene bereitzustellen, doch war deren Akzeptanz nur sehr gering. Zum Beispiel findet Java mittlerweile verbreitet auf Servern Verwendung, doch neigen Entwickler, die sich auf das Design von Client-Applikationen f√ľr Desktop-Computer konzentrieren, nach wie vor dazu, bei den nativen Sprachen und APIs von Windows, Linux und OS X zu bleiben.


Native Sprachen zeichnen sich generell durch eine h√∂here Performance und direkten Zugriff auf Ressourcen des Betriebssystems aus und bieten dadurch den Vorteil, dass sie die nativen User-Interfache-(UI-)Elemente einsetzen und folglich zu einer gleichbleibenden Optik auch bei den anderen Applikationen im System f√ľhren. Eine auf Windows laufende App sollte wie eine Windows-App aussehen, w√§hrend andererseits Java-basierte Applikationen dem Kernbetriebssystem fremd erscheinen.







Auch HTML5 ist kein Patentrezept

Mit dem Aufkommen des Smartphones und deren Fokus auf Web-taugliche Apps stieg die Hoffnung, dass die HyperText Markup Language (HTML) vielleicht die Basis einer gemeinsamen Anwendungsentwicklungssprache und API bilden könnte.


Durch die Kombination von Javascript, HTML Markup und Cascading StyleSheet (CSS) Version 3-Definitionen erm√∂glicht es HTML5, Rich-Media-Applikationen auf jeder beliebigen mobilen Plattform einzurichten, die den Standard durchg√§ngig und in vollem Umfang unterst√ľtzt. Doch wenngleich sich die konsistente Interpretation von HTML5-Definitionen durch Browser auf verschiedenen Plattformen in den letzten Jahren verbessert hat ‚Äď dabei war bei einigen Apps in der mobilen Umgebung der weitverbreitete Einsatz der Open-Source WebKit-Browsertechnologie hilfreich ‚Äď bestehen immer noch Unterschiede in der internen Implementierung der Features sowie ein Wettbewerb zwischen den verschiedenen Ports der Browser-Engines.


Beispielsweise zweigte Google seine eigene Browser-Engine Blink vom WebKit-Projekt ab und nahm eine Reihe von Partnern mit, die ebenfalls Beitr√§ge einbrachten, w√§hrend Apple und ihre Plattform auf dem urspr√ľnglichen, unver√§nderten WebKit verblieben. Das erh√∂hte wiederum die Fragmentierung der Web-Technologie, mit der sich Applikationsentwickler abm√ľhen m√ľssen, wenn sie verschiedene Browser-Implementierungen ins Auge fassen.






Browser-Implementierungen ...

k√∂nnen sich auf ganze einfache Weise voneinander unterscheiden, so etwa darin, wie sie Formel-Elemente interpretieren. Zum Beispiel k√∂nnen Browser m√∂glicherweise hochentwickeltere Datentypen in Formeln wie die Spezifizierung der Wochentage nicht verarbeiten. √Ąhnlich k√∂nnen etwa verschiedene Anzeigeelemente fehlen oder sie werden nur zum Teil unterst√ľtzt.


Zwar können die Funktionen derartiger Elemente häufig mithilfe kundenspezifischer CSS und JavaScript emuliert werden, doch das verlängert den Entwicklungszyklus und erfordert die Verwendung von Browserweichen-Code auf dem Server oder komplexeres JavaScript auf dem mobilen Client, damit die Applikation korrekt wiedergegeben wird.



Die Anspr√ľche komplizierterer Applikationen...

wie die Ereignisverarbeitung, Animationen und Videos werden von einigen Browsern v√∂llig unterschiedlich verarbeitet; sie ben√∂tigen ma√ügeschneiderte Entwicklungsarbeit, um eine effektive Emulation dieser Features zu erzielen. Ein weiteres, grunds√§tzlicheres Problem beim Einsatz von HTML5 f√ľr die Entwicklung mobiler Applikationen besteht darin, dass es eine funktionierenden Internet-Verbindung voraussetzt.


Das mag f√ľr Apps angebracht sein, die ein Daten-Feed in Echtzeit bieten. Die Verwendung von vom Server geliefertem HTML5 kann f√ľr Applikationen von Vorteil sein, bei denen regelm√§√üige Updates der Software w√ľnschenswert sind, weil der neue Code eingesetzt werden kann, ohne dass er von einem App-Store-Anbieter vorab genehmigt werden muss.


Hingegen ist die Voraussetzung einer aktiven Internet-Verbindung ein Nachteil f√ľr Software, die eigenst√§ndiger ist, etwa bei einem Spiel mit nur einem Nutzer, besonders auch deshalb, weil die User die Internetverbindung beim Herumwandern h√§ufig unterbrechen, um ihre Kosten bei ihrem Betreiber unter Kontrolle zu halten.


Nativer Code, der auf dem mobilen Ger√§t selbst gespeichert ist, erlaubt eine wesentlich feink√∂rnigere Steuerung des Netzwerkzugriffs. √Ąhnlich lassen sich Sicherheits-Features sowie der Zugriff auf I/O und die Peripherie des Ger√§ts unter Verwendung von nativem Code einfacher implementieren als mit HTML5. In manchen F√§llen besteht eine M√∂glichkeit, √ľber HTML5 auf bestimmte Peripherieger√§te, zum Beispiel die Kamera, zuzugreifen.





Andererseits bietet HTML5 ...

gegen√ľber nativen L√∂sungsans√§tzen den Vorteil eines dynamischeren Inhalts sowie die M√∂glichkeit, den Content innerhalb jedes beliebigen Web-Browsers au√üerhalb der mobilen Applikation laufen zu lassen. Sollte die Anwenderschnittstelle der App Teile enthalten, die in einer regul√§ren Website gezeigt oder angewandt werden sollten, k√∂nnten native UI-Methoden in den Browser √ľbernommen werden.


HTML5 erm√∂glicht die Wiederverwendung von regul√§ren Webseiten-Features und Inhalten direkt innerhalb der mobilen Applikation. Eine HTML5-UI ist deshalb oft dynamischer und ‚Äď wegen ihrer zuweilen problematischen Online-Anforderung -andauernd aktualisiert und festgelegt, weil eine neue Version des Markups jedes Mal dann vom Server geladen werden kann, ohne dass der Applikations-Code rekompiliert und neu eingef√ľgt werden muss.






Hybride Applikationen- mit Surf-and-Turf liegt man niemals falsch

F√ľr viele Entwicklungs-Teams ist es sinnvoll, einen hybriden L√∂sungsansatz einzusetzen. Manche Teile der App werden in nativem Code implementiert, um die Performance zu unterst√ľtzen und um eine wesentlich feink√∂rnigere Steuerung der Software auf der Zielplattform zu erreichen. Andere Teile k√∂nnten dagegen die reichhaltigen, Netzwerk-orientierten Funktionen von HTML5 nutzen, um Echtzeit-Daten mit Servern auszutauschen und eine rasche, nahtlose Aktualisierung des Codes zu erlauben.


Die Frage ist nur, wie das auf eine Art und Weise erreicht werden kann, die einen einfachen Einsatz auf multiplen Plattformen erlaubt, ohne dass jedes Mal signifikante Teile neu geschrieben oder ein erheblicher Portieraufwand getrieben werden m√ľssen.


Kendo UI (1) zufolge werden 32 Prozent der mobilen Applikationen unter Einsatz einer hybriden Strategie entwickelt, wobei HTML5-Code neben nativem Code l√§uft. Bei weiteren 17 Prozent kommt eine andere Art der hybriden Strategie zur Anwendung, bei der f√ľhrende Plattformen eine native codierte Software mit einer ‚ÄėCatch All‚Äô- HTML5-Implementierung verbinden, wie sie in weniger bekannten Plattformen Verwendung findet. Gartner (2) hat vorhergesagt, dass bis 2016 mehr als 50 Prozent der verwendeten mobilen Applikationen hybrid ausgef√ľhrt sein werden.


Die Antwort auf die Frage, wie man hybride oder rein native Strategien zum Laufen bringt, liegt im Einsatz eines Applikationsentwicklungs-Frameworks, das von Grund auf f√ľr plattform√ľbergreifende L√∂sungen designt wurde. Das vermeidet die Einschr√§nkungen des propriet√§ren nativen Softwaremodells und bietet eine Vielfalt von Implementiersprachen, die sich f√ľr die hybride Applikationsentwicklung eignen.


Eines dieser Frameworks ist das Open-Source Qt, das im Laufe von mehr als zehn Jahren eine bewährte und ausgereifte Cross-Plattform-Codebasis aufgebaut hat. Qt wurde nicht nur in Mobiltelefonen verwendet, sondern auch in so unterschiedlichen Systemen wie digitalen Fotorahmen, medizinischen Geräten, Netzwerk-Analysatoren und Fernseh-Set-Top-Boxen.



Qt - das Beste aus allen Welten

Qt 5 bietet eine vollst√§ndige Entwicklungsumgebung sowie einen Satz von Bibliotheken, welche die Entwickler in die Lage versetzen, sich f√ľr eine Codebasis zu entscheiden und sie auf mehreren mobile Plattformen anzuwenden, einschlie√ülich iOS, Android und BlackBerry. Um Entwickler mit der Flexibilit√§t auszustatten, die sie von einer hybriden Applikations-Architektur erwarten, umfasst Qt 5 Techniken, mit denen sie sowohl von der nativen Entwicklung als auch von HTML her vertraut sind, wobei jedoch die Unterschiede in der Plattformunterst√ľtzung entfernt wurden.


Über eine herkömmlichere API hinaus, die mit Sprachen wie C++ mit Zugriff auf Schnittstellenelemente, I/O und Sicherheitsfunktionen hinaus bietet Qt5 das Qt Quick-Framework, das auf einer deklarativen Sprache mit der Bezeichnung QML basiert. QML erleichtert die Schaffung von Rich-Media-Anwenderschnittstellen erheblich und kann vom User-Interface-Designer und vom Softwareentwickler gemeinsam genutzt werden.


Wie HTML5 enth√§lt QML sowohl JavaScript als auch Markup zum Bau von interaktiven Schnittstellen, welche die Kern-C++-Bibliotheken ebenso nutzen wie den OpenGL ES-Rendering-Support, der inzwischen in vielen mobilen Ger√§ten verf√ľgbar ist. Doch im Gegensatz zu HTML5 wurde QML speziell zur Erzeugung moderner, Touch-basierter Anwender-Schnittstellen entwickelt und bietet einen produktiven Satz von Features zur Erstellung von Nutzschnittstellen mit √úberg√§ngen, Animationen oder Zustandsautomaten.


Dar√ľber hinaus ist QML gut in Web-Technologien integriert und erlaubt einen Integration von dynamischem Web-Content, selbst wenn dieser entweder direkt mit HTML5 geschrieben wurde, und es kann JavaScript-Code zur Durchf√ľhrung von Business-Logik-Operationen verwendet werden. Das erm√∂glicht die direkte Wiederverwendung von Web-Dokumenten. Nachdem Qt 5 das in weitem Umfang eingesetzte JSON-Format (JavaScript Object Notation) nativ unterst√ľtzt, erfolgt eine Integration in REST-APIs von Online-Web-Service nahtlos direkt vom QML- oder C++-Backend-Code.



Der entscheidende Vorteil beim Einsatz von Qt 5 und Qt Quick liegt darin, dass sie Entwicklern eine durchg√§ngige Entwicklungsumgebung bieten, das Plattformen mobiler Ger√§te zugeordnet ist. Entwickler k√∂nnen eine hybride Strategie einsetzen, indem sie C++ mit dem Qt 5-Framework f√ľr Code nutzen, der Zugriff auf Kern-Ger√§teservices erfordert. Andere Teile k√∂nnen in QML geschrieben werden, das dann f√ľr eine High-Performance 2D- oder 3D-Graphik sowohl auf HTML5 als auch auf WebGL abgebildet wird.


Durch das Schreiben von QML sind Entwickler vor Inkonsistenz im HTML5-Support gesch√ľtzt. Sie erhalten die Plattform-Unabh√§ngigkeit, die man sich urspr√ľnglich von HTML5 erwartete. F√ľr Use-Cases, die HTML5-basierte Dokumente f√ľr eine Web-Schnittstelle ben√∂tigen, bietet Qt nahtlose Integration, die ein Einbetten dieser in dynamische Teil einer in QML geschriebenen UI erlaubt.


Beim Einsatz einer hybriden Strategie f√ľr mobile Applikationen k√∂nnen Entwickler das Beste aus beiden Welten erreichen. Und die Verwendung eines plattform√ľbergreifenden Frameworks wie Qt 5 kann Entwicklern die Aufgabe erleichtern, hybride Strategien √ľber die immer komplizierteren Mobilger√§te-Umgebungen hinweg zu implementieren.


(1) Kendo UI Global Developer Survey 2013

(2) www.gartner.com/newsroom/id/2324917

Einen √úberblick √ľber die Qt-Tools gibt das unten angef√ľgte PDF.

 

 


 


--> -->