Da ich relativ neu in der html5- und mobilen Entwicklung bin, habe ich auf der QCon-Konferenz in San Fransisco eine hervorragende Gelegenheit gesehen, mich über die neuesten Trends zu informieren. In diesem Blog werde ich die Erkenntnisse teilen, die ich auf der Konferenz gewonnen habe. Nach der Lektüre sollten Sie einen Überblick über die folgenden Themen haben:
- wo html5 derzeit steht und wohin es sich in Bezug auf die mobile Entwicklung entwickelt
- die Vor- und Nachteile von html5 für Web-Apps im Vergleich zu nativen Apps
- wie man einige der Unzulänglichkeiten von html5 in Bezug auf native Anwendungen überbrücken kann
- wertvolle Hinweise auf Ressourcen, die Ihnen den Einstieg in die mobile html5-Entwicklung erleichtern
Gesamteindruck
Nachdem ich mehrere Sitzungen zum Thema html5 und Mobile verfolgt hatte, fühlte ich mich wie auf einer riesigen Autobahn, die sich noch im Bau befindet. Ich bekam eine Vorstellung davon, wie das Endergebnis aussehen wird, aber in der Zwischenzeit müssen wir Hindernisse umfahren, wechselnde Umwege in Kauf nehmen, das Risiko eingehen, in Sackgassen zu landen und uns ständig Sorgen machen, ob das gewählte Fahrzeug, unser Browser, die frisch geteerten Fahrbahnen (html5-Standards) bewältigen kann. Nichtsdestotrotz wurde deutlich, dass das Web in Bewegung ist und großartige neue Möglichkeiten darauf warten, genutzt zu werden.
Von html4 zu html5: der Paradigmenwechsel
Die klassische Web-Architektur für html4-Anwendungen basiert auf einem dokumentenzentrierten Ansatz, bei dem Client-Browser html-Dokumente vom Server anfordern und einfach rendern. Der Server kümmert sich um den gesamten Konversationsstatus und die Geschäftslogik, während der Client nichts weiter als eine dumme Rendering-Engine ist. Html5 bietet im Gegensatz dazu eine wirklich zustandsorientierte Laufzeitumgebung. Dies ermöglicht einen Wechsel von einem dokumentenzentrierten Anfrage/Antwort-Ansatz zu einem anwendungszentrierten Ansatz, bei dem die Daten synchronisiert werden, wenn eine Verbindung besteht, anstatt sie ständig vom Server anzufordern. Mit anderen Worten: Die html5-Laufzeitumgebung bietet Unterstützung für Rich Clients, die eigenständig und ohne Verbindung arbeiten können. Die klassische Web-Architektur ist weder besonders veraltet noch schlecht. Es gibt durchaus Fälle, in denen zustandslose Clients sinnvoll sind. Durch die Unterstützung zustandsbehafteter Funktionen kommt Html5 jedoch viel näher an native Anwendungen heran, die von Natur aus zustandsbehaftet sind. Statefulness eröffnet eine Vielzahl neuer Möglichkeiten und Anwendungen, die alle in Reichweite des Webentwicklers liegen. Lassen Sie uns kurz auf die zustandsabhängigen Funktionen von html5 eingehen.
Html5 und Staat
Im folgenden Abschnitt beschreibe ich die wichtigsten zustandsbehafteten Funktionen, die html5 bietet und die für mobile Geräte entscheidend sind, um konnektivitätsunabhängig zu sein:
Anwendungs-Cache
Die Anwendungs-Cache-Funktion von html5 ermöglicht es, Dateien vorab von einem Server abzurufen. Sie ähnelt den Browser-Caches, mit dem entscheidenden Unterschied, dass Sie jede beliebige Datei eifrig abrufen können. Eine Cache-Manifestdatei wird verwendet, um eine Auswahl von Dateien zu konfigurieren, die vorab geladen werden müssen, unabhängig davon, ob sie vom Markup verwendet werden oder nicht.
WebStorage
WebStorage ist eine einfache API, um kleine Mengen von Textinformationen in einem Name/Wert-Paar-Format lokal zu speichern. Dies bietet eine breite Palette von Möglichkeiten. Stellen Sie sich vor, Sie haben einen Assistenten, der aus mehreren Seiten besteht. Alle Zwischendaten lassen sich mit Hilfe der WebStorage-API einfach speichern. Stellen Sie sich außerdem vor, Sie haben den Assistenten abgeschlossen und möchten das Formular abschicken, aber es besteht keine Verbindung. Mit WebStorage speichern Sie einfach das Formular und zeigen dem Benutzer eine Meldung an, dass der Inhalt des Formulars übermittelt wird, sobald die Verbindung wiederhergestellt ist.
Konnektivität und Offline/Online-Ereignisse
Der Status der aktuellen Konnektivität kann mit Offline/Online-Ereignissen überprüft werden. Diese Ereignisse gehen Hand in Hand mit WebStorage. Anstatt sich auf die Konnektivität zu verlassen, könnte der Anwendungsstatus, wie z.B. Formulardaten, vor dem Senden immer lokal gespeichert werden. Vor dem Senden prüfen wir den Verbindungsstatus. Falls keine Verbindung besteht, warten wir auf ein Online-Ereignis, bevor der Status mit dem Server synchronisiert wird.
Datei-API
Mit der Datei-API können Sie lokale Dateien lesen und den Inhalt direkt einem HTML-Element zuweisen oder auf einer Leinwand darstellen.
IndexedDB
IndexedDB ist ein schlanker Objektspeicher, der Daten in Form von Schlüssel-/Objektpaaren speichert. Alle Schlüssel sind indiziert. Abfragen können nur auf Schlüssel und nicht auf das Objekt selbst durchgeführt werden. Im Vergleich zur WebStorage-API sollte IndexedDB größere Datensätze ermöglichen, die lokal gespeichert und abgefragt werden können.
Aktuelle Unterstützung für html5' zustandsabhängige Funktionen
Fast alle aktuellen mobilen Browser unterstützen ApplicationCache-, WebStorage- und Connectivity-Ereignisse, während die Datei-API noch in Arbeit ist. Die IndexedDB befindet sich noch in der Entwicklung, so dass es nicht verwunderlich ist, dass fast kein mobiler Browser sie
Umgang mit browser- und geräteübergreifenden Kompatibilitätsproblemen
Derzeit gibt es folgende Abhilfemaßnahmen, um fehlende html5-Funktionen zu beseitigen:
Feature-Erkennung
Wenn Sie vorab prüfen möchten, welche Funktionen ein bestimmter Browser unterstützt, werfen Sie einen Blick auf CanIUse. Um die Verfügbarkeit von html5-Funktionen zur Laufzeit zu überprüfen, ist Modernizer die beste Bibliothek der Wahl. Modernizer bietet eine unkomplizierte API, über die alle html5-Eigenschaften getestet werden können. Je nachdem, ob eine Funktion aktiviert ist, können geeignete Maßnahmen ergriffen werden, z.B. die Verwendung einer Polyfill-Alternative.
Polyfills
Polyfill-Bibliotheken sind Fallbacks für den Fall, dass eine HTML5-Funktion nicht unterstützt wird. Ein gutes Beispiel ist socket.io, das Unterstützung für die Echtzeitkommunikation (Push) bietet. Die html5-Antwort auf Push sind WebSockets. Da noch nicht viele mobile Browser WebSockets unterstützen, überbrückt socket.io diese Lücke, indem es andere Kommunikationsmechanismen bereitstellt, wie z.B. Long-Polling für den Fall, dass WebSockets nicht verfügbar sind. Es gibt eine große Auswahl an Polyfill-Bibliotheken, die vorzugsweise in Kombination mit Modernizer verwendet werden. Sollte Modernizer feststellen, dass eine bestimmte Funktion fehlt, kann ein Polyfill-Pendant geladen werden.
Einheimisches Aussehen und Gefühl
Html5 bietet von Haus aus kein natives OS-Look and Feel. Es gibt jedoch einige großartige Javascript-Frameworks/Bibliotheken, die native Widgets und Touch-Unterstützung bieten:
Vor- und Nachteile von Html5 Web-Apps gegenüber nativen Apps
Mit den Funktionen, die html5 in Kombination mit Polyfill-Bibliotheken bietet, können wir 'anständige' Web-Apps schreiben, die eigenständig laufen, einige Gerätefunktionen nutzen usw. Mit all den Möglichkeiten, die native Apps bieten, zu konkurrieren, steht jedoch außer Frage. Dennoch bietet html5 auch große Vorteile, von denen die native App-Entwicklung nur träumen kann. Werfen wir einen genaueren Blick auf die Unterschiede. Im Folgenden finden Sie die Vor- und Nachteile von html5-Web-Apps im Vergleich zu nativen Apps:
Die Vorteile von html5
- Ein Stack für alle: Verwenden Sie einen Technologie-Stack (html5, css, javascript) für alle Plattformen.
- Schnellere Markteinführung: Da nur ein einziger Technologie-Stack beherrscht werden muss, ist die Ausweitung auf andere Plattformen nicht so schwierig. Seien Sie sich jedoch bewusst, dass das Prinzip "einmal schreiben, überall ausführen" für eine komplexe html5-Webanwendung immer noch eine Illusion ist. Verschiedene Projekte haben bewiesen, dass es immer noch eine beträchtliche Investition sein kann, eine komplexe html5-Webanwendung auf allen Browserplattformen zum Laufen zu bringen.
- Wiederverwendung von Fähigkeiten: Ein einziges Team von Webentwicklern kann Web-Apps für alle Plattformen schreiben. Auch wenn es teuer sein kann, eine HTML5-Webanwendung auf allen Plattformen zum Laufen zu bringen, ist sie wahrscheinlich immer noch billiger als ein nativer Ansatz. Der Grund dafür ist, dass ein einziges Webentwicklerteam alle Plattformen unterstützen kann, anstatt für jede Plattform ein eigenes Entwicklerteam zu haben. Auch die Kosten für die Wartung und die Erweiterung auf neue Plattformen können viel niedriger sein als bei einem nativen Ansatz.
- Weniger Code: Wenn Sie nur einen Stack zu beherrschen haben, bedeutet dies weniger Code. Weniger Code bedeutet weniger Wartung, weniger Bugs, weniger Komplexität und damit geringere Kosten.
Die Nachteile von html5
- Begrenzter Zugriff auf Gerätefunktionen: Die meisten Html5-Browser unterstützen keinen Zugriff auf Gerätefunktionen wie Kamera, Dateisystem, Kontakte, SMS, Gyroskop, Cross-App-Messaging usw. Es gibt zwar Vorschläge, aber tatsächliche Implementierungen sind noch nicht in Reichweite.
- Keine Monetarisierung und kein Vertrieb: Html5 Web-Apps können nicht vertrieben und monetarisiert werden, d.h. sie können nicht in einem App-Store angeboten werden. Für Unternehmen, die mit Apps ihren Lebensunterhalt verdienen möchten, ist dieses Manko ein ernstes Problem.
- Schlechtere Rendering-Leistung: Html5 kann nicht mit der nativen Leistung mithalten, da es noch keinen direkten Zugriff auf die Hardware-Renderfähigkeiten des Geräts hat. Einfache Rendervorgänge, wie z.B. das Scrollen einer Liste, fühlen sich heutzutage wie nativ an. Komplexe Renderings in html5 können jedoch nicht mit ihren nativen Gegenstücken mithalten.
Je nachdem, was für eine Art von App Sie schreiben möchten, kann die Liste der Nachteile Ihnen keine andere Wahl lassen, als nativ zu arbeiten. Wenn die Rendering-Performance Ihr Killer-Merkmal ist, stehen die Chancen schlecht: Native ist Ihre einzige Wahl.
Von der Web-App zur Hybrid-App
Was sind Hybrid-Apps? Hybride Apps sind html5-Web-Apps, die nicht in einem Browser, sondern in einem nativen Wrapper laufen. Ein nativer Wrapper kann als ein eingebetteter Browser angesehen werden. Ein solcher Wrapper wird innerhalb einer nativen App gestartet und vermittelt dem Benutzer den Eindruck, dass er mit einer herkömmlichen App interagiert.
Ein beliebter hybrider App-Stack: PhoneGap(Apache Callback)
PhoneGap ist vollständig quelloffen. Es ist nicht nur weit verbreitet, sondern wird auch von großen Anbietern wie Adobe, IBM, Microsoft, RIM usw. unterstützt. Mittlerweile gibt es bereits ~15.000 PhoneGap-Apps in App-Stores für verschiedene Plattformen.
Wie es funktioniert
Das Schreiben von Anwendungen mit PhoneGap ist sehr einfach. Im Wesentlichen schreiben Sie eine herkömmliche html5-Anwendung, die einen Verweis auf eine PhoneGap js-Bibliothek in Ihrer html-Datei enthält. Nach der Fertigstellung können Sie den Build-Service von PhoneGap nutzen, der die HTML5-Webanwendung in alle nativen Wrapper Ihrer Wahl einbettet. Außerdem stellt er die resultierende Hybrid-App im App-Store zur Verfügung, wo sie auf dem entsprechenden Gerät zur Verwendung oder zum Testen heruntergeladen werden kann.
Entwicklung mit PhoneGap
Für eine bequeme Entwicklung und kurze Rundreisen ist die Verwendung von Emulatoren wünschenswert. Die meisten großen IDEs haben ein PhoneGap-Plugin, das eine schnelle Bereitstellung im SDK-Emulator ermöglicht. Andere Emulatoren sind WebKit und
Zugriff auf Gerätefunktionen
Da die html5-Standards für den Zugriff auf Gerätefunktionen lückenhaft sind und sich noch in der Entwicklung befinden, hat PhoneGap eine eigene PhoneGap-Javascript-API entwickelt, die alle Lücken schließt. Es gibt APIs für Sensoren (GPS, Beschleunigungsmesser, Kompass, Netzwerk und Kamera), Daten (Kontakte, Medien, Dateisystem, Benachrichtigungen) und Ereignisse.
PhoneGap und andere JS-Bibliotheken
Neben der PhoneGaps-eigenen API für den Zugriff auf Gerätefunktionen können alle gängigen Javascript-APIs verwendet werden, z.B. JQuery Mobile, Sencha Touch für GUI, JQuery, XUI, Zepto für DOM usw. In Bezug auf diese JS-Bibliotheken von Drittanbietern gibt es bei PhoneGaps keine Einschränkungen. Sie müssen nur sicherstellen, dass die gewählte Bibliothek innerhalb des eingebetteten nativen Browsers funktioniert.
Zugang zu nativem Code
Für den Fall, dass PhoneGap nicht alle "Lücken" für Sie schließt, bietet es eine Plugin-Architektur, mit der Sie Ihre eigenen PhoneGap-Plugins schreiben können. Mit Plugins erhalten Sie direkten Zugriff auf die zugrunde liegende Plattform mit all ihren Möglichkeiten. Allerdings sind dafür plattformspezifische Kenntnisse erforderlich. Alles in allem sind hybride Ansätze wie PhoneGap also eine großartige Alternative zu nativen Apps. Sie vereinen das Beste aus beiden Welten: ein einziger Technologie-Stack, Wiederverwendung von Fähigkeiten, kürzere Markteinführungszeiten und Zugang zu gerätespezifischen Funktionen.
Allgemeine Schlussfolgerung
Polyfills und Hybrid-Apps beweisen, dass html5 noch lange nicht ausgereift ist. Es entwickelt sich jedoch schnell. Das Ziel von Html5, ein natives Benutzererlebnis für alle Plattformen mit einem einzigen Technologiestack zu bieten, ist noch nicht Realität, aber Frameworks wie PhoneGap leisten gute Arbeit bei der Simulation dieser Utopie. Html5 und Mobile haben gerade erst Fahrt aufgenommen. Auch wenn beide noch aneinander wachsen müssen, sieht die Zukunft vielversprechend aus, denn eine Vielzahl neuer Möglichkeiten wartet auf uns. Mein Rat: Gehen Sie an Bord, um Zeuge der nächsten (R)Evolution des Webs zu werden, die diesen Planeten erschüttern wird ;-)
Danksagung
Die folgenden Präsentationen von der QCon dienten als Grundlage für diesen Blog:
- Eine Momentaufnahme der mobilen HTML5-Revolution von James Pearce
- Hybride mobile Anwendungen mit PhoneGap von Dave Johnson
- Offline-Zugriff auf Websites mit HTML5 von Israel Hilerio
Verfasst von
Urs Peter
Unsere Ideen
Weitere Blogs
Contact