Depuis le lancement de l'activité Web fiable l'année dernière, l'équipe Chrome continue de travailler sur ce produit pour en faciliter l'utilisation avec Bubblewrap, ajouter de nouvelles fonctionnalités telles que l'intégration de Google Play Billing à venir et le rendre compatible avec davantage de plates-formes, comme ChromeOS. Cet article récapitule les dernières mises à jour et celles à venir concernant l'activité Web sécurisée.
Nouvelles fonctionnalités du papier bulle et de l'activité Web fiable
Bubblewrap vous permet de créer des applications qui lancent vos PWA dans une activité Web fiable, sans que vous ayez 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 sa 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 recommande des correctifs pour la configuration, qui peut maintenant être mise à jour à partir de la ligne de commande à l'aide de la commande updateConfig.
Assistant amélioré
Lors de la création d'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 lorsque cela est possible.
Vous pouvez modifier ces valeurs lors de la création d'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 une meilleure validation pour chaque champ de saisie.
affichage: prise en charge du mode plein écran et de l'orientation
Dans certains cas, vous souhaiterez peut-être que votre application utilise autant de l'écran que possible. Lors de la création de PWA, cela est implémenté 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 s'ouvre également en plein écran, ou en mode immersif, dans les termes spécifiques à Android.
Le champ orientation du fichier manifeste de l'application Web définit si l'application doit être démarrée en mode portrait, paysage ou dans l'orientation actuellement utilisée par l'appareil. Bubblewrap lit désormais le champ "Manifeste de l'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 AppBundles
Les app bundles sont un format de publication pour les applications qui délègue la génération finale de l'APK et la signature à Play. En pratique, cela permet de diffuser des fichiers plus petits auprès des utilisateurs lorsqu'ils téléchargent l'application depuis la plate-forme.
Bubblewrap empaquette à présent 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 sera obligatoire à partir du second semestre 2021.
Délégation de géolocalisation
Les utilisateurs s'attendent à ce que les applications installées sur leurs appareils fonctionnent de manière cohérente, quelle que soit la technologie utilisée. Lorsqu'elle est utilisée dans une activité Web de confiance, 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 les commandes permettant de gérer l'autorisation au même endroit.
Vous pouvez ajouter cette fonctionnalité à l'aide d'une bulle de texte. Comme elle ajoute des dépendances supplémentaires au projet Android, vous ne devez l'activer que lorsque l'application Web utilise l'autorisation Geolocation.
Binaires optimisés
Les appareils à stockage limité sont courants dans certaines régions du monde et les propriétaires de ces appareils préfèrent souvent les applications plus petites. Les applications qui utilisent l'activité Web sécurisée produisent de petits fichiers binaires, ce qui élimine une partie de l'angoisse de ces utilisateurs.
Le wrapper à bulles a été optimisé en réduisant la liste des bibliothèques Android nécessaires, ce qui a pour effet de réduire la taille de fichiers binaires générés de 800 000. En pratique, cela représente moins de la moitié de la taille moyenne générée par les versions précédentes. Pour tirer parti des binaires plus petits, il vous suffit de mettre à jour votre application en utilisant la dernière version de Bubblewrap.
Mettre à jour une application existante
Une application générée par Bubblewrap se compose 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. Avec 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
Il est également nécessaire de mettre à jour ces applications pour s'assurer que les modifications apportées au fichier manifeste Web sont bien appliquées à l'application. Pour ce faire, utilisez la nouvelle commande merge:
bubblewrap merge
bubblewrap update
bubblewrap build
Mise à jour des critères de qualité
Chrome 86 a apporté des modifications aux critères de qualité pour l'activité Web de confiance, qui sont expliqués en détail dans la section Modifications apportées aux critères de qualité pour les PWA utilisant l'activité Web de confiance.
En résumé, vous devez vous assurer que vos applications gèrent les scénarios suivants pour éviter leur plantage:
- Défaut de validation des liens vers les ressources numériques lors du 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 lorsque vous utilisez des 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,
});
}
}
Google Play Billing
En plus de permettre à votre application de vendre des produits numériques et des abonnements sur le Play Store, Google Play Billing propose des outils de gestion de votre catalogue, des prix et des abonnements, des rapports utiles et un processus de paiement optimisé par le Play Store et que vos utilisateurs connaissent déjà. Il s'agit également d'une exigence pour les applications publiées sur le Play Store qui vendent des produits numériques.
Chrome 88 sera lancé lors d'une phase d'évaluation sur Android permettant d'intégrer les activités Web fiables, l'API Payment Request et l'API Digital Goods pour implémenter les parcours d'achat via Google Play Billing. Cette phase d'évaluation devrait également être disponible pour ChromeOS à partir de la version 89.
Important:L'API Google Play Billing possède sa propre terminologie, et inclut des composants client et backend. Cette section ne couvre qu'une petite partie de l'API, spécifique à l'utilisation de l'API Digital Goods et de l'activité Web sécurisée. Veillez à lire la documentation Google Play Billing et à comprendre ses concepts avant de l'intégrer à une application de production.
Procédure de base
Pour proposer des produits numériques sur le Play Store, vous devez configurer votre catalogue sur le Play Store et associer le Play Store comme mode de paiement à partir de votre PWA.
Lorsque vous êtes prêt à configurer votre catalogue, commencez par accéder à la section "Produits" dans le menu de gauche de la Play Console:
Vous y trouverez l'option permettant d'afficher vos abonnements et produits intégrés existants, ainsi que le bouton "Créer" pour en ajouter de nouveaux.
Pour créer un produit intégré, vous avez besoin d'un identifiant produit, de son nom, d'une description et d'un prix. Il est important de créer des ID produit pertinents et faciles à mémoriser. Vous en aurez besoin ultérieurement. Une fois créés, les ID ne peuvent plus être modifiés.
Lorsque vous créez des abonnements, vous devez également spécifier une période de facturation. Vous avez la possibilité de lister les avantages de votre abonnement et d'ajouter des fonctionnalités, comme un essai sans frais, un prix découverte, un délai de grâce et une option de réabonnement.
Après avoir créé chaque produit, activez-le pour le rendre disponible dans votre application.
Si vous préférez, vous pouvez ajouter vos produits via l'API Play Developers.
Une fois votre catalogue configuré, l'étape suivante consiste à configurer le processus de paiement à partir de la PWA. Pour ce faire, vous devez combiner l'API Digital Goods et l'API Payment Request.
Récupérer le prix d'un produit avec l'API Digital Goods
Lorsque vous utilisez Google Play Billing, vous devez vous assurer que le prix affiché pour les utilisateurs correspond à celui indiqué sur la fiche Play Store. Il serait impossible de synchroniser manuellement ces prix. L'API Digital Goods offre donc à l'application Web un moyen d'interroger le fournisseur de paiement sous-jacent pour connaître les prix:
// The SKU for the product, as defined in the Play Store interface
async function populatePrice(sku) {
try {
// Check if the Digital Goods API is supported by the browser.
if (window.getDigitalGoodsService) {
// The Digital Goods API can be supported by other Payments provider.
// In this case, we're retrieving the Google Play Billing provider.
const service =
await window.getDigitalGoodsService("https://play.google.com/billing");
// Fetch product details using the `getDetails()` method.
const details = await service.getDetails([sku]);
if (details.length === 0) {
console.log(`Could not get SKU: "${sku}".`);
return false;
}
// The details will contain both the price and the currenncy.
item = details[0];
const value = item.price.value;
const currency = item.price.currency;
const formattedPrice = new Intl.NumberFormat(navigator.language, {
style: 'currency', currency: currency }).format(value);
// Display the price to the user.
document.getElementById("price").innerHTML = formattedPrice;
} else {
console.error("Could not get price for SKU \"" + sku + "\".");
}
} catch (error) {
console.log(error);
}
return false;
}
Vous pouvez détecter la prise en charge de l'API Digital Goods en vérifiant si getDigitalGoodsService() est disponible dans l'objet window.
Appelez ensuite window.getDigitalGoodsService() avec l'identifiant Google Play Billing en tant que paramètre.
Cela renverra une instance de service pour Google Play Billing. D'autres fournisseurs pourront implémenter la prise en charge de l'API Digital Goods et disposeront d'identifiants différents.
Enfin, appelez getDetails() sur la référence à l'objet Google Play Billing transmettant le SKU de l'article en tant que paramètre. La méthode renvoie un objet "details" contenant à la fois le prix et la devise de l'article, qui peuvent être présentés à l'utilisateur.
Démarrer le parcours d'achat
L'API Payment Request facilite les parcours d'achat sur le Web et est également utilisée pour l'intégration de Google Play Billing. Si vous débutez avec l'API Payment Request, consultez cette page sur le fonctionnement de l'API Payment Request.
Pour utiliser l'API avec Google Play Billing, vous devez ajouter un mode de paiement disposant d'un metod compatible appelé https://play.google.com/billing, puis ajouter le SKU dans les données du mode:
const supportedInstruments = [{
supportedMethods: "https://play.google.com/billing",
data: {
sku: sku
}
}];
Ensuite, créez un objet PaymentRequest comme vous le faites habituellement et utilisez l'API comme vous le faites habituellement.
const request = new PaymentRequest(supportedInstruments, details);
Confirmer l'achat
Une fois la transaction terminée, vous devez utiliser l'API Digital Goods pour confirmer le paiement. L'objet de réponse de PaymentRequest contient un jeton que vous utiliserez pour accuser réception de la transaction:
const response = await request.show();
const token = response.details.token;
const service =
await window.getDigitalGoodsService("https://play.google.com/billing");
await service.acknowledge(token, 'onetime');
Les API Digital Goods et Payment Request ne connaissent pas l'identité de l'utilisateur. Il vous appartient donc d'associer l'achat à l'utilisateur dans votre backend et de vous assurer qu'il a accès aux articles achetés. Lorsque vous associez l'achat à un utilisateur, n'oubliez pas d'enregistrer le jeton d'achat, car vous en aurez peut-être besoin pour vérifier si l'achat a été annulé ou remboursé, ou si un abonnement est toujours actif. Consultez l'API Real Time Developer Notifications et l'API Google Play Developer, car elles fournissent des points de terminaison pour gérer ces cas dans votre backend.
Vérifier les droits d'accès existants
Un utilisateur peut avoir utilisé un code promotionnel ou disposer d'un abonnement existant pour votre produit. Pour vérifier que l'utilisateur dispose des droits d'accès appropriés, vous pouvez appeler la commande listPurchases() sur le service de produits numériques. Tous les achats que votre client a effectués dans votre application s'affichent alors. Vous pouvez également confirmer les achats non confirmés pour vous assurer que l'utilisateur utilise correctement ses droits d'accès.
const purchases = await itemService.listPurchases();
for (p of purchases) {
if (!p.acknowledged) {
await itemService.acknowledge(p.purchaseToken, 'onetime');
}
}
Importer sur le Play Store ChromeOS
Les activités Web fiables sont également disponibles depuis Chrome 85 sur le Play Store de ChromeOS. Le processus d'ajout de votre application sur la plate-forme de téléchargement d'applications est le même pour ChromeOS et Android.
Une fois votre app bundle créé, la Play Console vous guide tout au long des étapes requises pour afficher l'application sur le Play Store. Dans la documentation de la Play Console, vous pouvez obtenir de l'aide pour créer la fiche de votre application, gérer vos fichiers APK et d'autres paramètres, ainsi que des instructions pour tester votre application et la publier en toute sécurité.
Pour limiter votre application aux Chromebooks, ajoutez l'indicateur --chromeosonly lors de l'initialisation de l'application dans Bubblewrap:
bubblewrap init --manifest="https://example.com/manifest.json" --chromeosonly
Lorsque vous compilez votre application manuellement, sans Bubble wrap, ajoutez un indicateur uses-feature à votre fichier manifeste Android:
<uses-feature android:name="org.chromium.arc" android:required="true"/>
Si votre fiche est partagée avec une application Android, la version du package uniquement ChromeOS devra toujours être ultérieure à la version du package d'application Android. Vous pouvez définir un numéro de version du bundle ChromeOS bien supérieur à celui de la version d'Android. Vous n'avez donc pas besoin de mettre à jour les deux versions à chaque version.