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 qu'il existe quelques scénarios qui rendent la compréhension et la logique difficiles.

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 gérer le message push, que l'application soit fermée ou non.

C'est exactement la même chose avec n'importe quel navigateur 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 de bureau, c'est plus nuancé et plus facile à expliquer sur Mac OS X, car il existe un indicateur visuel pour expliquer les différents scénarios.

Sous Mac OS X, vous pouvez savoir si un programme s'exécute ou non grâce à un marquage 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 illustré par le repère sous l'icône, tandis que Chrome à droite n'est pas en cours d'exécution, d'où l'absence de repère en dessous.

Exemple d'OS X

Pour recevoir des messages push sur ordinateur, vous devez les recevoir lorsque le navigateur est en cours d'exécution (c'est-à-dire que le marquage sous l'icône est visible).

Cela signifie que le navigateur ne peut pas avoir de fenêtres ouvertes, et vous recevrez toujours le message push dans votre service worker, car le navigateur s'exécute en arrière-plan.

Le seul cas où un push n'est pas reçu est lorsque le navigateur est complètement fermé, c'est-à-dire qu'il ne s'exécute pas du tout (pas de marquage). Il en va de même pour Windows, bien qu'il soit 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 de l'écran d'accueil s'ouvre en plein écran à partir d'un push ?

Dans Chrome pour Android, vous pouvez ajouter une application Web à 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 soit cohérente, les développeurs souhaitent que leurs notifications cliquées ouvrent également leur application Web en plein écran.

Chrome a "en quelque sorte" implémenté cela, bien que vous puissiez le trouver peu fiable et difficile à raisonner. Les détails d'implémentation pertinents sont les suivants:

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

Nous allons continuer à travailler sur ce problème.

Pourquoi est-ce mieux que les sockets Web ?

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

Qu'est-ce que GCM, FCM, Web Push et Chrome ?

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

Décembre 2014

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

Il ne s'agissait pas d'un push Web. Plusieurs raisons expliquent que cette configuration précoce de Chrome et de GCM n'était pas un "vrai" push Web.

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

Juillet 2016

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

  • Les clés Chrome et de serveur d'applications ne nécessitent aucun type de projet à configurer avec Google ou Firebase. Tout fonctionnera.
  • 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 de push utilisé par un navigateur, il vous suffit d'effectuer le même type de requête pour envoyer le message.

Pourquoi est-ce déroutant aujourd'hui ?

Il existe une grande confusion maintenant que des contenus ont été rédigés sur le sujet du push Web, dont une grande partie fait référence à GCM ou FCM. Si un contenu fait référence à GCM, vous devez probablement le considérer comme un signe qu'il s'agit d'un contenu ancien OU qu'il est trop axé sur Chrome. (Je suis coupable de l'avoir fait dans un certain nombre d'anciens posts.)

Considérez plutôt le push Web comme un navigateur qui utilise un service push pour gérer l'envoi et la réception de messages, où le service push accepte une requête de "protocole push Web". Si vous raisonnez ainsi, vous pouvez ignorer le navigateur et le service de push utilisés, et vous mettre au travail.

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

Firebase dispose d'un SDK JavaScript. Qu'est-ce que vous faites et pourquoi ?

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

Le SDK de messagerie (connu sous le nom de SDK JavaScript Firebase Cloud Messaging) effectue quelques astuces en coulisses 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).
  • À l'aide des 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 chiffrer les 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 les fonctionnalités personnalisées, comme les thèmes FCM (elle fonctionne également sur le Web, mais elle est mal documentée).
  • Enfin, FCM est compatible avec Android, iOS et le Web. Il est donc plus facile à utiliser pour certaines équipes dans les projets existants.

Cette méthode utilise le push Web en arrière-plan, mais son objectif est de l'extraire.

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

Étapes suivantes

Ateliers de programmation