Test de la fonctionnalité de proximité et résolution des problèmes connexes dans les applications (HTML)

  • Article

[ Cet article est destiné aux développeurs de Windows 8.x et Windows Phone 8.x qui créent des applications Windows Runtime. Si vous développez une application pour Windows 10, voir la Documentation ]

Cette rubrique fournit des instructions que les développeurs d’applications peuvent suivre pour tester la proximité et résoudre les problèmes qui y sont liés au sein d’une application, avant de soumettre celle-ci au Windows Store.

Avant de commencer

La proximité représente un excellent moyen de créer une expérience de partage d’application entre deux instances de votre application qui s’exécutent sur deux appareils distincts. Avec une application de proximité, il suffit aux utilisateurs de poser un appareil sur un autre pour établir une connexion. De même, un utilisateur peut rechercher un autre appareil qui exécute ce type d’application à portée de connexion sans fil. La recherche d’applications homologues sur d’autres PC utilise la fonctionnalité WiFi-Direct. Sur Windows Phone, la découverte d’applications homologues utilise la technologie Bluetooth et recherche les applications homologues qui s’exécutent sur d’autres téléphones.

Pour permettre le test des fonctionnalités qui répondent à une action d’appuyer, chaque appareil doit être doté de la technologie de proximité appropriée, par exemple la communication en champ proche (NFC) par ondes radio. Pour permettre le test des fonctionnalités qui utilisent la navigation sans fil sur PC, chaque PC doit prendre en charge la fonctionnalité Wi-Fi Direct.

Remarque  Pour permettre le test des fonctionnalités de navigation des applications du Windows Phone Store, chaque téléphone doit prendre en charge la technologie Bluetooth.

Préparation aux tests:

Si vous ne possédez aucun matériel prenant en charge l’action d’appuyer pour la proximité, comme la communication en champ proche (NFC) par ondes radio, vous pouvez utiliser le pilote de proximité proposé à titre d’exemple dans le cadre des exemples du WDK (Windows Driver Kit). Ce pilote peut vous servir à simuler une action par appui sur une connexion réseau établie entre deux appareils. Pour plus d’informations sur le téléchargement du Windows Driver Kit (WDK), voir Windows Driver Kit (WDK). Après avoir installé le WDK et les exemples, vous trouverez l’exemple de pilote de proximité dans le répertoire src\nfp, là où vous avez installé les exemples WDK. Reportez-vous au fichier NetNfpProvider.html, dans le répertoire src\nfp\net, pour obtenir des instructions sur la création et l’exécution du simulateur. Une fois le simulateur démarré, celui-ci s’exécute en arrière-plan tandis que votre application de proximité opère au premier plan. Pour que la simulation de l’action par appui fonctionne, votre application doit se trouver au premier plan.

Connexion des applications à l’aide de la classe PeerFinder

Vous pouvez utiliser la classe PeerFinder pour connecter des sockets entre des instances de la même application fonctionnant sur deux appareils distincts, autrement dit une application homologue. À l’aide de la classe PeerFinder, vous pouvez soit connecter des applications homologues par une simple action d’appuyer, soit utiliser Wi-Fi Direct pour rechercher des homologues à portée de connexion sans fil. Ces deux méthodes de connexion d’applications homologues créent un socket ouvert entre ces applications et la prise en charge des fonctionnalités de connexion déclenchées (appui) et recherchées (Wi-Fi Direct) dans votre application.

Pour consulter un exemple de connexion d’applications homologues, voir Démarrage rapide : connexion d’applications via une action d’appuyer ou une recherche ou Exemple de proximité dans la galerie d’exemples. Pour obtenir des recommandations en matière de création d’applications utilisant la fonctionnalité de proximité, voir Recommandations sur le développement avec la fonctionnalité de proximité.

Hh967765.wedge(fr-fr,WIN.10).gifTest de connexion des applications homologues

  1. Installez et démarrez votre application sur deux appareils.
  2. Sur ces deux appareils, effectuez une publication pour une connexion homologue. Pour cela, appelez la méthode Start.
  3. Pour tester les connexions déclenchées, appuyez sur les périphériques en même temps.
  4. Assurez-vous que l’interface utilisateur au sein de l’application reflète l’état de l’action d’appuyer (par exemple, quand un homologue est détecté, quand les appareils sont en cours de connexion, et ainsi de suite). Pour plus d’informations, voir l’événement TriggeredConnectionStateChanged.
  5. Si la connexion aboutit, vérifiez alors que l’interface utilisateur dans l’application confirme que cette fonctionnalité réseau est activée sur les deux appareils.
  6. Si la connexion échoue, assurez-vous dans ce cas que l’interface utilisateur dans l’application informe l’utilisateur de l’échec de la connexion réseau.
  7. Pour tester les connexions sans fil, demandez à l’un des deux appareils de rechercher des connexions homologues disponibles. Pour cela, appelez la méthode FindAllPeersAsync. La navigation est prise en charge uniquement entre des PC ou entre des téléphones, mais pas entre des téléphones et des PC. Le mécanisme du déroulement de la navigation est différent pour une application exécutée sur un PC et une application exécutée sur un téléphone. Windows Phone prend uniquement en charge la navigation via Bluetooth, alors que les PC prennent uniquement en charge la navigation via WiFi-Direct.
  8. Si la connexion aboutit, vérifiez alors que l’interface utilisateur dans l’application confirme que cette fonctionnalité réseau est activée sur les deux appareils.
  9. Si la connexion échoue, assurez-vous dans ce cas que l’interface utilisateur dans l’application informe l’utilisateur de l’échec de la connexion réseau.
  10. Si votre application prend en charge les connexions avec plus de deux homologues, étendez le test à plusieurs appareils.

Si une application prenant en charge les connexions déclenchées (appui) est installée sur deux appareils, le fait de solliciter une connexion depuis un appareil via une action d’appuyer déclenchera un message invitant l’utilisateur du deuxième appareil à démarrer ou installer l’application. Cette application doit être exécutée au premier plan sur l’appareil à l’origine de la requête. Cette fonctionnalité n’est pas prise en charge quand vous recherchez des connexions à l’aide de la méthode FindAllPeersAsync.

Hh967765.wedge(fr-fr,WIN.10).gifTest des applications démarrées par une action d’appuyer

  1. Installez votre application sur deux appareils. Démarrez l’application sur le premier appareil seulement.
  2. Sur l’appareil qui exécute votre application, effectuez une publication pour une connexion homologue. Pour cela, appelez la méthode Start.
  3. Posez les appareils l’un sur l’autre.
  4. Sur le deuxième appareil, assurez-vous qu’un message de notification est émis et invite l’utilisateur à démarrer l’application. Acceptez la notification.
  5. Assurez-vous que l’application démarre correctement sur le deuxième appareil et qu’elle crée immédiatement un socket réseau de proximité. Vérifiez que l’interface utilisateur dans l’application confirme que la fonctionnalité réseau est activée sur les deux appareils.
  6. Si l’application ne démarre pas comme prévu, assurez-vous que son interface utilisateur sur l’appareil émetteur de la requête reflète l’échec de la tentative. Si l’application démarre, mais ne parvient pas à établir un socket réseau de proximité, vérifiez que son interface utilisateur sur les deux appareils confirme cet échec.

Votre application doit être rédigée afin de tenir compte d’un scénario dans lequel une demande de démarrage d’une application homologue est rejetée.

Hh967765.wedge(fr-fr,WIN.10).gifTest des applications refusées par une action d’appuyer

  1. Installez votre application sur deux appareils. Démarrez l’application sur le premier appareil seulement.
  2. Sur l’appareil qui exécute votre application, effectuez une publication pour une connexion homologue. Pour cela, appelez la méthode Start.
  3. Posez les appareils l’un sur l’autre.
  4. Sur le deuxième appareil, assurez-vous qu’un message de notification est émis et invite l’utilisateur à démarrer ou installer l’application. Refusez la notification.
  5. Assurez-vous que l’application ne démarre pas sur le deuxième appareil et que l’interface utilisateur de l’application à l’origine de la requête reflète le refus de la requête.

Publication et abonnement pour les messages utilisant la classe ProximityDevice

Vous pouvez recourir à la classe ProximityDevice pour publier de petits messages entre les appareils durant une action d’appuyer. Les appareils doivent se trouver à portée du matériel de proximité que vous avez installé. (généralement, à une distance de 2 à 3 cm).

Pour publier un message durant une action d’appuyer, utilisez la méthode PublishMessage, PublishBinaryMessage ou PublishUriMessage sur l’appareil de publication et la méthode SubscribeForMessage sur l’appareil de réception. Pour consulter un exemple de publication et d’abonnement pour les messages, voir Démarrage rapide : publication et abonnement à des messages via une action d’appuyer ou Exemple de proximité dans la galerie d’exemples.

Hh967765.wedge(fr-fr,WIN.10).gifTest d’une application publiée et abonnée à un message

  1. Démarrez l’application de publication sur un appareil et l’application d’abonnement sur un autre. Il peut s’agir de la même application sur les deux appareils mais cela n’est pas une obligation.
  2. Mettez les applications dans un état de publication et de réception d’un message. Vous devez pour cela appeler l’une des méthodes de publication dans l’application de publication, puis la méthode SubscribeForMessage dans l’application de réception.
  3. Posez les appareils l’un sur l’autre.
  4. Si le message est transmis comme il se doit, assurez-vous alors que l’interface utilisateur dans l’application d’abonnement confirme que le message a été reçu. À titre d’option dans l’application de publication, vous pouvez appeler la surcharge de la méthode de publication dans laquelle vous trouverez le paramètre d’un gestionnaire d’événements de type MessageTransmittedHandler qui est appelé lors de la transmission du message. Dans le code de ce gestionnaire d’événements, vous pouvez mettre à jour l’interface utilisateur de l’application de publication pour refléter la transmission en bonne et due forme du message.
  5. Si la publication du message échoue ou si ce dernier n’est pas reçu, examinez le code de votre application afin d’identifier le problème. Pour connaître la procédure à suivre pour résoudre ce problème, voir "Un message publié et abonné n’est pas reçu" dans la section "Résolution des problèmes" de cette rubrique.
  6. Testez les deux applications pour vérifier qu’il est possible d’annuler leur état de publication et d’abonnement à un message. Sur l’appareil de publication, appelez la méthode StopPublishingMessage. Sur l’appareil d’abonnement, appelez la méthode StopSubscribingForMessage. Après avoir posé les deux appareils l’un sur l’autre, assurez-vous que le message n’est plus publié ni reçu.

Résolution des problèmes

Si le problème que vous rencontrez n’est pas répertorié ici, vous trouverez peut-être une réponse sur les forums des développeurs Windows.

Problème Procédure de résolution
Aucune réponse de l’action d’appuyer. Lorsque vous connectez des applications homologues via une action d’appuyer, ou bien procédez à une publication et un abonnement à un message lors d’une action de ce type, le code censé répondre à cette action n’est pas exécuté.

Assurez-vous que les appareils concernés par l’action d’appuyer sont placés à proximité, à une portée d’au moins 2 cm. Vous devrez peut-être aligner les appareils en fonction de l’emplacement du périphérique de proximité. Windows émet un son lorsque les appareils sont placés à proximité.

Vous pouvez utiliser les événements DeviceArrived et DeviceDeparted pour savoir à quel moment un appareil entre dans la zone de proximité ou en sort. Ajoutez des gestionnaires d’événements à votre code pour les événements DeviceArrived et DeviceDeparted. Si le code des gestionnaires d’événements est exécuté, c’est le signe que l’action d’appuyer a réussi. Si le code des gestionnaires d’événements pour les événements DeviceArrived et DeviceDeparted n’est pas exécuté, vous êtes peut-être confronté à un problème lié à votre matériel ou pilote de proximité.

Si votre application a recours à la classe PeerFinder pour créer une connexion déclenchée et si l’événement DeviceArrived est déclenché mais pas l’événement TriggeredConnection, vérifiez tous les éléments suivants :

  • Les deux instances de votre application ont appelé la méthode Start avant de se connecter par un appui.
  • Il n’existe aucune connexion de sockets ouverte entre les appareils depuis une action d’appuyer précédente. Si tel est le cas, assurez-vous que votre application appelle la méthode Close dans un socket qui n’est plus nécessaire. Si besoin, vous pouvez fermer une connexion de socket ouverte entre les instances homologues de votre application en quittant, puis en redémarrant l’application.
L’application ne démarre pas après un appui.

Assurez-vous que votre application s’exécute au premier plan sur au moins l’un des deux appareils sur lesquels vous avez effectué l’appui. Si tel est le cas et que l’application ne démarre pas après un appui, reportez-vous à la procédure à suivre pour le problème "Aucune réponse de l’action d’appuyer".

Si l’événement TriggeredConnection est déclenché dans l’application exécutée au premier plan mais qu’aucun message ne vous invite à démarrer l’application sur l’autre appareil impliqué dans l’action d’appuyer, assurez-vous que l’application est correctement installée. Si c’est le cas, elle démarrera à partir de la vignette de démarrage et se connectera via une action d’appuyer lors de son exécution au premier plan.
Aucun homologue n’est détecté lors de la navigation.

  • Assurez-vous que l’application s’exécute au premier plan et que vous avez appelé la méthode Start sur tous les appareils qui recherchent ou disposent d’une connexion. Si vous recherchez des applications homologues sur des appareils Windows, assurez-vous que la fonctionnalité Wi-Fi Direct est activée sur tous les appareils disponibles pour une connexion. Si vous recherchez des applications homologues sur des Windows Phone, assurez-vous que la fonctionnalité Bluetooth est activée sur tous les téléphones. Vous pouvez déterminer si l’ordinateur prend en charge la recherche d’homologues à l’aide de la propriété SupportedDiscoveryTypes.

  • Vérifiez que l’application de recherche ne dispose pas d’une connexion de socket ouverte provenant d’un précédent appel de la méthode ConnectAsync. Si tel est le cas, assurez-vous que votre application appelle la méthode Close dans un socket qui n’est plus nécessaire. Si besoin, vous pouvez fermer une connexion de socket ouverte entre les instances homologues de votre application en quittant, puis en redémarrant l’application.

  • La recherche d’homologues permet seulement de détecter des appareils homologues dotés de la même application de proximité. Assurez-vous que la même application fonctionne sur tous les appareils testés. Vous pouvez uniquement connecter deux appareils à la fois à l’aide de la méthode ConnectAsync.

  • Si les appareils que vous essayez de connecter sont joints à un domaine, une stratégie de domaine risque d’empêcher la création d’une connexion ou la fermeture d’une connexion existante. Si la connexion aboutit pour des appareils qui ne sont pas joints au domaine et échoue pour des appareils qui le sont, passez en revue la stratégie de pare-feu de votre domaine.

  • Si vos connexions échouent sur un PC, une limitation de votre matériel Wi-Fi Direct en est peut-être la cause. Essayez d’exécuter l’application sur les deux PC avec la communication radio sans fil activée mais sans connexion aux réseaux sans fil.
Une tentative de connexion par un appui échoue au bout d’une minute.

Vérifiez les paramètres sans fil des deux appareils impliqués dans l’action d’appuyer et assurez-vous que leurs fonctionnalités de communication radio Wi-Fi et Bluetooth sont activées. Si l’un des appareils ne dispose pas d’un périphérique sans fil prenant en charge la fonctionnalité Wi-Fi Direct ou une communication radio Bluetooth, assurez-vous que les deux appareils sont connectés au même réseau.
Un message publié et abonné n’est pas reçu. Quand vous publiez des messages et que vous vous abonnez à ces derniers, l’appareil d’abonnement ne reçoit pas le message publié.

Sur l’appareil de publication, vous pouvez appeler la surcharge de la méthode PublishMessage, PublishUriMessage ou PublishBinaryMessage dans laquelle vous trouverez le paramètre d’un gestionnaire d’événements de type MessageTransmittedHandler qui est appelé durant la transmission du message. Si l’appel à la méthode de publication aboutit et que le code inclus dans le gestionnaire d’événements MessageTransmittedHandler s’exécute, c’est la preuve que le message a bien été transmis.

Sur l’appareil d’abonnement, vérifiez que la valeur du paramètre messageType que vous avez transmis à la méthode SubscribeForMessage correspond à la valeur du paramètre messageType transmis à la méthode PublishMessage ou PublishBinaryMessage (pour la méthode PublishUriMessage, la valeur messageType est toujours WindowsUri). Les valeurs des types de message respectent la casse.

 

Rubriques associées

Prise en charge de la fonctionnalité de proximité et du geste tactile

Démarrage rapide : connexion d’applications à l’aide d’un geste tactile ou de la navigation

Démarrage rapide : publication et abonnement à des messages à l’aide d’un geste d’appui

Recommandations et liste de vérification sur la proximité

Windows.Networking.Proximity namespace

Exemples

Exemple de proximité