Publié le 2 décembre 2020
Depuis l'introduction de l'activité Web fiable, l'équipe Chrome a simplifié son utilisation avec Bubblewrap. Nous avons ajouté des fonctionnalités supplémentaires, comme l'intégration de Google Play Billing, et avons rendu la fonctionnalité compatible avec davantage de plates-formes, comme ChromeOS.
Fonctionnalités Bubblewrap et Activité Web fiable
Bubblewrap vous permet de créer des applications qui lancent vos PWA dans une activité Web fiable, sans avoir besoin de connaître les outils spécifiques à la plate-forme.
Flux de configuration simplifié
Auparavant, l'utilisation de Bubblewrap nécessitait de configurer manuellement le kit de développement Java et le SDK Android, qui sont tous deux sujets aux erreurs. L'outil propose désormais de télécharger automatiquement les dépendances externes lors de la première exécution.
Si vous préférez, vous pouvez toujours choisir d'utiliser une installation existante des dépendances. La nouvelle commande doctor vous aide à détecter les problèmes et vous recommande des corrections pour la configuration, qui peut maintenant ê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 des valeurs du fichier manifeste d'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é recréées avec de meilleures descriptions et validations pour chaque champ de saisie.
Afficher la prise en charge du plein écran et de l'orientation
Dans certains cas, vous souhaiterez peut-être que votre application utilise le plus d'espace possible à l'écran. Lors de la création de PWA, vous devez définir le champ display du fichier manifeste d'application Web sur fullscreen.
Lorsque Bubblewrap détecte l'option plein écran dans le fichier manifeste d'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 d'application Web définit si l'application doit être démarrée en mode portrait, en mode paysage ou dans l'orientation 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 flux bubblewrap init.
Sortie des app bundles
App Bundle est un format de publication pour les applications qui délègue la génération et la signature finales de l'APK à Play. En pratique, cela permet de proposer des fichiers plus petits aux utilisateurs lors du téléchargement de l'application depuis la plate-forme.
Bubblewrap empaquette désormais l'application en tant qu'App Bundle, dans un fichier appelé app-release-bundle.aab. Vous devez privilégier ce format lorsque vous publiez des applications sur le Play Store, car il est requis par le Play Store 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 sécurisée, l'autorisation Position géographique peut désormais être déléguée au système d'exploitation. Lorsque cette autorisation est activée, les utilisateurs voient les mêmes boîtes de dialogue que les applications créées avec Kotlin ou Java, et trouvent les commandes permettant de gérer l'autorisation au même endroit.
La fonctionnalité peut être ajoutée via Bubblewrap. Étant donné qu'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 à espace de stockage limité sont courants dans certaines régions du monde, et les propriétaires de ces appareils préfèrent souvent des applications plus petites. Les applications qui utilisent l'activité Web sécurisée produisent de petits binaires, ce qui réduit l'anxiété de ces utilisateurs.
Le wrapper a été optimisé en réduisant la liste des bibliothèques Android nécessaires, ce qui génère des binaires générés 800 000 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 des binaires plus petits, il vous suffit de mettre à jour votre application avec 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 de confiance 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 cela, utilisez la nouvelle commande merge:
bubblewrap merge
bubblewrap update
bubblewrap build
Mises à jour des critères de qualité
Chrome 86 a apporté des modifications aux critères de qualité des activités Web fiables, qui sont expliqués en détail dans la section Modifications des critères de qualité pour les PWA utilisant Trusted Web Activity.
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 liens vers des composants numériques au lancement de l'application
- Échec de la réponse 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 passe la validation Digital Asset Links, les scénarios restants 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 les éléments standards 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,
});
}
}