Veröffentlicht: 2. Dezember 2020
Seit der Einführung von Trusted Web Activity hat das Chrome-Team die Verwendung mit Bubblewrap vereinfacht. Wir haben zusätzliche Funktionen hinzugefügt, z. B. die Google Play Billing-Integration, und die Nutzung auf weiteren Plattformen wie ChromeOS ermöglicht.
Bubblewrap- und vertrauenswürdige Web-Aktivität-Funktionen
Mit Bubblewrap können Sie Apps erstellen, die Ihre PWAs in einer vertrauenswürdigen Web-Aktivität starten, ohne dass Sie Kenntnisse über plattformspezifische Tools benötigen.
Vereinfachte Einrichtung
Bisher mussten Sie für die Verwendung von Bubblewrap das Java Development Kit und das Android SDK manuell einrichten, was fehleranfällig ist. Das Tool bietet jetzt an, die externen Abhängigkeiten beim ersten Ausführen automatisch herunterzuladen.
Sie können weiterhin eine vorhandene Installation der Abhängigkeiten verwenden, wenn Sie dies bevorzugen. Der neue Befehl doctor hilft Ihnen, Probleme zu finden, und empfiehlt Korrekturen für die Konfiguration, die jetzt über die Befehlszeile mit dem Befehl updateConfig aktualisiert werden kann.
Verbesserter Assistent
Wenn Sie ein Projekt mit init erstellen, benötigt Bubblewrap Informationen, um die Android-App zu generieren. Das Tool extrahiert Werte aus dem Web-App-Manifest und stellt nach Möglichkeit Standardwerte bereit.
Sie können diese Werte beim Erstellen eines neuen Projekts ändern, aber die Bedeutung der einzelnen Felder war bisher nicht klar. Die Initialisierungsdialoge wurden mit besseren Beschreibungen und Validierungen für jedes Eingabefeld neu erstellt.
Unterstützung für Vollbild und Ausrichtung des Displays
In einigen Fällen möchten Sie vielleicht, dass Ihre Anwendung so viel wie möglich vom Bildschirm einnimmt. Wenn Sie PWAs erstellen, wird dies durch Festlegen des Felds display im Web-App-Manifest auf fullscreen implementiert.
Wenn Bubblewrap die Vollbildoption im Web-App-Manifest erkennt, wird die Android-Anwendung so konfiguriert, dass sie ebenfalls im Vollbildmodus oder im immersiven Modus (Android-spezifischer Begriff) gestartet wird.
Das Feld orientation aus dem Web-App-Manifest definiert, ob die Anwendung im Hochformat, im Querformat oder in der Ausrichtung gestartet werden soll, die das Gerät gerade verwendet. Bubblewrap liest jetzt das Feld „Web App Manifest“ und verwendet es als Standard, wenn die Android-App erstellt wird.
Beide Konfigurationen können im Rahmen des bubblewrap init-Ablaufs angepasst werden.
AppBundles-Ausgabe
App-Bundles sind ein Veröffentlichungsformat für Apps, bei dem die endgültige APK-Generierung und ‑Signierung an Google Play delegiert wird. In der Praxis können Nutzer so kleinere Dateien herunterladen, wenn sie die App aus dem Store herunterladen.
Bubblewrap verpackt die Anwendung jetzt als App-Bundle in einer Datei namens app-release-bundle.aab. Sie sollten dieses Format bevorzugen, wenn Sie Apps im Google Play Store veröffentlichen, da es seit 2021 im Store erforderlich ist.
Delegierung der Standortbestimmung
Nutzer erwarten, dass sich auf ihren Geräten installierte Anwendungen unabhängig von der Technologie einheitlich verhalten. Wenn die Berechtigung GeoLocation in einer vertrauenswürdigen Web-Aktivität verwendet wird, kann sie jetzt an das Betriebssystem delegiert werden. Wenn sie aktiviert ist, sehen Nutzer dieselben Dialogfelder wie in Apps, die mit Kotlin oder Java erstellt wurden, und finden die Steuerelemente zum Verwalten der Berechtigung an derselben Stelle.
Die Funktion kann über Bubblewrap hinzugefügt werden. Da sie dem Android-Projekt zusätzliche Abhängigkeiten hinzufügt, sollten Sie sie nur aktivieren, wenn die Web-App die Berechtigung zur Standortermittlung verwendet.
Optimierte Binärdateien
In bestimmten Regionen der Welt sind Geräte mit begrenztem Speicherplatz weit verbreitet und die Nutzer dieser Geräte bevorzugen häufig kleinere Apps. Anwendungen, die vertrauenswürdige Web-Aktivität verwenden, erzeugen kleine Binärdateien, was die Bedenken dieser Nutzer etwas verringert.
Bubblewrap wurde optimiert, indem die Liste der erforderlichen Android-Bibliotheken reduziert wurde. Dadurch sind die generierten Binärdateien um 800 KB kleiner. In der Praxis ist das weniger als die Hälfte der durchschnittlichen Größe, die von früheren Versionen generiert wurde. Wenn Sie die kleineren Binärdateien nutzen möchten, müssen Sie Ihre App nur mit der aktuellen Version von Bubblewrap aktualisieren.
Vorhandene App aktualisieren
Eine von Bubblewrap generierte Anwendung besteht aus einer Webanwendung und einem einfachen Android-Wrapper, der die PWA öffnet. Auch wenn die PWA, die in einer vertrauenswürdigen Web-Aktivität geöffnet wird, denselben Aktualisierungszyklen wie jede Web-App folgt, kann und sollte der native Wrapper aktualisiert werden.
Sie sollten Ihre App aktualisieren, damit sie die aktuelle Version des Wrappers mit den neuesten Fehlerkorrekturen und Funktionen verwendet. Wenn die aktuelle Version von Bubblewrap installiert ist, wird mit dem Befehl update die aktuelle Version des Wrappers auf ein vorhandenes Projekt angewendet:
npm update -g @bubblewrap/cli
bubblewrap update
bubblewrap build
Ein weiterer Grund für die Aktualisierung dieser Anwendungen ist, dass Änderungen am Web-Manifest auf die Anwendung angewendet werden. Verwenden Sie dazu den neuen Befehl merge:
bubblewrap merge
bubblewrap update
bubblewrap build
Aktualisierung der Qualitätskriterien
In Chrome 86 wurden Änderungen an den Qualitätskriterien für vertrauenswürdige Web-Aktivitäten eingeführt, die unter Änderungen an den Qualitätskriterien für PWAs, die vertrauenswürdige Web-Aktivitäten verwenden ausführlich erläutert werden.
Kurz gesagt sollten Sie dafür sorgen, dass Ihre Anwendungen die folgenden Szenarien verarbeiten, um Abstürze zu vermeiden:
- Fehler beim Überprüfen von Digital Asset Links beim Start der Anwendung
- Fehler bei der Rückgabe von HTTP 200 für eine Offlinenetzwerk-Ressourcenanfrage
- Rückgabe eines HTTP-Fehlers vom Typ 404 oder 5xx in der Anwendung.
Neben der Validierung von Digital Asset Links können die verbleibenden Szenarien von einem Service Worker verarbeitet werden:
self.addEventListener('fetch', event => {
event.respondWith((async () => {
try {
return await fetchAndHandleError(event.request);
} catch {
// Failed to load from the network. User is offline or the response
// has a status code that triggers the Quality Criteria.
// Try loading from cache.
const cachedResponse = await caches.match(event.request);
if (cachedResponse) {
return cachedResponse;
}
// Response was not found on the cache. Send the error / offline
// page. OFFLINE_PAGE should be pre-cached when the service worker
// is activated.
return await caches.match(OFFLINE_PAGE);
}
})());
});
async function fetchAndHandleError(request) {
const cache = await caches.open(RUNTIME_CACHE);
const response = await fetch(request);
// Throw an error if the response returns one of the status
// that trigger the Quality Criteria.
if (response.status === 404 ||
response.status >= 500 && response.status < 600) {
throw new Error(`Server responded with status: ${response.status}`);
}
// Cache the response if the request is successful.
cache.put(request, response.clone());
return response;
}
Workbox enthält Best Practices und entfernt Boilerplate-Code bei der Verwendung von Service Workern. Alternativ können Sie ein Workbox-Plug-in verwenden, um diese Szenarien zu verarbeiten:
export class FallbackOnErrorPlugin {
constructor(offlineFallbackUrl, notFoundFallbackUrl, serverErrorFallbackUrl) {
this.notFoundFallbackUrl = notFoundFallbackUrl;
this.offlineFallbackUrl = offlineFallbackUrl;
this.serverErrorFallbackUrl = serverErrorFallbackUrl;
}
checkTrustedWebActivityCrash(response) {
if (response.status === 404 || response.status >= 500 && response.status <= 600) {
const type = response.status === 404 ? 'E_NOT_FOUND' : 'E_SERVER_ERROR';
const error = new Error(`Invalid response status (${response.status})`);
error.type = type;
throw error;
}
}
// This is called whenever there's a network response,
// but we want special behavior for 404 and 5**.
fetchDidSucceed({response}) {
// Cause a crash if this is a Trusted Web Activity crash.
this.checkTrustedWebActivityCrash(response);
// If it's a good response, it can be used as-is.
return response;
}
// This callback is new in Workbox v6, and is triggered whenever
// an error (including a NetworkError) is thrown when a handler runs.
handlerDidError(details) {
let fallbackURL;
switch (details.error.details.error.type) {
case 'E_NOT_FOUND': fallbackURL = this.notFoundFallbackUrl; break;
case 'E_SERVER_ERROR': fallbackURL = this.serverErrorFallbackUrl; break;
default: fallbackURL = this.offlineFallbackUrl;
}
return caches.match(fallbackURL, {
// Use ignoreSearch as a shortcut to work with precached URLs
// that have _WB_REVISION parameters.
ignoreSearch: true,
});
}
}