Progressive Web Apps

Das Praxisbuch
 
 
Rheinwerk (Verlag)
  • 1. Auflage
  • |
  • erschienen am 21. Dezember 2018
  • |
  • 518 Seiten
 
E-Book | ePUB mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-8362-6496-9 (ISBN)
 

PWAs: Das App-Modell der Zukunft

  • Plattformübergreifende Client-Anwendungen
  • PWAs mit Workbox, Angular, inkl. Payment Request API
  • Für den Browser, Android, iOS, Windows, macOS, Linux
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. Unser Buch vermittelt alles notwendige Hintergrundwissen im Umgang mit dem Web App Manifest, Service Worker, Cache und Push API. Erste eigene PWAs entwickeln Sie mit Workbox und Angular. Inkl. Migrationsstrategien mit Apache Cordova und GitHub Electron sowie Einsatz der Payment Request API, über die Sie trotz fehlenem App Store Ihre Webapp monetarisieren können.

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
1. Auflage
  • Deutsch
  • Bonn
  • |
  • Deutschland
  • Neue Ausgabe
  • 18,55 MB
978-3-8362-6496-9 (9783836264969)
weitere Ausgaben werden ermittelt

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

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...

Dateiformat: ePUB
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie eine Lese-Software, die das Dateiformat EPUB verarbeiten kann: z.B. Adobe Digital Editions oder FBReader - beide kostenlos (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nicht Kindle)

Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet - also für "fließenden" Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Download (sofort verfügbar)

35,90 €
inkl. 7% MwSt.
Download / Einzel-Lizenz
ePUB mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
E-Book bestellen