Depuis le lancement de la fonctionnalité Activité Web fiable l'année dernière, l'équipe Chrome continue de travailler sur pour simplifier son utilisation avec Bubblewrap et ajouter de nouvelles fonctionnalités, comme la prochaine l'intégration de la facturation et sa compatibilité avec un plus grand nombre de plates-formes, comme ChromeOS. Cet article va résumer les dernières mises à jour et celles à venir concernant l'activité Web de confiance.
Nouvelles fonctionnalités Bubble wrap et Activité Web fiable
Bubblewrap vous permet de créer des applications qui lancent vos PWA au sein d'une activité Web fiable, sans nécessitant une connaissance des outils spécifiques à la plate-forme.
Flux de configuration simplifié
Auparavant, pour utiliser Bubblewrap, vous deviez configurer manuellement le kit de développement Java et Android SDK, qui sont tous deux sujets aux erreurs. L'outil propose désormais de télécharger automatiquement le fichier dépendances lorsqu'il est exécuté pour la première fois.
Vous pouvez toujours choisir d'utiliser une installation
existante des dépendances, si vous préférez le faire,
La nouvelle commande doctor permet d'identifier les problèmes et recommande des correctifs pour la configuration, ce qui peut
être mis à 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. La
extrait les valeurs du fichier manifeste d'application Web et fournit des valeurs par défaut si possible.
Vous pouvez modifier ces valeurs lors de la création d'un projet, mais auparavant la signification de chaque champ n'était pas . Les boîtes de dialogue d'initialisation ont été recompilées avec de meilleures descriptions et une meilleure validation pour chaque .
affichage: 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 sur l'écran.
pour créer des 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 de l'application Web, il configure l'Android l'application pour pouvoir la lancer en plein écran ou en mode immersif, avec des conditions spécifiques à Android.
Le champ orientation du fichier manifeste d'application Web indique si l'application doit être démarrée dans
le mode Portrait ou Paysage, ou l'orientation de l'appareil. Papier bulle maintenant
lit 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 AppBundles
Les app bundles sont un format de publication pour les applications qui délèguent la génération finale de l'APK et à Play. En pratique, cela permet de diffuser des fichiers plus petits auprès des utilisateurs lorsqu'ils téléchargent le l'application sur le Play Store.
Bubblewrap crée désormais un package de l'application en tant qu'app bundle, dans un fichier appelé
app-release-bundle.aab Nous vous recommandons de choisir ce format lorsque vous publiez des applications sur le Play Store.
car il sera requis par le Play Store à partir du second semestre 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, quels que soient de l'IA générative. Lorsqu'elle est utilisée dans une activité Web fiable, l'autorisation GeoLocation peut désormais être délégués au système d'exploitation. Lorsque cette option est activée, les utilisateurs voient les mêmes boîtes de dialogue que les applications créées avec Kotlin ou Java, et accédez aux commandes permettant de gérer les autorisations au même endroit.
Cette fonctionnalité peut être ajoutée via Bubblewrap et, comme elle ajoute des dépendances supplémentaires à la version vous ne devez l'activer que lorsque l'application Web utilise l'autorisation Géolocalisation.
Binaires optimisés
Il est courant dans certaines régions du monde d'avoir des appareils dont l'espace de stockage est limité, et les propriétaires de ces appareils préfèrent souvent des applications plus petites. Les applications qui utilisent l'activité Web fiable produisent binaires, ce qui élimine une partie de l'anxiété de ces utilisateurs.
Le Bubblewrap a été optimisé en réduisant la liste des bibliothèques Android nécessaires, ce qui se traduit par binaires générés dont la taille est inférieure de 800 000. En pratique, c'est moins de la moitié de la taille moyenne générées par les versions précédentes. Pour tirer parti des 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 se compose d'une application Web et d'une application Android légère qui ouvre la PWA. Même si la PWA ouverte dans une activité Web fiable suit le 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 la dernière version
corrections de bugs et fonctionnalités. Avec la dernière version de Bubblewrap installée, la commande update
appliquez 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 du fichier manifeste Web sont
appliquée à l'application. Pour cela, utilisez la nouvelle commande merge:
bubblewrap merge
bubblewrap update
bubblewrap build
Modifications apportées aux critères de qualité
Chrome 86 a apporté des modifications aux critères de qualité des activités sur le Web de confiance, qui sont expliquées dans consultez l'article Modifications apportées aux 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 pour empêcher leur plantage:
- Échec de la vérification des liens vers les ressources numériques lors du lancement de l'application
- L'échec de l'affichage du code HTTP 200 pour une requête de ressources réseau hors connexion
- Le renvoi d'une erreur HTTP 404 ou 5xx dans l'application
En plus de s'assurer que l'application est validée Digital Asset Links, les autres 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 élimine le code récurrent lors de l'utilisation de service workers. Vous pouvez également 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 vous permettre de vendre des produits numériques et des abonnements sur le Play Store, Google Play Billing propose des outils pour gérer votre catalogue, vos prix et vos abonnements. et un processus de paiement déjà connu de vos utilisateurs, optimisé par le Play Store. Il est également obligatoire pour les applications publiées sur le Play Store qui vendent des produits numériques.
Chrome 88 lancera une phase d'évaluation sur Android qui permettra d'intégrer Trusted Web Activity (Activités Web fiables), l'API Payment Request et l'API Digital Goods (Produits numériques) pour implémenter des parcours d'achat via Google Play Billing. Cette phase d'évaluation devrait également être disponible pour ChromeOS sur la version 89.
Important:L'API Google Play Billing possède sa propre terminologie, et inclut les API composants backend. Cette section ne concerne qu'une petite partie de l'API, spécifique à l'utilisation de la classe API Digital Goods et Trusted Web Activity Veillez à lire les documentation Google Play Billing et comprendre ses concepts avant de l'intégrer à un application de production.
Procédure de base
Pour fournir des produits numériques via le Play Store, vous devez configurer votre catalogue sur le Play Store et associez le Play Store en tant que mode de paiement depuis votre PWA.
Lorsque vous êtes prêt à configurer votre catalogue, commencez par trouver la section "Produits" sur la gauche dans le menu latéral de la Play Console:
Vous y trouverez une option vous permettant d'afficher vos abonnements et produits intégrés existants, ainsi que recherchez le bouton "Créer" pour en ajouter de nouveaux.
Pour créer un produit intégré, vous avez besoin d'un ID produit, d'un nom, d'une description et d'un prix. Il est important de créer des identifiants produit significatifs et faciles à mémoriser, vous en aurez besoin plus tard et les identifiants ne peut plus être modifié une fois créé.
Lorsque vous créez des abonnements, vous devez également spécifier une période de facturation. Vous avez la possibilité énumérez les avantages de votre abonnement et ajoutez des fonctionnalités comme si vous bénéficiez d'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. Toi utilise une combinaison de l'API Digital Goods et de l'API Payment Request pour obtenir cette étape.
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 présenté aux utilisateurs correspond au même prix le prix indiqué sur la fiche Play Store. Il serait impossible de synchroniser manuellement ces prix. l'API Digital Goods permet à l'application Web d'interroger le mode de paiement sous-jacent fournisseur pour 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 l'assistance pour l'API Digital Goods en vérifiant si getDigitalGoodsService() est
disponible sur l'objet window.
Appelez ensuite window.getDigitalGoodsService() avec l'identifiant Google Play Billing comme paramètre.
Une instance de service sera alors renvoyée pour Google Play Billing, et les autres fournisseurs pourront mettre en œuvre l'assistance
pour l'API Digital Goods et ont des identifiants différents.
Enfin, appelez getDetails() sur la référence à l'objet Google Play Billing qui transmet le SKU pour
l'élément en tant que paramètre. Cette méthode renvoie un objet "detail" contenant à la fois le prix et le paramètre
la devise de l'élément
qui peut être présentée à l'utilisateur.
Démarrer le parcours d'achat
L'API Payment Request active les parcours d'achat sur le Web et est également utilisée pour Google Play Intégration de la facturation. Si vous faites vos premiers pas avec l'API Payment, consultez cette page sur le fonctionnement de l'API Payment Request. API Request.
Pour utiliser l'API avec Google Play Billing, vous devez ajouter un mode de paiement,
possède un métod compatible appelé https://play.google.com/billing et ajoute le SKU dans les données
pour l'instrument:
const supportedInstruments = [{
supportedMethods: "https://play.google.com/billing",
data: {
sku: sku
}
}];
Ensuite, créez un objet PaymentRequest comme d'habitude et utilisez l'API normalement.
const request = new PaymentRequest(supportedInstruments, details);
Confirmer l'achat
Une fois la transaction terminée, vous devez utiliser l'API Digital Goods pour accepter
le paiement. L'objet de réponse de PaymentRequest contiendra un jeton que vous utiliserez pour
Confirmez 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');
L'API Digital Goods et l'API Payment Request ne disposent pas de connaissances sur l'identité de l'utilisateur. En tant que c'est à vous d'associer l'achat à l'utilisateur dans votre backend et de vous assurer qu'il a l'accès aux articles achetés. Lorsque vous associez l'achat à un utilisateur, n'oubliez pas d'enregistrer le 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. Découvrez l'API de notifications en temps réel pour les développeurs et le L'API Google Play Developer, car elle fournit des points de terminaison pour gérer ces demandes dans votre backend.
Vérifier les droits d'accès existants
Il se peut qu'un utilisateur ait déjà utilisé un code promotionnel ou qu'il ait déjà souscrit un abonnement à votre produit. Dans
afin de vérifier que l'utilisateur dispose des droits d'accès appropriés, vous pouvez appeler
listPurchases() sur le service d'articles numériques. Vous obtiendrez ainsi tous les achats
effectuées par le client dans votre application. C’est aussi l’endroit pour accuser réception
de toute notification non confirmée
achats pour s'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 dans le Play Store de ChromeOS
Les activités Web fiables sont également disponibles depuis Chrome 85 sur le Play Store de ChromeOS. Procédure de lister votre application sur le Play Store est la même chose pour ChromeOS et Android.
Une fois votre app bundle créé, la Play Console vous guide tout au long des étapes étapes pour lister l'application sur le Play Store. Dans la documentation de la Play Console, vous trouverez de l'aide pour créez la fiche de votre application, gérez les fichiers APK, les autres paramètres et les instructions. pour tester et publier votre appli en toute sécurité.
Pour limiter votre application aux Chromebooks uniquement, ajoutez l'indicateur --chromeosonly lors de l'initialisation
l'application dans Bubblewrap:
bubblewrap init --manifest="https://example.com/manifest.json" --chromeosonly
Lorsque vous créez votre application manuellement, sans Bubblewrap, 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 aura toujours par rapport à la version du package d'application Android. Vous pouvez configurer la version du bundle ChromeOS sur bien plus élevé que la version d'Android. Vous n'avez donc pas besoin de mettre à jour les deux versions de sortie.