Windows Dev Center

Développement d’applications connectées

Le présent document fournit un ensemble de considérations sur le réseau que chaque application du Windows Store connectée doit respecter.

Introduction

Windows 8 présente le nouveau Windows Runtime proposant un ensemble d’API simples mais puissantes que les développeurs peuvent utiliser pour générer des applications en C++, C# ou JavaScript. L’une des principales caractéristiques des applications du Windows Store est que la plupart d’entre elles sont « connectées ».

Ce document définit une application connectée, ou orientée réseau, comme une application du Windows Store utilisant le réseau à diverses fins. Chaque application connectée doit respecter les recommandations ci-dessous afin de fournir une expérience prévisible et agréable aux utilisateurs.

Sélection de la fonctionnalité réseau appropriée

Les applications doivent déclarer les fonctionnalités d’isolement réseau afin d’obtenir l’accès aux ressources réseau. Utilisez la liste de vérification suivante afin de vous assurer que l’isolement réseau est configuré pour votre application.

  • Déterminez le sens de l’accès réseau dont votre application réseau a besoin : Cela peut être des demandes sortantes engagées par des clients, des demandes entrantes non sollicitées ou une combinaison des deux.
  • Déterminez le type de ressources réseau avec lesquelles votre application doit communiquer. Songez à prévoir si votre application a besoin de communiquer avec des ressources approuvées sur un réseau domestique, d’entreprise, sur Internet ou une combinaison de ces types de réseau.
  • Configurez les fonctionnalités d’isolement réseau minimales requises dans le manifeste de l’application. Vous pouvez procéder à l’aide de Microsoft Visual Studio Express 2012 pour Windows 8 lors du développement de l’application.
  • Déployez et exécutez votre application afin de la tester à l’aide des outils d’isolement réseau fournis pour la résolution des problèmes.

Les fonctionnalités déclarées sont appliquées par Windows. Les applications doivent utiliser le principe des privilèges minimum et ajouter uniquement les fonctionnalités dont elles ont besoin. Le tableau suivant détaille les fonctionnalités d’isolement réseau.

Fonctionnalité réseauDescription

Internet (client)

Fournit un accès sortant à Internet et aux réseaux dans les lieux publics, comme les aéroports et les cybercafés. La plupart des applications qui nécessitent un accès Internet doivent déclarer cette fonctionnalité.

Remarque  

Déclarée par le mot-clé internetClient dans le manifeste de l’application.

Internet (client et serveur)

Fournit un accès bidirectionnel à Internet et aux réseaux dans les lieux publics, comme les aéroports et les cybercafés. L’accès entrant aux ports critiques est toujours bloqué.

Cette fonctionnalité représente un sur-ensemble de la fonctionnalité Internet (client). Il n’est pas nécessaire de déclarer les deux.

Remarque  

Déclarée par le mot-clé internetClientServer dans le manifeste de l’application.

Réseaux privés (client et serveur)

Fournit un accès réseau entrant et sortant aux lieux approuvés par l’utilisateur, par exemple à son domicile ou sur son lieu de travail. L’accès entrant aux ports critiques est toujours bloqué.

Déclarée par le mot-clé privateNetworkClientServer dans le manifeste de l’application.

 

Les autres certificats susceptibles d’être nécessaires à votre application connectée incluent ceux liés à la détection de proximité d’appareils ou les certificats utilisateur partagés. Pour plus d’informations sur l’isolement réseau et la déclaration des fonctionnalités, voir Comment configurer les fonctionnalités d’isolement réseau.

Sélection de l’API appropriée

Windows Runtime fournit la prise en charge de plusieurs API de réseau permettant de communiquer avec des points de terminaison distants sur Internet ou sur des réseaux privés. Dans l’éventualité où un protocole de niveau supérieur spécifique ne serait pas disponible par le biais d’une API, Windows Runtime prend également en charge les sockets TCP et UDP (avec la multidiffusion) afin de permettre aux développeurs d’implémenter d’autres protocoles de niveau supérieur.

Qui est impacté ?

Toutes les applications du Windows Store devant envoyer ou recevoir des données sur le réseau sont concernées.

Indications

Tout d’abord, déterminez la fonctionnalité que vous souhaitez attribuer à votre application. Si la fonctionnalité fait partie des domaines indiqués ci-dessous, utilisez ces API directement.

APIFonctionnalité

Windows.Web.AtomPub, Windows.Web.Syndication

API utilisées pour la récupération des flux aux formats RSS ou Atom dans plusieurs versions. Windows Runtime prend également en charge le protocole APP (Atom Publication Protocol) qui active la publication des collections Atom. Ces API simplifient également l’implémentation de la prise en charge des formats plus récents tels qu’OData.

Windows.Networking.BackgroundTransfer

API utilisées pour le chargement/téléchargement de contenu ininterrompu, rentable et pouvant être repris, même lorsque l’application d’appel n’est pas en arrière-plan. Cette API prend en charge le téléchargement au moyen des protocoles HTTP, HTTPS et FTP.

XMLHTTPRequest (JavaScript), HttpClient (C#), IXHR2 (C++).

API utilisées pour interagir avec les services Web RESTful et autres protocoles HTTP.

Windows.Networking.Proximity

API servant à détecter la proximité entre deux périphériques, à la suite de quoi les applications peuvent lancer les communications réseau entre eux à l’aide des API de socket.

Windows.Storage.Pickers

Les API utilisées pour assurer la communication avec les partages de fichiers distants (comme l’enregistrement d’un fichier dans un partage de fichiers distant) doivent utiliser les API de sélecteur de fichiers.

 

Si une API avec la fonctionnalité que vous souhaitez inclure n’est pas répertoriée ci-dessus, utilisez les nouvelles API de Windows.Networking.Sockets. Sachez toutefois que les points suivants s’appliquent aux applications utilisant ces API :

  • Windows 8 introduit un nouveau type de socket, appelé « WebSocket ». Vous trouverez ci-dessous quelques éléments d’informations à prendre en considération pour choisir à quel moment utiliser les différents types de sockets (UDP, TCP ou Websockets).

    • Si vous vous connectez à un service utilisant un protocole non pris en charge par les API décrites dans cette section, comme SMTP, MAPI ou telnet, utilisez les sockets TCP ou UDP.

    • Si vous devez vous connecter à un autre périphérique sur le même réseau local, utilisez les sockets TCP ou UDP.

    • Si vous avez besoin d’un protocole de demande et de réponse simple pouvant communiquer par le biais de proxys HTTP, utilisez les API REST décrites ci-dessus. (C++, C#, JavaScript).

    • Si vous créez une application nécessitant une sémantique similaire à celle des sockets (asynchrone, bidirectionnelle) pour se connecter sur le Web (notamment via des proxys HTTP) à un service que vous créez également, utilisez les WebSockets.

  • Utilisez les noms pour déclarer les points de terminaison. Évitez d’utiliser les adresses IP (qui incluent des littéraux IP dans URIs) pour déclarer les points de terminaison car elles peuvent changer, contrairement aux noms. L’utilisation d’un nom garantit généralement que vous vous connectez à l’adresse IP actuelle du point de terminaison.

  • Les API Windows utilisent généralement des chaînes Unicode au format natif (y compris pour HostNames et URIs). Un protocole donné peut toutefois nécessiter un autre format ; veillez alors à convertir les chaînes dans le format requis par le protocole à l’aide des méthodes de classe DataReader/DataWriter.

  • HostNames et URIs doivent être implémentées en tant qu’objets de classe et non en tant que chaînes, lors de la comparaison d’égalité, car les règles d’égalité sont différentes pour les objets.

  • Inscrivez-vous aux notifications de changements d’état du réseau, puis suivez les instructions indiquées dans Comportement en réponse aux changements d’état du réseau.

Adaptation du comportement de l’application pour les connexions réseau limitées

Les connexions réseau limitées existent depuis longtemps. La plupart des fournisseurs de services Internet (ISP) ont établi un plafond (généralement assez élevé) définissant le volume de données que les utilisateurs peuvent transférer chaque mois. Très récemment, la popularité grandissante des technologies de réseaux haut débit mobiles ont rendu le problème plus aigu en ce sens que le dépassement de la quantité de données autorisée ou l’itinérance peut engendrer un surcoût non négligeable pour l’utilisateur. Les applications doivent donc surveiller les ressources réseau disponibles et s’adapter en conséquence.

Le tableau ci-dessous répertorie les coûts de connexion possibles défini par l’API Windows.Networking.Connectivity.ConnectionCost.

PropriétéDescription

ApproachingDataLimit

Obtient une valeur indiquant si une connexion approche de son quota d’utilisation indiqué par le plan de facturation à l’usage.

NetworkCostType

Obtient une valeur indiquant le coût du réseau actif pour une connexion.

  • Unrestricted: connexion réseau illimitée. Aucune contrainte de frais d’utilisation et de capacité n’est appliquée.

  • Fixed: connexion réseau illimitée jusqu’à un certain seuil.

  • Variable: connexion limitée à un volume de données exprimé en octets.

  • Unknown: informations sur les coûts non disponibles pour cette connexion réseau.

OverDataLimit

Obtient une valeur indiquant si la connexion a dépassé son quota d’utilisation indiqué par le plan de facturation à l’usage.

Roaming

Obtient une valeur indiquant si la connexion est établie avec un réseau à l’extérieur du fournisseur personnel.

 

Qui est impacté ?

En général, toutes les applications, notamment celles qui transfèrent de grandes quantités de données, doivent suivre les instructions ci-dessous :

Les utilisateurs sont capables de déterminer la bande passante utilisée par chaque application. Une utilisation incorrecte de la bande passante de la connexion réseau limitée peut avoir des répercussions sur la réputation de votre application et de votre société.

Guidance

Les applications qui se connectent à des serveurs sur Internet doivent obtenir des informations sur le coût du réseau à travers lequel elles envoient et reçoivent des données par le biais de GetInternetConnectionProfile. En fonction des limites de transfert de données définies par le fournisseur, suivez les recommandations ci-après :

ComportementRecommandations
Normal

Dans les scénarios habituels, l’application ne doit pas implémenter de restrictions. La connexion doit être considérée comme illimitée (« Unlimited ») du point de vue des coûts et non restreinte par des frais d’usage et des contraintes de capacité.

Si le type de coût du réseau NetworkCostType correspond à « Unrestricted » ou à « Unknown » et que le coût de connexion ConnectionCost est différent de « Roaming », l’application doit alors implémenter un comportement normal.

Exemples :

  • L’application de lecteur multimédia peut lire l’intégralité d’un film HD.

  • Une application peut télécharger un fichier volumineux sans aucun message d’invite ou restriction.

Conservateur

Dans les scénarios prudents, l’application doit implémenter des restrictions pour l’optimisation de l’usage du réseau pour gérer les opérations sur les connexions réseau limitées.

Si le type de coût du réseau NetworkCostType correspond à « Fixed » ou à « Variable » et que le coût de connexion ConnectionCost est différent de « Roaming » ou « OverDataLimit », l’application doit alors implémenter un comportement conservateur.

Exemples :

  • L’application de lecteur multimédia peut reproduire des films dans des résolutions inférieures.

  • Une application peut retarder les téléchargements non critiques.

  • Une application peut éviter la prérecherche d’informations à travers un réseau.

  • Les applications de messagerie électronique peuvent passer à un mode se limitant aux en-têtes pour la réception des messages électroniques.

Accord

Dans les scénarios d’abonnement, l’application doit gérer les cas exceptionnels où le coût d’accès au réseau est significativement supérieur au coût du plan de facturation. Par exemple, lorsqu’un utilisateur se connecte en itinérance, un opérateur mobile peut alors facturer des frais nettement supérieurs.

Si le coût de connexion ConnectionCost correspond à « Roaming » ou à « OverDataLimit », l’application doit alors implémenter un comportement demandant l’accord de l’utilisateur.

Exemples :

  • L’application doit demander à l’utilisateur d’accéder au réseau.

  • L’application doit suspendre toutes les activités réseau de données en arrière-plan.

 

Comportement en réponse aux changements d’état du réseau

Lorsque Windows 8 détecte de nouveaux réseaux, il fournit automatiquement les nouvelles options de connexion. Ainsi, si un utilisateur utilise un réseau 3G pour transmettre des données et qu’il revient ensuite dans un réseau Wi-Fi, la nouvelle option de connexion est mise à la disposition de l’application qui peut l’exploiter si nécessaire.

Quels que soient les appareils mobiles utilisés, l’offre de réseaux varie. Un réseau 3G peut ne pas être opérationnel dans la maison ou le garage d’un utilisateur alors que la connexion Wi-Fi est toujours disponible ; de la même façon, les connexions Wi-Fi peuvent être hors de portée lorsqu’un utilisateur quitte son domicile. Parfois aussi, aucun réseau n’est disponible. En raison de la multiplication actuelle des réseaux haut débit mobiles et Wi-Fi, les changements de réseau (réseaux nouveaux, retirés ou non disponibles) seront bientôt courants. Les connexions ne passent pas automatiquement et de façon transparente sur un nouveau réseau : l’application doit le faire de manière explicite. Notez que la stratégie par défaut dans Windows 8 est de donner la priorité au réseau non restreint sur la connexion réseau limitée, et de sélectionner le réseau le plus rapide.

Qui est impacté ?

Toutes les applications du Windows Store exploitant un réseau sont concernées. Le non-respect de ces instructions peut nuire au confort d’utilisation lorsque des changements de réseau se produisent.

Indications

Toutes les applications du Windows Store doivent respecter la procédure suivante :

  1. Si la connexion que l’application utilisait n’est plus disponible (indication par une erreur) :

    1. Vérifiez le coût de connexion à Internet.

    2. Réessayez l’opération. Si cela échoue, attendre la prochaine notification NetworkStatusChanged.

  2. Vérifiez le coût de connexion à Internet, puis adaptez le comportement en suivant les recommandations indiquées plus haut, dans la section Adaptation du comportement de l’application pour les connexions réseau limitées.

  3. Inscrivez-vous aux notifications de changements d’état du réseau (onNetworkStatusChanged).

  4. Démarrez l’opération réseau au moyen de l’une des API décrites dans Sélection de l’API appropriée.

  5. Une notification de changement d’état du réseau indique que les options de connexion ou de coût disponibles ont changé. À la réception de cette notification, procédez comme suit :

    1. Vérifiez le coût de connexion à Internet. Si la caractéristique du coût a changé (gratuit -> payant ou payant -> gratuit), réessayez l’opération réseau. Windows 8 utilisera automatiquement le réseau le plus adapté ou le coût le plus faible disponible. Si, lors de la nouvelle tentative, l’opération réseau réussit, annulez l’opération réseau d’origine.

      Remarque  Les développeurs confirmés peuvent également choisir d’optimiser le comportement de l’application lors de nouvelles tentatives d’opérations réseau. Vous voudrez peut-être remplacer une connexion existante par une nouvelle connexion sur un réseau plus rapide. Dans ce scénario, un développeur peut utiliser les API de sockets (BandwidthStatistics) pour déterminer si le changement est pertinent.
    2. Si la caractéristique de coût de la connexion à Internet n’a pas changé, alors qu’une notification liée au coût est reçue, telle qu’une stratégie de connexion consommée, un coût variable, une itinérance >80 %, etc., adaptez le comportement.

Débogage et résolution des problèmes des applications connectées

Les problèmes réseau peuvent engendrer le blocage ou l’arrêt des applications, ainsi que l’affichage de boîtes de dialogue inertes et de messages d’erreur déroutants pour les utilisateurs. Le débogage de ces erreurs peut s’avérer difficile car celles-ci peuvent se produire n’importe où dans la pile du réseau.

Qui est impacté ?

Toutes les applications du Windows Store utilisant le réseau soit directement (à l’aide des sockets) soit indirectement (à l’aide d’une API utilisant le réseau) sont concernées. Idéalement, le système d’exploitation traite automatiquement les conditions d’erreur au nom du développeur et lorsque cela ne fonctionne pas, les applications doivent être prêtes à gérer les erreurs.

Indications

Assurez-vous que les applications du Windows Store permettent les actions suivantes :

  • En cas d’erreur de réseau, vous devez pouvoir réessayer l’opération. Par exemple, ne renouvelez pas l’opération en cas d’échec de l’authentification, mais retentez-la si la connexion au réseau avec lequel vous communiquiez s’est interrompue car un autre réseau était peut-être disponible. De nombreuses erreurs disparaissent naturellement lors d’une nouvelle tentative d’opération. Veillez à suivre les recommandations indiquées plus haut dans Comportement en réponse aux changements d’état du réseau.

  • Utilisez des API asynchrones afin d’empêcher la présence d’appels de blocage sur le thread d’interface utilisateur. Autrement dit, si l’exécution d’une opération réseau est très longue ou qu’une erreur est signalée, votre application ne doit pas se bloquer. N’émulez pas un comportement synchrone sur le comportement asynchrone de Windows Runtime.

  • Dans l’idéal, vous devez disposer d’un modèle de traitement des erreurs planifié à l’avance à portée de main. Lors de la conception de votre application, réfléchissez à la façon dont vous souhaitez signaler les erreurs à l’utilisateur. Par exemple, Outlook utilise un indicateur réseau discret, Communicator se sert d’un modèle de « remplacement de l’intégralité de l’interface utilisateur », tandis qu’Internet Explorer intègre une boîte de dialogue orientée vers les tâches de téléchargement qui affiche les erreurs de réseau. Interceptez les éventuelles exceptions levées, essayez de comprendre chacune des chaînes d’erreur et informez l’utilisateur en conséquence.

  • Testez votre application dans différents environnements réseau en essayant plusieurs opérations (déconnexion de votre réseau ou nouvelle connexion à votre réseau, interruption ou reprise de la connexion, ou encore changement de réseau).

  • Lorsque vous testez votre application et détectez des erreurs qui ne sont pas évidentes, activez le traçage ETW.

Ressources

La documentation suivante fournit des instructions et des détails sur les API pour les fonctionnalités Windows Runtime décrites dans cette rubrique :

Recommandations en matière d’implémentation de fonctionnalités

Ajout d’une prise en charge de réseau
Connexion à un service Web
Connexion aux services réseau
Connexion à un service WebSocket
Accès aux informations de connexion et de forfait données
Transfert d’un fichier à partir d’une ressource réseau
Accès et gestion du contenu syndiqué

Exemples de code

Documentation relative aux espaces de noms

Windows.Networking.BackgroundTransfer
Windows.Networking.Connectivity
Windows.Networking.Proximity
Windows.Networking.Sockets
Windows.Storage.Picker
Windows.Web.AtomPub
Windows.Data.Html
Windows.Web.Syndication
Windows.Foundation (classe Uri)
Windows.Networking (classe HostName)
Windows.Storage.Streams (classes DataReader/DataWriter)

 

 

Afficher:
© 2015 Microsoft