Lorsque vous développez des applications du Windows Store en JavaScript, vous rencontrez des constructions appelées promesses dès que vous réalisez une action impliquant une API asynchrone. En très peu de temps, vous pouvez écrire facilement des chaînes de promesses pour les opérations séquentielles asynchrones.

Au cours de votre travail de développement, vous rencontrerez cependant d'autres usages des promesses, dont les principes de fonctionnement peuvent paraître moins évidents. L'optimisation des fonctions de rendu des éléments d'un contrôle ListView est un bon exemple, comme le montre l'exemple d'optimisation des performances de contrôle HTML ListView. Nous examinerons cet exemple plus en détail dans un prochain billet. Vous pouvez également découvrir cette fabuleuse démonstration (dans une version légèrement modifiée) présentée par Josh Williams lors de son intervention à la conférence //build 2012, et intitulée Deep Dive into WinJS :

list.reduce(function callback (prev, item, i) {
    var result = doOperationAsync(item);
    return WinJS.Promise.join({ prev: prev, result: result}).then(function (v) {
        console.log(i + ", item: " + item+ ", " + v.result);
    });
})

Cet extrait de code rejoint les promesses d'opérations asynchrones parallèles et fournit leur résultat de façon séquentielle, selon leur ordre d'apparition dans l'élément list. Si en examinant ce code, vous comprenez immédiatement son fonctionnement, vous pouvez passer ce billet ! Dans le cas contraire, examinons ensemble comment fonctionnent réellement les promesses et comment elles sont exprimées dans WinJS (la bibliothèque Windows pour JavaScript), afin de mieux comprendre les types de schémas mis en jeu.

Une promesse ? De quoi s'agit-il exactement ? Les relations de promesse

Commençons par établir une vérité fondamentale : une promesse n'est rien d'autre qu'une construction de code ou, si vous préférez, une convention d'appel. En tant que telles, les promesses n'ont aucune relation intrinsèque avec les opérations asynchrones, elles sont simplement très utiles dans ce contexte ! Une promesse est tout simplement un objet représentant une valeur pouvant être disponible à tel ou tel moment dans le futur, mais qui peut également être déjà disponible. À cet égard, la promesse est semblable à sa définition usuelle dans le cadre des relations humaines. Si je dis à quelqu'un « Je te promets que je vais t'apporter des croissants », il est parfaitement clair que je ne possède pas encore les croissants, mais que je suppose que je les aurai à un moment ou à un autre. Une fois que je les ai en ma possession, je les apporte à la personne en question.

Ainsi, une promesse implique une relation entre deux agents : l'initiateur, qui fait la promesse d'apporter telle ou telle marchandise, et le consommateur, qui est à la fois le destinataire de la promesse et des marchandises. Peu importe la manière dont l'initiateur parvient à obtenir les marchandises, cela ne concerne pas le destinataire. De même, le consommateur peut faire ce que bon lui semble de la promesse elle-même et des marchandises livrées. Il peut même partager les marchandises obtenues avec d'autres consommateurs.

La relation entre l'initiateur et le consommateur se compose de deux étapes : la création et la réalisation. Tous ces éléments sont indiqués sur le schéma ci-dessous.

Le fait que la relation se compose de deux étapes explique pourquoi les promesses fonctionnent parfaitement avec une livraison asynchrone, comme le montre le déroulement du flux sur le schéma. Une fois que le consommateur reçoit l'accusé de réception de la demande (la promesse), il peut « faire sa vie » (de façon asynchrone) au lieu d'attendre (de façon synchrone). Par conséquent, le consommateur peut faire autre chose pendant qu'il attend que la promesse soit réalisée. Il peut par exemple répondre à d'autres demandes, ce qui est justement le but principal des API asynchrones. Que se passe-t-il si les marchandises sont déjà disponibles ? La promesse est réalisée immédiatement, ce qui transforme l'ensemble du processus en une sorte de convention d'appel synchrone.

Bien évidemment, cette relation est un peu plus complexe que cela. Au cours de votre vie, vous avez certainement déjà fait des promesses, et des personnes vous ont également fait des promesses. Bien que la plupart de ces promesses aient été réalisées, en pratique de nombreuses promesses ne sont pas tenues : le livreur de pizzas, par exemple, n'est pas à l'abri d'un accident de la circulation ! Les promesses non tenues font partie de la vie quotidienne, et nous devons accepter cet état de fait, aussi bien dans nos vies personnelles qu'en matière de programmation asynchrone.

Dans la relation de promesse, l'initiateur doit donc disposer d'une méthode pour signaler qu'il ne peut pas tenir sa promesse. De son côté, le consommateur doit disposer d'une méthode pour vérifier l'affirmation de l'initiateur. Deuxièmement, en tant que consommateurs, nous sommes parfois impatients quant aux promesses qui nous sont faites ! Par conséquent, si l'initiateur peut suivre la progression de la réalisation de sa promesse, le consommateur doit également disposer d'un moyen de recevoir cette information. Troisièmement, le consommateur peut également annuler sa commande et signaler à l'initiateur qu'il n'a plus besoin des marchandises.

En ajoutant ces besoins à notre schéma, nous disposons désormais d'une vue d'ensemble de la relation :

Examinons maintenant comment ces relations se manifestent dans le code.

La construction de la promesse et les chaînes de promesses

En matière de promesses, il existe en fait plusieurs propositions et spécifications. Celle utilisée dans Windows et WinJS porte le nom Common JS/Promises A. Elle formule une promesse, laquelle est renvoyée par un initiateur pour représenter une valeur à transmettre ultérieurement. Cette promesse prend la forme d'un objet associé à une fonction appelée then. Les consommateurs s'abonnement à la réalisation de la promesse en appelant la méthode then. (Dans Windows, les promesses prennent aussi en charge une fonction similaire appelée done, qui est utilisée dans les chaînes de promesses, comme nous le verrons très vite.)

Le consommateur transmet jusqu'à trois fonctions optionnelles à cette fonction, sous forme d'arguments, dans l'ordre suivant :

1. Un gestionnaire Terminé. L'initiateur appelle cette fonction lorsque la valeur promise est disponible. Si cette valeur est déjà disponible (is ), le gestionnaire Terminé est appelé immédiatement (de façon synchrone) à partir de then.
2. Un gestionnaire d'erreurs facultatif, appelé lorsqu'il s'avère impossible d'acquérir la valeur promise. Pour une promesse donnée, le gestionnaire Terminé n'est jamais appelé si le gestionnaire d'erreur l'a été.
3. Un gestionnaire de progression facultatif, qui est appelé de façon périodique à partir de résultats intermédiaires, si l'opération prend en charge cette possibilité. (Dans WinRT, cela signifie que l'API a la valeur renvoyée IAsync[Action | Operation]WithProgress, celles dont la valeur est IAsync[Action | Operation] ne prenant pas en charge cette possibilité.)

Sachez que vous pouvez transmettre la valeur null pour l'ensemble de ces arguments, par exemple lorsque vous souhaitez attacher uniquement un gestionnaire d'erreurs et non pas un gestionnaire Terminé.

De l'autre côté de la relation, un consommateur peut abonner autant de gestionnaires qu'il le souhaite à la même promesse, en appelant then à plusieurs reprises. Il peut également partager la promesse avec d'autres consommateurs, qui peuvent aussi appeler then pour leur propre contenu. Cette possibilité est intégralement prise en charge.

Par conséquent, une promesse doit gérer des listes contenant l'intégralité des gestionnaires qu'elle reçoit, et les appeler au moment adéquat. Les promesses doivent également pouvoir être annulées, comme nous l'avons expliqué dans notre description complète de la relation.

Autre exigence de la spécification Promises A, la méthode then renvoie elle-même une promesse. Cette deuxième promesse est réalisée lorsque le gestionnaire Terminé envoyé au premier appel de la méthode promise.then renvoie une valeur, la valeur renvoyée étant transmise en tant que résultat de cette deuxième promesse. Examinez le fragment de code suivant :

var promise1 = someOperationAsync();
var promise2 = promise1.then(function completedHandler1 (result1) { return 7103; } );
promise2.then(function completedHandler2 (result2) { });

Ici, la chaîne d'exécution consiste à démarrer someOperationAsync, qui renvoie promise1. Pendant que cette opération est en cours, nous appelons promise1.then, qui renvoie immédiatement promise2. Il va sans dire que la méthode completedHandler1 n'est pas appelée, sauf si le résultat de l'opération asynchrone est déjà disponible. Supposons que nous attendons encore le résultat. Dans ce cas, nous appelons directement promise2.then et une là encore, la méthode completedHandler2 n'est pas appelée pour le moment.

Supposons que par la suite, la méthode someOperationAsync renvoie la valeur 14618. La promesse promise1 est alors réalisée, et elle appelle donc completedHandler1 en utilisant cette valeur. result1 a donc la valeur 14618. completedHandler1 s'exécute alors et renvoie la valeur 7103. À ce stade, la promesse promise2 est réalisée, ce qui provoque l'appel de completedHandler2 avec 7103 comme valeur result2.

Que se passe-t-il si un gestionnaire Terminé renvoie une autre promesse ? La situation est alors gérée de façon quelque peu différente. Supposons que la méthode completedHandler1 du code ci-dessus renvoie une promesse comme celle-ci :

var promise2 = promise1.then(function completedHandler1 (result1) {
    var promise2a = anotherOperationAsync();
    return promise2a;
});

Dans ce cas, la valeur result2 de completedHandler2 ne correspond pas directement à promise2a, mais à la valeur fulfillment de promise2a. En effet, le gestionnaire Terminé renvoie une promesse, promise2, telle qu'elle est renvoyée par promise1.then, qui elle-même est réalisée en utilisant le résultat de promise2a.

C'est précisément cette caractéristique qui rend possible la création de chaînes d'opération séquentielles asynchrones, dans lesquelles le résultat de chaque opération de la chaîne est transmis à l'opération suivante. Dépourvues de variables intermédiaires et de gestionnaires nommés, les chaînes de promesses ressemblent souvent à ce modèle :

operation1().then(function (result1) {
    return operation2(result1)
}).then(function (result2) {
    return operation3(result2);
}).then(function (result3) {
    return operation4(result3);
}).then(function (result4) {
    return operation5(result4)
}).then(function (result5) {
    //And so on
});

Bien évidemment, chaque gestionnaire Terminé réalise en général d'autres opérations à partir du résultat reçu, mais cette structure de base reste commune à toutes les chaînes. Par ailleurs, toutes les méthodes then s'exécutent ici l'une après l'autre, car leur seule fonction consiste à enregistrer un gestionnaire Terminé spécifique et à renvoyer une autre promesse. Ainsi, à la fin du code, seule l'opération operation1 a démarré et aucun gestionnaire Terminé n'a été appelé. En revanche, plusieurs promesses intermédiaires issues des appels de la méthode then ont été créées et reliées les unes aux autres, afin de gérer la chaîne à mesure que les opérations séquentielles se déroulent.

Il faut ici remarquer que la même séquence peut être exécutée en imbriquant chacune des opérations suivantes dans le gestionnaire Terminé précédent, auquel cas vous ne disposez pas d'instruction return. Cependant, ces imbrications peuvent conduire à un véritable casse-tête en termes de mise en retrait, en particulier si vous commencez à ajouter des gestionnaires de progression et d'erreurs à chaque appel de la méthode then.

D'ailleurs, les promesses de WinJS offrent notamment la fonctionnalité suivante : les erreurs qui ont lieu dans une partie de la chaîne sont automatiquement propagées en bout de chaîne. Par conséquent, vous pouvez en principe attacher un seul gestionnaire d'erreurs au dernier appel de la méthode then, au lieu de mettre en place des gestionnaires à chaque niveau. Cependant, pour différentes raisons assez subtiles, ces erreurs sont omises si le dernier lien de la chaîne est un appel de la méthode then. Pour cette raison, WinJS fournit également une méthode done pour les promesses. Cette méthode accepte les mêmes arguments que then, mais elle indique que la chaîne est terminée (elle renvoie la valeur undefined plutôt qu'une autre promesse). Un gestionnaire d'erreurs attaché à la méthode done est ensuite appelé pour gérer les erreurs de l'ensemble de la chaîne. En outre, en l'absence de gestionnaire d'erreurs, done émet une exception au niveau de l'application, où elle peut être gérée par les événements window.onerror de WinJS.Application.onerror. Pour simplifier, toutes les chaînes doivent idéalement se terminer par done pour faire en sorte que les exceptions apparaissent en surface et soient gérées correctement.

Bien évidemment, si vous écrivez une fonction dont le but est de renvoyer la dernière promesse d'une longue chaîne d'appels de la méthode then, vous utiliserez quand même then à la fin : la responsabilité du traitement des erreurs appartient ensuite à l'appelant, qui peut utiliser cette promesse dans une autre chaîne.

Création de promesses : la classe WinJS.Promise

Si vous pouvez dans tous les cas créer vos propres classes de promesses autour de la spécification Promises A, cela représente beaucoup de travail et il est préférable de faire appel à une bibliothèque. Pour cette raison, WinJS fournit une classe de promesses flexible, performante et rigoureusement testée, appelée WinJS.Promise. Elle vous permet de créer facilement des promesses autour de différentes valeurs et opérations, sans devoir gérer les détails de la relation initiateur/consommateur, ni le comportement de la méthode then.

Lorsque vous en avez besoin, vous pouvez (et vous avez d'ailleurs tout intérêt à le faire) utiliser new WinJS.Promise ou une fonction d'assistance adaptée pour créer des promesses autour des opérations asynchrones et des valeurs existantes (synchrones). N'oubliez pas qu'une promesse n'est ni plus ni moins qu'une construction de code : elle ne doit pas obligatoirement inclure une opération asynchrone, ni quoi que ce soit dans un wrapper. De même, le simple fait d'inclure un morceau de code dans un wrapper au sein d'une promesse ne rend pas pour autant son exécution asynchrone. C'est en effet à vous de réaliser ce travail.

Pour prendre un exemple d'utilisation simple et direct de WinJS.Promise, supposons que nous souhaitons réaliser un calcul long (ajouter différents nombres de 1 à une valeur maximale) de façon asynchrone. Nous pourrions inventer notre propre mécanisme de rappel pour une telle routine, mais si nous l'incluons dans un wrapper, nous pouvons le joindre aux promesses d'autres API ou l'assembler sous forme de chaîne à ces promesses. (À ce propos, la fonction WinJS.xhr inclut la demande asynchrone XmlHttpRequest de JavaScript dans un wrapper au sein d'une promesse, et vous n'avez donc pas à vous préoccuper de la structure d'événements spécifique de cette dernière.)

Nous pouvons évidemment utiliser un processus de travail JavaScript pour réaliser le calcul long, mais pour les besoins de notre illustration, nous allons le laisser sur le thread d'interface utilisateur et utiliser setImmediate pour diviser l'opération en plusieurs étapes. Voici comment implémenter cette méthode dans une structure de promesse en utilisant WinJS.Promise :

function calculateIntegerSum(max, step) {
    //The WinJS.Promise constructor's argument is an initializer function that receives 
    //dispatchers for completed, error, and progress cases.
    return new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
        var sum = 0;

        function iterate(args) {
            for (var i = args.start; i < args.end; i++) {
                sum += i;
            };

            if (i >= max) {
                //Complete--dispatch results to completed handlers
                completeDispatch(sum);
            } else {
                //Dispatch intermediate results to progress handlers
                progressDispatch(sum);
                setImmediate(iterate, { start: args.end, end: Math.min(args.end + step, max) });
            }
        }
            
        setImmediate(iterate, { start: 0, end: Math.min(step, max) });
    });
}

Lorsque la méthode new WinJS.Promise est appelée, le seul argument de son constructeur est une fonction initializer (qui est anonyme, dans notre cas). L'initialiseur encapsule l'opération à réaliser, mais sachez que la fonction elle-même s'exécute de façon synchrone sur le thread d'interface utilisateur. Par conséquent, si nous devions simplement réaliser un calcul long sans utiliser setImmediate, nous bloquerions intégralement le thread d'interface utilisateur à ce stade. Rappelons que le fait de placer du code dans une promesse ne le rend pas automatiquement asynchrone : la fonction de l'initialiseur doit configurer elle-même ce paramètre.

En termes d'arguments, la fonction d'initialiseur reçoit trois répartiteurs pour les différents cas pris en charge par les promesses (opération terminée, erreur et progression). Comme vous pouvez le constater, nous appelons ces répartiteurs à certains moments bien précis au cours de l'opération, en utilisant les arguments appropriés.

J'appelle ces fonctions des « répartiteurs », car ils ne jouent pas le même rôle que les gestionnaires que les consommateurs abonnent à la méthode then de la promesse (ou à la méthode done, comme vous le savez désormais). En arrière-plan, WinJS gère des tableaux de gestionnaires, ce qui permet à un nombre illimité de consommateurs de s'abonner à un nombre illimité de gestionnaires. Lorsque vous appelez l'un de ces répartiteurs, WinJS réalise une itération au sein de sa liste interne et appelle de votre part l'ensemble de ces gestionnaires. WinJS.Promise s'assure également que sa méthode then renvoie une autre promesse, car cela est requis pour former une chaîne.

Pour résumer, WinJS.Promise fournit l'ensemble des détails qui entourent une promesse. Vous pouvez ainsi vous concentrer sur l'opération centrale représentée par la promesse, qui prend la forme de la fonction d'initialiseur.

Fonctions d'assistance pour la création de promesses

La principale fonction d'assistance permettant de créer une promesse est la méthode statique WinJS.Promise.as, qui inclut dans un wrapper n'importe quelle valeur au sein d'une promesse. Un tel wrapper sur une valeur existante se retourne et appelle le gestionnaire Terminé transmis à la méthode then. Ceci vous permet plus précisément de traiter les valeurs arbitraires connues comme des promesses, que vous pouvez entremêler et mélanger (en les liant ou en les regroupant en chaîne) à d'autres promesses. En utilisant as sur une promesse existante, cette promesse est renvoyée.

L'autre fonction d'assistance statique est WinJS.Promise.timeout, qui fournit un wrapper très pratique autour de setTimeout et setImmediate. Vous pouvez également créer une promesse qui annule une seconde promesse si cette dernière n'est pas réalisée au bout d'un certain nombre de millisecondes.

Sachez que les promesses timeout qui entourent setTimeout et setImmediate sont elles-mêmes réalisées avec la valeur undefined. Une question revient souvent : « Comment ces promesses peuvent-elles être utilisées pour fournir un autre résultat une fois le délai expiré ? ». Pour trouver la réponse, rappelons que then renvoie une autre promesse qui est réalisée avec la valeur renvoyée par le gestionnaire Terminé. Prenons par exemple cette ligne de code :

var p = WinJS.Promise.timeout(1000).then(function () { return 12345; });

Elle crée la promesse p, qui sera réalisée avec la valeur 12345 au bout d'une seconde. En d'autres termes, WinJS.Promise.timeout(…).then(function () { return <valeur>} ) est un schéma qui permet de renvoyer <valeur> au bout du délai d'expiration donné. Si la valeur <valeur> est elle-même une autre promesse, l'opération revient alors à fournir la valeur de réalisation de cette promesse au bout d'un certain temps après l'expiration du délai.

Annulation et génération d'erreurs de promesse

Dans le code que nous venons d'examiner, vous avez peut-être remarqué trois problèmes. En premier lieu, il est impossible d'annuler l'opération une fois qu'elle a démarré. Deuxièmement, le traitement des erreurs n'est pas vraiment optimal.

Dans les deux cas, le problème est que les fonctions qui créent une promesse, par exemple calculateIntegerSum, doivent toujours renvoyer une promesse. Si une opération ne se termine pas ou n'est jamais démarrée, la promesse se retrouve à l'état d'erreur. Par conséquent, la promesse n'a pas de résultat à transmettre aux gestionnaires Terminé et n'en aura d'ailleurs jamais : elle appelle uniquement ses gestionnaires d'erreurs. En effet, si un consommateur appelle la méthode then pour une promesse qui se trouve déjà en état d'erreur, cette promesse appelle immédiatement (de façon synchrone) le gestionnaire d'erreurs indiqué à la méthode then.

Une promesse WinJS.Promise peut entrer dans un état d'erreur pour deux raisons : si le consommateur appelle sa méthode cancel ou si le code de la fonction d'initialiseur appelle le répartiteur d'erreurs. Lorsque cela se produit, les gestionnaires d'erreurs reçoivent la valeur d'erreur interceptée ou propagée dans la promesse. Si vous créez une opération dans une promesse WinJS.Promise, vous pouvez également utiliser une instance de WinJS.ErrorFromName. Il s'agit simplement d'un objet JavaScript contenant une propriété name qui identifie l'erreur et une propriété message offrant plus de détails. Par exemple, lorsqu'une promesse est annulée, les gestionnaires d'erreurs reçoivent un objet d'erreur dont les propriétés name et message portent la valeur « Canceled ».

Mais que faire si vous ne pouvez même pas démarrer l'opération ? Par exemple, si vous appelez la méthode calculateIntegerSum en utilisant des arguments incorrects (0, 0, par exemple), en principe elle n'essaie même pas de lancer le décompte et renvoie une promesse dans un état d'erreur. C'est le but de la méthode statique WinJS.Promise.wrapError. Elle accepte comme paramètre une instance de WinJS.ErrorFromName et renvoie une promesse dans un état d'erreur, qui dans ce cas est renvoyée en lieu et place d'une nouvelle instance WinJS.Promise.

Autre partie importante, bien qu'un appel de la méthode cancel de la promesse met la promesse elle-même dans un état d'erreur, comment faire pour arrêter l'opération asynchrone en cours ? Dans l'implémentation précédente de calculateIntegerSum, la méthode setImmediate est appelée de façon répétée jusqu'à ce que l'opération soit terminée, quel que soit l'état de la promesse que nous avons créée. En effet, si l'opération appelle le répartiteur Terminé après l'annulation de la promesse, cette dernière ignore que l'opération est terminée.

Ensuite, nous devons faire en sorte que la promesse signale à l'opération qu'elle n'a plus besoin de poursuivre son travail. Pour cette raison, le constructeur WinJS.Promise accepte un deuxième argument de fonction, qui est appelé en cas d'annulation de la promesse. Dans notre exemple, l'appel de cette fonction doit pouvoir empêcher l'appel suivant de la méthode setImmediate, pour arrêter ainsi le calcul. Voici à quoi ressemble le code une fois que la gestion des erreurs a été améliorée :

function calculateIntegerSum(max, step) {
    //Return a promise in the error state for bad arguments
    if (max < 1 || step < 1) {
        var err = new WinJS.ErrorFromName("calculateIntegerSum", "max and step must be 1 or greater");
        return WinJS.Promise.wrapError(err);
    }

    var _cancel = false;

    //The WinJS.Promise constructor's argument is an initializer function that receives 
    //dispatchers for completed, error, and progress cases.
    return new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
        var sum = 0;

        function iterate(args) {
            for (var i = args.start; i < args.end; i++) {
                sum += i;
            };

            //If for some reason there was an error, create the error with WinJS.ErrorFromName
            //and pass to errorDispatch
            if (false /* replace with any necessary error check -- we don’t have any here */) {
                errorDispatch(new WinJS.ErrorFromName("calculateIntegerSum (scenario 7)", "error occurred"));
            }

            if (i >= max) {
                //Complete--dispatch results to completed handlers
                completeDispatch(sum); 
            } else {
                //Dispatch intermediate results to progress handlers
                progressDispatch(sum);

                //Interrupt the operation if canceled
                if (!_cancel) {
                    setImmediate(iterate, { start: args.end, end: Math.min(args.end + step, max) });
                }
            }
        }
            
        setImmediate(iterate, { start: 0, end: Math.min(step, max) });
    },
    //Cancellation function for the WinJS.Promise constructor
    function () {
        _cancel = true;
    });
}

Au final, le fait de créer plusieurs instances de WinJS.Promise permet plusieurs usages. Par exemple, si vous disposez d'une bibliothèque qui communique avec un service Web par le biais d'une autre méthode asynchrone, vous pouvez inclure ces opérations dans un wrapper au sein des promesses. Vous pouvez également utiliser une nouvelle promesse pour combiner dans une seule promesse plusieurs opérations asynchrones (ou d'autres promesses) issues de différentes sources, afin de contrôler toutes les relations concernées. Dans le code d'un initialiseur de WinJS.Promise, vous pouvez évidemment intégrer vos propres gestionnaires pour d'autres opérations asynchrones et leurs promesses. Ces gestionnaires peuvent être utilisés pour encapsuler des mécanismes de relance automatique en cas d'expiration des délais réseau, par exemple, pour se raccorder à une interface générique de progression de mise à jour ou encore pour ajouter des fonctionnalités d'arrière-plan de journalisation ou d'analyse d'audience. Dans tous ces cas, le reste de votre code n'a jamais besoin de connaître les détails et peut simplement traiter les promesses du côté consommateur.

Dans le même esprit, il est relativement simple d'inclure un processus de travail JavaScript dans un wrapper au sein d'une promesse, pour qu'il ressemble à d'autres opérations asynchrones dans WinRT et qu'il se comporte de la même manière. Comme vous le savez peut-être, les processus de travail envoient leurs résultats par le biais d'un appel postMessage qui émet un événement message sur l'objet du processus de travail de l'application. Le code suivant relie ensuite cet événement à une promesse réalisée avec les résultats qui sont fournis dans le message :

// This is the function variable we're wiring up.
var workerCompleteDispatch = null;

var promiseJS = new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
    workerCompleteDispatch = completeDispatch;
});

// Worker is created here and stored in the 'worker' variable

// Listen for worker events
worker.onmessage = function (e) {
    if (workerCompleteDispatch != null) {
        workerCompleteDispatch(e.data.results); /* event args depends on the worker */
    }
}

promiseJS.done(function (result) {
    // Output for JS worker
});

Pour élargir ce code en vue de gérer les erreurs issues du processus de travail, vous devez enregistrer le répartiteur d'erreurs dans une autre variable, faire en sorte que le gestionnaire d'événements message vérifie les informations d'erreur dans ses arguments d'événement, puis appeler le répartiteur d'erreurs en lieu et place du répartiteur Terminé.

Joindre des promesses parallèles

Comme les promesses sont souvent utilisées pour inclure des opérations asynchrones dans un wrapper, il est tout à fait possible que plusieurs opérations soient en cours au même moment. Dans ce cas, il peut être utile de savoir à quel moment l'une des promesses d'un groupe est réalisée ou à quel moment toutes les promesses du groupe sont réalisées. Les fonctions statiques WinJS.Promise.any et WinJS.Promise.join sont justement là pour ça.

Les deux fonctions acceptent un tableau de valeurs ou un objet comportant des propriétés de valeur. Ces valeurs peuvent être des promesses, et les éventuelles valeurs qui ne sont pas des promesses sont incluses dans un wrapper avec WinJS.Promise.as, de telle sorte que l'intégralité du tableau ou de l'objet se compose de promesses.

Voici les caractéristiques de la méthode any :

• any crée une seule promesse qui est réalisée lorsque l'une de ses promesses est réalisée ou échoue en raison d'une erreur (OU logique). En substance, any rattache les gestionnaires Terminé à toutes ces promesses et dès qu'un gestionnaire Terminé est appelé, il appelle les gestionnaires Terminé que la promesse any a elle-même reçu.
• Une fois que la promesse any est réalisée (c'est-à-dire lorsque la première promesse de la liste est réalisée), les autres opérations de la liste sont exécutées, en appelant les gestionnaires Terminé, les gestionnaires d'erreur ou les gestionnaires de progression affectés individuellement aux différentes promesses.
• Si vous annulez la promesse à partir de any, toutes les promesses de la liste sont annulées.

En ce qui concerne join :

• join crée une seule promesse qui est réalisée lorsque toutes ses promesses sont réalisées ou échouent en raison d'une erreur (ET logique). En substance, join rattache les gestionnaires Terminé et les gestionnaires d'erreurs à toutes ces promesses, et attend que tous ces gestionnaires aient été appelés, avant d'appeler les gestionnaires Terminé qu'elle a elle-même reçu.
• La promesse join signale également sa progression aux éventuels gestionnaires de progression que vous fournissez. Dans ce cas, le résultat intermédiaire est un tableau de résultats issus des promesses individuelles réalisées jusque là.
• Si vous annulez la promesse à partir de join, toutes les promesses en attente sont annulées.

En dehors de any et join, il existe deux autres méthodes statiques WinJS.Promise à connaître, car elles peuvent s'avérer pratiques :

• is détermine si une valeur arbitraire est une promesse et renvoie une valeur booléenne. Pour simplifier, elle vérifie qu'il s'agit d'un objet comportant une fonction appelée « then » et ne teste pas « done ».
• theneach applique des gestionnaires Terminé, des gestionnaires d'erreurs et des gestionnaires de progression à un groupe de promesses (en utilisant then) et renvoie les résultats sous forme d'un groupe de valeurs au sein d'une promesse. La valeur des gestionnaires peut être null.

Promesses parallèles avec résultats séquentiels

Avec WinJS.Promise.join et WinJS.Promise.any, nous pouvons travailler avec des promesses parallèles, c'est-à-dire avec des opérations parallèles asynchrones. La promesse renvoyée par join est là encore réalisée lorsque toutes les promesses d'un tableau sont réalisées. Cependant, il est fort probable que ces promesses se réalisent dans un ordre aléatoire. Comment faire si vous disposez d'un ensemble d'opérations qui peuvent s'exécuter de cette manière, mais que vous souhaitez traiter leurs résultats dans un ordre bien défini, c'est-à-dire dans l'ordre dans lequel leurs promesses apparaissent dans le tableau ?

Pour parvenir au but escompté, vous devez joindre chaque promesse suivante à la méthode join de toutes les méthodes précédentes. Le petit extrait de code qui figure au début de ce billet réalise précisément cette opération. Voici de nouveau le code, légèrement réécrit pour rendre les promesses plus explicites. (Supposez que list est un tableau de valeurs utilisées comme arguments d'un appel asynchrone doOperationAsync susceptible de générer une promesse) :

list.reduce(function callback (prev, item, i) {
    var opPromise = doOperationAsync(item);
    var join = WinJS.Promise.join({ prev: prev, result: opPromise});

    return join.then(function completed (v) {
        console.log(i + ", item: " + item+ ", " + v.result);
    });
})

Pour comprendre ce code, nous devons tout d'abord comprendre comment fonctionne la méthode reduce du tableau. Pour chaque élément du tableau, reduce appelle l'argument de fonction ici appelé callback, qui reçoit quatre arguments (seuls trois d'entre eux sont utilisés dans le code) :

• prev Valeur renvoyée par l'appel précédent de callback (valeur null pour le premier élément).
• item Valeur actuelle issue du tableau.
• i Index de l'élément dans la liste.
• source Tableau d'origine.

Pour le premier élément de la liste, nous obtenons une promesse que j'appellerai opPromise₁. Comme la valeur de prev est null, nous joignons [WinJS.Promise.as(null), opPromise₁]. Remarquez cependant que nous ne renvoyons pas la méthode join elle-même. En lieu et place, nous attachons un gestionnaire Terminé (que j'ai appelé completed) à cette méthode join et renvoyons la promesse de sa méthode then.

N'oubliez pas que la promesse renvoyée par then sera réalisée lorsque le gestionnaire Terminé renverra une valeur. Par conséquent, nous renvoyons à partir de callback une promesse qui n'est pas réalisée tant que le gestionnaire completed du premier élément n'a pas traité les résultats de opPromise₁. Si vous regardez le résultat d'une méthode join, elle est réalisée au moyen d'un objet contenant les résultats issus des promesses de la liste d'origine. Par conséquent, la valeur de réalisation v contiendra à la fois une propriété prev et une propriété result, la valeur de cette dernière correspondant au résultat de opPromise₁.

Avec l'élément suivant de list, callback reçoit une propriété prev qui contient la promesse issue de la méthode join.then précédente. Nous créons ensuite une nouvelle jointure de opPromise₁.then et opPromise₂. Par conséquent, cette jointure ne se termine pas tant que opPromise₂ n'a pas été réalisée et que le gestionnaire Terminé de opPromise₁ n'a pas renvoyé de valeur. Et voilà ! Le gestionnaire completed₂ que nous attachons à cette méthode join n'est pas appelé tant que completed₁ n'a pas renvoyé de valeur.

Les mêmes dépendances sont progressivement construites pour chaque élément de la liste. La promesse issue de join.then pour l'élément n n'est pas réalisée tant que completed_n ne renvoie pas de valeur. Ainsi, les gestionnaires Terminé sont forcément appelés dans le même ordre que list.

Pour conclure

Dans ce billet, nous avons constaté qu'une promesse n'est en substance qu'une construction de code ou une convention d'appel (quoique très puissante), qui permet de représenter une relation spécifique entre un initiateur, qui doit fournir des valeurs à une heure ultérieure arbitraire, et un consommateur, qui souhaite savoir quand ces valeurs sont disponibles. Ainsi, les promesses sont idéales pour représenter des résultats issus d'opérations asynchrones. Elles sont très souvent utilisées dans les applications du Windows Store écrites en JavaScript. La spécification des promesses permet également la création de chaînes d'opérations séquentielles asynchrones, chaque résultat intermédiaire passant d'un lien à un autre.

WinJS, la Bibliothèque Windows pour JavaScript, fournit une implémentation fiable des promesses, que vous pouvez utiliser pour inclure dans un wrapper n'importe quel type d'opération de votre choix. Elle fournit également des fonctions d'assistance pour certains scénarios courants, par exemple pour regrouper des promesses dans le cadre d'opérations parallèles. Grâce aux avantages de WinJS, vous pouvez travailler de façon très efficace avec des opérations asynchrones.

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

Pour de nombreuses applications du Windows Store écrites en JavaScript qui utilisent les collections, une coopération appropriée avec le contrôle ListView WinJS est essentielle pour optimiser leurs performances. Ceci n'est pas surprenant : lorsque vous devez gérer et afficher des milliers d'éléments potentiels, toutes les optimisations que vous réalisez sur ces éléments font la différence. Ce qui compte le plus, c'est la manière dont chacun de ces éléments est rendu, c'est-à-dire comment (et quand) chaque élément du contrôle ListView est élaboré dans le DOM et apparaît dans l'application. En effet, la composante quand de cette équation devient un facteur critique lorsqu'un utilisateur se déplace rapidement dans une liste et s'attend à ce que cette liste soutienne le rythme qu'il lui impose.

Le rendu des éléments dans un contrôle ListView se produit via un modèle déclaratif défini en HTML ou via une fonction de rendu JavaScript personnalisée qui est appelée pour chaque élément de la liste. Même si l'utilisation d'un modèle déclaratif est la méthode la plus simple, elle ne confère pas une latitude très importante pour contrôler précisément le processus. Une fonction de rendu, d'un autre côté, vous permet de personnaliser le rendu élément par élément et de mettre en œuvre différentes optimisations qui sont illustrées dans l'exemple d'optimisation des performances de contrôle HTML ListView. Ces optimisations sont les suivantes :

• Autoriser la distribution asynchrone des données des éléments et d'un élément rendu. Ceci est pris en charge par les fonctions de rendu élémentaires.
• Séparer la création de la forme d'un élément, qui est nécessaire à la disposition globale du contrôle ListView, de ses éléments internes. Ceci est pris en charge via un convertisseur d'espace réservé.
• Réutiliser un élément créé au préalable (et ses enfants) en remplaçant ses données, ce qui évite la plupart des étapes de création d'un élément. Ceci est possible via un convertisseur d'espace réservé de recyclage.
• Reporter les opérations visuelles intensives, telles que le chargement d'images et les animations, jusqu'à ce qu'un élément soit visible et tant que le contrôle ListView n'est pas déplacé rapidement. Ceci s'effectue via un convertisseur à plusieurs phases.
• Traiter par lot les opérations visuelles identiques afin de limiter la répétition des rendus du DOM avec un convertisseur par lot à plusieurs phases.

Dans ce billet, nous allons examiner toutes ces étapes et voir comment elles coopèrent avec le processus de rendu des éléments du contrôle ListView. Comme vous pouvez l'imaginer, les optimisations qui entourent le moment où les éléments sont rendus entraînent un grand nombre d'opérations asynchrones et véhiculent par conséquent beaucoup de promesses. Au cours du processus, nous allons également acquérir une connaissance plus approfondie des promesses, en nous appuyant sur le billet précédent Tout sur les promesses de ce blog.

De manière générale pour tous les convertisseurs, il est important de toujours ramener au minimum le temps de rendu des principaux éléments (sans compter les opérations reportées). Comme les performances finales du contrôle ListView dépendent de beaucoup du bon alignement de ses mises à jour sur les intervalles d'actualisation de l'écran, quelques millisecondes supplémentaires dans un convertisseur d'élément peut faire dépasser le temps de rendu global du contrôle ListView sur le prochain intervalle d'actualisation, entraînant la suppression d'images et des irrégularités visuelles. En d'autres termes, il est réellement très important d'optimiser votre code JavaScript dans les convertisseurs d'éléments.

Convertisseurs élémentaires

Commençons par passer rapidement en revue la fonction de rendu des éléments (que je vais simplement appeler convertisseur. Un convertisseur est une fonction que vous attribuez à la propriété itemTemplate du contrôle ListView à la place d'un nom de modèle. Cette fonction est appelée, lorsque cela est nécessaire, pour les éléments que le contrôle ListView souhaite inclure dans le DOM. (Vous trouverez une documentation élémentaire sur les convertisseurs à la page itemTemplate, mais l'exemple illustre mieux les optimisations.)

Vous pouvez penser qu'une fonction de rendu des éléments reçoit simplement un élément de la source de données du contrôle ListView. Qu'elle crée ensuite les composants HTML nécessaires à cet élément en particulier et renvoie le composant racine que le contrôle ListView peut ajouter au DOM. C'est essentiellement ce qui se passe, mais vous devez prendre en considération deux points complémentaires. D'abord, comme les données de l'élément même peuvent être chargées de manière asynchrone, il est logique de lier la création des composants à la disponibilité de ces données. Ensuite, le processus de rendu de l'élément même peut entraîner d'autres tâches asynchrones, telles que le chargement d'images à partir d'URI à distance ou la lecture de données dans d'autres fichiers identifiés dans les données de l'élément. Les différents niveaux d'optimisation que nous allons voir, en fait, peuvent donner lieu à un nombre arbitraire de tâches asynchrones entre la demande des composants de l'élément et la distribution effective de ces composants.

Ici encore, vous pouvez donc vous attendre à voir apparaître des promesses ! D'abord, le contrôle ListView ne communique pas simplement les données de l'élément au convertisseur directement ; il fournit une promesse concernant ces données. Et la fonction ne renvoie pas directement le composant racine de l'élément ; elle renvoie une promesse concernant ce composant. Ceci permet au contrôle ListView d'associer plusieurs promesses de rendu d'éléments et d'attendre (en mode asynchrone) qu'une page entière d'éléments soit rendue. En fait, il procède ainsi pour gérer intelligemment l'élaboration de différentes pages, en créant d'abord la page des éléments visibles, puis deux pages hors écran avant et après (les deux pages que les utilisateurs ont le plus de chances de consulter ensuite). En outre, la mise en place de toutes ces promesses signifie que le contrôle ListView peut facilement annuler le rendu des éléments non terminés si l'utilisateur s'éloigne, ce qui évite de créer inutilement des composants.

Nous pouvons voir comment ces promesses sont utilisées dans la fonction simpleRenderer de l'exemple :

function simpleRenderer(itemPromise) {
    return itemPromise.then(function (item) {
        var element = document.createElement("div");
        element.className = "itemTempl";
        element.innerHTML = "<img src='" + item.data.thumbnail +
            "' alt='Databound image' /><div class='content'>" + item.data.title + "</div>";
        return element;
    });
}

Ce code associe d'abord un gestionnaire Terminé à itemPromise. Le gestionnaire est appelé lorsque les données de l'élément sont disponibles et répond en créant les composants. Mais remarquez à nouveau que nous ne renvoyons pas l'élément directement : nous renvoyons une promesse qui est réalisée avec ce composant. En d'autres termes, la valeur renvoyée par itemPromise.then() est une promesse qui est réalisée avec element si et quand le contrôle ListView en a besoin.

Le renvoi d'une promesse nous permet d'effectuer d'autres tâches de synchronisation si nécessaire. Dans ce cas, le convertisseur peut simplement relier ces promesses intermédiaires et renvoyer la promesse issue du dernier appel de la méthode then dans la chaîne. Par exemple :

function someRenderer(itemPromise) {
    return itemPromise.then(function (item) {
        return doSomeWorkAsync(item.data);
    }).then(function (results) {
        return doMoreWorkAsync(results1);
    }).then(function (results2) {
        var element = document.createElement("div");
        // use results2 to configure the element
        return element;
    });
}

Notez que dans ce cas, nous n'utilisons pas done à la fin de la chaîne, car nous renvoyons la promesse issue du dernier appel de la méthode then. Le contrôle ListView est chargé de la gestion des erreurs susceptibles de survenir.

Convertisseurs d'espaces réservés

La prochaine étape d'optimisation ListView utilise un convertisseur d'espace réservé qui décompose la création du composant en deux phases. Cela permet au contrôle ListView de demander uniquement les parties d'un composant qui sont nécessaires pour définir la disposition globale de la liste, sans créer tous les composants à l'intérieur de chaque élément. Le contrôle ListView peut ainsi s'acquitter de sa passe de disposition rapidement tout en demeurant hautement réactif aux saisies. Il peut ensuite demander le reste du composant plus tard.

Un convertisseur d'espace réservé renvoie un objet avec deux propriétés au lieu d'une simple promesse :

• element Composant de niveau supérieur dans la structure de l'élément qui permet de définir sa taille et sa forme et ne dépend pas des données de l'élément.
• renderComplete Promesse qui est réalisée lorsque le reste du contenu du composant est créé. En d'autres termes, cette propriété renvoie la promesse à partir de la chaîne que vous avez démarrée avec itemPromise.then comme dans l'exemple précédent.

Le contrôle ListView est suffisamment intelligent pour savoir si votre convertisseur renvoie une promesse (cas élémentaire de l'exemple précédent) ou un objet avec les propriétés element et renderComplete (cas plus avancés). Ainsi, le convertisseur d'espace réservé équivalent (dans l'exemple) pour la fonction simpleRenderer précédente ressemble à ceci :

function placeholderRenderer(itemPromise) {
    // create a basic template for the item that doesn't depend on the data
    var element = document.createElement("div");
    element.className = "itemTempl";
    element.innerHTML = "<div class='content'>...</div>";

    // return the element as the placeholder, and a callback to update it when data is available
    return {
        element: element,

        // specifies a promise that will be completed when rendering is complete
        // itemPromise will complete when the data is available
        renderComplete: itemPromise.then(function (item) {
            // mutate the element to include the data
            element.querySelector(".content").innerText = item.data.title;
            element.insertAdjacentHTML("afterBegin", "<img src='" +
                item.data.thumbnail + "' alt='Databound image' />");
        })
    };
}

Notez que l'affectation element.innerHTML peut être déplacée à l'intérieur de renderComplete, car la classe itemTempl dans le fichier css/scenario1.css de l'exemple stipule directement la largeur et la hauteur de l'élément. L'affectation est incluse dans la propriété element, car elle fournit le texte « … » par défaut dans l'espace réservé. Il serait également possible d'utiliser un composant img se rapportant à une petite ressource dans le package qui est partagée dans tous les éléments (et dont le rendu est par conséquent rapide).

Convertisseurs d'espaces réservés de recyclage

La prochaine optimisation, le convertisseur d'espace réservé de recyclage, n'apporte aucune nouveauté sur le front des promesses. Elle met en revanche l'accent sur un deuxième paramètre du convertisseur, nommé recycled. Il s'agit du composant racine d'un élément qui a déjà été rendu mais qui n'est plus visible. Ainsi, les composants enfants du composant « recycled » (recyclé) sont déjà en place et vous pouvez simplement remplacer les données et même transformer certains de ces composants. Ceci évite la plupart des coûteux appels de création de composants qui sont nécessaires pour créer un élément entièrement nouveau et permet d'accélérer le processus de rendu.

Le contrôle ListView peut fournir un composant « recycled » lorsque sa propriété loadingBehavior est définie sur « randomaccess ». Si le composant recycled est stipulé, vous pouvez simplement supprimer les données du composant (et ses enfants), le renvoyer comme espace réservé, puis indiquer d'autres données et créer des enfants supplémentaires (le cas échéant) dans renderComplete. Si aucun composant « recycled » n'est fourni (par exemple si le contrôle ListView est créé en premier ou si loadingBehavior est « incrémentiel »), vous devez créer entièrement le composant. Voici le code de l'exemple correspondant à cette variante :

function recyclingPlaceholderRenderer(itemPromise, recycled) {
    var element, img, label;
    if (!recycled) {
        // create a basic template for the item that doesn't depend on the data
        element = document.createElement("div");
        element.className = "itemTempl";
        element.innerHTML = "<img alt='Databound image' style='visibility:hidden;'/>" +
            "<div class='content'>...</div>";
    }
    else {
        // clean up the recycled element so that we can reuse it 
        element = recycled;
        label = element.querySelector(".content");
        label.innerHTML = "...";
        img = element.querySelector("img");
        img.style.visibility = "hidden";
    }
    return {
        element: element,
        renderComplete: itemPromise.then(function (item) {
            // mutate the element to include the data
            if (!label) {
                label = element.querySelector(".content");
                img = element.querySelector("img");
            }
            label.innerText = item.data.title;
            img.src = item.data.thumbnail;
            img.style.visibility = "visible";
        })
    };
}

Dans renderComplete, veillez à vérifier l'existence des composants que vous ne créez pas pour un nouvel espace réservé (par exemple label) et créez-les si cela est nécessaire.

Si vous souhaitez supprimer les éléments recyclés de manière plus générale, notez que vous pouvez attribuer une fonction à la propriété resetItem du contrôle ListView. Le code de cette fonction serait alors similaire à celui présenté ci-dessus. Il en va de même pour la propriété resetGroupHeader, car vous pouvez utiliser les fonctions de modèles pour les en-têtes de groupes comme pour les éléments. Nous en avons peu parlé, car les en-têtes de groupes sont beaucoup moins nombreux et les implications en termes de performances ne sont généralement pas les mêmes. La fonctionnalité existe néanmoins.

Convertisseurs à plusieurs phases

Tout ceci nous amène à l'avant-dernière optimisation, le convertisseur à plusieurs phases. Il prolonge le convertisseur d'espace réservé de recyclage aux images et autres données multimédias à chargement différé tant que le reste de l'élément n'est pas entièrement présent dans le DOM. Il retarde également des effets, tels que les animations, tant que l'élément n'est pas réellement à l'écran. Les utilisateurs se déplaçant souvent très rapidement au sein du contrôle ListView, il est logique de reporter de manière asynchrone les opérations les plus exigeantes jusqu'à ce que le contrôle parvienne à une position stable.

Le contrôle ListView offre les points de raccordement nécessaires lorsque les membres de item sont issus de itemPromise : une propriété nommée ready (une promesse) et deux méthodes, loadImage et isOnScreen, toutes les deux renvoyant plus de promesses. C'est-à-dire :

renderComplete: itemPromise.then(function (item) {
    // item.ready, item.loadImage, and item.isOnScreen available
})

Voici comment les utiliser :

• ready Renvoie cette promesse à partir du premier gestionnaire Terminé de votre chaîne. Cette promesse est réalisée lorsque l'intégralité de la structure du composant a été rendue et est visible. Cela signifie que vous pouvez associer une autre méthode then à un gestionnaire Terminé dans lequel vous effectuez d'autres tâches postérieures à la visibilité, par exemple le chargement d'images.
• loadImage Télécharge une image à partir d'un URI et l'affiche dans le composant img donné, ce qui renvoie une promesse qui est réalisée avec ce même composant. Vous joignez un gestionnaire Terminé à cette promesse, qui renvoie à son tour la promesse depuis isOnScreen. Notez que loadImage crée un composant img si aucun n'est fourni et le distribue à votre gestionnaire Terminé.
• isOnScreen Renvoie une promesse dont la valeur de réalisation est une valeur booléenne qui indique si le composant est visible ou non. Dans les implémentations actuelles, il s'agit d'une valeur connue et la promesse est donc réalisée de manière synchrone. En l'incluant dans une promesse, cependant, elle peut être utilisée dans une chaîne plus longue.

Tout cela est illustré dans la fonction multistageRenderer de l'exemple, où la fin du chargement de l'image déclenche l'apparition en fondu d'une animation. Voici simplement ce qui est renvoyé par la promesse renderComplete :

renderComplete: itemPromise.then(function (item) {
    // mutate the element to update only the title
    if (!label) { label = element.querySelector(".content"); }
    label.innerText = item.data.title;

    // use the item.ready promise to delay the more expensive work
    return item.ready;
    // use the ability to chain promises, to enable work to be cancelled
}).then(function (item) {
    // use the image loader to queue the loading of the image
    if (!img) { img = element.querySelector("img"); }
    return item.loadImage(item.data.thumbnail, img).then(function () {
        // once loaded check if the item is visible
        return item.isOnScreen();
    });
}).then(function (onscreen) {
    if (!onscreen) {
        // if the item is not visible, don't animate its opacity
        img.style.opacity = 1;
    } else {
        // if the item is visible, animate the opacity of the image
        WinJS.UI.Animation.fadeIn(img);
    }
})

Même si un grand nombre d'opérations se déroulent, cette chaîne de promesses demeure élémentaire. La première opération asynchrone du convertisseur actualise les parties simples de la structure des composants de l'élément, par exemple le texte. Elle renvoie ensuite la promesse dans item.ready. Une fois cette promesse réalisée (ou, plus précisément, si cette promesse est réalisée), nous utilisons la méthode asynchrone loadImage de l'élément pour déclencher le téléchargement d'une image, ce qui renvoie la promesse item.isOnScreen depuis ce gestionnaire Terminé. Cela signifie que l'indicateur de visibilité onscreen est transmis au gestionnaire Terminé final de la chaîne. Lorsque (et si) cette promesse isOnScreen est réalisée (ce qui signifie que l'élément est réellement visible), nous pouvons effectuer les opérations appropriées, telles que des animations.

Je tiens à souligner le caractère hypothétique (avec le terme « si »), car il est à nouveau probable que l'utilisateur se déplace au sein du contrôle ListView pendant le déroulement de toutes ces opérations. L'enchaînement de toutes ces promesses permet au contrôle ListView d'annuler les opérations asynchrones lorsque ces éléments sont déplacés hors de l'écran et/ou hors des pages mises en mémoire tampon. Qu'il suffise de dire que le contrôle ListView a subi à un grand nombre de tests de performances !

Il est également important de se rappeler que nous utilisons la méthode then dans toutes ces chaînes, car nous renvoyons toujours une promesse depuis la fonction de rendu au sein de la propriété renderComplete. Nous ne sommes jamais à la fin de la chaîne dans ces convertisseurs et nous n'utiliserons donc jamais done à la fin.

Traitement de miniatures par lot

La dernière optimisation constitue sans aucun doute le coup de grâce pour le contrôle ListView. Dans la fonction nommée batchRenderer, nous trouvons cette structure pour renderComplete (la plupart du code est omis) :

renderComplete: itemPromise.then(function (item) {
    // mutate the element to update only the title
    if (!label) { label = element.querySelector(".content"); }
    label.innerText = item.data.title;

    // use the item.ready promise to delay the more expensive work
    return item.ready;
    // use the ability to chain promises, to enable work to be cancelled
}).then(function (item) {
    // use the image loader to queue the loading of the image
    if (!img) { img = element.querySelector("img"); }
    return item.loadImage(item.data.thumbnail, img).then(function () {
        // once loaded check if the item is visible
        return item.isOnScreen();
    });
}).then(function (onscreen) {
    if (!onscreen) {
        // if the item is not visible, don't animate its opacity
        img.style.opacity = 1;
    } else {
        // if the item is visible, animate the opacity of the image
        WinJS.UI.Animation.fadeIn(img);
    }
})

Cela ressemble beaucoup à la fonction multistageRenderer, à l'exception de l'insertion de cet appel mystérieux destiné à la fonction thumbnailBatch entre l'appel item.loadImage et la vérification item.isOnScreen. La position de thumbnailBatch dans la chaîne indique que la valeur renvoyée doit être un gestionnaire Terminé qui renvoie lui-même une autre promesse.

Ce n'est pas très clair ? Nous y reviendrons en détail ! Mais d'abord, nous avons besoin d'informations complémentaires sur ce que nous tentons d'accomplir.

Si nous n'avions qu'un contrôle ListView avec un seul élément, les différentes optimisations de chargement ne seraient pas significatives. Mais le contrôle ListView comporte généralement de nombreux éléments et la fonction de rendu est appelée pour chacun d'entre eux. Dans la fonction multistageRenderer de la section précédente, le rendu de chaque élément déclenche une opération item.loadImage asynchrone qui télécharge sa miniature à partir d'un URI arbitraire. La durée de chaque opération peut être arbitraire. Ainsi, pour toute la liste, plusieurs appels loadImage peuvent se dérouler simultanément, avec le rendu de chaque élément attendant la fin de sa miniature en particulier. Jusque là, tout va bien.

Une des caractéristiques importantes qui n'est pas du tout visible dans la fonction multistageRenderer, cependant, est que le composant img de la miniature est déjà présent dans le DOM et que la fonction loadImage définit l'attribut src de cette image dès la fin du téléchargement. Ceci déclenche à son tour une mise à jour dans le moteur de rendu dès que nous revenons du reste de la chaîne de promesses, qui est essentiellement synchrone au-delà de ce point.

Il est alors possible que certaines des miniatures réintègrent rapidement le thread d'interface utilisateur. Ceci entraînera une trop grande évolution dans le moteur de rendu et des performances visuelles médiocres. Pour éviter cette situation, nous voulons créer entièrement ces composants img avant qu'ils ne soient dans le DOM, puis les ajouter par lots afin qu''ils soient tous gérés au cours d'une passe de rendu unique.

L'exemple effectue ces opérations à l'aide de la fonction createBatch. La fonction createBatch est appelée une seule fois pour toute l'application et son résultat (une autre fonction) est stocké dans la variable nommée thumbnailBatch:

var thumbnailBatch;
thumbnailBatch = createBatch();

Un appel à cette fonction thumbnailBatch, comme je vais désormais la désigner, est à nouveau inséré dans la chaîne de promesses du convertisseur. L'objectif de cette insertion, étant donné la nature du code de traitement par lot que nous examinerons plus loin, est de regrouper un ensemble de composants img chargés, en les libérant pour d'autres traitements à intervalles appropriés. Ici encore, en regardant simplement la chaîne de promesses dans le convertisseur, un appel à thumbnailBatch() doit renvoyer une fonction de gestionnaire Terminé qui renvoie une promesse et la valeur de réalisation de cette promesse (en regardant la prochaine étape de la chaîne) doit être un composant img qui peut ensuite être ajouté au DOM. En ajoutant ces images au DOM après le traitement par lot, nous associons l'intégralité du groupe dans la même passe de rendu.

Cette différence entre la fonction batchRenderer et la fonction multistageRenderer de la section précédente est importante : dans la deuxième fonction, le composant img de la miniature existe déjà dans le DOM et est transmis à la méthode loadImage comme deuxième paramètre. Ainsi, lorsque la méthode loadImage définit l'attribut src de l'image, le rendu est mis à jour. Au sein de la fonction batchRenderer toutefois, ce composant img est créé séparément dans la méthode loadImage (où l'attribut src est également défini), mais le composant img n'est pas encore présent dans le DOM. Il n'est ajouté au DOM qu'à la fin de l'étape thumbnailBatch, ce qui lui permet de faire partie d'un groupe au sein de cette passe de disposition unique.

Examinons maintenant le fonctionnement de ce traitement par lot. Voici la fonction createBatch dans son intégralité :

function createBatch(waitPeriod) {
    var batchTimeout = WinJS.Promise.as();
    var batchedItems = [];

    function completeBatch() {
        var callbacks = batchedItems;
        batchedItems = [];
        for (var i = 0; i < callbacks.length; i++) {
            callbacks[i]();
        }
    }

    return function () {
        batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

        var delayedPromise = new WinJS.Promise(function (c) {
            batchedItems.push(c);
        });

        return function (v) {
            return delayedPromise.then(function () {
                return v;
            });
        };
    };
}

Ici encore, la fonction createBatch est appelée une seule fois et son résultat thumbnailBatch est appelé pour chaque élément rendu dans la liste. Le gestionnaire Terminé que thumbnailBatch génère est ensuite appelé dès qu'une opération loadImage se termine.

Ce gestionnaire Terminé aurait pu être inséré directement dans la fonction de rendu, mais nous essayons dans ce cas de coordonner les activités sur plusieurs éléments à la fois, et non élément par élément. Cette coordination est possible grâce aux deux variables créées et initialisées au début de la fonction createBatch : batchedTimeout, initialisée en tant que promesse vide, et batchedItems, initialisée en tant que tableau de fonctions vide à l'origine. createBatch déclare également une fonction, completeBatch, qui vide simplement batchedItems, en appelant chaque fonction du tableau :

function createBatch(waitPeriod) {
    var batchTimeout = WinJS.Promise.as();
    var batchedItems = [];

    function completeBatch() {
        var callbacks = batchedItems;
        batchedItems = [];
        for (var i = 0; i < callbacks.length; i++) {
            callbacks[i]();
        }
    }

    return function () {
        batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

        var delayedPromise = new WinJS.Promise(function (c) {
            batchedItems.push(c);
        });

        return function (v) {
            return delayedPromise.then(function () {
                return v;
            });
        };
    };
}

Étudions maintenant ce qui se passe dans thumbnailBatch (la fonction renvoyée par createBatch), qui est à nouveau appelée pour chaque élément rendu. D'abord, nous annulons les variables batchedTimeout existantes et en recréons une immédiatement :

batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

La deuxième ligne illustre le futur modèle de distribution/réalisation abordé dans le billet Tout sur les promesses <TODO: link>: elle demande d'appeler completeBatch après un délai de waitPeriod millisecondes (avec une valeur par défaut de 64 ms). Cela signifie que tant que la fonction thumbnailBatch est rappelée dans un intervalle de waitPeriod par rapport à un appel précédent, la variable batchTimeout est réinitialisée sur un autre délai waitPeriod. Et comme la fonction thumbnailBatch est appelée uniquement après la fin d'un appel item.loadImage, cela revient à dire que les opérations loadImage qui se terminent dans l'intervalle waitPeriod par rapport à la précédente seront incluses dans le même lot. Lorsque l'intervalle est supérieur à waitPeriod, le lot est traité (les images sont ajoutées au DOM) et le prochain lot commence.

Une fois ces délais d'expiration gérés, la fonction thumbnailBatch crée une nouvelle promesse qui charge simplement la fonction de répartiteur complète dans le tableau batchedItems :

var delayedPromise = new WinJS.Promise(function (c) {
         batchedItems.push(c);
     });

Comme l'indique le billet Tout sur les promesses <TODO: link> n'oubliez pas qu'une promesse n'est ni plus ni moins qu'une construction de code, et c'est tout ce que nous avons ici. La promesse qui vient d'être créée n'est associée à aucun comportement asynchrone : nous ajoutons simplement la fonction de répartiteur complète c dans batchedItems. Il est évident toutefois que nous ne touchons pas au répartiteur tant que la fonction batchedTimeout n'est pas terminée de manière asynchrone. Il existe par conséquent une relation asynchrone dans ce cas. Lorsque le délai d'expiration se produit et que nous effaçons le lot (à l'intérieur de completeBatch), nous appelons les gestionnaires Terminé qui sont indiqués ailleurs dans delayedPromise.then.

Ceci nous amène aux dernières lignes de code dans createBatch, qui est la fonction que thumbnailBatch renvoie réellement. Cette fonction est exactement le gestionnaire Terminé qui est inséré dans l'intégralité de la chaîne de promesses du convertisseur.

return function (v) {
           return delayedPromise.then(function () {
               return v;
           });
       };

En fait, insérons ce code directement dans la chaîne de promesses pour voir les relations que nous obtenons :

return item.loadImage(item.data.thumbnail);
          }).then(function (v) {
              return delayedPromise.then(function () {
                  return v;
              });
          ).then(function (newimg) {

Nous voyons maintenant que l'argument v est le résultat de item.loadImage, qui est le composant img créé à notre intention. Si nous ne voulions pas du traitement par lot, nous pourrions simplement indiquer return WinJS.Promise.as(v) et toute la chaîne fonctionnerait parfaitement : v serait dans ce cas transmis de manière synchrone et apparaîtrait comme newimg à la prochaine étape.

Nous renvoyons toutefois à la place une promesse depuis delayedPromise.then qui ne sera pas réalisée (avec v) tant que la fonction batchedTimeout n'est pas réalisée. À ce stade (lorsqu'un délai de waitPeriod sépare la fin des opérations loadImage), ces composants img sont ensuite distribués à la prochaine étape de la chaîne, où ils sont ajoutés au DOM.

Et c'est tout !

Pour conclure

Les cinq différentes fonctions de rendu illustrées dans l'exemple d'optimisation des performances de contrôle HTML ListView ont toutes une caractéristique en commun : elles montrent comment la relation asynchrone entre le contrôle ListView et le convertisseur (exprimée au moyen de promesses) confère au convertisseur une extrême flexibilité quant à la manière dont il produit des composants pour les éléments de la liste et quant au moment où il les produit. Pour écrire vos propres applications, la stratégie que vous utilisez pour l'optimisation du contrôle ListView dépend énormément de la taille de votre source de données, de la complexité des éléments eux-mêmes et de la quantité de données que vous obtenez de manière asynchrone pour ces éléments (téléchargement d'images distantes, par exemple). Pour de nombreuses raisons, il est souhaitable de simplifier au maximum les convertisseurs d'éléments en vue de satisfaire vos objectifs de performances. Mais dans tous les cas, vous disposez maintenant de tous les outils dont vous avez besoin pour optimiser les performances du contrôle ListView et de votre application.

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

Les jeux constituent une classe d'applications primordiale dans le Windows Store. Si vous souhaitez créer un jeu Windows Store, la manifestation virtuelle sur la conception des jeux peut vous aider. Cette manifestation gratuite est ouverte aux développeurs de jeux comme aux professionnels.

Nous utiliserons GameMaker : Studio de YoYo Games pour vous montrer comment créer et publier plus rapidement des jeux de grande qualité. Grâce aux nombreuses options de conception intégrées et aux formidables outils de glisser-déplacer de GameMaker : Studio, vous pouvez commencer facilement, même si vous n'avez pas encore de projet bien défini ou n'avez pas encore une grande expérience en développement. Cependant, si vous êtes un développeur de jeux expérimenté, les outils avancés vous permettront d'élaborer une expérience de jeu unique.

La manifestation en ligne commence le samedi 15 juin à 10 h 00 PDT, avec une session de lancement et une conversation en direct. Vous apprendrez à connaître les différents types de jeux et à ajouter des graphismes, des niveaux et du son aux jeux de base, tout en découvrant comment personnaliser votre propre jeu. Tout au long de la semaine, une assistance personnalisée vous sera proposée via les forums GameMaker.

Que vous soyez étudiant, développeur débutant ou professionnel chevronné, cette manifestation vous aidera à créer, ajouter et publier des jeux sur le Windows Store. Pour en savoir plus, vous inscrire et découvrir les ressources et outils gratuits, consultez la page http://msdnevents.com/gameon/.

--Robert Rodriguez-Lawson, Responsable senior de la publication de contenu, Contenu de développement Windows

Si vous n'avez pas encore entendu parler du Stockage sécurisé des informations d'identification qui est disponible pour les applications du Windows Store, il est temps d'aborder le sujet. Pourquoi ? Parce que, non seulement il simplifie le stockage et la récupération des informations d'identification de l'utilisateur, mais il les stocke de manière sécurisée et les informations d'identification suivent « gratuitement » les utilisateurs avec leur compte Microsoft.

Supposons que vous disposiez d'une application qui se connecte à un service pour accéder à des ressources protégées, telles que des fichiers multimédias, un réseau social, etc. Votre service requiert des informations de connexion pour chaque utilisateur. Vous avez donc intégré à votre application une interface utilisateur qui récupère le nom d'utilisateur et le mot de passe de l'utilisateur, qui sont ensuite utilisés pour connecter l'utilisateur au service. Tout fonctionne à merveille.

Vous voulez maintenant aller plus loin pour vos utilisateurs et stocker leurs informations d'identification de manière sécurisée afin qu'ils n'aient pas à se connecter à chaque fois qu'ils utilisent votre application. C'est là que le Stockage sécurisé des informations d'identification intervient. En quelques appels simples à l'API du Stockage sécurisé des informations d'identification, vous pouvez stocker le nom d'utilisateur et le mot de passe de votre utilisateur, puis les récupérer facilement et connecter l'utilisateur lors de sa prochaine ouverture de votre application.

Stockage sécurisé

Un des atouts du Stockage sécurisé des informations d'identification pour votre application est qu'il stocke les informations d'identification de l'utilisateur dans un lieu sécurisé et que ces informations d'identification sont chiffrées lorsqu'elles sont stockées sur le disque. Vous pourriez évidemment stocker les informations d'identification de l'utilisateur dans un fichier du stockage local de votre application, mais enregistrer ce type d'informations en texte brut présente une faille de sécurité considérable. Si le système de l'utilisateur est compromis d'une manière ou d'une autre, son nom d'utilisateur et son mot de passe sont facilement accessibles et utilisables. Si le nom d'utilisateur et le mot de passe sont stockés avec le Stockage sécurisé des informations d'identification, une source malveillante ne réussira qu'à récupérer un fichier chiffré.

Le Stockage sécurisé des informations d'identification est unique pour chaque utilisateur d'un PC Windows et l'accès aux informations d'identification est limité à l'application qui les a stockées. En d'autres termes, vous ne pouvez récupérer que les informations d'identification que vous avez stockées pour votre application. De même, aucune autre application ne peut obtenir les informations d'identification que votre application a stockées dans le stockage sécurisé.

Informations d'identification itinérantes

Autre avantage pour les utilisateurs : lorsque vous stockez leur nom d'utilisateur et leur mot de passe avec le Stockage sécurisé des informations d'identification, ces dernières suivent leur compte Microsoft sur n'importe quelle machine approuvée qu'ils utilisent avec ce compte Microsoft. Ceci rend votre application sécurisée encore plus pratique pour vos utilisateurs, car elle peut les connecter automatiquement (sans demander une nouvelle fois à l'utilisateur ses informations d'identification) sur n'importe quelle machine approuvée sur laquelle ils ont installé votre application et associé leur compte Microsoft.

Le fonctionnement est légèrement différent pour les comptes de domaine. Si des informations d'identification sont stockées avec votre compte Microsoft et que vous associez ce compte à un compte de domaine (par exemple le compte que vous utilisez au travail), vos informations d'identification suivent ce compte de domaine. Toutefois, les nouvelles informations d'identification ajoutées une fois que vous êtes connecté avec le compte de domaine ne sont pas itinérantes. Ceci garantit que les informations d'identification privées du domaine ne sont pas exposées à l'extérieur du domaine.

Stockage des informations d'identification de l'utilisateur

Le stockage des informations d'identification de l'utilisateur dans le Stockage sécurisé des informations d'identification est une procédure simple qui se décompose en deux étapes. Commencez par obtenir une référence au Stockage sécurisé des informations d'identification à l'aide de l'objet PasswordVault auprès de l'espace de noms Windows.Security.Credentials. Créez ensuite un objet PasswordCredential contenant un identifiant pour votre application, le nom d'utilisateur et le mot de passe, puis transmettez ces informations à la méthode PasswordVault.Add() en vue d'ajouter les informations d'identification dans le stockage sécurisé.

C#

var vault = new Windows.Security.Credentials.PasswordVault();
vault.Add(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

JavaScript

var vault = new Windows.Security.Credentials.PasswordVault();
vault.add(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

Récupération des informations d'identification de l'utilisateur

Plusieurs options permettent de récupérer les informations d'identification de l'utilisateur dans le Stockage sécurisé des informations d'identification après avoir obtenu une référence à l'objet PasswordVault.

• Vous pouvez récupérer toutes les informations d'identification que l'utilisateur a fournies pour votre application dans le Stockage sécurisé avec la méthode PasswordVault.RetrieveAll().
• Si vous connaissez le nom d'utilisateur des informations d'identification, vous pouvez récupérer toutes les informations d'identification de ce nom d'utilisateur grâce à la méthode PasswordVault.FindAllByUserName().
• Si vous connaissez le nom de ressource des informations d'identification, vous pouvez récupérer toutes les informations d'identification de ce nom de ressource grâce à la méthode PasswordVault.FindAllByResource().
• Enfin, si vous connaissez à la fois le nom d'utilisateur et le nom de ressource d'informations d'identification en particulier, vous pouvez récupérer uniquement ces informations d'identification à l'aide de la méthode PasswordVault.Retrieve().

Examinons un exemple dans lequel nous avons stocké globalement le nom de ressource dans une application et où nous connectons l'utilisateur automatiquement si nous trouvons des informations d'identification qui lui correspondent. Si nous trouvons plusieurs informations d'identification pour l'utilisateur, nous lui demandons de choisir les informations par défaut à utiliser lors de la connexion.

C#

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    var loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }

    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}


private Windows.Security.Credentials.PasswordCredential GetCredentialFromLocker()
{
    Windows.Security.Credentials.PasswordCredential credential = null;

    var vault = new Windows.Security.Credentials.PasswordVault();
    var credentialList = vault.FindAllByResource(resourceName);
    if (credentialList.Count > 0)
    {
        if (credentialList.Count == 1)
        {
            credential = credentialList[0];
        }
        else
        {
            // When there are multiple usernames,
            // retrieve the default username. If one doesn’t
            // exist, then display UI to have the user select
            // a default username.

            defaultUserName = GetDefaultUserNameUI();

            credential = vault.Retrieve(resourceName, defaultUserName);
        }
    }

    return credential;
}

var resourceName = "My App";
var defaultUserName;

function login() {
    var loginCredential = getCredentialFromLocker();

    if (loginCredential != null) {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.retrievePassword();
    } else {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = getLoginCredentialUI();
    }

    // Log the user in.
    serverLogin(loginCredential.userName, loginCredential.password);
}


function GetCredentialFromLocker() {
    var credential = null;

    var vault = new Windows.Security.Credentials.PasswordVault();
    var credentialList = vault.findAllByResource(resourceName);
    if (credentialList.length > 0) {
        if (credentialList.length == 1) {
            credential = credentialList[0];
        } else {
            // When there are multiple usernames,
            // retrieve the default username. If one doesn’t
            // exist, display UI to have the user select
            // a default username.

            defaultUserName = getDefaultUserNameUI();
            credential = vault.retrieve(resourceName, defaultUserName);
        }
    }

    return credential;
}

Suppression des informations d'identification de l'utilisateur

La suppression des informations d'identification de l'utilisateur dans le Stockage sécurisé des informations d'identification est également une procédure simple qui se décompose en deux étapes. Cette fois encore, obtenez une référence au Stockage sécurisé des informations d'identification à l'aide de l'objet PasswordVault auprès de l'espace de noms Windows.Security.Credentials. Ensuite, transmettez les informations d'identification que vous souhaitez supprimer à la méthode PasswordVault.Remove().

C#

var vault = new Windows.Security.Credentials.PasswordVault();
vault.Remove(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

JavaScript

var vault = new Windows.Security.Credentials.PasswordVault();
vault.remove(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

Simplicité et sécurité

Comme vous pouvez le voir, le Stockage sécurisé des informations d'identification est une fonctionnalité facile à utiliser qui simplifie l'authentification des utilisateurs et le stockage des informations d'identification de ces utilisateurs pour une utilisation future, tout cela dans un mode hautement sécurisé.

Les autres rubriques concernant l'authentification des applications Windows 8 sont notamment celles sur le service Broker d'authentification Web, qui permet de récupérer un jeton d'authentification auprès d'un site Web (par exemple, OAuth) et celle sur la personnalisation de votre applications en fonction du compte Microsoft d'un utilisateur.

Pour plus d'informations, consultez

• Gestion des informations utilisateur (JavaScript)
• Gestion des informations utilisateur (applications du Windows Store en C#/VB/C++ et XAML)
• Exemple de Stockage sécurisé des informations d'identification
• Windows.Security.Credentials

--Doug Rothaus, Développeur de contenu, Contenu de développement Windows

Remerciements tout particuliers à Yashar Bahman pour son aide et sa participation à ce billet.

En associant la localisation d'un utilisateur à la logique métier de votre application, vous pouvez facilement fournir aux utilisateurs de l'application la météo, les bons de réduction, les événements sportifs ou les concerts correspondant à leur position géographique actuelle. Vous pouvez utiliser les fonctionnalités de géolocalisation de Windows 8, ainsi que le SDK Cartes Bing, pour créer de formidables applications du Windows Store prenant en charge la géolocalisation.

Examinons comment votre application peut tirer parti du service de localisation pour offrir aux utilisateurs des informations spécifiques à une localisation à l'aide d'une adresse IP, d'un réseau Wi-Fi ou de données GPS. Une fois que vous connaissez la localisation, vous pouvez utiliser le SDK Cartes Bing pour afficher la position géographique à l'utilisateur.

Récupération de la localisation

L'espace de noms Windows.Devices.Geolocation permet de récupérer votre localisation. Le fait que vous utilisiez le GPS, un réseau Wi-Fi ou une adresse IP pour récupérer la localisation d'un utilisateur dépend de deux facteurs principaux :

1. Le niveau de précision demandé. Il s'agit du niveau de précision idéal pour répondre aux besoins de votre application.
2. La disponibilité des données de localisation. Tous les périphériques n'ont pas de GPS intégré. Il est également possible qu'aucun réseau ou qu'aucune connexion Wi-Fi ne soit disponible au moment où la localisation est demandée.

Précision voulue

Lors de la demande d'une localisation, votre application doit spécifier la précision voulue afin que les données de localisation puissent être renvoyées aussi rapidement que possible dans la plage donnée. Chacun des types de localisation dispose de degrés de précision :

• GPS : le GPS offre une précision optimale, jusqu'à 10 mètres environ. Toutefois, si le capteur doit « se réveiller » et acquérir les données satellite, puis trianguler les données, le renvoi des détails de localisation peut nécessiter une ou deux minutes. Cependant, une fois que le GPS a acquis les connexions satellite, il peut ensuite acquérir le point de localisation suivant plus rapidement. Évidemment, plus le GPS est utilisé et plus sa consommation énergétique est élevée. La propriété Geolocator.DesiredAccuracy doit être définie sur High (élevée) pour que le GPS puisse acquérir des données.
• Wi-Fi : une connexion Wi-Fi peut fournir une précision comprise entre 300 et 500 mètres. En cas de connexion, le renvoi des données de localisation peut être plus rapide que l'acquisition des connexions satellite par un GPS. Définissez la propriété DesiredAccuracy sur Default (par défaut) afin d'acquérir la localisation avec une connexion Wi-Fi.
• IP : une résolution de niveau IP peut fournir une précision allant jusqu'à environ 1 kilomètre. En cas de connexion réseau, le renvoi des données de localisation peut être plus rapide que l'acquisition d'une connexion satellite par un GPS. Vous pouvez définir la propriété DesiredAccuracy sur Default (par défaut) pour acquérir la localisation avec IP. Le service de localisation renvoie la précision la plus élevée possible et vous en fait connaître le niveau dans la propriété Geocoordinate.Accuracy.

Choisissez la précision voulue avec attention. Elle peut affecter les performances et la consommation énergétique de votre application. Par exemple, si votre application fournit des prévisions météorologique, vous avez rarement besoin de la précision élevée du GPS. Veillez par ailleurs à indiquer la précision de vos données en affichant un rayon d'erreur basé sur la précision des données renvoyées. Voici le code C# permettant de définir votre précision voulue :

C#

Geolocator geolocator = new Geolocator();
geolocator.DesiredAccuracy = Windows.Devices.Geolocation.PositionAccuracy.High;

C#

Geoposition pos = await geolocator.GetGeopositionAsync().AsTask(token);

Ce code JavaScript permet de créer une instance de la classe Geolocator, de définir la précision voulue, puis d'obtenir la localisation actuelle. Notez que la variable « promise » ci-dessous est un objet WinJS.Promise. Vous devez utiliser la méthode done pour accéder aux données depuis l'appel à getGeopositionAsync.

JavaScript

var geolocator = Windows.Devices.Geolocation.Geolocator();
geolocator.desiredAccuracy =
Windows.Devices.Geolocation.PositionAccuracy.high;

// Get the geoposition, capturing the request in a 'promise' object.
var promise = geolocator.getGeopositionAsync();

Cartes Bing

L'application Cartes Bing est un bon exemple d'application qui s'adapte à la précision des données de localisation qui lui sont proposées. Sur un ordinateur de bureau, qui n'est généralement pas doté d'un GPS ou d'une connexion Wi-Fi, elle recherche la localisation en fonction de l'adresse IP et zoome sur une région lorsqu'elle affiche la position géographique actuelle sur la carte. Sur un ordinateur portable, qui comporte généralement une carte sans fil, elle utilise la connexion Wi-Fi pour obtenir une localisation plus précise et affiche la position géographique actuelle avec un zoom plus important. Si l'utilisateur zoome encore plus, l'icône de localisation actuelle présente un rayon d'erreur. Sur un périphérique avec GPS, Cartes Bing reçoit les données de localisation d'une précision élevée de la part du GPS et affiche une position géographique plus précise.

Bing Météo

Comme indiqué ci-dessus, une application telle que l'application Bing Météo n'a besoin que d'informations régionales. Elle peut ainsi indiquer qu'elle n'a besoin que d'une précision faible et renvoyer rapidement une valeur de localisation. Cela permet à l'application d'être plus réactive aux yeux des utilisateurs. Parmi les autres applications qui ne nécessitent que des informations au niveau régional se trouvent les guides des stations de radio, certaines offres commerciales ou les flux d'actualités locales.

Affichage de données de localisation avec le SDK Cartes Bing

Après avoir obtenu les informations de localisation suite à votre appel à GetGeopositionAsync, vous pouvez les afficher sur une carte.

• Commencez par convertir la classe Geoposition en classe Location pouvant être utilisée avec Cartes Bing. Pour ce faire, utilisez le code suivant :

C#

Location location = new Location(pos.Coordinate.Latitude, pos.Coordinate.Longitude);

JavaScript :

promise.done(
  function (pos) {
    // Get the coordinates of the current location.
    var coord = pos.coordinate,
    location = new Microsoft.Maps.Location(coord.latitude, coord.longitude);
 
  },
  function (err) {
    // Handle the error.
  });

• Affichez ensuite votre localisation avec Cartes Bing. Vous pouvez obtenir le SDK Cartes Bing ici. Vous devez également obtenir une clé Cartes Bing en vous inscrivant sur le portail Cartes Bing et en suivant les instructions d'obtention d'une clé Cartes Bing. Au moment de l'inscription, n'oubliez pas de regarder les restrictions d'utilisation de chaque type de clé et choisissez celle qui convient le mieux à votre application.
  Ajoutez un contrôle Cartes Bing à votre concepteur et insérez votre clé dans les informations d'identification.

<Page
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:SimpleMapping"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:Maps="using:Bing.Maps"
    x:Class="SimpleMapping.MainPage"
    mc:Ignorable="d">

    <Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
        <Maps:Map x:Name="Map" Margin="0,120,0,0" Credentials="Insert Your Bing Maps Key Here"/>
    </Grid>
</Page>

• Vous pouvez maintenant utiliser le code suivant sur la page de votre application où la carte apparaît. Cette opération définit le niveau de zoom de la carte et affiche la localisation. Pour en savoir plus sur le niveau de zoom, consultez Comment afficher votre localisation sur une carte Bing :

C#

double zoomLevel = 13.0f;

Map.SetView(location, zoomLevel);

<script type="text/javascript" 
   src="ms-appx:///Bing.Maps.JavaScript//js/veapicore.js">
/script>

Vous devez ensuite créer une balise <div> qui contiendra la carte, en définissant l'attribut id de façon à pouvoir y accéder.

<div id=’map-div’></div>

Dernière opération : vous devez initialiser le contrôle de carte dans la page HTML. Voici un code JavaScript correspondant :

// Load the Microsoft.Maps.Map module and then call getMap when the 
// module has loaded.
function initMap() {
  Microsoft.Maps.loadModule('Microsoft.Maps.Map', 
    { 
      callback: getMap, 
      culture: "en", 
      homeRegion: "US" 
  });
}

// Get the div to contain the map from the interface of the app.
function getMap() {

  // Create a new instance of the Map class, passing in the app ID.
  var map = new Microsoft.Maps.Map(
    document.getElementById(mapDivId), 
    { credentials: “Insert your credentials here” });

  // Set the initial zoom level and type of map.
  map.setView({
    mapTypeId: Microsoft.Maps.MapTypeId.road,
    zoom: 3
  });
}

• Enfin, toutes les applications qui utilisent la localisation doivent respecter les paramètres d'autorisation de l'utilisateur, susceptibles de changer à tout moment. L'application Météo utilise la localisation pour obtenir la météo de l'emplacement actuel. Mais l'utilisateur peut à tout moment accéder aux paramètres et désactiver les autorisations liées à la localisation. Votre application doit toujours faire face à la possibilité d'une désactivation des autorisations liées à la localisation. Dans ce cas, l'application Météo affiche un message du type « Votre localisation est introuvable. Modifiez vos autorisations pour autoriser l'application Météo à utiliser votre localisation. ». Consultez les Recommandations pour les applications prenant en charge la géolocalisation pour voir des exemples de gestion des autorisations de localisation.
  

Pour en savoir plus sur la géolocalisation et le SDK Cartes Bing, nous proposons une nouvelle rubrique détaillée avec vidéo, ainsi qu'un exemple de code qui vous explique comment acquérir de manière asynchrone votre localisation, puis comment utiliser le SDK Cartes Bing pour visualiser votre position géographique. La vidéo, la rubrique détaillée et l'exemple vous indiquent comment activer la fonctionnalité de localisation, obtenir la localisation de manière asynchrone, définir la carte sur une localisation donnée et définir l'icône de localisation en fonction de la précision des données de localisation. Vous trouverez également plus d'informations dans Bing Maps for Windows Store Apps.

Pour résumer

L'ajout de la localisation dans votre application peut vous faire gagner du temps. Cette fonctionnalité vous permet d'offrir à l'utilisateur des informations plus pertinentes en fonction de sa position géographique. Qu'il s'agisse d'une liste de stations de radio locales, d'offres commerciales, de conditions de circulation ou d'informations météorologiques, la capacité d'adapter ces données en fonction de la localisation peut accroître l'utilité de votre application. En outre, la possibilité de rendre tout le processus automatique, sans que l'utilisateur n'ait besoin d'intervenir, permet à ce dernier de gagner du temps et augmente les chances qu'il utilise votre application.

--Ross Heise, Développeur de contenu, Contenu de développement Windows

   Remerciements tout particuliers à Jon Kay et Eric Schmidt pour leur aide et leur participation à ce billet.

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 :

1. 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.
2. 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

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 :

• Restaurant
• Place
• LocalBusiness
• FoodEstablishment

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 :

1. Une nouvelle instance de l'application est ouverte dans la fenêtre de la cible de partage, par-dessus l'application source.
2. 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.
3. Votre application peut récupérer les données que l'utilisateur a partagées à partir de cet objet.
4. 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

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 :

1. 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 »

2. 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 :

1. 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.
2. 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 :

1. 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.
2. 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.
3. 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
}

1. 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.
2. 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.
3. 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

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

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);
        });
}

C#

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.

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 :

1. 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.
2. 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.

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.

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;
}

C#

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 :

1. 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.
2. 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);
    }
}

C#

// 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.
        });
}

C#

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

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 !