La poursuite GPS côté téléphone mobile

--ooOoo--

Pour la "Poursuite GPS" côté téléphone mobile, il s'agit d'implanter une petite application dont l'objectif est d'assurer tout simplement deux fonctions en temps réel :

 En dehors de la familiarisation avec la programmation en langage Java et l'utilisation d'Eclipse, cette petite application peut présenter quelques intérêts à plusieurs titres dans l'emploi de fonctions, ici assez élémentaires :

Le diagramme en étoile de la figure ci-dessous illustre le principe de fonctionnement général de l'application que l'on va de réaliser :

I - Les outils de programmation du téléphone mobile :

Le marché propose une multitude de téléphones portables se caractérisant par les systèmes d'exploitation qui les gèrent. Donc, dans l'absolu, il faudrait réaliser la programmation de la poursuite sur tous les systèmes disponibles. Tel n'est pas mon but car l'exercice est purement ludique pour satisfaire ma curiosité et surtout, comme je le souhaite, celle de mes petits-enfants. Pour programmer cette petite application, il convient donc de choisir un type de téléphone. Je me suis porté sur les "smartphones" gérés par le système d'exploitation "Androïd". Je compte en acquérir un très bientôt à l'expiration de mon engagement d'abonnement.

Pour ce faire, un kit de développement Android est obligatoire car les procédures en lignes de commandes m'ont paru assez laborieuses. J'ai donc téléchargé puis installé sur mon ordinateur portable le "Android Development Tools" (ADT) qui intègre une plateforme "Eclipse" d'aide et d'assistance à la programmation en différents langages et en particulier le langage "Java" :

adt-bundle-windows-x86-20130729

Cette plateforme permet l'écriture de la programmation et simule le fonctionnement du téléphone, l' "Android Virtual Device" (AVD) qui évite d'utiliser le téléphone mobile durant toute la phase de mise au point ou en attendant d'en avoir un.

Sur la toile, il y a une foule de tutoriels, de forums et cours en ligne qui permettent l'apprentissage à l'utilisation d'Android. Très souvent, les informations sont malheureusement parcellaires et l'apprentissage est parfois un peu laborieux. Mais avec de la persévérance, on y arrive quand même. Je n'ai quand même pas l'impression que les développeurs de ces systèmes aient choisi délibérément les solutions et les procédures les plus aisées, ce n'est pas dans l'air du temps. D'ailleurs, cela se confirme en voyant justement la multitude de tutoriels, de forums, de cours sur le sujet et principalement le nombre de forumeurs qui ont ou qui ont eu les mêmes difficultés que moi.

Bref !...Passons donc maintenant aux faits ...

I.1 - La capture de la trajectoire du compétiteur :

I.1.1 - L'affichage sur le téléphone mobile :

Une trajectoire est définie par une suite de points de localisation que le GPS obtient en interrogeant la constellation de satellites du système de géolocalisation. Chaque point de localisation est donc définit principalement par :

1. sa longitude,
2. sa latitude,
3. son altitude.

Pour les besoins de l'application de classements de la compétition, on a besoin de connaître l'heure à la seconde près de la capture du point de géolocalisation. En effet, grâce aux heures associées aux points, il sera facile de déterminer l'heure exacte de franchissement de la ligne de départ, celle du franchissement de la ligne d'arrivée et de vérifier que les points de virage ont été contournés dans les règles des procédures imposées.

Plusieurs choix s'imposent :

Que choisir donc ?

hh:mm:ss.d,±aaa.bbbbb,±ccc.ddddd,eeee.f

Pour permettre l'utilisation de la poursuite GPS à d'autres fins, l'application téléphone doit permettre de saisir une adresse courrielle quelconque. Pour régler la fréquence d'envoi des courriels, elle doit permettre de spécifier la taille maximale des courriels ainsi que l'intervalle de temps en secondes qui sépare deux prises de mesure de géolocalisation.

Pour permettre enfin l'envoi automatique de courriels, il faut saisir un certain nombre de paramètres conformes à la configuration d'un compte dans le téléphone et aux caractéristiques du fournisseur d'accès.

L'image ci-dessous, à gauche,  montre l'écran principal de l'application lors de la toute première exécution. Il n'y a donc pas de fichier de sauvegarde. Un écran secondaire, l'image de droite sera alors proposée directement à l'utilisateur pour la saisie de tous les paramètres de configuration.

Écran principal de l'application lors de la toute première exécution

Écran de saisie des paramètres que l'utilisateur doit obligatoirement saisir

Signification des paramètres de configuration :

La figure ci-dessous montre, à gauche, un exemple de saisie des paramètres dans l'écran de saisie des paramètres de l'application. L'utilisateur valide ensuite sa saisie et l'application affiche l'écran de droite en attente du démarrage de la géolocalisation.

Exemple de saisie dans l'écran secondaire de l'application

Écran principal proposé par l'application avant de démarrage de la géolocalisation

Avant le début de l'épreuve, le concurrent saisit donc l'adresse courrielle du poste de traitement de la compétition, la taille maximale en caractères du corps du message ainsi que le cycle en secondes de prise de localisation indiqués par le directeur de la compétition.

Du côté poste de traitement de la compétition, au moment de l'inscription des concurrents, le directeur de la compétition enregistre l'adresse courrielle du téléphone correspondant à son numéro pour identifier l'envoi.

Tout au long du parcours, l'affichage des points de géolocalisation est mis à jour à chaque fin du cycle défini. Une version plus sophistiquée pourrait afficher une carte, IGN par exemple, centrée sur le point capturé avec une trace du parcours. Cette solution, plus complexe à réaliser, me paraît plus publicitaire qu'efficace vu la taille réduite des écrans des téléphones mobiles et puis... en vol, surtout en montagne, on regarde avec attention ce qu'il se passe dehors, et, dedans, très furtivement, les instruments qui doivent confirmer les sensations !.... non ?

Pour démarrer le développement de l'application, il a été question, pour commencer, de modifier un peu la configuration du programme "Hello World" chargé lors de l'ouverture d'un nouveau projet à titre d'exemple.

L'image ci-dessous représente les ajouts à appliquer à la configuration standard "Hello World!"  de base c'est à dire :

Quelques remarques toutes personnelles :

Remarque 1 : La plateforme Android/Eclipse sépare la présentation de l'écran de la programmation sur l'écran. Ceci est en effet très intéressant. La mise en page de l'écran est assurée par un "layout" qui veut dire "agencement", "mise en page", dans un fichier de type ".xml". La programmation est réalisée dans un fichier de type ".java".
     On peut donc préparer son écran sans avoir à commencer la programmation.     

Remarque 2 : La plateforme propose plusieurs types de "layout", "FrameLayout, LinearLayout, RelativeLayout et GridLayout). Par défaut au moment de la création d'un projet, il est créé un "<RelativeLayout>". Les champs sont positionnés les uns par rapport aux autres ainsi qu'aux limites et aux axes milieu de l'écran. C'est très séduisant quand on agence l'écran pour la première fois. Mais cela devient galère quand il faut modifier leur disposition après coup. En effet, quand on déplace un champ, tous les champs qui lui sont liés se déplacent en même temps, même ceux qui ne devraient pas l'être logiquement.
     On aurait pu penser qu'avec le type "GridLayout" il aurait été possible de positionner indépendamment les champs sur un carreau d'une grille à moins de jouer peut-être sur une palanquée de paramètres. Eh bien, non !...
     Pour moi, cela ne méritait pas la peine d'insister puisque la composition de l'écran était simple. Mais malgré tout, cela a été une petite galère en modification !... Je serais assez sévère envers cette manière d'éditer. Il y a quand même plus simple et plus pratique. Mais bon !...

     Dommage !... le principe d'aide de Euclide/Android est bien vu. Il manque tout simplement un peu d'intuitivité. En effet, un applicatif est d'autant de bonne qualité qu'il est auto-informatif. L'utilisateur devrait pouvoir anticiper naturellement les procédures. Sans cela, même s'il est superpuissant, le logiciel  n'emballe pas les foules, si j'en juge par le nombre de forums, de cours et de tutoriels tout azimut jusqu'à la manifestation de gens excédés qui pestent contre cet état de fait...

Un petit résumé de la procédure en forme de cahier des charges :

En entrant dans l'application pour la toute première fois, l'application force l'utilisateur à saisir les paramètres :

• l'identifiant du serveur d'envoi de courriel chez le fournisseur (forme : "smtp.fournisseur.ext"),
• le mot de passe du serveur,
• l'adresse courrielle du compte déclaré dans le téléphone qui sera l'expéditeur des courriels de la forme "compte@fornisseur.ext",
• le mot de passe du compte,
• l'adresse courrielle du concentrateur de la forme "nom_compte_expediteur@fornisseur.ext",
• l'intervalle de temps en secondes entre deux prises de mesure de la géolocalisation,
• la taille maximale en octets du tronçon de trajectoire à envoyer dans un courriel.

La validité des paramètres est vérifiée. Toute erreur cantonne naturellement l'utilisateur sur l'écran de saisie. Un clic sur le bouton "Valider" lance la sauvegarde des paramètres pour un usage ultérieur et retourne à l'écran principal de l'application où seuls les boutons "Départ" et "Sortie" sont activés.

Lors des exécutions ultérieures, l'utilisateur n'est plus obligé de passer par le bouton "Paramètres" s'il est sûr de ses paramètres saisis lors de l'exécution précédente.

Un clic sur le bouton "Départ" lancera les actions suivantes :

• désactivation des boutons "Départ" et "Sortie" pour sécuriser le déroulement de l'application,
• activation du bouton "Arrêt",
• déclenchement de la poursuite GPS qui collectera une géolocalisation tous les intervalles de temps spécifiés en paramètre et  remplira un corps du courriel à concurrence de sa taille spécifiée. Par sécurité, le tronçon de trajectoire sera sauvegardé sur la carte mémoire du téléphone, si elle est montée sinon le sera en mémoire interne.
• envoi d'un courriel contenant le tronçon de trajectoire dans le corps du message,
• réinitialisation du processus de géolocalisation pour un nouveau tronçon.

L'utilisateur pourra alors arrêter la poursuite à tout moment avec le bouton "Arrêt", ce qui aura pour effet de sauvegarder le corps résiduel du courriel partiellement rempli et de l'envoyer vers le concentrateur. Le programme sera alors en attente de capture d'une nouvelle trajectoire avec le bouton "Départ" ou de disparition avec le bouton "Sortie".

I.1.2 - La programmation de l'application-téléphone :

Cet exercice est un apprentissage à l'utilisation d'Android et Java. Tout est donc problèmes même si j'ai déjà pratiqué le langage Java (ICI une ébauche d'éditeur de dessin technique pour illustrer une requête à Inkscape) . Ils vont donc être pris patiemment les uns après les autres.

 On a pris soin de mettre le plus de commentaires possible dans le source Java. La progression s'effectue par phases comme suit :

I.1.2. phase 1 - La partie ergonomique de l'application : == > ICI

I.1.2. phas 2  - La capture des trajectoires : == > ICI

I.1.2. phase 3 - L'envoi des tronçons de trajectoire : == > ICI

--ooOoo--