프로그레시브 웹 앱의 빌딩 블록

웹 앱은 네이티브 앱과 웹사이트의 모든 기능을 한 번에 대체할 수 있습니다. 요즘 점점 더 부각되고 있지만 아직 익숙하지 않거나 채택하는 사람들이 충분하지 않습니다.

이 기사에서는 프로그레시브 웹 앱을 만드는 방법에 대한 몇 가지 해야 할 일과 하지 말아야 할 일과 추가 연구를 위한 리소스를 찾을 수 있습니다. 또한 웹 앱을 둘러싼 다양한 구성 요소 및 지원 문제로 이동합니다. 모든 브라우저가 친숙한 것은 아니지만 이 기술에 대해 더 자세히 알아야 할 몇 가지 강력한 이유가 있습니다.

무엇이 웹 앱을 진보적으로 만드는가?

프로그레시브 웹 앱은 웹에서 앱과 같은 경험을 제공하기 위해 함께 사용되는 특정 기술에 대한 포괄적인 용어입니다. 편의상 이제부터는 그냥 웹앱이라고 부르겠습니다.

이상적인 웹 앱은 웹과 기본 앱의 장점을 모두 갖춘 웹 페이지입니다. 빠르고 빠르게 상호 작용하고, 장치의 뷰포트에 맞고, 오프라인에서 사용할 수 있어야 하며, 홈 화면에 아이콘을 표시할 수 있어야 합니다.

동시에 앱에 깊숙이 연결하고 URL을 사용하여 콘텐츠 공유를 가능하게 하는 기능과 같이 웹을 훌륭하게 만드는 요소를 희생해서는 안 됩니다. 웹과 마찬가지로 모바일에만 초점을 맞추지 않고 여러 플랫폼에서 잘 작동 해야 합니다. 응답하지 않는 m.example.com 웹사이트의 또 다른 시대가 도래하지 않도록 하려면 데스크톱 컴퓨터에서 다른 폼 팩터와 마찬가지로 제대로 작동해야 합니다.

프로그레시브 웹 앱은 새로운 것이 아닙니다. 모바일 브라우저는 2011년(Chrome Android의 경우 2013년)부터 휴대전화의 홈 화면에 웹사이트를 북마크할 수 있는 기능을 가지고 있으며 head 의 메타 태그가 설치된 웹 페이지의 모양을 결정합니다. Financial Times는 2012년부터 모바일 장치의 디지털 콘텐츠 전달을 위해 웹 앱을 사용하고 있습니다.

웹 앱으로 전환함으로써 Financial Times는 동일한 앱을 사용하여 단일 배포 채널의 여러 플랫폼에 배송할 수 있었습니다. 내가 Financial Times에서 일할 때 단일 빌드로 다음을 지원할 수 있었습니다.

• iOS,
• 안드로이드(4.4+) 크롬,
• 구형 Android(래퍼를 통해),
• 윈도우 8,
• 블랙베리,
• 파이어폭스 OS.

이는 진정으로 "한 번 구축하고 어디서나 배포"를 달성합니다.

“하지만 앱스토어에는 없어요”

웹사이트로 기본 앱을 보완하는 것이 여전히 대부분의 주요 회사에서 표준 관행인 데에는 몇 가지 타당한 이유가 있습니다. 그 중에는 브라우저 지원에 대한 우려와 대부분의 사용자가 기본 앱 사용에 익숙해 있다는 사실이 있습니다. 이러한 문제는 나중에 더 자세히 다루겠습니다. 이러한 우려 중 적어도 하나는 앱 스토어에 없는 경우 앱이 노출되는 방식입니다.

앱 스토어에 있는 앱의 상위 0.1%에 속하지 않으면 앱 스토어에 있는 것으로부터 큰 이점을 얻지 못하는 것으로 나타났기 때문에 앱 스토어에 있는 것이 큰 이점이 없다고 주장하고 싶습니다.

사용자는 먼저 웹사이트를 검색하여 앱을 찾는 경향이 있습니다. 웹사이트가 웹 앱이라면 이미 목적지에 도달한 것입니다.

웹 앱의 장점 중 하나는 웹사이트 방문과 앱 참여 사이에 사용자를 다시 참여시키는 데 필요한 클릭 수를 줄여 참여도를 높일 수 있다는 것입니다.

사용자가 웹 앱을 홈 화면에 추가하여 "설치"하도록 하면 웹사이트에 계속 참여할 수 있습니다. 웹 브라우저를 닫으면 전화가 웹 앱이 설치된 위치를 표시하여 다시 인식하게 합니다.

배경 및 현재 기후

최신 웹 앱은 서비스 작업자라는 새로운 기술을 기반으로 합니다. 서비스 작업자는 사용자 탭과 더 넓은 인터넷 사이에 있는 프로그래밍 가능한 프록시입니다. 네트워크 요청을 가로채서 다시 작성하거나 조작하여 매우 세분화된 캐싱 및 오프라인 지원을 허용합니다.

웹사이트를 홈 화면에 북마크할 수 있는 웹 앱이 2011년에 탄생한 이후로, 프로그레시브 웹 앱을 만들기 위한 더 많은 토대를 마련하기 위해 많은 개발이 이루어졌습니다.

Chrome 38에는 웹 앱의 구성을 설명하는 JSON 파일인 웹 앱 매니페스트가 도입되었습니다. 이를 통해 head 에서 구성을 제거할 수 있었습니다.

Chrome 40(2014년 12월)에서 서비스 작업자는 Firefox와 Chrome 전체에 배포되기 시작했습니다. Apple은 문서 작성 당시 Safari에서 이 기능을 구현하지 않기로 결정했지만 "고려 중"입니다. 서비스 워커의 기능은 앱을 오프라인으로 전환하는 프로세스를 단순화하는 것입니다. 또한 푸시 알림 및 백그라운드 동기화와 같은 향후 앱과 유사한 기능을 위한 기반을 마련합니다.

새로운 서비스 워커와 웹 앱 매니페스트를 기반으로 구축된 앱은 프로그레시브 웹 앱으로 알려지게 되었습니다.

프로그레시브 웹 앱은 사양과 다릅니다. 사실, 그것은 새로운 기술이 브라우저에 내장되어 있다는 점을 감안할 때 서비스 워커 시대에 웹 앱이 무엇이어야 하는지에 대한 정의로 시작되었습니다. 특히 Chrome은 이 정의를 사용하여 여러 조건이 충족될 때 브라우저에서 설치 프롬프트를 트리거합니다. 조건은 웹 앱이 다음과 같습니다.

• 서비스 작업자가 있습니다(HTTPS 필요).
• 웹 앱 매니페스트 파일이 있습니다(최소한 구성 및 display: "standalone" ).
• 두 번의 별개의 방문이 있었습니다.

이 경우 "프로그레시브"는 브라우저가 지원하는 기능이 많을수록 앱과 같은 경험이 될 수 있음을 의미합니다.

웹 앱을 설치하라는 메시지는 현재 Opera, Chrome 및 Samsung 브라우저에서 다양한 조건에서 표시됩니다.

Apple은 iOS용 프로그레시브 웹 앱에 관심을 표명했지만 작성 당시에는 웹 앱 구성을 위한 메타 태그와 오프라인 사용을 위한 애플리케이션 캐시(AppCache)에 여전히 의존하고 있습니다.

웹 사이트가 웹 앱이 되는 시점은?

우리는 웹사이트가 어떻게 생겼는지, 앱이 어떻게 생겼는지 알고 있지만, 웹사이트가 웹 앱이 되는 시점은 어디일까요? 웹사이트가 아닌 웹 앱으로 만드는 요소에 대한 명확한 측정 기준은 없습니다.

여기에서는 웹 앱의 특성에 대해 좀 더 자세히 살펴보겠습니다.

프로그레시브 웹 앱은 특정 앱과 유사한 속성을 보여야 합니다…

• 반응형
  화면을 완벽하게 채우는 이러한 웹 사이트는 주로 휴대폰과 태블릿을 대상으로 하며 과도한 화면 크기에 응답해야 합니다. 또한 데스크톱 웹사이트로도 작동해야 합니다. 반응형 디자인은 수년 동안 웹사이트 구축의 주요 부분이었습니다. Smashing Magazine에는 이에 대한 훌륭한 기사가 있습니다.
• 오프라인 우선
  앱은 오프라인으로 시작할 수 있어야 하며 여전히 유용한 정보를 표시해야 합니다.
• 터치 가능
  인터페이스는 제스처 상호 작용과 함께 터치용으로 설계되어야 합니다. 사용자 상호 작용은 터치와 응답 사이에 지연 없이 즉각적으로 반응해야 합니다.
• 앱 메타 데이터
  앱은 설치 시 브라우저에 표시되는 메타 데이터를 제공해야 홈 화면에 멋진 고해상도 아이콘이 표시되고 일부 플랫폼에서는 시작 화면이 표시됩니다.
• 푸시 알림
  앱은 앱이 실행되고 있지 않을 때 알림을 받을 수 있습니다(해당되는 경우).

... 그러나 특정 웹과 같은 속성을 유지해야 합니다.

• 프로그레시브
  앱의 설치 기능은 점진적으로 향상되었습니다. 특히 설치 또는 서비스 작업자를 아직 지원하지 않는 플랫폼에서 앱이 여전히 일반 웹사이트로 작동하는 것이 중요합니다.
• 개방형 웹의 HTTPS
  앱은 브라우저나 앱 스토어에 잠겨 있어서는 안 됩니다. 딥링크가 가능해야 하며 현재 URL을 공유하는 방법을 제공해야 합니다.

웹사이트를 오프라인으로 전환

웹 사이트를 오프라인으로 전환하면 몇 가지 주요 이점이 있습니다.

첫째, 사용자가 불안정한 네트워크 연결에 있는 경우에도 여전히 작동합니다.

또한 앱이 네트워크에 의존하지 않는 경우 앱을 여는 시간부터 앱을 사용하는 시간까지 크게 단축됩니다. 이것은 사용자에게 훌륭한 경험을 제공합니다. 신중하게 최적화된 웹 앱은 브라우저를 최근에 사용한 적이 있는 경우 기본 앱보다 빠르게 시작할 수 있습니다.

웹사이트를 오프라인으로 작동시키는 방법에는 두 가지가 있습니다.

• 오래되고 파괴된 방법
  웹 사이트를 오프라인으로 시작하기 위한 지원은 AppCache의 형태로 수년 동안 있었습니다. 그러나 AppCache에는 몇 가지 심각한 결함이 있으며 사양에서 더 이상 사용되지 않습니다. 작업하기 어렵고 잘못 구성하면 웹 사이트가 영구적으로 손상될 수 있습니다. 그럼에도 불구하고 적어도 Apple이 서비스 작업자를 지원하기 위해 움직일 때까지는 iOS에서 오프라인으로 수행할 수 있는 유일한 방법입니다.
• 새로운 매력
  또한 현재 Chrome, Firefox 및 Opera에서 지원되고 곧 Edge에 제공될 서비스 작업자도 효과적입니다. Apple의 WebKit 팀은 "고려 중"이라고 표시했습니다.

서비스 워커는 별도의 스레드에서 실행된다는 점에서 다른 웹 워커와 같지만 특정 탭에 연결되지 않습니다. 생성 시 URL 범위가 할당되며 이 범위의 모든 요청을 가로채서 다시 작성할 수 있습니다. 서비스 워커가 https://example.com/my-site/sw.js 에 있는 경우 /my-site/ 이하에 대한 모든 요청을 가로챌 수 있지만 루트 https://example.com/ 에 대한 요청을 가로챌 수는 없습니다. https://example.com/ .

탭에 연결되어 있지 않기 때문에 푸시 알림이나 백그라운드 동기화를 처리하기 위해 백그라운드에서 활성화될 수 있습니다. 무엇보다도 새로운 서비스 작업자 스크립트가 감지되면 자동으로 업데이트되기 때문에 웹사이트를 영구적으로 중단하는 것은 불가능합니다.

좋은 지침은 새 웹사이트를 처음부터 구축하는 경우 서비스 워커와 함께 시작하는 것입니다. 그러나 웹 사이트가 이미 AppCache를 사용하여 오프라인으로 작동하는 경우 sw-appcache-behavior 도구를 사용하여 여기에서 서비스 워커를 생성할 수 있습니다. 일부 브라우저는 서비스 워커만 허용하고 일부는 허용 앱캐시.

AppCache는 더 이상 사용되지 않으므로 이 기사에서 더 이상 논의하지 않겠습니다.

서비스 워커 설정

(또한 자세한 지침은 "서비스 워커 설정"을 참조하십시오.)

서비스 워커는 공유 웹 워커의 특수한 유형이기 때문에 메인 페이지와 별도의 스레드에서 실행됩니다. 즉, 서비스 워커와 같은 경로에 있는 모든 웹 페이지에서 공유됩니다. 예를 들어 /my-page/sw.js 에 있는 서비스 작업자는 /my-page/index.html 및 my-page/images/header.jpg 에 영향을 줄 수 있지만 /index.html 에는 영향을 줄 수 없습니다.

서비스 워커는 data:// URL에 대한 요청을 포함하여 페이지에서 이루어진 모든 네트워크 요청을 가로채서 다시 작성하거나 스푸핑할 수 있습니다!

이 기능을 사용하면 데이터 연결이 없을 때 페이지가 작동하도록 캐시된 응답을 제공할 수 있습니다. 그러나 가능한 많은 사용 사례를 허용할 만큼 충분히 유연합니다.

매우 강력하기 때문에 보안 컨텍스트(예: HTTPS)에서만 허용됩니다. 이렇게 하면 제3자가 감염되거나 악의적인 Wi-Fi 액세스 포인트에서 주입된 서비스 작업자를 사용하여 웹사이트를 영구적으로 무시하는 것을 방지할 수 있습니다.

오늘날 HTTPS를 설정하는 것은 벅차고 비용이 많이 들지만 실제로는 그 어느 때보다 쉽고 저렴합니다. Let's Encrypt는 서버를 자동으로 구성할 수 있는 무료 SSL 인증서와 스크립트를 제공합니다. GitHub에서 호스팅하는 경우 GitHub 페이지는 HTTPS를 통해 자동으로 제공됩니다. Tumblr 페이지는 HTTPS에서도 실행되도록 구성할 수 있습니다. CloudFlare는 HTTPS로 업그레이드하기 위해 요청을 프록시할 수 있습니다.

오프라인은 일반적으로 웹 사이트의 다른 부분에 대해 특정 캐싱 방법을 선택하여 더 빠르게 제공하거나 인터넷에 연결되어 있지 않을 때 사용합니다. 아래에서 다양한 캐싱 방법에 대해 설명합니다.

Service Worker Toolbox를 사용하여 복잡한 캐싱 논리를 추상화합니다. 이 라이브러리는 깨끗한 방식으로 구성할 수 있는 4개의 미리 구성된 경로를 제공하여 라우팅을 처리하도록 설정할 수 있습니다. 서비스 워커로 가져올 수 있습니다.

사용 사례 1: 사전 캐싱

사전 캐싱은 웹사이트가 필요하다고 판단하기 전에 요청을 풀다운합니다. 이렇게 하면 웹사이트의 로고 /images/logo.png 다운로드를 시작하기 전에 웹사이트에서 /site.css 를 구문 분석할 필요가 없기 때문에 첫 번째 페인트 시간을 크게 줄일 수 있습니다.

 toolbox.precache(['/index.html', '/site.css', '/images/logo.png']);

사용 사례 2: 오프라인

가장 간단한 경우 사용자가 오프라인 상태일 때 웹사이트를 다시 방문할 수 있도록 허용한다는 것은 기기가 오프라인일 때 캐시로 폴백하는 것을 의미합니다. 불안정한 네트워크, 잘못 구성된 라우터 또는 종속 포털로 인해 사용자가 무기한 대기 상태가 될 수 있으므로 여기에서 시간 초과를 설정하는 것이 중요합니다.

 toolbox.router.default = toolbox.networkFirst; toolbox.options.networkTimeoutSeconds = 5;

실제로 대부분의 자산은 시간이 지나도 변하지 않기 때문에 실제로 조금 더 똑똑해질 수 있습니다. 우리는 아마도 캐시에서든 네트워크에서든 가능한 한 빨리 콘텐츠를 얻고 싶을 것입니다. 다음 줄은 이미지 경로에 대한 모든 요청이 캐시에서 사용 가능한 경우 캐시에서 가져와야 한다고 Service Worker Toolbox에 알려줍니다.

 toolbox.router.all('/images/*', toolbox.fastest);

이 경우 사용자가 인증할 때 캐시된 응답을 반환하지 않는 것이 중요합니다. /auth/ 에 대한 요청은 네트워크 전용이어야 함을 명시해야 합니다.

 toolbox.router.post('/auth/*', toolbox.networkOnly);

다음은 오프라인에 대한 몇 가지 모범 사례입니다.

• 초기 정적 자산은 사전 캐시되어야 합니다. 그러면 서비스 워커가 설치될 때 다운로드되고 캐시됩니다. 이는 결국 필요할 때 서버에서 로드할 필요가 없음을 의미합니다.
• 기본적으로 요청은 이상적으로는 네트워크에서 새로 소싱되지만 오프라인에서 사용할 수 있도록 캐시로 대체되어야 합니다.
• 상대적으로 짧은 네트워크 시간 초과는 요청이 네트워크 연결에서 캐시된 데이터를 반환할 수 있음을 의미합니다. 즉, 데이터 연결은 있지만 응답이 반환되지 않습니다.
• 이미지와 같이 자주 업데이트되지 않는 자산은 먼저 캐시에서 전달되어야 합니다. 그러면 브라우저도 해당 자산을 업데이트하려고 합니다. toolbox.cacheOnly 를 사용하면 사용자 데이터도 저장할 수 있습니다.

참고: 브라우저 캐시와 캐시 API는 다른 동물입니다. 네트워크 우선 또는 네트워크 전용의 경우 캐시 API가 우회되었습니다. 요청의 캐싱 헤더가 여전히 유효하다고 말하므로 요청이 여전히 브라우저의 캐시에 도달할 수 있습니다. 이로 인해 사용자가 캐시된 데이터와 최신 데이터를 혼합하여 수신하는 문제가 발생할 수 있습니다. Jake Archibald는 이 문제를 피하기 위한 몇 가지 좋은 제안을 했습니다.

서비스 워커 디버깅

Chrome 또는 Opera를 사용 중인 경우 chrome://serviceworker-internals 로 이동합니다. 이렇게 하면 서비스 작업자 스크립트를 검사하고 일시 중지하고 제거할 수 있습니다.

최신 버전의 Chrome 및 Opera에서는 인스펙터의 "애플리케이션" 탭을 통해 자세한 보기 및 디버깅 도구를 얻을 수 있습니다.

상호 작용 및 애니메이션 성능

사람들은 웹에 네이티브 앱처럼 매끄럽게 움직이는 인터페이스가 없다고 기대하게 되었습니다. 그러나 웹 앱에는 동일한 표준이 허용되지 않습니다. 웹 앱은 사용자가 우리가 품질이 떨어지는 2급 경험을 제공하고 있다고 느끼지 않도록 원활하게 애니메이션되어야 합니다. 빠르게 느껴지 도록 하는 세 가지 목표가 있습니다.

• 사용자가 어떤 작업을 수행할 때 앱도 100밀리초 이내에 작업을 수행해야 합니다. 그렇지 않으면 사용자가 지연을 알 수 있습니다. 이것은 탭, 클릭, 드래그 및 스크롤에 적용됩니다.
• 각 프레임은 일관된 초당 60프레임(프레임당 16밀리초)으로 렌더링되어야 합니다. 몇 개의 느린 프레임도 분명합니다.
• 당신의 빛나는 개발 머신뿐만 아니라 열악한 네트워크에서 실행되는 3년 된 저가형 전화기에서는 빨라야 합니다.
• 빨리 시작해야 합니다. 오랫동안 우리는 웹사이트를 1~2초 이내에 표시하고 사용할 수 있도록 하여 사용자 참여를 유지하는 데 집중해 왔습니다. 웹 앱과 관련하여 시작 시간은 그 어느 때보다 중요합니다. 앱의 모든 콘텐츠가 캐시되고 브라우저가 여전히 기기의 메모리에 있는 경우 웹 앱은 기본 앱보다 빠르게 시작할 수 있습니다. 네이티브 앱과 웹사이트 개발자가 똑같이 범하는 한 가지 실수는 제품이 작동하기 위해 네트워크 콘텐츠가 필요하다는 것입니다.
• 웹 앱을 다운로드하고 업데이트하려면 작아야 합니다. 앱 스토어에서 10MB는 별로 느껴지지 않지만 매번 다운로드되는 10MB의 캐시되지 않은 MB는 많은 모바일 사용자가 관리하기가 매우 어렵습니다.

박쥐에서 가장 중요한 항목은 문서의 head 에 다음과 같습니다.

 <meta name="viewport" content="width=device-width">

이 줄은 Chromium 기반 또는 Firefox인 전화 브라우저에서 300밀리초 탭 지연이 없도록 하지만 여전히 사용자가 핀치로 확대할 수 있도록 합니다(접근성 측면에서 좋음).

iOS 8이 나온 이후로 클릭은 기본적으로 빠르지만 탭이 빠르면 특정 휴리스틱에 따라 느리게 보일 수 있습니다. 이것이 문제라면 FastClick을 사용하여 지연을 제거하는 것이 좋습니다.

애니메이션 성능 문제도 있습니다. 당신은 아마도 안팎으로 움직이는 예쁜 요소, 사용자가 끌 수 있는 요소 및 기타 멋진 상호 작용을 원할 것입니다.

웹 성능은 매우 자세하게 논의될 수 있고 내 마음에 가까운 주제이지만 여기에서 자세히 설명하지 않겠습니다. 내 상호 작용과 애니메이션이 선명하고 매끄럽게 하기 위해 내가 하는 일에 대해 설명하겠습니다.

오래된 스마트폰을 찾아 친구나 가족에게 물어보세요. 나는 보통 파트너의 Nexus 4를 빌립니다.

전화를 컴퓨터에 연결하고 chrome://inspect/#devices 로 이동합니다. 그러면 전화기에서 실행되는 웹 페이지를 검사하는 데 사용할 수 있는 검사 창이 열립니다. 프로파일링을 사용하고 타임라인을 확인하여 성능 저하의 원인을 찾은 다음 실제 기준 장치를 기반으로 최적화할 수 있습니다.

특정 CSS 속성에 애니메이션을 적용하는 것은 버벅거림으로 알려진 애니메이션이 흔들리는 가장 큰 원인 중 하나입니다. CSS Triggers는 브라우저가 전체 페이지를 다시 그리거나 다시 레이아웃하지 않고 안전하게 애니메이션할 수 있는 속성을 결정하기 위한 훌륭한 리소스입니다.

성능 좋은 애니메이션을 작성하는 것이 어려운 작업이라면 많은 라이브러리가 이 작업을 처리할 것입니다. 내가 가장 좋아하는 것은 항목 끌기와 같은 터치 상호 작용을 매우 잘 처리할 수 있고 매우 멋진 애니메이션 및 트위닝을 수행할 수 있는 GreenSock입니다.

푸시 알림

푸시 알림은 사용자와 다시 소통할 수 있는 좋은 방법입니다. 사용자에게 메시지를 표시하여 앱을 가장 먼저 떠올리게 합니다. 완료되지 않은 거래를 마무리하거나 관련 새 콘텐츠에 대한 알림을 받을 수 있습니다.

푸시 알림이 그 순간에 발생하는 이벤트에 대해 사용자와 관련이 있는지 확인하십시오. 나중에 할 수 있는 일에 시간을 낭비하지 마십시오. 당신이 그들에게 알리는 것은 그들의 행동이 필요해야 합니다(누군가에게 답장을 보내거나 행사에 참석하기). 또한 웹 앱이 표시되거나 포커스가 있는 경우 알림을 푸시하지 마십시오.

와 상호 작용할 때 알림은 사용자를 오프라인으로 작동하는 페이지로 안내해야 합니다. 알림은 읽지 않은 상태로 있을 수 있습니다. 사용자가 네트워크에 연결되어 있지 않을 때 상호 작용할 수 있습니다. 푸시 알림과 상호 작용을 시도한 후 작동을 거부하면 사용자는 좌절할 것입니다.

푸시 알림을 위한 최고의 경험을 통해 사용자는 웹 앱을 전혀 열지 않아도 됩니다 ! "새 메시지가 있습니다."는 클릭 유인 헤드라인만큼 쓸모없고 짜증납니다. 메시지와 보낸 사람을 표시합니다.

알림의 작업 버튼은 브라우저를 열지 않아도 되는 상호 작용 프롬프트를 제공할 수 있습니다("이 게시물에 좋아요", "예로 회신", "아니요로 회신", "나중에 알림"). 이는 사용자의 조건에 따라 서비스를 제공하고 참여를 유지하며 시간 투자를 최소화합니다.

사용자에게 정기적이거나 관련 없는 알림을 스팸으로 보내는 경우 사용자는 브라우저에서 앱에 대한 알림을 비활성화할 수 있습니다. 그 후에는 그들을 다시 참여시키는 것이 거의 불가능할 것이며 다시 쉽게 허락을 요청할 수 없을 것입니다!

이를 방지하려면 앱의 "알림 비활성화" 버튼으로 가는 경로를 명확하고 쉽게 만드십시오. 사용자를 실망시키는 문제를 해결한 후에는 다시 참여를 시도할 수 있습니다.

푸시 알림 API에는 서비스 워커가 필요합니다. 브라우저 탭이 열려 있지 않을 때 푸시 알림을 받을 수 있으므로 서비스 워커는 백그라운드 스레드에서 알림 요청을 처리합니다. 사용자에게 알림을 표시하기 전에 API에 가져오기 요청을 하는 것과 같은 비동기 작업을 수행할 수 있습니다.

푸시 알림을 생성하려면 브라우저 제조업체에서 제공한 엔드포인트에 요청하세요. Chromium 기반 브라우저(Opera, Samsung 및 Chrome)의 경우 Firebase 클라우드 메시징입니다. 이러한 브라우저는 사양에서도 약간 벗어나 작동합니다.

푸시 알림 권한을 요청하여 이에 대한 세부 정보를 찾을 수 있습니다.

 serviceWorkerRegistration .pushManager .subscribe({ // Required parameter as receiving updates // but not displaying a message is not supported everywhere. userVisibleOnly: true }) .then(function(subscription) { return sendSubscriptionToServer(subscription); })

구독은 다음과 같은 개체입니다.

 { "endpoint": "https://example.com/some/uuid" }

위의 예에서 uuid 는 현재 사용 중인 브라우저를 고유하게 식별합니다.

참고: Chromium 기반 브라우저는 약간 다르게 작동합니다. 웹 앱의 매니페스트 파일에 입력해야 하는 Firebase 앱 ID가 필요합니다(예 "gcm_sender_id": "90157766285" ).

또한 끝점은 제공된 형식으로 작동하지 않습니다. 서버가 작동하려면 약간 수정해야 합니다. head 에 API 키가 있고 body 에 uuid 가 있는 POST 요청이어야 합니다.

푸시 알림을 보낼 때 푸시 알림 자체의 본문에 데이터를 보낼 수 있습니다. 이는 복잡하며 API 요청의 내용을 암호화해야 합니다. Node.js용 web-push 패키지가 이를 처리할 수 있지만 선호하지 않습니다.

알림이 수신되면 비동기 요청을 수행할 수 있으므로 "간지럼"이라고 하는 최소한의 알림을 클라이언트에 보내는 것을 선호합니다. 그러면 서비스 워커가 내 API에 가져오기 요청을 보내 모든 최근 업데이트.

참고: 서비스 워커는 언제든지 브라우저에서 닫을 수 있습니다. 푸시 이벤트의 event.waitUntil 함수는 서비스 작업자에게 이벤트가 완료될 때까지 닫지 않도록 지시합니다.

 self.addEventListener('push', function(event) { event.waitUntil( // Makes API request, returns Promise getMessageDetails() .then(function (details) { self.registration.showNotification( details.title, { body: details.message, icon: '/my-app-logo-192x192.png' }) }) ); });

알림 이벤트에 대한 클릭 또는 누르기 상호 작용도 수신할 수 있습니다. 이것들을 사용하여 대응 방법을 결정하십시오. 새 브라우저 탭을 열거나 기존 탭에 초점을 맞추거나 API를 요청할 수 있습니다. 알림을 닫을지 아니면 계속 열어둘지 선택할 수도 있습니다. 알림 자체에 뛰어난 기능을 구축하려면 알림에 대한 작업과 함께 이 기능을 사용하십시오. 이렇게 하면 사용자가 매번 앱을 열 필요가 없기 때문에 훌륭한 경험이 될 것입니다.

웹의 강점을 무시하지 마십시오

마지막이자 가장 중요한 점은 앱과 같은 경험을 위해 서두를 때 매우 중요한 한 가지 측면인 URL에서 웹과 같은 상태를 유지하는 것을 잊지 말아야 한다는 것입니다.

설치된 웹 앱은 종종 브라우저 셸을 숨깁니다. 사용자가 현재 URL을 공유할 수 있는 주소 표시줄이 없으며 사용자는 나중을 위해 현재 페이지를 저장할 수 없습니다.

URL에는 고유한 웹 이점이 있습니다. 앱을 탐색하는 방법을 설명하는 대신 클릭하여 사람들이 앱을 사용하도록 할 수 있습니다. 그럼에도 불구하고 이것을 사용자에게 노출하는 것을 잊는 것은 매우 쉽습니다. 당신은 세계 최고의 앱을 작성할 수 있지만 아무도 그것을 공유할 수 없다면 스스로에게 큰 손해를 끼친 것입니다.

공유 버튼이나 URL을 노출하는 버튼을 통해 앱을 공유할 수 있는 방법을 제공하세요.

프로그레시브 웹 앱을 지원하지 않는 브라우저는 어떻습니까?

ServiceWorker가 준비되었습니까?를 확인하십시오. 브라우저 전반에 걸친 서비스 워커에 대한 지원의 현재 상태.

이 모든 과정에서 내가 Chrome, Firefox 및 Edge를 언급했지만 Safari는 제외했다는 사실을 눈치채셨을 것입니다. 애플은 웹앱을 세상에 선보이고 프로그레시브 웹앱에 관심을 보여왔지만 여전히 서비스 워커나 웹앱 매니페스트를 지원하지 않는다. 당신은 무엇을 할 수 있나요?

AppCache를 사용하여 Safari용 오프라인 웹사이트를 만드는 것이 가능하지만, 그렇게 하는 것은 어렵고 페이지를 깨뜨리거나 처음 로드한 후 영구적으로 최신 상태가 아닌 상태로 유지할 수 있는 이상한 경우가 많습니다.

대신 훌륭한 웹 앱 경험을 구축하십시오. 매우 좋은 브라우저인 Safari에서 경험이 여전히 훌륭할 것이기 때문에 작업이 낭비되지 않을 것입니다. 서비스 워커가 Safari에 올 때, 당신은 그들을 이용할 준비가 되어 있을 것입니다.

마지막으로 하드웨어와 상호 작용하기 위한 Web Bluetooth API, 가상 환경을 위한 WebVR과 같은 웹 플랫폼에 제공되는 새로운 기능과 그 이면의 기술에 대한 지원이 증가함에 따라 웹 앱 세계에서 많은 흥미진진한 발전을 기대할 수 있습니다. 리얼리티, 그리고 고속 게임을 위한 WebGL 2. 지금은 웹 앱의 가능성을 탐구하고 웹의 미래를 형성하는 데 참여할 좋은 시간입니다.

연결

프로그레시브 웹 앱에 대한 기타 쓰기

• "프로그레시브 웹 앱의 상태와 미래에 대한 또 다른 블로그", Ada Rose Edwards

기사에서 참조된 링크

• "App Store의 형태", Charles Perry
• 서비스 워커 도우미, Google, GitHub
• 서비스 워커 도구 상자, Google, GitHub
• "300밀리초의 클릭 지연과 iOS 8", TJ VanToll
• "캐싱 모범 사례 및 최대 연령 문제", Jake Archibald