Ihre erste progressive Web-App

Zuletzt aktualisiert: 30.04.2019

Was macht eine Web-App zu einer progressiven Web-App?

Progressive Web-Apps bieten eine installierbare, appähnliche Oberfläche auf Computern und Mobilgeräten, die direkt über das Web erstellt und ausgeliefert werden. Sie sind schnell und zuverlässig. Und was noch wichtiger ist: Sie sind Webanwendungen, die in jedem Browser funktionieren. Wenn Sie noch heute eine Web-App entwickeln, sind Sie bereits auf dem besten Weg, eine progressive Web-App zu entwickeln.

Schnell und zuverlässig

Jede Website muss schnell ablaufen. Das gilt besonders für progressive Web-Apps. Mit „Schnell“ ist die Zeit gemeint, die es braucht, um sinnvolle Inhalte auf dem Bildschirm anzuzeigen und ein interaktives Erlebnis zu schaffen.

Außerdem muss es zuverlässig schnell sein. Es ist schwer genug zu betonen, wie viel zuverlässiger die Leistung ist. Denken Sie so vor: Das erste Laden einer nativen App ist frustrierend. Die App wird durch einen App-Shop und einen riesigen Download geschlossen. Sobald diese App jedoch installiert ist, werden die Vorabkosten für den Start aller Apps amortisiert. Bei keinem dieser Dateien tritt eine verzögerte Verzögerung auf. Jeder Anwendungsstart ist genauso schnell wie die letzte. Eine progressive Web-App muss diese zuverlässige Leistung bieten, die Nutzer von jeder installierten Installation erwarten.

Installierbar

Progressive Web-Apps können in einem Browsertab ausgeführt werden, sind aber auch installierbar. Wenn Sie eine Website als Lesezeichen speichern, wird lediglich eine Verknüpfung hinzugefügt. Eine installierte progressive Web-App (PWA) funktioniert jedoch wie alle anderen installierten Apps. Es wird genauso gestartet wie andere Apps. Sie können die Einführung steuern, einschließlich eines benutzerdefinierten Startbildschirms und Symbolen. Die App wird als App in einem App-Fenster ohne Adressleiste oder andere Browser-UI ausgeführt. Wie alle anderen installierten Apps ist sie eine App auf oberster Ebene im Task-Wechsler.

Denken Sie daran, dass eine installierbare PWA schnell und zuverlässig ist. Nutzer, die eine PWA installieren, erwarten, dass ihre Apps funktionieren, unabhängig davon, welche Netzwerkverbindung sie verwenden. Es handelt sich dabei um einen Normalbereich, den jede installierte App erfüllen muss.

Mobilgeräte und Computer

PWAs sind mit responsiven Designtechniken kompatibel und funktionieren sowohl auf Mobilgeräten als auch auf Computern, sodass zwischen den Plattformen eine einzige Codebasis genutzt wird. Wenn Sie darüber nachdenken, eine native App zu entwickeln, sehen Sie sich die Vorteile einer PWA an.

Inhalte, die Sie erstellen werden

In diesem Codelab werden Sie eine Wetter-Web-App mit PWA-Techniken erstellen. Mit der Anwendung können Sie Folgendes tun:

Verwenden Sie responsives Webdesign, damit es auf Computern und Mobilgeräten funktioniert.
Schneller Zugriff: Verwenden Sie einen Service Worker, um die zur Ausführung benötigten App-Ressourcen (HTML, CSS, JavaScript, Bilder) im Cache zu speichern und die Wetterdaten zur Laufzeit im Cache zu speichern.
Sie muss installierbar sein, dazu ein Web-App-Manifest und das Ereignis beforeinstallprompt verwenden, um den Nutzer darüber zu informieren, dass es installiert werden kann.

Lerninhalte

Web-App-Manifest erstellen und hinzufügen
Für eine einfache Offlinenutzung sorgen
Offline-Nutzung
So installierst du deine App installierbar

In diesem Codelab geht es um progressive Web-Apps. Auf irrelevante Konzepte wird nicht genauer eingegangen und entsprechende Codeblöcke können Sie einfach kopieren und einfügen.

Voraussetzungen

Eine aktuelle Version von Chrome (74 oder höher). PWAs funktionieren in allen Browsern, wir verwenden jedoch einige Funktionen der Chrome-Entwicklertools, um die Funktionsweise auf Browserebene besser zu verstehen und gegebenenfalls die Installation zu testen.
Kenntnisse in den Bereichen HTML, CSS, JavaScript und Chrome-Entwicklertools

Schlüssel für die Dark Sky API abrufen

Unsere Wetterdaten stammen von der Dark Sky API. Um sie zu verwenden, musst du einen API-Schlüssel anfordern. Die App ist einfach zu verwenden und für nicht kommerzielle Projekte kostenlos verfügbar.

Für API-Schlüssel registrieren

Prüfen, ob der API-Schlüssel richtig funktioniert

Um zu prüfen, ob dein API-Schlüssel richtig funktioniert, kannst du eine HTTP-Anfrage an die DarkSky API senden. Aktualisieren Sie die URL unten, um DARKSKY_API_KEY durch Ihren API-Schlüssel zu ersetzen. Wenn alles funktioniert, solltest du die neueste Wettervorhersage für New York sehen.

https://api.darksky.net/forecast/DARKSKY_API_KEY/40.7720232,-73.9732319

Code abrufen

Wir haben alles, was Sie für dieses Projekt benötigen, in ein Git-Repository umgewandelt. Um loszulegen, musst du den Code abrufen und in deiner bevorzugten Entwicklungsumgebung öffnen. Für dieses Codelab empfehlen wir Glitch.

Dringende Empfehlung: Importieren Sie das Repository mit Glitch.

Für dieses Codelab empfehlen wir die Verwendung von Glitch.

Öffnen Sie einen neuen Browsertab und rufen Sie https://glitch.com auf.
Falls Sie noch kein Konto haben, müssen Sie sich registrieren.
Klicken Sie auf Neues Projekt und dann auf Aus Git-Repository klonen.
Klonen Sie https://github.com/googlecodelabs/your-first-pwapp.git und klicken Sie auf „OK“.
Nachdem das Repository geladen wurde, bearbeite die Datei .env und aktualisiere sie mit deinem DarkSky API-Schlüssel.
Klicken Sie auf Anzeigen und wählen Sie dann In einem neuen Fenster aus, um die PWA in Aktion zu sehen.

Alternative: Code herunterladen &lokal arbeiten

Wenn Sie den Code herunterladen und lokal verwenden möchten, benötigen Sie eine aktuelle Version von Node.js und können den Codeeditor einrichten.

Quellcode herunterladen

Entpacken Sie die heruntergeladene ZIP-Datei.
Führen Sie npm install aus, um die Abhängigkeiten zu installieren, die für die Ausführung des Servers erforderlich sind.
Bearbeiten Sie server.js und legen Sie Ihren DarkSky API-Schlüssel fest.
Führen Sie node server.js aus, um den Server an Port 8000 zu starten.
Öffnen Sie einen Browsertab unter http://localhost:8000

Was sind der Ausgangspunkt?

Dein Ausgangspunkt ist eine einfache Wetter-App für dieses Codelab. Der Code wurde vereinfacht, um die Konzepte in diesem Codelab zu präsentieren. Außerdem funktionieren Fehler nicht besonders gut. Wenn Sie diesen Code in einer Produktions-App wiederverwenden möchten, achten Sie darauf, dass Sie alle Fehler beheben und den gesamten Code testen.

Probieren Sie Folgendes aus:

Fügen Sie über die blaue Schaltfläche + rechts unten eine neue Stadt hinzu.
Aktualisieren Sie die Daten mit der Schaltfläche „Aktualisieren“ oben rechts.
Verwenden Sie zum Löschen einer Stadt das x oben rechts auf jeder Stadtkarte.
Über die Ein-/Aus-Schaltfläche in den Chrome-Entwicklertools können Sie sehen, wie die App auf Computern und Mobilgeräten funktioniert.
Im Bereich Netzwerk in den Chrome-Entwicklertools sehen Sie, was passiert, wenn Sie offline sind.
Im Bereich Netzwerk der Chrome-Entwicklertools sehen Sie, was passiert, wenn das Netzwerk auf langsames 3G gedrosselt wird.
Fügen Sie dem Prognoseserver eine Verzögerung hinzu, indem Sie den Wert für FORECAST_DELAY in server.js ändern

Mit Lighthouse prüfen

Lighthouse ist ein benutzerfreundliches Tool, mit dem Sie die Qualität Ihrer Websites und Seiten verbessern können. Lighthouse führt Prüfungen für Leistung, Barrierefreiheit, progressive Web-Apps und mehr durch. Jedes Audit umfasst ein Referenzdokument, in dem erläutert wird, warum die Prüfung wichtig ist und wie Probleme behoben werden.

Wir verwenden Lighthouse, um unsere Wetter-App zu prüfen und die von uns vorgenommenen Änderungen zu überprüfen.

Lighthouse ausführen

Öffnen Sie Ihr Projekt in einem neuen Tab.
Öffnen Sie die Chrome-Entwicklertools und wechseln Sie zum Bereich Audits. Lassen Sie alle Audit-Typen aktiviert.
Klicken Sie auf Prüfungen ausführen. Nach einiger Zeit erhalten Sie von Lighthouse einen Bericht auf der Seite.

Progressive Web-App-Prüfung

Wir konzentrieren uns nun auf die Ergebnisse der Prüfungen für progressive Web-Apps.

Und es gibt noch viel Rot:

❗FAILED:Die aktuelle Seite reagiert nicht mit einem „200“ im Offlinemodus.
❗FAILED: start_url antwortet nicht mit „200“.
❗FAILED:Registriert keinen Service Worker, der die Seite und start_url. steuert
❗FAILED: Das Manifest der Web-App erfüllt die Anforderungen für die Installierbarkeit nicht.
❗FAILED:Ist nicht für einen benutzerdefinierten Startbildschirm konfiguriert.
❗FAILED: Dadurch wird keine Designfarbe für die Adressleiste festgelegt.

Beginne mit der Behebung einiger dieser Probleme!

Am Ende dieses Abschnitts erfüllt unsere Wetter-App die folgenden Prüfungen:

Das Web-App-Manifest erfüllt die Anforderungen für die Installierbarkeit nicht.
Der Bildschirm wurde nicht für einen benutzerdefinierten Startbildschirm eingerichtet.
Es wird keine Farbe für das Adressleistendesign festgelegt.

Web-App-Manifest erstellen

Das Web-App-Manifest ist eine einfache JSON-Datei, mit der Sie als Entwickler die Darstellung Ihrer App für den Nutzer steuern können.

Mithilfe des Web-App-Manifests kann Ihre Web-App:

Teilen Sie dem Browser mit, dass Ihre App in einem eigenständigen Fenster (display) geöffnet werden soll.
Definieren Sie, welche Seite beim ersten Öffnen der App geöffnet wird (start_url).
Lege fest, wie die App im Dock oder App Launcher aussehen soll (short_name, icons).
Erstelle einen Startbildschirm (name, icons, colors).
Bitten Sie den Browser, das Fenster im Quer- oder Hochformat (orientation) zu öffnen.
Und viele weitere.

Erstelle in deinem Projekt eine Datei mit dem Namen public/manifest.json. Kopieren Sie den folgenden Inhalt und fügen Sie ihn ein:

public/manifest.json

{
  "name": "Weather",
  "short_name": "Weather",
  "icons": [{
    "src": "/images/icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-256x256.png",
      "sizes": "256x256",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }],
  "start_url": "/index.html",
  "display": "standalone",
  "background_color": "#3E4EB8",
  "theme_color": "#2F3BA2"
}

Das Manifest unterstützt eine Reihe von Symbolen für unterschiedliche Bildschirmgrößen. Für dieses Codelab haben wir einige weitere für die iOS-Integration aufgenommen.

Link zum Web-App-Manifest hinzufügen

Als Nächstes müssen wir den Browser über unser Manifest informieren, indem wir jeder Seite in unserer App eine <link rel="manifest"... hinzufügen. Fügen Sie dem <head>-Element Ihrer index.html-Datei die folgende Zeile hinzu.

öffentlich/index.html

<!-- CODELAB: Add link rel manifest -->
<link rel="manifest" href="/manifest.json">

DevTools-Umleitung

Mit DevTools können Sie Ihre manifest.json-Datei schnell und einfach überprüfen. Öffnen Sie das Steuerfeld Manifest im Steuerfeld Anwendung. Wenn Sie die Manifest-Informationen richtig hinzugefügt haben, können Sie in diesem Bereich sehen, dass sie korrekt formatiert und angezeigt werden.

iOS-Meta-Tags und Symbole hinzufügen

Safari unter iOS unterstützt das Manifest der Web-App (noch). Sie müssen die traditionellen meta-Tags der <head>-Datei der index.html-Datei hinzufügen:

öffentlich/index.html

<!-- CODELAB: Add iOS meta tags and icons -->
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black">
<meta name="apple-mobile-web-app-title" content="Weather PWA">
<link rel="apple-touch-icon" href="/images/icons/icon-152x152.png">

Bonus: Einfache Lighthouse-Fehlerbehebung

In unserer Lighthouse-Prüfung wurden einige andere Dinge angesprochen, die leicht zu beheben sind. Lass uns das jetzt erledigen.

Meta-Beschreibung festlegen

Im Rahmen der SEO-Prüfung hat Lighthouse unsere &Dokument ohne Meta-Beschreibung notiert. Beschreibungen können in den Google-Suchergebnissen angezeigt werden. Hochwertige, eindeutige Beschreibungen können die Ergebnisse für Nutzer der Suche relevanter machen und die Anzahl der Suchzugriffe erhöhen.

Fügen Sie dem <head> Ihres Dokuments das folgende meta-Tag hinzu, um eine Beschreibung hinzuzufügen:

öffentlich/index.html

<!-- CODELAB: Add description here -->
<meta name="description" content="A sample weather app">

Designfarbe der Adressleiste festlegen

In der PWA-Prüfung wurde unsere App mit Lighthouse ermittelt, die keine Farbe für das Adressleistendesign festlegt. Wenn Sie die Adressleiste des Browsers an die Farben Ihrer Marke anpassen, können Sie ansprechender wirken.

Wenn Sie die Designfarbe auf Mobilgeräten festlegen möchten, fügen Sie dem <head> Ihres Dokuments das folgende meta-Tag hinzu:

öffentlich/index.html

<!-- CODELAB: Add meta theme-color -->
<meta name="theme-color" content="#2F3BA2" />

Änderungen mit Lighthouse prüfen

Führen Sie Lighthouse noch einmal aus. Klicken Sie dazu links oben im Bereich „Audits“ auf das Pluszeichen und bestätigen Sie Ihre Änderungen.

SEO-Prüfung

✅ PASSIERT: Das Dokument hat eine Meta-Beschreibung.

Progressive Web-App-Prüfung

❗FAILED:Die aktuelle Seite reagiert nicht mit einem „200“ im Offlinemodus.
❗FAILED: start_url antwortet nicht mit „200“.
❗FAILED:Registriert keinen Service Worker, der die Seite und start_url. steuert
✅ PASSIERT: Das Web-App-Manifest erfüllt die Anforderungen an die Installierbarkeit.
✅ PASSIERT:Konfiguriert für einen benutzerdefinierten Startbildschirm.
✅ PASSED (PASSIERT): Hiermit wird die Designfarbe einer Adressleiste festgelegt.

Von den Nutzern wird erwartet, dass installierte Apps immer als Basis gelten, wenn sie offline sind. Daher können Browser-Apps, in denen eine Installation möglich ist, entscheidend dazu beitragen, dass das Offline-Dinosaurierspiel von Chrome nicht angezeigt wird. Die Offlinenutzung reicht von einer einfachen Offlineseite über die reine Offlinewiedergabe mit zuvor im Cache gespeicherten Daten bis hin zu voll funktionsfähigen Offlinefunktionen, die automatisch synchronisiert werden, wenn die Netzwerkverbindung wiederhergestellt ist.

In diesem Abschnitt fügen wir unserer Wetter-App eine einfache Offlineseite hinzu. Wenn der Nutzer versucht, die App zu laden, während sie offline ist, wird unsere benutzerdefinierte Seite angezeigt und nicht die typische Offlineseite, die der Browser anzeigt. Am Ende dieses Abschnitts erfüllt unsere Wetter-App die folgenden Prüfungen:

Die aktuelle Seite reagiert nicht mit „200“, wenn sie offline ist.
start_url antwortet nicht mit einem 200-Statuscode.
Registriert keinen Service Worker, der die Seite und start_url. steuert

Im nächsten Abschnitt ersetzen wir unsere benutzerdefinierte Offline-Seite durch eine vollständige Offline-Funktion. Dadurch wird die Offline-Nutzung verbessert, aber vor allem die Leistung erheblich verbessert, da der Großteil unserer Assets (HTML, CSS und JavaScript) lokal gespeichert und ausgeliefert wird. Dadurch besteht für das Netzwerk ein Engpässe.

Notfalldienstmitarbeiter zur Rettung

Weitere Informationen zu Service Workern

Funktionen, die über Dienst-Worker zur Verfügung gestellt werden, gelten als schrittweise Verbesserung und werden nur hinzugefügt, wenn sie vom Browser unterstützt werden. Bei Service Workern können Sie beispielsweise die Anwendungsshell und Daten für Ihre Anwendung im Cache speichern, sodass sie auch dann verfügbar sind, wenn das Netzwerk nicht verfügbar ist. Wenn Service Worker nicht unterstützt werden, wird der Offlinecode aufgerufen und der Nutzer erhält eine grundlegende Konfiguration. Die schrittweise Nutzung der Funktionserkennung hat wenig Aufwand und in älteren Browsern, die diese Funktion nicht unterstützen, funktioniert sie nicht.

Service Worker registrieren

Der erste Schritt besteht darin, den Service Worker zu registrieren. Fügen Sie Ihrer index.html-Datei den folgenden Code hinzu:

öffentlich/index.html

// CODELAB: Register service worker.
if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/service-worker.js')
        .then((reg) => {
          console.log('Service worker registered.', reg);
        });
  });
}

Dieser Code prüft, ob die Service Worker API verfügbar ist und ob der Service Worker unter /service-worker.js registriert wird, sobald die Seite geladen wurde.

Hinweis: Der Service Worker wird über das Stammverzeichnis bereitgestellt, nicht über ein /scripts/-Verzeichnis. Dies ist die einfachste Methode, um den scope Ihres Service Workers festzulegen. Die scope des Service Workers bestimmt, welche Dateien der Service Worker steuert, d. h. von welchem Pfad der Service Worker Anfragen abfängt. Die Standardeinstellung scope ist der Speicherort der Service Worker-Datei und gilt für alle Verzeichnisse unten. Wenn sich service-worker.js im Stammverzeichnis befindet, steuert der Service Worker Anfragen von allen Webseiten in dieser Domain.

Offline-Seite im Cache speichern

Zuerst müssen wir dem Service Worker mitteilen, was im Cache gespeichert werden soll. Wir haben bereits eine einfache Offlineseite (public/offline.html) erstellt, die jedes Mal angezeigt wird, wenn keine Netzwerkverbindung besteht.

Füge in deinem service-worker.js-Objekt '/offline.html', zum Array FILES_TO_CACHE hinzu, das Ergebnis sollte so aussehen:

public/service-worker.js

// CODELAB: Add list of files to cache here.
const FILES_TO_CACHE = [
  '/offline.html',
];

Als Nächstes müssen wir den folgenden Code in das Ereignis install einfügen, damit der Service Worker die Offlineseite vorab im Cache speichern kann:

public/service-worker.js

// CODELAB: Precache static resources here.
evt.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      console.log('[ServiceWorker] Pre-caching offline page');
      return cache.addAll(FILES_TO_CACHE);
    })
);

Unser install-Ereignis öffnet nun den Cache mit caches.open() und gibt einen Cache-Namen an. Wenn Sie einen Cache-Namen angeben, können wir Versionsdateien erstellen oder Daten von den im Cache gespeicherten Ressourcen trennen. So können wir die eine Datei problemlos aktualisieren, die andere davon aber nicht beeinflussen.

Sobald der Cache geöffnet ist, können wir cache.addAll() aufrufen. Dieser ruft eine Liste von URLs auf, ruft sie vom Server ab und fügt die Antwort in den Cache hinzu. Beachten Sie, dass cache.addAll() fehlschlägt, wenn eine der einzelnen Anfragen fehlschlägt. Das bedeutet, dass Ihr Cache bei einem erfolgreichen Installationsschritt einen einheitlichen Status hat. Wenn jedoch aus irgendeinem Grund ein Fehler auftritt, wird der Dienstleister das nächste Mal automatisch gestartet.

DevTools-Umleitung

Sehen wir uns nun an, wie du mit DevTools Service Worker analysieren und Fehler beheben kannst. Bevor Sie die Seite aktualisieren, öffnen Sie die Entwicklertools und gehen Sie im Bereich Anwendung zum Bereich Service Worker. Das sollte so aussehen:

Wenn eine leere Seite wie diese angezeigt wird, sind auf der aktuell geöffneten Seite keine registrierten Service Worker vorhanden.

Aktualisieren Sie die Seite. Der Service Worker-Bereich sollte jetzt so aussehen:

Wenn Sie diese Informationen sehen, wird auf der Seite ein Service Worker ausgeführt.

Neben dem Statuslabel sehen Sie eine Zahl (in diesem Fall 34251). Behalten Sie diese Nummer im Blick, während Sie mit Service Workern zusammenarbeiten. So können Sie ganz einfach feststellen, ob Ihr Service Worker aktualisiert wurde.

Alte Offlineseiten bereinigen

Alte Elemente aus dem Cache werden mit dem Ereignis activate bereinigt. Dieser Code stellt sicher, dass Ihr Service Worker den Cache aktualisiert, sobald sich Dateien der App-Shell ändern. Damit das funktioniert, müssen Sie die Variable CACHE_NAME oben in Ihrer Service Worker-Datei erhöhen.

Fügen Sie dem activate-Ereignis den folgenden Code hinzu:

public/service-worker.js

// CODELAB: Remove previous cached data from disk.
evt.waitUntil(
    caches.keys().then((keyList) => {
      return Promise.all(keyList.map((key) => {
        if (key !== CACHE_NAME) {
          console.log('[ServiceWorker] Removing old cache', key);
          return caches.delete(key);
        }
      }));
    })
);

DevTools-Umleitung

Öffnen Sie den Bereich „Service Worker“ und aktualisieren Sie die Seite. Der neue Service Worker wird installiert und die Statusnummer wird erhöht.

Der aktualisierte Service Worker übernimmt sofort die Kontrolle, weil das Ereignis install mit self.skipWaiting() und das Ereignis activate mit self.clients.claim() beendet wird. Ohne diese Option verwaltet der alte Service Worker die Seite weiterhin, solange ein Tab geöffnet ist.

Fehlgeschlagene Netzwerkanfragen verarbeiten

Und schließlich müssen wir fetch-Ereignisse verarbeiten. Wir verwenden eine Strategie, in der ein Netzwerk auf den Cache zurückgesetzt wird. Der Service Worker versucht zuerst, die Ressource aus dem Netzwerk abzurufen. Wenn das nicht funktioniert, gibt der Service Worker die Offline-Seite aus dem Cache zurück.

public/service-worker.js

// CODELAB: Add fetch event handler here.
if (evt.request.mode !== 'navigate') {
  // Not a page navigation, bail.
  return;
}
evt.respondWith(
    fetch(evt.request)
        .catch(() => {
          return caches.open(CACHE_NAME)
              .then((cache) => {
                return cache.match('offline.html');
              });
        })
);

Der fetch-Handler muss nur die Seitennavigation verarbeiten. Andere Anfragen können also aus dem Handler entfernt und ganz normal vom Browser verarbeitet werden. Wenn die Anfrage .mode jedoch navigate lautet, kannst du versuchen, den Artikel aus dem Netzwerk mit fetch abzurufen. Wenn er fehlschlägt, öffnet der catch-Handler den Cache mit caches.open(CACHE_NAME) und nutzt cache.match('offline.html'), um die vorab im Cache gespeicherte Offlineseite abzurufen. Das Ergebnis wird dann mit evt.respondWith() an den Browser zurückgegeben.

DevTools-Umleitung

Prüfen Sie, ob alles erwartungsgemäß funktioniert. Öffnen Sie den Bereich Service Worker und aktualisieren Sie die Seite. Der neue Service Worker wird installiert und die Statusnummer wird erhöht.

Wir können auch prüfen, was im Cache gespeichert wurde. Gehen Sie im Bereich Anwendung der Entwicklertools zum Bereich Cache-Speicher. Klicken Sie mit der rechten Maustaste auf Cache-Speicher, wählen Sie Caches aktualisieren aus und maximieren Sie den Abschnitt. Den Namen Ihres statischen Cache sollten Sie links sehen. Klicken Sie auf den Cache-Namen, um alle Dateien im Cache zu sehen.

Testen wir als Nächstes den Offlinemodus. Kehren Sie zum Bereich Service Workers im Bereich Application der Entwicklertools zurück und klicken Sie das Kästchen Offline an. Nach der Überprüfung sollte neben dem Steuerfeld Netzwerk ein kleines gelbes Warnsymbol zu sehen sein. Es weist darauf hin, dass du offline bist.

Aktualisieren Sie die Seite und es funktioniert! Wir bekommen unseren Offline-Panda statt Chrome-Dino!

Tipps zum Testen von Service Workern

Das Debuggen von Dienst-Workern kann eine Herausforderung sein. Wenn sie Caching erfordert, können Dinge sogar ein Albtraum werden, wenn der Cache nicht wie erwartet aktualisiert wird. Zwischen dem normalen Service Worker-Lebenszyklus und dem Fehler in Ihrem Code kann es schnell zu Frustration kommen. Aber bitte nicht:

Entwicklertools verwenden

Im Bereich Dienstmitarbeiter des Steuerfelds Anwendung finden Sie einige Kästchen, die das Leben viel einfacher machen.

Offline: Wenn diese Option aktiviert ist, wird eine Offlinewiedergabe simuliert. Außerdem wird verhindert, dass Anfragen an das Netzwerk gesendet werden.
Beim Aktualisieren aktualisieren – Wenn diese Option aktiviert ist, wird der neueste Service Worker installiert, installiert und sofort aktiviert.
Für Netzwerk umgehen: Wenn diese Option aktiviert ist, werden Anfragen umgangen und direkt an das Netzwerk gesendet.

Von Neuem beginnen

In einigen Fällen können Daten im Cache gespeichert werden oder es kann zu Änderungen kommen. Verwenden Sie den Bereich Speicher löschen im Steuerfeld Anwendung, um alle gespeicherten Daten (localStorage, indexierte DB-Daten, im Cache gespeicherte Dateien) zu löschen und alle Service Worker zu entfernen. Alternativ können Sie auch in einem Inkognitofenster arbeiten.

Weitere Tipps:

Nachdem ein Service Worker abgemeldet wurde, wird er möglicherweise aufgelistet, bis das Browserfenster geschlossen wird.
Wenn mehrere Fenster für Ihre App geöffnet sind, wird ein neuer Service Worker erst wirksam, wenn alle Fenster neu geladen und auf den neuesten Service Worker aktualisiert wurden.
Durch das Aufheben der Registrierung eines Service Workers wird der Cache nicht geleert.
Wenn ein Service Worker vorhanden und ein neuer Service Worker registriert ist, übernimmt der neue Service Worker die Kontrolle, bis die Seite neu geladen wird – es sei denn, Sie nehmen sofort die Kontrolle.

Änderungen mit Lighthouse prüfen

Führen Sie Lighthouse noch einmal aus und überprüfen Sie Ihre Änderungen. Vergessen Sie nicht, das Häkchen bei „Offline“ zu entfernen, bevor Sie Ihre Änderungen bestätigen.

SEO-Prüfung

✅ PASSIERT:Das Dokument hat eine Meta-Beschreibung.

Progressive Web-App-Prüfung

✅ PASSEND:Die aktuelle Seite hat einen 200-Statuscode.
✅ PASSIERT: start_url antwortet mit einer 200.
✅ PASSED: Registriert einen Service Worker, der die Seite und start_url. steuert.
✅ PASSIERT: Das Web-App-Manifest erfüllt die Anforderungen an die Installierbarkeit.
✅ PASSIERT: Konfiguriert für einen benutzerdefinierten Startbildschirm.
✅ PASSED (PASSIERT): Hiermit wird die Designfarbe einer Adressleiste festgelegt.

Nimm dir einen Moment Zeit, lege dein Smartphone in den Flugmodus und probiere ein paar deiner Lieblings-Apps aus. In den meisten Fällen sind die Offlinefunktionen ziemlich zuverlässig. Nutzer erwarten zuverlässige Funktionen in ihren Apps. Und das Web sollte genauso sein. Progressive Web-Apps sollten als Erstes ein Offline-Design haben.

Lebenszyklus von Service Workern

Der Lebenszyklus des Service Workers ist der komplizierteste Teil. Wenn du nicht weißt, was genau versucht wird und was die Vorteile für dich sind, hat man das Gefühl, dass es gegen dich ankämpft. Sobald Sie wissen, wie die Funktion funktioniert, können Sie Nutzern nahtlose, unaufdringliche Updates bieten und das Beste aus Web und nativen Designs kombinieren.

`install` Ereignis

Das erste Ereignis, das ein Service Worker erhält, ist install. Es wird ausgelöst, sobald der Worker ausgeführt wird, und es wird pro Dienst-Worker nur einmal aufgerufen. Wenn Sie das Service Worker-Skript ändern, wird der Browser als ein anderer Dienst-Worker betrachtet, der ein eigenes install-Ereignis erhält.

Normalerweise wird das Ereignis install verwendet, um alles, was Sie zum Ausführen Ihrer App benötigen, im Cache zu speichern.

`activate` Ereignis

Der Service Worker erhält bei jedem Start ein activate-Ereignis. Das Ereignis activate dient hauptsächlich dazu, das Verhalten des Service Workers zu konfigurieren, sämtliche Ressourcen aus vorherigen Ausführungen zu löschen (z. B. alte Caches) und den Service Worker für die Verarbeitung von Netzwerkanfragen vorzubereiten (z. B. das unten beschriebenen fetch-Ereignis).

`fetch` Ereignis

Mit dem Abrufereignis können die Dienst-Worker alle Netzwerkanfragen abfangen und Anfragen verarbeiten. Es kann an das Netzwerk weitergeleitet werden, um die Ressource abzurufen, sie aus ihrem eigenen Cache abzurufen, eine benutzerdefinierte Antwort zu generieren oder eine beliebige Anzahl verschiedener Optionen zu erzeugen. Im Offline-Cookbook findest du verschiedene Strategien, die du verwenden kannst.

Service Worker aktualisieren

Der Browser prüft bei jedem Seitenaufbau, ob es eine neue Version des Service Workers gibt. Wenn eine neue Version gefunden wird, wird sie im Hintergrund heruntergeladen und installiert, aber nicht aktiviert. Die neue Version des Service Workers befindet sich in einem Wartestatus, bis keine Seiten mehr geöffnet sind, die den alten Service Worker verwenden. Sobald alle Fenster, die den alten Service Worker verwenden, geschlossen werden, wird der neue Service Worker aktiviert und kann die Kontrolle übernehmen. Weitere Informationen finden Sie im Abschnitt Service Worker aktualisieren.

Die richtige Caching-Strategie auswählen

Die richtige Caching-Strategie hängt von der Art der Ressource ab, die Sie im Cache speichern möchten, und davon, wie Sie später darauf zugreifen können. Für unsere Wetter-App teilen wir die benötigten Ressourcen in zwei Kategorien auf: die Ressourcen, die wir im Cache speichern möchten, und die Daten, die während der Laufzeit im Cache gespeichert werden.

Statische Ressourcen im Cache speichern

Das Verbergen Ihrer Ressourcen ist ein ähnliches Konzept wie das, was passiert, wenn ein Nutzer eine Desktop- oder mobile App installiert. Die für die Ausführung der App erforderlichen Ressourcen werden auf dem Gerät installiert oder im Cache gespeichert, damit sie später geladen werden können, unabhängig davon, ob es eine Netzwerkverbindung gibt oder nicht.

Für unsere Anwendung speichern wir bei der Installation unseres Service Workers alle statischen Ressourcen vorab im Cache, sodass alles, was zum Ausführen der App erforderlich ist, auf dem Gerät des Nutzers gespeichert wird. Um sicherzustellen, dass unsere App blitzschnell lädt, verwenden wir die Cache-First-Strategie. Statt die Netzwerke aufzurufen, werden die Ressourcen aus dem lokalen Cache abgerufen. Nur wenn sie dort nicht verfügbar sind, werden wir versuchen, sie aus dem Netzwerk abzurufen.

Durch das Abrufen aus dem lokalen Cache werden jegliche Netzwerkvariabilitäten behoben. Unabhängig davon, in welchem Netzwerk sich der Nutzer befindet (WLAN, 5G, 3G oder sogar 2G), sind die wichtigsten Ressourcen, die wir für den Betrieb benötigen, fast sofort verfügbar.

App-Daten im Cache speichern

Die Strategie veraltete-erneute Validierung eignet sich ideal für bestimmte Datentypen und funktioniert gut für unsere App. Die Daten werden so schnell wie möglich auf dem Bildschirm angezeigt. Sobald im Netzwerk die neuesten Daten zurückgegeben wurden, werden sie aktualisiert. Bei der nochmaligen erneuten Überprüfung müssen zwei asynchrone Anfragen gestartet werden: eine an den Cache und eine für das Netzwerk.

Im Allgemeinen werden die im Cache gespeicherten Daten fast sofort zurückgegeben, damit die App auf aktuelle Daten zugreifen kann. Wenn die Netzwerkanfrage zurückgegeben wird, wird die App mit den neuesten Daten aus dem Netzwerk aktualisiert.

Das ist für unsere App eine bessere Erfahrung als das Netzwerk, denn sie wird auf die Cache-Strategie zurückgegriffen, da der Nutzer nicht warten muss, bis bei der Netzwerkanfrage eine Zeitüberschreitung auftritt und er dann etwas auf dem Bildschirm sehen kann. Möglicherweise werden zuerst ältere Daten angezeigt. Sobald die Netzwerkanfrage zurückgegeben wird, wird die App aber mit den neuesten Daten aktualisiert.

App-Logik aktualisieren

Wie bereits erwähnt, muss die App zwei asynchrone Anfragen starten: eine an den Cache und eine für das Netzwerk. Die App verwendet das in window verfügbare caches-Objekt, um auf den Cache zuzugreifen und die neuesten Daten abzurufen. Dies ist ein hervorragendes Beispiel für die progressive Verbesserung, da das caches-Objekt möglicherweise nicht in allen Browsern verfügbar ist. Wenn es nicht funktioniert, sollte die Netzwerkanfrage weiterhin funktionieren.

Aktualisiere die getForecastFromCache()-Funktion, um zu prüfen, ob das caches-Objekt im globalen window-Objekt verfügbar ist. Falls ja, forderst du die Daten aus dem Cache an.

public/scripts/app.js

// CODELAB: Add code to get weather forecast from the caches object.
if (!('caches' in window)) {
  return null;
}
const url = `${window.location.origin}/forecast/${coords}`;
return caches.match(url)
    .then((response) => {
      if (response) {
        return response.json();
      }
      return null;
    })
    .catch((err) => {
      console.error('Error getting data from cache', err);
      return null;
    });

Dann müssen wir updateData() so ändern, dass es zwei Aufrufe sendet: einen an getForecastFromNetwork(), um die Prognose aus dem Netzwerk abzurufen, und einen zu getForecastFromCache(), um die letzte im Cache gespeicherte Prognose abzurufen.

public/scripts/app.js

// CODELAB: Add code to call getForecastFromCache.
getForecastFromCache(location.geo)
    .then((forecast) => {
      renderForecast(card, forecast);
    });

Unsere Wetter-App sendet jetzt zwei asynchrone Datenanfragen: eine aus dem Cache und eine über fetch. Wenn die Daten im Cache vorhanden sind, werden sie extrem schnell zurückgegeben und gerendert (zehn Millisekunden). Wenn fetch dann antwortet, wird die Karte direkt über die Wetter-API mit den neuesten Daten aktualisiert.

Beachten Sie, dass sowohl die Cache-Anfrage als auch die fetch-Anfrage mit einem Aufruf zum Aktualisieren der Prognosekarte beendet werden. Woher weiß die App, ob die neuesten Daten angezeigt werden? Dies wird im folgenden Code von renderForecast() verarbeitet:

public/scripts/app.js

// If the data on the element is newer, skip the update.
if (lastUpdated >= data.currently.time) {
  return;
}

Bei jeder Aktualisierung einer Karte speichert die App den Zeitstempel der Daten auf einem ausgeblendeten Attribut. Die Anwendung gilt nur dann, wenn der Zeitstempel, der bereits auf der Karte vorhanden ist, neuer ist als die Daten, die an die Funktion übergeben wurden.

Unsere App-Ressourcen im Cache speichern

Fügen Sie im Service Worker ein DATA_CACHE_NAME hinzu, damit die Daten unserer Anwendung von der Shell getrennt werden können. Wenn die Shell der Anwendung aktualisiert und ältere Caches dauerhaft gelöscht werden, bleiben Ihre Daten unberührt, sodass Sie sie extrem schnell laden können. Hinweis: Wenn sich dein Datenformat in Zukunft ändert, benötigst du eine Möglichkeit, das zu verarbeiten und dafür zu sorgen, dass Shell und Inhalte der App synchron bleiben.

public/service-worker.js

// CODELAB: Update cache names any time any of the cached files change.
const CACHE_NAME = 'static-cache-v2';
const DATA_CACHE_NAME = 'data-cache-v1';

Vergessen Sie nicht, auch die CACHE_NAME zu aktualisieren. Außerdem werden wir alle unsere statischen Ressourcen ändern.

Damit unsere Anwendung offline funktioniert, müssen wir alle erforderlichen Ressourcen im Cache speichern. Dies verbessert auch unsere Leistung. Anstatt alle Ressourcen aus dem Netzwerk abrufen zu müssen, kann die Anwendung alle Ressourcen aus dem lokalen Cache laden, wodurch jegliche Netzwerkinstabilität vermieden wird.

Aktualisieren Sie das Array FILES_TO_CACHE mit der Liste der Dateien:

public/service-worker.js

// CODELAB: Add list of files to cache here.
const FILES_TO_CACHE = [
  '/',
  '/index.html',
  '/scripts/app.js',
  '/scripts/install.js',
  '/scripts/luxon-1.11.4.js',
  '/styles/inline.css',
  '/images/add.svg',
  '/images/clear-day.svg',
  '/images/clear-night.svg',
  '/images/cloudy.svg',
  '/images/fog.svg',
  '/images/hail.svg',
  '/images/install.svg',
  '/images/partly-cloudy-day.svg',
  '/images/partly-cloudy-night.svg',
  '/images/rain.svg',
  '/images/refresh.svg',
  '/images/sleet.svg',
  '/images/snow.svg',
  '/images/thunderstorm.svg',
  '/images/tornado.svg',
  '/images/wind.svg',
];

Da wir die Liste der im Cache zu speichernden Dateien manuell generieren, müssen wir jedes Mal, wenn wir eine Datei aktualisieren, CACHE_NAME aktualisieren. Wir konnten offline.html aus der Liste der im Cache gespeicherten Dateien entfernen, da unsere App jetzt alle erforderlichen Ressourcen hat, die für die Offlinenutzung erforderlich sind. Die Offlineseite wird dann nicht mehr angezeigt.

Ereignis-Handler zur Aktivierung aktualisieren

Um sicherzustellen, dass unser activate Ereignis versehentlich gelöscht wird, ersetzen Sie im activate Ereignis von service-worker.js if (key !== CACHE_NAME) { durch:

public/service-worker.js

if (key !== CACHE_NAME && key !== DATA_CACHE_NAME) {

Abruf-Event-Handler aktualisieren

Der Dienst-Worker muss die Anfragen an die Wetter-API abfangen und ihre Antworten im Cache speichern, damit wir später einfach darauf zugreifen können. Bei einer veralteten Strategie müssen die Netzwerkdaten immer die aktuellen Informationen liefern. Falls das Netzwerk nicht schlagen kann, schlägt der Vorgang fehl, da die aktuellen Daten im Cache bereits in unserer App abgerufen wurden.

Aktualisieren Sie den Event-Handler fetch, um Anfragen an die Daten-API getrennt von anderen Anfragen zu verarbeiten.

public/service-worker.js

// CODELAB: Add fetch event handler here.
if (evt.request.url.includes('/forecast/')) {
  console.log('[Service Worker] Fetch (data)', evt.request.url);
  evt.respondWith(
      caches.open(DATA_CACHE_NAME).then((cache) => {
        return fetch(evt.request)
            .then((response) => {
              // If the response was good, clone it and store it in the cache.
              if (response.status === 200) {
                cache.put(evt.request.url, response.clone());
              }
              return response;
            }).catch((err) => {
              // Network request failed, try to get it from the cache.
              return cache.match(evt.request);
            });
      }));
  return;
}
evt.respondWith(
    caches.open(CACHE_NAME).then((cache) => {
      return cache.match(evt.request)
          .then((response) => {
            return response || fetch(evt.request);
          });
    })
);

Der Code fängt die Anfrage ab und prüft, ob es sich um eine Wettervorhersage handelt. Ist das der Fall, verwenden Sie fetch. Nachdem die Antwort zurückgegeben wurde, öffnen Sie den Cache, klonen Sie die Antwort, speichern Sie sie im Cache und geben Sie die Antwort an den ursprünglichen Anfragenden zurück.

Die Prüfung auf evt.request.mode !== 'navigate' muss entfernt werden, da unser Service Worker alle Anfragen – auch Bilder, Skripts und CSS-Dateien – verarbeiten soll und nicht nur Navigationen. Wenn wir das tun, wird nur der HTML-Code aus dem Service Worker-Cache bereitgestellt. Alles andere wird vom Netzwerk angefordert.

Jetzt ausprobieren

Die App sollte jetzt vollständig offline funktionieren. Aktualisieren Sie die Seite, damit der aktuelle Service Worker installiert ist. Speichern Sie anschließend einige Städte und klicken Sie in der App auf die Schaltfläche „Aktualisieren“, um aktuelle Wetterdaten zu erhalten.

Gehen Sie als Nächstes im Bereich Anwendung der Entwicklertools zum Bereich Cache-Speicher. Maximieren Sie den Abschnitt. Der Name des statischen Caches und des Datencaches werden links angezeigt. Wenn Sie den Daten-Cache öffnen, sollten die für jede Stadt gespeicherten Daten angezeigt werden.

Wechseln Sie zum Bereich Service Worker und klicken Sie das Kästchen Offline an. Aktualisieren Sie die Seite, gehen Sie dann offline und aktualisieren Sie die Seite.

Wenn du in einem schnellen Netzwerk angemeldet bist und wissen möchtest, wie Daten zur Wettervorhersage bei einer langsamen Verbindung aktualisiert werden, setze die Property FORECAST_DELAY in server.js auf 5000. Alle Anfragen an die Prediction API werden um 5.000 ms verzögert.

Änderungen mit Lighthouse prüfen

Es empfiehlt sich auch, Lighthouse noch einmal auszuführen.

SEO-Prüfung

✅ PASSIERT: Das Dokument hat eine Meta-Beschreibung.

Progressive Web-App-Prüfung

✅ PASSEND:Die aktuelle Seite hat einen 200-Statuscode.
✅ PASSIERT: start_url antwortet mit einer 200.
✅ PASSED: Registriert einen Service Worker, der die Seite und start_url. steuert.
✅ PASSIERT:Das Web-App-Manifest erfüllt die Anforderungen an die Installierbarkeit.
✅ PASSIERT: Konfiguriert für einen benutzerdefinierten Startbildschirm.
✅ PASSED (PASSIERT): Hiermit wird die Designfarbe einer Adressleiste festgelegt.

Wenn eine progressive Web-App installiert ist, funktioniert sie wie alle anderen installierten Apps. Der Start gilt dort, wie die anderen Apps starten. Sie funktioniert in einer Anwendung ohne Adressleiste oder andere Browser-UI. Wie bei allen anderen installierten Apps ist sie eine App auf oberster Ebene im Task-Wechsler.

In Chrome können Sie progressive Web-Apps installieren, indem Sie das Dreipunkt-Menü verwenden oder eine Schaltfläche oder eine andere UI-Komponente für Nutzer bereitstellen, die die Installation Ihrer App auffordern.

Mit Lighthouse prüfen

Damit ein Nutzer Ihre progressive Web-App installieren kann, muss er bestimmte Kriterien erfüllen. Am einfachsten können Sie das prüfen, indem Sie Lighthouse nutzen und prüfen, ob es die installierbaren Kriterien erfüllt.

Wenn Sie dieses Codelab durchgearbeitet haben, sollte Ihre PWA diese Kriterien bereits erfüllen.

install.js zu index.html hinzufügen

Als Erstes fügen wir der Datei index.html das install.js-Objekt hinzu.

öffentlich/index.html

<!-- CODELAB: Add the install script here -->
<script src="/scripts/install.js"></script>

Auf `beforeinstallprompt`-Ereignis warten

Wenn die Kriterien für das Hinzufügen zum Startbildschirm erfüllt sind, löst Chrome ein beforeinstallprompt-Ereignis aus, mit dem Sie angeben können, dass Ihre App installiert werden kann, und den Nutzer dann zur Installation auffordert. Fügen Sie den folgenden Code hinzu, damit Sie das Ereignis beforeinstallprompt erfassen können:

public/scripts/install.js

// CODELAB: Add event listener for beforeinstallprompt event
window.addEventListener('beforeinstallprompt', saveBeforeInstallPromptEvent);

Ereignis speichern und Installationsschaltfläche anzeigen

In unserer saveBeforeInstallPromptEvent-Funktion wird ein Verweis auf das Ereignis beforeinstallprompt gespeichert, damit wir später prompt() aufrufen können und die Benutzeroberfläche so aktualisieren, dass die Installationsschaltfläche angezeigt wird.

public/scripts/install.js

// CODELAB: Add code to save event & show the install button.
deferredInstallPrompt = evt;
installButton.removeAttribute('hidden');

Aufforderung anzeigen und Schaltfläche ausblenden

Wenn der Nutzer auf die Schaltfläche zum Installieren klickt, müssen wir für das gespeicherte beforeinstallprompt-Ereignis .prompt() aufrufen. Die Installationsschaltfläche muss ausgeblendet werden, weil .prompt() nur einmal für jedes gespeicherte Ereignis aufgerufen werden kann.

public/scripts/install.js

// CODELAB: Add code show install prompt & hide the install button.
deferredInstallPrompt.prompt();
// Hide the install button, it can't be called twice.
evt.srcElement.setAttribute('hidden', true);

Wenn du .prompt() aufrufst, wird ein modales Dialogfeld angezeigt, in dem der Nutzer aufgefordert wird, deine App dem Startbildschirm hinzuzufügen.

Ergebnisse protokollieren

Du kannst nachsehen, wie der Nutzer auf den Installationsdialog reagiert hat. Dazu wartest du auf das Versprechen, das von der Property userChoice des gespeicherten Ereignisses beforeinstallprompt zurückgegeben wird. Das Versprechen gibt ein Objekt mit der Property outcome zurück, nachdem die Aufforderung angezeigt wurde und der Nutzer darauf geantwortet hat.

public/scripts/install.js

// CODELAB: Log user response to prompt.
deferredInstallPrompt.userChoice
    .then((choice) => {
      if (choice.outcome === 'accepted') {
        console.log('User accepted the A2HS prompt', choice);
      } else {
        console.log('User dismissed the A2HS prompt', choice);
      }
      deferredInstallPrompt = null;
    });

Ein Kommentar zu userChoice: Die Spezifikation definiert sie als Eigenschaft, nicht wie erwartet.

Alle Installationsereignisse protokollieren

Zusätzlich zu jeder Benutzeroberfläche, die Sie der Installation Ihrer App hinzufügen, können Nutzer Ihre PWA auch über andere Methoden installieren, z. B. das Dreipunkt-Menü in Chrome. Warten Sie auf das Appinstall-Ereignis, um diese Ereignisse zu erfassen.

public/scripts/install.js

// CODELAB: Add event listener for appinstalled event
window.addEventListener('appinstalled', logAppInstalled);

Anschließend müssen Sie die logAppInstalled-Funktion aktualisieren. Für dieses Codelab nutzen wir einfach console.log. In einer Produktions-App möchtest du aber wahrscheinlich auch ein Ereignis mit deiner Analysesoftware protokollieren.

public/scripts/install.js

// CODELAB: Add code to log the event
console.log('Weather App was installed.', evt);

Service Worker aktualisieren

Vergessen Sie nicht, die CACHE_NAME in Ihrer service-worker.js-Datei zu aktualisieren, da Sie Änderungen an Dateien vorgenommen haben, die bereits im Cache gespeichert sind. Die Aktivierung des Kästchens Für Netzwerk umgehen im Bereich Dienst-Worker des Steuerfelds Anwendung in Entwicklertools funktioniert zwar in der Entwicklung, aber in der Praxis ist das nicht möglich.

Jetzt ausprobieren

Sehen wir uns an, wie unser Installationsschritt lief. Verwenden Sie im Bereich Anwendung der Entwicklertools die Schaltfläche Websitedaten löschen, um alle Daten zu löschen und sicherzustellen, dass wir neu beginnen. Wenn du die App bereits installiert hast, solltest du sie deinstallieren. Andernfalls wird das Installationssymbol nicht wieder angezeigt.

Prüfen, ob die Schaltfläche zum Installieren sichtbar ist

Zuerst müssen wir prüfen, ob unser Installationssymbol richtig angezeigt wird. Versuche dies sowohl auf dem Computer als auch auf dem Mobilgerät.

Öffnen Sie die URL in einem neuen Chrome-Tab.
Öffnen Sie das Dreipunkt-Menü von Chrome (neben der Adressleiste).
Prüfe, ob im FensterWetter installieren...installiert ist.
Aktualisieren Sie die Wetterdaten. Klicken Sie dazu rechts oben auf die Schaltfläche „Aktualisieren“. So stellen wir sicher, dass die Heftigkeit in Bezug auf die Nutzerinteraktion eingehalten wird.
▢ Überprüfen Sie, ob das Installationssymbol im App-Header angezeigt wird.

Prüfen, ob die Schaltfläche zum Installieren funktioniert

Als Nächstes sorgen wir dafür, dass alles korrekt installiert und unsere Ereignisse korrekt ausgelöst werden. Das ist auf dem Computer oder auf Mobilgeräten möglich. Wenn du das auf deinem Mobilgerät testen möchtest, achte darauf, dass Sie Remote-Debugging verwenden, um zu sehen, was in der Konsole protokolliert wurde.

Öffnen Sie Chrome und rufen Sie in einem neuen Browsertab die Wetter-PWA auf.
Öffnen Sie die Entwicklertools und wechseln Sie zum Steuerfeld Konsole.
Klicken Sie rechts oben auf die Schaltfläche „Installieren“.
▢ Sehen Sie nach, ob die Schaltfläche „Installieren“ ausgeblendet wird
▢ Sehen Sie nach, ob das Dialogfeld für die Installation angezeigt wird.
Klicken Sie auf „Abbrechen“.
▢ „Bestätigen“ Der Nutzer hat die A2HS-Aufforderung geschlossen. In der Konsolenausgabe wird angezeigt.
▢ Überprüfen, ob die Schaltfläche zum Installieren wieder angezeigt wird.
Klicken Sie noch einmal auf die Schaltfläche „Installieren“ und dann im Dialogfenster auf „Installieren“.
▢ „Bestätigt“ Der Nutzer hat die A2HS-Aufforderung akzeptiert.Sie wird in der Konsolenausgabe angezeigt.
▢ Prüfen Sie, ob die Wetter-App in der Konsolenausgabe angezeigt wurde.
Starten Sie die Wetter-PWA.
▢

iOS-Installation prüfen

Auch das Verhalten auf iOS-Geräten wird geprüft. iOS-Geräte, die Sie verwenden können, oder, falls Sie einen Mac nutzen, sind mit iOS verfügbar.

Öffnen Sie Safari und rufen Sie in einem neuen Browsertab Ihre Wetter-PWA auf.
Klicke auf die Schaltfläche Teilen .
Scrollen Sie nach rechts und klicken Sie auf die Schaltfläche Zum Startbildschirm hinzufügen.
▢ Prüfen Sie, ob Titel, URL und Symbol korrekt sind.
Klicken Sie auf Hinzufügen
%%. Prüfen Sie, ob dem Startbildschirm das App-Symbol hinzugefügt wurde.
Öffnen Sie die Wetter-PWA auf dem Startbildschirm.
▢ Nach dem Start der App:

Bonus: Es wird ermittelt, ob deine App über den Startbildschirm gestartet wird

Mit der Medienabfrage display-mode können Sie Stile anwenden, je nachdem, wie die App gestartet wurde, oder festlegen, wie sie mit JavaScript gestartet wurde.

@media all and (display-mode: standalone) {
  body {
    background-color: yellow;
  }
}

Sie können auch die display-mode-Medienabfrage in JavaScript prüfen, um festzustellen, ob die Migration eigenständige Aktionen betrifft.

Bonus: PWA deinstallieren

Denken Sie daran, dass die beforeinstallevent nicht ausgelöst wird, wenn die App bereits installiert ist. Während der Entwicklung ist es wahrscheinlich, dass Sie die App mehrmals installieren und deinstallieren, um sicherzustellen, dass alles wie erwartet funktioniert.

Android

Auf Android-Geräten werden PWAs auf die gleiche Weise deinstalliert wie andere installierte Apps.

Öffnen Sie die App-Leiste.
Scrolle nach unten, um das Wetter-Symbol zu finden.
Ziehen Sie das App-Symbol an den oberen Bildschirmrand.
Wählen Sie Deinstallieren aus.

Chrome OS

Unter Chrome OS lassen sich PWAs ganz einfach über das Launcher-Suchfeld deinstallieren.

Öffnen Sie den Launcher.
Geben Sie Wetter in das Suchfeld ein, damit Ihre Wetter-PWA in den Ergebnissen angezeigt wird.
Klicken Sie mit der rechten Maustaste auf die Wetter-PWA, indem Sie mit der rechten Maustaste darauf klicken.
Klicken Sie auf Aus Chrome entfernen...

macOS und Windows

Unter Mac und Windows können PWAs über Chrome deinstalliert werden:

Öffnen Sie einen neuen Browsertab und chrome://apps.
Klicken Sie mit der rechten Maustaste auf die Wetter-PWA, indem Sie mit der rechten Maustaste darauf klicken.
Klicken Sie auf Aus Chrome entfernen...

Alternativ können Sie die installierte PWA öffnen, oben rechts auf das Dreipunkt-Menü klicken und Wetter-PWA deinstallieren... auswählen.

Herzlichen Glückwunsch! Sie haben Ihre erste progressive Web-App erstellt!

Sie haben ein Web-App-Manifest hinzugefügt, damit es installiert werden kann. Außerdem haben Sie einen Service Worker hinzugefügt, damit Ihre PWA immer schnell und zuverlässig ist. Du hast gelernt, wie du mit den Entwicklertools eine App prüfen kannst und wie du die Nutzerfreundlichkeit verbessern kannst.

Ihre erste progressive Web-App Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Was macht eine Web-App zu einer progressiven Web-App?

Schnell und zuverlässig

Installierbar

Mobilgeräte und Computer

Inhalte, die Sie erstellen werden

Lerninhalte

Voraussetzungen

Schlüssel für die Dark Sky API abrufen

Prüfen, ob der API-Schlüssel richtig funktioniert

Code abrufen

Dringende Empfehlung: Importieren Sie das Repository mit Glitch.

Alternative: Code herunterladen &lokal arbeiten

Was sind der Ausgangspunkt?

Mit Lighthouse prüfen

Lighthouse ausführen

Progressive Web-App-Prüfung

Web-App-Manifest erstellen

Link zum Web-App-Manifest hinzufügen

DevTools-Umleitung

iOS-Meta-Tags und Symbole hinzufügen

Bonus: Einfache Lighthouse-Fehlerbehebung

Meta-Beschreibung festlegen

Designfarbe der Adressleiste festlegen

Änderungen mit Lighthouse prüfen

Notfalldienstmitarbeiter zur Rettung

Service Worker registrieren

Offline-Seite im Cache speichern

DevTools-Umleitung

Alte Offlineseiten bereinigen

DevTools-Umleitung

Fehlgeschlagene Netzwerkanfragen verarbeiten

DevTools-Umleitung

Tipps zum Testen von Service Workern

Entwicklertools verwenden

Von Neuem beginnen

Änderungen mit Lighthouse prüfen

Lebenszyklus von Service Workern

install Ereignis

activate Ereignis

fetch Ereignis

Service Worker aktualisieren

Die richtige Caching-Strategie auswählen

Statische Ressourcen im Cache speichern

App-Daten im Cache speichern

App-Logik aktualisieren

Unsere App-Ressourcen im Cache speichern

Ereignis-Handler zur Aktivierung aktualisieren

public/service-worker.js

Abruf-Event-Handler aktualisieren

Jetzt ausprobieren

Änderungen mit Lighthouse prüfen

Mit Lighthouse prüfen

install.js zu index.html hinzufügen

Auf beforeinstallprompt-Ereignis warten

Ereignis speichern und Installationsschaltfläche anzeigen

Aufforderung anzeigen und Schaltfläche ausblenden

Ergebnisse protokollieren

Alle Installationsereignisse protokollieren

Service Worker aktualisieren

Jetzt ausprobieren

Prüfen, ob die Schaltfläche zum Installieren sichtbar ist

Prüfen, ob die Schaltfläche zum Installieren funktioniert

iOS-Installation prüfen

Bonus: Es wird ermittelt, ob deine App über den Startbildschirm gestartet wird

Bonus: PWA deinstallieren

Android

Chrome OS

macOS und Windows

Was liegt als Nächstes an?

Weitere Informationen

Referenzdokumente

Ihre erste progressive Web-App

`install` Ereignis

`activate` Ereignis

`fetch` Ereignis

Auf `beforeinstallprompt`-Ereignis warten