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 wie die Integration von Google Play Billing hinzugefügt und die App für weitere Plattformen wie ChromeOS verfügbar gemacht.
Bubblewrap- und vertrauenswürdige Web-Aktivitäten-Funktionen
Mit Bubblewrap können Sie Apps erstellen, die Ihre PWAs in einer Trusted Web Activity starten, ohne dass Sie plattformspezifische Tools kennen müssen.
Vereinfachter Einrichtungsprozess
Bisher mussten Sie das Java Development Kit und das Android SDK manuell einrichten, was fehleranfällig war. 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. Der neue doctor-Befehl hilft Ihnen, Probleme zu finden und empfiehlt Korrekturen für die Konfiguration. Diese kann jetzt über die Befehlszeile mit dem updateConfig-Befehl aktualisiert werden.
Verbesserter Assistent
Wenn Sie ein Projekt mit init erstellen, benötigt Bubblewrap Informationen zum Generieren der Android-App. 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. Bisher war die Bedeutung der einzelnen Felder jedoch nicht klar. Die Initialisierungsdialogfelder wurden mit besseren Beschreibungen und Validierungen für jedes Eingabefeld neu erstellt.
Unterstützung für Vollbild und Ausrichtung
In einigen Fällen soll Ihre Anwendung so viel Bildschirm wie möglich nutzen. Beim Erstellen von PWAs wird dies durch Festlegen des Felds display im Web-App-Manifest auf fullscreen erreicht.
Wenn Bubblewrap die Option „Vollbild“ im Web-App-Manifest erkennt, wird die Android-Anwendung so konfiguriert, dass sie auch im Vollbildmodus oder Immersive Mode (Android-Begriff) gestartet wird.
Das Feld orientation im 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 Standardwert beim Erstellen der Android-App.
Beide Konfigurationen können im Rahmen des bubblewrap init-Ablaufs angepasst werden.
App-Bundles-Ausgabe
App Bundles ist ein Veröffentlichungsformat für Apps, bei dem die endgültige APK-Generierung und ‑Signierung an Play delegiert wird. In der Praxis bedeutet das, dass Nutzern beim Herunterladen der App aus dem Store kleinere Dateien bereitgestellt werden können.
Bubblewrap verpackt die Anwendung jetzt als App-Bundle in einer Datei mit dem Namen app-release-bundle.aab. Sie sollten dieses Format bevorzugen, wenn Sie Apps im Play Store veröffentlichen, da es seit 2021 vom Store vorgeschrieben ist.
Delegierung der Standortbestimmung
Nutzer erwarten, dass auf ihren Geräten installierte Anwendungen unabhängig von der Technologie einheitlich funktionieren. 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 bei 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 dadurch zusätzliche Abhängigkeiten zum Android-Projekt hinzugefügt werden, sollten Sie sie nur aktivieren, wenn die Web-App die Berechtigung „Standort“ verwendet.
Optimierte Binärdateien
Geräte mit begrenztem Speicherplatz sind in bestimmten Regionen der Welt weit verbreitet und Nutzer dieser Geräte bevorzugen häufig kleinere Anwendungen. Anwendungen, die Trusted Web Activity verwenden, haben kleine Binärdateien, was Nutzern die Sorge vor großen Downloads nimmt.
Bubblewrap wurde optimiert, indem die Liste der erforderlichen Android-Bibliotheken reduziert wurde. Dadurch sind die generierten Binärdateien 800 KB kleiner. In der Praxis ist das weniger als die Hälfte der durchschnittlichen Größe, die von früheren Versionen generiert wurde. Um die kleineren Binärdateien nutzen zu können, 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 in einer vertrauenswürdigen Web-Aktivität geöffnete PWA 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 neueste Version von Bubblewrap installiert ist, wird mit dem Befehl update die neueste 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
Aktualisierungen der Qualitätskriterien
In Chrome 86 wurden Änderungen an den Qualitätskriterien für vertrauenswürdige Web-Aktivitäten eingeführt, die unter Änderungen der Qualitätskriterien für PWAs mit vertrauenswürdiger Web-Aktivität ausführlich beschrieben werden.
Kurz gesagt: Sie sollten dafür sorgen, dass Ihre Anwendungen die folgenden Szenarien abfangen, um Abstürze zu vermeiden:
- Digital Asset Links werden beim Start der Anwendung nicht überprüft
- HTTP 200 wird für eine Anfrage für eine Offlinenetzwerkressource nicht zurückgegeben
- Rückgabe eines HTTP 404- oder 5xx-Fehlers 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,
});
}
}