Etat de l'art du push sur iOS, Android et Windows Phone

le 05/11/2013 par Cédric Pointel
Tags: Software Engineering

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 :

  • iOS
  • Android
  • Windows Phone

Vue d'ensemble des notifications push

Qu'est ce qu'une notification ?

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 :

  • iOS : Apple Push Notification Service (APNS)(version OS >= 3.0)
  • Android : Google Cloud Messaging (GCM)(version OS >= 2.2)
  • Windows Phone : Microsoft Push Notification Service (MPNS)(version OS >=7)

Avantages des notifications

Les notifications push offrent les avantages suivants :

  • Des messages ciblés à un utilisateur
  • Des notifications contextuelles basées selon des critères
  • Un lien direct avec les utilisateurs

Cependant l'utilisation des notifications impose certaines recommandations :

  • Les messages envoyés doivent être pertinents
  • Laisser le choix à l'utilisateur d'activer/désactiver les notifications
  • Pouvoir personnaliser les notifications (fréquence, plage d'horaire de réception, type d'information)
  • Ne pas utiliser ce mécanisme pour faire du spam
  • Ne pas utiliser les notifications pour faire transiter des données sensibles

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

  • Les alertes des réseaux sociaux (ex : un nouveau tweet, une publication sur Facebook, un nouveau contact sur Viadeo, ...)
  • Les alertes sur la météo (ex : le bulletin météo, les préventions d'avalanches, ...)
  • Les alertes de variation (ex : le solde de mon compte, la valeur d'une action, ...)
  • Les alertes sportives (ex : les résultats des matches, ...)
  • Les actualités (ex : le taux du chômage est en hausse, la réforme des retraites, ...)
  • Les alertes sur le traffic (ex : un bouchon sur le périphérique, un accident sur une ligne de métro, ...)

Architecture

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 :

  • L'application demande au serveur de sa plateforme un token permettant d'identifier l'application sur un appareil donné
  • L'application envoie le token au serveur de notifications
  • Le serveur de notifications doit sauvegarder en base les différents tokens
  • Le serveur émet une requête de notification à la plateforme ciblée (un message + un token)
  • La plateforme se charge d'envoyer la notification sur le smartphone
  • Le serveur de notification doit s'assurer de maintenir une liste de tokens à jour (désinstallation de l'application, désactivation des notifications, ...)

iOS : Apple Push Notification Service

Présentation

Il y a 3 types de notifications sur iOS :

  • Un message d'alerte
  • Un badge situé sur l'icône de l'application
  • Un son (à condition que le fichier audio soit déjà présent au sein de l'application)

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 :

  • activer l'affichage dans le centre de notification
  • spécifier le nombre maximal de notifications à afficher dans le centre de notifications
  • configurer le style de l'alerte affichant le message (popup, bannière, aucun)
  • afficher le badge sur l'icône de l'application
  • jouer un son lors de la réception de la notification
  • activer l'affichage sur l'écran de verrouillage

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

Côté serveur

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 :

  • lors de l'envoi de plusieurs notifications sur une courte période de temps, APNS enverra vers l'appareil seulement la dernière notification
  • la taille du message est limitée à 256k max

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 :

  • limité à l'application
  • limité à un environnement (développement ou production)

Qu'est ce qu'une notification iOS ?

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
}

Le cycle de vie d'une notification

Deux situations sont à prendre en compte :

  • l'appareil est connecté au réseau : le serveur de notification envoie un message à APNS, la notification est instantanément délivrée.
  • l'appareil est déconnecté : le message est sauvegardé sur les serveurs APNS jusqu'à ce que l'appareil soit de nouveau connecté. Cependant APNS sauvegarde seulement une seule notification par application pour un appareil donné. L'ancien message est automatiquement remplacé par le nouveau. De plus APNS ne retient pas le message de façon indéterminée, au bout d'un certain temps le message peut être supprimé. Malheureusement cette durée n'est pas connue mais d'après PCWorld.com en 2009 la durée serait de 28 jours.

Le service de feedback

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.

La nouveauté avec iOS 7

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.

Google Cloud Messaging

Présentation

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

Côté serveur

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"}
     ]
}

Qu'est ce qu'une notification Android ?

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 :

  • Send-to-sync
    • Les notifications dîtes "collapsed" : où chaque nouveau message remplace le précédent.
    • Il s'agit de notifications permettant d'informer l'application de synchroniser des données (par exemple : les mails)
    • GCM permet d'avoir maximum 4 clés différentes dans ce type de notification (ex : "newMail", "updatesAvailable", ...)
  • Les messages avec "payload"
    • Les notifications "not collapsed" : où chaque message sera délivré sur l'appareil
    • Il s'agit ici de notifications avec des données envoyées par ce mécanisme.

Une notification Android (multicast) est composée :

  • D'une liste de "registration_ids" correspondant à l'ensemble des appareils Android qui doivent recevoir la notification (max : 1000 par requête)
  • D'une clé appelée "collapse_key" permettant de faire une distinction entre les notifications "Send-to-sync" et les messages avec payload
  • D'un booléen "delay_while_idle" permettant de garder la notification sur les serveurs de GCM tant que l'appareil n'est pas "actif"
  • D'un "time_to_live" correspondant à la durée de sauvegarde de la notification sur les serveurs de GCM (une valeur en secondes pouvant aller de 0 à 4 semaines)
  • Et des données à transmettre dans la notification

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 d'une notification

Le cycle de vie des notifications sous Android est complexe.

Il faut considérer 3 cas :

  • L'appareil est connecté au réseau et actif
    • La notification est délivrée instantanément
  • L'appareil est connecté au réseau et inactif (IDLE)
    • Le paramètre "delay_while_idle"=false : la notification est délivrée instantanément
    • Le paramètre "delay_while_idle"=true + collapsed : la notification est sauvegardée sur les serveurs de GCM. Si une nouvelle notification arrive, elle remplacera l'ancienne jusqu'à ce que l'appareil soit de nouveau actif pour délivrer la notification.
    • Le paramètre "delay_while_idle"=true + not collapsed : la notification est sauvegardée sur les serveurs de GCM. Les nouvelles et anciennes notifications sont stockées jusqu'à ce que l'appareil soit de nouveau actif. GCM permet de stocker jusqu'à 100 messages différents, une fois cette limite dépassée, tous les messages sont supprimés et un message particulier sera généré afin de traiter ce cas côté application
  • L'appareil n'est pas connecté au réseau
    • Les mêmes règles que "Appareil connecté et inactif" lorsque "delay_while_idle"=true s'appliquent jusqu'à ce que la connection soit de nouveau rétablie.
    • Une fois la connection établie, GCM délivre toutes les notifications en attente à l'appareil en fonction de l'état du flag "delay_while_idle"

Le service de feedback

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 :

  • Si l'utilisateur a désactivé les notifications pour cette application
  • Si l'application a été désinstallé
  • Si le registration_id a expiré
  • Si l'application a été mise à jour et que cette nouvelle version n'intègre plus de receveur pour la notification

Microsoft Push Notification Service

Présentation

Il existe 3 types de notifications sur Windows Phone :

  • Tile

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.

  • Toast

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.

  • Raw

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

Côté serveur

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 :

  • 500 messages max par application et par channel
  • Aucune URL de callback n'est possible dans ce mode

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.

Qu'est ce qu'une notification WP8

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 :

  • Une message ID : permettant de spécifier un ID à la notification
  • Un type de notification parmi : "Toast", "Tile et "Raw"
  • Une durée au bout de laquelle la notification sera envoyée par MNPS vers l'appareil (une valeur parmi : "immédiatement", "au bout de 450s" ou "au bout de 900s")
  • Une URL de callback permettant de récupérer des messages lorsque certains évènements se produiront

Pour plus d'informations, je vous renvois sur cette page.

Feedback service

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 :

  • Le code de réponse de la requête (ex : 200 OK, 404 Not found, 412 Precondition failed, ...)
  • Le message id associé à cette notification
  • Le status de la notification (received / dropped / queuefull)
  • Le status de la connexion avec le smartphone (connected, inactive, disconnected >24h, tempDisconnected <24h)
  • Le status de la subscription du smartphone (active, expired)

Microsoft donne toutes les informations ainsi que les cas possibles sur cette page.

Conclusion

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 :

  • les notifications sont unifiées
  • les formats des notifications selon la plateforme sont gérés par la solution
  • la maintenance de la liste des tokens est effectuée par la solution
  • possibilité de programmer l'envoi des messages à une date donnée
  • possibilité d'obtenir des analytics sur l'envoi/l'ouverture des notifications par les utilisateurs

Quelques exemples de solutions :