Partager via

Choisir une méthode de remise de notification

  • Article

Cet article couvre les quatre options de notification—locale, planifiée, périodique et push—qui fournissent des mises à jour de mosaïques et de badges et du contenu de notification toast. Une vignette ou une notification toast peut obtenir des informations à votre utilisateur même si l’utilisateur n’est pas directement engagé avec votre application. La nature et le contenu de votre application et les informations que vous souhaitez fournir peuvent vous aider à déterminer la méthode de notification ou les méthodes qui conviennent le mieux à votre scénario.

Vue d’ensemble des méthodes de remise de notification

Il existe quatre mécanismes qu’une application peut utiliser pour remettre une notification :

  • Local
  • Planifié
  • Périodique
  • Envoi (push)

Ce tableau récapitule les types de remise de notification.

Mode de livraison Utiliser avec Description Exemples
Local Vignette, Badge, Toast Ensemble d’appels d’API qui envoient des notifications pendant l’exécution de votre application, mettant directement à jour la vignette ou le badge, ou en envoyant une notification toast.
  • Une application musicale met à jour sa vignette pour afficher ce qu’est « Now Playing ».
  • Une application de jeu met à jour sa vignette avec le score élevé de l’utilisateur lorsque l’utilisateur quitte le jeu.
  • Un badge dont le glyphe indique qu’il existe de nouvelles informations dans l’application est effacé lorsque l’application est activée.
Planifié Vignette, Toast Ensemble d’appels d’API qui planifient une notification à l’avance, à mettre à jour au moment où vous spécifiez.
  • Une application de calendrier définit un rappel de notification toast pour une réunion à venir.
Périodique Vignette, Badge Notifications qui mettent à jour des vignettes et des badges régulièrement à un intervalle de temps fixe en interrogeant un service cloud pour le nouveau contenu.
  • Une application météo met à jour sa vignette, qui affiche les prévisions, à intervalles de 30 minutes.
  • Un site de « transactions quotidiennes » met à jour son accord de la journée tous les matins.
  • Vignette qui affiche les jours jusqu’à ce qu’un événement met à jour le compte à rebours affiché chaque jour à minuit.
Envoi (push) Vignette, Badge, Toast, Raw Notifications envoyées à partir d’un serveur cloud, même si votre application n’est pas en cours d’exécution.
  • Une application d’achat envoie une notification toast pour informer un utilisateur d’une vente sur un article qu’il regarde.
  • Une application d’actualités met à jour sa vignette avec les dernières nouvelles telles qu’elles se produisent.
  • Une application sportive conserve sa vignette à jour pendant un jeu en cours.
  • Une application de communication fournit des alertes sur les messages entrants ou les appels téléphoniques.

 

Notifications locales

La mise à jour de la vignette ou du badge de l’application ou la levée d’une notification toast pendant l’exécution de l’application est la plus simple des mécanismes de remise de notification ; elle nécessite uniquement des appels d’API locaux. Chaque application peut avoir des informations utiles ou intéressantes à afficher sur la vignette, même si ce contenu change uniquement après le lancement et l’interaction de l’utilisateur avec l’application. Les notifications locales sont également un bon moyen de maintenir la vignette de l’application actuelle, même si vous utilisez également l’un des autres mécanismes de notification. Par exemple, une vignette d’application photo peut afficher des photos d’un album récemment ajouté.

Nous vous recommandons de mettre à jour sa vignette localement lors du premier lancement, ou au moins immédiatement après que l’utilisateur a apporté une modification que votre application reflète normalement sur la vignette. Cette mise à jour n’est pas visible tant que l’utilisateur n’a pas quitté l’application, mais en effectuant cette modification pendant l’utilisation de l’application, elle garantit que la vignette est déjà à jour lorsque l’utilisateur quitte l’application.

Bien que les appels d’API soient locaux, les notifications peuvent référencer des images web. Si l’image web n’est pas disponible pour le téléchargement, est endommagée ou ne répond pas aux spécifications, vignettes et toast répondent différemment :

  • Vignettes : la mise à jour n’est pas affichée
  • Toast : la notification s’affiche, mais votre image est supprimée

Par défaut, les notifications toast locales expirent en trois jours et les notifications de vignette locale n’expirent jamais. Nous vous recommandons de remplacer ces valeurs par défaut par un délai d’expiration explicite qui est logique pour vos notifications (les toasts ont un maximum de trois jours).

Pour plus d’informations, consultez ces rubriques :

Notifications planifiées

Les notifications planifiées sont le sous-ensemble de notifications locales qui peuvent spécifier l’heure précise à laquelle une vignette doit être mise à jour ou une notification toast doit être affichée. Les notifications planifiées sont idéales dans les situations où le contenu à mettre à jour est connu à l’avance, par exemple une invitation à une réunion. Si vous n’avez pas connaissance préalable du contenu de notification, vous devez utiliser une notification Push ou périodique.

Notez que les notifications planifiées ne peuvent pas être utilisées pour les notifications de badge ; Les notifications de badge sont mieux traitées par les notifications locales, périodiques ou Push.

Par défaut, les notifications planifiées expirent trois jours après leur remise. Vous pouvez remplacer cette heure d’expiration par défaut sur les notifications de vignette planifiées, mais vous ne pouvez pas remplacer l’heure d’expiration des toasts planifiés.

Pour plus d’informations, consultez ces rubriques :

Notifications périodiques

Les notifications périodiques vous permettent de mettre à jour des vignettes actives avec un service cloud minimal et un investissement client. Ils constituent également une excellente méthode de distribution du même contenu à un large public. Votre code client spécifie l’URL d’un emplacement cloud que Windows interroge pour les mises à jour des vignettes ou des badges, ainsi que la fréquence à laquelle l’emplacement doit être interrogé. À chaque intervalle d’interrogation, Windows contacte l’URL pour télécharger le contenu XML spécifié et l’afficher sur la vignette.

Les notifications périodiques nécessitent que l’application héberge un service cloud, et ce service sera interrogé à l’intervalle spécifié par tous les utilisateurs sur lesquels l’application est installée. Notez que les mises à jour périodiques ne peuvent pas être utilisées pour les notifications toast ; Les notifications toast sont mieux prises en charge par les notifications planifiées ou Push.

Par défaut, les notifications périodiques expirent trois jours après l’interrogation. Si nécessaire, vous pouvez remplacer cette valeur par défaut par une heure d’expiration explicite.

Pour plus d’informations, consultez ces rubriques :

Notifications push

Les notifications Push sont idéales pour communiquer des données ou des données en temps réel personnalisées pour votre utilisateur. Les notifications Push sont utilisées pour le contenu généré à des moments imprévisibles, tels que les dernières nouvelles, les mises à jour des réseaux sociaux ou les messages instantanés. Les notifications Push sont également utiles dans les situations où les données respectent le temps d’une manière qui ne convient pas aux notifications périodiques, telles que les scores sportifs pendant un jeu.

Les notifications Push nécessitent un service cloud qui gère les canaux de notification Push et choisit quand et à qui envoyer des notifications.

Par défaut, les notifications Push expirent trois jours après leur réception par l’appareil. Si nécessaire, vous pouvez remplacer cette valeur par défaut par une heure d’expiration explicite (les toasts ont un maximum de trois jours).

Pour plus d’informations, consultez l’article suivant :