Les notifications push permettent d'envoyer des messages depuis un serveur vers les smartphones en passant par le réseau data. Contrairement aux SMS, les notifications peuvent enrichir l'expérience utilisateur en ajoutant du contenu riche comme de l'audio ou des images.
Dans cet article, nous présenterons les notifications push et ferons une comparaison de leur utilisation sur les trois principales plateformes mobiles :
Une notification n'est rien d'autre que des données transmises à un smartphone. Elle est liée à une application et elle est capable de réveiller cette dernière. En général, la réception du message s'effectue en quelques secondes mais n'est pas garantie.
Toutes les plateformes mobiles disposent de leur propre mécanisme de notifications.
Ainsi, l'envoi de notifications requiert de passer par ces plateformes :
Les notifications push offrent les avantages suivants :
Cependant l'utilisation des notifications impose certaines recommandations :
Par exemple Facebook permet à l'utilisateur de choisir sur quoi il désire être notifié
De même Le Monde propose à l'utilisateur de choisir le type d'information qu'il souhaite recevoir par notification (l'essentiel d'un article ou l'intégral)
Les notifications push sont souvent utilisées pour
Lorsque l'on souhaite mettre en place du push, il est nécessaire de monter un serveur de notifications. L'architecture standard que l'on retrouve est la suivante :
Il y a 3 types de notifications sur iOS :
Apple ne garantit pas la réception d'une notification, ni l'ordre d'arrivée des messages.
Il faut savoir que si l'utilisateur est en train d'utiliser l'application lorsqu'une notification arrive, il n'y aura aucune alerte d'affichée, aucun badge mis à jour et aucun son joué. Et ceci même si l'appareil est verrouillé. Cependant l'application est capable d'intercepter la notification et de la traiter.
Lorsqu'une application utilise les notifications, l'utilisateur doit accepter de recevoir ces messages. Une popup s'affiche afin de demander l'autorisation.
Si l'utilisateur accepte, la demande du device token est émise à Apple automatiquement. Si l'utilisateur refuse, l'application n'est pas en mesure de recevoir de notifications push. La seule manière de pouvoir changer cette configuration pour l'utilisateur, est d'aller dans les paramètres du téléphone et d'activer le push.
L'utilisateur est également en mesure de pouvoir configurer la notification :
Pour recevoir les notifications l'appareil doit effectuer une requête à APNS pour récupérer un device token. Ce token permettra par la suite de lui envoyer des messages. Un device token iOS ressemble à :
D8959FC15D6120302HABC240284B2349D3E52662074F137199BAE5C7E117CCF5
APNS fournit une interface pour envoyer des notifications vers les iPhones/iPads/iPods. Il s'agit d'une communication TCP socket.
Cependant cette interface a certaines limitations :
Afin de pouvoir envoyer des notifications, il faut disposer d'un certificat qu'il faut créer depuis le Provisioning Portal d'Apple. Il est :
Le serveur de push est en charge de générer la notification dans le format demandé par APNS. Une notification est composée d'un device token (qui identifie l'appareil visé) et d'un payload (correspondant aux données).
Le payload doit être un dictionnaire JSON de la forme :
{
"aps":
{
"alert": "Hello, world!",
"sound": "default”
}
}
Bien entendu d'autres clés peuvent être ajoutées afin de configurer la notification mais je vous renvoie vers la documentation officielle pour les découvrir.
Il est également possible d'envoyer des données personnalisées dans le payload afin de transmettre des informations à l'application (ex : l'id d'un produit à afficher lorsque l'application sera ouverte depuis la notification).
{
"aps":
{
"alert": "Hello, world!",
"sound": "default”
},
"product_id":1234
}
Deux situations sont à prendre en compte :
Lorsqu'une application est désinstallée, elle n'est plus en mesure de recevoir des notifications. Afin d'arrêter d'essayer d'envoyer des messages à des appareils n'étant plus capables de répondre, APNS fournit un service pour connaitre la liste de ces appareils. Le serveur de push doit régulièrement interroger APNS pour récupérer cette liste de tokens et la maintenir à jour.
iOS 7 introduit un nouveau type de notification, il s'agit des notifications silencieuses. Désormais il est possible d'envoyer une notification à une application sans avoir la popup qui s'affiche. Ainsi l'utilisateur n'a aucun action à faire, la notification est invisible et l'application l'intercepte. L'application se voit attribuée un temps durant lequel elle est capable de télécharger des données et enfin d'en informer l'utilisateur.
GCM permet à un serveur tiers d'envoyer des notifications aux différents appareils Android qui ont été préalablement enregistrés. Cependant Android ne fournit aucune interface utilisateur de base pour afficher les messages reçus. L'application est en charge de fournir les composants nécessaires pour afficher la notification.
Par exemple, il est possible de générer des vues riches pour les messages qui seront affichés dans la barre de notifications :
De même il n'y a aucune garantie au sujet de la réception de la notification, il s'agit d'une offre en "best-effort".
Afin de pouvoir recevoir des notifications, il faut être au minimum sur la version 2.2 d'Android et d'avoir l'application Google Play Store.
Un très bon article de Jérôme Van Der Linden et Cédrick Lunven explique comment mettre en place la partie cliente et le serveur push sous Android
L'utilisateur est en mesure de pouvoir désactiver les notifications en allant dans les paramètres de l'application. Cependant cette fonctionnalité n'est disponible que pour les appareils fonctionnant sous Android 4.1+.
Pour envoyer des notifications à un appareil, il faut que l'application s'enregistre auprès de GCM afin d'obtenir un registration id. Ce token se présente sous la forme suivante :
APA91bGMHZnfrLNjvrvsnlNLNZPPMLnnvmn70nnlen13xbPb6OnwXtDtNWPjn19o_TFZ
iHwqTYJJl-vhmaTd_uhSM-DBRgpoa993bj0rnei1wjI-9Wn7YnzQehXg7M30OmYQyna_
cRo9l4qHL5rLj_fJTPEb6G0-NA
Les communications avec le GCM s'effectuent directement par des requêtes HTTPS. Le serveur de push est en mesure d'envoyer un message à un unique appareil ou à un ensemble d'appareils (dans une limite de 1000 tokens par requête).
Le format des données peut être soit du plain/text (fonctionne seulement pour l'envoi vers un appareil unique), soit du JSON.
Exemple de requête CURL pour envoyer une notification
curl
-X POST
-H "Authorization:key=MY_API_KEY"
-H "Content-Type: application/json"
--data '{
"registration_ids":["DEVICE_REGISTRATION_ID"],
"data":{"productId":"400"}
}'
https://android.googleapis.com/gcm/send
Résultat de la requête.
{
"multicast_id":5043079104923827512,
"success":1,
"failure":0,
"canonical_ids":0,
"results":[
{"message_id":"0:1368194022851940%e2c9f46df9fd7ecd"}
]
}
Le serveur de push est en charge de générer la notification dans le format demandé par GCM.
Il existe deux grands types de notification sous Android :
Une notification Android (multicast) est composée :
Par exemple :
{ "collapse_key": "score_update",
"time_to_live": 108,
"delay_while_idle": true,
"data": {
"score": "4x8",
"time": "15:16.2342"
},
"registration_ids":["4", "8", "15", "16", "23", "42"]
}
Le cycle de vie des notifications sous Android est complexe.
Il faut considérer 3 cas :
L'état des tokens Android est connu lorsque l'on exécute la requête HTTP pour envoyer une notification. En effet, nous avons en réponse une liste permettant d'avoir des informations pour chacun des appareils qui devait recevoir la notification. Il s'agit de l'erreur "Unregistered Device" pouvant survenir dans les cas suivants :
Il existe 3 types de notifications sur Windows Phone :
Cette notification se situe sur l'écran principal du smartphone et permet d'avoir des informations comme un flux avec différents types de templates (circle, flip, iconic). Par exemple avec le template flip nous avons une notification qui dispose d'un avant et d'un arrière, comme dans facebook qui devant (à droite) affiche son icône et derrière (à gauche) affiche le dernière message sur son mur.
Contrairement au "tile", le "toast" peut être affiché à n'importe quel endroit où se situe l'utilisateur. En effet il s'agit d'une notification simple permettant à l'utilisateur d'être informé d'un évènement (ex : "une demande d'ajout sur facebook"). Si l'utilisateur clique sur le "toast", il est automatiquement redirigé vers l'application associée.
Cette notification ne fonctionne que si l'application est actuellement lancée et permet de lui envoyer des données (JSON, XML, ...). Ces données doivent être traitées par l'application puis affichées au besoin à l'utilisateur.
Contrairement aux deux plateformes précédentes, Microsoft n'offre pas la possibilité d'activer/désactiver les notifications pour un utilisateur. Cependant il est recommandé d'implémenter ce mécanisme à l'intérieur même de l'application et de sauvegarder le choix de l'utilisateur afin de lui envoyer ou non des messages par push.
Par exemple Twitter demande la première fois à l'utilisateur s'il souhaite recevoir des notifications. Puis il fournit une page de paramètrage afin de les activer ou les désactiver.
Lorsque l'appareil s'enregistre auprès de Microsoft pour recevoir les notifications, une URI est générée représentant à canal ("channel") vers ce smartphone. C'est cette URI qui permet d'envoyer les notificatons, elle se présente sous la forme :
http://sn1.notify.live.net/throttledthirdparty/01.00/AAJZivnlZofnRpn
5NOxvwSxPAgHDHZADAgAAAAQUZm627hJCMjg1QTg1QkZDMkUxREQ
Il suffit tout simplement d'effectuer une requête POST vers l'URI de l'appareil avec les données nécessaires. Puis MPNS se chargera d'envoyer la notification au smartphone.
Pour envoyer des notifications WP8 l'authentification auprès de MPNS n'est pas obligatoire. Cependant, l'envoi de ces notifications sans être authentifié a quelques limitations :
Ainsi, il est recommandé d'utiliser un certificat (généré depuis Windows Marketplace) afin d'établir une connexion SSL entre le serveur de notifications et MPNS.
Comme présenté précédemment il existe 3 types de notifications sous Windows Phone : Tile, Toast et Raw.
Une "tile" dispose de différentes propriétés comme un titre et une image de background (devant et derrière) mais aussi un contenu et un badge. Microsoft propose 3 templates dans différentes tailles (small, medium et wide).
Ces différents templates sont disponible seulement sur Windows Phone 8. Cependant Microsoft propose un template pour Windows Phone 7.1, il s'agit du même template que le "flip" sur WP8 mais dans une taille unique.
Pour envoyer une notification "Tile", il faut fournir dans la requête une représentation en XML.
Ci-dessous un exemple pour WP7.1
<?xml version="1.0" encoding="utf-8"?>
<wp:Notification xmlns:wp="WPNotification">
<wp:Tile>
<wp:BackgroundImage>/assets/images/background.png</wp:BackgroundImage>
<wp:Count>3</wp:Count>
<wp:Title>Notification WP7.1</wp:Title>
<wp:BackTitle>Back notification WP7.1</wp:BackTitle>
<wp:BackContent>Ceci est une notification</wp:BackContent>
</wp:Tile>
</wp:Notification>
Ci-dessous un exemple pour WP8 avec un template "flip"
<?xml version="1.0" encoding="utf-8"?>
<wp:Notification xmlns:wp="WPNotification" Version="2.0">
<wp:Tile Id="[Tile ID]" Template="FlipTile">
<wp:SmallBackgroundImage>/assets/images/smallbackground.png</wp:SmallBackgroundImage>
<wp:WideBackgroundImage>/assets/images/widebackground.png</wp:WideBackgroundImage>
<wp:WideBackBackgroundImage>/assets/images/widebackbackground.png</wp:WideBackBackgroundImage>
<wp:WideBackContent>Ceci est une notification (wide Tile size)</wp:WideBackContent>
<wp:BackgroundImage>assets/images/background.png</wp:BackgroundImage>
<wp:Count>4</wp:Count>
<wp:Title>Notification WP8</wp:Title>
<wp:BackBackgroundImage>/assets/images/backBackground.png</wp:BackBackgroundImage>
<wp:BackTitle>Back notification WP8</wp:BackTitle>
<wp:BackContent>Ceci est une notification (medium Tile size)</wp:BackContent>
</wp:Tile>
</wp:Notification>
Un "toast" dispose seulement d'un titre et d'un sous-titre.
<?xml version="1.0" encoding="utf-8"?>
<wp:Notification xmlns:wp="WPNotification">
<wp:Toast>
<wp:Text1>Titre</wp:Text1>
<wp:Text2>Sous titre</wp:Text2>
<wp:Param>/Page2.xaml?NavigatedFrom=Toast Notification</wp:Param>
</wp:Toast>
</wp:Notification>
Dans l'exemple précédent, nous pouvons constater également un paramètre "Param", il permet de fournir une URL vers une page de l'application qui sera ouverte lorsque l'utilisateur cliquera sur la notification. Ainsi au travers de cette URL, nous sommes capables de transmettre des données que l'application pourra traiter.
Le dernier type de notification "raw" ne fonctionne que si l'application est actuellement lancée. Il permet de transmettre via push des données à l'application. Ces données peuvent être dans n'importe quel format (JSON, XML, ...) puisque c'est à l'application d'être capable de les traiter afin de s'en servir par la suite.
Lors de la requête HTTP pour notifier un appareil, il est possible de fournir différentes informations dans le header :
Pour plus d'informations, je vous renvois sur cette page.
Contrairement aux deux plateformes précédentes, Windows permet de connaître l'état de la notification et de l'appareil. En effet en analysant la réponse de la requête et son status, nous sommes capables de connaitre différentes informations.
La réponse retourne 5 types d'informations :
Microsoft donne toutes les informations ainsi que les cas possibles sur cette page.
Pour résumer les notifications push sur les 3 plateformes principales, je vous propose un tableau récapitulatif :
Les notifications push sur mobile est un sujet qui peut paraître simpliste au départ mais en réalité on se rend compte que chaque plateforme a son propre système de notifications, ses propres formats et ainsi ses propres contraintes.
Mettre en place son serveur de notifications requiert de traiter toutes les contraintes selon les plateformes mais également de devoir maintenir à jour la liste des tokens des appareils.
Depuis plusieurs années, des solutions en SaaS permettent de gérer les notifications push selon les plateformes. Les avantages de ces solutions sont :
Quelques exemples de solutions :