Date de publication : 2 décembre 2020
Depuis l'introduction de l'activité Web fiable, l'équipe Chrome a facilité son utilisation avec Bubblewrap. Nous avons ajouté des fonctionnalités supplémentaires, telles que l'intégration de Google Play Billing, et l'avons activé pour qu'il fonctionne sur d'autres plates-formes, comme ChromeOS.
Fonctionnalités de Bubblewrap et des activités Web fiables
Bubblewrap vous aide à créer des applications qui lancent vos PWA dans une activité Web fiable, sans nécessiter de connaissances sur les outils spécifiques à la plate-forme.
Processus de configuration simplifié
Auparavant, l'utilisation de Bubblewrap nécessitait de configurer manuellement le kit de développement Java et le SDK Android, deux opérations sujettes aux erreurs. L'outil propose désormais de télécharger automatiquement les dépendances externes lors de sa première exécution.
Vous pouvez toujours choisir d'utiliser une installation existante des dépendances, si vous le souhaitez. La nouvelle commande doctor permet de détecter les problèmes et de recommander des correctifs pour la configuration, qui peut désormais être mise à jour à partir de la ligne de commande à l'aide de la commande updateConfig.
Assistant amélioré
Lorsque vous créez un projet avec init, Bubblewrap a besoin d'informations pour générer l'application Android. L'outil extrait les valeurs du fichier manifeste de l'application Web et fournit des valeurs par défaut dans la mesure du possible.
Vous pouvez modifier ces valeurs lorsque vous créez un projet, mais auparavant, la signification de chaque champ n'était pas claire. Les boîtes de dialogue d'initialisation ont été repensées avec de meilleures descriptions et une meilleure validation pour chaque champ de saisie.
Prise en charge de l'affichage plein écran et de l'orientation
Dans certains cas, vous pouvez souhaiter que votre application utilise autant d'espace que possible sur l'écran. Lorsque vous créez des PWA, vous pouvez implémenter cela en définissant le champ display du fichier manifeste de l'application Web sur fullscreen.
Lorsque Bubblewrap détecte l'option plein écran dans le fichier manifeste de l'application Web, il configure l'application Android pour qu'elle se lance également en plein écran ou en mode immersif, en termes spécifiques à Android.
Le champ orientation du fichier manifeste de l'application Web définit si l'application doit être lancée en mode Portrait, en mode Paysage ou dans l'orientation actuellement utilisée par l'appareil. Bubblewrap lit désormais le champ du fichier manifeste d'application Web et l'utilise par défaut lors de la création de l'application Android.
Vous pouvez personnaliser les deux configurations dans le cadre du flux bubblewrap init.
Sortie AppBundles
App Bundles est un format de publication d'applications qui délègue la génération et la signature de l'APK final à Play. En pratique, cela permet de diffuser des fichiers plus petits auprès des utilisateurs lorsqu'ils téléchargent l'application depuis le store.
Bubblewrap empaquette désormais l'application en tant qu'App Bundle, dans un fichier nommé app-release-bundle.aab. Nous vous recommandons de privilégier ce format lorsque vous publiez des applications sur le Play Store, car il est obligatoire depuis 2021.
Délégation de géolocalisation
Les utilisateurs s'attendent à ce que les applications installées sur leurs appareils se comportent de manière cohérente, quelle que soit la technologie. Lorsqu'elle est utilisée dans une activité Web fiable, l'autorisation GeoLocation peut désormais être déléguée au système d'exploitation. Lorsqu'elle est activée, les utilisateurs voient les mêmes boîtes de dialogue que les applications créées avec Kotlin ou Java, et trouvent des commandes pour gérer l'autorisation au même endroit.
Cette fonctionnalité peut être ajoutée via Bubblewrap. Comme elle ajoute des dépendances supplémentaires au projet Android, vous ne devez l'activer que lorsque l'application Web utilise l'autorisation de géolocalisation.
Binaires optimisés
Les appareils disposant d'un espace de stockage limité sont courants dans certaines régions du monde, et les propriétaires de ces appareils préfèrent souvent les applications de petite taille. Les applications utilisant une activité Web fiable produisent de petits binaires, ce qui réduit l'anxiété de ces utilisateurs.
Bubblewrap a été optimisé en réduisant la liste des bibliothèques Android nécessaires, ce qui permet de générer des binaires 800 Ko plus petits. En pratique, cela représente moins de la moitié de la taille moyenne générée par les versions précédentes. Pour profiter de binaires plus petits, il vous suffit de mettre à jour votre application à l'aide de la dernière version de Bubblewrap.
Mettre à jour une application existante
Une application générée par Bubblewrap est composée d'une application Web et d'un wrapper Android léger qui ouvre la PWA. Même si la PWA ouverte dans une activité Web fiable suit les mêmes cycles de mise à jour que n'importe quelle application Web, le wrapper natif peut et doit être mis à jour.
Vous devez mettre à jour votre application pour vous assurer qu'elle utilise la dernière version du wrapper, avec les dernières corrections de bugs et fonctionnalités. Une fois la dernière version de Bubblewrap installée, la commande update applique la dernière version du wrapper à un projet existant :
npm update -g @bubblewrap/cli
bubblewrap update
bubblewrap build
Une autre raison de mettre à jour ces applications est de s'assurer que les modifications apportées au fichier manifeste Web sont appliquées à l'application. Pour ce faire, utilisez la nouvelle commande merge :
bubblewrap merge
bubblewrap update
bubblewrap build
Mises à jour des critères de qualité
Chrome 86 a introduit des modifications dans les critères de qualité des activités Web fiables, qui sont expliqués en détail dans Modifications apportées aux critères de qualité des PWA utilisant une activité Web fiable.
En résumé, vous devez vous assurer que vos applications gèrent les scénarios suivants pour éviter qu'elles ne plantent :
- Échec de la validation des Digital Asset Links au lancement de l'application
- Échec du renvoi du code HTTP 200 pour une requête de ressource réseau hors connexion
- Renvoi d'une erreur HTTP 404 ou 5xx dans l'application.
En plus de s'assurer que l'application réussit la validation Digital Asset Links, les autres scénarios peuvent être gérés par un service worker :
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 intègre les bonnes pratiques et supprime le code récurrent lors de l'utilisation de service workers. Vous pouvez également envisager d'utiliser un plug-in Workbox pour gérer ces scénarios :
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,
});
}
}