브라우저가 닫혀 있을 때 푸시가 작동하지 않는 이유는 무엇인가요?
이 질문은 추론하고 이해하기 어려운 몇 가지 시나리오가 있기 때문에 자주 발생합니다.
Android부터 시작하겠습니다. Android OS는 푸시 메시지를 수신 대기하도록 설계되었으며, 푸시 메시지를 수신하면 앱이 종료되었는지 여부와 관계없이 푸시 메시지를 처리할 적절한 Android 앱을 절전 모드에서 해제합니다.
이는 Android의 모든 브라우저에서 정확히 동일합니다. 푸시 메시지가 수신되면 브라우저가 절전 모드에서 해제되고 브라우저가 서비스 워커를 절전 모드에서 해제하고 푸시 이벤트를 전달합니다.
데스크톱 OS에서는 좀 더 미묘한 차이가 있으며, 다양한 시나리오를 설명하는 데 도움이 되는 시각적 표시기가 있으므로 Mac OS X에서 설명하는 것이 가장 쉽습니다.
Mac OS X에서는 Dock의 앱 아이콘 아래에 있는 표시를 통해 프로그램이 실행 중인지 여부를 알 수 있습니다.
다음 도크에서 두 Chrome 아이콘을 비교하면 왼쪽 아이콘은 아이콘 아래의 표시에서 알 수 있듯이 실행 중인 반면 오른쪽 Chrome은 실행 중이 아니므로 아래에 표시가 없습니다.
데스크톱에서 푸시 메시지를 수신하는 경우 브라우저가 실행 중일 때, 즉 아이콘 아래에 표시가 있을 때 메시지를 수신합니다.
즉, 브라우저에 열려 있는 창이 없어도 브라우저가 백그라운드에서 실행 중이므로 서비스 워커에서 푸시 메시지를 계속 수신할 수 있습니다.
브라우저가 완전히 닫혀 있는 경우, 즉 전혀 실행되지 않는 경우 (표시 없음)에만 푸시가 수신되지 않습니다. Windows도 마찬가지지만 Chrome이 백그라운드에서 실행 중인지 확인하기가 조금 더 까다롭습니다.
푸시에서 홈 화면 웹 앱을 전체 화면으로 열려면 어떻게 해야 하나요?
Android용 Chrome에서는 웹 앱을 홈 화면에 추가할 수 있으며, 홈 화면에서 웹 앱을 열면 아래와 같이 URL 표시줄 없이 전체 화면 모드로 실행할 수 있습니다.
이러한 환경을 일관되게 유지하기 위해 개발자는 클릭한 알림이 웹 앱을 전체 화면으로 열기를 원합니다.
Chrome은 이를 '일종의' 구현으로 구현했지만, 신뢰할 수 없고 추론하기 어려울 수 있습니다. 관련 구현 세부정보는 다음과 같습니다.
즉, 사용자가 홈 화면 아이콘을 통해 사이트를 정기적으로 방문하지 않는 한 알림은 일반 브라우저 UI에서 열립니다.
이 문제는 추가로 해결될 예정입니다.
웹 소켓보다 나은 점은 무엇인가요?
브라우저 창이 닫혀 있을 때 서비스 워커가 활성화될 수 있습니다. 웹 소켓은 브라우저와 웹페이지가 열려 있는 동안에만 유지됩니다.
GCM, FCM, 웹 푸시, Chrome의 관계는 무엇인가요?
이 질문에는 여러 측면이 있으며 가장 쉽게 설명하는 방법은 웹 푸시와 Chrome의 역사를 단계별로 살펴보는 것입니다. (걱정하지 마세요. 짧습니다.)
2014년 12월
Chrome에서 웹 푸시를 처음 구현했을 때 Chrome은 Google 클라우드 메시징 (GCM)을 사용하여 서버에서 브라우저로 푸시 메시지를 전송했습니다.
이것은 웹 푸시가 아니었습니다. Chrome과 GCM의 초기 설정이 '실제' 웹 푸시가 아니었던 데에는 몇 가지 이유가 있습니다.
- GCM을 사용하려면 개발자가 Google Developers Console에서 계정을 설정해야 합니다.
- Chrome과 GCM은 메시지를 올바르게 설정하기 위해 웹 앱에서 공유할 특별한 발신자 ID가 필요했습니다.
- GCM 서버는 웹 표준이 아닌 맞춤 API 요청을 수락했습니다.
2016년 7월
7월에는 웹 푸시에 애플리케이션 서버 키 (또는 사양으로 알려진 VAPID)라는 새로운 기능이 추가되었습니다. Chrome에서 이 새로운 API에 대한 지원을 추가했을 때 메시징 서비스로 GCM 대신 Firebase 클라우드 메시징 (FCM)을 사용했습니다. 이는 다음과 같은 몇 가지 이유로 중요합니다.
- Chrome 및 애플리케이션 서버 키는 Google 또는 Firebase에서 프로젝트를 설정할 필요가 없습니다. 별다른 설정 없이 작동합니다.
- FCM은 모든 웹 푸시 서비스에서 지원하는 API인 웹 푸시 프로토콜을 지원합니다. 즉, 브라우저에서 사용하는 푸시 서비스에 관계없이 동일한 종류의 요청을 하면 메시지가 전송됩니다.
오늘날 혼란스러운 이유는 무엇인가요?
웹 푸시 주제에 관해 작성된 콘텐츠가 많고 이 중 상당수가 GCM 또는 FCM을 참조하므로 현재 많은 혼란이 있습니다. 콘텐츠가 GCM을 참조하는 경우 오래된 콘텐츠이거나 Chrome에 너무 집중하고 있다는 신호로 간주해야 합니다. (저도 예전 게시물에서 이런 실수를 많이 했습니다.)
대신 웹 푸시는 푸시 서비스를 사용하여 메시지 송수신을 관리하는 브라우저로 구성되며, 푸시 서비스는 '웹 푸시 프로토콜' 요청을 수락한다고 생각하면 됩니다. 이러한 관점에서 생각하면 어떤 브라우저와 어떤 푸시 서비스를 사용하고 있는지 무시하고 작업을 시작할 수 있습니다.
이 가이드는 웹 푸시의 표준 접근 방식에 초점을 맞춰 작성되었으며, 다른 모든 것은 의도적으로 무시합니다.
Firebase에는 JavaScript SDK가 있습니다. 개념 및 필요성
Firebase 웹 SDK를 발견하고 JavaScript용 메시징 API가 있다는 것을 알게 된 분들은 웹 푸시와 어떻게 다른지 궁금할 수 있습니다.
메시징 SDK (Firebase 클라우드 메시징 JS SDK)는 웹 푸시를 더 쉽게 구현할 수 있도록 백그라운드에서 몇 가지 작업을 수행합니다.
PushSubscription및 다양한 필드에 대해 걱정할 필요 없이 FCM 토큰 (문자열)만 신경 쓰면 됩니다.- 각 사용자의 토큰을 사용하여 독점 FCM API를 통해 푸시 메시지를 트리거할 수 있습니다. 이 API는 페이로드 암호화가 필요하지 않습니다. POST 요청 본문에 일반 텍스트 페이로드를 전송할 수 있습니다.
- FCM의 독점 API는 맞춤 기능(예: FCM 주제)을 지원합니다(웹에서도 작동하지만 문서화가 제대로 되어 있지 않음).
- 마지막으로 FCM은 Android, iOS, 웹을 지원하므로 일부 팀에서는 기존 프로젝트에서 작업하기가 더 쉽습니다.
이 API는 백그라운드에서 웹 푸시를 사용하지만, 이를 추상화하는 것이 목표입니다.
이전 질문에서 말씀드렸듯이 웹 푸시를 브라우저와 푸시 서비스로만 생각한다면 Firebase의 메시징 SDK를 웹 푸시 구현을 간소화하는 라이브러리로 생각할 수 있습니다.
다음에 수행할 작업
- 웹 푸시 알림 개요
- 푸시 작동 방식
- 사용자 구독
- 권한 UX
- 웹 푸시 라이브러리를 사용하여 메시지 보내기
- 웹 푸시 프로토콜
- 푸시 이벤트 처리
- 알림 표시
- 알림 동작
- 일반적인 알림 패턴
- 푸시 알림 FAQ
- 일반적인 문제 및 버그 신고