Liebel Progressive Web Apps

Das Praxisbuch
1. Auflage 2018
ISBN: 978-3-8362-6496-9
Verlag: Rheinwerk
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Deutsch, 518 Seiten

Reihe: Rheinwerk Computing

Progressive Web Apps (PWAs) sind eine moderne und zeitgemäße Form der Webapp. Ausgestattet mit allen Möglichkeiten wie Offlinefähigkeit, Push-Benachrichtigungen und Datensynchronisation können Sie mit modernen Webtechnologien (HTML5, CSS3, JavaScript) plattformübergreifend beeindruckende Anwendungen entwickeln, die sich wie native Apps verhalten.
Lernen Sie, wie Sie das volle Potenzial des Web App Manifest ausschöpfen und erfahren Sie, wie Sie Server Worker sowie die APIs von Push, Cache und Payment Request richtig einsetzen. Erste eigene Progressive Web Apps entwickeln und debbuggen Sie mit dem Single-Page-Application-Framework Angular oder Workbox. Migrationsszenarien hin zu Progressive Web Apps auf Basis der beiden Technologien Apache Cordova und GitHub Electron helfen Ihnen zudem beim Verpacken Ihrer Weblösung als natives Anwendungspaket für Mobil- und Desktopplattformen.

Aus dem Inhalt:

• Moderne Webtechnologien in der Anwendung
• Zehn Eigenschaften, die PWA einzigartig machen
• Web App Manifest: Aussehen der App definieren
• Umgang mit dem Service Worker
• Cache API
• Push API
• PWA und Angular
• So läuft's auf Desktop und Mobile
• Validierung mit Lighthouse und Co.
• Migrationsstrategien mit Cordova und Electron
• Payment Request API

Autoren/Hrsg.

Liebel, Christian

Inhaltsverzeichnis

Materialien zum Buch ... 17  Geleitwort ... 19  Vorwort ... 21  1.  Im Web, als App: Geschichte und Einstieg ... 25  1.1 ... Wie Apps auf unser Handy kamen - eine kleine Zeitreise ... 27  1.2 ... Progressive Web Apps: wohin die Reise der Anwendungsentwicklung geht ... 35  1.3 ... Voraussetzungen und Basics: welches Wissen Sie schon mitbringen sollten ... 42  1.4 ... Tools installieren: das Handwerkszeug zur PWA-Entwicklung ... 48  1.5 ... Setup: Das erste PWA-Projekt ... 54  1.6 ... Zusammenfassung ... 65  2.  Mächtiges modernes Web ... 67  2.1 ... Audio-/Videoelement: Multimediainhalte ohne Plug-in wiedergeben ... 70  2.2 ... Canvas-Element: ansprechende 2D- und 3D-Visualisierungen ... 72  2.3 ... Gamepad API: App mit dem Game-Controller steuern ... 78  2.4 ... WebAssembly: Binärcode für das Web mit nahezu nativer Performance ... 82  2.5 ... Web Share API: Teilen von Inhalten aus dem Browser heraus ... 84  2.6 ... Web Speech API: Text-to-Speech im Browser ... 87  2.7 ... Media Capture and Streams: auf Kamera und Mikrofon zugreifen ... 88  2.8 ... Generic Sensor API: Zugriff auf die Gerätesensoren ... 91  2.9 ... Pointer Events und Pressure.js: Force Touch im Web ... 93  2.10 ... Geolocation: Implementierung standortbezogener Dienste ... 94  2.11 ... Zusammenfassung ... 98  3.  Zehn Eigenschaften, die PWA einzigartig machen ... 99  3.1 ... Voranschreiten mit Progressive Enhancement ... 100  3.2 ... App-ähnlich: Sieht aus wie eine App, fühlt sich an wie eine App ... 103  3.3 ... Verbindungsunabhängigkeit: Kein Funkloch hält Sie auf ... 106  3.4 ... Immer schön frisch bleiben: der Service-Worker-Updateprozess ... 109  3.5 ... Sicher: Mit großer Macht kommt große Verantwortung ... 110  3.6 ... Einer für alle: Responsive Webdesign ... 115  3.7 ... Auffindbarkeit: Websites und Apps unterscheiden ... 118  3.8 ... Installierbarkeit: So kommt Ihre PWA auf den Homebildschirm ... 120  3.9 ... Nutzer binden: Anwender mit Pushbenachrichtigungen zurückholen ... 123  3.10 ... Verlinkbar: auf Anwendungen und Zustände verweisen ... 126  3.11 ... Zusammenfassung ... 129  4.  Web App Manifest: Aussehen der App definieren ... 131  4.1 ... App-Aussehen auf dem Homebildschirm anpassen ... 135  4.2 ... App-Verhalten anpassen ... 146  4.3 ... Web App Manifest referenzieren ... 156  4.4 ... Zur Installation auffordern ... 157  4.5 ... Zukunftsmusik: Badging API ... 166  4.6 ... Microsoft Store Ingestion: Wie die App den Weg in den Microsoft Store findet ... 168  4.7 ... PWA Builder ... 170  4.8 ... Zusammenfassung ... 170  5.  Service Worker: Einer muss ja arbeiten ... 171  5.1 ... Vom Web Worker zum Service Worker ... 171  5.2 ... Kontrollzwang mit Vorteilen: Service Worker als zentraler Proxy ... 176  5.3 ... Lebenszyklus ... 188  5.4 ... Schnittstellen ... 199  5.5 ... Wir alle machen Fehler: Service Worker debuggen ... 207  5.6 ... Background Sync API ... 217  5.7 ... Navigation Preload ... 221  5.8 ... Zusammenfassung ... 223  6.  Cache API: So lädt die App auch ohne Netzverbindung ... 225  6.1 ... HTTP-Crashkurs: So war das noch mal mit Anfragen und Antworten ... 226  6.2 ... Auslaufmodell Application Cache ... 235  6.3 ... Caches verwalten ... 236  6.4 ... Antworten zur Seite legen: Man weiß nie, wann man sie wieder gebrauchen kann ... 238  6.5 ... It's a match! - Passende Antworten aus dem Cache holen ... 246  6.6 ... Cacheeinträge löschen ... 250  6.7 ... Caches debuggen ... 251  6.8 ... Caching-Strategien ... 252  6.9 ... Weitere Service-Worker-Use-Cases ... 259  6.10 ... Zusammenfassung ... 260  7.  Workbox ... 261  7.1 ... Befehle der Workbox CLI ... 262  7.2 ... Workbox-Projekt aufsetzen ... 263  7.3 ... Precaching ... 265  7.4 ... Runtime Caching ... 270  7.5 ... Service Worker erweitern ... 276  7.6 ... Workbox in den Buildprozess integrieren ... 279  7.7 ... Navigation Preload aktivieren ... 282  7.8 ... Offlineanalysedaten erfassen ... 282  7.9 ... Zusammenfassung ... 283  8.  Push API: Rufen Sie nicht uns an - wir rufen Sie an! ... 285  8.1 ... Das Push-Prinzip ... 286  8.2 ... Nur eine Chance: Pushregistrierung beantragen ... 287  8.3 ... Informationsaustausch ... 293  8.4 ... Den Server Pushnachrichten verschicken lassen ... 297  8.5 ... Pushereignisse behandeln ... 302  8.6 ... Sonderfall Apple ... 310  8.7 ... Drittanbieterdienste: OneSignal & Co. ... 314  8.8 ... Pushnachrichten zur Laufzeit ... 316  8.9 ... Zusammenfassung ... 319  9.  PWA und Angular: Single-Page-Application-Framework einsetzen ... 321  9.1 ... Projekt-Setup ... 323  9.2 ... Responsive und App-like: Navigationsgrundgerüst mit Angular Material ... 325  9.3 ... Linkable: Routing implementieren ... 329  9.4 ... App-Like, die zweite: Moderne Web-APIs einsetzen ... 333  9.5 ... PWA-Unterstützung installieren ... 335  9.6 ... Discoverable: Web App Manifest anpassen ... 336  9.7 ... Connectivity Independent, die erste: Quelldateien der Anwendung offlinefähig machen ... 338  9.8 ... Connectivity Independent, die zweite: strukturierte Daten zwischenspeichern ... 348  9.9 ... Reengageable: Pushereignisse mit SwPush ... 359  9.10 ... Fresh: Updateprozess mit SwUpdate ... 364  9.11 ... Installable: Installation anbieten ... 366  9.12 ... Angular Universal: mit Server-Side-Rendering zur App Shell ... 368  9.13 ... PRPL-Entwurfsmuster ... 369  9.14 ... Zusammenfassung ... 370

10.  App-like aussehen ... 373  10.1 ... Native Schriftarten einsetzen ... 373  10.2 ... Textauswahl und Link-Highlighting verhindern ... 375  10.3 ... App-like Anwendungsframeworks ... 379  10.4 ... Notches unterstützen ... 381  10.5 ... Zusammenfassung ... 386

11.  Plattformverhalten ... 387  11.1 ... macOS ... 387  11.2 ... iOS ... 389  11.3 ... Android ... 391  11.4 ... Windows ... 395  11.5 ... Linux ... 397  11.6 ... Zusammenfassung ... 399

12.  Alles richtig gemacht? - PWAs validieren mit Lighthouse & Co. ... 401  12.1 ... Barrierefreiheit testen mit aXe ... 402  12.2 ... Lighthouse: der Leuchtturm der Websitevalidierung ... 405  12.3 ... webhint: ein Linter für das Web ... 411  12.4 ... Zusammenfassung ... 416

13.  Migrationsstrategien mit Apache Cordova und GitHub Electron ... 417  13.1 ... Apache Cordova ... 419  13.2 ... GitHub Electron ... 440  13.3 ... Plattformunterschiede elegant verbergen ... 455  13.4 ... Chromium Embedded Framework: Desktopanwendungen schrittweise entkernen ... 459  13.5 ... Zusammenfassung und Fazit ... 460

14.  Payment Request API: Wie Sie trotz fehlendem App Store an Ihr Geld kommen ... 463  14.1 ... Warum Check-out-Formulare nicht die Lösung sind ... 464  14.2 ... Einfaches Check-out mit der Payment Request API ... 466  14.3 ... Ablauf einer Zahlungsanforderung ... 470  14.4 ... Payment Method: Basic Card ... 474  14.5 ... Google Pay ... 478  14.6 ... Apple Pay ... 482  14.7 ... Fazit: Viele Wege führen zum Fallback ... 489  14.8 ... Ausblick: Payment Handler API ... 491  14.9 ... Zusammenfassung ... 492

15.  Brandheiße Progressive Web Apps ... 495  15.1 ... Twitter Lite ... 496  15.2 ... Financial Times ... 497  15.3 ... Telegram ... 498  15.4 ... Pokédex ... 499  15.5 ... QR Scanner ... 500  15.6 ... Zusammenfassung ... 502

16.  Fazit: Eine Codebasis, alle Plattformen ... 503  16.1 ... Ideales technologisches Umfeld ... 503  16.2 ... Interessen der Plattformhersteller ... 504  16.3 ... Wer heute schon PWAs baut ... 506  16.4 ... Limitationen ... 506  16.5 ... Chancen ... 507  16.6 ... Ausblick ... 508  Über den Autor ... 511  Index ... 513

Leseproben

1    Im Web, als App: Geschichte und Einstieg

Google sagt: Die Zukunft gehört den Progressive Web Apps. Bevor Sie sich mit diesem Anwendungsmodell ausführlich auseinandersetzen, lohnt sich ein Blick auf die Geschichte mobiler Apps sowie auf hilfreiche Tools, die die App-Entwicklung zum Kinderspiel machen.

Wir schreiben den 1. April 2004. Die Ankündigung eines neuen E-Mail-Dienstes sorgt für Aufsehen: Wegen seines für damalige Verhältnisse sehr großzügigen E-Mail-Speicherplatzes von einem Gigabyte (üblich waren damals nur wenige Megabytes) halten manche die Ankündigung zunächst für einen Aprilscherz. Und nicht nur der Speicherplatz ist bemerkenswert, sondern auch die besondere Schnelligkeit des zugehörigen webbasierten E-Mail-Clients. Die Rede ist von Gmail, dem bekannten Freemail-Dienst von Google und zugleich einem der ersten Produkte, mit denen der Suchmaschinenanbieter sein klassisches Kerngeschäft verließ. Google etablierte mit diesem E-Mail-Dienst einen der ersten großen Vertreter einer Single-Page Web Application (SPA). Darunter versteht man eine als Fat Client realisierte Webanwendung, die Interaktionen durch clientseitige Dynamik umsetzt, anstatt einen serverseitigen Seitenwechsel durchzuführen. Nach dem initialen Laden der Quelldateien nimmt dieser Typ Anwendung lediglich zur Abfrage oder Manipulation von Daten Kontakt zu einem entfernten Server auf, etwa mithilfe von Asynchronous JavaScript and XML (AJAX). Diese Technologie stellt wiederum einen Baustein des Web 2.0 dar, das ungefähr zeitgleich Fahrt aufnahm. Im weiteren Verlauf wurden Webanwendungen salonfähig und zunehmend mehr Anwendungen auf der SPA-Architektur aufgesetzt. Heute sind GitHub, Google Maps oder Facebook weitere bekannte Vertreter dieses Typs Webanwendung.

Etwas mehr als zehn Jahre nach der Veröffentlichung von Gmail will es Google erneut wissen und postuliert mit den Progressive Web Apps (PWA) das Anwendungsmodell der Zukunft. Mit dem mobilen Betriebssystem Android und dem Webbrowser Chrome hat Google zwei mächtige und weitverbreitete Anwendungsplattformen im Portfolio, die in ihren jeweiligen Segmenten zu Marktführern avanciert sind. Progressive Web Apps möchten das Beste aus diesen beiden Welten vereinen: den Funktionsreichtum nativer Anwendungen und die plattformübergreifende Ausführbarkeit von Webanwendungen. Zwar wurden über die vergangenen Jahre viele neue Schnittstellen mit wichtigen Features im Web eingeführt, doch blieben die Installierbarkeit von Anwendungen auf den Homebildschirm, Pushbenachrichtigungen, vollumfängliche Offlinefähigkeit sowie die Abwicklung von In-App-Käufen bislang nur nativen Anwendungen vorbehalten. Unter anderem mit dem Service Worker, dem Web App Manifest und der Payment Request API wurden nun Schnittstellen für das Web geschaffen, die diese Lücken schließen. Außerdem können Progressive Web Apps auf alle weiteren Funktionen zurückgreifen, für die es eine Webschnittstelle gibt und die vom jeweiligen Webbrowser auf der jeweiligen Plattform zur Verfügung gestellt werden. Mit den Progressive Web Apps wird ein gravierendes Problem der Anwendungsentwicklung ein für alle Mal aus der Welt geschafft: die Plattformabhängigkeit. Denn diese Apps können auf jedem Gerät ausgeführt werden, auf dem ein halbwegs moderner Browser läuft: vom Smartphone mit Android bis hin zum Desktopcomputer mit Microsoft Windows.

Insgesamt haben Progressive Web Apps kein geringeres Ziel, als die altbekannten App Stores abzuschaffen. Diese Anwendungen werden nicht über eine zentrale Vertriebsplattform installiert, sondern zunächst im Browser ausgeführt. Dabei sind Progressive Web Apps aber keine funktional reduzierten Webclients, die ihr Leben nur in einer Browserregisterkarte fristen – wünscht der Benutzer einen schnelleren Zugang zur Anwendung, kann er eine Verknüpfung zur App auf dem Homebildschirm respektive dem Desktop hinterlegen. Von dort startet die Anwendung auf Wunsch ohne Menüleisten und Statuszeilen, auf Mobilgeräten als vollflächige App oder auf dem Desktop in einem eigenen Fenster mit nativer Fensterdekoration. Auch im App-Switcher oder der Taskleiste erhält die Anwendung einen Platz, womit sie von nativen Anwendungen kaum mehr zu unterscheiden ist (siehe Abbildung 1.1). Die Anwendung verlässt den Browser schrittweise, unter anderem darauf weist der Namensbestandteil Progressive hin. Unter der Haube tickt jedoch weiterhin der Browser und darin die Progressive Web App: Eine Progressive Web App, die über eine Verknüpfung in einem eigenen Fenster gestartet wird, unterscheidet sich funktional nicht von der im Webbrowser ausgeführten Variante. Insgesamt begegnen Progressive Web Apps ihren nativen Gegenstücken also auf Augenhöhe. Native Anwendungen und App Stores könnten damit in weiten Teilen bald überflüssig werden.

Abbildung 1.1    Hätten Sie es geahnt? Hier läuft die Progressive Web App Twitter Lite, von nativen Anwendungen nicht zu unterscheiden.

1.1    Wie Apps auf unser Handy kamen – eine kleine Zeitreise

Mit den Progressive Web Apps geht es für Anwender, Entwickler und Plattformbetreiber also zurück in eine Zeit vor dem App Store. Eine Zeit, die es schon einmal gab, denn Anwendungen für mobile Endgeräte wie Smartphones und Tablets sind natürlich keine Neuerfindung: Bereits die ersten Handys waren mit solchen Minianwendungen für einen abgegrenzten, dedizierten Zweck ausgestattet. Später kam die Möglichkeit hinzu, beliebige von Drittanbietern bereitgestellte Anwendungen auf den Geräten zu installieren. Der Weg, auf dem Apps auf die mobilen Endgeräte kommen, änderte sich aber im Laufe der Zeit. Blicken wir daher kurz zurück auf die Entwicklung mobiler Anwendungen.

1.1.1    Der PC für die Hosentasche

Microsoft Windows CE ist ein früher Vertreter eines potenten Betriebssystems für mobile Geräte. Manche davon wurden zwischenzeitlich als Pocket PC bezeichnet, also als PC für die Hosentasche. Während sich der Unterbau dieses Systems zwar grundsätzlich vom Desktopbetriebssystem Windows unterscheidet, wurden diesem dennoch viele Konzepte entnommen: So hat Windows CE etwa eine Startschaltfläche, eine Taskleiste und Menüzeilen. Alle Steuerelemente sind so klein, dass der Anwender zur Bedienung auf einen Stylus, einen kleinen Plastikstift, angewiesen ist.

Auch das Anwendungskonzept wurde vom Desktopbetriebssystem übernommen: Programmdateien (Executables) können, wie es unter Windows nach wie vor üblich ist, aus beliebigen Quellen (etwa aus dem Internet oder über einen angeschlossenen Rechner) bezogen und direkt ausgeführt werden. Abbildung 1.2 zeigt die Installation einer Drittanbieteranwendung unter Windows Mobile 2003: Führt man die Installationsdatei (hier tcmdpocketarm.cab) aus, werden die Programmdateien im Programme-Verzeichnis des Geräts hinterlegt. Danach erscheint eine Verknüpfung zur Anwendung in der Programmliste. Was heute auf Desktopbetriebssystemen noch immer üblich ist, erschien auch auf mobilen Plattformen in den Anfangsjahren als passables Konzept. Das Betriebssystem vertraute den darauf ausgeführten Anwendungen noch und stellte ihnen eine Vielzahl von Schnittstellen zur Verfügung, eine Sandbox oder ein Berechtigungskonzept gab es nicht.

Abbildung 1.2    Apps installieren auf die klassische Art, hier unter Windows Mobile 2003

1.1.2    Der Browser als Anwendungsplattform

Dann kam Apple und änderte wieder einmal alles: Am 9. Januar 2007 stellte Steve Jobs das iPhone auf der Macworld in San Francisco vor. Dieses Smartphone setzte sich von der seinerzeit vorherrschenden Konkurrenz durch seinen vollflächigen Multi-Touch-Bildschirm, die intuitive und auch mit Fingern gut bedienbare Benutzeroberfläche sowie seinen Webbrowser Safari ab. Auf dem iPhone stand die Safari-Engine mit dem vollen aus der Desktopvariante bekannten Funktionsumfang zur Verfügung. Für damalige Verhältnisse war diese Ausgabe eines mobilen Browsers herausragend leistungsstark.

Über das Anwendungsmodell des iPhone wurde bei der Keynote noch nicht gesprochen. Informationen dazu lieferte Jobs bei der hauseigenen Entwicklerkonferenz WWDC am 11. Juli 2007 nach, nur 18 Tage vor der Auslieferung der ersten iPhones. Der Weg, auf dem Apps von Drittanbietern auf das iPhone kommen sollten, wurde als innovativ und besonders sicher beschrieben: Als Anwendungsplattform sollte Safari zum Einsatz kommen – und damit ein Webbrowser. Jobs dazu:

And so, you can write amazing Web 2.0 and AJAX apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps.

Als weitere Vorteile dieses webbasierten Anwendungsmodells nannte Jobs, dass Apps durch die Bereitstellung auf einem eigenen Server besonders einfach verteilt und durch eine simple Änderung an den Quelldateien auch aktualisiert werden könnten, ganz ohne komplizierte Prozesse. Durch die Ausführung von Webinhalten in einer Sandbox wäre dieses Modell auch...