작년에 신뢰할 수 있는 웹 활동이 도입된 이후 Chrome팀은 출시 예정인 Google Play의 출시 예정 기능과 같은 새로운 기능을 추가하여 결제 통합 및 ChromeOS와 같은 더 많은 플랫폼에서 작동하도록 사용 설정 이 도움말에서는 신뢰할 수 있는 웹 활동에 대한 최신 업데이트 및 향후 업데이트를 요약합니다.
새로운 버블랩 및 신뢰할 수 있는 웹 활동 기능
버블랩을 사용하면 신뢰할 수 있는 웹 활동 내에서 PWA를 실행하는 앱을 생성할 수 있으며, 플랫폼별 도구에 관한 지식이 필요할 수 있습니다
간소화된 설정 흐름
이전에는 버블랩을 사용하려면 자바 개발 키트와 Android SDK를 수동으로 설정해야 했습니다. 둘 다 오류가 발생하기 쉽습니다. 이제 도구에서 자동으로 외부 종속 항목을 자동으로 제거합니다
기존 종속 항목 설치를 사용할 수도 있습니다. 원하는 경우
새로운 doctor 명령어는 문제를 찾는 데 도움이 되고 구성 수정을 추천하여
이제 updateConfig 명령어를 사용하여 명령줄에서 업데이트합니다.
향상된 마법사
init로 프로젝트를 만들 때 Bubblewrap은 Android 앱을 생성하기 위한 정보를 필요로 합니다. 이
도구는 웹 앱 매니페스트에서 값을 추출하고 가능한 경우 기본값을 제공합니다.
새 프로젝트를 만들 때 이러한 값을 변경할 수 있지만 이전에는 각 필드의 의미는 없었습니다. 명확합니다. 초기화 대화상자는 각각에 대해 더 나은 설명과 유효성 검사를 포함하여 다시 빌드되었습니다. 입력합니다.
디스플레이: 전체화면 및 방향 지원
어떤 경우에는 애플리케이션이 화면을 최대한 많이 사용하도록 하고 싶을 때가 있을 것입니다.
PWA를 빌드하는 경우 웹 앱 매니페스트의 display 필드를
fullscreen입니다.
버블랩이 웹 앱 매니페스트에서 전체 화면 옵션을 감지하면 Android 몰입형 모드로도 실행할 수 있습니다.
웹 앱 매니페스트의 orientation 필드는 애플리케이션을 다음에서 시작해야 하는지 정의합니다.
세로 모드, 가로 모드 또는 기기가 현재 사용 중인 방향으로 설정할 수 있습니다. 지금 버블랩 사용
는 웹 앱 매니페스트 필드를 읽고 Android 앱을 만들 때 이를 기본값으로 사용합니다.
두 구성을 모두 bubblewrap init 흐름의 일부로 맞춤설정할 수 있습니다.
AppBundle 출력
App Bundle은 최종 APK 생성과 Play에 로그인합니다. 실제로 이렇게 하면 앱을 다운로드할 수 있습니다.
Bubblewrap은 이제 애플리케이션을 App Bundle로 패키징합니다.
app-release-bundle.aab Play 스토어에 앱을 게시할 때 이 형식을 선호해야 합니다.
2021년 하반기부터 매장에서 요구하기 때문입니다.
위치정보 위임
사용자는 기기에 설치된 애플리케이션이 있습니다. 신뢰할 수 있는 웹 활동 내에서 사용하는 경우 이제 GeoLocation 권한을 운영 체제에 위임되며, 활성화되면 사용자에게 빌드된 앱과 동일한 대화상자가 표시됩니다. 하고 같은 위치에서 권한을 관리하는 컨트롤을 찾으세요.
이 기능은 Bubblewrap을 통해 추가할 수 있으며, Android 프로젝트에서 위치정보 권한을 사용하는 경우, 웹 앱에서 위치정보 권한을 사용 중일 때만 사용 설정해야 합니다.
최적화된 바이너리
저장용량이 제한된 기기는 전 세계 특정 지역에서 흔히 볼 수 있으며 해당 기기의 소유자는 많습니다. 더 작은 애플리케이션을 선호하는 경우가 많습니다 신뢰할 수 있는 웹 활동을 사용하는 애플리케이션은 이러한 사용자의 불안을 일부 제거하는 바이너리를 제공합니다.
필요한 Android 라이브러리 목록을 줄여 버블랩을 최적화했습니다. 80만 개 더 작은 바이너리를 생성했습니다 실제로는 평균 크기의 절반에 못 미치고 생성할 수 있습니다 더 작은 바이너리를 활용하려면 앱을 설치해야 합니다.
기존 앱을 업데이트하는 방법
Bubblewrap에서 생성된 애플리케이션은 웹 애플리케이션과 경량의 Android로 구성됩니다. 래퍼를 정의합니다. 신뢰할 수 있는 웹 활동 내에서 PWA가 열렸더라도 업데이트 주기가 같으면 네이티브 래퍼를 업데이트할 수 있고 업데이트해야 합니다.
앱을 업데이트하여 최신 버전의 래퍼가 적용된 최신 버전
버그 수정 및 기능이 추가되었습니다. 최신 버전의 Bubblewrap이 설치된 상태에서 update 명령어는 다음을 실행합니다.
최신 버전의 래퍼를 기존 프로젝트에 적용합니다.
npm update -g @bubblewrap/cli
bubblewrap update
bubblewrap build
이러한 애플리케이션을 업데이트하는 또 다른 이유는 웹 매니페스트의 변경 사항이
애플리케이션에 적용됩니다 이를 위해 새로운 merge 명령어를 사용합니다.
bubblewrap merge
bubblewrap update
bubblewrap build
품질 기준 업데이트
Chrome 86에서는 신뢰할 수 있는 웹 활동 품질 기준이 변경되었습니다. 자세한 내용은 신뢰할 수 있는 웹 활동을 사용하는 PWA 품질 기준 변경사항 전문을 확인하세요.
간단히 요약하자면 애플리케이션이 다음 시나리오를 처리할 수 있도록 해야 방지:
- 애플리케이션 실행 시 디지털 애셋 링크 인증 실패
- 오프라인 네트워크 리소스 요청에 대해 HTTP 200 반환 실패
- 애플리케이션에서 HTTP 404 또는 5xx 오류 반환
애플리케이션이 디지털 애셋 링크 유효성 검사를 통과하는지 확인하는 것 외에도, 시나리오는 서비스 워커가 처리할 수 있습니다.
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는 서비스 워커를 사용할 때 권장사항을 적용하고 상용구를 삭제합니다. 또는 Workbox 플러그인을 사용하여 이러한 시나리오를 처리하는 방법도 있습니다.
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 결제
앱이 Play 스토어에서 디지털 상품과 구독을 판매할 수 있도록 허용하는 것 외에도 Google Play 결제는 카탈로그, 가격, 정기 결제를 관리하는 데 유용한 도구를 제공합니다. 보고서, 그리고 이미 사용자에게 익숙한 Play 스토어에서 제공하는 결제 절차도 포함됩니다. 그것은 은 Play 스토어에 게시되어 디지털 상품을 판매하는 애플리케이션의 요구사항이기도 합니다.
Chrome 88은 Android에서 오리진 트라이얼과 함께 출시됩니다. 신뢰할 수 있는 웹 활동, Payment Request API 및 Digital Goods API는 Google Play 결제를 통해 구매 흐름을 구현합니다. 이 오리진 트라이얼도 - ChromeOS 버전 89용
중요: Google Play Billing API에는 자체 용어가 있으며 백엔드 구성요소를 사용합니다 이 섹션에서는 Digital Goods API 및 신뢰할 수 있는 웹 활동. 자세한 내용은 Google Play 결제 문서를 살펴보고 결제 개념을 이해한 후에 결제 계정에 애플리케이션을 만들 수 있습니다
기본 흐름
Play 스토어를 통해 디지털 상품을 제공하려면 Play 스토어에서 카탈로그를 설정해야 합니다. 스토어를 열고 PWA에서 Play 스토어를 결제 수단으로 연결할 수 있습니다.
카탈로그를 구성할 준비가 되면 먼저 왼쪽에서 제품 섹션을 찾습니다. 핸드 사이드 메뉴에서 다음을 수행합니다.
여기에서 기존 인앱 상품 및 구독을 볼 수 있는 옵션을 찾을 수 있으며 '만들기' 버튼을 찾아 새로 추가할 수 있습니다
새 인앱 상품을 만들려면 상품 ID, 이름, 설명, 가격이 필요합니다. 그것은 의미 있고 기억하기 쉬운 제품 ID를 만드는 데 중요하므로 나중에 필요하고 ID는 한 번 생성된 후에는 변경할 수 없습니다.
정기 결제를 만들 때 결제 기간도 지정해야 합니다. 다음과 같은 옵션이 있습니다. 구독 혜택을 나열하고 무료 체험판, 신규 할인 가격, 유예 기간, 정기 결제 재신청 옵션 등이 있습니다
각 제품을 만든 후 앱에서 제품을 사용할 수 있도록 활성화하세요.
원하는 경우 Play Developers API를 통해 제품을 추가할 수 있습니다.
카탈로그가 구성되었으면 다음 단계는 PWA에서 결제 흐름을 구성하는 것입니다. 나 Digital Goods API와 Payment Request API를 조합하여 사용합니다. 이거죠.
Digital Goods API를 사용하여 제품 가격 가져오기
Google Play 결제를 사용할 때 사용자에게 표시되는 가격이 일치하는지 확인해야 합니다. 가격을 확인합니다. 수동으로 이러한 가격을 동기화하는 것은 불가능하므로 Digital Goods API는 웹 애플리케이션이 기본 결제를 쿼리하는 방법을 제공합니다. 제공업체에 문의하세요.
// 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;
}
getDigitalGoodsService()가
window 객체에서 사용할 수 있습니다.
그런 다음 Google Play 결제 식별자를 매개변수로 사용하여 window.getDigitalGoodsService()를 호출합니다.
이렇게 하면 Google Play 결제를 위한 서비스 인스턴스가 반환되고 다른 공급업체에서 지원을 구현할 수 있습니다.
디지털 상품 API에 사용할 수 있으며 식별자는 서로 다릅니다.
마지막으로, SKU를 전달하는 Google Play 결제 객체 참조에서 getDetails()를 호출합니다.
항목을 매개변수로 전달합니다. 이 메서드는 가격과
사용자에게 표시될 수 있는 항목의 통화입니다.
구매 절차를 시작합니다.
Payment Request API는 웹에서 구매 흐름을 활성화하며 Google Play 결제 통합. Payment를 처음 사용하는 경우 Payment Request API 작동 방식에서 자세히 알아보세요. API 요청
Google Play 결제와 함께 API를 사용하려면 결제 수단을 추가해야 합니다.
https://play.google.com/billing라는 지원되는 측정항목이 있고 데이터의 일부로 SKU를 추가합니다.
설정합니다.
const supportedInstruments = [{
supportedMethods: "https://play.google.com/billing",
data: {
sku: sku
}
}];
그런 다음 평소와 같이 PaymentRequest 객체를 빌드하고 평소와 같이 API를 사용합니다.
const request = new PaymentRequest(supportedInstruments, details);
구매 확인
거래가 완료되면 Digital Goods API를 사용하여
있습니다. PaymentRequest의 응답 객체에는
트랜잭션을 확인합니다.
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');
Digital Goods API와 Payment Request API는 사용자의 신원을 알 수 없습니다. 백엔드에서 구매를 사용자와 연결하고 액세스할 수 없습니다. 구매를 사용자와 연결할 때 구매가 취소 또는 환불되었는지 또는 취소 또는 환불되었는지 확인하는 데 필요할 수 있으므로 구독이 여전히 활성 상태인 경우 Real Time Developer Notifications API 및 Google Play Developer API는 백엔드에서 이러한 케이스를 처리하기 위한 엔드포인트를 제공합니다.
기존 사용 권한 확인
사용자가 프로모션 코드를 사용했거나 제품의 기존 구독을 보유하고 있을 수 있습니다. 포함
사용자에게 적절한 사용 권한이 있는지 확인하려면
listPurchases() 명령어를 사용합니다. 이렇게 하면 해당 기간 동안 구매한 모든 항목이
파악할 수 있습니다. 이곳에서는 미확인 신고에 대한
사실을 인정할 수도 있습니다
사용자가 자격을 올바르게 사용할 수 있도록 해야 합니다.
const purchases = await itemService.listPurchases();
for (p of purchases) {
if (!p.acknowledged) {
await itemService.acknowledge(p.purchaseToken, 'onetime');
}
}
ChromeOS Play 스토어에 업로드
신뢰할 수 있는 웹 활동도 ChromeOS Play 스토어의 Chrome 85부터 사용할 수 있습니다. 과정 Android와 ChromeOS는 동일합니다.
App Bundle을 만들면 Play Console에서 필수 단계를 안내합니다. Play 스토어에 앱을 등록하는 단계 Play Console 문서에서 앱 등록정보 만들기, APK 파일 및 기타 설정 관리, 안내 앱을 테스트하고 안전하게 출시할 수 있습니다.
애플리케이션을 Chromebook으로만 제한하려면 초기화할 때 --chromeosonly 플래그를 추가합니다.
다음과 같이 Bubblewrap에서 애플리케이션을 실행합니다.
bubblewrap init --manifest="https://example.com/manifest.json" --chromeosonly
Bubblewrap 없이 애플리케이션을 수동으로 빌드하는 경우 uses-feature 플래그를
Android 매니페스트:
<uses-feature android:name="org.chromium.arc" android:required="true"/>
등록정보를 Android 앱과 공유하는 경우 ChromeOS 전용 패키지 버전은 항상 Android 앱 패키지 버전보다 높을 수 있습니다. ChromeOS 번들 버전을 Android 버전보다 훨씬 높기 때문에 각 버전마다 두 버전을 모두 업데이트하지 않아도 있습니다.