Archives de catégorie : Windows Phone

Articles traitant de la plateforme Windows Phone.

Article BLE dans Programmez!, partie 3

Bonjour à tous,

Le dernier numéro du mensuel Programmez! (189) est en kiosque.

Programmez189

Vous trouverez en page 56 la partie 3 d’un article sur l’utilisation du Bluetooth Low Energy dans les applications universelles.

Article BLE partie 3

Cet article reprend les éléments de la session du même nom que j’ai jouée aux TechDays cette année.

Alors bonne lecture et amusez-vous bien avec le Bluetooth Low Energy et le SensorTag 🙂

Stéphane Sibué

Empreinte Guyzmo 360

Article BLE dans programmez, partie 2

Bonjour à tous,

Le dernier numéro du mensuel Programmez! (186) est en kiosque.

Programmez186

Vous trouverez en page 76 la partie 2 d’un article sur l’utilisation du Bluetooth Low Energy dans les applications universelles. La partie 1 se trouvant dans le numéro 185 de programmez (logique me direz-vous).

Article BLE partie 2

Cet article reprend les éléments de la session du même nom que j’ai jouée aux TechDays cette année.

Alors bonne lecture et amusez-vous bien avec le Bluetooth Low Energy et le SensorTag 🙂

Stéphane Sibué

Empreinte Guyzmo 360

Article sur le Bluetooth Low Energy dans Programmez!

Bonjour à tous,

Le dernier numéro du mensuel Programmez! (185) est en kiosque.

Programmez185

Parmi les très bons articles de ce dernier numéro, vous trouverez page 56 un article de GUYZMO sur la mise en œuvre du Bluetooth Low Energy dans les applications Windows Universelle. Cet article est découpé en deux parties, la seconde partie étant prévue pour le numéro de fin mai.

Article BLE partie 1

Cet article reprend les éléments de la session du même nom que j’ai jouée aux TechDays cette année.

Alors bonne lecture et amusez-vous bien avec le Bluetooth Low Energy et le SensorTag 🙂

Stéphane Sibué

Empreinte Guyzmo 360

Une manette de jeu réalisée avec un SensorTag

Si vous avez suivi un peu nos aventures vous savez que chez GUYZMO nous aimons beaucoup le SensorTag de Texas Instruments.

ti-sensortag

Après la station météo présentée aux TechDays lors de notre session sur « le Bluetooth Low Energy dans les applications Windows » qui utilisait les capteurs de pression atmosphérique, de température et d’humidité du SensorTag, je me suis demandé comment utiliser, de manière ludique, ses boutons de commande (2 boutons placés sur la partie haute du SensorTag) et ses accéléromètres.

J’avais développé un petit jeu pour Windows Phone, dans lequel le joueur pilote un petit vaisseau spatial devant tirer sur une multitude d’astéroïdes sans les percuter, et ce en avançant dans des niveaux de plus en plus difficiles (très classique me direz vous mais très amusant à coder).

J’ai donc adapté ce jeu pour utiliser un bouton de commande du SensorTag pour tirer, et ses accéléromètres pour déplacer le vaisseau. Le résultat final dans cette petite vidéo :

Stéphane Sibué

 

Bluetooth Low Energy sous Windows Phone : Différences entre Silverlight et WinRT

Comme vous le savez très certainement, si vous suivez un peu ce blog, j’ai présenté une session aux TechDays 2015 sur le Bluetooth Low Energy dans les applications Windows (sous entendu applications universelles Windows Store et Windows Phone), vous trouverez d’ailleurs quelques infos ici.

Je suis en train de préparer un article complet qui reprendra chaque point de cette session, mais en attendant je vous propose de voir quelques différences entre la gestion du BLE en WinRT et en Silverlight.

Actuellement vous pouvez développer des applications Windows Store uniquement en utilisant Windows RT, alors que pour Windows Phone vous avez le choix entre Windows RT et Silverlight.

Chose importante aussi, BLE n’est supporté qu’à partir de Windows Phone 8.1 et Windows 8.1 donc pour les versions précédentes on se contentera du Bluetooth classique.

Dernièrement j’ai voulu ajouter des fonctions BLE (Bluetooth Low Energy) dans une applications Windows Phone Silverlight et je me suis rendu compte de 2 choses importantes :

  • Les fonctions BLE en WinRT sont accessibles depuis SL mais ne fonctionnent pas.
  • Les fonctions BLE incluses dans SL fonctionnent mais sont différentes de celles de WinRT

Capabilities

Elles doivent être placées au même endroit, dans le fichier « Package.appxmanifest » du projet, qu’on soit en SL ou en WinRT.

Par exemple, déclaration de 2 GATT services :

   <Capabilities>
    <Capability Name="internetClient" />
    <m2:DeviceCapability Name="bluetooth.genericAttributeProfile">
      <m2:Device Id="any">
        <m2:Function Type="serviceId:0000ffe0-0000-1000-8000-00805f9b34fb"/>
        <m2:Function Type="serviceId:f000aa50-0451-4000-b000-000000000000"/>
      </m2:Device>
    </m2:DeviceCapability>
  </Capabilities>

Connexion à un service

Le code de connexion à un service (qui aura au préalable été déclaré dans les capabilities sinon vous n’aurez aucune possibilité de vous y connecter) est légèrement différent en Silverlight et en WinRT.

Voici une fonction qui recherche à se connecter à un service avec la vérification que le serveur est un SensorTag (code en WinRT puis en Silverlight) :

WinRT

N’oubliez pas de déclarer les espaces de noms suivants :

Windows.Devices.Bluetooth.GenericAttributeProfile
Windows.Devices.Enumeration

private async Task<GattDeviceService> GetDeviceService(Guid service)
{
    var filter = GattDeviceService.GetDeviceSelectorFromUuid(service);
    var deviceInfos = await DeviceInformation.FindAllAsync(filter);

    foreach (var deviceInfo in deviceInfos)
    {
        if (deviceInfo.Name == "TI BLE Sensor Tag")
        {
            // On a trouvé un SensorTag qui implémente le service recherché
            return await GattDeviceService.FromIdAsync(deviceInfo.Id);
         }
     }

    return null;
}

Silverlight

N’oubliez pas de déclarer les espaces de noms suivants :

Windows.Devices.Enumeration
Windows.Devices.Bluetooth
Windows.Devices.Bluetooth.GenericAttributeProfile

private async Task<GattDeviceService> GetDeviceService(Guid service)
{
    var deviceInfos = await DeviceInformation.FindAllAsync(BluetoothLEDevice.GetDeviceSelector());

    foreach (var deviceInfo in deviceInfos)
    {
        if (deviceInfo.Name == "TI BLE Sensor Tag")
        {
            // On a trouvé un SensorTag qui implémente le service recherché

            var bluetoothDevice = await BluetoothLEDevice.FromIdAsync(deviceInfo.Id);
            var gattService = bluetoothDevice.GetGattService(service);

            return gattService;
        }
    }

    return null;
}

Accès aux caractéristiques

Pour ce qui est d’accéder aux caractéristiques, le principe est le même en WinRT et en Silverlight.

Par contre, en Silverlight la manipulation des buffers est moins simple car les classes DataReader et DataWriter de Silverlight ne travaillent pas directement sur un IBuffer qui est systématiquement utilisé pour lire et écrire des données au niveau des caractéristiques.

Dans Silverlight le plus simple est de passer par un tableau de bytes en utilisant les méthodes ToArray() pour passer du IBuffer au tableau et AsBuffer() pour passer du tableau de bytes au IBuffer.

Note : Pour avoir accès à la méthode AsBuffer depuis un tableau de bytes vous devez déclarer l’espace de nom System.Runtime.InteropServices.WindowsRuntime, que vous soyez en WinRT ou en Silverlight.

 

Conclusion

Les différences ne sont pas énormes mais suffisamment importantes pour dérouter le développeur qui débute dans ce genre de développement.

 

Stéphane Sibué

 

 

 

 

Session Guyzmo aux TechDays 2015

Cette année, les TechDays se dérouleront au Palais des Congrès à Paris les 10, 11 et 12 février 2015.

Ce sera encore une fois l’occasion de participer à plus de 300 sessions techniques, de rencontrer les acteurs des technologies Microsoft, avec en prévision plus de 18000 visiteurs sur 3 jours.

Le thème cette année est L’Ambient Intelligence :

L’Ambient Intelligence est à la fois une vision et déjà une réalité, rendue possible par les avancées technologiques de l’électronique, du cloud, du big data et du machine learning.  Une vision d’un monde dans lequel la technologie anticipera nos besoins, voire nos intentions.  Une réalité car les applications et les objets qui tirent profit de nos actions et des informations à notre disposition existent déjà et nous permettent de faire plus et mieux.

Aux TechDays 2015, l’Ambient Intelligence sera au cœur des sessions et de la zone d’exposition. Plénières, keynotes, retours d’expériences, présentations de projets concrets, nous vous montrerons comment nos technologies, celles de nos partenaires mais aussi du monde open source vous permettront de :

  • Concevoir et développer des applications et services intelligents,
  • Construire et opérer en toute sécurité les infrastructures requises,
  • Révéler les nouveaux usages professionnels et personnels et les opportunités business liées.

Et puis, l’Ambient Intelligence, c’est aussi ce qui se passe aux TechDays… lors de chaque rencontre, de chaque interaction, de chaque étincelle qui naîtra de votre présence à tous.

Cette année encore j’aurai la joie d’animer une session technique liée au développement Windows Phone dont voici le contenu :

Bluetooth Low Energy dans les applications Windows

Le Bluetooth Low Energy est un des protocoles clé de l’Internet des objets. Montres, bracelets, ampoules et autres portes clés l’exploitent à merveille. Venez en comprendre ses principes, son fonctionnement et sa mise en oeuvre au sein d’une application Windows Universelle au travers d’un exemple très simple que vous pourrez reproduire chez vous à moindre frais. Nous développerons une station météo connectée avec l’application mobile qui l’accompagne.

Comme expliqué dans le descriptif de la session, nous allons créer une petite station météo grâce à un petit appareil bien sympathique de chez Texas Instruments, le SensorTag. Il permet de tester divers capteurs (température, humidité, pression atmosphérique, etc) et discute en Bluetooth Low Energy.

ti-sensortag

Les données fournies par le SensorTag seront traitées et affichées par une petite application universelle (Windows Phone + Windows 8), ce qui nous permettra d’aborder tous les aspects de la communication BLE sous Windows RT.

Alors venez nombreux à cette session, ce sera une magnifique occasion d’échanger tous ensemble sur le développement d’applications mobiles et plus particulièrement sur l’utilisation du BLE dans vos applications Windows.

Stéphane Sibué

Empreinte Guyzmo 360

 

 

Communiquer avec un GPS Bluetooth, quelques améliorations

Dans un précédent article j’ai abordé la communication avec un périphérique Bluetooth en utilisant comme exemple la communication avec un GPS.

Comme j’étais en train de découvrir la nouvelle manière de lire des données en provenance d’un socket (StreamSocket) je n’avais pas utilisé la manière la plus simple ni la plus efficace.

Dans ce nouvel article, je vais apporter quelques améliorations à la méthode utilisée.

En creusant encore un peu le sujet, je me suis rendu compte que ma méthode était loin d’être la meilleure. Et tant mieux car perso je n’en étais pas super satisfait.

En 1er lieu, il faut passer par un DataReader pour lire les données en provenance du StreamSocket. On donne au DataReader l’InputStream utilisé par le StreamSocket pour collecter les données entrantes et on paramètre de DataReader pour qu’il effectue une lecture partielle des données.

DataReader wReader = new DataReader(_StreamSocket.InputStream);
wReader.InputStreamOptions = InputStreamOptions.Partial;

En d’autres termes, si on demande de lire 100 octets et qu’il n’y en a que 50 dans le buffer d’entrée, le DataReader va lire les 50 octets et rendre la main au lieu d’attendre la vie des rats que les 100 octets soient effectivement disponibles. Ca arrange bien nos affaires cette histoire.

La lecture en elle-même est très simplifiée. Il suffit de dire combien on veut lire d’octets maximum et on reprend la main quand on a lu au maximum ce nombre d’octets. Simple et rapide.

La fonction de lecture est asynchrone, donc pour l’attendre on n’oublie pas de placer le petit await qui va bien devant. La fonction retourne le nombre d’octets effectivement lus.

Si elle retourne zéro c’est que rien n’était disponible dans le buffer d’entrée. Suivant les matériels connectés ça peut vouloir dire qu’il ne cause plus pour le moment (il boude par exemple) ou alors qu’il n’est plus connecté. Dans le cas d’un GPS, qui est je vous le rappelle un appareil très bavard, le fait de ne plus recevoir de données signifie souvent qu’il n’est plus là pour le faire.

// Lecture de 300 octets
uint r = await wReader.LoadAsync(300);

Une fois qu’on a des données disponibles dans le buffer d’entrée, il suffit d’aller les récupérer de la manière qui convient le mieux en utilisant le DataReader et ses fonctions de récupération (ReadByte, ReadBytes, ReadDouble, etc…). C’est lui qui s’occupe d’aller puiser le bon nombre d’octets dans le buffer d’entrée pour récupérer les informations dans le format que vous souhaitez (sympa le mec).

Dans le cas du GPS nous devons récupérer les données sous la format de caractères ASCII. Malheureusement la méthode ReadString ne convient pas car elle lit la chaîne en UTF8 ou en Unicode, mais ne sais pas le faire en ASCII. En fait le format ASCII a été retiré des formats proposés dans System.Text.Encoding. Quelle idée ???

Donc nous allons récupérer les octets comme si c’était de simples caractères ASCII et construire une chaîne ASCII, à la mano, comme le faisait mon grand père.

// On prépare le buffer de réception
// La variable r contient le nombre d'octets lus du StreamSocket

byte[] wBuffer = new byte[r];

// On récupère les données 

wReader.ReadBytes(wBuffer);

// On transforme ces données en string ASCII

string wString = "";

for (int i = 0; i < r; i++)
{ 
    wString += (char)wBuffer[i];
}

// Dans wString on a maintenant les données lues sous forme d'une chaîne de caractères

Ensuite il suffit de traiter ces informations comme dans l’article précédent pour afficher les trames NMEA envoyées par le GPS.

Il suffit alors de reboucler pour lire le flot suivant de caractères et le tour est joué. Plus besoin de timer pour effectuer la lecture à intervalles réguliers. On est toujours en mode pooling car nous ne sommes pas notifié de la disponibilité de nouveaux octets dans le buffer d’entrée, mais ce pooling-ci est plus « souple » que celui que je vous avais précédemment proposé.

Idéalement, il faudrait gérer un timeout. En effet, comme expliqué un peu plus haut, quand le périphérique est déconnecté, il cesse d’envoyer des données, mais aucune erreur n’est levée au moment où l’on essaye de notre coté de lire de nouvelles données, on n’a seulement comme indice le fait que la fonction de lecture du DataReader retourne zéro.

Au bout d’un certain temps, il sera donc nécessaire d’en conclure que la liaison est rompue. La durée de ce timeout dépendra du comportement « normal » du périphérique auquel vous êtes connectés. Par exemple, pour le GPS Hollux que j’ai utilisé, une absence de données pendant plus d’une seconde n’est pas normale, le timeout sera donc compris en 1000 et 1500 millisecondes.

Si j’en ai le courage, j’ajouterai ce timeout dans un prochain article. En tous cas, si cela vous intéresse, n’hésitez pas à me le demander, ce sera pour moi la meilleure des motivations.

Stéphane Sibué

Communiquer avec un GPS Bluetooth sous Windows Phone

A l’époque de Windows Mobile, communiquer avec un périphérique en utilisant une liaison série était quelques chose de très simple à mettre en œuvre. Le système d’exploitation intégrait tout ce qu’il fallait pour ouvrir un port série et permettre l’envoi et la réception de données par ce canal. Simple, ouvert, pratique.

Dans les 1ères versions de l’OS mobile de Microsoft, du temps de Pocket PC 2000 sous Windows CE 3 par exemple, la liaison série était physiquement réelle. On branchait un câble qui reliait le PDA avec le périphérique, comme on peut le voir dans cet exemple de borne interactive animée par un Pocket PC que j’ai mis en ligne en 2001. Le programme était réalisé en eVB (ça ne me rajeunit pas cette histoire).

Ensuite, avec la démocratisation du Bluetooth, les machines ont été en mesure de créer des liaisons séries virtuelles, le câble ayant été remplacé par les ondes radio. Classiquement, à cette époque, on se connectait avec des GPS Bluetooth car les machines sous Windows Mobile n’intégraient pas encore de puce GPS, il fallait donc passer par des appareils externes pour être en mesure de proposer une géolocalisation et de la carto.

A l’époque j’avais d’ailleurs écrit un article sur la manière de se connecter à un GPS et être en mesure de décoder les trames NMEA qu’il crachait périodiquement et pour le TechDays 2008 j’avais présenté une application permettant de prendre des photos géolocalisées avec la possibilité de les afficher sur une carte. Et oui à l’époque ça en a impressionné plus d’un, maintenant c’est d’une grande banalité je vous l’accorde.

Pour moi la sortie de Windows Phone fût un grand choc. Belle plateforme, belles et puissantes machines, fluidité, design moderne, en gros que du bonheur par rapport à la plateforme Windows Mobile. Mais en creusant un peu, quel retour en arrière sur certains points ! Certes les machines intégraient nativement une puce GPS et le SDK permettait d’en tirer partie, mais impossible par exemple d’ouvrir une liaison série (réelle ou virtuelle), impossible de créer un socket serveur, impossible de faire plein de choses qui étaient devenues si naturelles avec l’ancienne plateforme… Allez expliquer ça à vos clients qui vous demandent de porter leurs anciennes applications Windows Mobile vers Windows Phone. Dans certains cas impossible de le faire, et on passe donc à Android où là il n’y a rien qui s’y oppose.

Avec le recul je comprends très bien pourquoi les choses ont été faites comme ça, mais je dois bien avouer qu’à l’époque MS a pourri une partie de mon business avec ces choix !

Dans certains cas il est indispensable d’avoir plusieurs GPS en même temps. Par exemple, si vous faites du GPS différentiel, vous ne pouvez vous contenter d’utiliser celui inclus dans le device, vous devez collecter les données de plusieurs GPS et effectuer des traitements en temps réel pour arriver à une précision de positionnement de l’ordre du cm par exemple. De plus vous ne pouvez vous contenter de récupérer simplement la position (latitude, longitude), vous devez aussi récupérer des données très importantes sur le niveau de précision, le nombre de satellites en vue et j’en passe. Je ne vais pas entrer dans le détail du GPS différentiel ce n’est pas le but de cet article.

Donc avec Windows Phone, si vous voulez faire du GPS différentiel vous êtes cuit. Sauf depuis la sortie de Windows Phone 8 qui a ouvert encore un peu plus le périmètre des libertés anciennes (Windows Mobile) retrouvées.

Avec Windows Phone 8 vous avez la possibilité de créer un socket entre votre application et un périphérique Bluetooth. Donc pour faire simple, on peut communiquer très facilement en Bluetooth avec par exemple… un GPS, et même plusieurs GPS en même temps ! Ca y est, 3 ans après la sortie de la plateforme Windows Phone, je peux dire à mes clients qu’il peuvent abandonner Android et revenir dans le droit chemin sous Windows Phone ! Sauf que pour eux maintenant c’est trop tard, ils sont passés à Android et ne reviendront pas en arrière. En effet il n’ont pas la capacité financière de faire redévelopper toutes les 5 minutes leurs applications mobiles.

Je vais donc dans cet article vous montrer comment dialoguer avec un GPS en Bluetooth et vous allez voir que c’est assez simple à faire.

Le petit programme GpsBT que j’ai réalisé pour l’occasion permet de faire 3 choses :

  1. Lister les appareils liés en Bluetooth
  2. Sélectionner un appareil et s’y connecter
  3. Afficher les trames NMEA envoyées par le GPS

Les sources de GpsBT sont disponibles ici.

1/ Les droits

La 1ère chose à faire, c’est de donner à votre application les droits pour utiliser les fonctions Bluetooth :

ID_CAP_PROXIMITY

ID_CAP_NETWORKING

2/ Lister les appareils liés

Il faut partir à la découverte des appareils liées. Ces appareils sont ceux qui sont listés dans l’écran des settings du Bluetooth et qui ont été liés à votre téléphone par une opération d’appairage. On ne peut se connecter qu’avec un appareil qui a été au préalable lié et impossible dans l’état actuel du SDK de provoquer par programme ce lien.

        private async void BouPeerDiscovery_Click(object sender, RoutedEventArgs e)
        {
            BouPeerDiscovery.IsEnabled = false;

            PeerFinder.AlternateIdentities["Bluetooth:Paired"] = "";

            try
            {
                var wPairedDevices = await PeerFinder.FindAllPeersAsync();
                this.ViewModel = new MainPageViewModel(wPairedDevices.ToList());
                BouPeerDiscovery.Visibility = System.Windows.Visibility.Collapsed;
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Message, "Peer Discovery", MessageBoxButton.OK);
                BouPeerDiscovery.IsEnabled = true;
            }
        }

La liste des appareils liés est retournée par la fonction PeerFinder.FindAllPeerAsync. Dans mon exemple, la liste est fournie au ViewModel de la page pour un affichage dans une liste comme dans l’écran suivant :

Le GPS que j’utilise est le Holux GR-230, c’est donc à lui que je vais essayer de me connecter. Il ne faut pas oublier au préalable de le mettre en route, bien sûr.

3/ Connexion à un appareil

La fonction permettant de lister les appareils disponibles retourne pour chacun d’entre eux un objet de type PeerInformation. Parmi les informations disponibles, on a le DisplayName qui est le nom en clair (celui que j’utilise dans la liste), et le HostName qui sera utilisé pour effectuer la connexion.

La connexion est réalisée via un objet de type « StreamSocket » en utilisant sa méthode asynchrone « ConnectAsync » avec en premier paramètres le HostName provenant du PeerInformation de l’appareil auquel on veut se connecter et la chaîne 1 en second paramètre (je ne sais pas vraiment à quoi correspond ce second paramètre, dans tous les exemples de la documentation la valeur utilisée est la chaine 1 alors va pour ça).

        public async Task ConnectAsync(PeerInformation wPeer)
        {
            // Si un précédent device était déjà connecté, on débranche

            if (_StreamSocket != null)
            {
                _ScanGpsTimer.Stop();

                _StreamSocket.Dispose();
                _StreamSocket = null;
            }

            // On essaye de se connecter au device

            _StreamSocket = new StreamSocket();

            try
            {
                await _StreamSocket.ConnectAsync(wPeer.HostName, "1");

                // Pas d'erreur ?
                // Alors c'est qu'on est connecté
                // On peut mettre en place le scan des données qui arrivent du device

                _CurrentGpsInput = "";
                this.DeviceName = wPeer.DisplayName;
                _ScanGpsTimer.Start();
            }
            catch (Exception ex)
            {
                // Erreur pendant la connexion

                _StreamSocket = null;
                return ex;
            }

            return null;
        }

Ma petite fonction de connexion, placée dans le ViewModel de la page, retourne l’erreur rencontrée en cas de problème ou null si tout c’est bien passé.
Si la connexion se passe bien, on passe en mode pooling dans lequel on va lire à intervalle régulier le contenu du buffer d’entrée du StreamSocket. Si des données sont disponibles, elles sont lues et partant du principe que ce sont des trames NMEA, elles sont « découpées » pour être affichées dans une liste.

C’est un DispatcherTimer qui s’occupe d’effectuer les lectures à intervalles régulier :

        private async void OnScanGpsTimerTick(object sender, EventArgs e)
        {
            if (_StreamSocket != null)
            {
                _ScanGpsTimer.Stop();

                // Lecture des données

                var wBuffer = new Windows.Storage.Streams.Buffer(100);
                await _StreamSocket.InputStream.ReadAsync(wBuffer, 100, Windows.Storage.Streams.InputStreamOptions.None);

                if (wBuffer.Length > 0)
                {
                    // On a bien des données

                    using (var wReader = DataReader.FromBuffer(wBuffer))
                    {
                        // On prépare le buffer de réception 

                        byte[] wBuffer2 = new byte[wBuffer.Length];

                        // On récupère les données 
                        wReader.ReadBytes(wBuffer2);

                        // On transforme ces données en string

                        string wString = System.Text.Encoding.UTF8.GetString(wBuffer2, 0, wBuffer2.Length);

                        // On ajoute ces données aux trames générales reçues du GPS

                        _CurrentGpsInput += wString;

                        // On essaye de découper la trame générale en lignes NMEA

                        int p;

                        do
                        {
                            // On recherche les caractères CRLF

                            p = _CurrentGpsInput.IndexOf("\r\n");

                            if (p > -1)
                            {
                                // On récupère le début (avant les caratères CRLF)

                                string wDebut = _CurrentGpsInput.Substring(0, p);

                                // On enlève cette partie de la trame générale

                                _CurrentGpsInput = _CurrentGpsInput.Substring(p + 2);

                                // Généralement une trame NMEA valide commence par $GP

                                if (wDebut.StartsWith("$GP"))
                                {
                                    // On ajoute la partie à la liste des trames NMEA

                                    this.GpsNmea.Add(wDebut);

                                    // On ne garde que les 25 dernières trames NMEA dans la liste

                                    while (GpsNmea.Count > 25) { GpsNmea.RemoveAt(0); }
                                }
                            }

                        } while (p > -1);
                    }
                }
                else
                {
                    // Aucune donnée n'a été lue, si ça dure trop longtemps cela voudra dire
                    // Que le device ne communique plus ou qu'il n'est plus connecté
                    // Dans la vraie vie, c'est un cas qu'il faut traiter
                }

                _ScanGpsTimer.Start();
            }
        }

Voilà, la boucle est bouclée, nous avons réalisé toutes les opérations pour se connecter à un GPS Bluetooth depuis un device Windows Phone 8.

Comme vous pouvez le constater, c’est très simple à mettre en œuvre. Mon seul regret étant de devoir effectuer du pooling pour récupérer les données.

Il y a peut-être le moyen de se « brancher » sur un événement du StreamSocket ou du InputStream sous-jacent, mais je dois vous avouer que je n’ai pas encore pris le temps de creuser cette piste pour le moment.

Stéphane Sibué