Update

PWA를 게시했습니다. 일부 사용자는 브라우저에서 PWA를 사용하고 다른 사용자는 기기에 설치합니다. 앱을 업데이트할 때 권장사항을 적용하여 실수를 피하는 것이 중요합니다.

다음 항목을 업데이트할 수 있습니다.

  • 앱 데이터를 탭합니다.
  • 애셋이 이미 기기에 캐시되었습니다.
  • 서비스 워커 파일 또는 그 종속 항목
  • 매니페스트 메타데이터입니다.

각 요소에 대한 권장사항을 확인해 보겠습니다.

데이터 업데이트

IndexedDB에 저장된 데이터와 같은 데이터를 업데이트하려면 Fetch, WebRTC 또는 WebSockets API와 같은 도구를 사용합니다. 앱에서 오프라인 기능을 지원하는 경우 해당 기능을 지원하는 데이터도 업데이트해야 합니다.

호환되는 브라우저에서는 사용자가 PWA를 열었을 때뿐만 아니라 백그라운드에서도 데이터를 동기화할 수 있는 옵션이 있습니다. 이러한 옵션은 다음과 같습니다.

  • 백그라운드 동기화: 실패한 요청을 저장하고 서비스 워커의 동기화를 사용하여 다시 시도합니다.
  • 웹 주기적 백그라운드 동기화: 특정 시간에 백그라운드에서 데이터를 주기적으로 동기화하므로 사용자가 아직 앱을 열지 않았더라도 앱이 업데이트된 데이터를 제공할 수 있습니다.
  • 백그라운드 가져오기: PWA가 닫혀 있을 때도 대용량 파일을 다운로드합니다.
  • 웹 푸시: 서버에서 메시지를 보내 서비스 워커의 절전 모드를 해제하고 사용자에게 알립니다. 이를 흔히 '푸시 알림'이라고 합니다. 이 API를 사용하려면 사용자의 권한이 필요합니다.

이러한 모든 API는 서비스 워커 컨텍스트에서 실행됩니다. 현재 Chromium 기반 브라우저, Android, 데스크톱 운영체제에서만 사용할 수 있습니다. 이러한 API 중 하나를 사용하면 서비스 워커 스레드에서 코드를 실행할 수 있습니다. 예를 들어 서버에서 데이터를 다운로드하고 IndexedDB 데이터를 업데이트할 수 있습니다.

저작물 업데이트 중

애셋 업데이트에는 HTML, CSS, 자바스크립트, 이미지 등 앱의 인터페이스를 렌더링하는 데 사용하는 파일의 모든 변경사항이 포함됩니다. 예를 들어 앱 로직 변경, 인터페이스의 일부인 이미지 또는 CSS 스타일시트입니다.

패턴 업데이트

다음은 앱 업데이트를 처리하는 몇 가지 일반적인 패턴이지만 언제든지 필요에 따라 프로세스를 맞춤설정할 수 있습니다.

  • 전체 업데이트: 사소한 변경을 포함한 모든 변경사항이 전체 캐시 콘텐츠 교체를 트리거합니다. 이 패턴은 기기별 앱이 업데이트를 처리하는 방법을 모방하며, 더 많은 대역폭을 소비하고 더 많은 시간이 걸립니다.
  • 변경된 애셋 업데이트: 마지막 업데이트 이후에 변경된 애셋만 캐시에서 교체됩니다. Workbox와 같은 라이브러리를 사용하여 구현되는 경우가 많습니다. 캐시된 파일의 목록, 파일의 해시 표현 및 타임스탬프를 만드는 과정이 포함됩니다. 서비스 워커는 이 정보를 사용하여 이 목록을 캐시된 자산과 비교하고 업데이트할 자산을 결정합니다.
  • 개별 확장 소재 업데이트: 확장 소재가 변경되면 각 확장 소재가 개별적으로 업데이트됩니다. 게재 챕터에 설명된 비활성 재검증 전략은 애셋을 개별적으로 업데이트하는 예입니다.

업데이트 시기

또 다른 좋은 방법은 업데이트를 확인하고 적용할 적절한 시간을 찾는 것입니다. 다음과 같은 몇 가지 옵션이 있습니다.

  • 서비스 워커의 절전 모드가 해제될 때 이 순간을 수신할 이벤트는 없지만, 브라우저가 절전 모드에서 해제되면 브라우저가 서비스 워커의 전역 범위에 있는 모든 코드를 실행합니다.
  • PWA의 기본 창 컨텍스트에서 브라우저가 페이지를 로드한 후 앱 로드 속도가 느려지지 않도록 하기 위해
  • 백그라운드 이벤트가 트리거되는 경우(예: PWA가 푸시 알림을 수신하거나 백그라운드 동기화가 실행될 때) 그런 다음 캐시를 업데이트하면 사용자가 다음에 앱을 열 때 애셋의 새 버전을 사용할 수 있습니다.

실시간 소식

앱이 열려 있을 때 (실시간) 닫힐 때 업데이트를 적용할지 선택할 수도 있습니다. 앱 닫힘 방식을 사용하면 앱이 새 애셋을 다운로드했더라도 아무것도 변경되지 않으며 다음 로드 시 새 버전을 사용합니다.

실시간 업데이트는 캐시에서 애셋이 업데이트되는 즉시 PWA가 현재 로드의 애셋을 대체한다는 것을 의미합니다. 이는 이 과정에서 다루지 않는 복잡한 작업입니다. 이 업데이트를 구현하는 데 도움이 되는 도구로는 livereload-js 및 CSS 애셋 업데이트 CSSStyleSheet.replace() API가 있습니다.

서비스 워커 업데이트

서비스 워커나 종속 항목이 변경되면 브라우저가 업데이트 알고리즘을 트리거합니다. 브라우저는 캐시된 파일과 네트워크에서 유입되는 리소스를 바이트별로 비교하여 업데이트를 감지합니다.

그런 다음 브라우저는 서비스 워커의 새 버전을 설치하려 하고 서비스 워커 장에서 설명한 것처럼 새 서비스 워커는 대기 중 상태가 됩니다. 새로 설치하면 새 서비스 워커에 대해 install 이벤트가 실행됩니다. 해당 이벤트 핸들러에서 자산을 캐싱하는 경우 자산도 다시 캐시됩니다.

서비스 워커 변경 감지

새 서비스 워커가 준비되고 설치되었는지 감지하기 위해 서비스 워커 등록에서 updatefound 이벤트를 사용합니다. 이 이벤트는 새 서비스 워커가 설치를 시작하면 시작됩니다. statechange 이벤트로 상태가 installed로 변경될 때까지 기다려야 합니다. 다음을 참고하세요.

async function detectSWUpdate() {
  const registration = await navigator.serviceWorker.ready;

  registration.addEventListener("updatefound", event => {
    const newSW = registration.installing;
    newSW.addEventListener("statechange", event => {
      if (newSW.state == "installed") {
         // New service worker is installed, but waiting activation
      }
    });
  })
}

강제 재정의

새 서비스 워커가 설치되지만 기본적으로 활성화 대기 중입니다. 이 대기 시간 동안 새 서비스 워커가 새 버전과 호환되지 않을 수 있는 이전 클라이언트를 인계받지 못합니다.

권장되지는 않지만 새 서비스 워커가 대기 시간을 건너뛰고 활성화를 즉시 시작할 수 있습니다.

self.addEventListener("install", event => {
   // forces a service worker to activate immediately
   self.skipWaiting();
  });

self.addEventListener("activate", event => {
  // when this SW becomes activated, we claim all the opened clients
  // they can be standalone PWA windows or browser tabs
  event.waitUntil(clients.claim());
});

controllerchange 이벤트는 현재 페이지를 제어하는 서비스 워커가 변경될 때 실행됩니다. 예를 들어 새 작업자가 대기를 건너뛰고 새 활성 작업자가 된 경우입니다.

navigator.serviceWorker.addEventListener("controllerchange", event => {
   // The service worker controller has changed
 });

메타데이터 업데이트

주로 웹 앱 매니페스트에 설정되는 앱의 메타데이터를 업데이트할 수도 있습니다. 예를 들어 아이콘, 이름 또는 시작 URL을 업데이트하거나 앱 바로가기와 같은 새로운 기능을 추가할 수 있습니다. 하지만 이미 기기에 이전 아이콘이 있는 앱을 설치한 모든 사용자는 어떻게 될까요? 언제 어떻게 업데이트된 버전을 받을 수 있나요?

답은 플랫폼에 따라 다릅니다. 사용 가능한 옵션을 살펴보겠습니다.

iOS, iPadOS, Android 브라우저의 Safari

이러한 플랫폼에서 새 매니페스트 메타데이터를 가져올 수 있는 유일한 방법은 브라우저에서 앱을 다시 설치하는 것입니다.

WebAPK를 사용하는 Android용 Chrome

사용자가 WebAPK가 활성화된 Chrome을 사용하여 Android에 PWA를 설치하면 (대부분 Chrome PWA 설치) 알고리즘에 따라 업데이트가 감지되고 적용됩니다. 매니페스트 업데이트 도움말에서 자세한 내용을 확인하세요.

프로세스에 대한 몇 가지 추가 참고사항:

사용자가 PWA를 열지 않으면 WebAPK가 업데이트되지 않습니다. 서버가 매니페스트 파일로 응답하지 않으면 (404 오류 발생) 사용자가 PWA를 열더라도 Chrome에서 최소 30일 동안 업데이트를 확인하지 않습니다.

Android의 Chrome에서 about:webapks(으)로 이동하여 '업데이트 필요' 플래그의 상태를 확인하고 업데이트를 요청하세요. 도구 및 디버그 챕터에서 이 디버깅 도구에 관해 자세히 알아볼 수 있습니다.

WebAPK로 Android용 Samsung Internet

이 프로세스는 Chrome 버전과 유사합니다. 이 경우 PWA 매니페스트를 업데이트해야 하는 경우 다음 24시간 동안 업데이트된 WebAPK를 생성한 후 Wi-Fi에서 WebAPK가 업데이트됩니다.

데스크톱용 Chrome 및 Microsoft Edge

데스크톱 기기에서 PWA가 실행될 때 브라우저는 로컬 매니페스트의 변경사항을 마지막으로 확인한 시간을 결정합니다. 브라우저가 마지막으로 시작된 후 매니페스트가 검토되지 않았거나 지난 24시간 동안 확인되지 않은 경우 브라우저에서 매니페스트에 대한 네트워크 요청을 한 다음 이를 로컬 사본과 비교합니다.

선택한 속성이 업데이트되면 모든 창이 닫힌 후 업데이트가 트리거됩니다.

사용자에게 알림

일부 업데이트 전략의 경우 새로고침하거나 클라이언트에서 새로 탐색해야 합니다. 사용자에게 업데이트가 대기 중임을 알리고 사용자에게 가장 적합한 시점에 페이지를 업데이트할 기회를 제공하는 것이 좋습니다.

사용자에게 알리기 위한 옵션은 다음과 같습니다.

  • DOM 또는 canvas API를 사용하여 화면에 알림을 렌더링합니다.
  • Web Notifications API를 사용합니다. 이 API는 운영체제에서 알림을 생성하는 푸시 권한의 일부입니다. 서버에서 푸시 메시지 프로토콜을 사용하지 않더라도 웹 푸시 권한을 사용하려면 권한을 요청해야 합니다. 이는 PWA가 열려 있지 않은 경우에 사용할 수 있는 유일한 옵션입니다.
  • Badging API를 사용하여 PWA의 설치된 아이콘에서 업데이트를 사용할 수 있음을 보여줍니다.

DOM에 표시되는 업데이트 알림.

Badging API에 대해 자세히 알아보기

Badging API를 사용하면 PWA 아이콘을 배지 번호 또는 호환되는 브라우저에서 배지 점으로 표시할 수 있습니다. 배지 점은 설치된 아이콘 내에 있는 작은 표시로, 앱 내에서 무언가가 대기 중임을 나타냅니다.

8개의 알림이 있는 트위터와 깃발 유형 배지를 표시하는 다른 앱의 예

배지 번호를 설정하려면 navigator 객체에서 setAppBadge(count)를 호출해야 합니다. 사용자에게 알리는 업데이트가 있다는 것을 알고 있는 경우 창이나 서비스 워커의 컨텍스트에서 이 작업을 수행할 수 있습니다.

let unreadCount = 125;
navigator.setAppBadge(unreadCount);

배지를 지우려면 동일한 객체에서 clearAppBadge()를 호출합니다.

navigator.clearAppBadge();

자료