Notifications

Introduction

Qui n’a jamais oublié une application après l’avoir installée et utilisée quelques jours seulement ? Ce comportement est le cauchemar des concepteurs d’applications, car elles doivent être utilisées un maximum afin de générer les revenus qui leur sont associés (publicité, achats…).

L’un des moyens de faire revenir des utilisateurs sur une application est de leur rappeler que celle-ci a été installée sur leur terminal et de leur signaler que certaines interactions ont été faites. Ces interactions peuvent être de tout type : une nouvelle offre commerciale, un commentaire sur un article ou encore un message privé. Pour cela, nous allons utiliser une solution que nous avons l’habitude de manipuler tous les jours avec des applications natives : les notifications.

Les notifications peuvent être de tout type : e-mail, SMS, message push… Elles se basent le plus souvent sur des développements spécifiques côté serveur. Dans cet ouvrage, nous allons nous concentrer sur les notifications de type push. Avec ce système de notifications, qui suppose l’accord de l’utilisateur bien évidemment, le serveur est en charge d’envoyer un message dès qu’il pense que quelque chose d’intéressant pour l’utilisateur...

API Notification

L’API Notification permet d’afficher un message dans le système de notifications natif de l’appareil. Aucun développement supplémentaire n’est nécessaire pour gérer l’affichage à proprement parler de ce message.

Ces notifications peuvent correspondre à un message push envoyé par le serveur afin de réengager l’utilisateur ou à un message indiquant qu’une tâche asynchrone est terminée, par exemple.

Comme d’habitude, avant d’appeler l’API, nous vérifions qu’elle est disponible en procédant à une feature detection.

if(‘Notification' in window) { 
 
} else { 
  console.log(‘Ce navigateur ne supporte pas cette API') ; 
}

Une fois l’API détectée, nous demandons à l’utilisateur le droit de lui envoyer des notifications. Pour cela, nous utilisons la méthode requestPermission.

if(‘Notification' in window) { 
  Notification.requestPermission(permission => { 
    ... 
  }) ; 
} else { 
  console.log(‘Ce navigateur ne supporte pas cette API') ; 
}

La chaîne de caractères permission que nous récupérons peut prendre trois valeurs :

default : l’utilisateur n’a pas encore fait de choix.
denied : l’utilisateur ne nous donne pas la permission de lui envoyer des notifications.
granted : l’utilisateur nous donne la permission de lui envoyer des notifications.

Dans l’exemple...

API Push

Nous venons de voir comment afficher une notification. Mais ce n’est pas grâce à l’API Notification que nous sommes capables de recevoir des messages depuis le serveur. Nous pourrions mettre en place une solution à base de WebSocket via l’utilisation de librairies comme Socket.io ou SockJS. Mais une telle solution a un gros désavantage : elle n’est pas fonctionnelle lorsque l’application n’est plus utilisée.

Pour rappel, le but d’une Progressive Web App est de réduire l’écart entre une application native et une application web, notamment en la rendant fonctionnelle même quand elle n’est pas démarrée. Nous allons donc utiliser une autre solution : l’API Push.

Grâce à l’API Push, il est à présent possible d’envoyer des messages push afin de notifier à l’utilisateur qu’une mise à jour a été réalisée sur l’application ou dans ses données, et de l’inviter à revenir sur l’application.

Pour récupérer ces messages, nous allons gérer un nouvel événement dans notre Service Worker : l’événement push. Nous devons gérer cet événement dans le Service Worker pour une simple raison. Comme le Service Worker est actif même...

Événements

Depuis le Service Worker, nous pouvons exécuter du code quand l’utilisateur acquitte la réception de la notification (notificationclose) ou clique sur l’une des actions associées à la notification (notificationclick).

Nous devons tout de même faire attention à un point en particulier. L’événement notificationclose est émis lorsque l’utilisateur supprime la notification. S’il supprime toutes les notifications affichées, cet événement n’est pas émis, afin d’optimiser les ressources du téléphone.

Pour ces deux événements, nous pouvons récupérer la notification qui vient d’être manipulée via la propriété notification.

self.addEventListener("notificationclick", event => { 
  console.log(event.notification) ; 
 }) ;

Sur cet objet, nous pouvons récupérer la propriété data :

self.addEventListener("notificationclick", event => { 
     console.log(event.notification.data.dateOfArrival ) ; 
 }) ;

Nous pouvons également savoir sur quelle action l’utilisateur a cliqué, et ainsi déterminer quel traitement doit être exécuté.

self.addEventListener("notificationclick"...

Mise en place côté serveur

Une fois le traitement côté navigateur réalisé, une étape importante reste à faire. Comment envoyer physiquement la notification ? Comment indiquer à notre serveur le moment où une notification doit être envoyée, suite à une interaction dans le système.

Avant d’aller plus loin, rappelons les différents protagonistes de ce workflow.

Le client. Il visite une Progressive Web App depuis son navigateur et décide de s’abonner à certaines notifications afin d’être mis au courant des nouveautés de l’application.
Le serveur de l’application. En fonction des interactions que les clients abonnés ont avec lui, il décide de leur envoyer une notification.
Le serveur tiers qui est en charge d’envoyer la notification. Ce serveur est dépendant du navigateur utilisé par le client. Nous pouvons par exemple citer Firebase Cloud Messaging pour Chrome ou Mozilla Push Service pour Firefox. Lors que le serveur applicatif décide d’envoyer une notification, il ne l’envoie pas directement au client. Il l’envoie tout d’abord au serveur de notification qui se charge, lui, de l’envoyer au client.

Nous allons à présent détailler les différentes briques à implémenter afin de mettre en place un système de push messaging. Pour cela, nous allons manipuler une propriété pushMasnager disponible dans le thread principal de l’application sur l’instance du Service Worker enregistrée.

La première étape est d’enregistrer l’utilisateur dans le système de notification lorsqu’il décide d’activer les notifications pour notre application. Pour cela, nous enregistrons l’objet subscription côté serveur dans une base de données. Un lien doit être fait côté serveur entre cette base de données et l’identifiant du client afin de le retrouver facilement.

Par exemple, dans le thread principal de l’application, lorsque le client clique sur un bouton permettant d’activer ce mécanisme, nous récupérons cet objet subscription et nous le passons en paramètre d’une méthode...

API Notification Triggers

Comme nous venons de le voir, la mise en place de messages de type push nécessite une connexion, car c’est le serveur de notre application qui est à l’origine de l’émission.

Une nouvelle API, développée dans le cadre du projet Fugu (voir le chapitre Projet Fugu), permet de créer des notifications en local, sans avoir besoin du réseau. Cette API se nomme Notification Triggers. Elle est en cours de standardisation et d’implémentation par les navigateurs.

Avant d’appeler l’API, nous vérifions qu’elle est disponible via une feature detection.

if(‘showTrigger' in Notification.prototype) { 
  ... 
} else { 
  console.log(‘Ce navigateur ne supporte pas cette API') ; 
}

Cette API permet donc de programmer des notifications dans le temps. Imaginons une application Calendrier qui crée des rappels pour certains événements que l’utilisateur a enregistrés. Nous pouvons définir un trigger permettant de programmer une notification localement.

Pour cela, nous devons ajouter une nouvelle propriété lors de l’appel de la méthode showNotification. Cette propriété, showTrigger, permet de définir à quel moment la notification doit être affichée. Cette information...

Compatibilité navigateurs

Le tableau suivant récapitule le support de l’API Push par l’ensemble des navigateurs du marché.

Si le navigateur de l’utilisateur ne supporte pas la réception de messages push, mais qu’il souhaite tout de même être averti quand un événement se produit, il faut implémenter, côté serveur, une solution de notification alternative, par exemple basée sur l’envoi d’e-mails.

Application fil rouge

Dans notre application, nous allons afficher une notification lorsqu’une synchronisation de type Background Sync est exécutée par le Service Worker. Pour cela, nous devons tout d’abord modifier notre fichier JavaScript principal afin de demander la permission d’émettre des notifications. Afin de garder une expérience utilisateur optimale, nous faisons cette demande non pas à l’affichage de la page, mais si et seulement si nous en avons besoin, c’est-à-dire lorsque notre fichier JavaScript réalise une demande de synchronisation. Nous ajoutons donc le code suivant juste avant de faire la demande de synchronisation.

navigator.permissions 
  .query({ 
    name: "background-sync", 
  }) 
  .then(({ state }) => { 
    if (state === "granted") { 
      Notification.requestPermission(status => { 
        console.log("Notification permission status:", status); 
      }); 
 
      return navigator.serviceWorker.ready 
          .then((reg) => { 
           ...