Créer des applications Windows Store connectées

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: "https://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("https://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