Avril 2016

Volume 31 numéro 4

Cet article a fait l'objet d'une traduction automatique.

À la pointe : renvoi des notifications vers les applications mobiles

Par Dino Esposito | Avril 2016

Dino EspositoDans Mes derniers articles, j'ai écrit principalement sur l'architecture et de conception de logiciels. Bien que le rôle de l'architecture de la création d'un système logiciel ne doit jamais être sous-estimée, ou refusé, n'importe quelle application dans le résultat final de la somme des fonctionnalités individuelles. Il s'agit du même utilisateur expérience pilotée par développement (UXDD) philosophie qui indique les mesures de réussite pour une application logicielle se trouve dans l'expérience de l'utilisateur parcourt lorsqu'elle porte sur l'application. Si votre système logiciel comprend un front end mobile, puis difficilement, vous pouvez ignorer une fonctionnalité tels que des notifications push.

Dans cet article, je résumerai ce qui est nécessaire pour ajouter une couche de notification sur des applications mobiles, quel que soit le système d'exploitation mobile lui-même. Dans ce cas, je vais examiner les services de la plateforme Microsoft Azure Notification Hub.

Un coup de œil les Notifications push

Une notification de transmission est lorsqu'un périphérique mobile reçoit un message à partir du serveur principal de l'application sans l'envoyer une demande explicite. La plupart des interactions entre les composants client et serveur d'une application sont dus à une action explicite, en règle générale, une action de l'utilisateur, qui sollicite les commentaires. Dans une certaine façon, une notification de transmission est une sorte de commentaires non sollicité, un message que le serveur principal envoie lorsque certaines informations essentielles ne sont disponibles. Pour être précis, le terme « non sollicité » n'est pas complètement précis ici. N'importe quelle application mobile doit s'abonner au flux disponible afin de recevoir des notifications push. Toutefois, une fois abonné au service, des notifications arrivent de manière non sollicitée.

L'effet net de notifications push sur un utilisateur est la distribution de mises à jour appropriées ou non il est activement à l'aide de l'application. Par exemple, l'installation les application d'un airliner probablement vous permet de recevoir rapides et en temps voulus des mises à jour sur les modifications de planification et de la porte. À un moment donné votre téléphone émet un signal sonore ou un terme et commentaires visible apparaît quelque part sur l'interface du téléphone. Où exactement il apparaît toutefois, strictement dépend de la version du système d'exploitation sur lequel repose votre appareil, ainsi que les paramètres utilisateur et de configuration de l'application. Selon le système d'exploitation, une notification push peut prendre la forme d'une icône dans la barre supérieure, un message toast, une mise à jour de badge et ainsi de suite.

Le point crucial de notifications push est que tous leurs aspects techniques sont rigoureusement spécifique à la plateforme. Par exemple, le moyen de qu'une application s'abonne à un service de notification push est différent dans les applications Universal Windows Platform (UWP), iOS, Android et Windows Phone. De même, chaque plateforme utilise sa propre surcharge pour remettre des messages pour les périphériques connectés et chaque plateforme, vous devez configurer un autre moteur de distribution. En dépit de différences significatives dans l'implémentation réelle, utiliser dire que l'architecture globale d'un système de notification push (PNS) est assez courante et l'aspect du diagramme dans Figure 1.

Architecture globale d'un système de Notification spécifique à la plateforme Push
Figure 1 Architecture globale d'un système de Notification spécifique à la plateforme Push

Utilisation de plusieurs systèmes de Notification Push

Il est fourni en tant qu'aucune surprise reflétant la diversité des plateformes mobiles existent également dans une variété de plateformes de notification push. Un développeur crée une application mobile pour plusieurs plateformes doive se familiariser avec plusieurs moteurs de notification push différents et devez configurer un environnement de serveur approprié pour chaque. Sauf si vous développez une application pour une plate-forme mobile sans plan prévisible pour le port à d'autres plates-formes, vous pouvez souhaiter étudier PNSes inter-plateformes, comme indiqué dans Figure 2. Comparaison du diagramme dans Figure 1, la nouvelle architecture ajoute une autre couche et offre un point d'entrée unique pour la programmation.

Architecture globale d'un système de Notification Push interplateforme
Figure 2 Architecture globale d'un système de Notification Push interplateforme

L'application mobile inscrit avec le concentrateur de notification générique push et back-end de l'application des messages de files d'attente sur le concentrateur. Ensuite, le concentrateur remet les messages physiques à la plateforme mobile spécifique à l'aide du protocole approprié et la charge utile. À l'aide d'un de ces systèmes de notification mobile interplateforme, vous pouvez utiliser une seule API pour transmettre les messages aux appareils Android, iOS et Windows Phone dans un seul plan.

Le concentrateur de Notification Azure est une de ces systèmes multiplates-notification. Voyons comment cela fonctionne.

Le concentrateur de Notification Azure

La première étape pour utiliser le concentrateur de Notification Azure consiste à configurer un plan d'Azure. Le service est proposé dans trois niveaux, la plus petite qui est gratuit et définit une limite du nombre de périphériques est accessibles (500) et notifications maximales, que vous pouvez envoyer (1 million). Pour plus d'informations, reportez-vous à bit.ly/1Tbimew. Pour commencer, il vous suffit d'un compte gratuit pour créer un concentrateur de Notification et un espace de noms qu'elle contient. Cette information est utile ultérieurement pour établir la connexion à partir principale de l'application pour les messages de file d'attente pour les périphériques.

La partie la plus lourde de l'utilisation des notifications push n'est pas affaire à un concentrateur inter-plateformes, mais répondant aux exigences de chaque plate-forme mobile que vous souhaitez atteindre. Par exemple, pour fournir des mises à jour pour les appareils Android ou iOS, vous devez tout d'abord entièrement configurer vos applications avec le PNSes natif respectifs. Pour plus d'informations, consultez la page bit.ly/1o15uv2. Comme vous le savez peut-être, les applications iOS inscrits uniquement recevoir les notifications push. Pour inscrire votre application avec le Service de Notification Push Apple natif, vous devez tout d'abord obtenir un certificat auprès d'Apple qui a pour but d'identifier de manière unique les notifications provenant de votre application. La même tâche pour Android nécessite à la place une clé d'API que vous obtenez via l'interface d'Android Studio. Pour les applications UWP, vous devez d'abord inscrire auprès du Windows Store. Toutes les étapes propres à la plate-forme doivent être accomplies pour toutes les plateformes que vous avez l'intention de prendre en charge. Des informations d'inscription doivent être entrées dans le concentrateur de Notification Azure, agir au nom de votre en ce qui concerne le PNSes natif.

L'inscription de l'Application avec le Hub

Supposons que vous maintenez un fichier .p12 du certificat et un profil de configuration mis à jour pour votre application iOS qui a activé pour recevoir des notifications à partir du système d'Apple. Vous êtes principalement effectuée si vous n'utilisiez le concentrateur de Notification Azure. Doit utiliser un système hub intermédiaires vraiment ?

Le point est que n'importe quel PNS spécifique à la plateforme laisse beaucoup de travail pour le développeur effectuer les tâches couramment demandées comme simple diffusion à tous les appareils connectés ou uniquement à certains groupes d'utilisateurs tels que ceux qui utilisent le périphérique dans les paramètres régionaux particuliers. La diffusion, en particulier, n'est pas une tâche facile car il peut engendrer des problèmes d'évolutivité importante lorsque le nombre de périphériques augmente. C'est la raison pour laquelle une infrastructure évolutive au milieu qui sépare spécifique à la plate-forme principale services à partir du code d'écriture est un atout considérable. Pour utiliser le concentrateur de Notification Azure, cependant, vous devez également télécharger le certificat .p12 Apple et par programmation inscrire votre application avec le concentrateur d'Azure. Si vous utilisez Xamarin.iOS pour écrire l'application iOS, un excellent didacticiel pas à pas est bit.ly/1KaySJ3.

L'application mobile a deux responsabilités principales. Tout d'abord, elle doit incorporer du code qui s'abonne à la notification Azure flux. Deuxièmement, il doit inclure le code pour traiter d'une certaine façon, les notifications entrantes. Une application iOS physiquement reçoit des notifications push à partir du service Apple il doit y abonner. Cela s'effectue via la méthode UIApplication.SharedApplication.RegisterForRemoteNotifications. En quittant, cette méthode appelle une méthode substituable dans la classe de délégué d'application nommée RegisteredForRemoteNotifications. Ici, vous vous abonnez au concentrateur Azure. Cette méthode reçoit le jeton de périphérique du système d'exploitation et votre code transfère simplement au concentrateur. Le concentrateur Azure est identifié par une chaîne de chemin d'accès et de connexion, comme suit :

var hub = new SBNotificationHub(connectionString, hubPath);
hub.RegisterNativeAsync(deviceToken, null);

Ensuite, lorsqu'une notification est reçue en fait, une autre méthode substituable dans la classe du délégué d'application est appelée : ReceivedRemoteNotification. La méthode reçoit le contenu réel du message transmise sous la forme d'un dictionnaire de chaînes (éventuellement imbriquée) du système d'exploitation. Le remplacement de méthode est responsable de l'extraction du message proprement dit et de les afficher à tout ce qui fonctionne pour l'application: badge, audio ou d'alerte.

Files d'attente de Messages au concentrateur Azure

Tout le travail effectué jusqu'ici est que la moitié de l'effort. Ce qui reste est de déterminer comment envoyer des messages au concentrateur Azure et à partir de là, les périphériques connectés. En d'autres termes, vous devez disposer d'une application back-end qui connaît les informations de connexion de concentrateur et transmet le message pour l'utilisateur. Telle une application back-end peut être tout type d'application .NET, y compris une application ASP.NET. Si vous avez une raison d'une application mobile recevoir des notifications push, quelque chose dans le domaine d'entreprise est générer les messages connexes. Il peut être un déclencheur de logiciels pour envoyer un message ou il peut être l'action d'un utilisateur administrateur, comme indiqué dans Figure 3.

Un ASP.NET Back-End pour envoyer des Messages spécifiques à un iOS et Android application Via le concentrateur Azure
Figure 3 un ASP.NET Back-End pour envoyer des Messages spécifiques à un iOS et Android application Via le concentrateur Azure

Pour incorporer des notifications push dans un back-end ASP.NET, il vous suffit du package Nuget Microsoft Azure notification hubs. En outre, votre code est responsable de la construction de la chaîne de connexion correcte. Une chaîne de connexion contient des informations sur le point de terminaison Azure Service Bus URL connexe et un jeton chiffré. Le point de terminaison de Service Bus contient le nom de l'espace de noms que vous avez créé lorsque vous configurez le service Azure. Il est quelque chose comme sb://your-ns.servicebus.windows.net. Le jeton chiffré est lu à partir de la page configuration de votre espace de noms sous l'étiquette « Chaîne de connexion ». Voici le code que vous devez créer une instance de concentrateur valide :

var hub = NotificationHubClient.CreateClientFromConnectionString(
  connString, hubName);

L'étape suivante consiste à créer la charge utile appropriée pour chacune des plateformes à cibler. La charge utile est une chaîne JSON qui suit un modèle fixe. Vous pouvez générer la chaîne JSON comme vous le souhaitez. Dans l'exemple suivant, le $ est un espace réservé pour le message réel à envoyer :

const string iosFormat = "{\"aps\":{\"alert\":\"$\"}}";
const string androidFormat = "{\"data\":{\"message\":\"$\"}}";
var iosAlert = iosFormat.Replace("$", actualMessage);
var androidAlert = androidFormat.Replace("$", actualMessage);

Une fois que la charge utile est construite, l'envoyer vers le concentrateur est aussi simple que le code suivant :

var task1 = hub.SendAppleNativeNotificationAsync(iosAlert);
var outcome1 = task1.Result;
var task2 = hub.SendGcmNativeNotificationAsync(androidAlert);
var outcome2 = task2.Result;

Les variables de résultat dans l'extrait de code sont des instances du type NotificationOutcome et retournent des informations détaillées sur le résultat de l'opération.

Envoi de Messages basés sur le modèle

L'exemple de code précédent illustre simplement la façon la plus simple d'envoyer des notifications push, une simple chaîne de texte qui sera diffusée inchangée sur les appareils connectés. En outre, vous devez mettre en forme pour chaque plate-forme mobile d'intérêt. Un scénario plus courant est l'envoi de messages basé sur le modèle. Remise d'un message basé sur le modèle dans Azure sous la forme d'un dictionnaire de chaîne et le concentrateur Azure permet de s'assurer qu'il est remis à n'importe quelle plateforme mobile, que le compte est configuré. L'idée derrière les messages basés sur le modèle est que l'application a l'intention d'utiliser un format plus riche que celui par défaut. Par exemple, nous allons voir comment envoyer des messages différents utilisateurs suivant différents paramètres régionaux :

var locale = "EN";
var template = String.Format("{{\"aps\":{{\"alert\":\"$(News_{0})\"}}}}", locale);

L'exemple montre le modèle à enregistrer avec le PNS Apple tout message entrant en fonction de modèle nommé News_XX, où XX est les deux premières lettres d'un paramètre régional. Grâce à des modèles ici est que l'application principale peut envoyer plusieurs entrées dans un dictionnaire unique, mais chaque périphérique reçoit le message pour lequel il est enregistré uniquement. Il s'agit juste un des services supplémentaires mis un concentrateur intermédiaire, tels que le concentrateur de Notification Azure. Pour envoyer des messages spécifiques aux paramètres régionaux, vous devez le code suivant :

var messages = new Dictionary<string, string>
{
  {"News_EN", "..."},
  {"News_ES", "..."},  {"News_PT", "..."},
  {"News_IT", "..."}
};var task = hub.SendTemplateNotificationAsync(messages);
var outcome = task.Result;

Avec une commande unique, vous atteignez périphériques plates-formes avec la garantie que chaque utilisateur ne voit simplement la notification appropriée pour les paramètres régionaux qu'il a sélectionné sur le téléphone. Notez qu'il s'agit d'une fonctionnalité légèrement différente de localisation automatique des messages qui n'est disponible, par exemple, sur des appareils iOS. Sur les appareils iOS, en fait, vous pouvez envoyer des messages avec un espace réservé qui correspond à des entrées dans le dictionnaire de chaînes localisées et le système d'exploitation la magie de traduire automatiquement le message avant l'appel de l'alerte. Messages de modèle sont à la place, une fonctionnalité Azure qui vous permet d'envoyer des messages différents à segmenté les groupes d'utilisateurs et vous décider comment segmenter les groupes d'utilisateurs.

Messages planifiés

Une autre fonctionnalité intéressante que vous trouverez dans le concentrateur de Notification Azure concerne les messages planifiés. Messages planifiés sont des notifications mis à Azure et envoyés aux périphériques connectés uniquement à un moment donné. Pour envoyer des notifications planifiées que vous utilisez uniquement une API légèrement différente :

var notification = new TemplateNotification(messages);
var task = hub.ScheduleNotificationAsync(notification, new DateTime(...));
var outcome = task.Result;

Il est important de noter que les notifications planifiées exigent un abonnement de niveau Standard et ne sont pas disponibles dans l'abonnement d'essai gratuit.

Un bon citoyen

Au-delà des simples aspects techniques de comment enregistrer et envoyer des notifications push via le concentrateur d'Azure, le point très pénible de notifications push est leur utilisation dans le cadre d'une communication avec l'utilisateur.

Vous ne souhaitez pas l'utilisateur avec notifications d'information brutes des bogues en permanence. Car il s'agit d'une notification de « push », que vous souhaitez rendre qu'il y a un intérêt réel de l'utilisateur dans poussé. À cet égard, segmentés groupes d'utilisateurs sont une fonctionnalité intéressante sur laquelle s'appuient. La taille du message est trop important. Je vous suggère de que vous rendre n'importe quel message proche de la taille d'un tweet. Jusqu'à iOS 8, par exemple, la taille maximale des notifications push a été 256 octets et ont augmenté de 2 Ko dans les systèmes plus récents. Il est de 4 Ko sur Android. La dernière, mais pas des moindres, assurez-vous que le système d'exploitation que vous ciblez facilite la totalité de cette fonctionnalité pour annuler l'abonnement. C'est surtout vrai avec les systèmes d'exploitation plus récent, mais il vaut mieux à double contrôle.


Dino Espositoest l'auteur de « Microsoft .NET : Conception d'Applications pour l'entreprise » (Microsoft Press, 2014) et « Applications Web modernes avec ASP.NET » (Microsoft Press, 2016). Un développeur technique pour les plateformes .NET et Android chez JetBrains, dans le monde entier manifestations du secteur, Esposito partage sa vision du logiciel à software2cents@wordpress.com et sur Twitter : @despos.

Merci à l'experte technique Microsoft suivante d'avoir relu cet article : Jon Arne Saeteras