Questions fréquentes sur les notifications push

Pourquoi la commande push ne fonctionne-t-elle pas lorsque le navigateur est fermé ?

Cette question se pose un peu, en grande partie parce que certains scénarios rendent il est difficile de raisonner et de comprendre.

Commençons par Android. L'OS Android est conçu pour écouter les messages push. Lorsque vous en recevez un, activez 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 s'active à la réception d'un message push, puis le navigateur active votre service worker et envoie l'événement push.

Sur Mac OS X, il est plus nuancé et plus facile à expliquer sur Mac OS X, car un indicateur visuel permet d'expliquer les différents scénarios.

Sous Mac OS X, vous pouvez savoir si un programme est en cours d'exécution en le marquant sous l'icône de l'application dans le dock.

Si vous comparez les deux icônes Chrome du dock suivant, celle de gauche est en cours d'exécution, comme l'illustre le marquage sous l'icône, tandis que Chrome de droite n'est pas en cours d'exécution, d'où l'absence de marquage 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 sera en cours d'exécution, c'est-à-dire lorsqu'il sera marqué sous l'icône.

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

Le seul moment où un push n'est pas reçu est lorsque le navigateur est complètement fermé, c'est-à-dire lorsqu'il n'est pas en cours d'exécution (aucun 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 l'application Web de l'écran d'accueil s'ouvre en plein écran suite à une pression ?

Sur Chrome pour Android, une application Web peut être ajoutée à l'écran d'accueil. Lorsque l'application Web est ouverte depuis l'écran d'accueil, elle peut se lancer en mode plein écran sans la barre d'adresse, 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 lorsqu'ils cliquent sur leurs notifications ouvrent également leur application Web en plein écran.

Chrome l'a en quelque sorte implémenté, même si vous trouvez qu'elle n'est pas fiable et qu'elle est difficile à raisonner. Voici les détails d'implémentation pertinents:

Cela signifie qu'à moins que l'utilisateur ne consulte régulièrement votre site via l'icône de l'écran d'accueil, vos notifications s'ouvriront dans l'interface utilisateur normale du navigateur.

Nous étudierons ce problème plus en détail.

Pourquoi est-ce meilleur que WebSockets ?

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

Quel est le problème avec GCM, FCM, Web Push et Chrome ?

Cette question comporte plusieurs facettes. La façon la plus simple de l'expliquer est de parcourir l'historique de Web Push et de Chrome. (Ne vous inquiétez pas, il est court.)

Décembre 2014

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

Il ne s'agissait pas de push Web. Plusieurs raisons peuvent expliquer pourquoi cette configuration précoce de Chrome et de GCM n'était pas une "vraie" transmission Web.

  • Les développeurs doivent créer un compte dans la Google Developers Console.
  • Pour configurer correctement la messagerie, Chrome et GCM avaient besoin qu'une application Web partage un identifiant d'expéditeur spécial.
  • 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 Web push est disponible : les clés de serveur d'applications (ou VAPID, comme l'on connaît la spécification). Lorsque Chrome est compatible 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:

  • Chrome et les clés de serveur d'applications n'ont pas besoin d'être configurés avec Google ou Firebase. Ça marchera tout simplement.
  • FCM est compatible avec le protocole Web push, qui est l'API compatible avec tous les services Web push. Ainsi, quel que soit le service push utilisé par un navigateur, vous envoyez simplement le même type de requête, qui enverra le message.

Pourquoi est-ce déroutant aujourd'hui ?

Maintenant que le contenu a été écrit sur le sujet du push Web, qui fait en grande partie référence à GCM ou FCM, cela prêt à confusion. Si un contenu fait référence à GCM, vous devriez probablement le traiter comme un signe qu'il s'agit d'un contenu ancien OU qu'il est trop axé sur Chrome. (Je suis coupable d'avoir fait cela dans un certain nombre d'anciens messages.)

Considérez plutôt le protocole Web push 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 Web push". Si vous réfléchissez à ces termes, vous pouvez ignorer le navigateur et le service push qu'il utilise pour vous mettre au travail.

Ce guide a été rédigé pour se concentrer sur l'approche standard de la transmission Web et ignore tout le reste.

Firebase dispose d'un SDK JavaScript. Quoi et pourquoi ?

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

Le SDK de messagerie (appelé SDK JS Firebase Cloud Messaging) effectue quelques astuces en arrière-plan pour faciliter l'implémentation du push Web.

  • Au lieu de vous soucier d'un PushSubscription et de ses différents champs, vous n'avez à vous soucier que du jeton FCM (une chaîne).
  • À l'aide des jetons de chaque utilisateur, vous pouvez vous servir de l'API propriétaire FCM 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 un corps de requête POST.
  • L'API propriétaire de FCM prend en charge des fonctionnalités personnalisées, telles que FCM Topics. Elle fonctionne aussi sur le Web, bien qu'elle soit mal documentée.
  • Enfin, FCM est compatible avec Android, iOS et le Web. Il est donc plus facile pour certaines équipes de travailler sur des projets existants.

Elle utilise le Web push en arrière-plan, mais son objectif est de faire abstraction du contexte.

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

Étapes suivantes

Ateliers de programmation