Blog des développeurs d'applications Windows 8

Présentation d'une nouvelle expérience du Centre de développement Windows

Windows 8 Team — Thu, 16 May 2013 16:50:39 GMT

Depuis le lancement du Centre de développement Windows en octobre 2011, nous avons travaillé en étroite collaboration avec les développeurs et concepteurs du monde entier afin d'offrir les meilleurs conseils, avis et exemples aux concepteurs d'applications. Les millions de visiteurs et vos commentaires nous ont permis d'évaluer les points positifs et ce qui restait à améliorer.

Nouveautés

L'objectif de l'équipe Windows est de développer un écosystème d'applications dynamique et prospère. Cela s'exprime de trois manières : de formidables applications, de formidables débouchés commerciaux et de formidables opportunités de développement. Le nouveau Centre de développement permet aux concepteurs d'applications, développeurs et entreprises d'accéder aux ressources dont ils ont besoin pour réussir pleinement le développement de formidables applications et créer leur activité avec Windows.

Dans cette optique, le Centre de développement a évolué dans les domaines suivants :

Le modèle de navigation a changé afin que vous puissiez trouver le contenu approprié au cycle de vie du développement d'application dans lequel vous vous trouvez.
La conception du site met en évidence les tâches principales, les scénarios clés et les nouveaux contenus.

Outre le contenu, les exemples et les téléchargements dont les développeurs ont besoin, nous avons également facilité l'accès aux ressources pour les concepteurs et les entreprises.

Selon ce que vous concevez, vous pouvez accéder à l'une de ces quatre rubriques : Applications du Windows Store, Internet Explorer, Bureau Windows et Matériel. Chaque rubrique présente une nouvelle expérience qui répond aux points soulevés ci-dessus. Dans ce billet, nous allons examiner de plus près les modifications spécifiques apportées à la rubrique Applications du Windows Store.

Un contenu adapté à votre rôle

Le site le mieux documenté ne vous sera pas utile si vous ne trouvez pas ce dont vous avez besoin. Avec les centaines de milliers de rubriques du Centre de développement, l'organisation et la recherche du contenu sont des critères essentiels. En ce qui concerne le développement d'applications du Windows Store, cela signifie un affinement des recherches en fonction du rôle et du scénario (en mettant à votre disposition dont ce dont vous avez besoin pour commencer au même endroit pour parvenir à une assistance plus appropriée pour les concepteurs et les entreprises). Voici quelques-unes des principales améliorations.

Développeurs

Nous avons rationalisé le contenu dont vous avez besoin pour créer de formidables applications du Windows Store. La page d'accueil Applications du Windows Store présente les éléments suivants :

La section « Principaux contenus et tâches » apparaît au premier plan pour vous aider à accéder au contenu qui vous intéresse. Les événements locaux dans votre région sont mis en évidence, ainsi que les nouvelles ressources récemment ajoutées au site.
Des téléchargements ont pour but de vous aider à programmer et vous trouverez toutes les ressources dont vous avez besoin pour démarrer, ainsi que nos conseils détaillés pour transférer votre application dans le Windows Store.
Des exemples de code importants sont mis en évidence, et la consultation des rubriques d'aide est simplifiée et plus centrée sur le cycle de vie de développement.
Des vidéos « One Dev Minute » présentes sur tout le site vous permettent de savoir rapidement comment ajouter des fonctionnalités à votre application.

Concepteurs

Nous avons remanié la section Concevoir du site afin d'en faciliter l'utilisation et de la compléter. Vous y trouverez plus facilement des téléchargements utiles et des ressources de conception réutilisables, ainsi que des idées de conception et des études de cas qui vous donnent les clés dont vous avez besoin pour vivre une expérience unique sur Windows. Tout ce qui est nécessaire pour concevoir une application magnifique qui sorte du lot se trouve à portée de main, avec une mise en page conviviale et simple d'utilisation.

Entreprises

Les débouchés commerciaux que représente le Windows Store sont importants, avec un meilleur modèle économique que les plateformes concurrentes et une flexibilité supérieure qui vous permet de créer l'activité que vous voulez. La nouvelle section Commercialiser du site fournit de précieux conseils sur la commercialisation de vos applications, sur l'évaluation des données télémétriques et sur la réussite de la certification de vos applications. Nous avons beaucoup appris sur la façon dont nous pouvions simplifier la certification et avons amélioré le contenu pour vous aider à suivre plus rapidement le processus.

Évidemment, vous êtes nombreux à remplir plusieurs rôles et nous pensons que la nouvelle organisation du site vous aidera également dans ce cas. La nouvelle organisation du site permettra à tous les acteurs d'atteindre leurs objectifs avec Windows, qu'il s'agisse d'amateurs ou d'agences de création en passant par les éditeurs de logiciels les plus importants.

Ce n'est qu'un début et nous voudrions entendre votre avis

Avec la conférence BUILD 2013 qui se tient dans un peu plus d'un mois, beaucoup de sujets restent à aborder. Nous travaillons d'arrache-pied pour produire de nouveaux contenus à partager lors de la conférence. Outre ce blog, vous pouvez également vous tenir au courant des derniers événements en suivant @windevs sur Twitter et en vous abonnant au bulletin d'informations du Windows Store.

Parallèlement au lancement de contenus supplémentaires pour vous aider à concevoir, développer et commercialiser vos applications du Windows Store, nous voulons continuer à améliorer l'utilisation du Centre de développement. Afin que vous puissiez nous dire plus facilement ce que vous pensez, nous avons proposé deux nouvelles options d'envoi des commentaires au bas de chaque page. N'hésitez pas à nous donner votre avis. Nous en prenons connaissance et faisons toujours tout notre possible pour répondre à vos attentes.

Keith Boyd, Responsable de la publication de contenu, Contenu de développement Windows

Partage vers votre application cible

Windows 8 Team — Wed, 15 May 2013 16:10:42 GMT

Dans le billet Partage à partir de votre application, nous avons présenté le concept de partage de contenu à partir de l'exemple d'application Food with Friends. Dans ce billet, les contenus sont partagés avec plusieurs applications cibles qui permettent à l'utilisateur de mener à bien l'intégralité de différents scénarios complexes. Les applications de Windows 8 offrent des contenus intéressants que vos clients souhaiteront certainement partager avec leurs amis ou avec d'autres applications. Si vous réussissez à faire de votre application une cible de partage convaincante et bien conçue, elle peut devenir pour vos clients le véritable cœur d'une expérience sociale et connectée.

Dans ce billet, nous examinons comment vous pouvez utiliser le contrat de partage cible avec vos applications, en particulier avec les applications de type « Food with Friends ». Grâce à ce contrat, votre application peut recevoir des contenus issus d'autres applications et utiliser ces contenus pour les enrichir. Notre objectif : vous aider à faire de votre application la meilleure de sa catégorie !

Pour créer une application cible, vous devez utiliser le contrat de partage cible. Les applications cibles permettent de partager facilement et rapidement des contenus. Toutes les applications Windows ne peuvent pas être utilisées comme cibles de partage. Cependant, si votre application peut publier les contenus issus d'autres applications, les transformer, les stocker ou y ajouter une quelconque valeur, la création d'une cible de partage offre de nombreux avantages.

Votre application apparaîtra toujours dans la liste des applications cibles. Elle offre instantanément des informations pertinentes et elle est connectée à d'autres applications qui peuvent partager les données que vous souhaitez.
Le contrat de partage crée un pont entre votre application et n'importe quelle application source, sans que l'une ou l'autre des applications ait besoin de prévoir une intégration spécifique avec l'autre application.
Comme l'icône Partager est toujours présente et disponible dans le système d'exploitation, elle permet à votre application cible d'être présente dans le système d'exploitation, bien au-delà des limites de votre application. Ainsi, plus de clients peuvent potentiellement être dirigés vers votre application !

Réception des contenus partagés

Examinons quelques exemples qui vous montrent comment proposer des expériences utilisateur convaincantes par le biais d'une application cible de partage.

Vous connaissez peut-être déjà les applications Courrier et Contacts de Windows 8. Courrier crée une expérience de cible de partage extrêmement simple et personnalisée, permettant de recevoir et de partager des contenus avec un ou plusieurs amis. L'application Contacts vous permet de partager des contenus avec des publics plus larges sur vos réseaux sociaux. En plus du partage social, vous pouvez aller encore plus loin avec le partage d'application dans l'application. Les applications de productivité telles que SkyDrive peuvent recevoir des fichiers de tous les emplacements de Windows et les stocker sur le cloud. Les applications de prise de notes peuvent recevoir du texte, des liens et éventuellement des données dans de nombreux autres formats et les archiver, en vue d'une consultation ultérieure. Vous profitez également d'une grande marge de créativité.

Observez comment, sur les deux images ci-dessous, le processus de partage apparaît lors du partage d'une photo à partir de l'application Photos avec PuzzleTouch, une application de jeu qui transforme l'image en puzzle visuel.

Figure 1 : l'application source apparaît à gauche, tandis que la liste filtrée des applications cibles pouvant recevoir des photos apparaît à droite dans le volet Partager.
PuzzleTouch fait partie des cibles de partage pouvant recevoir une image issue de l'application Photos.

Figure 2 : dans la partie droite, l'aperçu de l'application cible permet à l'utilisateur de sélectionner le type de puzzle
à créer. Le puzzle est prêt dès que l'utilisateur accède de nouveau à l'application.

Qu'est-ce qu'une application cible de partage ?

Dans Windows , l'expérience de partage se compose de deux éléments. Elle comprend tout d'abord d'une application source qui met son contenu à la disposition de Windows, dans différents formats. Vient ensuite une application cible de partage, qui indique à Windows qu'elle reconnaît certains formats et qui sert de destination pour le contenu partagé. Grâce au contrat de partage, l'application source et l'application cible de partage peuvent communiquer.

Lorsque vous réfléchissez à l'expérience de partage de votre application, prenez en compte le fait que l'application cible de partage est affichée dans la fenêtre de partage hébergée. Concevez l'expérience de telle sorte que l'utilisateur puisse afficher rapidement un aperçu de son contenu et confirmer le partage dans cette vue. Cet exemple représente la vue d'application cible de partage de l'application Courrier, qui permet à l'utilisateur de partager rapidement un lien à partir du navigateur avec un ou plusieurs contacts de messagerie.

Figure 3 : partage d'un lien à partir de l'application Photos avec l'application cible Courrier

Scénarios pour Food with Friends

Voyons maintenant comment Food with Friends crée une expérience convaincante d'application cible de partage. Si vous connaissez déjà l'application, vous savez que dans Food with Friends, l'utilisateur peut entreprendre deux actions principales : créer un programme et ajouter un restaurant à sa liste d'envies. Bien évidemment, d'autres opérations sont réalisables : rédaction d'un avis, publication d'un commentaire, affichage des listes d'envies des amis, etc. Toutefois, ces expériences sont uniquement mises en œuvre dans le contexte de l'application principale. Pour les deux scénarios principaux, faisons un petit test pour vérifier s'ils peuvent être menés à bien de façon efficace via l'application cible Food with Friends.

Créer le programme de la soirée

S'il fait partie des scénarios essentiels de l'application principale, il ne s'agit pas du scénario idéal dans le cadre d'une expérience de cible de partage. Voici pourquoi : l'expérience de cible de partage est censée être rapide et simple. Or la création d'un programme est une tâche bien plus complexe : dans ce cas, l'utilisateur souhaite savoir quels restaurants ses amis veulent essayer, comparer quelques restaurants figurant dans la liste d'envies, passer les notes en revue, etc. Comme la planification implique d'exploiter des détails qui sont mieux présentés dans la vue de l'application principale, il n'est pas très judicieux de condenser cette fonctionnalité dans l'application cible du partage.

Ajouter à la liste d'envies

Ce scénario fonctionne parfaitement bien en tant que tâche courte et guidée dans la cible de partage. Voici quelques-uns des principaux aspects de cette expérience dans l'application :

Les utilisateurs trouvent des restaurants dans d'autres applications (applications d'organisation de voyages, applications consacrées à une ville précise et comportant des recommandations, blogs consacrés à la gastronomie, etc.). Food with Friends est une destination idéale pour regrouper des restaurants dans la section « Ma liste d'envies ».
La vue d'application cible d'une application est conçue pour permettre à l'utilisateur d'entreprendre rapidement une action dans le contexte d'une autre application. Ainsi, l'ajout d'un restaurant à une liste d'envies est une option idéale à faire apparaître dans la cible de partage.
S'il est certainement possible pour l'utilisateur de changer d'application, de relancer la recherche afin de trouver le restaurant, puis d'ajouter le restaurant à sa liste d'envies, il est bien plus rapide d'appuyer sur Partager.

La liste d'envies de Food with Friends offre donc a priori une formidable expérience d'application cible de partage, que nous souhaitons donc concevoir et créer. Voici le scénario complet auquel nous avons pensé :

En parcourant une application qui recense les restaurants ambulants à proximité, je découvre une recommandation qui m'a l'air intéressante. Je souhaite ajouter le restaurant ambulant indiqué dans cette application à ma liste d'envies Food with Friends, pour faciliter la planification ultérieure.

Figure 4 : navigation dans une application qui affiche les restaurants ambulants à proximité et recommande les lieux intéressants

Cette image représente la vue d'application cible de partage que nous souhaitons utiliser :

Figure 5 : vue d'application cible de partage

En réalisant l'action de partage dans la vue d'application cible, les utilisateurs peuvent choisir des restaurants dans Food with Friends sans sortir du contexte de leur expérience actuelle d'application immersive.

Implémentation d'une cible de partage

Maintenant que vous avez découvert quelques exemples montrant quand implémenter une cible de partage, examinons comment implémenter notre cible de partage. Nous devons tout d'abord définir les formats de données que votre application devra accepter.

Quels formats de données devez-vous prendre en charge ?

Avec le partage, vous pouvez prendre en charge des formats de données standard (texte, URI, HTML, images bitmap, fichiers, etc.) ou des formats de données personnalisés, tels que ceux qui figurent sur http://schema.org. Windows filtre les applications cibles en fonction des formats de données qu'elles acceptent, afin d'afficher la liste filtrée des applications cibles dans le volet Partager. Votre application doit prendre en charge les formats de données les plus importants dans le cadre de l'expérience utilisateur de l'application. Par exemple, si votre application permet d'afficher des photos, il n'est sans doute pas nécessaire de prendre en charge les formats texte. Si vous déclarez la prise en charge de plusieurs formats de données, identifiez celui qui vous aide à représenter le mieux les données partagées, pour sélectionner ce format en premier dans le package de données.

Comme Food with Friends implémente une expérience de cible de partage qui permet aux utilisateurs de partager des restaurants vers l'application, nous utiliserons le format de données Restaurant disponible sur http://schema.org. Food with Friends peut s'inscrire auprès du contrat de partage cible afin de recevoir ce format de données. À partir des données disponibles dans le package reçu, l'application peut ensuite créer une expérience convaincante dans sa vue d'application cible, qui permet à l'utilisateur d'ajouter ce restaurant à sa liste d'envies.

Si certaines applications sources peuvent partager des données en utilisant spécifiquement le format de données Restaurant, d'autres applications sources peuvent représenter des informations similaires en utilisant d'autres formats, par exemple Place, LocalBusiness ou FoodEstablishment, qui figurent sur schema.org. Ainsi, Food with Friends peut prendre en charge la réception de plusieurs formats de données dans le contrat de partage, pour s'adapter à une grande variété d'applications sources.

Food with Friends prend en charge les formats suivants dans les déclarations de cible de partage du manifeste de l'application :

Pour plus de concision, nous nous concentrons ici sur le type de données Restaurant, mais les concepts s'appliquent également à d'autres types de données.

Quels formats de données et scénarios devez-vous prévoir ?

Food with Friends ne permettra d'ajouter un restaurant à la liste d'envies de l'utilisateur que si les informations reçues concernant le restaurant correspondent à celles d'un restaurant que l'application connaît déjà. Ce comportement est voulu : il évite de créer plusieurs copies d'un même restaurant dans l'application.

Nous ne prenons pas en charge les types de données standards, car la plupart des contenus de type texte, fichiers, photos URI ou HTML partagés à partir d'applications sources ne sont pas associées à un restaurant ou à une entreprise locale. Par exemple, si Food with Friends prenait en charge la réception de texte, il apparaîtrait dans la liste des applications cibles d'une application source de prise de notes. Dans ce cas, Food With Friends devrait afficher un message d'erreur pour indiquer pourquoi cette application ne fonctionne pas avec telle ou telle application source. Au final, les formats de données jouent le rôle de lien entre l'application source, qui possède un contenu à proposer à une application cible, et l'application cible elle-même. Si les formats de données sont différents, il n'y a pas lieu de partager quoi que ce soit.

Pensez à prendre en compte tous les formats de données qui vous aident à identifier les informations importantes et à identifier les formats de données qui risqueraient de rendre l'expérience de partage trop généraliste.

Prise en charge du contrat de partage cible

Pour prendre en charge les formats de données, déclarez-les dans le concepteur de manifeste de votre application, dans Visual Studio. Voici ce qui se produit lorsqu'un utilisateur sélectionne votre application en tant que cible d'une action de partage :

Une nouvelle instance de l'application est ouverte dans la fenêtre de la cible de partage, par-dessus l'application source.
Un événement d'activation de cible de partage est déclenché et votre application reçoit un objet ShareOperation en tant que résultat.
Votre application peut récupérer les données que l'utilisateur a partagées à partir de cet objet.
Vous pouvez utiliser ces données pour générer la vue de l'application cible et terminer la procédure de partage initiée par l'utilisateur.

Pour plus d'informations sur la création de cette expérience, consultez le guide Démarrage rapide : réception d’un contenu partagé.

Par ailleurs, Visual Studio prend en charge un modèle pour les cibles de partage. Cliquez avec le bouton droit de la souris sur votre projet, sélectionnez Ajouter un élément, Ajouter un nouvel élément, puis cliquez dans la liste sur Contrat de partage cible afin d'ajouter le code de prise en charge du contrat. L'exemple de code de cible de partage montre comment recevoir du contenu partagé.

Conception d'une vue d'application cible personnalisée

Lorsque l'utilisateur sélectionne une application cible dans la liste des applications du volet Partager, Windows ouvre l'application dans la vue de cible de partage de l'application. La vue d'application cible est une vue spécifique hébergée dans le volet Partager. Elle diffère de la vue principale de l'application. Le billet Activation des contrats Windows 8 dans votre application offre des informations complémentaires sur les vues hébergées et sur la gestion de l'activation de ces vues. La vue d'application cible est conçue pour vous aider à terminer l'action de partage initiée par l'utilisateur. Dans cette vue, les utilisateurs doivent être en mesure d'afficher un aperçu du contenu, d'entreprendre des actions simples et de confirmer leur souhait de partager le contenu.

Avant d'étudier la conception d'application cible de Food with Friends, examinons une application cible que vous connaissez peut-être déjà. Les images ci-dessous illustrent la vue d'application cible de l'application Courrier, ainsi que la vue complète de l'application dans Windows 8.

Figure 6 : partage à partir de l'application Photos vers l'application cible Courrier, située à droite

Figure 7 : rédaction d'un nouveau message dans la vue d'application principale de Courrier

Vous remarquerez que la vue d'application cible de partage de Courrier est plus simple que la vue d'application complète. Elle offre un aperçu clair et minimaliste du contenu que l'utilisateur s'apprête à partager, présenté sous la forme d'une miniature agrémentée de texte et de contenus HTML. Elle offre une ligne À permettant d'ajouter des destinataires, une zone de saisie permettant de rédiger un court message, ainsi qu'un bouton Envoyer, qui permet de confirmer très simplement l'envoi du message.

Aussi simpliste soit-elle, la vue d'application cible de cette application est facilement identifiable en tant qu'avatar de l'application Courrier, ce qui renforce la confiance de l'utilisateur vis-à-vis de la destination du contenu partagé.

Food with Friends en tant qu'application cible de partage

Maintenant que vous comprenez mieux comment est conçue la vue d'application cible, examinons comment Food with Friends crée une application cible qui aide les utilisateurs à ajouter des restaurants à leur liste d'envies.

Lorsque Food with Friends reçoit le package de données contenant un restaurant en provenance de l'application source, il peut utiliser les détails figurant dans le format de données Restaurant pour identifier quel restaurant correspond au package de données reçu dans sa base de données existante. L'application peut ensuite afficher un aperçu de ce restaurant dans la vue d'application cible. La confiance de l'utilisateur vis-à-vis de l'intégrité du contenu partagé est ainsi renforcée.

Cette image représente la vue d'application cible de Food with Friends :

Figure 8 : vue d'application cible de Food with Friends

Comme vous pouvez le constater, cette vue de Food with Friends est simple et adaptée à une application cible de partage. Elle affiche un aperçu du restaurant que l'utilisateur s'apprête à partager, ainsi qu'un bouton simple, Ajouter à la liste d'envies, qui indique clairement la destination du contenu partagé dans l'application principale. Lorsque l'utilisateur appuie ou clique sur ce bouton, il confirme l'opération de partage. En obligeant l'utilisateur à appuyer ou à cliquer sur ce bouton, nous empêchons tout partage accidentel et nous améliorons la confiance de l'utilisateur vis-à-vis de l'expérience de partage globale.

Si l'application trouve plusieurs restaurants correspondant aux informations figurant dans le contenu du package de données, Food with Friends utilise la vue d'application cible de partage pour afficher des options et permettre à l'utilisateur de choisir celui qu'il souhaite partager.

Figure 9 : la vue d'application cible affiche des options permettant à l'utilisateur de choisir les éléments à partager

Si jamais l'application ne parvient pas à identifier précisément un restaurant ou un ensemble d'options valides à partir du package de données reçu, utilisez la vue d'application cible pour communiquer ce message.

Création d'un QuickLink

Un QuickLink est une disposition de l'API de partage qui permet aux utilisateurs de partager des contenus vers des destinations courantes très rapidement, au sein de votre application cible. Un QuickLink joue le rôle de lien personnalisé vers votre vue cible, en fournissant des actions spécifiques. Lorsque Windows filtre la liste des applications cibles proposées à l'utilisateur, la liste des QuickLinks apparaît en haut du volet Partager, sous forme de liste des cibles disponibles. Ces destinations courantes ou ces actions utilisateurs peuvent inclure des emplacements ou des contacts qui sont souvent utilisés comme destination du partage dans l'application cible. Par exemple, l'application Courrier renvoie des QuickLinks pour les contacts précédemment utilisés comme destinataires. De même, vous pouvez ajouter des QuickLinks aux dossiers, groupes, blocs-notes et listes de lecture que vous partagez souvent vers votre application cible.

Figure 10 : le volet Partager montre un QuickLink fourni par l'application cible Courrier pour les contacts
qui ont été précédemment utilisés comme destinataires dans l'application cible

L'application cible peut fournir un QuickLink en appelant la méthode reportCompleted des objets ShareOperation . Un QuickLink doit posséder un titre, une icône et un ID. Le titre ("Envoyer un e-mail à maman", par exemple) et l'icône apparaissent lorsque l'utilisateur appuie sur l'icône Partager. L'ID est utilisé par votre application pour accéder à des informations personnalisées (adresse e-mail, emplacement de dossier, etc.). Pour en savoir plus sur cet outil, voir Comment créer un objet QuickLink.

Remarque : les QuickLinks sont utiles lorsque l'application prend en charge plusieurs actions de l'application cible. Comme Food with Friends ne prend en charge qu'une seule action dans la cible de partage (Ajouter à la liste d'envies), l'application n'implémente pas de QuickLinks.

Partage étendu et signalement des erreurs

Dans certains cas, les applications sources partagent de gros volumes de données, par exemple des photos, des vidéos ou encore de gros fichiers, ce qui rallonge les temps de transfert. Ces types d'opérations de partage appelés partages étendus sont utilisés lorsque votre application cible peut avoir besoin de plus de temps pour recevoir et traiter les données.

Comme le partage doit être rapide et fluide, et que la vue d'application cible est une vue légère et hébergée, affichée par-dessus l'application principale, les utilisateurs sont susceptibles de sortir de la vue d'application cible pour revenir à l'application principale. Par conséquent, les applications cibles ne doivent pas exiger ni attendre une interaction de l'utilisateur avec la vue d'application cible après le démarrage du partage. Les applications cibles peuvent s'appuyer sur l'objet ShareOperation et ses méthodes pour indiquer à Windows que l'application est en train de traiter des données.

reportStarted : appelez cette méthode pour indiquer à Windows que votre application a commencé à récupérer les données de l'objet DataPackage issu de l'application source.
reportDataRetrieved : appelez cette méthode pour indiquer à Windows que votre application a terminé de récupérer les données du package.
reportCompleted : appelez cette méthode pour indiquer à Windows que votre application a terminé l'opération de partage.

Lorsque votre application traite les données d'un partage étendu, fournissez à l'utilisateur un indicateur de progression dans la vue d'application cible. L'utilisateur saura ainsi que sa demande est en cours de traitement, ce qui améliorera sa confiance vis-à-vis de l'application lorsqu'il accédera de nouveau à l'application pour consulter la progression de l'opération de partage. Pour en savoir plus sur les contrôles de progression dans Windows 8, consultez le guide Démarrage rapide : ajout de contrôles de progression.

Figure 11 : l'application cible Courrier affiche une roue de progression pendant un partage étendu (envoi de pièces jointes volumineuses, par exemple)

Si quelque chose se passe mal au cours du transfert de données et que votre application cible doit arrêter l'opération de partage, vous pouvez appeler la méthode reportError pour envoyer un message d'erreur à Windows. L'utilisateur verra le message lorsqu'il consultera l'état du partage dans le volet Partager. Une fois l'erreur signalée, votre application est fermée et le partage est arrêté. L'utilisateur doit alors recommencer la procédure pour partage du contenu vers votre application.

Dans l'exemple de cible de partage Food with Friends, si l'application ne peut pas identifier dans sa base de données un restaurant correspondant à celui partagé à partir de l'application source via le format de données Restaurant, l'application doit signaler une erreur.

Révisons un peu !

Le partage d'une application à une autre est une formidable opportunité pour les applications cibles de partage. En offrant à votre application la possibilité de recevoir des contenus partagés, vos utilisateurs profitent de votre application même lorsqu'ils réalisent une autre activité. Nous espérons que vous comprenez maintenant mieux les principes de conception, ainsi que les types de données, les classes et les propriétés que vous pouvez utiliser pour créer une formidable destination cible de partage. Nous sommes impatients de découvrir comment vos applications transformeront le contenu partagé et créeront des expériences toujours plus riches et plus complètes pour l'utilisateur final.

Pour en savoir plus sur le partage, commencez par consulter l'article Partage et échange de données et l'exemple d'application cible de partage de contenu.

Ishita Kapur

Chef de projet

Expérience utilisateur Windows

Développer une application innovante grâce au NFC

Windows 8 Team — Wed, 24 Apr 2013 22:39:26 GMT

Le NFC (Near Field Communication) est une technologie émergente de communication sans fil en champ proche. Grâce à sa portée très précise de l'ordre de 2 cm, les utilisateurs peuvent mettre physiquement en contact deux appareils pour envoyer et recevoir des contenus. Cette opération vous permet de sélectionner quelque chose (ou quelqu'un) très rapidement. Le principe est non seulement rapide, mais aussi très facile à comprendre. Dès lorsque vous avez vu comment fonctionne cette technologie, vous avez tout compris : pas besoin de lire le moindre manuel !

Imaginons par exemple que vous regardez des photos avec une amie et qu'elle souhaite télécharger vos images. Grâce à la technologie NFC, il vous suffit de mettre en contact votre appareil avec son PC pour lui envoyer les photos. Cet exemple est trop simpliste ? C'est possible, mais il montre bien à quel point il est facile de partager des contenus entre des appareils.

Figure 1 : sur cette image, l'enceinte du Nokia 360 partage ses informations de couplage Bluetooth
avec un Windows Phone

Comme les technologies Bluetooth ou Wi-Fi, le NFC est un protocole sans fil standard, défini par le NFC Forum. Votre PC doit posséder un émetteur-récepteur NFC. De nombreux PC Windows 8 intègrent directement des émetteurs-récepteurs NFC. Si votre PC ne possède pas d'équipement NFC, vous pouvez acquérir une clé NFC qui se branche directement à votre PC.

La technologie NFC offre des fonctionnalités vraiment formidables. Ainsi, les utilisateurs peuvent envoyer des photos par simple contact, mettre en contact leur appareil avec une carte pour commander un repas au restaurant, ou même mettre en contact deux appareils pour coupler un appareil Bluetooth. Bien que différents les uns des autres, ces scénarios ont un point commun : le « contact », qui vise à initier l'opération. La technologie NFC est utilisée sur des appareils très divers : PC, téléphones, enceintes, casques audio, écrans sans fil, etc., pour rendre plus intuitive la connexion d'un appareil à un autre. En outre, le NFC utilise également des étiquettes RFID, ces antennes passives, légères et très peu coûteuses qui peuvent stocker une quantité non négligeable de données et qui peuvent être collées à n'importe quel objet, y compris des affiches. Par exemple, on peut dès lors imaginer acheter un ticket de cinéma en mettant en contact le téléphone avec l'affiche du film ! Dans ce cas, on parle « d'étiquette NFC ». Nous examinerons un exemple très simple de mise en contact avec une étiquette NFC, pour présenter quelques-uns des principaux concepts de l'API NFC.

Commençons cependant par regarder de plus près en quoi consiste la mise en contact d'appareils.

Qu'est-ce qu'une mise en contact ?

Qu'il s'agisse de mettre en contact des appareils pour coupler une souris Bluetooth à un ordinateur ou pour partager des photos, il est indispensable de mettre en contact les appareils de la même manière pour tous les utilisateurs. Si nous savons tous à peu près de quoi il s'agit, en pratique la plupart des utilisateurs ne savent pas quoi faire lorsqu'ils doivent mettre en contact un PC avec un autre appareil. Voici quelques recommandations en la matière, qui permettent aux utilisateurs :

De savoir où mettre en contact les appareils, en utilisant un repère visuel (parfois appelé « Approcher pour activer »), qui indique où se trouve l'antenne NFC. Le point de contact diffère selon le modèle de PC utilisé. Ainsi, pour une tablette, le point de contact peut se trouver au dos, tandis qu'il se trouvera plus vraisemblablement en face avant sur un tout-en-un. Voici à quoi ressemble le repère sur un PC Windows 8 compatible NFC :

Figure 2 : repère « Approcher pour activer »
De savoir si les appareils communiquent entre eux : lors de la mise en contact, les utilisateurs doivent savoir si l'opération se passe comme prévu, même s'ils ne peuvent pas voir que les données sont en cours de transfert. Ainsi, Windows émet un son lorsque des appareils sont dans le champ de portée et communiquent les uns avec les autres.

Windows effectue cette opération automatiquement et vous n'avez donc pas à vous en préoccuper. Pour plus d'informations sur ces éléments d'expérience utilisateur, consultez la spécification Windows 8 Near Field Proximity Implementation (implémentation de la proximité en champ proche dans Windows 8). Maintenant que nous comprenons mieux le principe, examinons quelques scénarios très intéressants qui utilisent la technologie NFC.

Dans quels cas utiliser la technologie NFC ?

Utilisez le NFC lorsqu'un utilisateur doit sélectionner quelque chose ou quelqu'un dans votre application. Le NFC offre une solution intuitive pour sélectionner des éléments, solution qui s'avère souvent plus rapide (et plus amusante !) qu'une recherche manuelle. La mise en contact joue le rôle de déclencheur de l'expérience. Selon la nature de votre application, elle peut déclencher la réception d'une photo ou le lancement d'une liste de lecture. Une fois la mise en contact effectuée, il appartient à votre application de décider du comportement à adopter. Pour plus de simplicité, nous classons ce type d'expériences dans la catégorie « Approcher pour activer ».

Voici quelques exemples qui utilisent la technologie NFC pour sélectionner un élément dans une application. Grâce à une simple mise en contact, vous pouvez…

Obtenir des informations à partir d'une affiche : les étiquettes NFC sont des étiquettes RFID légères et peu coûteuses (entre 0,15 et 1 USD pièce, selon les coûts d'impression). Le fonctionnement est similaire à celui des codes QR, mais tout est plus simple et plus rapide. D'un point de vue ergonomique, il est ainsi plus facile de mettre en contact un appareil avec une étiquette plutôt que de prendre en photo un code-barres (en croisant les doigts pour que l'appareil photo trouve le bon angle). De plus en plus de fabricants intègrent des étiquettes à leurs affiches dans les lieux de passage particulièrement fréquentés (aéroports, stations de métro, arrêts de bus, etc.). Elles peuvent stocker entre 48 octets et 4 Ko de données. Vous pouvez programmer une étiquette afin qu'elle ouvre votre application sur une page spécifique.

Échanger des coordonnées : au lieu de dicter vos informations de contact à un ami en espérant qu'il ne fera pas d'erreur, il suffit de mettre en contact vos appareils pour échanger vos coordonnées. Comme dans le scénario ci-dessus, vous pouvez programmer vos coordonnées dans une carte de visite/étiquette NFC. Vous pouvez aussi échanger directement des coordonnées par le biais d'une application.
Écouter votre station de radio préférée : sur le chemin du travail, en voiture ou confortablement installé dans votre canapé, vous pouvez utiliser une étiquette pour démarrer l'écoute d'une station de radio. Vous pouvez même programmer différentes stations musicales sur différentes étiquettes : une étiquette pour vos séances de jogging, une autre pour la relaxation et une dernière pour vous endormir, par exemple.
Commander un menu dans un restaurant très fréquenté : au restaurant, vous devez parfois attendre très longtemps avant de pouvoir commander. Avec la technologie NFC, il suffit de mettre votre appareil en contact avec l'étiquette de votre table pour passer commande.
Jouer à un jeu multijoueur avec un ami : vous pouvez facilement jouer en réseau avec un ami à un jeu multijoueur tel que Battleship, Chess ou Scrabble, en mettant en contact les appareils. Une fois la mise en contact effectuée, la connexion est maintenue en mode hors-bande, offrant une portée plus grande et un meilleur débit (Bluetooth ou Wi-Fi Direct, par exemple).

Maintenant que vous comprenez sans doute mieux comment utiliser la technologie NFC, amusons-nous un peu en créant une application qui utilise les API de proximité (NFC) de Windows 8.

Comment mettre en œuvre la technologie NFC ?

Comme vous pouvez le constater, la technologie NFC facilite de nombreuses tâches quotidiennes pour l'utilisateur final. Prenons l'exemple du réglage d'une alarme. Je suis certain que nous avons tous au moins une fois mal réglé notre réveil pour le lendemain. Lorsqu'il est tard et que nous sommes fatigués, nous n'avons pas toujours les idées claires ! Avec le NFC, il vous suffit de mettre en contact votre appareil avec une étiquette préréglée, de confirmer, puis de vous endormir tranquillement, en étant certain d'être réveillé à l'heure. Pour aider les utilisateurs à accomplir cette tâche quotidienne, vous pourriez par exemple développer une application d'alarme élémentaire permettant aux utilisateurs de configurer une alarme en utilisant une étiquette NFC. Divisions le processus en deux scénarios :

Configuration d'une alarme sur l'étiquette : les étiquettes NFC étant réutilisables, l'application peut permettre aux utilisateurs de programmer une alarme. Par exemple, un utilisateur peut avoir besoin de programmer différentes alarmes : une pour la semaine, une autre pour le week-end. Dans ce cas, on parle de « publication » de données sur une étiquette.
Configuration d'une alarme à partir de l'étiquette : Dès lors qu'un utilisateur met son appareil en contact avec l'étiquette, l'application doit être ouverte pour confirmer la configuration de l'alarme. L'application peut ainsi être lancée avec un contexte ou des arguments.

L'API NFC offre plusieurs solutions pour parvenir au même résultat. Dans ce billet, je vais présenter la façon la plus simple de mettre en œuvre ce scénario.

Examinons le processus de configuration d'une alarme sur une étiquette NFC :

Mario lance l'application d'alarme et définit une heure, par exemple 7 h. Pour l'instant, rien d'exceptionnel : la technologie NFC n'est pas utilisée.
Mario sélectionne une option permettant de « Configurer l'alarme sur une étiquette NFC ». À cet instant, l'application appelle les API NFC afin de publier des informations sur l'émetteur-récepteur NFC, en particulier une chaîne d'identificateur d'application & 07:00. Les étiquettes NFC utilisent un format standardisé de messages, appelé NDEF (NFC Defined Exchange Format). Votre application n'a pas à gérer la mise en forme des données du message NDEF : Windows s'en occupe ! L'utilisateur peut alors mettre en contact son appareil avec l'étiquette NFC.
Mario met en contact l'étiquette avec le PC, et l'application confirme la programmation de l'étiquette. Au moment de la mise en contact avec l'étiquette, il est important d'indiquer à l'utilisateur que l'application a bien programmé l'étiquette. Comme nous l'avons déjà évoqué, le fait de mettre en contact un PC avec une étiquette est un concept inconnu de la plupart des utilisateurs. La confirmation permet ainsi à l'utilisateur d'être certain que l'opération s'est bien déroulée. L'application sait qu'un message a été correctement transmis en s'inscrivant auprès d'un gestionnaire de message transmis.

Les API NFC se trouvent dans l'espace de noms Windows.Networking.Proximity. Elles sont utilisées à partir de l'étape 2, lorsque l'utilisateur sélectionne l'option permettant de « Configurer l'alarme sur une étiquette NFC ». Tout d'abord, l'application initialise un objet de proximité. L'objet de proximité est utilisé pour indiquer quand une étiquette (ou un appareil) se trouve à l'intérieur du champ de portée ou au contraire hors de portée. Nous ajoutons ensuite le gestionnaire d'événements DeviceArrival. Ce gestionnaire détecte à quel moment l'étiquette est mise en contact avec un appareil, ce qui signifie que nous pouvons commencer à écrire des données sur l'étiquette. Il est important de signaler aux utilisateurs à quel moment vous écrivez des informations sur une étiquette, pour qu'il ne sorte pas du champ de portée. Vous pouvez utiliser le même événement pour détecter quand un appareil de proximité est mis en contact.

L'extrait de code ci-dessous montre comment initialiser et ajouter un gestionnaire d'événements DeviceArrival.

JavaScript

var proximityDevice;

function initializeProximityDevice() {
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.getDefault();

    if (proximityDevice) {
        proximityDevice.addEventListener("devicearrived", proximityDeviceArrived);
       
}
   else {
        // No NFC radio on the PC, display an error message
    }


function proximityDeviceArrived(device) {
        // Let the user know we’re ‘Writing to Tag’

}
}

private void InitializeProximityDevice()
{

Windows.Networking.Proximity.ProximityDevice proximityDevice;
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.GetDefault();

    if (proximityDevice != null) {
        proximityDevice.DeviceArrived += ProximityDeviceArrived;
    
    }
    else
    {
        // No NFC radio on the PC, display an error message
    }
}

private void ProximityDeviceArrived(Windows.Networking.Proximity.ProximityDevice device)
{
            // Let the user know we’re ‘Writing to Tag’

}

Publions ensuite ces informations sur l'étiquette. L'application publie deux informations : une chaîne d'identificateur d'application, qui se compose d'un ID d'application et d'une plateforme d'application, ainsi que des arguments de lancement. Pour Windows 8, l'ID d'application est <nom de famille du package>!<ID d'application> et la plateforme d'application est « Windows ». Vous devez copier la valeur d'ID d'application qui figure dans l'attribut ID de l'élément Application du manifeste de package de votre application. L'argument de lancement est « 07:00 », c'est-à-dire l'heure définie par l'utilisateur. Appelons-le message.

Si l'application fonctionne sur plusieurs plateformes, Windows vous permet de publier d'autres ID d'application et plateformes d'application. Vous pouvez ainsi mettre en contact la même étiquette avec d'autres appareils compatibles NFC, par exemple un téléphone Windows Phone 8 ! Vous trouverez des informations supplémentaires sur les autres ID sur MSDN.

L'application publie les données sur l'étiquette en utilisant une méthode appelée publishBinaryMessage. Cette méthode accepte trois paramètres : messageType, message, ainsi qu'une fonction messageTransmittedHandler. Définissons le paramètre messageType sur « LaunchApp:WriteTag ». Ceci indique à Windows que votre application souhaite écrire des informations sur une étiquette NFC. Le message est celui que nous avons défini plus tôt (chaîne d'identification de l'application et arguments de lancement). Nous devons stocker le message sous forme de message binaire dans un tampon. La fonction messageTransmittedHandler assure l'inscription des rappels. Ainsi, votre application sait que le message a bien été écrit sur l'étiquette. Nous utiliserons cette fonction pour signaler à l'utilisateur que le message a bien été écrit sur l'étiquette et qu'il n'est plus nécessaire que l'étiquette reste dans le champ de portée.

Les messages continuent à être publiés jusqu'à ce que nous appelions la fonction StopPublishingMessage ou jusqu'à ce que l'objet ProximityDevice soit publié. Dans cet exemple, nous utilisons la fonction stop. PublishBinaryMessage renvoie un ID de publication. Nous utiliserons ce même ID de publication pour arrêter la publication du message sur l'émetteur-récepteur NFC.

L'extrait de code suivant montre comment écrire des données sur une étiquette NFC :

JavaScript

var proximityDevice;

function getAlarmTime(){

    // Grab time set by the user, call this variable ‘Alarm’
    return Alarm;

}

function publishLaunchApp() {
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.GetDefault();

if (proximityDevice) {
        // The format of the app launch string is: "<args>\tWindows\t<AppName>".
        // The string is tab or null delimited.

        // The <args> string can be an empty string ("").
        var launchArgs = getAlarmTime();

        // The format of the AppName is: PackageFamilyName!PRAID.
        var praid = "AlarmApp"; // The Application Id value from your package.appxmanifest.

        var appName = Windows.ApplicationModel.Package.current.id.familyName + "!" + praid;

        var launchAppMessage = launchArgs + "\tWindows\t" + appName;

        var dataWriter = new Windows.Storage.Streams.DataWriter();
        dataWriter.unicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.utf16LE;
        dataWriter.writeString(launchAppMessage);
        var launchAppPubId =
             proximityDevice.publishBinaryMessage(
                 "LaunchApp:WriteTag", 
                 dataWriter.detachBuffer(), 
                 proximityWriteTagLaunchAppMessageTransmitCallback);
        
    if (launchAppPubId != -1) {
            // Stop publishing the message on NFC radio
        proximityDevice.stopPublishingMessage(launchAppPubId);
    }

     }
}

function proximityWriteTagLaunchAppMessageTransmitCallback() {
    // Inform the user that: the message has been successfully written to a tag & the tag no longer needs to be in range
}

Windows.Networking.Proximity.ProximityDevice proximityDevice;

private string GetAlarmTime(){

    // Grab time set by the user, call this variable ‘Alarm’
    return Alarm;
}

private void PublishLaunchApp()
{
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.GetDefault();

if (proximityDevice != null)
    {
        // The format of the app launch string is: "<args>\tWindows\t<AppName>".
        // The string is tab or null delimited.

        // The <args> string can be an empty string ("").
        string launchArgs = getAlarmTime();

        // The format of the AppName is: PackageFamilyName!PRAID.
        string praid = "MyAppId"; // The Application Id value from your package.appxmanifest.

        string appName = Windows.ApplicationModel.Package.Current.Id.FamilyName + "!" + praid;

        string launchAppMessage = launchArgs + "\tWindows\t" + appName;

        var dataWriter = new Windows.Storage.Streams.DataWriter();
        dataWriter.UnicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.Utf16LE;
        dataWriter.WriteString(launchAppMessage);
        var launchAppPubId =
        proximityDevice.PublishBinaryMessage(
            "LaunchApp:WriteTag", dataWriter.DetachBuffer(), 
            proximityWriteTagLaunchAppMessageTransmitCallback);
    
    if (launchAppPubId!= -1)
    {
        proximityDevice.StopPublishingMessage(launchAppPubId);
    // Stop publishing the message on NFC radio
    }

    }
}

private void proximityWriteTagLaunchAppMessageTransmitCallback(
    Windows.Networking.Proximity.ProximityDevice sender,
    long messageId)
{
        // Inform the user that: the message has been successfully written to a tag & the tag no longer needs to be in range
}

C'est tout ! Vous savez maintenant comment écrire des données sur une étiquette NFC à partir d'une application du Windows Store. Puisque la procédure est relativement simple, passons au scénario suivant et configurons une alarme à partir de l'étiquette. Examinons le processus permettant de lire une alarme à partir d'une étiquette NFC :

Mario lit son écran d'accueil, rédige un courrier électronique, joue à un jeu ou utilise Windows, et réalise qu'il doit régler une alarme pour lundi matin. Il attrape son étiquette « Alarme semaine » et la met en contact avec son PC. Un toast s'affiche pour l'inviter à lancer son application Alarme. Pour le moment, Windows s'occupe de tout et votre application n'a pas encore été utilisée.
Mario accepte. Votre application démarre et affiche un écran « Confirmer l'alarme ? » qui indique 7 h. Une fois le toast accepté par Mario, Windows transmet les arguments de lancement (comme ci-dessus) à votre application lors de l'activation. Nous désignons cette opération par le terme « lancement contextuel ». Cela revient à ouvrir votre application sur une page spécifique.
Mario configure l'alarme. Cette opération est totalement classique et n'implique pas la technologie NFC.

Il est relativement simple d'obtenir les arguments de lancement auprès de l'étiquette NFC. L'application doit gérer un lancement contextuel à partir d'une étiquette NFC. Le lancement contextuel revient à ouvrir votre application sur une page spécifique. Nos arguments de lancement configurent l'alarme sur 7 h et votre application utilise cette information pour afficher l'alarme proposée. En outre, si jamais votre application n'est pas installée sur le PC, Windows invite Mario à installer votre application à partir du Windows Store, le tout de façon automatisée !

L'extrait de code suivant montre comment mettre en œuvre le lancement contextuel.

JavaScript

app.onactivated = function (args) {
    if (args.detail.kind === activation.ActivationKind.launch) {
        if (args.detail.arguments == "Windows.Networking.Proximity.PeerFinder:StreamSocket") {
            //do nothing here.
        }
        else {
    // Use args.detail.arguments to parse out ’07.00’ string, and display to the user
        }

        args.setPromise(WinJS.UI.processAll());
    }
}

async protected override void OnLaunched(LaunchActivatedEventArgs args)
        {
            if (args.Arguments == "Windows.Networking.Proximity.PeerFinder:StreamSocket")
            {
                _isLaunchedByTap = true;
            }
            else
            {
// Use args.Arguments to parse out ’07.00’ string, and display to the user

            }
            Window.Current.Activate();
        }

Tout cela suffit pour que votre application prenne en charge la lecture des étiquettes NFC et l'écriture sur ces étiquettes : plutôt simple, pour un scénario vraiment innovant ! Avant de conclure, évoquons une bonne pratique : la gestion des erreurs.

Gestion des erreurs

Votre application est susceptible de rencontrer un certain nombre d'erreurs courantes.

L'étiquette mise en contact n'est pas au format NDEF. Windows 8 ne prend pas en charge la conversion automatique des étiquettes au format NDEF. Par conséquent, vous devez télécharger et installer un outil de mise en forme NDEF.
L'étiquette mise en contact est en lecture seule. Certaines étiquettes NFC peuvent être verrouillées en lecture seule (comme ces bonnes vieilles cassettes VHS).
L'étiquette mise en contact est trop petite et ne peut pas stocker toutes les données.
Le PC de l'utilisateur ne possède pas d'émetteur-récepteur NFC. Comme je l'ai expliqué au début de ce billet, la technologie NFC est encore émergente, mais son adoption à grande échelle est en cours. Pour savoir si un PC prend en charge les transferts de proximité, utilisez la méthode ProximityDevice.getDefault(). Elle renvoie la valeur NULL si aucun émetteur-récepteur radio n'est installé.

Une technologie aussi amusante qu'intuitive

La technologie NFC est enfin à la portée du grand public : Windows possède l'écosystème requis et une expérience utilisateur complète extrêmement bien conçue. Le potentiel de cette technologie est immense et devrait rendre les applications et les expériences utilisateur des appareils incroyablement interactives. Son fonctionnement est amusant et intuitif.

Le NFC est un domaine très vaste et nous publierons probablement d'autres billets de blog pour présenter d'autres fonctionnalités NFC mises en œuvre par des développeurs sur Windows 8.

Pour plus d'informations sur le NFC et les transferts de proximité, consultez les ressources ci-dessous.

Ressources

Lien	Type
Recommandations sur le développement avec la fonctionnalité de proximité	Document
API de proximité	Document
Test de la fonctionnalité de proximité et résolution des problèmes connexes dans les applications	Document
Publication et abonnement (plus de détails)	Document
Exemple d'application de proximité	Exemple
Une question sur les fonctions de proximité ? Posez-la ici !	Forum

Merci !

Priya Dandawate
Chef de projet, Appareils et mise en réseau

Avec la participation de Max Morris, Marzena Makuta, Mike Loholt, Jake Sabulsky et Vishal Mhatre

Créer des applications Windows Store connectées

Windows 8 Team — Wed, 17 Apr 2013 20:56:03 GMT

De plus en plus, nous sommes entourés de nombreux appareils connectés à un réseau. Même les dernières générations de réfrigérateurs et de machines à laver peuvent aussi se connecter à Internet et aux réseaux domestiques. Sans surprise, l'utilisateur final attend de ses applications qu'elles soient elles aussi connectées. Ces « applications connectées » exploitent les derniers contenus du Web : médias sociaux, médias numériques, blogs et autres types de contenus. Le développement d'applications connectées est désormais la norme. Néanmoins, il est parfois difficile de résoudre certains problèmes courants : perte de connectivité réseau, coûts liés à une connexion réseau limitée, problèmes de performances, etc. Avec Windows 8, il est plus facile que jamais de développer une application connectée.

Dans ce billet, nous dévoilons quelques conseils utiles qui vous aideront à proposer aux utilisateurs de vos applications du Windows Store une expérience connectée, rapide, fluide et sans la moindre complication :

Sélectionner l'API adaptée à vos scénarios
Choisir les fonctionnalités réseau adéquates
Adapter le comportement de l'application aux connexions réseau limitées
Réagir aux changements d'état du réseau
Mettre le contenu en cache pour plus de fluidité

Examinons en détail chacun de ces conseils.

Sélectionner l'API adéquate

Lorsque vous construisez une maison, vous devez disposer des bons outils. Vous avez besoin d'un marteau pour enfoncer les clous, d'une scie pour couper des panneaux et d'un tournevis pour fixer vos vis. De la même manière, lorsque vous développez une application du Windows Store connectée, vous devez utiliser les API de réseau adéquates. Windows 8 offre plusieurs API de réseau que votre application peut exploiter pour communiquer avec d'autres ordinateurs et appareils, via Internet ou des réseaux privés. Pour commencer, vous devez déterminer de quelles fonctionnalités réseau votre application a besoin.

Le scénario de mise en réseau le plus courant consiste à accéder à un site Web pour récupérer ou stocker des informations. Un jeu utilisant un site Web pour stocker les informations relatives aux utilisateurs et leurs scores fait partie des exemples les plus simples. De façon plus complexe, une application peut aussi se connecter à un service Web REST et utiliser une bibliothèque fournie par le service Web pour accéder à des informations ou les stocker. Windows 8 possède plusieurs API qui se connectent aux services Web et aux sites Web. Grâce à ces API, votre application peut accéder aux services Web compatibles REST ou envoyer des commandes de base du protocole HTTP (GET et POST, par exemple) à un serveur Web. Dans le cas d'un accès Web, l'API à utiliser dépend du langage de développement de l'application :

XMLHTTPRequest et WinJS.xhr : applications écrites en JavaScript et HTML.
HttpClient : applications écrites en C# ou en Visual Basic .NET et XAML.
XML HTTP Request 2 (IXHR2) : applications écrites en C++ et XAML.

Le code ci-dessous montre comment réaliser une opération de requête/réponse élémentaire à l'aide d'un service Web REST. Dans ce cas, le service Web peut exécuter un script ASP.NET sur le serveur Web.

JavaScript

function makeXHRCall() {
    WinJS.xhr({ uri: "http://www.microsoft.com/en-us/default.aspx” }).done(
        function onComplete(result) {
            print(result.responseText);
        },
        function onError(err) {
            print("Error: " + err.responseText);
        });
}

private async void MakeHttpCall()
{
    HttpClient httpClient = new HttpClient();
    try {
        string response = await httpClient.GetStringAsync("http://www.microsoft.com/en-us/default.aspx");
    }
    catch (Exception) {
        // Handle exception.
    }
}

Pour plus d'informations sur WinJS.xhr, voir Connexion aux services Web (applications du Windows Store en JavaScript et HTML). Pour plus d'informations sur HttpClient, voir Démarrage rapide : connexion à l'aide de HttpClient (applications du Windows Store en C#/VB/C++ et XAML) et l'exemple HttpClient.

Autre scénario courant de mise en réseau : les opérations de téléchargement ou de chargement de fichiers qui peuvent être relativement longues. Il peut par exemple s'agir d'une application d'appareil photo ou de galerie qui doit charger ou télécharger des albums photo auprès d'un service Web. Ces transferts pouvant prendre du temps, il est impensable d'obliger l'utilisateur à patienter jusqu'à la fin du transfert. L'API Windows.Networking.BackgroundTransfer offre la possibilité de télécharger ou de charger des fichiers même lorsque votre application n'est plus en cours d'exécution. L'application lance le transfert lorsqu'elle est exécutée au premier plan, puis Windows 8 poursuit le transfert en arrière-plan même lorsque l'application n'est plus en cours d'exécution.

L'accès à du contenu syndiqué fait partie des scénarios plus spécialisés. L'API Windows.Web.Syndication peut récupérer des flux au format RSS ou Atom. Par ailleurs, l'API Windows.Web.AtomPub permet à une application de publier des données dans différents formats AtomPub.

Pour les scénarios dans lesquels un protocole de haut niveau spécifique n'est pas disponible via une API, Windows Runtime prend également en charge les sockets TCP et UDP (ainsi que la multidiffusion). L'API Windows.Networking.Sockets fournit un socket StreamSocket (TCP) et un socket DatagramSocket (UDP), pour vous permettre d'implémenter d'autres protocoles de plus haut niveau.

Remarque : Windows 8 possède un nouveau type de socket appelé WebSocket. Pour obtenir plus d'informations sur les sockets WebSocket et pour savoir dans quels cas les utiliser, voir Connexion à l'aide de sockets WebSocket.

Le tableau ci-dessous contient une liste plus complète des fonctionnalités réseau prises en charge, ainsi que des liens permettant d'accéder à des informations complémentaires.

API

Fonctionnalité

Exemples

Windows.Web.Syndication

Windows.Web.AtomPub

Récupération de flux au format RSS ou Atom (plusieurs versions compatibles). Ces API facilitent l'implémentation de la prise en charge de formats plus récents tels qu'OData. Windows Runtime prend également en charge le protocole Atom Publishing Protocol, ce qui lui permet de publier des collections Atom.
Pour plus d'informations, voir Accès et gestion du contenu syndiqué.

Exemple de syndication

Exemple AtomPub

Lecteurs RSS

Windows.Networking.BackgroundTransfer

Téléchargement et chargement du contenu sans interruption, à moindre coût et avec possibilité de reprise, même lorsque l'application appelante n'est pas au premier plan. Cette API prend en charge le transfert de contenu via les protocoles HTTP, HTTPS et FTP.
Pour plus d'informations, voir Transfert de données en arrière-plan.

Exemple de transfert en arrière-plan

SkyDrive

Vidéo Xbox

XMLHTTPRequest (JavaScript)

WinJS.xhr (JavaScript)

HttpClient (C#)

XML HTTP Request 2 (IXHR2) (C++)

Interaction avec les services Web REST et d'autres protocoles HTTP.
Pour plus d'informations, voir Connexion aux services Web.

XHR, gestion des erreurs de navigation et exemple de schémas d'URL

Exemple HttpClient

Bing Cartes

Windows.Networking.Proximity

Détection de la proximité entre deux appareils, après quoi les applications peuvent déclencher une communication réseau entre elles à l'aide d'API de socket.
Pour plus d'informations, voir Prise en charge de la fonctionnalité de proximité et du geste tactile.

Exemple de proximité

Jeux

Applications de collaboration

Windows.Storage.Pickers

Communication avec des partages de fichiers distants.
Pour plus d'informations, voir Accès aux données et aux fichiers.

Exemple de sélecteur de fichiers

Xbox Music

Photos

Windows.Networking.Sockets

Connexion à un service qui utilise un protocole non pris en charge par les API déjà mentionnées, tel que SMTP, MAPI ou telnet, ou connexion à un autre appareil situé sur le même réseau local. Également utilisée pour les applications qui nécessitent une sémantique similaire à celle d'un socket (communication asynchrone et bidirectionnelle) pour la connexion via le Web (y compris via des proxys HTTP) à un nouveau service.
Pour plus d'informations, voir Connexion à l'aide de sockets.

Exemple de socket StreamSocket

Exemple de socket DatagramSocket

Exemple de connexion à l'aide de sockets WebSocket

Exemples ControlChannelTrigger

Lync, tableau blanc collaboratif ou stock-picking

Windows.Storage.ApplicationData

Windows 8 convertit automatiquement certaines données d'applications entre les appareils des utilisateurs. L'itinérance des données des applications est utile lorsque l'utilisateur possède plusieurs appareils (un PC au travail et une tablette à son domicile, par exemple) et il installe l'application sur ces différents appareils.
Pour plus d'informations, voir Recommandations en matière de données d'application itinérantes.

Exemple de données d'application

Choisir les fonctionnalités réseau adéquates

L'isolement réseau fait partie du modèle de sécurité utilisé par Windows 8. Windows détecte de façon active les limites du réseau et met en application des restrictions d'accès réseau pour l'isolement réseau. Déployées correctement, ces fonctionnalités vous aident à protéger les utilisateurs et les applications contre les attaques malveillantes.

Les applications doivent déclarer des fonctionnalités d'isolement réseau pour pouvoir définir le périmètre de l'accès réseau. En l'absence de déclaration de ces fonctionnalités, votre application n'aura pas accès aux ressources réseau. Pour en savoir plus sur la manière dont Windows applique l'isolement réseau pour les applications, voir Comment définir les fonctionnalités réseau.

Sachez que vous ne pouvez pas utiliser la mise en réseau comme mécanisme de communication entre processeurs, entre une application du Windows Store et une application de bureau sur un même appareil. Par conséquent, vous ne pouvez pas utiliser des adresses de bouclage IP dans une application du Windows Store. Il existe quelques exceptions à cette règle, prévues à des fins de développement. Elles permettent d'utiliser des adresses de bouclage IP dans le débogueur Visual Studio. Pour plus d'informations, voir Comment activer le bouclage et résoudre les problèmes liés à l'isolement réseau.

Les requêtes d'accès réseau se répartissent en deux catégories :

Requêtes sortantes initiées par le client : votre application joue le rôle de client et initie un accès réseau en envoyant une requête réseau initiale à un ordinateur distant (un serveur, en général). L'application envoie une ou plusieurs requêtes au serveur, puis le serveur renvoie une ou plusieurs réponses. Par exemple, le trafic entre une application de client Web et un serveur Web entre dans cette catégorie.
Requêtes sortantes non sollicitées : votre application joue le rôle de serveur réseau et écoute les requêtes réseau entrantes issues d'un ordinateur distant. L'ordinateur distant initie un accès réseau en envoyant une requête initiale à votre application, qui joue le rôle de serveur. L'ordinateur distant envoie une ou plusieurs requêtes à votre application, qui renvoie une ou plusieurs réponses à l'ordinateur distant. Par exemple, une application jouant le rôle de serveur multimédia entre dans cette catégorie.

Suivez le principe des privilèges minimum et ajoutez uniquement les fonctionnalités dont votre application a besoin. Ainsi, votre application peut n'avoir besoin que de requêtes sortantes initiées par le client ou au contraire pouvoir recevoir des requêtes entrantes non sollicitées. Certaines applications ont aussi besoin d'accéder aux informations et aux certificats de l'utilisateur pour s'authentifier sur un réseau.

Le tableau ci-dessous détaille les fonctionnalités d'isolement réseau et les autres fonctionnalités similaires souvent requises par les applications connectées. Les trois premières correspondent aux fonctionnalités d'isolement réseau principales que les applications connectées utilisent. En fait, votre application connectée doit activer au moins l'une de ces trois premières fonctionnalités. Les autres entrées de la table correspondent à des fonctionnalités complémentaires souvent requises par certaines applications connectées.

Fonctionnalité réseau

Description

Exemples d'applications

Internet (client)

Fournit un accès sortant à Internet et aux réseaux situés dans des lieux publics (aéroports, cafés, etc.). La plupart des applications nécessitant un accès à Internet doivent déclarer cette fonctionnalité.

Lecteurs RSS

Réseaux sociaux

Jeux

Internet (client et serveur)

Fournit à la fois un accès entrant et un accès sortant à Internet et aux réseaux situés dans des lieux publics (aéroports, cafés, etc.). L'accès entrant aux ports critiques est toujours bloqué. Cette fonctionnalité est un sur-ensemble de la fonctionnalité Internet (client). Il n'est pas nécessaire de déclarer les deux.

Applications P2P

Jeux multijoueurs détectant les joueurs par le biais d'une multidiffusion.

Réseaux privés (client et serveur)

Fournit un accès réseau entrant et sortant dans les liens privés approuvés par l'utilisateur. Il s'agit généralement de réseaux domestiques ou de réseaux d'entreprise. L'accès entrant aux ports critiques est toujours bloqué.

Applications qui accèdent au contenu d'un NAS (Network Attached Storage)

Applications métier

Jeux multijoueurs détectant les joueurs par le biais d'une multidiffusion sur un réseau privé (réseau domestique ou réseau d'entreprise).

Proximité

Fonctionnalité requise pour la communication en champ proche avec des appareils. Permet aux applications d'accéder au réseau pour se connecter à un appareil situé à proximité, en demandant à l'utilisateur d'envoyer ou d'accepter une invitation.

Jeux multijoueurs dont les joueurs sont très proches les uns des autres

Authentification en entreprise

Offre la possibilité de se connecter aux ressources intranet d'entreprise qui nécessitent des informations d'identification de domaine.

Applications métier

Certificats utilisateur partagés

Offre la possibilité d'accéder aux certificats logiciels et matériels (certificats sur carte à puce, par exemple) pour valider l'identité d'un utilisateur. Lorsque les API associées sont appelées au moment de l'exécution, l'utilisateur doit entreprendre une action (insérer une carte, sélectionner un certificat, etc.).

Applications de réseau privé virtuel

Applications métier

Servez-vous de cette liste pour vérifier que l'isolement réseau est configuré dans votre application :

Déterminez le sens de l'accès réseau dont votre application a besoin : requêtes sortantes initiées par le client, requêtes entrantes non sollicitées ou les deux à la fois.
Déterminez le type de ressources réseau avec lesquelles votre application communiquera : ressources approuvées sur un réseau domestique ou un réseau d'entreprise, ressources hébergées sur Internet ou les deux à la fois.
Configurez les fonctionnalités minimales requises pour l'isolement réseau dans le manifeste de l'application. Pour cela, vous pouvez utiliser le concepteur de manifeste de Microsoft Visual Studio 2012 ou les ajouter manuellement.
Déployez et exécutez votre application afin de la tester en utilisant les outils d'isolement réseau fournis pour le dépannage. Pour plus d'informations, voir Comment activer le bouclage et résoudre les problèmes liés à l'isolement réseau.

La capture d'écran ci-dessous montre comment activer les fonctionnalités d'isolement réseau à l'aide du concepteur de manifeste de Microsoft Visual Studio 2012.

Sélectionnez les fonctionnalités réseau dans le fichier package.appxmanifest de votre application dans Visual Studio 2012

Adapter le comportement de l'application aux connexions réseau limitées

Réfléchissez à la dernière fois que vous avez atteint les limites de votre forfait données ou que vous avez voyagé à l'étranger. Dans ces situations, personnellement, je finis par utiliser mon appareil et les applications avec une extrême précaution pour empêcher une lourde facturation réseau.

Windows 8 résout ce problème pour l'utilisateur en permettant aux applications de surveiller les ressources réseau disponibles et d'adopter le comportement adéquat sur les connexions réseau limitées. Pour que l'utilisateur ait toujours plus confiance dans vos applications, vous pouvez permettre à votre application de savoir quand une connexion peut engendrer des coûts et adapter son comportement pour réduire ou éliminer ces coûts.

L'API Windows.Networking.Connectivity fournit des informations sur le type et le coût d'une connexion réseau limitée. Ainsi, votre application peut déterminer s'il est préférable d'utiliser les ressources réseau normalement, de façon restrictive, ou de poser la question à l'utilisateur.

Une classe ConnectionProfile représente une connexion réseau. Votre application peut utiliser la classe ConnectionCost d'une classe ConnectionProfile pour déterminer si son comportement doit ou non être adapté. La propriété NetworkCostType indique le type de connexion réseau. Il existe quatre valeurs possibles :

Unrestricted (sans restriction) : cette connexion réseau peut être utilisée de façon illimitée. Aucuns frais ne sont facturés en fonction de l'utilisation ou de la capacité.
Fixed (fixe) : cette connexion réseau peut être utilisée de façon illimitée jusqu'à une certaine limite.
Variable (variable) : cette connexion réseau est facturée selon la consommation (en octets).
Unknown (inconnu) : les informations de tarification de cette connexion réseau ne sont pas disponibles.

Plusieurs autres propriétés booléennes de la classe ConnectionCost fournissent d'autres informations.

Roaming : la connexion est établie avec un réseau situé à l'extérieur du périmètre domestique.
ApproachingDataLimit : la connexion approche de la limite d'utilisation spécifiée dans le forfait.
OverDataLimit : la connexion a dépassé la limite d'utilisation spécifiée par le forfait.

Vous pouvez faire en sorte que votre application réagisse aux conditions indiquées par ces propriétés. Chaque fois qu'une connexion a la valeur Roaming, les coûts de transfert de données associés à l'utilisateur du réseau peuvent être élevés. Lorsque la valeur de la propriété NetworkCostType est Variable, l'application utilise une connexion réseau limitée : l'utilisateur est facturé en fonction de la quantité de données envoyées ou reçues sur le réseau. Lorsque la valeur de la propriété NetworkCostType est Fixed, mieux vaut limiter les transferts de données si l'utilisateur a déjà dépassé la limite ou s'en approche.

En utilisant ces informations, une application peut respecter ces recommandations afin de décider comment utiliser au mieux les ressources réseau.

Comportement

Coût de la connexion

Recommandations relatives à l'application

Exemples

Normal

La valeur de NetworkCostType estUnrestricted ou Unknown, et la valeur de ConnectionCost n'est pas Roaming

L'application n'applique aucune restriction. Elle considère la connexion comme étant de type Unlimited, c'est-à-dire illimitée en termes de coût, et non limitée par l'utilisation ou la capacité.

Un lecteur multimédia peut lire un film HD en entier.

L'application peut télécharger des fichiers sans appliquer de limite ni afficher un message destiné à l'utilisateur.

Prudent

La valeur de NetworkCostType est Fixed ou Variable, et la valeur de ConnectionCost n'est pas Roaming ni OverDataLimit

L'application applique des restrictions pour optimiser l'utilisateur du réseau, afin de traiter les opérations sur les connexions réseau limitées.

Un lecteur multimédia peut lire des films en basse résolution.

L'application peut retarder les téléchargements qui ne sont pas indispensables.

Sur demande

La valeur de ConnectionCost est Roaming ou OverDataLimit

L'application gère les cas exceptionnels où le coût de l'accès réseau est vraiment supérieur à celui du forfait.

L'application demande à l'utilisateur si elle peut accéder au réseau.

L'application suspend l'ensemble des activités d'arrière-plan de transfert de données via le réseau.

Cet exemple de code vérifie le coût de la connexion et renvoie des suggestions de comportement adéquat.

JavaScript

var CostGuidance = { Normal: 0, Conservative: 1, OptIn: 2 };
// GetCostGuidance returns an object with a Cost (with value of CostGuidance), 
// CostName (a string) and Reason, which says why the cost is what it is.
function GetCostGuidance() 
{
    var connectionCost = Windows.Networking.Connectivity.NetworkInformation.getInternetConnectionProfile().getConnectionCost();
    var networkCostConstants = Windows.Networking.Connectivity.NetworkCostType;
    var Retval = new Object();
    if (connectionCost.roaming || connectionCost.overDataLimit)
    {
        Retval.Cost = CostGuidance.OptIn;
        Retval.CostName = "OptIn";
        Retval.Reason = connectionCost.roaming
            ? "Connection is roaming; using the connection may result in additional charge."
            : "Connection has exceeded the usage cap limit.";
    }
    else if (connectionCost.networkCostType == networkCostConstants.fixed
        || connectionCost.networkCostType == networkCostConstants.variable)
    {
        Retval.Cost = CostGuidance.conservative;
        Retval.CostName = "Conservative";
        Retval.Reason = connectionCost.networkCostType == NetworkCostType.fixed
            ? "Connection has limited allowed usage."
            : "Connection is charged based on usage. ";
    }
    else
    {
        Retval.Cost = CostGuidance.Normal;
        Retval.CostName = "Normal";
        Retval.Reason = connectionCost.networkCostType == networkCostConstants.unknown
            ? "Connection is unknown."
            : "Connection cost is unrestricted.";
    }

    return Retval;
}

public enum NetworkCost { Normal, Conservative, OptIn };
public class CostGuidance
{
    public CostGuidance()
    {
        var connectionCost = NetworkInformation.GetInternetConnectionProfile().GetConnectionCost();
        Init(connectionCost);
    }
    public NetworkCost Cost { get; private set; }
    public String Reason { get; private set; }


    public void Init(ConnectionCost connectionCost)
    {
        if (connectionCost == null) return;
        if (connectionCost.Roaming || connectionCost.OverDataLimit)
        {
            Cost = NetworkCost.OptIn;
            Reason = connectionCost.Roaming
                ? "Connection is roaming; using the connection may result in additional charge."
                : "Connection has exceeded the usage cap limit.";
        }
        else if (connectionCost.NetworkCostType == NetworkCostType.Fixed
            || connectionCost.NetworkCostType == NetworkCostType.Variable)
        {
            Cost = NetworkCost.Conservative;
            Reason = connectionCost.NetworkCostType == NetworkCostType.Fixed
                ? "Connection has limited allowed usage."
                : "Connection is charged based on usage. ";
        }
        else
        {
            Cost = NetworkCost.Normal;
            Reason = connectionCost.NetworkCostType == NetworkCostType.Unknown
                ? "Connection is unknown."
                : "Connection cost is unrestricted.";
        }
    }
}

Utilisez l'exemple d'informations réseau pour en savoir plus sur l'adaptation du comportement de votre application aux connexions réseau limitées.

Les utilisateurs peuvent également exécuter le Gestionnaire des tâches pour connaître la consommation de données réseau de chaque application. La capture d'écran ci-dessous montre un exemple de ce comportement.

L'onglet Historique des applications du Gestionnaire des tâches permet aux utilisateurs de connaître les quantités de ressources processeur et de ressources réseau consommées par les applications

Réagir aux changements d'état du réseau

Dans n'importe quel scénario impliquant un appareil mobile, les réseaux peuvent disparaître et réapparaître à tout moment. Un réseau haut débit mobile 3G ou 4G peut être hors portée dans la maison ou le garage de l'utilisateur, tandis que le Wi-Fi y sera plus facilement accessible. De même, le réseau Wi-Fi peut devenir hors portée lorsque l'utilisateur quitte son domicile. Il peut également arriver qu'aucun réseau ne soit disponible. Avec la prolifération des réseaux haut débit Wi-Fi et mobiles, les changements de réseau sont très fréquents.

Un événement NetworkStatusChanged indique que le coût disponible ou les options de connectivité ont peut-être changé. Pour réagir aux changements d'état du réseau et proposer à l'utilisateur une expérience client transparente dans cette situation, faites en sorte que vos applications connectées respectent les recommandations de ce scénario.

Perte de connexion en raison d'une erreur

Dans la plupart des cas, les connexions peuvent être rétablies en réessayant l'opération réseau. En cas d'échec, attendez un événement NetworkStatusChanged. Nous recommandons aux applications d'utiliser un intervalle d'interruption croissant entre les tentatives, en commençant par 50 millisecondes, puis en augmentant progressivement cet intervalle en cas d'échecs répétés.

Perte de réseau

Signalez à l'utilisateur que la connexion a été perdue, puis procédez à une inscription et attendez un événement NetworkStatusChanged.

Nouvelle disponibilité réseau

Dans certains cas, l'appareil est connecté à plusieurs réseaux. Par exemple, un utilisateur peut être connecté à un réseau mobile et converser en ligne avec des amis via l'application Messagerie de Windows 8, puis arriver à son domicile et se connecter au réseau illimité disponible. Par défaut, Windows 8 privilégie les réseaux illimités par rapport aux réseaux limités, ainsi que les réseaux plus rapides par rapport aux moins rapides. Cependant, les connexions existantes établies par une application ne basculent pas automatiquement sur un nouveau réseau. L'application doit être impliquée dans l'opération, car elle seule est capable de prendre la bonne décision quant au basculement ou non sur le nouveau réseau.

Par exemple, si un flux vidéo est presque terminé, il n'est peut-être pas judicieux de basculer sur le nouveau réseau. En revanche, si le réseau actuel perd des paquets ou est trop lent, ou si le transfert du flux risque de prendre encore beaucoup de temps, dans ce cas il est peut-être préférable de basculer sur le nouveau réseau.

Si vous déterminez qu'un changement de réseau est idéal dans les scénarios impliquant votre application, suivez ces recommandations lorsque vous détectez un nouveau réseau :

Vérifiez les coûts réseau du réseau existant et du nouveau réseau. S'il est judicieux de basculer sur le nouveau réseau, essayez d'établir une nouvelle connexion réseau et relancez l'opération réseau à partir des recommandations mentionnées ci-dessus. Windows sélectionne automatiquement le réseau illimité plutôt que le réseau à connexion limitée, et le réseau le plus rapide plutôt que le plus lent, le cas échéant.
Si la connexion avec le nouveau réseau est établie, utilisez cette nouvelle connexion réseau dans votre application et annulez l'opération réseau initiale sur le réseau précédent, si la connexion existe encore.

Changement de coût réseau

Un changement de coût réseau peut se produire lorsque la valeur de NetworkCostType est Fixed et que l'utilisation approche de la limite ou la dépasse. Un changement de coût réseau peut aussi se produire si la valeur de NetworkCostType devient Variable ou si la valeur de Roaming devient true. Dans ces cas, adaptez le comportement de l'application en fonction des recommandations énoncées pour le conseil précédent.

Ces exemples de code utilisent l'événement NetworkStatusChanged pour fournir une expérience utilisateur transparente au sein de l'application en cas de changements d'état du réseau de différente nature. Les deux exemples utilisent une variable booléenne globale appelée registeredNetworkStatusNotification, initialement définie sur false.

JavaScript

// Register for NetworkStatusChanged notifications, and display new 
// Internet ConnectionProfile info upon network status change.
function registerForNetworkStatusChange() {
    try {

        // Register for network status change notifications.
        if (!registeredNetworkStatusNotification) {
            var networkInfo.addEventListener("networkstatuschanged", onNetworkStatusChange);
            registeredNetworkStatusNotification = true;
        }
    }
    catch (e) {
        print("An unexpected exception occurred: " + e.name + ": " + e.message);
    }
}

// Event handler for NetworkStatusChanged event
function onNetworkStatusChange(sender) {
    try {
        // Get the ConnectionProfile that is currently used to connect 
        // to the Internet.
        var internetProfile = networkInfo.getInternetConnectionProfile();
        if (internetProfile === null) {
            print("Not connected to Internet\n\r");
        }
        else {
            internetProfileInfo += getConnectionProfileInfo(internetProfile) + "\n\r";
            print(internetProfileInfo);
        }
        internetProfileInfo = "";
    }
    catch (e) {
        print("An unexpected exception occurred: " + e.name + ": " + e.message);
    }
}

// Register for NetworkStatusChanged notifications, and display new 
// Internet ConnectionProfile info upon network status change.
void NetworkStatusChange()
{
    // Register for network status change notifications.
    try
    {
        var networkStatusCallback = new NetworkStatusChangedEventHandler(OnNetworkStatusChange);
        if (!registeredNetworkStatusNotification)
        {
            NetworkInformation.NetworkStatusChanged += networkStatusCallback;
            registeredNetworkStatusNotification = true;
        }
    }
    catch (Exception ex)
    {
        rootPage.NotifyUser("Unexpected exception occurred: " + ex.ToString(), NotifyType.ErrorMessage);
    }
}

// Event handler for NetworkStatusChanged event
async void OnNetworkStatusChange(object sender)
{
    try
    {
        // Get the ConnectionProfile that is currently used to connect 
        // to the Internet                
        ConnectionProfile InternetConnectionProfile = NetworkInformation.GetInternetConnectionProfile();

        if (InternetConnectionProfile == null)
        {
            await _cd.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                rootPage.NotifyUser("Not connected to Internet\n", NotifyType.StatusMessage);
            });
        }
        else
        {
            connectionProfileInfo = GetConnectionProfile(InternetConnectionProfile);
            await _cd.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                rootPage.NotifyUser(connectionProfileInfo, NotifyType.StatusMessage);
            });
        }
        internetProfileInfo = "";
    }
    catch (Exception ex)
    {
        rootPage.NotifyUser("Unexpected exception occurred: " + ex.ToString(), NotifyType.ErrorMessage);
    }
}

Pour en savoir plus sur l'événement NetworkStatusChanged, voir Démarrage rapide : gestion des événements de connexion et des changements de disponibilité et l'exemple d'informations réseau.

Mettre le contenu en cache pour plus de fluidité

La mise en cache des contenus sur le disque permet d'améliorer les performances et la fluidité de votre application. Par exemple, une application de lecture de flux RSS peut afficher immédiatement les flux qui ont été mis en cache sur le disque au cours d'une session précédente. Dès que les derniers flux sont disponibles, l'application met à jour son contenu. La mise en cache permet à l'utilisateur de disposer immédiatement du contenu, dès le lancement de l'application, pendant que celle-ci récupère les nouveaux contenus.

Windows 8 fournit la classe ApplicationData dans l'espace de noms Windows.Storage. Cette classe permet d'accéder au magasin de données de l'application. Ce magasin de données se compose de fichiers et de paramètres qui sont soit stockés en local sur l'appareil, soit transférés en itinérance sur plusieurs appareils, soit temporaires.

Les fichiers sont idéaux pour stocker de gros jeux de données, des bases de données volumineuses ou des données stockées dans un format de fichier courant. Les fichiers peuvent se trouver dans les dossiers Roaming, Local ou Temporary. Ces dossiers sont utilisés de façon différente :

Les fichiers du dossier Roaming sont synchronisés sur tous les ordinateurs et appareils auxquels les utilisateurs se connectent en utilisant des comptes connectés. L'itinérance des fichiers n'est pas instantanée : le système prend en considération plusieurs facteurs pour déterminer à quel moment envoyer les données. L'utilisation de données itinérantes doit rester en dessous du quota (accessible via la propriété RoamingStorageQuota). En cas de dépassement du quota, l'itinérance est suspendue. Les fichiers ne peuvent pas être déplacés pendant qu'une application est toujours en train d'écrire des données dans ces derniers. Pensez donc à fermer les objets fichier de votre application lorsqu'ils ne sont plus nécessaires.
Les fichiers du dossier Local ne sont pas synchronisés entre les différents ordinateurs et appareils. Ils restent stockés sur l'ordinateur ou l'appareil sur lequel ils ont été écrits initialement.
Les fichiers du dossier Temporary peuvent être supprimés s'ils ne sont pas utilisés. Le système prend en compte des facteurs tels que la capacité disponible sur le disque et l'ancienneté du fichier pour déterminer si un fichier temporaire doit ou non être supprimé.

Ces exemples de code mettent en cache du contenu sur le disque. La mise en cache de la réponse du serveur permet à votre application de présenter immédiatement le contenu à l'utilisateur après une fermeture et une réouverture. Pour plus de concision, ces exemples ne montrent pas comment écrire des paramètres dans le magasin de données de l'application, ni comment répondre aux événements d'itinérance. Ces détails sont en revanche abordés dans l'exemple de données d'application.

JavaScript

var roamingFolder = Windows.Storage.ApplicationData.current.roamingFolder;
var filename = "serverResponse.txt";

function cacheResponse(strResponse) {
    roamingFolder.createFileAsync(filename, Windows.Storage.CreationCollisionOption.replaceExisting)
        .done(function (file) {
            return Windows.Storage.FileIO.writeTextAsync(file, strResponse);
        });
}

function getCachedResponse() {
    roamingFolder.getFileAsync(filename)
        .then(function (file) {
            return Windows.Storage.FileIO.readTextAsync(file);
        }).done(function (response) {
            print(response);
        }, function () {
            // getFileAsync or readTextAsync failed. 
            // No cached response.
        });
}

MainPage rootPage = MainPage.Current;
StorageFolder roamingFolder = null;
const string filename = "serverResponse.txt";

async void cacheResponse(string strResponse)
{
    StorageFile file = await roamingFolder.CreateFileAsync(filename, CreationCollisionOption.ReplaceExisting);
    await FileIO.WriteTextAsync(file, strResponse);
}

async void getCachedResponse()
{
    try
    {
        StorageFile file = await roamingFolder.GetFileAsync(filename);
        string response = await FileIO.ReadTextAsync(file);
    }
    catch (Exception)
    {
        // getFileAsync or readTextAsync failed.
        // No cached response.
    }
}

Pour plus d'informations sur le magasin de données des applications, consultez le billet Itinérance des données de vos applications et essayez de mettre en œuvre l'exemple de données d'application.

Pour résumer

Lors de la planification de vos applications du Windows Store, suivez les recommandations énoncées dans ce billet pour proposer à l'utilisateur une expérience connectée, parfaite et sans la moindre complication. En suivant ces conseils, vous simplifierez vos processus de développement, tout en maintenant la fluidité de vos applications et en améliorant leur potentiel de confiance pour l'utilisateur.

- Suhail Khalid, chef de projet II, Windows

Avec la participation de Steven Baker et Peter Smith

Inscrivez-vous dès maintenant à la conférence //build/ 2013 !

Windows 8 Team — Fri, 05 Apr 2013 17:31:58 GMT

La semaine dernière, Steve Guggenheimer a annoncé la tenue de //build/ 2013. La conférence aura lieu du 26 au 28 juin 2013 au Moscone Center à San Francisco. //build/ est l'endroit idéal pour en apprendre davantage sur le développement d'applications du Windows Store. La conférence comprendra des présentations, des démonstrations, des sessions d'informations, etc. Nous sommes nombreux au sein de l'équipe de développement à nous rendre à San Francisco pour animer ces démonstrations et répondre à vos questions. La conférence est le meilleur endroit qui existe pour découvrir les dernières évolutions du développement d'applications du Windows Store.

Les inscriptions ont débuté le mardi 2 avril. Accédez au site www.buildwindows.com pour connaître tous les détails de la conférence et vous inscrire.

En espérant vous y rencontrer !

Prise en charge des applications du Windows Store dans la version jQuery 2.0

Windows 8 Team — Thu, 04 Apr 2013 18:38:30 GMT

Si vous avez déjà réalisé du développement Web, vous avez probablement utilisé l'infrastructure open source jQuery de JavaScript. Et si vous avez essayé de créer des applications du Windows Store avec jQuery, vous avez peut-être rencontré des erreurs liées à l'exécution de JavaScript ou au contenu dynamique. Avec la prochaine version v2.0, l'équipe jQuery a résolu ces problèmes. La version jQuery v2 bêta prend maintenant en charge le développement dans HTML5/JS pour les applications du Windows Store. En tant que développeur Web, vous pouvez utiliser vos compétences et ressources existantes pour concevoir de formidables applications pour Windows 8. Vous pouvez essayer la dernière version jQuery 2.0 bêta dès maintenant.

« L'équipe jQuery est très satisfaite des nouveaux environnements dans lesquels jQuery 2.0 peut être utilisé. Les développeurs HTML et JavaScript veulent tirer parti de leurs connaissances en jQuery pour rationaliser le processus de développement, quel que soit leur contexte de travail. jQuery 2.0 leur donne cette possibilité dans des environnements, tels que les applications du Windows Store. » - Dave Methvin, président, jQuery Foundation

Application du Windows Store : un contexte différent pour le code JavaScript

Vous pouvez vous demander pourquoi jQuery ne fonctionnait pas simplement auparavant. Toutes les applications du Windows Store, qu'elles soient écrites dans HTML/JS, C# ou C++, disposent d'un accès natif à Windows Runtime, de sorte qu'un nouveau modèle de sécurité a été créé pour aider vos applications à s'exécuter en toute sécurité sur la nouvelle plateforme. En outre, certaines des API courantes sur le Web ont été modifiées pour être en meilleure adéquation avec leur nouvel environnement natif. Ces différences peuvent entraîner des problèmes pour le code qui s'attendait à s'exécuter dans un navigateur. La plupart des problèmes sont liés au contenu dynamique. Vous avez peut-être reçu le message « HTML1701 : Impossible d'ajouter du contenu dynamique… » ou des exceptions du type « 0x800c001c - Erreur d'exécution JavaScript : Impossible d'ajouter du contenu dynamique... »

Pour en savoir plus sur ce modèle, consultez le billet Concevoir des applications de style Metro fiables et dignes de confiance. Consultez l'article sur les différences entre le contexte d'une application du Windows Store et un navigateur Web dans le Centre de développement Windows.

Mise à jour de jQuery pour la prise en charge du nouveau modèle

Comme vous le savez sans doute, jQuery est une infrastructure JavaScript très appréciée sur le Web, car elle simplifie le balayage et la manipulation des documents HTML, la gestion des événements, l'animation et Ajax avec une API facile à utiliser qui fonctionne sur de nombreux navigateurs.

Dans le but d'activer toutes ces fonctionnalités de jQuery dans vos applications du Windows Store, les experts jQuery sur appendTo ont collaboré avec la communauté jQuery pour actualiser jQuery et prendre en charge le nouveau modèle d'application Windows 8. Nos propres ingénieurs de la section Microsoft Open Technologies se sont chargés du support technique pour s'assurer que toutes les modifications tirent pleinement parti de la plateforme.

La prise en charge des applications du Windows Store dans jQuery impliquait des tests initiaux, le portage de tests unitaires et l'évaluation des dépendances jQuery, par exemple le moteur de sélection Sizzle, qui est au cœur de jQuery. appendTo a identifié plusieurs domaines dans la logique de prise en charge de jQuery, ainsi que certains composants dans Sizzle, utilisés pour cibler des éléments dans un document, qui devaient être recréés pour fonctionner conformément aux directives du modèle de sécurité des applications du Windows Store.

appendTo a soumis le code directement au projet jQuery Core, qui a intégré cette prise en charge. Vous bénéficiez donc maintenant de tous ces avantages gratuitement lorsque vous ajoutez jQuery dans votre application. Vous pouvez de plus essayer d'autres modèles lorsque vous utilisez jQuery dans une application du Windows Store. Pour en savoir plus sur ces modèles, consultez le site net.tuts+. Visitez le billet de blog d'appendTo pour en savoir plus sur les modifications apportées dans leurs mises à jour.

Essayons !

Si vous êtes un développeur HTML5 et JavaScript, vous pouvez concevoir des applications Windows 8 en vous appuyant sur vos connaissances et en utilisant vos bibliothèques et votre code JavaScript existants. Pour votre code jQuery, procédez à la mise à niveau vers jQuery 2.0 bêta et suivez les nouveaux modèles partagés par appendTo. Si vous n'utilisez pas jQuery, vous pouvez appliquer ces modèles et techniques à votre propre code et à vos bibliothèques pour les rendre entièrement compatibles avec Windows 8.

Si vous souhaitez savoir comment utiliser au mieux vos compétences en développement Web avec les plateformes Windows, consultez le billet de blog MS Open Tech.

--Olivier Bloch, Senior Technical Evangelist, MS Open Tech

Développement de jeux pour le Windows Store

Windows 8 Team — Fri, 29 Mar 2013 22:49:14 GMT

Avec ses formats d'appareils innovants, ses nouvelles architectures de processeur, ses modèles commerciaux attrayants et ses fantastiques opportunités, Windows 8 a profondément bouleversé l'univers des PC. Les jeux PC font depuis très longtemps partie des principaux usages des ordinateurs. Plus que jamais auparavant, les jeux montrent tout l'intérêt de ces nouveaux appareils. Grâce au Windows Store, il est désormais plus facile d'acquérir des jeux, d'y jouer, de les partager avec des amis et de les mettre à jour en toute sécurité. Rien d'étonnant donc à ce que les jeux soient à l'origine d'une quantité impressionnante de téléchargements, à ce qu'ils génèrent des revenus importants et à ce qu'ils attirent de nombreux utilisateurs sur la nouvelle plateforme. La GDC bat son plein et de plus en plus de développeurs de jeux souhaitent en savoir plus sur Windows 8.

Comment faire pour créer un jeu Windows Store de qualité ? Quelles sont les fonctionnalités offertes par Windows pour rendre votre jeu plus créatif, plus innovant, plus rentable et plus facile à développer ? Quels outils, quelles technologies et quels services sont à votre disposition ? En quoi l'écosystème peut-il vous aider ? Quelles sont les autres découvertes faites par les développeurs au cours du développement de jeux pour Windows 8 ? Ce billet tente de répondre à ces différentes questions et a pour objectif de vous aider à mieux comprendre comment vous pouvez vous aussi développer un jeu de qualité destiné au Windows Store.

Remarques sur la conception et le développement de jeux pour Windows 8

Windows 8 a été spécialement conçu et mis au point pour les divertissements. Les recommandations relatives à l'expérience utilisateur de Windows 8 encouragent l'utilisation d'images plein écran et les interactions rapides et fluides, sans bordures ni fioritures décoratives. Ces consignes de conception visent à recentrer l'application sur des expériences qui favorisent la fidélité de l'utilisateur et qui créent des interactions générant plus d'immersion. Les principales commandes du jeu doivent être facilement accessibles. Quant aux commandes secondaires, elles doivent être cachées dans une barre d'application ou dans un panneau de paramètres, tant qu'elles ne sont pas nécessaires. En quoi ces principes applicables aux applications en général affectent-ils les jeux ? Après tout, les développeurs de jeux proposent depuis longtemps des expériences rapides et fluides, immersives et en plein écran. Néanmoins, plusieurs questions se posent d'emblée :

De quelle manière les mécanismes d'un jeu prévu pour un PC de bureau puissant peuvent-ils être transposés sur des ordinateurs portables et sur des tablettes ?
Quels sont les principaux formats d'appareils à cibler ?
Est-il possible de créer des jeux adaptés à la fois au tactile, aux manettes de jeu et aux ensembles clavier/souris ?
Quelles sont les tailles d'écran, les proportions d'écran et les résolutions à privilégier ?

Depuis longtemps déjà, les développeurs de jeux utilisent un large éventail de technologies pour proposer des jeux divertissants aux utilisateurs de PC. Les API utilisées dans Windows ont beaucoup évolué au fil du temps. Avec Windows 8 vient s'ajouter une nouvelle plateforme de développement. L'API Windows Runtime regroupe les meilleures technologies issues des API antérieures et offre des améliorations importantes sur le plan des performances, de la sécurité, de la cohérence du développement et de la maintenance. Le Windows Store constitue un nouveau canal pour la découverte, la distribution et la maintenance des jeux. Ces nouvelles API génèrent toujours plus de valeur pour les développeurs de jeux ciblant le nouveau modèle de développement. Lorsque vous commencez à développer un jeu Windows Store, vous vous posez peut-être différentes questions :

Quelles sont les meilleures API Windows Runtime à utiliser pour développer des jeux ?
Dans quelle mesure les modèles de développement s'adaptent-ils aux différents genres de jeux ?
Comment puis-je porter mon code à partir d'autres plateformes ?
Comment puis-je mettre à jour mon code à partir d'anciennes versions de Windows ?
Quelles ressources de mon jeu sont susceptibles de nécessiter une mise à jour, le cas échéant ?
Quelles ressources sont à ma disposition pour réduire les coûts de développement ?
En quoi consiste le SDK DirectX ?

Le jeu réimaginé

Tous les jeux commencent par une bonne idée. La source de cette idée est très variable. Les idées vous parviennent parfois par hasard sous la douche ou dans la rue. Dans d'autres cas, elles résultent d'une approche collaborative et itérative impliquant toute une équipe. Une fois que l'idée est là, vous devez décider de quel type de jeu il s'agit. Vous souhaitez peut-être créer un nouveau jeu unique en son genre ou alors porter un jeu existant. Il peut s'agir d'un jeu de tir, d'un casse-tête ou d'un jeu de course. Quel que soit le genre auquel il appartient, il a sa place sur le Windows Store ! Vous trouverez peut-être de l'inspiration dans les études de cas consacrées aux jeux, présentées au cours de la conférence //build/. Si vous possédez un compte développeur Windows Store, vous pouvez parcourir les sous-catégories de jeux pour trouver des idées et découvrir les performances des différentes catégories de jeux dans différentes régions.

Recommandations en matière de conception de jeux

Une fois que vous avez décidé du jeu à créer, en prenant tout de suite les bonnes décisions, vous pourrez gagner beaucoup de temps par la suite en termes de développement. Les recommandations relatives aux catégories de jeux Windows 8 suggèrent des idées pour attirer toujours plus de joueurs et les fidéliser à travers des vignettes et des notifications. Vous y trouverez également des suggestions quant à la disposition globale à adopter et à la position des commandes principales et secondaires.

Cet article offre aussi des recommandations sur les interactions et sur la façon dont vous pouvez intégrer le tactile, des capteurs et des contrats à votre jeu. Les décisions relatives aux mécanismes du jeu et aux commandes doivent être prises le plus tôt possible pour délimiter l'étendue du développement. Cela dit, grâce à la plateforme Windows Runtime, il est plus facile que jamais de prendre en charge le tactile, les stylets et les souris avec le même code et vous n'avez donc pas besoin de concevoir des mécanismes spécifiques à chaque plateforme. Comme tous les PC Windows disposent de la place suffisante pour brancher une manette de jeu, ne laissez pas passer cette chance et pensez à inclure ce mécanisme de contrôle dans votre jeu.

Prévoyez également comment et à quel rythme vous comptez présenter les interactions du jeu et les mécanismes au joueur. En cas de lenteur, le jeu perd de son intérêt. S'il est trop rapide, il peut en revanche s'avérer frustrant. Mais surtout, choisissez le modèle de monétisation et la plateforme de commercialisation à utiliser. Le Windows Store vous permet de choisir votre modèle commercial. Plusieurs modèles sont proposés : jeu gratuit, achats dans l'application et contenus téléchargeables. Les jeux du Windows Store peuvent profiter des fonctionnalités intégrées de gestion des versions d'évaluation (limitées en temps ou en fonctionnalités). Vous avez aussi la possibilité de faire appel à un fournisseur de services de commercialisation tiers ou de déployer le vôtre. Quel que soit votre choix, ces questions doivent être prises en compte, car elles influent de façon significative sur le succès de votre jeu, tant en termes de revenus que de popularité.

Comme toutes les applications du Windows Store, les jeux doivent prendre en charge les différents états d'activation, d'affichage et de suspension. Les recommandations en matière de conception vous aident à définir comment et quand mettre votre jeu en pause ou le suspendre, et comment gérer les états d'affichage (plein écran, mode ancré ou mode rempli). Décidez également de quelle manière votre jeu prendra en charge les orientations paysage et portrait. Lorsque vous ajustez la résolution de tout ou partie des ressources de votre jeu aux différentes tailles d'écran, prenez en compte la taille des cibles. Par ailleurs, n'oubliez pas non plus de prendre en compte les proportions d'affichage, les résolutions, ainsi que les paramètres relatifs au nombre de points par pouce. Vous serez ainsi certain que le contenu de votre jeu pourra s'afficher correctement sur tous les écrans, quels que soient leur taille et le facteur d'échelle.

Enfin, n'oubliez pas de prendre en compte d'autres éléments susceptibles d'améliorer l'accessibilité de votre jeu et ses fonctionnalités sociales. Un mode à contraste élevé et des files d'attente audio supplémentaires améliorent la visibilité et la jouabilité, et favorisent ainsi la fidélisation des joueurs habitués à jouer dans de mauvaises conditions de luminosité ou souffrant de problèmes de vue. Par ailleurs, en exploitant les fonctionnalités intégrées à la plateforme en matière d'identité en ligne (authentification), d'itinérance des données et de partage avec d'autres applications, vous améliorez la fidélisation via les activités sociales (comparaison des résultats, parties sur différents PC, etc.).

Recommandations en matière de développement de jeux

DirectX est considérée comme étant au cœur de la plateforme de développement de jeux de Windows. Cependant, de nombreux autres composants ont été développés ou adaptés au SDK Windows 8, pour fournir les fonctionnalités dont la plateforme a besoin pour prendre en charge toute la diversité de l'écosystème des jeux Windows. Nous proposons une approche de développement complète et cohérente. Nous avons également intégré les bonnes pratiques recueillies au fil de développement de jeux sur d'autres plateformes. Mais surtout, nous avons observé deux objectifs architecturaux essentiels et mis l'accent sur ces deux objectifs. Les performances et la consommation électrique ont joué un rôle essentiel dans toutes les décisions prises relatives à l'architecture, comme nous l'avons expliqué dans le billet Étendue de l'accélération matérielle : les graphismes Windows 8. Le développement de jeux sur Windows 8 est une expérience fantastique, car l'intégralité de la plateforme a été conçue pour délivrer des expériences de divertissement rapides et fluides.

C++ avec DirectX est le langage de développement de prédilection des développeurs de jeux

Windows Runtime fournit un ensemble complet d'API exposant l'ensemble des nouveaux appareils et des capteurs de façon cohérente et pratique, pour simplifier la gestion des événements dans Windows. Un seul SDK Windows est proposé et toutes les API dont vous avez besoin pour développer un jeu Windows Store sont donc disponibles dans Microsoft Visual Studio 2012. Pour une expérience utilisateur encore plus fidèle et immersive, il peut être utile d'utiliser les API DirectX de Windows 8 lors de la création de jeux 3D. Il s'agit de la version de DirectX la plus simple à utiliser pour le développement de jeux. Elle prend en charge un large éventail de niveaux de fonctionnalités graphiques, de DirectX 9.1 aux dernières fonctionnalités matérielles exposées dans DirectX 11.1. Ainsi, vous pouvez adapter votre jeu à n'importe quel PC, qu'il s'agisse d'une tablette PC Windows 8 portable équipée d'un processeur ARM économe en ressources ou d'un PC de joueur overclocké embarquant plusieurs processeurs graphiques.

Si vous vous sentez à l'aise avec un langage de développement spécifique, vous pouvez réutiliser bon nombre de vos compétences et de votre expérience dans Windows 8. En effet, les jeux Windows Store peuvent être développés en combinant différentes technologies, selon le type de jeu que vous développez et vos préférences personnelles. Vous n'êtes en aucun cas contraint d'utiliser une syntaxe ou un modèle spécifique. Les développeurs de code managé peuvent créer des jeux 2D aussi beaux que fluides en XAML, un langage qui exploite pleinement les atouts et les fonctionnalités de la plateforme Windows Store. Si vous êtes développeur Web, vous pouvez exploiter vos compétences actuelles en matière de développement de sites et de jeux Web pour créer un jeu que vous pourrez ensuite monétiser par le biais du Windows Store. Pour les jeux interactifs en 3D, nous vous recommandons d'utiliser le langage C++ avec DirectX (et éventuellement XAML). Nous allons d'ailleurs utiliser cette combinaison dans la suite de cet article.

Composants utilisés dans le cadre du développement de jeux

Windows 8 offre une technologie de jeu intégrée. Elle est fournie dans chaque version du système d'exploitation et hébergée sur chaque PC, et vous n'avez donc pas à vous soucier de sa distribution ni à gérer plusieurs versions. Vous n'avez pas besoin de rechercher, de télécharger et d'installer des composants supplémentaires.

Figure 1 : composants et bibliothèques de développement de jeux pour Windows 8

Qu'il s'agisse de graphismes, de son, de saisie, d'entrées-sorties, de planification, de calcul ou de mise en réseau, tous les composants sont accessibles dans le langage de développement de votre choix. Les composants de bas niveau offrent plus de flexibilité, de possibilités de gestion des ressources et de performances, mais ils peuvent nécessiter du code supplémentaire pour contrôler intégralement le traitement et le flux des données requises. Avec C++, vous accédez directement au processeur graphique, au processeur central et aux services de bas niveau de la plateforme Windows 8, ce qui vous permet d'écrire du code extrêmement performant. Avec les nouvelles extensions de langage C++/CX, la syntaxe est désormais presque aussi simple que du C#. Vous pouvez gérer de façon transparente les objets grâce au comptage des références, tout en vous affranchissant des couches d'exécution, des nettoyages de mémoire et des comportements de compilation JIT, susceptibles de mettre à mal la fluidité de votre jeu.

Pour les graphismes 3D et 2D, les fichiers multimédias, les images et bon nombre d'autres composants de jeu, les technologies DirectX de Windows 8 fournissent un ensemble complet d'API, de composants et de bibliothèques sur lesquels vous pouvez vous appuyer. Pour une présentation complète, consultez le guide Prise en main du développement de jeux DirectX. La nouvelle pile graphique de Windows 8 est mieux intégrée et les composants Direct2D, Direct3D, DirectVideo et DirectCompute sont ainsi plus faciles à utiliser conjointement. Ils nécessitent en outre moins de ressources dupliquées qu'auparavant. Nous avons également ajouté une prise en charge intégrée des contrôleurs Xbox avec la bibliothèque XInput. Pour en savoir plus, consultez l'article Utilisation d’entrée et de contrôles dans votre jeu DirectX. Les API améliorées relatives à l'audio et au mixage des sons avec XAudio2 sont abordées dans la section Utilisation de l’audio dans votre jeu DirectX, tandis que les fonctions mathématiques simplifiées et les types sont abordés dans le Guide de programmation DirectXMath.

L'approche de développement en DirectX/C++ offre notamment un immense avantage : vous pouvez réutiliser des quantités importantes de code pour créer un jeu Windows Store (et un jeu pour le Bureau Windows), un jeu Windows Phone et un jeu Xbox 360. Les API DirectX s'appliquent à toutes les plateformes de jeu Microsoft. Tout ce dont vous avez besoin pour développer un fantastique jeu Windows est disponible dans le Runtime, le SDK Windows et Visual Studio 2012. Pour plus d'informations sur le SDK DirectX d'ancienne génération, voir Où se trouve le SDK DirectX ? Plusieurs modèles de développement complémentaires sont disponibles dans Windows 8. Un modèle hybride prenant en charge l'interopérabilité entre DirectX et XAML offre ce qui se fait de mieux en termes de possibilités de contrôle et de performances, et bénéficie en outre des avantages pratiques du kit de ressources d'interface utilisateur WinRT.

Outils de développement

Nous proposons de fantastiques outils conçus pour répondre aux besoins des développeurs de jeux Windows Store. Visual Studio 2012 intègre un modèle pour les applications DirectX du Windows Store qui vous aide à commencer à développer des jeux avec Direct3D. Le code du modèle fournit l'infrastructure de base pour la fourniture des affichages et la prise en charge des fenêtres, ainsi que les références vers tous les en-têtes et composants requis. D'autres modèles sont à votre disposition pour vérifier que vous respectez les bonnes pratiques, quel que soit le modèle de développement de jeux choisi.

Par ailleurs, de nouvelles fonctionnalités ont été ajoutées dans Visual Studio 2012 afin d'améliorer le développement, le débogage et le profilage des jeux. Les outils graphiques de Visual Studio 2012 ont été améliorés pour permettre une intégration transparente du développement d'applications graphiques. Vous pouvez travailler avec des modèles 3D, des textures d'affichage et des images, ou créer, modifier et compiler des nuanceurs HLSL sans jamais quitter votre interface IDE habituelle. Dans Visual Studio 2012, le débogage des applications DirectX utilisant beaucoup de graphismes est désormais plus intuitif, grâce à l'intégration des fonctionnalités de capture et de lecture des API graphiques (précédemment appelées Windows PIX).

Exemples et didacticiels

Ces exemples fournissent de nombreux échantillons de code source, qui vous permettront de vous lancer plus rapidement dans le développement de votre jeu. Chaque exemple se concentre sur une technologie ou une technique spécifique. Les didacticiels et les exemples ont été conçus selon une approche progressive. Ils sont classés dans un ordre logique, en commençant par une quantité de code limitée et une approche simple, pour vous aider à vous lancer. Chaque exemple supplémentaire vient compléter l'exemple précédent en y ajoutant un ou deux concepts complémentaires, jusqu'à aboutir à un jeu complet. L'article Écriture de code pour les applications du Windows Store dévoile un certain nombre d'informations à connaître sur l'écriture de code DirectX et C++ pour les applications du Windows Store.

Didacticiel Direct3D : ce didacticiel en cinq étapes montre comment initialiser Direct3D, effectuer des tracés en surface et afficher des mises à jour en surface à l'aide de la chaîne de permutation. Le « cube tournant » affiché par cet exemple est complété par d'autres exemples Direct3D. Si vous ne connaissez pas les API Direct3D, cet exemple est donc idéal pour démarrer.
Exemple tactile DirectX : cet exemple montre comment prendre en charge le tactile de façon minimale pour le cube tournant du didacticiel D3D. En particulier, il montre comment connecter vos mises à jour d'animation Direct3D aux événements tactiles fournis par Windows Runtime. Pour une navigation permettant de zoomer par pincement, consultez l'exemple de placage de relief.
Exemple de sprite Direct3D : cet exemple illustre une implémentation Direct3D des comportements des lots de sprites, similaires à l'API XNA SpriteBatch. Les sprites sont des bitmaps 2D qui peuvent être transformés et gérés indépendamment dans une scène 3D. Ils sont souvent utilisés dans des jeux 2D ou pour représenter des objets gourmands en ressources de calcul ou des objets distants dans les jeux 3D.
Exemple de chargement de ressources : cet exemple illustre une approche permettant de charger des ressources (nuanceurs, textures, maillages, etc.). (Vous remarquerez que chaque type de contenu possède une règle de génération correspondante dans le projet. Vous pouvez ajouter vos propres applications de traitement de contenu et créer vos propres règles pour les appeler.)
Exemple de placage de relief Direct3D : cet exemple montre comment utiliser le placage de relief en utilisant un mappage standard et un éclairage pixel par pixel. L'exemple fournit le code permettant d'éclairer un objet avec des ombres de surface à l'aide d'un mappage standard et d'une texture de couleur. Il implémente également une commande de zoom par pincement très basique, qui n'utilise pas la reconnaissance de mouvements.
Exemple de post-traitement Direct3D : cet exemple montre comment effectuer un post-traitement de la scène du cube tournant en utilisant des tampons intermédiaires sous-échantillonnés dans une application du Windows Store en C++ avec Direct3D. Il montre comment utiliser deux nuanceurs différents, selon le niveau de fonctionnalités du matériel. La cible de rendu intermédiaire peut être modifiée pour afficher le rendu sur une surface plus petite en vue d'améliorer les performances, puis être suréchantillonnée jusqu'à atteindre la résolution native de l'appareil, pour une qualité maximale.
Exemple de lecture de fichier audio AUDIO2 : cet exemple d'application montre comment incorporer les API XAudio2 pour ajouter des effets sonores interactifs à faible latence à votre jeu DirectX, afin d'améliorer l'expérience sonore.
Exemple de contrôleur de jeu XINPUT : cet exemple montre comment ajouter la prise en charge d'un contrôleur Xbox à votre jeu DirectX. Il lit l'entrée d'un contrôleur de jeu Xbox et affiche des données sur les mouvements du joystick analogique et les appuis sur les boutons. Il montre comment obtenir l'état d'entrée d'un contrôleur connecté et effectuer des tracés sur l'écran grâce à Direct2D et DirectWrite.
Exemple de 3D stéréoscopique Direct3D : Windows 8 prend en charge la 3D stéréo en tant que fonctionnalité centrale du système d'exploitation. Cette application montre comment incorporer la 3D stéréoscopique à votre jeu DirectX. Elle montre également comment répondre aux changements de stéréo système avec Direct3D.
Les versions d'évaluation et les achats dans l'application jouent un rôle crucial dans la réussite des jeux. Cet exemple montre comment utiliser l'API de gestion des licences fournies par le Windows Store pour déterminer l'état de la licence d'un jeu ou d'une fonctionnalité activée par un achat dans l'application.

Les exemples suivants sont des exemples de bout en bout qui associent les différentes techniques pour aboutir à des jeux complets :

Exemple de jeu 3D simple DirectX : cet exemple d'application de bout en bout et sa procédure de codage pas à pas montre comment intégrer différents types de contrôle et différentes techniques DirectX au sein d'un jeu simple de type FPS (jeu de tir). Si vous vous sentez à l'aise avec les concepts de base des différentes techniques illustrées dans les exemples, cet exemple est idéal pour observer tous les composants d'un jeu Windows Store Direct3D en action.
Exemple de jeu de tir en 3D avec XAML et DirectX : cet exemple illustre l'implémentation de bout en bout basique d'un jeu de tir en 3D avec DirectX (Direct3D 11.1, Direct2D, XInput et XAudio2) et XAML dans une application C++. Direct3D est utilisé pour afficher le rendu du contenu 3D. XAML est utilisé pour l'affichage tête haute et les messages d'état du jeu.
Exemple de jeu de labyrinthe avec DirectX : Cette application de jeu de bout en bout est un jeu de labyrinthe simple dans lequel le joueur doit faire rouler une bille dans un labyrinthe où se trouvent des trous, grâce à des commandes d'inclinaison. Elle montre comment regrouper tous les composants d'un jeu dans une seule et même application. Nous proposons également des conseils pas à pas pour cette application, sous forme de procédure de codage pas à pas complète.

Techniques de développement des jeux

En matière de développement de jeux, plusieurs modèles de développement, bonnes pratiques et techniques sont particulièrement utiles :

L'article Développement pour différents niveaux de fonctionnalités Direct3D vous aide à mieux comprendre comment optimiser le code pour de nombreux appareils offrant différents niveaux de performances graphiques. Vous pourrez ainsi cibler un public plus large avec votre jeu Windows Store conçu pour Windows à l'aide de DirectX et C++.
La programmation asynchrone permet à votre jeu de profiter des avantages des processeurs multicœurs et multithreads. Les graphismes, les éléments audio, la logique, les entrées-sorties de fichier et la mise en réseau peuvent être parallélisés pour améliorer les performances et l'autonomie de la batterie.
Utilisez la parallélisation à l'aide d'un pool de threads pour les jeux Windows Store, plutôt que des API traditionnelles de threading (CreateThread, par exemple). Le modèle de tâche est particulièrement important pour le rendu et pour garantir la réactivité de l'interface, comme expliqué dans ce billet.
L'article Prise en charge de l'orientation de l'écran porte sur la rotation de l'écran et sur la mise à l'échelle PPP du contenu et de l'entrée pour les applications DirectX. Ainsi, votre jeu aura plus de chances de fonctionner correctement sur des écrans de résolutions différentes.
L'article Ajout de contrôles de déplacement/vue à votre jeu détaille une technique traditionnelle de navigation de type souris, qui a été adaptée pour ajouter une prise en charge tactile au modèle de développement du Windows Store.
L'article Développement de contrôles basés sur la souris aborde l'implémentation de contrôles de souris relatifs, qui masquent le curseur système et renvoient des coordonnées d'écran relatives au lieu de valeurs absolues.
L'article Spécifications de publication de jeux Windows fournit aux développeurs de jeux Windows 8 des informations sur les outils et la prise en charge de scénarios de publication de jeux courants (certificat de classification, packaging, etc.).
L'article Prise en charge de Windows RT et des processeurs ARM explique comment adapter votre jeu Windows Store DirectX aux appareils Windows RT, en ciblant le niveau de fonctionnalités Direct3D 9_1 et en compilant un package ARM.

Utilisation de middleware à des fins de réduction du temps et du coût de développement

Le développement de jeux de qualité peut s'avérer coûteux. Le développement de jeux pour plusieurs plateformes peut être complexe, sujet aux erreurs et encore plus coûteux. De nombreux studios de jeux bien établis sur le marché créent des outils et développent des technologies de production qui leur permettent de créer leur propre processus de développement de jeux ou « pipeline ». Ces investissements aident les studios à exploiter leurs ressources de jeux sur différents jeux et différentes plateformes. Les moteurs de rendu, les kits de ressources d'interface utilisateur, l'occlusion de visibilité, les simulateurs de physique, les outils de création audio et vidéo, l'interpolation d'animations et l'intelligence artificielle font partie des catégories de technologies couramment mises en œuvre dans le cadre du développement de jeux. Le développement et l'optimisation de certaines technologies de jeux peuvent prendre plusieurs années.

Les pipelines de jeu propriétaires offrent une immense valeur ajoutée et de nombreux studios de développement considèrent que leurs investissements sont aussi stratégiques que les jeux qu'ils développent. Cependant, tout le monde n'a pas le temps ni l'argent nécessaires au développement d'un pipeline. Heureusement, des fournisseurs tiers proposent des pipelines de développement de jeux de bout en bout ou des bibliothèques technologiques individuelles qui permettent de profiter de ces fonctionnalités. Depuis la commercialisation de Windows 8, de nombreux fournisseurs de middleware ont porté leurs offres vers le nouveau modèle d'application du Windows Store. En utilisant ces produits, vous pourrez publier votre jeu bien plus rapidement sur le Windows Store et en prenant moins de risques. Au fil du temps, d'autres fournisseurs vont proposer d'autres produits pour le développement de jeux Windows Store. La liste ci-dessous (classée dans l'ordre alphabétique) indique quels fournisseurs de middleware de jeux tiers avaient, au moment de la rédaction de ce billet, annoncé ou commercialisé des versions de leur produit prenant en charge le développement de jeux Windows 8.

Appcelerator	appMobi {!}	Audiokinetic Wwise
Autodesk Scaleform	Cocos2d	Epic Unreal Engine 3
Exit Games Photon Server	Fortumo Mobile Payments	Firelight Technologies FMOD
GameSalad Creator	Havok Physics	Havok Vision Engine
MonoGame	Ogre Rendering Engine	NVIDIA PhysX
Scirra Construct 2	SharpDX	ShiVa3D
SlimDX	Unigine Engine	Unity 3d
Yoyo Games GameMaker

Microsoft XNA Game Studio est un pipeline de développement de jeux qui cible la Xbox 360, Windows Phone et Windows. En revanche, il ne permet pas de développer des jeux Windows Store (même si les jeux XNA sont pris en charge en tant qu'applications de Bureau Windows 8). Le développement DirectX avec Visual C++/CX reprend bon nombre des modèles et des pratiques de XNA, et de nombreux concepts y sont similaires. Par conséquent, de nombreux développeurs de jeux XNA pourront adopter DirectX et C++ de façon relativement simple. Par ailleurs, nous avons constaté que des développeurs ont réussi à utiliser la bibliothèque open source MonoGame, qui réplique bon nombre des fonctionnalités de XNA Game Studio. Plusieurs articles expliquant comment exploiter les ressources créées avec XNA dans des jeux ciblant le Windows Store ont été publiés. Pour plus d'informations à ce sujet, cliquez sur ce lien.

Ressources complémentaires pour le développement de jeux

La documentation possède une section entièrement consacrée au développement de jeux sur MSDN
Sessions consacrées aux jeux, diapositives et enregistrements de la conférence //build/ 2012
Sessions consacrées aux jeux, diapositives et enregistrements de la conférence GDC 2012
Sessions consacrées aux jeux, diapositives et enregistrements de la conférence //build/ 2011
Aide et support accessibles sur le Centre de développement, qui possède un forum entièrement consacré au développement de jeux destiné aux développeurs de jeux comme vous, qui peuvent apporter rapidement des réponses à vos questions
Le kit de ressources DirectX est une collection de classes d'assistance pour l'écriture de code Direct3D 11 C++
Autres ressources utiles : blog de Chuck Walbourn et blog de Shawn Hargreaves

Résumé

Avec ses nouveaux formats d'appareils, ses technologies innovantes et ses modèles commerciaux rentables, Windows 8 réimagine le PC et s'avère idéal pour le jeu. La plateforme représente une opportunité inédite pour ceux qui sauront l'exploiter. À l'heure où j'écris ces lignes, le Windows Store propose plusieurs milliers de jeux et ce chiffre augmente chaque jour. L'objectif de ce billet était de vous aider à mieux comprendre comment créer votre propre jeu Windows Store pour exploiter toutes les possibilités qui s'offrent à vous. Ces informations vous ont en principe permis de mieux comprendre comment simplifier le développement des jeux, et comment les rendre plus créatifs, plus innovants et plus rentables. Nous avons passé en revue les outils, les technologies et les services disponibles sur la plateforme, ainsi que les technologies tierces qui s'offrent à vous. À l'heure où la Game Developer Conference annuelle bat son plein à San Francisco, j'espère que ce billet vous aura fourni les conseils dont vous avez besoin pour développer des jeux Windows Store.

À vos manettes !

Shai Hinitz, chef de projet senior

Un système animé et dynamique, troisième partie : notifications Push et services mobiles Windows Azure

Windows 8 Team — Fri, 29 Mar 2013 17:36:12 GMT

Dans la première partie de cette série, nous avons étudié ce que représente un système « animé et dynamique » pour un utilisateur, ainsi que le rôle joué par les applications au sein du système. Dans la deuxième partie, nous avons examiné comment écrire et déboguer des services Web afin de mettre à jour périodiquement les vignettes dynamiques. Dans cette troisième partie, nous allons clore la série en expliquant comment fournir à la demande des mises à jour de vignette, des toasts et des notifications brutes à des périphériques client donnés via les services de notifications Push Windows (WNS) et comment les services mobiles Windows Azure simplifient l'ensemble du processus.

Notifications Push

Les mises à jour périodiques, comme nous l'avons vu dans la deuxième partie, sont initiées côté client et offrent une méthode d'interrogation visant à mettre à jour une vignette ou un badge. Les notifications « Push » ont lieu lorsqu'un service envoie directement une mise à jour à un périphérique et si cette mise à jour est susceptible de s'appliquer à un utilisateur, à une application ou même à une vignette secondaire en particulier.

Contrairement à l'interrogation, les notifications Push peuvent se produire à tout moment avec une fréquence bien supérieure. Vous devez toutefois garder à l'esprit que Windows limite le volume du trafic des notifications Push sur un périphérique si ce dernier est sur batterie, en mode de veille connectée ou si le trafic des notifications devient excessif. En d'autres termes, rien ne garantit que toutes les notifications parviendront à destination (en particulier si le périphérique est hors tension).

Par conséquent, ne pensez pas que vous pouvez utiliser les notifications Push pour implémenter une vignette d'horloge ou d'autres gadgets de vignette avec une fréquence ou une résolution temporelle similaire. En revanche, envisagez la manière dont vous pouvez utiliser les notifications Push pour connecter des vignettes et notifications à un service principal doté d'informations intéressantes et utiles à communiquer à l'utilisateur, ce qui l'incite à utiliser le plus souvent possible votre application.

Avant d'entrer dans les détails, il est important de comprendre qu'il existe deux types de notifications Push :

Mises à jour XML contenant des mises à jour de vignette ou de badge ou des charges utiles de notification toast : Windows peut traiter ces notifications Push et émettre la mise à jour ou le toast au nom d'une application. Une application peut également gérer ces notifications directement, le cas échéant.
Notifications binaires ou brutes contenant les données que le service souhaite envoyer : elles doivent être gérées par un code propre à l'application, car sinon, Windows ne sait pas comment traiter les données. Pour plus d'informations sur les tailles limites (5 Ko) et l'encodage (base64), voir Recommandations et liste de vérification sur les notifications brutes.

Dans les deux cas, une application en cours d'exécution (au premier plan) peut gérer les notifications Push directement par l'intermédiaire de la classe PushNotificationChannel et de son événement PushNotificationReceived. Pour les charges utiles XML, l'application peut modifier le contenu, changer les balises et ainsi de suite, avant de les émettre en local (ou de les ignorer). Pour les notifications brutes, l'application traite le contenu, puis choisit les notifications à émettre (ou n'en émet aucune).

Si l'application est suspendue ou n'est pas en cours d'exécution, elle peut également fournir une tâche en arrière-plan à cet effet. L'application doit demander et obtenir l'accès à l'écran de verrouillage, ce qui permet ensuite au code propre à l'application de s'exécuter lorsqu'une notification est reçue.

Une tâche en arrière-plan réalise en général une ou deux opérations lorsque la notification arrive. D'abord, elle peut enregistrer certaines informations pertinentes de la notification dans les données d'application locales, que l'application peut récupérer lors de sa prochaine activation ou reprise. Ensuite, la tâche en arrière-plan peut émettre des mises à jour de vignette et de badge locales et/ou des notifications toast.

Pour mieux comprendre les notifications brutes, prenez une application de messagerie électronique classique. Lorsque son service principal détecte de nouveaux messages pour un utilisateur, il envoie une notification Push brute aux services de notifications Push Windows (WNS) contenant un certain nombre d'en-têtes de messages électroniques. Le service effectue cette opération à l'aide d'un URI de canal qui est connecté à l'application spécifique sur le périphérique de cet utilisateur.

Les services de notifications Push Windows (WNS) tentent ensuite de transmettre cette notification au client. En cas de succès de l'opération, Windows reçoit cette notification et recherche l'application qui est associée à l'URI de canal en question. S'il ne parvient pas à trouver l'application appropriée, la notification est ignorée. Si une application existe et qu'elle est en cours d'exécution, Windows déclenche l'événement PushNotificationReceived. Sinon, Windows recherche et appelle une tâche en arrière-plan disponible pour cette application.

Dans tous les cas, la notification brute se retrouve dans le code d'une application, qui traite ensuite les données, émet une mise à jour de badge à destination de la vignette de l'application pour indiquer le nombre de nouveaux messages, puis émet jusqu'à cinq mises à jour de vignette cycliques avec des en-têtes de messages. L'application peut également émettre des notifications toast pour chaque nouveau message arrivé ou au moins une indiquant la présence de nouveaux messages.

En conséquence, les toasts indiquent à l'utilisateur que de nouveaux messages électroniques sont arrivés et la vignette de l'application sur l'écran d'accueil présente une vue rapide et immédiate de l'activité des nouveaux messages.

Pour en savoir plus sur ces gestionnaires d'événements côté client et sur les tâches en arrière-plan, consultez l'exemple de notifications brutes, le billet Rester productif lorsque votre application n'est pas à l'écran : tâches en arrière-plan de ce blog et le livre blanc sur le réseau en arrière-plan. Dans le cadre de ce billet, examinons maintenant le côté service.

Utilisation des services de notifications Push Windows (WNS)

Grâce à la coopération de Windows, des applications, des services et de WNS, il est possible de fournir à une vignette d'application précise (ou à un gestionnaire de notification toast ou brute) des données spécifiques à l'utilisateur sur un périphérique spécifique pour un utilisateur donné. Les relations entre tous ces composants sont illustrées ci-dessous.

Il est évident que des liaisons sont nécessaires pour que tous ces composants fonctionnent harmonieusement :

Vous (le développeur) inscrivez l'application dans le Windows Store afin d'utiliser les notifications Push. Cette opération permet d'obtenir un identifiant de sécurité (SID) et une clé secrète client que le service utilise pour s'authentifier auprès des services de notifications Push Windows (WNS). Pour des raisons de sécurité, ces informations ne doivent jamais être stockées sur les périphériques client.
Au moment de l'exécution, l'application demande un URI de canal de notifications Push Windows (WNS) auprès de Windows pour chacune de ses vignettes dynamiques (principales et secondaires) ou un seul pour les notifications brutes. Une application doit également actualiser ces URI de canaux tous les 30 jours, pour lesquels vous pouvez utiliser une autre tâche en arrière-plan.
Le service de l'application fournit un URI par l'intermédiaire duquel l'application peut charger ces URI de canaux avec les données qui décrivent son utilisation (par exemple un lieu géographique pour les bulletins météo ou une activité et un compte d'utilisateur précis). Dès réception, le service stocke ces URI de canaux et les données associées pour les utiliser ultérieurement.
Le service recherche sur le service principal les modifications à appliquer à chaque combinaison utilisateur/périphérique/application/vignette particulière. Lorsque le service détecte une condition qui déclenche une notification pour un canal particulier, il crée le contenu de cette notification (XML ou brute), s'authentifie auprès des services de notifications Push Windows (WNS) à l'aide de l'identifiant de sécurité (SID) et de la clé secrète client, puis il envoie la notification aux services de notifications Push Windows (WNS) avec l'URI de canal.

Examinons chaque étape en détail. (Si le fait d'aborder les requêtes HTTP vous inquiète, soyez rassuré car les services mobiles Windows Azure vous décharge d'un grand nombre de tâches, comme nous allons le voir.)

Inscription de l'application auprès du Windows Store

Pour obtenir l'identifiant de sécurité et la clé secrète client de votre service, consultez l'article Comment s’authentifier auprès des services de notifications Push Windows (WNS) sur le Centre de développement Windows. L'identifiant de sécurité permet d'identifier votre application auprès des services de notifications Push Windows (WNS) et la clé secrète client permet à votre service d'indiquer aux services de notifications Push Windows (WNS) qu'il est autorisé à envoyer des notifications pour votre application. Là encore, ces informations doivent uniquement être stockées dans le service.

Notez que vous ne devez suivre l'étape 4 de l'article Comment s’authentifier auprès des services de notifications Push Windows (WNS), intitulée « Envoyer les informations d’identification du serveur nuage à WNS » que lorsque votre service envoie une notification Push. Nous y reviendrons ultérieurement, car pour le moment, votre service ne dispose pas encore de l'élément essentiel à l'envoi d'une notification, c'est-à-dire un URI de canal.

Obtention et actualisation des URI de canaux

L'application client obtient des URI de canaux au moment de l'exécution via l'objet Windows.Networking.PushNotifications.PushNotificationChannelManager. Cet objet ne possède que deux méthodes :

createPushNotificationChannelForApplicationAsync : crée un URI de canal pour la vignette principale de l'application, ainsi que pour les toasts et les notifications brutes.
createPushNotificationChannelForSecondaryTileAsync : crée un URI de canal pour une vignette secondaire spécifique qui est identifi��e par un argument tileId.

Le résultat des deux opérations asynchrones est un objet PushNotificationChannel. Cet objet contient l'URI de canal dans sa propriété Uri , ainsi qu'un élément ExpirationTime pour indiquer le délai d'actualisation du canal. Une méthode Close met fin spécialement au canal si cela est nécessaire et l'événement PushNotificationReceived est déclenché lorsque l'application se trouve au premier plan et qu'une notification Push est reçue à travers ce canal.

La durée de vie d'un URI de canal est de 30 jours, au terme desquels les services de notifications Push Windows (WNS) rejettent les requêtes formulées pour ce canal. Le code de l'application doit par conséquent actualiser ces URI avec les méthodes create ci-dessus au moins une fois tous les 30 jours et envoyer ces URI à son service. Voici comment procéder :

Lors du premier lancement, demandez un URI de canal et enregistrez la chaîne dans la propriété Uri de vos données d'application locales. Comme les URI de canaux sont spécifiques à un périphérique, ne les stockez pas dans vos données d'application itinérantes.
Lors des lancements suivants, redemandez un URI de canal et comparez-le avec celui qui a été enregistré auparavant. S'il est différent, communiquez-le au service ou envoyez-le et laissez le service en remplacer un plus ancien si cela est nécessaire.
Réalisez également l'étape précédente dans le gestionnaire Resuming de votre application (consultez l'article Lancement, reprise et multitâche), car il est possible que l'application ait été suspendue pendant plus de 30 jours.
Si vous pensez que l'application risque de ne pas être exécutée dans les 30 jours, implémentez une tâche en arrière-plan avec un déclencheur de maintenance devant s'exécuter à intervalle régulier ou une fois par semaine. Pour en savoir plus, reportez-vous à nouveau au billet Rester productif lorsque votre application n'est pas à l'écran : tâches en arrière-plan. La tâche en arrière-plan dans ce cas exécutera simplement le même code que l'application pour demander un canal et l'envoyer à votre service.

Envoi d'URI de canaux au service

En règle générale, les canaux des notifications Push fonctionnent avec des mises à jour propres à l'utilisateur (statut du courrier électronique, messages instantanés et autres informations personnalisées). Il est peu probable que votre service doive diffuser la même notification à chaque utilisateur et/ou chaque vignette. C'est pour cette raison que le service doit associer chaque URI de canal à des informations plus spécifiques. Pour une application de messagerie électronique, l'identificateur d'utilisateur est d'une importance capitale, car il indique quel compte vérifier. Une application de météo, quant à elle, associera probablement chaque URI de canal à une latitude et une longitude données, afin que chaque vignette (principales et secondaires) reflètent un lieu géographique différent.

L'application inclura ensuite ces détails lors de l'envoi d'un URI de canal à son service et le service devra les stocker pour les utiliser ultérieurement.

En ce qui concerne l'identité de l'utilisateur, il est préférable que l'application authentifie l'utilisateur séparément auprès du service, à l'aide des informations d'identification propres au service ou via un fournisseur OAuth, tel que Facebook, Twitter, Google ou le compte Microsoft de l'utilisateur (OAuth est utile avec les services mobiles Windows Azure, comme nous le verrons plus tard). Si cela n'est pas possible, veillez à chiffrer les identificateurs d'utilisateurs que vous communiquez au service ou envoyez-les avec le protocole HTTPS.

Dans tous les cas, c'est à vous de déterminer la manière dont vous envoyez toutes ces informations à votre service (dans les en-têtes, via des données dans le corps du message ou en tant que paramètres dans l'URI du service). Cette partie de la communication se passe strictement entre l'application et son service.

Prenons un exemple simple. Supposons que nous ayons un service doté d'une page nommée receiveuri.aspx (comme nous le verrons dans la prochaine section), dont l'adresse complète se trouve dans la variable url. Le code suivant demande un URI de canal principal auprès de Windows pour l'application et le publie sur cette page via HTTP. (Ce code, qui provient de manière simplifiée de l'exemple côté client des notifications Push et périodiques où la variable itemId est définie ailleurs, permet d'identifier les vignettes secondaires. L'exemple dispose également d'une variante C++, non illustrée ici) :

JavaScript :

Windows.Networking.PushNotifications.PushNotificationChannelManager
    .createPushNotificationChannelForApplicationAsync()
    .done(function (channel) {
        //Typically save the channel URI to appdata here.
        WinJS.xhr({ type: "POST", url:url,
            headers: { "Content-Type": "application/x-www-form-urlencoded" },
            data: "channelUri=" + encodeURIComponent(channel.uri) 
                + "&itemId=" + encodeURIComponent(itemId)
        }).done(function (request) {
            //Typically update the channel URI in app data here.
        }, function (e) {
            //Error handler
        });
    });

C# :

using Windows.Networking.PushNotifications;

PushNotificationChannel channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
HttpWebRequest webRequest = (HttpWebRequest)HttpWebRequest.Create(url);
webRequest.Method = "POST";
webRequest.ContentType = "application/x-www-form-urlencoded";
byte[] channelUriInBytes = Encoding.UTF8.GetBytes("ChannelUri=" + WebUtility.UrlEncode(newChannel.Uri) + "&ItemId=" + WebUtility.UrlEncode(itemId));

Task<Stream> requestTask = webRequest.GetRequestStreamAsync();
using (Stream requestStream = requestTask.Result)
{
    requestStream.Write(channelUriInBytes, 0, channelUriInBytes.Length);
}

Le code ASP.NET suivant est une implémentation basique d'une page receiveuri.aspx qui traite cette requête HTTP POST, en s'assurant de recevoir un URI de canal valide, un utilisateur et un identifiant pour l'élément.

Je tiens à souligner la nature « basique » de ce code, car comme vous pouvez le voir, la fonction SaveChannel écrit simplement le contenu de la requête dans un fichier texte fixe, dont il est clair qu'il ne peut s'adapter qu'à un seul utilisateur ! Un service réel utiliserait évidemment une base de données à cet effet, mais la structure est similaire.

<%@ Page Language="C#" AutoEventWireup="true" %>

<script runat="server">

protected void Page_Load(object sender, EventArgs e)
{
    //Output page header
    Response.Write("<!DOCTYPE html>\n<head>\n<title>Register Channel URI</title>\n</head>\n<html>\n<body>");
    
    //If called with HTTP GET (as from a browser), just show a message.
    if (Request.HttpMethod == "GET")
    {
        Response.StatusCode = 400;
        Response.Write("<p>This page is set up to receive channel URIs from a push notification client app.</p>");
        Response.Write("</body></html>");
        return;
    }

    if (Request.HttpMethod != "POST") {
        Response.StatusCode = 400;
        Response.Status = "400 This page only accepts POSTs.";
        Response.Write("<p>This page only accepts POSTs.</p>");
        Response.Write("</body></html>");        
        return;
    }
    
    //Otherwise assume a POST and check for parameters    
    try
    {
        //channelUri and itemId are the values posted from the Push and Periodic Notifications Sample in the Windows 8 SDK
        if (Request.Params["channelUri"] != null && Request.Params["itemId"] != null)
        {
            // Obtain the values, along with the user string
            string uri = Request.Params["channelUri"];
            string itemId = Request.Params["itemId"];
            string user = Request.Params["LOGON_USER"];
                 
            //TODO: validate the parameters and return 400 if not.
            
            //Output in response
            Response.Write("<p>Saved channel data:</p><p>channelUri = " + uri + "<br/>" + "itemId = " + itemId + "user = " + user + "</p>");

            //The service should save the URI and itemId here, along with any other unique data from the app such as the user;
            SaveChannel(uri, itemId, user);

            Response.Write("</body></html>");
        }
    }
    catch (Exception ex)
    {
        Trace.Write(ex.Message);
        Response.StatusCode = 500;
        Response.StatusDescription = ex.Message; 
        Response.End();
    }
}
</script>

protected void SaveChannel(String uri, String itemId, String user)
{
    //Typically this would be saved to a database of some kind; to keep this demonstration very simple, we'll just use
    //the complete hack of writing the data to a file, paying no heed to overwriting previous data.
    
    //If running in the debugger on localhost, this will save to the project folder
    string saveLocation = Server.MapPath(".") + "\\" + "channeldata_aspx.txt";
    string data = uri + "~" + itemId + "~" + user;

    System.Text.ASCIIEncoding encoding = new System.Text.ASCIIEncoding();
    byte[] dataBytes = encoding.GetBytes(data);

    using (System.IO.FileStream fs = new System.IO.FileStream(saveLocation, System.IO.FileMode.Create))
    {
        fs.Write(dataBytes, 0, data.Length);
    }

    return;
}

Le code de ce service se trouve au Chapitre 13 de mon livre électronique gratuit intitulé Programming Windows 8 Apps in HTML, CSS, and JavaScript, en particulier dans l'exemple HelloTiles des contenus d'accompagnement. Il est conçu pour fonctionner avec l'exemple SDK côté client référencé ci-dessus. Si vous exécutez HelloTiles dans le débogueur (Visual Studio 2012 Ultimate ou Visual Studio Express 2012 pour le Web) avec le localhost activé, vous obtenez une URL du type http://localhost:52568/HelloTiles/receiveuri.aspx que vous pouvez coller dans l'exemple SDK côté client. Lorsque l'exemple effectue ensuite une requête sur cette URL, vous vous arrêtez sur les points d'arrêt du service et pouvez exécuter le code pas à pas.

Envoi de la notification

Dans un service réel, un processus continu surveille ses sources de données et envoie des notifications Push à des utilisateurs spécifiques lorsque cela est requis. Ceci peut se produire de différentes manières :

Une tâche planifiée peut rechercher des alertes météo pour un lieu précis, disons, toutes les 15-30 minutes, selon la fréquence à laquelle ces alertes sont émises, et émettre des notifications Push en réponse.
Un autre service, tel qu'un service de messagerie principale, peut effectuer une requête sur une page de votre serveur lorsqu'un nouveau message est disponible. Cette page peut ensuite émettre la notification appropriée.
Des utilisateurs peuvent interagir avec des pages Web de votre serveur et leurs activités déclenchent des notifications Push vers des canaux précis.

En résumé, plusieurs déclencheurs peuvent être à l'origine des notifications Push, tout dépend entièrement de la nature de votre service principal ou du site Web. Dans le cadre de cet article, le même service d'exemple HelloTiles du Chapitre 13 de Programming Windows 8 Apps in HTML, CSS, and JavaScript comporte une page intitulée sendBadgeToWNS.aspx qui envoie une notification Push à chaque fois que vous consultez cette page dans un navigateur, à l'aide de l'URI de canal qui a été enregistré plus tôt dans le fichier texte. Un service réel effectue une recherche dans la base de données pour obtenir les URI de canaux au lieu de lire le contenu d'un fichier, mais je le répète, la structure globale est très similaire.

Page ASP.NET :

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="sendBadgeToWNS.aspx.cs" Inherits="sendBadgeToWNS" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">    
    <title>Send WNS Update</title>
</head>
<body>
    <p>Sending badge update to WNS</p>    
</body>
</html>

code-behind C# :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Net;
using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Json;
using System.Text;

public partial class sendBadgeToWNS : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        //Load our data that was previously saved. A real service would do a database lookup here
        //with user- or tile-specific criteria.
        string loadLocation = Server.MapPath(".") + "\\" + "channeldata_aspx.txt
        byte[] dataBytes;
        
        using (System.IO.FileStream fs = new System.IO.FileStream(loadLocation, System.IO.FileMode.Open))
        {
            dataBytes = new byte[fs.Length];
            fs.Read(dataBytes, 0, dataBytes.Length);
        }

        if (dataBytes.Length == 0)
        {
            return;
        }
        
        System.Text.ASCIIEncoding encoding = new System.Text.ASCIIEncoding();

        string data = encoding.GetString(dataBytes);
        string[] values = data.Split(new Char[] { '~' });
        string uri = values[0]; //Channel URI
        string secret = "9ttsZT0JgHAFveYahK1B6jQbvMOIWYbm";
        string sid = "ms-app://s-1-15-2-2676450768-845737348-110814325-22306146-1119600341-293560589-2707026538";
        
        //Create some simple XML for a badge update
        string xml = "<?xml version=\"1.0\" encoding=\"utf-8\" ?>";
        xml += "<badge value='alert'/>";
                    
        PostToWns(secret, sid, uri, xml, "wns/badge");
    }
}

Nous extrayons ici l'URI de canal, créons la charge utile XML, puis nous authentifions auprès des services de notifications Push Windows (WNS) et envoyons une requête HTTP POST à cet URI de canal. Les deux dernières étapes s'effectuent dans la fonction PostToWns qui provient de la rubrique Démarrage rapide : envoi d’une notification Push sur le Centre de développement Windows. Je ne mentionne pas la liste complète, car l'authentification s'effectue simplement auprès des services de notifications Push Windows (WNS) via OAuth (sur https://login.live.com/accesstoken.srf) à l'aide de votre clé secrète client et de votre identifiant de sécurité obtenus dans le Windows Store. Cette authentification permet d'obtenir un jeton d'accès qui est ensuite intégré à la requête HTTP POST que nous envoyons à l'URI de canal :

C# :

public string PostToWns(string secret, string sid, string uri, string xml, string type = "wns/badge")
{
    try
    {
        // You should cache this access token
        var accessToken = GetAccessToken(secret, sid);

        byte[] contentInBytes = Encoding.UTF8.GetBytes(xml);

        // uri is the channel URI
        HttpWebRequest request = HttpWebRequest.Create(uri) as HttpWebRequest;
        request.Method = "POST";
        request.Headers.Add("X-WNS-Type", type);
        request.Headers.Add("Authorization", String.Format("Bearer {0}", accessToken.AccessToken));

        using (Stream requestStream = request.GetRequestStream())
            requestStream.Write(contentInBytes, 0, contentInBytes.Length);

        using (HttpWebResponse webResponse = (HttpWebResponse)request.GetResponse())
            return webResponse.StatusCode.ToString();
    }
    catch (WebException webException)
    {
        // Implements a maximum retry policy (omitted)
    }
}

Dans cet exemple, notez que l'en-tête X-WNS-Type dans la requête HTTP est défini sur wns/badge et que l'en-tête Content-Type est défini par défaut sur text/xml. Pour les vignettes, le type doit être wns/tile. Les toasts utilisent wns/toast. Concernant les notifications brutes, utilisez le type wns/raw et définissez Content-Type sur application/octet-stream. Pour plus d'informations sur les en-têtes, consultez la page En-têtes des demandes et des réponses des services de notifications Push de la documentation.

Échec des notifications Push

L'envoi d'une requête HTTP ne fonctionne évidemment pas toujours et plusieurs raisons peuvent expliquer pourquoi WNS peut répondre avec un code autre que le code 200 (réussite). Pour plus d'informations, consultez la section « Code de réponse » de la page En-têtes des demandes et des réponses des services de notifications Push. Vous y trouverez des erreurs communes et les causes :

L'URI de canal n'est pas valide (404 Introuvable) ou a expiré (410 Supprimé). Dans ce cas, le service doit supprimer l'URI de canal de sa base de données et ne plus lui envoyer de requêtes.
La clé secrète client et l'identifiant de sécurité ne sont peut-être pas valides (401 Non autorisé) ou l'identifiant du package de l'application dans le manifeste et celui qui se trouve dans le Windows Store ne correspondent pas (403 Interdit). Pour s'assurer qu'ils correspondent, il est préférable d'utiliser la commande de menu Windows Store > Associer l'application au Windows Store dans Visual Studio (cette commande se trouve dans le menu Projet de Visual Studio 2012 Ultimate).
La charge utile de la notification brute dépasse 5 Ko (413 Entité de demande trop grande).
Le client peut être hors connexion, auquel cas WNS réessaie automatiquement, mais finit par signaler un échec. Pour les notifications XML, le comportement par défaut est que les notifications Push sont mises en cache et livrées lorsque le client se reconnecte. Pour les notifications brutes, la mise en cache est désactivée par défaut. Vous pouvez modifier ce comportement en définissant l'en-tête X-WNS-Cache-Policy sur cache dans la requête envoyée à l'URI de canal.

Pour les autres erreurs (400 Requête incorrecte), veillez à ce que les charges utiles XML contiennent du texte encodé en UTF-8 et que les notifications brutes soient en base64 avec l'en-tête Content-Type défini sur application/octet-stream. Il est également possible que WNS limite l'aboutissement des requêtes parce que vous essayez simplement d'envoyer trop de notifications Push au sein d'une période donnée.

Une notification Push brute peut également être rejetée si l'application ne se trouve pas sur l'écran de verrouillage et si l'appareil se trouve en mode de veille connectée. Comme Windows bloque les notifications brutes sur les applications qui ne se trouvent pas sur l'écran de verrouillage dans cet état (et à chaque fois que l'application n'est pas au premier plan), WNS supprime les notifications qui, d'après lui, ne parviendront pas à destination.

Services mobiles Windows Azure

Maintenant que nous avons passé en revue tous les détails de l'utilisation des notifications Push, même sans mentionner la question du stockage, vous vous demandez probablement s'il existe un moyen de simplifier tout cela ? Imaginez ce que cela serait de gérer des milliers ou des millions d'URI de canaux pour une clientèle vaste et grandissante !

Heureusement, la question s'est déjà posée. Outre les solutions tierces, telles que celles proposées par Urban Airship, les services mobiles Windows Azure peuvent simplifier énormément les choses.

Les services mobiles Windows Azure offrent une solution prédéfinie (en fait, plusieurs points de terminaison REST) pour la plupart des détails des services que nous allons aborder. Un « service mobile » gère une base de données en votre nom et offre des fonctions de bibliothèque afin d'envoyer facilement les charges utiles à WNS. Les services mobiles Windows Azure sont présentés dans le billet Connectez votre application au cloud avec les services mobiles Windows Azure.

Pour les notifications Push en particulier, récupérez d'abord la bibliothèque côté client dans le SDK des services mobiles Windows Azure pour Windows 8. Reportez-vous ensuite à la rubrique Get started with push notifications in Mobile Services sur l'utilisation des notifications Push dans les services mobiles (notez qu'il existe également une version JavaScript de cette rubrique) pour savoir comment les services mobiles Windows Azure peuvent vous aider à remplir toutes les conditions que nous avons vues plus tôt en terme de liaisons :

Inscription de l'application auprès du Windows Store : après avoir obtenu la clé secrète client et l'identifiant de sécurité de votre application auprès du Windows Store, enregistrez ces données dans la configuration des services mobiles. Consultez la section « Register your app for the Windows Store » (Inscription de votre application pour le Windows Store) de la rubrique Get started que nous venons de mentionner.
Obtention et actualisation des URI de canaux : la demande et la gestion des URI de canaux dans l'application s'effectuent uniquement côté client et sont les mêmes qu'auparavant.
Envoi d'URI de canaux au service : cette étape devient beaucoup plus facile avec les services mobiles Windows Azure. Vous commencez par créer une table de base de données dans le service mobile (via le portail Windows Azure). Ensuite, l'application peut simplement insérer des enregistrements dans cette table avec les URI de canaux et toute autre information importante que vous devez joindre. La bibliothèque cliente des services mobiles Windows Azure se charge de la requête HTTP en arrière-plan et actualise même l'enregistrement côté client en intégrant les modifications effectuées sur le serveur. En outre, les services mobiles Windows Azure peuvent gérer automatiquement l'authentification via le compte Microsoft de l'utilisateur ou via trois autres fournisseurs OAuth (Facebook, Twitter ou Google) si vous avez inscrit votre application auprès de l'un d'eux. Consultez la rubrique Get started with authentication in Mobile Services sur l'authentification dans les services mobiles.
Envoi de la notification : au sein du service mobile, vous pouvez joindre des scripts (écrits dans la variante de JavaScript connue sous le nom de Node.js) à des opérations de base de données, ainsi que des tâches planifiées créées dans JavaScript. Dans ces scripts, un simple appel à l'objet push.wns avec un URI de canal et une surcharge génère la requête HTTP nécessaire sur le canal. Il est également simple de capturer les échecs des notifications Push et d'enregistrer la réponse avec console.log. Ces journaux sont facilement consultables sur le portail Windows Azure.

Pour en savoir plus, consultez des deux didacticiels d'exemple : Tile, Toast, and Badge Push Notifications using Windows Azure Mobile Services et Raw Notifications using Windows Azure Mobile Services. Au lieu de répéter toutes ces instructions, passons en revue certains des points principaux.

Lorsque vous configurez un service mobile, il est doté d'une URL de service spécifique. Elle vous permettra de créer une instance de l'objet MobileServiceClient dans le SDK des services mobiles Windows Azure :

JavaScript :

var mobileService = new Microsoft.WindowsAzure.MobileServices.MobileServiceClient(
    "https://{mobile-service-url}.azure-mobile.net/",
    "{mobile-service-key}");

C# :

using Microsoft.WindowsAzure.MobileServices;

MobileServiceClient MobileService = new MobileServiceClient(
    "https://{mobile-service-url}.azure-mobile.net/",
    "{mobile-service-key}");

C++ (issu d'un exemple supplémentaire) :

using namespace Microsoft::WindowsAzure::MobileServices;

auto MobileService = ref new MobileServiceClient(
    ref new Uri(L" https://{mobile-service-url}.azure-mobile.net/"), 
    ref new String(L"{mobile-service-key}"));

Cette classe encapsule toute la communication HTTP avec le service, ce qui vous permet d'éviter tous les tâches de niveau inférieur sur lesquelles vous préférez probablement ne pas vous pencher.

Pour vous authentifier auprès d'un fournisseur OAuth précis, utilisez la méthode login ou LoginAsync, qui permet d'obtenir un objet User qui communique cette information à l'application. (Une fois l'authentification réalisée, la propriété CurrentUser de l'objet client contient également l'identificateur d'utilisateur.) Lorsque vous authentifiez le service mobile directement comme ceci, le service a accès à l'identificateur d'utilisateur et le client n'a pas besoin de l'envoyer explicitement :

JavaScript :

mobileService.login("facebook").done(function (user) { /* ... */ });
mobileService.login("twitter").done(function (user) { /* ... */ });
mobileService.login("google").done(function (user) { /* ... */ });
mobileService.login("microsoftaccount").done(function (user) { /* ... */ });

C# :

MobileServiceUser user = await MobileService.LoginAsync(MobileServiceAuthenticationProvider.Facebook);
MobileServiceUser user = await MobileService.LoginAsync(MobileServiceAuthenticationProvider.Twitter);
MobileServiceUser user = await MobileService.LoginAsync(MobileServiceAuthenticationProvider.Google);
MobileServiceUser user = await MobileService.LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount);

C++ :

task<MobileServiceUser^> (MobileService->LoginAsync(MobileServiceAuthenticationProvider::Facebook))
    .then([this](MobileServiceUser^ user) { /* */ } );
task<MobileServiceUser^> (MobileService->LoginAsync(MobileServiceAuthenticationProvider::Twitter))
    .then([this](MobileServiceUser^ user) { /* */ } );
task<MobileServiceUser^> (MobileService->LoginAsync(MobileServiceAuthenticationProvider::Google))
    .then([this](MobileServiceUser^ user) { /* */ } );
task<MobileServiceUser^> (MobileService->LoginAsync(MobileServiceAuthenticationProvider::MicrosoftAccount))
    .then([this](MobileServiceUser^ user) { /* */ } );

L'envoi d'un URI de canal au service est simple : un enregistrement est stocké dans la base de données du service et l'objet client effectue les requêtes HTTP. Pour ce faire, demandez simplement l'objet de base de données et insérez l'enregistrement comme illustré dans les exemples ci-dessous issus du didacticiel d'exemple sur les notifications Push référencés plus haut. Dans chaque extrait de code, supposons que ch contient l'objet PushNotificationChannel des API WinRT. Vous pouvez également inclure d'autres propriétés dans l'objet channel qui est élaboré, par exemple un identifiant de vignette secondaire ou d'autres données permettant d'identifier l'objectif du canal.

JavaScript :

var channelTable = MobileServicesSample.mobileService.getTable('Channels');

var channel = {
    uri: ch.uri, 
    expirationTime: ch.expirationTime.
};

channelTable.insert(channel).done(function (item) {

    },
    function () {
        // Error on the insertion.
    });
}

C# :

var channel = new Channel { Uri = ch.Uri, ExpirationTime = ch.ExpirationTime };
var channelTable = privateClient.GetTable<Channel>();

if (ApplicationData.Current.LocalSettings.Values["ChannelId"] == null)
{
    // Use try/catch block here to handle exceptions
    await channelTable.InsertAsync(channel);
}

C++ :

auto channel = ref new JsonObject();
channel->Insert(L"Uri", JsonValue::CreateStringValue(ch->Uri));
channel->Insert(L"ExpirationTime", JsonValue::CreateBooleanValue(ch->ExpirationTime));

auto table = MobileService->GetTable("Channel");
task<IJsonValue^> (table->InsertAsync(channel))
    .then([this, item](IJsonValue^ V) { /* ... */ });

Notez qu'une fois l'enregistrement de canal inséré, les modifications ou ajouts que ce service a pu apporter à cet enregistrement seront répercutés dans le client.

De plus, si vous orthographiez incorrectement le nom de la base de données dans l'appel GetTable/getTable, vous ne verrez aucune exception tant que vous n'essayez pas d'insérer un enregistrement. Ce problème pouvant être difficile à déceler, si vous êtes convaincu que tout devrait fonctionner alors que tel n'est pas le cas, vérifiez le nom de cette base de données.

Je le répète, ces insertions côté client sont converties en requêtes HTTP pour le service, mais même côté service, vous ne pouvez pas voir ce processus. Au lieu de recevoir et de traiter les requêtes, vous joignez des scripts personnalisés à chaque opération de base de données (insertion, lecture, mise à jour et suppression).

Ces scripts sont écrits sous forme de fonctions JavaScript à l'aide des mêmes objets et méthodes intrinsèques qui sont disponibles dans Node.js (aucun d'entre eux n'a quoi que ce soit à voir avec JavaScript côté client dans l'application). Chaque fonction reçoit les paramètres appropriés : insert et update reçoivent un nouvel enregistrement, delete reçoit l'identifiant de l'élément et read reçoit une requête. Toutes les fonctions reçoivent également un objet user si l'application a authentifié l'utilisateur auprès du service mobile et un objet request qui vous permet d'exécuter l'opération et de générer ce qui devient la réponse HTTP.

Le script le plus simple (celui par défaut insert exécute simplement la requête et insère l'enregistrement item tel quel :

function insert(item, user, request) {
    request.execute();
}

Si vous souhaitez joindre un horodateur et un identificateur d'utilisateur à l'enregistrement, il suffit d'ajouter ces propriétés au paramètre item avant d'exécuter la requête :

function insert(item, user, request) {
    item.user = user.userId;
    item.createdAt = new Date();
    request.execute();
}

Notez que les modifications apportées à item dans ces scripts avant l'insertion dans la base de données sont automatiquement repropagées dans le client. Dans le code ci-dessus, l'objet channel dans le client contient les propriétés user et createdAt une fois l'insertion réussie. Très pratique !

Les scripts de service peuvent également effectuer des actions supplémentaires après request.execute, en particulier suite à une réussite ou à un échec, mais vous trouverez tous les détails dans la documentation Server script example how tos.

Pour en revenir aux notifications Push, l'enregistrement d'URI de canaux dans une table ne constitue qu'une partie de l'équation et le service peut ou non envoyer des notifications en réponse à cet événement précis. Il est plus probable que le service dispose d'autres tables avec des informations complémentaires, et que les opérations effectuées dans ces tables déclenchent des notifications vers un sous-ensemble d'URI de canaux. Nous aborderons quelques exemples dans la section suivante. Quoi qu'il en soit, vous envoyez une notification Push à partir d'un script à l'aide de l'objet push.wns. Il existe là encore de nombreuses méthodes pour envoyer des types spécifiques de mises à jour (notamment brutes), où les vignettes, toasts et badges utilisent des méthodes de noms qui correspondent aux modèles disponibles. Par exemple :

push.wns.sendTileSquarePeekImageAndText02(channel.uri, {
    image1src: baseImageUrl + "image1.png",
    text1: "Notification Received",
    text2: item.text
}, {
    success: function (pushResponse) {
        console.log("Sent Tile Square:", pushResponse);
    },
    error: function (err) {
        console.log("Error sending tile:", err);
    }

});

push.wns.sendToastImageAndText02(channel.uri, {
    image1src: baseImageUrl + "image2.png",
    text1: "Notification Received",
    text2: item.text
}, {
    success: function (pushResponse) {
        console.log("Sent Toast:", pushResponse);
    }
});

push.wns.sendBadge(channel.uri, {
    value: value,
    text1: "Notification Received"
}, {
    success: function (pushResponse) {
        console.log("Sent Badge:", pushResponse);
    }
});

La fonction console.log crée là encore une entrée dans les journaux que vous pouvez consulter sur le portail des services Azure Mobile. En règle générale, il convient d'inclure les appels de journaux dans des gestionnaires d'erreurs, comme illustré dans la notification de vignette ci-dessous.

Vous avez peut-être remarqué que les méthodes send* sont chacune liées à un modèle particulier. Pour les vignettes, cela signifie que les charges utiles larges et carrées doivent être envoyées séparément sous forme de deux notifications. N'oubliez pas qu'il est presque toujours préférable d'envoyer les deux tailles ensemble, car c'est l'utilisateur qui détermine la manière dont la vignette s'affiche sur son écran d'accueil. Avec les fonctions send de push.wns spécifiques au modèle, cela implique l'émission de deux appels séquentiels qui génèrent chacun une notification Push distincte.

Pour combiner plusieurs mises à jour, ce qui implique l'envoi simultané de plusieurs mises à jour de vignettes avec différentes balises ou l'envoi de plusieurs toasts, utilisez les méthodes push.wns.sendTile et push.wns.sendToast. Par exemple :

var channel = '{channel_url}';

push.wns.sendTile(channel,
    { type: 'TileSquareText04', text1: 'Hello' },
    { type: 'TileWideText09', text1: 'Hello', text2: 'How are you?' },
    { client_id: '{your Package Security Identifier}', client_secret: '{your Client Secret}' },

    function (error, result) {
        // ...
    });

Si l'on se place à un niveau encore plus bas, la méthode push.wns.send vous permet d'être très exact en ce qui concerne le contenu des notifications. La méthode push.wns.sendRaw permet quant à elle de réaliser des notifications brutes. Pour en savoir plus, reportez-vous à nouveau à la documentation sur l'objet push.wns.

Scénarios réels avec les services mobiles Windows Azure

L'application d'exemple de la page Tile, Toast, and Badge Push Notifications using Windows Azure Mobile Services illustre comment envoyer des notifications Push en réponse à l'insertion d'un nouveau message dans une table de base de données. Cela signifie toutefois que l'application finit par s'envoyer une notification Push à elle-même, ce qui n'est en général pas nécessaire (sauf peut-être pour envoyer des notifications à la même application sur les autres périphériques de l'utilisateur).

Le plus probable, c'est que le service envoie des notifications Push en réponse à des événements qui se produisent en dehors de l'application/vignette qui reçoit ces notifications. Prenons ces scénarios :

Utilisation des réseaux sociaux :

Les applications peuvent utiliser le réseau social d'un utilisateur pour implémenter des fonctionnalités, par exemple pour mettre au défi les amis d'un utilisateur. Lorsqu'un utilisateur parvient à un nouveau score élevé dans un jeu, vous pouvez lancer des défis via des mises à jour de vignettes ou des toasts aux amis de l'utilisateur qui ont également installé ce jeu. Cela est également possible dans les applications de remise en forme, où vous pouvez par exemple publier un nouveau meilleur résultat pour un certain type d'activité.

Pour ce faire, l'application peut insérer un nouvel enregistrement dans la table du service mobile approprié (Scores, BestTimes, etc.). Au sein du script d'insertion, le service interroge sa base de données pour connaître les amis appropriés de l'utilisateur en cours, puis envoie des notifications à ces URI de canaux. Des critères de requête supplémentaires décrivent l'aspect exact d'un jeu, le type précis d'exercice (pour les vignettes secondaires), etc.

Bulletins et alertes météo :

Les application de météo vous permettent en général d'attribuer un lieu géographique à la vignette principale de l'application et de créer des vignettes secondaires pour d'autres lieux. Les informations importantes dans chaque vignette sont la latitude et la longitude du lieu, que l'application envoie au service avec chaque URI de canal (en les insérant dans une table). Pour déclencher une mise à jour sur ce canal, le service peut faire appel à un autre processus (par exemple une tâche planifiée décrite ci-dessus) qui interroge régulièrement un service de météo central pour connaître les bulletins et les alertes, puis traite ces réponse et insère les messages appropriés dans une table d'alertes du service mobile. Le script d'insertion récupère ensuite les URI de canaux appropriés et envoie les bulletins. De même, si un service de météo lui-même vous permet de vous inscrire à des alertes ou à des bulletins réguliers, une autre page du service reçoit ces requêtes (HTTP PUT, très probablement), les traite, puis appelle le service mobile pour insérer un enregistrement, ce qui déclenche une mise à jour.

Messages :

La gestion des messages instantanés ressemble beaucoup à la réception des bulletins météo. Pourtant, un autre processus surveille la réception de nouveaux messages, par exemple celui qui vérifie régulièrement les messages entrants ou s'inscrit auprès de la source des messages pour recevoir des alertes lorsque de nouveaux messages arrivent. Dans tous les cas, l'arrivée d'un nouveau message déclenche des notifications Push sur les canaux appropriés. Dans ce cas, les URI de canaux sont associés à la vignette d'un utilisateur pour un type particulier de messages. Il convient ici d'utiliser les notifications brutes, car ce cas ressemble au scénario de messagerie électronique décrit au début de ce billet.

Dans tous ces scénarios, notez qu'il n'est en fait pas nécessaire d'insérer quoi que ce soit dans une table de base de données. Si vous n'appelez pas request.execute dans le script d'insertion, rien ne se retrouve dans la base de données, mais vous pouvez toute de même effectuer d'autres tâches au sein de ce script, par exemple envoyer des notifications. En d'autres termes, il n'est pas nécessaire de renseigner une base de données avec des enregistrements que vous n'allez pas utiliser, en particulier parce que le stockage de données entraîne un certain coût.

Notez par ailleurs que les services mobiles Azure disposent d'une fonction de planification des tâches. Consultez la page Schedule recurring jobs in Mobile Services pour en savoir plus sur la planification des tâches récurrentes dans les services mobiles. Ces tâches sont capables d'extraire régulièrement des données d'autres services, de les traiter et d'insérer des enregistrements dans la base de données du service, ce qui déclenche à nouveau des notifications Push. De même, comme nous l'avons indiqué dans la deuxième partie de cette série, d'autres pages Web et applications mobiles peuvent également apporter des modifications dans cette base de données et déclencher des notifications Push. Les scripts de base de données dans le service mobile s'exécuteront dans tous ces cas.

Pour conclure

Pour conclure cette série, nous avons exploré toute l'étendue de ce qu'implique un « système animé et dynamique » du côté des utilisateurs, des développeurs, des applications et des services. Nous avons vu les fonctionnalités des mises à jour de vignette, de badge et de toast, comment configurer des notifications périodiques, comment utiliser des tâches d'arrière-plan dans le cadre de ce processus, ainsi que la structure des services pour gérer les notifications périodiques et Push. Il se dégage clairement que les services mobiles Windows Azure offrent une vision de niveau bien supérieur de tout le processus d'utilisation des notifications Push. Ils peuvent sans aucun doute vous aider à être beaucoup plus productif qu'en écrivant des services entièrement nouveaux.

Kraig Brockschmidt
Chef de projet, équipe Écosystème Windows
Auteur de Programming Windows 8 Apps in HTML, CSS, and JavaScript

Un système animé et dynamique, deuxième partie : écriture et débogage de services pour les vignettes dynamiques

Windows 8 Team — Mon, 11 Mar 2013 19:03:47 GMT

Dans la première partie de cette série de billets, nous avons étudié la nature même des mises à jour de vignette, des mises à jour de badge et des notifications toast, qui rendent l'expérience utilisateur globale de Windows 8 plus vivante. En particulier, nous avons examiné comment composer ces notifications à partir de charges utiles XML, qui sont ensuite émises localement (à partir d'une application en cours d'exécution ou d'une tâche d'arrière-plan) ou fournies à la demande par un service en ligne.

La génération d'une charge utile XML et son émission à partir d'une application en cours d'exécution sont des opérations que vous pouvez facilement développer et déboguer au sein d'une application grâce à Visual Studio Ultimate 2012 ou Visual Studio Express 2012 pour Windows 8. L'exemple de vignettes et de badges d'application, l'exemple de vignettes secondaires et l'exemple de notifications planifiées fournissent toutes les informations dont vous avez besoin pour cela.

En revanche, il est un peu plus délicat de développer et de déboguer un service Web pour prendre en charge à la fois des mises à jour périodiques et des notifications Push. Le déroulement de ces activités côté client est très bien expliqué dans l'exemple de notifications Push et de notifications périodiques côté client, mais pour pouvoir faire le moindre usage de cet exemple, vous devez disposer de services... Dans ce billet, nous allons examiner plus précisément comment développer des services Web prenant en charge les notifications périodiques pour les mises à jour des vignettes et des badges, en mettant l'accent sur l'utilisation des outils Visual Studio et du localhost pour déboguer les services avant de les déployer sur un environnement de production. Nous commencerons également à découvrir comment utiliser les services mobiles Windows Azure dans ce cadre, services qui sont également très utiles pour prendre en charge les notifications Push, comme nous le verrons dans la troisième partie.

Principes de base des services

Comment fonctionne concrètement un service prenant en charge les mises à jour périodiques des vignettes et des badges ? Commençons par expliquer ce que nous entendons par le terme « service », celui-ci étant souvent assez intimidant pour les développeurs qui se concentrent principalement sur les applications clientes.

Pour faire simple, un service correspond à un fragment de code stocké sur un serveur Web et qui s'exécute sur ce serveur à chaque fois qu'il reçoit une requête HTTP. Les pages HTML (.htm ou .html) n'entrent pas dans cette définition : comme aucun code n'est impliqué côté serveur, celui-ci renvoie simplement le texte de la page et l'ensemble du traitement s'effectue sur le client (y compris l'exécution des éventuels scripts côté client inclus dans cette page). Cependant, si des URI mènent à des pages qui portent l'extension php, asp, aspx, cgi, cshtml ou n'importe quelle autre extension côté serveur, vous communiquez en pratique avec un « service », au sens large du terme.

Le rôle d'un service est de recevoir une requête HTTP émanant d'un client, de traiter les arguments éventuellement inclus dans l'URI, puis de renvoyer une réponse adéquate sous forme de texte. Dans le cas des pages Web écrites en utilisant des technologies telles que PHP ou ASP.NET, la réponse doit être au format HTML. Les services qui implémentent des API Web, par exemple ceux de Facebook et Twitter (et des milliers d'autres) acceptent en général une quantité illimitée de paramètres dans les chaînes de requête d'URI (ou dans l'en-tête de requête) et renvoient en réponse des données XML ou JSON. (Pour information, nous évoquons ici uniquement les services basés sur l'architecture REpresentational State Transfer (REST) et pas ceux qui s'appuient sur d'autres protocoles tels que SOAP, car REST est à l'heure actuelle l'architecture la plus courante dans le domaine des services.)

Ainsi, un service fournissant des mises à jour périodiques de vignettes et/ou de badges est simplement un service présent à l'URI indiqué à Windows par une application et qui répond aux requêtes HTTP via une charge utile XML appropriée. Cette charge utile contient des éléments qui correspondent à n'importe quel modèle pris en charge, où les images sont référencées par le biais d'autres URI (le code inline n'est pas pris en charge). Les informations précises figurant dans la charge utile peuvent également provenir de n'importe quelle source, comme nous l'expliquerons dans un instant.

En dehors de ces détails, tous ces services partagent néanmoins une structure similaire, qui reçoit et traite la requête, puis construit la réponse XML. Examinons maintenant comment créer cette structure de base.

Écriture des services

Pour écrire et déboguer des services, vous pouvez utiliser les outils que vous souhaitez, à condition qu'ils prennent en charge le langage côté serveur que vous avez choisi. Nous allons ici nous concentrer sur Visual Studio, et plus particulièrement sur Visual Studio Ultimate 2012 et Visual Studio Express 2012 pour le Web, ce dernier étant disponible gratuitement avec son équivalent Windows que vous connaissez déjà. Pour l'installer, exécutez Web Platform Installer, qui vous permet également d'installer différentes technologies liées telles que PHP et WebMatrix. Vous pouvez ainsi créer des services dans différents langages.

Le code ci-dessous est un exemple très simple de code comprenant un service PHP complet qui répond par le biais d'une charge utile XML de mise à jour de badge, où la valeur du badge correspond au jour du mois actuel (selon le serveur). Cet exemple est issu de l'exemple de site HelloTiles, qui figure dans le Chapitre 13 de mon livre électronique gratuit, Programming Windows 8 Apps with HTML, CSS, and JavaScript :

<?php
    echo '<?xml version="1.0" encoding="utf-8" ?>';
    echo "<badge value='".date("j")."'/>";
?>

Vous pouvez essayer ce service directement. Cliquez sur ce lien sur le site Windows Azure que j'ai mis en place spécialement à cet effet : http://programmingwin8-js-ch13-hellotiles.azurewebsites.net/dayofmonthservice.php. Vous verrez que le code XML renvoyé ressemble à ceci :

<?xml version="1.0" encoding="UTF-8"?>
<badge value="24"/>

Essayez ce même URI dans l'exemple de notifications Push et de notifications périodiques côté client, scénario 5, « Polling for badge updates » (Interrogation des mises à jour de badge). Lorsque vous exécutez l'application pour la première fois (dans Visual Studio Express pour Windows), sa vignette apparaît comme ceci sur l'écran d'accueil :

Entrez maintenant l'URI ci-dessus dans la zone de texte du scénario 5 et appuyez sur le bouton de démarrage des mises à jour périodiques. En supposant que vous disposez d'une connexion réseau, un badge numérique s'affiche sur la vignette de l'exemple :

Vous remarquerez que Windows essaie de rechercher les mises à jour dès que l'application lance des mises à jour périodiques, puis continue l'interrogation selon l'intervalle spécifié.

Pour découvrir un exemple plus complet en PHP, consultez le billet Création d'une expérience utilisateur optimale en matière de vignettes (deuxième partie), qui montre comment personnaliser de façon plus aboutie une mise à jour de vignette. Dans cet exemple, la fonction hypothétique get_trucks_from_database interroge une base de données par le biais d'un code ZIP inclus dans les paramètres de chaîne de requête de l'URI, puis crée la réponse XML à partir des résultats de cette requête.

Sur le même principe, le service permet bien d'autres opérations. Exemple :

Avec le service PHP ci-dessus, qui indique le jour du mois, l'application peut indiquer son fuseau horaire local dans la chaîne de requête pour obtenir une date plus précise, car il est très courant que le serveur se trouve dans un autre fuseau.
Un service de météo peut utiliser des valeurs de latitude et de longitude dans l'URI pour récupérer les conditions météo actuelles du lieu en question.
Le service pourrait également générer des images à la volée et les stocker sur un serveur Web, puis insérer les URI adéquats dans la charge de travail XML.
Le service pourrait ensuite envoyer ses propres requêtes à d'autres services pour obtenir des données supplémentaires personnalisées à partir des paramètres de la chaîne de requête (nous y reviendrons ultérieurement).
Si une application active la file d'attente des mises à jour de vignette (voir la méthode EnableNotificationQueue), elle peut spécifier jusqu'à cinq URI distincts pour interroger les mises à jour périodiques, comme le montre le scénario 4 de l'exemple de notifications Push et de notifications périodiques côté client. La file d'attente de mise à jour des vignettes accueillera une mise à jour de chaque URI. Chacun de ces URI peut évidemment posséder sa propre chaîne de requête, pour encore plus de personnalisation, de façon à ce que le même service puisse répondre lui-même à toutes les requêtes.
Une application peut insérer un identificateur d'utilisateur dans la chaîne de requête, pour que le service puisse interroger les magasins de données associés à l'historique du programme de fitness de l'utilisateur, à ses meilleurs scores dans un jeu, aux actualités issues des flux auxquels il s'est inscrit, etc. Dans ces cas, l'identificateur d'utilisateur peut être une information d'identification personnelle et l'application doit donc respecter la confidentialité de ces informations. Par conséquent, elle doit soit chiffrer le nom d'utilisateur dans la chaîne de requête, soit utiliser des URI https://.

Remarque : Windows ne permet pas au mécanisme de mise à jour périodique d'authentifier l'utilisateur auprès du service. En revanche, cette possibilité est offerte par les notifications Push (et en entreprise par la fonctionnalité Authentification en entreprise déclarée dans le manifeste).

Bien évidemment, les services peuvent être écrits avec d'autres technologies. ASP.NET est un bon choix, car vous pouvez ensuite utiliser la même bibliothèque NotificationsExtensions (écrite en C#) que celle utilisée dans l'application, pour générer facilement des charges utiles XML correctement structurées.

Pour découvrir un exemple guidé, prenons le service WebMatrix très simple, que j'ai créé pour l'exemple de service HelloTiles du Chapitre 13 de mon livre (les contenus d'accompagnement sont disponibles ici). Ce service spécifique renvoie une charge utile XML fixe (comprenant des liaisons pour les vignettes carrée et rectangulaire) et sa structure est similaire à celle du premier exemple ASP.NET figurant dans Création d'une expérience utilisateur optimale en matière de vignettes (deuxième partie) :

@{
  //
  // This is where any other code would be placed to acquire the dynamic content
  // needed for the tile update. In this case we'll just return static XML to show
  // the structure of the service itself.
  // 
  var weekDay = DateTime.Now.DayOfWeek;
}
<?xml version="1.0" encoding="utf-8" ?>
<tile>
    <visual lang="en-US">
        <binding template="TileSquarePeekImageAndText02" branding="none">
            <image id="1" src="http://www.kraigbrockschmidt.com/images/Liam07.png"/>
            <text id="1">Liam--</text>
            <text id="2">Giddy on the day he learned to sit up!</text>
        </binding>
        <binding template="TileWideSmallImageAndText04" branding="none">
            <image id="1" src="http://www.kraigbrockschmidt.com/images/Liam08.png"/>
            <text id="1">This is Liam</text>
            <text id="2">Exploring the great outdoors!</text>
        </binding>
    </visual>
</tile>

Ce service est déployé sur la page suivante http://programmingwin8-js-ch13-hellotiles.azurewebsites.net/Default.cshtml. Si vous le souhaitez, vous pouvez essayer le scénario 4 de l'exemple de notifications Push et de notifications périodiques côté client. Au bout de quelques secondes, vous verrez les mises à jour de vignette suivantes (la version large est présentée à gauche et les deux parties de la vignette d'aperçu carrée figurent à droite) :

Écrivons maintenant la même chose, mais cette fois en utilisant la bibliothèque Notification Extensions. Pour commencer, vous devez créer une version de la bibliothèque pour votre site :

Accédez à l'exemple de vignettes et de badges d'application et copiez le dossier Notifications Extensions de ce projet dans un de vos dossiers. (Vous pouvez également installer la bibliothèque directement à partir de Visual Studio en cliquant avec le bouton droit de la souris sur un projet, puis en sélectionnant Gérer les packages NuGet… et en recherchant NotificationsExtensions.WinRT. Cependant, cette opération est conçue pour importer la bibliothèque dans un projet d'application existant, or nous devons ici créer une DLL autonome.)
Dans Visual Studio Express pour Windows, ouvrez le fichier NotificationsExtensions.csproj.
Dans l'Explorateur de solutions, cliquez avec le bouton droit de la souris sur le projet NotificationExtensions, sélectionnez Propriétés et effectuez les modifications suivantes :

Dans les paramètres de l'application, choisissez le type de sortie Bibliothèque de classes(une .dll). Cette modification est nécessaire pour pouvoir utiliser la bibliothèque avec un site ASP.NET.
Dans les paramètres du build, affectez la valeur Toutes les configurations à la configuration, modifiez les symboles de compilation conditionnelle pour lire NETFX_CORE; WINRT_NOT_PRESENT, puis vérifiez que le fichier de documentation XML est sélectionné en bas de la page. L'indicateur WINRT_NOT_PRESENT permet de compiler la bibliothèque sans WinRT.

Sélectionnez une cible de débogage ou de version, puis cliquez avec le bouton droit de la souris sur le projet Notification Extensions et sélectionnez Générer.

En principe, une DLL et les fichiers associés sont alors générés dans le dossier du projet. Nous devons maintenant l'importer dans un projet de site Web.

Dans Visual Studio Express pour le Web, cliquez avec le bouton droit de la souris sur le projet de site Web et sélectionnez Ajouter > Ajouter un dossier ASP.NET > Bin si votre site ne possède pas encore de dossier « Bin ».
Cliquez avec le bouton droit de la souris sur ce dossier Bin et sélectionnez Ajouter une référence…. Dans Ajouter une référence, accédez au dossier bin\Debug ou bin\Release du projet Notifications Extensions et sélectionnez la DLL qui s'y trouve.

Si vous utilisez Visual Studio Ultimate, vous pouvez si vous le souhaitez ajouter le projet Notification Extensions à votre solution de site Web, car l'outil peut gérer les deux types de projet. Faites cependant attention à ne pas déployer le code source de ce projet sur votre serveur Web !

Sachez également que si vous créez votre site en vue de l'exécuter localement dans un navigateur Web (comme nous le verrons dans la section ci-dessous consacrée au débogage), vous risquez d'obtenir une erreur concernant l'ajout d'une référence à System.Runtime. Pour résoudre le problème, ouvrez le fichier web.config et modifiez l'élément compilation comme suit :

<compilation debug="true" targetFramework="4.0">
  <assemblies>
    <add assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> 
  </assemblies>
</compilation>

Maintenant que tout est place, voici une page (appelée DefaultNE.aspx) qui produit la même sortie que l'exemple codé en dur que nous avons étudié plus tôt :

<?xml version="1.0" encoding="utf-8" ?>
<%@ Page Language="C#" %>
<script runat="server">   1:  
   2:     public string GenerateTileXML()
   3:     {
   4:         // Construct the square template
   5:         NotificationsExtensions.TileContent.ITileSquarePeekImageAndText02 squareTile = 
   6:             NotificationsExtensions.TileContent.TileContentFactory.CreateTileSquarePeekImageAndText02();
   7:         squareTile.Branding = NotificationsExtensions.TileContent.TileBranding.None;        
   8:         squareTile.Image.Src = "http://www.kraigbrockschmidt.com/images/Liam07.png";
   9:         squareTile.TextHeading.Text = "Liam--";
  10:         squareTile.TextBodyWrap.Text = "Giddy on the day he learned to sit up!";
  11:         
  12:         // Construct the wide template
  13:         NotificationsExtensions.TileContent.ITileWideSmallImageAndText04 wideTile =
  14:             NotificationsExtensions.TileContent.TileContentFactory.CreateTileWideSmallImageAndText04();
  15:         wideTile.Branding = NotificationsExtensions.TileContent.TileBranding.None;
  16:         wideTile.Image.Src = "http://www.kraigbrockschmidt.com/images/Liam08.png";
  17:         wideTile.TextHeading.Text = "This is Liam";
  18:         wideTile.TextBodyWrap.Text = "Exploring the great outdoors!";
  19:                 
  20:         // Attach the square template to the notification
  21:         wideTile.SquareContent = squareTile;
  22:         wideTile.Lang = "en-US";
  23:         
  24:         // The wideTile object is an XMLDOM object, suitable for issuing tile updates
  25:         // directly. In this case we just want the XML text.
  26:         return wideTile.ToString();        
  27:     }
</script>
<%   1:  = GenerateTileXML() 
%>

Vous pouvez accéder à ce service à l'adresse http://programmingwin8-js-ch13-hellotiles.azurewebsites.net/DefaultNE.aspx. Vous y obtiendrez globalement le même retour XML qu'auparavant, à quelques petites exceptions près. Si vous collez l'URI du scénario 4 de l'exemple de notifications Push et de notifications périodiques côté client, vous obtiendrez les mêmes mises à jour de vignette qu'auparavant.

Débogage des services

Pour créer une mise à jour de vignette ou de badge qui fonctionne correctement, il faut bien évidemment que la syntaxe XML de la réponse du service soit correcte : Windows rejette systématiquement le code XML dont la syntaxe est incorrecte. Raison de plus pour utiliser la bibliothèque Notifications Extensions, puisqu'elle réduit significativement le risque d'introduire des erreurs au cours du processus.

Que faire si votre service ne fonctionne pas du tout ? Comment diagnostiquer et déboguer la gestion des requêtes et générer une réponse ?

En fait, la première fois que j'ai utilisé le code du service ASP.NET ci-dessus, les mises à jour n'apparaissaient pas, car le haut de la réponse XML contient un saut de ligne. Voilà la raison pour laquelle l'en-tête <?xml ?> apparaît en tant que première ligne du fichier et non pas après l'instruction <%@ Page %>, ce qui explique aussi l'absence de sauts de ligne supplémentaires.

Pour de nombreuses raisons, il est souhaitable d'exécuter le code du service pas à pas et de le déboguer ligne par ligne, en particulier si vous interrogez une base de données et que vous traitez ces résultats de requête.

Pour cela, vous pouvez utiliser localhost sur votre machine de développement, ce qui vous permet d'exécuter et de déboguer votre service localement en même temps que vous exécutez le code de tests client (exemples de SDK, par exemple).

Pour disposer d'un localhost, vous devez exécuter un serveur Web local tel qu'Internet Information Services ou Apache. Pour activer les services IIS dans Windows (ces services sont intégrés dans Windows), cliquez sur Panneau de configuration > Activer ou désactiver des fonctionnalités Windows. Pour installer les fonctionnalités essentielles, cochez la case Services Internet (IIS) qui se trouve en haut, comme sur l'image ci-dessous :

Une fois les services Internet installés, le site local accessible à l'adresse http://localhost/ est disponible dans le dossier c:\inetpub\wwwroot. C'est dans ce dossier que vous devez déposer les éléments tels que la page PHP décrite dans la section précédente, afin de pouvoir utiliser un URI tel que http://localhost/dayofmonthservice.php dans les exemples clients.

Pour utiliser PHP avec les services Internet, il peut être nécessaire de l'installer via Microsoft Web Platform Installer. Sinon, le code côté serveur risque de ne pas s'exécuter correctement. Au terme de l'installation de PHP, essayez d'entrer l'URI d'une page PHP locale dans votre navigateur. Si un message d'erreur indiquant que le gestionnaire PHP53_via_FastCGI contient un module incorrect�� (un message qui ne vous aide pas beaucoup, avouons-le) s'affiche, retournez à la boîte de dialogue Activer ou désactiver des fonctionnalités Windows, accédez à Services Internet (IIS) > Services World Wide Web > Fonctionnalités de développement d'applications, cochez la case CGI, puis appuyez sur OK. Une fois le moteur CGI installé, en principe votre page PHP fonctionne.

Maintenant que le localhost est en place, vous pouvez déboguer les services sur votre ordinateur à l'aide de Visual Studio Express pour le Web ou de Visual Studio Ultimate. Vous pouvez aussi utiliser Visual Studio Express pour le Web aux côtés de Visual Studio Express pour Windows, afin de déboguer le code côté client et côté serveur simultanément.

Lorsque vous exécutez un service ou un site Web dans le débogueur de Visual Studio (pour le Web), il s'exécute dans le navigateur à une URL telle que http://localhost:<port>/, où <port> est un port affecté de façon aléatoire à ce projet. Par exemple, lorsque j'exécute la page DefaultNE.aspx de la section précédente dans Visual Studio Express pour le Web, cette page s'ouvre dans Internet Explorer à l'URI http://localhost:52568/HelloTiles/DefaultNE.aspx. Si j'ai défini un point d'arrêt dans le code de cette page, le débogueur s'arrête immédiatement à ce point.

Les points d'arrêt sont également atteints si vous utilisez le même URI de localhost dans le code client pour initier les requêtes. Ainsi, par exemple, si j'exécute l'exemple de notifications Push et de notifications périodiques côté client dans Visual Studio Express pour Windows et que je colle l'URI dans le scénario 4, Visual Studio Express pour le Web arrête mon service dans le débogueur dès que Windows crée une requête. Je peux ensuite exécuter ce code pas à pas (heureusement, Windows est patient), et m'assurer que la réponse adéquate est générée. Si cela n'est pas le cas, je peux corriger le code et redémarrer le service sur le localhost.

Lorsque vous êtes certain que votre service fonctionne comme prévu, vous pouvez ensuite le télécharger sur votre hôte Web dynamique (ou votre environnement intermédiaire) et procéder aux derniers tests de production.

Sachez qu'il n'est pas nécessaire d'exécuter le code client dans un débogueur pour utiliser le localhost de cette manière. Cependant, pour que le localhost fonctionne, vous devez activer une option dans Visual Studio. Elle est activée par défaut, mais si vous devez la modifier, vous la trouverez dans les propriétés du projet sous Débogage > Autoriser le bouclage de réseau local :

Données issues de sources externes

En plus d'interroger sa propre base de données, un service de notification périodique peut tout à fait envoyer des requêtes à d'autres services afin d'obtenir des données à intégrer dans sa réponse. Cependant, ces requêtes sont asynchrones par nature et fréquemment sujettes à différentes conditions d'échec. Par conséquent, leur utilisation peut compliquer significativement l'implémentation de votre service.

Pour simplifier les choses, nous pouvons profiter du fait que Windows envoie des requêtes à votre service au maximum toutes les 30 minutes, selon l'intervalle mis en œuvre par l'API client. Par conséquent, vous disposez d'un délai confortable pendant lequel d'autres processus côté serveur peuvent envoyer des requêtes externes pour surveiller des alertes météo, des tableaux de scores, des flux RSS et à peu près toutes les informations pour lesquelles il existe une API Web. Ces processus stockent les résultats dans votre base de données et ces résultats peuvent donc être interrogés par votre service de notification périodique (de façon synchrone) lorsqu'il reçoit la requête suivante.

En effet, de nombreux agents peuvent mettre à jour la même base de données. Par exemple, les utilisateurs peuvent entrer des données via votre site Web. Ils peuvent aussi utiliser des applications mobiles pour suivre leurs activités, ce qui entraîne l'importation de résultats dans une base de données. La base de données peut également être mise à jour par des amis qui utilisent la même application ou leurs propres appareils.

Cette configuration est illustrée ci-dessous : la base de données joue le rôle de magasin central pour votre état principal et le service de notification périodique joue uniquement le rôle de simple consommateur de cet état.

Utilisation des services mobiles Windows Azure avec les services de mise à jour périodique

Maintenant que vous commencez à mieux comprendre le fonctionnement et la mise en place des services principaux pour la prise en charge des vignettes dynamiques et d'autres notifications, il vous appartient d'étudier les services mobiles Windows Azure (AMS). En plus de simplifier de façon significative les notifications Push (comme nous le verrons dans la troisième partie de cette série), les services AMS peuvent être utilisés pour prendre en charge les services de mise à jour périodique de différentes manières :

Dans un service mobile, vous pouvez créer des tâches d'arrière-plan planifiées qui envoient des requêtes à d'autres services et stockent les résultats dans votre base de données. Un exemple permettant d'obtenir des tweets de Twitter est disponible dans la rubrique Schedule recurring jobs in Mobile Services (Planifier des tâches récurrentes dans les services mobiles).
Lorsque vous créez une base de données SQL Server dans les services AMS (ou ailleurs dans Windows Azure), cette base de données est accessible comme n'importe quelle autre base de données SQL Server hébergée sur le Web. Vous pouvez donc l'utiliser à partir de sites Web et d'autres services, y compris ceux écrits en PHP.
Les services AMS facilitent l'insertion d'enregistrements dans une base de données à partir d'une application cliente, à l'aide du SDK des services mobiles.
En dehors des services mobiles, Windows Azure peut héberger des processus côté serveur écrits dans différents langages, notamment Node.js, Python, Java, PHP et .NET.

À l'avenir, pensez également à utiliser une nouvelle fonctionnalité appelée « opérations de service » dans les services mobiles Azure. Elle permet de créer des points d'arrêt http arbitraire, notamment un service de notification périodique.

Pour plus d'informations sur Windows Azure, consultez le site http://www.windowsazure.com. Pour découvrir des vidéos de présentation, consultez également les didacticiels consacrés aux services mobiles Windows Azure sur le site Channel 9.

Maintenant que nous avons vu comment créer des services de notification périodique, nous pouvons passer à l'étape suivante et aborder les notifications Push. Les notifications Push sont nécessaires lorsque vous devez transmettre des mises à jour plus fréquemment que ne le permettent les notifications périodiques, et plus généralement à la demande. Nous aborderons ce sujet dans la troisième partie de cette série de billets, où nous découvrirons bien plus en détail les services mobiles Azure.

Kraig Brockschmidt
Chef de projet, équipe Écosystème Windows
Auteur de Programming Windows 8 Apps in HTML, CSS, and JavaScript

Un système animé et dynamique, première partie : utilisation des vignettes, des badges et des toasts

Windows 8 Team — Wed, 06 Mar 2013 00:08:26 GMT

Les vignettes dynamiques et les fonctionnalités associées (badges, notifications toast et notifications Push) font partie des éléments les plus caractéristiques de Windows 8 et des applications du Windows Store. Elles se combinent les unes aux autres pour créer un « système animé et dynamique » : les applications reçoivent en permanence des flux d'informations issus de leurs services, visibles à la fois sur l'écran d'accueil et sur l'écran de verrouillage, mêmes lorsqu'elles ne sont pas en cours d'exécution.

Dans de précédents billets publiés sur ce blog, nous avons déjà abordé quelques-uns des principaux aspects des vignettes dynamiques et des notifications.

Pour rappel :

Création d'une expérience utilisateur optimale en matière de vignettes (première partie) : ce billet explique comment concevoir une vignette et choisir un modèle basé sur la fonction première de l'application.
Création d'une expérience utilisateur optimale en matière de vignettes (deuxième partie) : ce billet décrit comment une application envoie des mises à jour locales, met en place des notifications périodiques et gère les vignettes secondaires. Il présente également la structure des services, aussi bien pour PHP que pour ASP.NET.

Pour prolonger les informations figurant dans ces ressources, ce billet en trois parties aborde de façon plus approfondie plusieurs domaines.

Voici les thèmes abordés dans la première partie (ce billet) :

Courte présentation en images de l'expérience utilisateur : que signifie ce « système animé et dynamique » pour l'utilisateur ?
Schéma XML des vignettes, des badges, et des notifications toast, qui présente différentes fonctionnalités et caractéristiques qui ne sont pas forcément évidentes au vu des catalogues de modèles.
Relation entre les vignettes, les notifications et les tâches d'arrière-plan.

Dans la deuxième partie, nous aborderons le développement et le débogage des services dans plusieurs langues. Nous utiliserons en particulier localhost et Visual Studio 2012 Express for Web/Visual Studio 2012. La deuxième partie abordera aussi l'utilisation des services mobiles Windows Azure, également dans le cadre du développement et du débogage.

La troisième partie portera quant à elle sur les notifications Push. Nous verrons notamment comment utiliser les Services de notifications Push Windows (WNS) ainsi que les services mobiles Windows Azure pour prendre en charge les notifications Push dans les applications.

Ces trois parties s'inscrivent dans le prolongement la présentation que j'ai animée au cours de la conférence //Build 2012, intitulée 3-101 Alive With Activity, et dont vous trouverez la vidéo et les diapositives sur le site Channel 9. Elles prolongent également les ressources du Chapitre 13 de mon livre électronique gratuit publié par Microsoft Press, Programming Windows 8 Apps in HTML, CSS, and JavaScript (malgré son titre, il peut également être utile aux développeurs travaillant avec d'autres langages).

Que signifie ce « système animé et dynamique » pour l'utilisateur ?

Le « système animé et dynamique » que nous évoquons dans cette série de billets est visible à trois endroits du système : dans l'écran d'accueil, dans l'écran de verrouillage et partout où des notifications toast sont susceptibles de s'afficher.

En ce qui concerne l'écran d'accueil, vous connaissez maintenant très bien le concept de vignette. Comme le montrent les exemples ci-dessous, les vignettes peuvent être carrées ou rectangulaires. Leur disposition est très variable, puisqu'il est possible d'afficher du texte, des images ou les deux à la fois. Les couleurs sont définies par le manifeste de l'application. L'utilisateur peut choisir le format de la vignette (carré ou rectangulaire), à condition toutefois que l'application prenne en charge les deux formats. La partie inférieure gauche de la vignette peut afficher le nom de l'application, un logo ou rien du tout. La partie inférieure droite peut contenir un petit badge, c'est-à-dire un nombre compris entre 1 et 99 (pour les courriers électroniques, les messages instantanés, etc.) ou l'un des glyphes prédéfinis (pour en savoir plus, consultez le Catalogue des images de badges).

Les modèles de vignettes intègrent également différentes présentations de type « aperçu », qui alternent entre une partie du contenu (une image, par exemple) et une deuxième partie, par exemple du texte (dans le Catalogue de modèles de vignette, ces modèles ressemblent à des vignettes deux fois plus hautes que la normale, parce que les deux moitiés sont affichées l'une au-dessus de l'autre). Le système anime les transitions entre ces deux parties, en parfaite harmonie avec les autres animations appliquées aux vignettes. Par ailleurs, chaque vignette peut posséder une file d'attente contenant jusqu'à cinq mises à jour cycliques, qui sont à leur tour animées par le système en coordination avec d'autres vignettes. Chaque mise à jour présente en file d'attente peut posséder une balise qui vous permet de les remplacer de façon individuelle. Dans le cas contraire, la file d'attente est traitée dans l'ordre d'arrivée.

Cette coordination entre les animations explique en partie pourquoi Windows limite les mises à jour des vignettes à un ensemble de modèles prédéfinis. Imaginez ce que serait l'expérience utilisateur de l'écran d'accueil si les applications pouvaient afficher absolument tout et n'importe quoi sur leurs vignettes. Si Windows offrait la liberté de lire des vidéos sur les vignettes, l'autonomie de la batterie diminuerait bien plus vite, par exemple, mais surtout l'écran d'accueil deviendrait véritablement anarchique. Alors oui, nous aurions là l'exact opposé d'un écran d'accueil entièrement statique, mais ce ne serait certainement pas beau à voir ! Les concepteurs de Windows souhaitaient mettre à votre disposition un écran d'accueil plaisant à regarder sur une longue durée. C'est pourquoi ils ont mis au point une expérience utilisateur animée et dynamique, mais qui respire l'unité et l'harmonie entre toutes les vignettes. L'utilisation de modèles et d'animations contrôlées par le système entraîne une certaine uniformité, mais autorise des variations significatives d'une application à l'autre. (Par ailleurs, n'oubliez pas que vous pouvez toujours utiliser un modèle contenant uniquement une image et y insérer ainsi la présentation que vous souhaitez. Évitez toutefois de créer des images contenant des boutons suggérant la possibilité de réaliser différentes actions à partir de différentes zones de la vignette, ce qui est techniquement impossible.)

Les notifications toast apparaissent par-dessus l'écran d'accueil, l'écran de verrouillage, le Bureau ou toute autre application en cours d'exécution. En appuyant sur une notification toast, vous activez l'application correspondante, en fonction des arguments spécifiés au moment de l'émission du toast. Les toasts s'affichent dans la couleur définie par le manifeste de l'application concernée et contiennent le logo de l'application (en bas à droite). La couleur et le logo facilitent l'identification de l'application, qui est activée dès que l'utilisateur appuie sur le toast.

Comme pour les vignettes, la disposition de chaque toast est définie par un modèle issu du Catalogue de modèles de toast, qui offre différentes possibilités de présentation (texte uniquement ou texte+image). Les toasts s'affichent pendant une durée bien précise, puis disparaissent progressivement de l'écran. Elles peuvent être accompagnées d'un son et être répétées, comme pour des rappels de rendez-vous.

Dans l'écran de verrouillage, l'activité des applications s'affiche aux côtés de la date, de l'heure et des badges système. Comme dans l'exemple ci-dessous, une application peut afficher jusqu'à sept logos et badges en bas de la vignette et une mise à jour textuelle située près de l'heure :

L'utilisateur contrôle les informations affichées sur l'écran de verrouillage par le biais du menu Paramètres du PC > Personnaliser > Écran de verrouillage (voir l'exemple ci-dessous). Sur la première ligne, le fait d'appuyer sur l'un des carrés affiche une liste d'applications compatibles avec l'écran de verrouillage, présentées au moyen d'un logo et d'un badge. Sur la deuxième ligne, vous pouvez choisir l'application chargée de fournir le texte détaillé. Ce texte provient plus précisément de la dernière mise à jour de la vignette de l'application correspondante.

Code XML des mises à jour

Maintenant que nous savons ce qui se passe côté utilisateur en matière d'animations, une question se pose : en quoi consistent exactement ces mises à jour ? En d'autres termes, à quoi correspond une mise à jour de vignette, un badge ou une notification toast ?

Dans tous les cas, à l'exception des notifications brutes, les mises à jour sont de simples fragments de code XML que Windows peut traiter pour mettre à jour une vignette ou afficher un toast. (Les notifications brutes contiennent du texte ou des données binaires propres à l'application. Les applications et les tâches d'arrière-plan qui reçoivent ces notifications traitent en général ces données elles-mêmes et génèrent des mises à jour de vignette ou de badge, ou des toasts.)

Les modèles précédemment mentionnés ne sont en fait que de simples structures XML bien précises destinées à accueillir ces mises à jour. Par exemple, une mise à jour de badge pour le numéro 7 ressemble à ceci :

<badge value="7"/>

Nous appelons souvent ces fragments de code XML des charges utiles. En voici une similaire, correspondant au badge représentant un point rouge, situé dans la vignette centrale du bas sur la première image de ce billet :

<badge value="busy"/>

La charge utile XML de cette même vignette rectangulaire, qui inclut une référence à son image, au texte et aux options de logo/nom, ressemblerait plus ou moins à l'extrait de code ci-dessous (l'URI de l'image est fictif), qui utilise le modèle TileWideSmallImageAndText01 :

<tile>
  <visual>
    <binding template="TileWideSmallImageAndText01" branding="logo">
      <image id="1" src="http://friends.contoso.com/sally.png" alt="Sally's picture"/>
      <text id="1">Hey, you there? Txt me when you’re back</text>
    </binding>
  </visual>
</tile>

Dans cette charge utile, vous pouvez constater que nous identifions le modèle par le biais de l'élément binding. Windows valide le reste du code XML par rapport à ce modèle. L'attribut branding de l'élément binding indique s'il faut afficher le logo, le nom de l'application (name) ou ni l'un ni l'autre (none). Les éléments enfants de binding décrivent ensuite les autres parties requises du modèle.

Plus que les modèles spécifiques de ces mises à jour, il est intéressant d'étudier le schéma général de leur code XML, car celui-ci révèle d'autres fonctionnalités qui peuvent être exploitées avec chaque mise à jour. En effet, le Catalogue de modèles de vignette, le Catalogue des images de badges et le Catalogue de modèles de toast indiquent uniquement les éléments obligatoires. Le schéma, de son côté, montre toutes les options supplémentaires.

Les schémas sont décrits dans la section de la documentation consacrée aux schémas des vignettes, des toasts et des badges. Cependant, les informations détaillées étant éparpillées dans de nombreux sujets, je vais les regrouper ici dans un pseudo-schéma qui nous permet d'examiner les structures dans leur ensemble.

Commençons par les mises à jour de badge, qui sont les plus simples :

<?xml version="1.0" encoding="utf-8" ?>
<badge value = "1-99" | "none" | "activity" | "alert" | “attention” | "available" |
    "away" | "busy" | "newMessage" | "paused" | "playing" | "unavailable" | "error" 
    version? = "integer" />

D'un point de vue technique, toutes les charges utiles XML doivent contenir la balise d'en-tête <?xml>. Windows fonctionne correctement sans cette balise, mais pour plus d'exhaustivité, je préfère l'inclure.

Vous remarquez ensuite que l'élément badge contient uniquement un attribut value, qui peut être un nombre (toutes les valeurs supérieures à 99 s'affichent sous la forme « 99+ ») ou l'un des mots prédéfinis qui identifient des glyphes spécifiques. Ceux-ci sont également décrits dans la page Catalogue des images de badges de la documentation.

Le seul autre attribut présent est l'attribut facultatif version (le ? situé après le nom indique qu'il est facultatif), ce qui permet de modifier le schéma par la suite. Celui-ci étant facultatif, vous pouvez l'omettre dans vos charges utiles pour le moment.

Les mises à jour de vignette possèdent le pseudo-schéma suivant :

<?xml version="1.0" encoding="utf-8" ?>
<tile>
  <visual version? = "integer" lang? = "string" baseUri? = "anyURI" fallback? = "string"
    branding? = "none" | "logo" | "name" addImageQuery? = "boolean" >

    <!-- One or more binding elements -->
    <binding template = "TileSquareImage" | "TileSquareBlock" | "TileSquareText01" | ... 
      fallback? = "string" lang? = "string" baseUri? = "anyURI"
      branding? = "none" addImageQuery? = "boolean" >
      
      <!-- Some combination of image and text elements -->
      <image id = "integer" src = "string" alt? = "string" addImageQuery? = "boolean" />
      <text id = "integer" lang? = "string" />
    </binding>
  </visual>
</tile>

Dans l'élément visual, qui contient des attributs qui s'appliquent à l'intégralité de la mise à jour, se trouve l'attribut facultatif version, que vous pouvez également omettre pour le moment. Voici la liste des autres attributs :

Attribut	Description
lang	Chaîne de langue BCP-47 facultative, identifiant la langue utilisée dans les données de la mise à jour, par exemple « en-US » ou « fr-FR ».
baseUri	URI facultatif ajouté en tant que préfixe aux autres URI de la charge utile. Il vous permet d'omettre ces informations redondantes lors de la création de la charge utile. La valeur par défaut est « ms-appx:/// ».
branding	Indique s'il faut afficher le logo de l'application sur la vignette (valeur par défaut « logo »), le nom de l'application (« name ») ou aucune de ces deux informations (« none »).
addImageQuery	Si la valeur de cet attribut est « true » (sa valeur par défaut est « false »), Windows ajoute des paramètres de requête après chacune des requêtes envoyées aux URI de la charge utile, c'est-à-dire à chaque URI d'image, afin d'identifier la langue actuelle, le facteur d'échelle et le paramètre de contraste. Le format des paramètres est le suivant : ?ms-scale=<échelle>&ms-contrast=<contraste>&ms-lang=<langue> Pour plus d'informations, voir Globalisation et accessibilité pour les notifications par vignette et toast.

Dans l'élément visual, la charge utile possède ensuite un ou plusieurs éléments binding : un pour chaque taille de vignette. Ainsi, une même charge de travail peut contenir (ou doit contenir, dans l'idéal) une mise à jour pour les vignettes carrées et rectangulaires. Ces informations sont importantes, car l'utilisateur peut modifier la taille de la vignette à tout moment. Si vous omettez une des tailles, la mise à jour ne s'affichera pas si l'utilisateur a choisi d'afficher la vignette à cette taille. Sachez cependant que vous pouvez envoyer des mises à jour séparées pour chaque taille : dans ce cas, Windows conserve les deux mises à jour.

Dans l'élément binding, vous pouvez constater que template identifie le modèle XML à valider. Les mêmes attributs que ceux de visual sont également présents, mais ils s'appliquent uniquement aux éléments figurant dans binding (et sont donc prioritaires sur ceux de visual). L'autre attribut est fallback, qui identifie le modèle à utiliser si le modèle principal est introuvable. Cet attribut permettra d'assurer une compatibilité descendante dans les futures versions de Windows et n'est donc d'aucune utilité avec Windows 8.

Chaque binding contient une combinaison d'éléments image et text, selon le modèle utilisé. Les attributs de ces éléments sont suffisamment explicites ou ont déjà été abordés. Comme vous pouvez vous y attendre, les attributs des éléments image et text qui figurent également dans binding ou visual remplacent les valeurs des mêmes attributs figurant dans les éléments parents.

Pour les notifications toast, la structure est similaire à celle des vignettes, mais offre des fonctionnalités supplémentaires :

<toast launch? = "string" duration? = "long" | "short" >
  <visual version? = "integer" lang? = "string"
    baseUri? = "anyURI" branding? = "none" | "name" | "logo" addImageQuery? = "boolean" >

    <!-- One or more bindings -->
    <binding template  = "ToastImageAndText01" | "ToastImageAndText02" | ...=""
      fallback? = "string"  lang? = "string" baseUri? = "anyURI"
      branding? = "none" addImageQuery? = "boolean" >

      <!-- Some number of child elements -->
      <image id  = "integer" src = "string" alt = "string" addImageQuery? = "boolean" />
      <text id = "integer" lang? = "string" />
    </binding>
  </visual>

  <!-- Optional audio -->
  <audio src? = "ms-winsoundevent:Notification.Default" | ...=""
    loop? = "boolean" silent? = "boolean" />
</toast>

L'ensemble des attributs lang, baseUri, branding et addImageQuery de visual ont la même signification et les mêmes valeurs par défaut que pour les vignettes, tout comme les attributs des attributs binding, image et text. Dans cette partie de la charge de travail, la seule différence entre une mise à jour de vignette et une notification toast réside dans les modèles pris en charge.

La particularité de la charge de travail d'un toast réside dans les attributs de l'élément toast situé le plus à l'extérieur et dans son enfant facultatif audio.

Avec toast, il est possible d'affecter à l'attribut launch une chaîne qui sera transmise sous forme d'arguments au gestionnaire d'activation de l'application, comme avec une vignette secondaire. L'attribut duration peut prendre la valeur « short » (cinq secondes ou la valeur définie dans Paramètres du PC > Options d'ergonomie) ou « long » (25 secondes ou la valeur définie dans Paramètres du PC > Options d'ergonomie, la plus longue des deux étant prise en compte).

Dans audio, l'attribut src est une chaîne indiquant un son parmi les sons prédéfinis disponibles dans le Catalogue d'options audio de toast. Pour le moment, le choix se limite à ces sons, qui sont généralement associés aux sons système configurés dans le Panneau de configuration. (Remarque : si vous désactivez tous les sons, comme j'ai l'habitude de le faire, vous n'entendrez rien... Pensez-y lorsque vous testez votre application !) Cette limitation s'explique par plusieurs raisons. Ainsi, le fait d'inclure des sons personnalisés à partir d'une source distante générerait beaucoup plus de trafic réseau, ce qui pourrait vite devenir un problème lorsque l'appareil affiche l'écran de verrouillage et essaie d'économiser de l'énergie en mode de veille connectée. Elle empêche également certains abus : les toasts pourraient par exemple être utilisés pour diffuser des publicités sonores.

Par ailleurs, si la valeur de l'attribut silent est « true », le son de l'appareil est systématiquement coupé. Comme pour loop, si l'attribut duration du toast est défini et que vous configurez src sur l'un des quatre sons « looping » du catalogue (deux variations pour « Alarm » et deux autres pour « Call »), vous pouvez également configurer loop sur la valeur « true » pour répéter le son ou sur la valeur « false » pour lire le son une seule fois (valeur par défaut).

En dehors de la lecture audio en boucle, il est également possible de planifier un toast déclenché à intervalle régulier. Ce comportement ne fait pas partie de la charge utile XML : en effet, vous l'activez lors de la création de l'objet ScheduledToastNotification. Dans ces cas, la même charge utile (son et autres informations) est affichée à chaque intervalle.

Un système animé sans applications en cours d'exécution

Une fois que vous savez quels types de mises à jour seront générés par quelles charges utiles XML, vous devez étudier comment ces charges utiles sont transmises au système à l'heure adéquate et comment elles sont créées. Nous avons déjà évoqué ces deux sujets dans de précédents billets, Création d'une expérience utilisateur optimale en matière de vignettes (première partie) et Création d'une expérience utilisateur optimale en matière de vignettes (deuxième partie), qui montrent comment générer les charges utiles dans le code. Pour cela, nous utilisons la bibliothèque NotificationsExtensions, qui est incluse dans différents exemples et est également disponible par le biais de Visual Studio sous forme de package NuGet.

Essayons de récapituler les méthodes permettant de fournir ces charges utiles. Trois moyens sont à notre disposition :

Une application en cours d'exécution ou une tâche d'arrière-plan d'application peuvent émettre des mises à jour directes ou des mises à jour locales. Celles-ci peuvent être immédiates ou être programmées à une heure ultérieure. Les vignettes, les badges et les toasts peuvent également avoir une heure d'expiration, à laquelle elles sont automatiquement supprimées ou retirées du calendrier, si elles n'ont pas encore été livrées.
Une application en cours d'exécution peut transmettre à Windows jusqu'à cinq URI pour les mises à jour périodiques et spécifier des intervalles compris entre 30 minutes et un jour. (Lorsque plusieurs URI sont utilisés, chacun d'entre eux correspond à l'un des cinq emplacements de la file d'attente des mises à jour.) Dès lors qu'une mise à jour périodique a été configurée, Windows envoie une requête (HTTP GET) à cet URI, à chaque intervalle. Si Windows reçoit en retour une charge utile valide, il envoie la mise à jour à la vignette adéquate de la part de l'application, exactement comme si elle avait été émise directement par l'application elle-même. Nous expliquerons comment créer des services de mise à jour dans la deuxième partie de cette série.
Les mises à jour périodiques offrent un avantage majeur : les requêtes continuent même si l'application n'est pas en cours d'exécution, ce qui permet à la vignette de recevoir des mises à jour et des badges en continu, sans que l'utilisateur soit obligé d'ouvrir l'application. Bien évidemment, j'espère que vos mises à jour sont suffisamment intéressantes pour inciter l'utilisateur à utiliser le plus souvent possible votre application !
Une application peut demander un URI de canal de notifications Push Windows (WNS) et envoyer cet URI à ses propres services principaux. Ces services peuvent ensuite émettre des mises à jour de toutes sortes via WNS, à travers cet URI de canal. À son tour, WNS envoie la mise à jour à l'appareil concerné lorsqu'il est connecté. Windows reçoit les mises à jour et les applique à la vignette adéquate ou affiche le toast. Une autre solution existe : une application peut configurer une tâche d'arrière-plan de façon à recevoir ces notifications Push (cette tâche est requise pour les notifications brutes). Nous aborderons les notifications Push dans la troisième partie de cette série de billets.

Le tableau ci-dessous résume les options et fournit des informations sur la fonctionnalité de file d'attente cyclique des vignettes, ainsi que sur les fonctionnalités de récurrence et de son des toasts :

Type de notification	Notification de file d'attente	Notification programmée	Notification d'expiration	Notification récurrente	Notification audio	Notification périodique	Notification Push
Vignette	✔	✔	✔			✔	✔
Badge			✔			✔	✔
Toast		✔	✔	✔	✔		✔
Notification brute							✔

Il est important de remarquer que toutes les informations de ce billet relatives aux vignettes et aux badges s'appliquent aussi bien à la vignette principale d'une application qu'aux vignettes secondaires. Les billets de blog mentionnés ci-dessus fournissent des informations complémentaires sur les vignettes secondaires. Pour en savoir plus, vous pouvez également consulter l'exemple de vignettes secondaires.

Puisque nous évoquons les exemples, sachez aussi que l'exemple de vignettes et de badges d'application, l'exemple de notifications planifiées et l'exemple de notifications Push et de notifications périodiques côté client sont à votre disposition pour découvrir différents scénarios. Dès lors que vous vous intéressez aux vignettes et aux notifications dans votre application, nous vous recommandons de vous familiariser avec le code détaillé dans ces exemples.

Rappelez-vous également que les mises à jour de vignette, de badge et de toast peuvent être générées à partir de tâches d'arrière-plan. De mon point de vue, les tâches d'arrière-plan constituent une sorte de code d'application qui est exécuté même lorsque l'application elle-même est suspendue, voire totalement absente de la mémoire. L'émission d'une mise à jour à partir d'une tâche d'arrière-plan utilise le même code que l'application principale et il n'y a donc aucune différence véritable à signaler.

Les tâches d'arrière-plan sont idéales pour vérifier l'état de diverses conditions. Cette opération peut être effectuée rapidement et respecte ainsi les quotas de charge processeur consommés par ces tâches. Lorsque les conditions l'exigent, la tâche d'arrière-plan peut générer une notification appropriée. En effet, le rôle principal d'une tâche d'arrière-plan est (a) d'émettre les mises à jour ou (b) d'enregistrer des valeurs dans les dossiers AppData de l'application ou dans le conteneur de paramètres que l'application traitera lors de sa prochaine exécution.

Les tâches d'arrière-plan sont également essentielles dans le cadre du traitement des notifications Push brutes lorsque l'application n'est pas en cours d'exécution, mais nous y reviendrons également dans la troisième partie.

Pour plus d'informations sur les tâches d'arrière-plan, consultez le billet précédemment publié sur ce blog intitulé Rester productif lorsque votre application n'est pas à l'écran : tâches en arrière-plan, ainsi que la présentation plus générale Rester productif lorsque votre application n'est pas à l'écran.

Forts de ces informations, nous sommes maintenant prêts à quitter le confort familier des applications clients pour étudier le rôle des services en ligne et ce qu'ils apportent à vos vignettes, vos badges et vos toasts. Nous aborderons ce sujet dans les deuxième et troisième parties.

Kraig Brockschmidt
Chef de projet, équipe Écosystème Windows
Auteur de Programming Windows 8 Apps in HTML, CSS, and JavaScript