Firebase Cloud Messaging (FCM) offre un large éventail d'options et de fonctionnalités de messagerie. Les informations de cette page sont destinées à vous aider à comprendre les différents types de messages FCM et ce que vous pouvez en faire.
Messages de notification avec charge utile de données facultative
Que ce soit de manière programmatique ou via la console Firebase, vous pouvez envoyer des messages de notification contenant une charge utile facultative de paires clé/valeur personnalisées. Dans le compositeur de notifications, utilisez les champs Données personnalisées dans Options avancées.
Le comportement de l'application lorsqu'elle reçoit des messages incluant des charges utiles de notification et de données dépend de l'état de l'application (en arrière-plan ou au premier plan), c'est-à-dire si elle est active ou non au moment de la réception.
- En arrière-plan, les applications reçoivent la charge utile de notification dans la barre de notification et ne gèrent la charge utile de données que lorsque l'utilisateur appuie sur la notification.
- Au premier plan, votre application reçoit un objet de message avec les deux charges utiles disponibles.
Voici un message au format JSON contenant à la fois la clé notification et la clé data :
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}Options de livraison
FCM fournit un ensemble spécifique d'options de remise pour les messages envoyés aux appareils Android, et permet d'utiliser des options similaires sur les plates-formes Apple et le Web. Par exemple, le comportement des messages "réductibles" est compatible avec Android via collapse_key de FCM, avec Apple via apns-collapse-id et avec JavaScript/Web via Topic. Pour en savoir plus, consultez les descriptions de cette section et la documentation de référence associée.
Définir la priorité d'un message
Vous avez deux options pour attribuer une priorité de diffusion aux messages en aval : normale et élevée. Bien que le comportement diffère légèrement selon les plates-formes, la diffusion des messages de priorité normale et élevée fonctionne comme suit :
Priorité normale : Les messages de priorité normale sont envoyés immédiatement lorsque l'application est au premier plan. Pour les applications mises en arrière-plan, la diffusion peut être retardée. Pour les messages moins urgents, comme les notifications de nouveaux e-mails, la synchronisation de votre UI ou la synchronisation des données de l'application en arrière-plan, choisissez la priorité de distribution normale.
Priorité élevée. FCM tente de distribuer immédiatement les messages à priorité élevée, même si l'appareil est en mode Sommeil. Les messages à priorité élevée sont destinés au contenu urgent et visible par l'utilisateur.
Voici un exemple de message à priorité normale envoyé via le protocole HTTP v1 FCM pour informer un abonné à un magazine que de nouveaux contenus sont disponibles au téléchargement :
{
"message":{
"topic":"subscriber-updates",
"notification":{
"body" : "This week's edition is now available.",
"title" : "NewsMagazine.com",
},
"data" : {
"volume" : "3.21.15",
"contents" : "http://www.news-magazine.com/world-week/21659772"
},
"android":{
"priority":"normal"
},
"apns":{
"headers":{
"apns-priority":"5"
}
},
"webpush": {
"headers": {
"Urgency": "high"
}
}
}
}Pour en savoir plus sur la définition de la priorité des messages sur des plates-formes spécifiques :
- Documentation APNs
- Définir et gérer la priorité des messages (Android)
- Urgence des messages push Web
Cas d'utilisation critiques pour la vie
Les API FCM ne sont pas conçues pour les alertes d'urgence ni pour d'autres activités à haut risque pour lesquelles l'utilisation ou la défaillance des API pourrait entraîner la perte de vies humaines, des préjudices corporels ou des dommages à l'environnement (comme l'exploitation d'installations nucléaires, le contrôle du trafic aérien ou l'utilisation d'équipements de survie). Toute utilisation de ce type est expressément interdite en vertu de la section 4. a. 7 des conditions d'utilisation. Vous êtes seul responsable de la gestion de la conformité de votre application avec les Conditions, ainsi que de tout dommage résultant de votre non-respect. Google fournit les API "telles quelles" et se réserve le droit d'interrompre les API, ou toute partie ou fonctionnalité de celles-ci, ou encore votre accès à celles-ci, pour quelque raison que ce soit et à tout moment, sans responsabilité ni autre obligation envers vous ou vos utilisateurs.
Définir la durée de vie d'un message
FCM distribue généralement les messages immédiatement après leur envoi. Toutefois, ce n'est pas toujours possible. Par exemple, si la plate-forme est Android, l'appareil peut être éteint, hors connexion ou indisponible. Ou FCM peut intentionnellement retarder les messages pour empêcher une application de consommer des ressources excessives et d'affecter négativement l'autonomie de la batterie.
Dans ce cas, FCM stocke le message et le distribue dès que possible. Bien que cela ne pose pas de problème dans la plupart des cas, il existe des applications pour lesquelles un message tardif peut être considéré comme non distribué. Par exemple, si le message est une notification d'appel entrant ou de chat vidéo, il n'est pertinent que pendant une courte période avant la fin de l'appel. De même, si le message est une invitation à un événement, il est inutile s'il est reçu après la fin de l'événement.
Sur Android et Web/JavaScript, vous pouvez spécifier la durée de vie maximale d'un message. La valeur doit être une durée comprise entre 0 et 2 419 200 secondes (28 jours). Elle correspond à la période maximale pendant laquelle FCM stocke le message et tente de le distribuer. Les demandes qui ne contiennent pas ce champ sont définies par défaut sur la période maximale de quatre semaines.
Voici quelques utilisations possibles de cette fonctionnalité :
- Appels vidéo entrants
- Événements d'expiration des invitations
- Événements d'agenda
Un autre avantage de la spécification de la durée de vie d'un message est que FCM n'applique pas la limitation des messages réductibles aux messages dont la durée de vie est de 0 seconde.
FCM gère au mieux les messages qui doivent être distribués "tout de suite ou jamais". N'oubliez pas qu'une valeur time_to_live de 0 signifie que les messages qui ne peuvent pas être distribués immédiatement sont supprimés. Toutefois, comme ces messages ne sont jamais stockés, cela permet d'obtenir la meilleure latence pour l'envoi de messages de notification.
Voici un exemple de requête qui inclut le TTL :
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
},
"apns":{
"headers":{
"apns-expiration":"1604750400"
}
},
"android":{
"ttl":"4500s"
},
"webpush":{
"headers":{
"TTL":"4500"
}
}
}
}Durée de vie d'un message
Lorsqu'un serveur d'application publie un message sur FCM et reçoit un ID de message en retour, cela ne signifie pas que le message a déjà été distribué à l'appareil. Cela signifie qu'il a été accepté pour la livraison. Le sort du message une fois accepté dépend de nombreux facteurs.
Dans le meilleur des cas, si l'appareil est connecté à FCM, que l'écran est allumé et qu'il n'y a aucune restriction de limitation du débit, le message est envoyé immédiatement.
Si l'appareil est connecté, mais en mode Sommeil, un message de faible priorité est stocké par FCM jusqu'à ce que l'appareil quitte le mode Sommeil. C'est là que l'indicateur collapse_key entre en jeu : s'il existe déjà un message avec la même clé de réduction (et le même jeton d'enregistrement) stocké et en attente de distribution, l'ancien message est supprimé et le nouveau le remplace (c'est-à-dire que l'ancien message est réduit par le nouveau). Toutefois, si la clé de réduction n'est pas définie, les nouveaux messages et les anciens sont stockés pour une diffusion ultérieure.
Si l'appareil n'est pas connecté à FCM, le message est stocké jusqu'à ce qu'une connexion soit établie (en respectant à nouveau les règles concernant la clé de réduction). Lorsqu'une connexion est établie, FCM envoie tous les messages en attente à l'appareil. Si l'appareil ne se reconnecte jamais (par exemple, s'il a été réinitialisé), le message finit par expirer et est supprimé du stockage FCM. Le délai avant expiration par défaut est de quatre semaines, sauf si l'indicateur time_to_live est défini.
Pour en savoir plus sur la distribution d'un message :
Pour en savoir plus sur la diffusion des messages sur les plates-formes Android ou Apple, consultez le tableau de bord des rapports FCM. Il enregistre le nombre de messages envoyés et ouverts sur les appareils Apple et Android, ainsi que les données sur les "impressions" (notifications vues par les utilisateurs) pour les applications Android.
Pour les appareils Android sur lesquels la messagerie directe est activée, si l'appareil ne s'est pas connecté à FCM depuis plus d'un mois, FCM accepte toujours le message, mais le supprime immédiatement. Si l'appareil se connecte dans les quatre semaines suivant le dernier message de données que vous lui avez envoyé, votre client reçoit le rappel onDeletedMessages(). L'application peut alors gérer la situation de manière appropriée, généralement en demandant une synchronisation complète au serveur d'application.
Enfin, lorsque FCM tente de distribuer un message à l'appareil et que l'application a été désinstallée, FCM supprime immédiatement ce message et invalide le jeton d'enregistrement. Toute tentative ultérieure d'envoi d'un message à cet appareil génère une erreur NotRegistered.