Questions fréquentes sur les notifications push

Pourquoi le push ne fonctionne-t-il pas lorsque le navigateur est fermé ?

Cette question revient souvent, en grande partie parce que certains scénarios rendent la compréhension difficile.

Commençons par Android. L'OS Android est conçu pour écouter les messages push et, lorsqu'il en reçoit un, réveiller l'application Android appropriée pour le traiter, que l'application soit fermée ou non.

Il en va de même pour tous les navigateurs sur Android : le navigateur est réveillé lorsqu'un message push est reçu, puis il réveille votre service worker et distribue l'événement push.

Sur les OS pour ordinateur, la situation est plus nuancée. Il est plus facile de l'expliquer sur Mac OS X, car un indicateur visuel permet d'illustrer les différents scénarios.

Sous Mac OS X, vous pouvez savoir si un programme est en cours d'exécution ou non grâce à un repère sous l'icône de l'application dans le Dock.

Si vous comparez les deux icônes Chrome dans le dock suivant, celle de gauche est en cours d'exécution, comme l'illustre le repère sous l'icône, tandis que celle de droite n'est pas en cours d'exécution, d'où l'absence de repère en dessous.

Exemple d'OS X

Dans le contexte de la réception de messages push sur ordinateur, vous recevrez des messages lorsque le navigateur est en cours d'exécution, c'est-à-dire lorsqu'il est marqué sous l'icône.

Cela signifie que le navigateur peut n'avoir aucune fenêtre ouverte, et que vous recevrez quand même le message push dans votre service worker, car le navigateur s'exécute en arrière-plan.

La seule fois où une notification push n'est pas reçue, c'est lorsque le navigateur est complètement fermé, c'est-à-dire qu'il ne s'exécute pas du tout (aucune marque). Il en va de même pour Windows, même s'il est un peu plus difficile de déterminer si Chrome s'exécute en arrière-plan ou non.

Comment faire en sorte que mon application Web sur l'écran d'accueil s'ouvre en plein écran à partir d'un push ?

Dans Chrome pour Android, une application Web peut être ajoutée à l'écran d'accueil. Lorsqu'elle est ouverte depuis l'écran d'accueil, elle peut se lancer en mode plein écran sans la barre d'URL, comme illustré ci-dessous.

Icône de l'écran d'accueil en plein écran

Pour que cette expérience reste cohérente, les développeurs souhaitent que les notifications sur lesquelles l'utilisateur clique ouvrent également leur application Web en plein écran.

Chrome a "en quelque sorte" implémenté cette fonctionnalité, mais vous la trouverez peut-être peu fiable et difficile à utiliser. Voici les détails d'implémentation pertinents :

Cela signifie que, sauf si l'utilisateur accède à votre site via l'icône de l'écran d'accueil assez régulièrement, vos notifications s'ouvriront dans l'UI normale du navigateur.

Nous allons continuer à travailler sur ce problème.

Pourquoi est-ce mieux que les WebSockets ?

Un service worker peut être activé lorsque la fenêtre du navigateur est fermée. Un WebSocket ne reste actif que tant que le navigateur et la page Web sont ouverts.

Qu'en est-il de GCM, FCM, Web Push et Chrome ?

Cette question comporte plusieurs aspects, et le moyen le plus simple de l'expliquer est de passer en revue l'historique des notifications push Web et de Chrome. (Ne vous inquiétez pas, c'est court.)

Décembre 2014

Lorsque Chrome a implémenté le push Web pour la première fois, il utilisait Google Cloud Messaging (GCM) pour envoyer des messages push du serveur au navigateur.

Il ne s'agissait pas de notifications push Web. Plusieurs raisons expliquent pourquoi cette configuration initiale de Chrome et GCM n'était pas une "vraie" notification push Web.

  • GCM nécessite que les développeurs configurent un compte sur la Google Developers Console.
  • Chrome et GCM avaient besoin d'un ID d'expéditeur spécial à partager par une application Web pour pouvoir configurer correctement la messagerie.
  • Les serveurs de GCM ont accepté une requête API personnalisée qui n'était pas une norme Web.

Juillet 2016

En juillet, une nouvelle fonctionnalité de push Web a été lancée : les clés de serveur d'application (ou VAPID, comme on l'appelle dans la spécification). Lorsque Chrome a ajouté la compatibilité avec cette nouvelle API, il a utilisé Firebase Cloud Messaging (également appelé FCM) au lieu de GCM comme service de messagerie. Ceci est important pour plusieurs raisons :

  • Les clés de serveur d'application et Chrome ne nécessitent pas de configurer un projet avec Google ou Firebase. Il fonctionnera, tout simplement.
  • FCM est compatible avec le protocole Web Push, qui est l'API que tous les services Web Push prendront en charge. Cela signifie que, quel que soit le service push utilisé par un navigateur, il vous suffit d'effectuer le même type de requête pour qu'il envoie le message.

Pourquoi est-ce déroutant aujourd'hui ?

La confusion est grande maintenant que du contenu a été écrit sur le sujet des notifications push Web, dont une grande partie fait référence à GCM ou FCM. Si un contenu fait référence à GCM, cela signifie probablement qu'il est obsolète OU qu'il se concentre trop sur Chrome. (Je suis coupable d'avoir fait cela dans un certain nombre d'anciens posts.)

Considérez plutôt que le push Web se compose d'un navigateur, qui utilise un service push pour gérer l'envoi et la réception de messages, et que le service push accepte une requête de "protocole push Web". Si vous pensez en ces termes, vous pouvez ignorer le navigateur et le service push utilisés et vous mettre au travail.

Ce guide a été rédigé pour se concentrer sur l'approche standard des notifications push Web et ignore délibérément tout le reste.

Firebase dispose d'un SDK JavaScript. définition et fonctions

Si vous avez découvert le SDK Web Firebase et remarqué qu'il dispose d'une API de messagerie pour JavaScript, vous vous demandez peut-être en quoi il diffère du Web Push.

Le SDK de messagerie (connu sous le nom de SDK JS Firebase Cloud Messaging) effectue quelques opérations en arrière-plan pour faciliter l'implémentation des notifications push Web.

  • Au lieu de vous soucier d'un PushSubscription et de ses différents champs, vous n'avez qu'à vous soucier d'un jeton FCM (une chaîne).
  • En utilisant les jetons de chaque utilisateur, vous pouvez utiliser l'API FCM propriétaire pour déclencher des messages push. Cette API ne nécessite pas de chiffrement des charges utiles. Vous pouvez envoyer une charge utile en texte brut dans le corps d'une requête POST.
  • L'API propriétaire de FCM est compatible avec des fonctionnalités personnalisées, par exemple les sujets FCM (elle fonctionne également sur le Web, bien qu'elle soit peu documentée).
  • Enfin, FCM est compatible avec Android, iOS et le Web. Il est donc plus facile pour certaines équipes de l'utiliser dans des projets existants.

Cette API utilise le push Web en coulisses, mais son objectif est de l'abstraire.

Comme je l'ai dit dans la question précédente, si vous considérez les notifications push Web comme un simple navigateur et un service push, vous pouvez considérer le SDK Messaging de Firebase comme une bibliothèque permettant de simplifier l'implémentation des notifications push Web.

Étapes suivantes

Ateliers de programmation