Sinds Trusted Web Activity vorig jaar werd geïntroduceerd, blijft het Chrome-team aan het product werken, waardoor het gemakkelijker te gebruiken is met Bubblewrap, nieuwe functies worden toegevoegd, zoals de aanstaande Google Play Billing-integratie, en het op meer platforms, zoals ChromeOS, kan werken. In dit artikel worden de nieuwste en komende updates voor Trusted Web Activity samengevat.
Nieuwe Bubblewrap- en Trusted Web Activity-functies
Met Bubblewrap kunt u apps maken die uw PWA's starten binnen een vertrouwde webactiviteit, zonder dat u kennis van platformspecifieke tools nodig heeft.
Vereenvoudigde installatiestroom
Voorheen vereiste het gebruik van Bubblewrap het handmatig instellen van de Java Development Kit en de Android SDK, die beide foutgevoelig zijn. De tool biedt nu de mogelijkheid om automatisch de externe afhankelijkheden te downloaden wanneer deze voor de eerste keer wordt uitgevoerd.
U kunt er nog steeds voor kiezen om een bestaande installatie van de afhankelijkheden te gebruiken, als u dat liever doet, en het nieuwe doctor commando helpt bij het vinden van problemen en beveelt oplossingen aan voor de configuratie, die nu kan worden bijgewerkt vanaf de opdrachtregel met behulp van de opdracht updateConfig .
Verbeterde tovenaar
Bij het maken van een project met init heeft Bubblewrap informatie nodig om de Android-app te genereren. De tool haalt waarden uit het Web App Manifest en biedt waar mogelijk standaardwaarden.
U kunt deze waarden wijzigen wanneer u een nieuw project aanmaakt, maar voorheen was de betekenis van elk veld niet duidelijk. De initialisatiedialogen zijn opnieuw opgebouwd met betere beschrijvingen en validatie voor elk invoerveld.
weergave: volledig scherm en oriëntatieondersteuning
In sommige gevallen wilt u misschien dat uw applicatie een zo groot mogelijk deel van het scherm gebruikt. Bij het bouwen van PWA's wordt dit geïmplementeerd door het display van het Web App Manifest in te stellen op fullscreen .
Wanneer Bubblewrap de optie voor volledig scherm in het Web App Manifest detecteert, wordt de Android-applicatie geconfigureerd om ook op volledig scherm of in meeslepende modus te starten, in Android-specifieke termen.
Het orientation van het Web App Manifest definieert of de applicatie moet worden gestart in portretmodus, landschapsmodus of in de oriëntatie die het apparaat momenteel gebruikt. Bubblewrap leest nu het veld Web App Manifest en gebruikt dit standaard bij het maken van de Android-app.
U kunt beide configuraties aanpassen als onderdeel van de bubblewrap init stroom.
AppBundles-uitvoer
App Bundles is een publicatieformaat voor apps dat de uiteindelijke APK-generatie en ondertekening delegeert aan Play. Hierdoor kunnen in de praktijk kleinere bestanden aan gebruikers worden aangeboden bij het downloaden van de app uit de store.
Bubblewrap verpakt de applicatie nu als een app-bundel, in een bestand met de naam app-release-bundle.aab . U zou de voorkeur moeten geven aan dit formaat wanneer u apps publiceert in de Play Store, aangezien dit vanaf de tweede helft van 2021 door de winkel vereist zal zijn.
Delegatie van geolocatie
Gebruikers verwachten dat applicaties die op hun apparaten zijn geïnstalleerd zich consistent gedragen, ongeacht de technologie. Bij gebruik binnen een vertrouwde webactiviteit kan de GeoLocation- machtiging nu worden gedelegeerd aan het besturingssysteem en, indien ingeschakeld, zien gebruikers dezelfde dialoogvensters als apps die zijn gebouwd met Kotlin of Java, en vinden ze bedieningselementen om de machtiging op dezelfde plaats te beheren.
De functie kan worden toegevoegd via Bubblewrap en omdat het extra afhankelijkheden aan het Android-project toevoegt, moet u deze alleen inschakelen als de webapp de toestemming voor geolocatie gebruikt.
Geoptimaliseerde binaire bestanden
Apparaten met beperkte opslagruimte zijn gebruikelijk in bepaalde delen van de wereld, en eigenaren van dergelijke apparaten geven vaak de voorkeur aan kleinere toepassingen. Applicaties die Trusted Web Activity gebruiken, produceren kleine binaire bestanden, waardoor een deel van de angst bij deze gebruikers wordt weggenomen.
Bubblewrap is geoptimaliseerd door de lijst met benodigde Android-bibliotheken te verkleinen, wat resulteert in gegenereerde binaire bestanden die 800k kleiner zijn. In de praktijk is dat minder dan de helft van de gemiddelde grootte van eerdere versies. Om te profiteren van de kleinere binaire bestanden, hoeft u uw app alleen maar bij te werken met de nieuwste versie van Bubblewrap.
Hoe u een bestaande app kunt updaten
Een door Bubblewrap gegenereerde applicatie bestaat uit een webapplicatie en een lichtgewicht Android-wrapper die de PWA opent. Hoewel de PWA die in een vertrouwde webactiviteit wordt geopend, dezelfde updatecycli volgt als elke andere webapp, kan en moet de native wrapper worden bijgewerkt.
U moet uw app bijwerken om er zeker van te zijn dat deze de nieuwste versie van de wrapper gebruikt, met de nieuwste bugfixes en functies. Als de nieuwste versie van Bubblewrap is geïnstalleerd, past de opdracht update de nieuwste versie van de wrapper toe op een bestaand project:
npm update -g @bubblewrap/cli
bubblewrap update
bubblewrap build
Een andere reden om deze applicaties bij te werken is ervoor te zorgen dat wijzigingen in het webmanifest op de applicatie worden toegepast. Gebruik daarvoor het nieuwe merge commando:
bubblewrap merge
bubblewrap update
bubblewrap build
Updates van de kwaliteitscriteria
Chrome 86 heeft wijzigingen geïntroduceerd in de kwaliteitscriteria voor vertrouwde webactiviteiten, die volledig worden uitgelegd in Wijzigingen in kwaliteitscriteria voor PWA's die vertrouwde webactiviteit gebruiken .
Een korte samenvatting is dat u ervoor moet zorgen dat uw toepassingen met de volgende scenario's omgaan om te voorkomen dat ze crashen:
- Kan de koppelingen naar digitale middelen niet verifiëren bij het starten van de applicatie
- Kan HTTP 200 niet retourneren voor een offline netwerkbronverzoek
- Terugkeer van een HTTP 404- of 5xx-fout in de applicatie.
Naast dat de applicatie de validatie van Digital Asset Links doorstaat, kunnen de overige scenario's door een servicemedewerker worden afgehandeld:
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 bakt volgens de beste praktijken en verwijdert standaardwerk bij het gebruik van servicemedewerkers. U kunt ook overwegen een Workbox-plug-in te gebruiken om deze scenario's af te handelen:
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-facturering
Naast dat uw app digitale goederen en abonnementen kan verkopen in de Play Store, biedt Google Play Billing tools voor het beheren van uw catalogus, prijzen en abonnementen, nuttige rapporten en een betaalstroom mogelijk gemaakt door de Play Store die al bekend is bij uw gebruikers. Het is ook een vereiste voor applicaties die in de Play Store zijn gepubliceerd en die digitale goederen verkopen.
Chrome 88 wordt gelanceerd met een origin-proefversie op Android die de integratie van Trusted Web Activity , de Payment Request API en de Digital Goods API mogelijk maakt om aankoopstromen via Google Play Billing te implementeren. We verwachten dat deze Origin Trial vanaf versie 89 ook beschikbaar zal zijn voor ChromeOS.
Belangrijk: De Google Play Billing API heeft zijn eigen terminologie en omvat client- en backend-componenten. Dit gedeelte behandelt slechts een klein deel van de API die specifiek is voor het gebruik van de Digital Goods API en Trusted Web Activity. Zorg ervoor dat u de Google Play Billing-documentatie leest en de concepten ervan begrijpt voordat u deze in een productietoepassing integreert.
De basisstroom
Om digitale goederen via de Play Store aan te bieden, moet u uw catalogus in de Play Store configureren en de Play Store als betaalmethode vanuit uw PWA verbinden.
Wanneer u klaar bent om uw catalogus te configureren, gaat u eerst naar de sectie Producten in het menu aan de linkerkant van de Play Console:
Hier vindt u de mogelijkheid om uw bestaande in-app-producten en abonnementen te bekijken en vindt u ook de knop Aanmaken om nieuwe toe te voegen.
Om een nieuw in-app-product te maken, heeft u een product-ID, naam, beschrijving en een prijs nodig. Het is belangrijk om betekenisvolle en gemakkelijk te onthouden product-ID's te maken. U heeft ze later nodig en de ID's kunnen niet meer worden gewijzigd nadat ze zijn gemaakt.
Bij het aanmaken van abonnementen moet u ook een factureringsperiode opgeven. U heeft de mogelijkheid om uw abonnementsvoordelen op te sommen en functies toe te voegen, zoals of u een gratis proefperiode, een introductieprijs, een respijtperiode en een optie voor opnieuw abonneren heeft.
Nadat u elk product heeft gemaakt, maakt u het beschikbaar via uw app door het te activeren.
Als u wilt, kunt u uw producten toevoegen via de Play Developers API .
Zodra uw catalogus is geconfigureerd, is de volgende stap het configureren van de afrekenstroom vanuit de PWA. Om dit te bereiken, gebruikt u een combinatie van de Digital Goods API en de Payment Request API .
Haal een productprijs op met de Digital Goods API
Wanneer u Google Play Billing gebruikt, moet u ervoor zorgen dat de prijs die aan gebruikers wordt weergegeven, overeenkomt met de prijs uit de winkelvermelding. Het zou onmogelijk zijn om deze prijzen handmatig gesynchroniseerd te houden, dus de Digital Goods API biedt de webapplicatie een manier om de onderliggende betalingsprovider om prijzen te vragen:
// 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;
}
U kunt ondersteuning voor de Digital Goods API detecteren door te controleren of getDigitalGoodsService() beschikbaar is voor het window object.
Roep vervolgens window.getDigitalGoodsService() aan met de Google Play Billing-ID als parameter. Hierdoor wordt een service-instantie voor Google Play Billing geretourneerd en kunnen andere leveranciers ondersteuning voor de Digital Goods API implementeren en verschillende ID's hebben.
Roep ten slotte getDetails() aan voor de verwijzing naar het Google Play Billing-object en geef de SKU voor het item door als parameter. De methode retourneert een detailobject dat zowel de prijs als de valuta voor het item bevat, dat aan de gebruiker kan worden weergegeven.
Start de aankoopstroom
De Payment Request API maakt aankoopstromen op internet mogelijk en wordt ook gebruikt voor de Google Play Billing-integratie. Bekijk dit artikel Hoe de API voor betalingsverzoeken werkt voor meer informatie als u nieuw bent bij de API voor betalingsverzoeken.
Als u de API wilt gebruiken met Google Play Billing, moet u een betaalinstrument toevoegen met een ondersteunde methode genaamd https://play.google.com/billing en de SKU toevoegen als onderdeel van de gegevens voor het instrument:
const supportedInstruments = [{
supportedMethods: "https://play.google.com/billing",
data: {
sku: sku
}
}];
Bouw vervolgens zoals gewoonlijk een PaymentRequest object en gebruik de API zoals gewoonlijk
const request = new PaymentRequest(supportedInstruments, details);
Erken de aankoop
Zodra de transactie is voltooid, moet u de Digital Goods API gebruiken om de betaling te bevestigen. Het responsobject van het PaymentRequest bevat een token dat u gebruikt om de transactie te bevestigen:
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');
De Digital Goods API en de Payment Request API hebben geen kennis over de identiteit van de gebruiker. Als gevolg hiervan is het aan u om de aankoop te koppelen aan de gebruiker in uw backend en ervoor te zorgen dat deze toegang heeft tot de gekochte items. Wanneer u de aankoop aan een gebruiker koppelt, vergeet dan niet om de aankooptoken op te slaan, omdat u deze mogelijk nodig heeft om te verifiëren of de aankoop is geannuleerd of terugbetaald, of dat een abonnement nog steeds actief is. Bekijk de Real Time Developer Notifications API en de Google Play Developer API , aangezien deze eindpunten bieden voor het afhandelen van deze cases in uw backend.
Controleer op bestaande rechten
Een gebruiker heeft mogelijk een promotiecode ingewisseld of heeft mogelijk een bestaand abonnement op uw product. Om te valideren dat de gebruiker over de juiste rechten beschikt, kunt u de opdracht listPurchases() aanroepen op de digitale goederenservice. Hiermee worden alle aankopen geretourneerd die uw klant in uw app heeft gedaan. Dit is ook de plek waar u eventuele niet-erkende aankopen kunt bevestigen om ervoor te zorgen dat de gebruiker zijn rechten correct inwisselt.
const purchases = await itemService.listPurchases();
for (p of purchases) {
if (!p.acknowledged) {
await itemService.acknowledge(p.purchaseToken, 'onetime');
}
}
Uploaden naar de ChromeOS Play Store
Trusted Web Activity is sinds Chrome 85 ook beschikbaar in de ChromeOS Play Store. Het proces om uw app in de winkel te vermelden is voor ChromeOS hetzelfde als voor Android.
Nadat u uw appbundel heeft gemaakt, begeleidt de Play Console u door de vereiste stappen om de app in de Play Store te vermelden. In de Play Console-documentatie vindt u hulp bij het maken van uw app-vermelding , het beheren van uw APK-bestanden en andere instellingen, evenals instructies voor het testen en veilig vrijgeven van uw app .
Als u uw applicatie alleen wilt beperken tot Chromebooks, voegt u de vlag --chromeosonly toe bij het initialiseren van de applicatie in Bubblewrap:
bubblewrap init --manifest="https://example.com/manifest.json" --chromeosonly
Wanneer u uw applicatie handmatig bouwt, zonder Bubblewrap, voegt u een markering uses-feature toe aan uw Android-manifest:
<uses-feature android:name="org.chromium.arc" android:required="true"/>
Als uw vermelding wordt gedeeld met een Android-app, moet de pakketversie met alleen ChromeOS altijd hoger zijn dan de pakketversie van de Android-app. Je kunt de ChromeOS-bundelversie instellen op een veel hoger nummer dan de Android-versie, zodat je niet bij elke release beide versies hoeft te updaten.