INSA DE RENNES STAGE D ÉTÉ Portabilité sur système Android d un système de borne d information Stagiaire : Vincent LE BIANNIC 4ème année, Informatique Maître de stage : M. Michel BRIAND Août 2011
Remerciements : Merci a M. Philippe Le Berre de m avoir accueilli dans son entreprise durant ces 3 mois de stage. Merci également à M. Michel Briand, mon maître de stage, pour m avoir encadré tout au long de ce dernier. Enfin, merci à toute l équipe de Cartelmatic pour son accueil chaleureux.
1 Introduction Cartelmatic est une S.A.S Rennaise créée en 1990, à l initiative de M. Philippe Le Berre, et réalisant depuis plus de 15 ans des bornes interactives. Celles-ci sont par exemple utilisées dans les offices de tourisme afin de faire découvrir une région et les sites touristiques que l on peut y trouver. Depuis la première borne d information installée à Vannes en 1996, plus de 200 autres furent également placées sur l ensemble de la France. L entreprise est également en partenariat avec de grands groupes de mobiliers tels que Giraud ou Lacroix, qui permettent d intégrer des bornes Cartelmatic dans leur mobilier urbain. Ces bornes se basent actuellement sur des systèmes Linux, et possèdent une interface développée à l aide du système de plugins du navigateur Mozilla Firefox. Le contenu est quant à lui généré à l aide de la technologie J2EE permettant d insérer du code Java dans des pages HTML, ce qui permet par exemple de récupérer des éléments contenus dans une base de données. Les bornes possèdent également d autres fonction, telles que la possibilité de faire office de bornes Wi-Fi ou la faculté de pouvoir interroger automatiquement les hôtels sur leurs disponibilités via des appels téléphoniques automatisés. Le travail demandé par l entreprise consistait à développer un système similaire à celui déjà présent sur les bornes d informations, mais à destination d appareils se basant sur le système d exploitation Android, et en réutilisant les bases de données déjà exploitées par l application actuelle. 2 Travail réalisé Android étant un système d exploitation très présent sur le marché des smartphones et tablettes tactiles, le développement ne s est par conséquent pas seulement limité à la réalisation d une application à destination de bornes interactives, mais aussi à destination des appareils mobiles. L application permet donc, à la compilation, de choisir si l on souhaite utiliser un mode «kiosque», dans lequel les fonctionnalités sont limitées, ou un mode «portable» relatif aux smartphones et tablettes tactiles, et où l utilisateur a un contrôle total sur l application. Les différentes spécificités des deux modes sont les suivantes : Mode kiosque Mode portable Possibilité de quitter l application Non Oui Bridage de la navigation internet Oui Non Retour automatique à l écran d accueil Oui Non Protection des paramètres via un mot de passe Oui Non 3
2.1 Organisation de l application 2.1.1 Dialogue avec le serveur Afin de ne pas établir de connexion directement avec la base de données (ce qui aurait nécessité de mettre les identifiants de celle-ci directement en clair dans l application, et par conséquent posé un gros problème de sécurité), un webservice devait être développé afin de faire office d intermédiaire. FIGURE 1 Communication entre l application et le serveur Lorsque l application doit récupérer des informations, une communication est donc établie avec un webservice développé en PHP qui se chargera d effectuer des requêtes sur le serveur MySQL, et de retourner les résultats à l application. L ensemble des messages échangés se fait au format JSON, qui est lui aussi un langage simple à lire et à utiliser. Exemple de requête (recherche du mot "kayak" dans une des tables) : {" requete ": {" type ":" recherche ", " recherche ":" kayak ", " bordereau ":" asc ", " length " :20, " longitude " : -1.616, " latitude " :48.098, " offset ":0, " champs " :[ {" id ":" ID "," nom ":" id "}, {" id ":" ID_TYPE "," nom ":" type "}, {" id ":" LOCALISATION "," nom ":" localisation "}, {" id ":" SOCIETE "," nom ":" nom "} ], " champsaverifier " :[ " SOCIETE ", " ID_TYPE " ] } } 4
2.1.2 Navigation dans l application L application repose sur un principe de menus composés de plusieurs catégories et permettant de passer, soit à d autres menus (organisation hiérarchique), soit à des modules spécifiques (comme par exemple l affichage d un texte ou d une page web). Ce système de modules (fig. 2) permet de développer rapidement de nouvelles catégories. FIGURE 2 Transitions entre les différents composants de l application 2.2 Interface utilisateur 2.2.1 Écran d accueil Le splashscreen (fig. 3) est un écran d accueil ayant des fonctions différentes selon le mode utilisé lors de la compilation. Ainsi, en mode kiosque, ce sera l écran sur lequel l application reviendra lors d une période d inactivité trop importante, tandis qu en mode portable, il ne sera affiché qu une seule fois, lors du lancement de l application. Si la géolocalisation est activée lors de la compilation, ce sera également l écran qui bloquera l utilisateur jusqu à ce que sa position soit détectée. 2.2.2 Menus Le menu (fig. 4) est l écran proposant les catégories accessibles à l utilisateur. Il permet, comme expliqué précédemment, de passer à un autre menu ou à un module de l application en fonction de la catégorie choisie. 5
FIGURE 3 Splashscreen FIGURE 4 Menu de l application 6
Ce menu est décrit à l aide d un fichier xml, permettant une lecture et une modification aisée et rapide. Un système de traduction a également été mis en place afin qu il ne soit pas nécessaire de redéfinir un menu complet pour chaque langue intégrée dans l application. Exemple de fichier menu : <? xml version =" 1.0 " encoding ="UTF -8 "? > < menu nom =" Menu principal " background =" images / img1. jpg " > <! -- Premiere categorie -- > < categorie nom =" Categorie 1" background =" images / img2. jpg " > <! -- Affichage d un texte depuis une URL -- > < categorie nom =" Texte2 " type =" texte " src =" http: // foo. com / test. html " background =" images / img4. jpg "/ > <! -- Affichage d un texte integre au menu -- > < categorie nom =" Text3 " type =" texte " background =" images / img5. jpg " > Texte </ categorie > </ categorie > <! -- Deuxieme categorie -- > < categorie nom =" Categorie 2" background =" http: // foo. com / foo. jpg " > <! -- Requete simple --> < categorie nom =" Requete 1" background =" images / img6. jpg " > < requete bordereau =" hot " / > </ categorie > <! -- Requete avec clause WHERE -- > < categorie nom =" Requete 2" > < requete bordereau =" hpa " > < where champ =" type " operateur =" LIKE " valeur =" CLASS " / > </ requete > </ categorie > </ categorie > </ menu > 2.2.3 Listes de lieux Une liste de lieux (fig. 5) peut correspondre soit à une recherche, soit à une requête précise dans la base de données (et définie dans le menu). Par défaut, les lieux sont triés en fonction de leur distance par rapport à la position courante de l utilisateur (récupérée à l aide du GPS) ou de la borne (définie lors de la compilation), ce qui permet de connaître directement les objets touristiques situés à proximité. D autres méthodes de tri peuvent également être spécifiées afin de, par exemple, afficher des événements en fonction des dates auxquelles ils sont planifiés. Depuis cette liste, il est possible pour l utilisateur d accéder à la description détaillée d un lieu en le sélectionnant. 2.2.4 Détails d un lieu Cet écran affiche une description détaillée d un objet touristique. Une nouvelle requête est générée et exécutée lorsque l utilisateur y accède, afin de récupérer les informations manquantes concernant le lieu concerné (son adresse, une liste de contacts, des photographies,...). 7
FIGURE 5 Liste de lieux 2.2.5 Navigateur Le module de navigation permet d inclure, par exemple, le site internet d une commune directement dans l application. Pour cela, il utilise le moteur de rendu WebKit intégré dans le système d exploitation et supportant un grand nombre de fonctionnalités telles que la gestion du JavaScript et des applets Flash. Dans le cas du mode kiosque, une des fonctionnalités de ce module est de limiter l utilisateur à la consultation de certaines pages prédéfinies, les adresses étant alors filtrées à l aide d expressions régulières. 2.2.6 Affichage d un texte L un des modules les plus simples de l application puisqu il permet d afficher un texte à l écran, avec la possibilité d inclure quelques balises HTML. Le texte peut être soit récupéré dans un fichier se trouvant sur l appareil, soit via un fichier distant téléchargé si nécessaire par l application. 2.2.7 Carte Le module carte (fig. 6) utilise l API Google Maps afin d afficher une carte et situer des objets touristiques. Il permet également de calculer et d afficher le trajet depuis la position actuelle de l appareil jusqu au lieu sélectionné par l utilisateur. 2.3 Système de cache Étant donné qu il n est pas forcément possible d assurer une disponibilité de la connexion internet, un système de cache a été mis en place. Celui-ci fonctionne de la façon suivante : A chaque requête est associé un hash MD5 calculé automatiquement. Lorsqu une requête est exécutée et qu un accès à internet est disponible, celle-ci est mise à jour dans le cache. Lorsqu une requête est exécutée et qu un problème de réseau est détecté, l application regarde si la requête existe déjà dans le cache, et si c est le cas, affiche son dernier 8
FIGURE 6 Affichage d une carte résultat connu. Sur une application à destination d une borne, ce principe est idéal car les lieux souvent consultés ont ainsi moins de chances d être inaccessibles. Des réflexions ont eu lieu concernant le mode portable et l utilisation de ce système de cache pour fournir un mode hors connexion. Il serait en effet possible d offrir la possibilité de télécharger une version du cache générée automatiquement par le serveur et permettant l accès à certaines données sans que la connexion internet du smartphone soit utilisée. 2.4 Création des projets Une application correspondant à un lieu spécifique, il est par conséquent nécessaire de créer un nouveau projet pour chaque nouvelle destination. Cette opération pouvant être relativement longue et coûteuse en temps (copie des sources Java, modification de celles-ci, modification des fichiers de configuration,...), un script bash a été conçu afin de la simplifier. Une fois lancé, celui-ci demande à l utilisateur les différents paramètres liés à l application et se charge de toutes les étapes pouvant être faites de façon automatique. Exemple d exécution du script : vincent@ debian :~/ Cartelmatic$./ newproject. sh ------------------------------------ Creation d un nouveau projet Android ------------------------------------ - Nom du projet : Ville de Rennes - Serveur HTTP ( ou sont stockees les photos ) : http :// www. cartelmatic. com :8080/ - Adresse du Webservice : http :// www. cartelmatic. com :80/ android / rennes / webservice. php 9
- Adresse de mise a jour : http :// www. cartelmatic. com :80/ android / apk / Rennes. apk - Application : rennes - GPS actif? (o/n) o - Mot de passe des parametres ( pour le mode borne ) : azertyuiop - ACRA Form Key : HHEUSJUiopoiHUHiuiuPPPAUEZH - Identifiant Google Analytics : UA -123456-12 ------------------------------------ Recapitulatif ------------------------------------ Nom du projet : Ville de Rennes Package : com. cartelmatic. villederennes Serveur HTTP : http :// www. cartelmatic. com :8080/ Webservice : http :// www. cartelmatic. com :80/ android / rennes / webservice. php Mise a jour : http :// www. adrastee. net / cartelmatic / apk / Rennes. apk Application : rennes Gps : o Longitude : Latitude : Mot de passe des parametres : azertyuiop ACRA Form Key : HHEUSJUiopoiHUHiuiuPPPAUEZH Identifiant Google Analytics : UA -123456-12 Voulez vous continuer? ( o/ n) o ------------------------------------ [ X] Creation des dossiers (./ Projects / villederennes ) [ X] Deplacement des fichiers pour la creation du package [ X] Modification des fichiers pour la creation du package [ X] Configuration du projet 2.5 Mise a jour L application dispose d un module de mise a jour permettant une maintenance aisée des bornes. Celui-ci est accessible directement via la fenêtre de configuration, et se charge de toute la procédure de désinstallation et réinstallation du logiciel. La procédure devait être la plus simple possible, celle-ci devant pouvoir par exemple être réalisée directement par le personnel des offices de tourisme, ne disposant pas de connaissances approfondies concernant le fonctionnement de l application. 2.6 Documentation L application devant être maintenue par d autres personnes ne connaissant pas forcément les spécificités du développement sous Android, une documentation très détaillée a dû être 10
écrite. Celle-ci consiste en plusieurs pages HTML expliquant les différents choix ayant été pris au cours du développement, ainsi que divers tutoriels décrivant les étapes d installation, de création, et de finalisation d un projet. Des diagrammes UML ont également été créés à partir de l application ArgoUML et donnent une représentation globale du projet ainsi que des divers modules déjà existants. Enfin, la totalité du code source est documentée en respectant le standard Javadoc, permettant à de futurs développeurs de le comprendre et de le modifier plus facilement. 2.7 Tests Des tests unitaires ont été réalisés tout au long de la phase de développement du projet, afin de tester les nouvelles fonctionnalités et les nouveaux modules implémentés. Ces tests ont ainsi eu pour objectif de valider le comportement de certaines fonctions comme, par exemple, celle chargée d effectuer la liaison entre l application et le webservice. Une fois cette partie terminée, d autres tests ont également été mis en place durant la phase d intégration de l application. Ceux-ci ont eu l avantage de mettre en avant certains problèmes non repérés lors du développement, notamment lors de l utilisation de bases de données comportant certaines informations sous des formats différents de ceux de la base utilisée pour les tests précédents. 2.8 Android-x86 En parallèle, un travail a aussi effectué afin de déterminer les différentes façons de faire fonctionner cette application sur une borne interactive traditionnelle. Android ne fonctionnant normalement que sur les architectures de type ARM, et les bornes utilisant quant à elles des processeurs x86, la distribution Android-x86 a dû être utilisée. Cette dernière ne faisant pas partie du projet officiel Android n était par conséquent pas complètement fonctionnelle, mais a permis de tester l application sur des configurations autres que des smartphones ou tablettes. Toutefois, un problème d incompatibilité entre le matériel composant les dernières versions des bornes et Android-x86 a été relevé, occasionnant des erreurs d affichage. Un script a également été réalisé afin de modifier une installation traditionnelle d Androidx86 en lui incluant l application réalisée ainsi que divers changements permettant sa bonne exécution. 3 Apports pour l entreprise et enseignements retirés L entreprise prévoit actuellement d utiliser l application créée dans une nouvelle gamme de produits utilisant des tablettes tactiles Android afin de proposer une solution miniaturisée du système de bornes actuel. Celles-ci pourraient en effet être intéressantes pour les offices de tourismes car beaucoup moins coûteuses que le système actuel. Le peu de modifications nécessaires pour convertir une application en mode kiosque, en une application en mode 11
portable, permettra également de mettre à disposition des utilisateurs de smartphones les applications conçues, à l aide de l Android Market. Un compte développeur Android a d ailleurs été créé par l entreprise à la fin du stage afin de préparer le déploiement des applications sur ce dernier. D un côté plus personnel, ce stage m a permis d améliorer mon expérience dans le milieu du développement Android. Connaissant déjà les bases de celui-ci, notamment grâce à mon projet de 4ème année à l INSA, j ai en effet eu l occasion d en découvrir davantage sur le fonctionnement interne de ce système d exploitation, et d acquérir diverses techniques permettant d optimiser l application créée. Ce stage m a également été utile afin d améliorer ma façon de développer. J ai en effet découvert diverses techniques permettant de travailler plus rapidement et plus efficacement avec l environnement de développement Eclipse ainsi qu avec le SDK Android. Étant le seul affecté au développement de l application Android, j ai également eu la chance de pouvoir travailler en autonomie complète sur ce projet. Cela m a permis une certaine liberté dans les choix que j ai eu à faire, tout en essayant de respecter les besoins émis par l entreprise. 12
4 Annexes 4.1 Planning 13
Résumé Cartelmatic est une entreprise réalisant des bornes interactives d informations, principalement à destination des offices de tourisme. Celles-ci permettent une consultation aisée et rapide des objets touristiques (hôtels, campings, fêtes,...) situés à proximité de ces derniers ainsi que leurs disponibilités. L objectif du stage a été de concevoir un système similaire à celui des bornes actuelles, mais à destination d appareils ayant pour système d exploitation Android. L application créée a par conséquent dû être développée en respectant certaines contraintes telles que l utilisation des bases de données déjà existantes. Plusieurs choix ont également été faits au cours du développement, comme la possibilité de choisir au moment de la compilation de l application un mode définissant si l on souhaite obtenir un programme à destination d une borne interactive (où certaines actions sont bridées) ou bien un programme ciblant des smartphones ou tablettes tactiles. L application fut également pensée pour être modifiable sans connaître en profondeur le développement sous Android, afin de pouvoir assurer sa maintenance suite au stage. Elle est aussi composée de plusieurs modules permettant des modifications faciles et rapides de ses fonctionnalités. Une autre partie du stage eut pour objectif de chercher des solutions permettant d exécuter l application développée sur le matériel utilisé par les bornes interactives actuelles. Pour cela, l attention fut portée sur Android-x86, une version d Android développée à destination des ordinateurs ayant un processeur de type x86. Summary Cartelmatic is a company developping interactive information terminals, principally for tourist offices. Those terminals allow an easy and quick consult of tourism places (hotels, campsites, festivals,...) located near them, and also provide their availibility. The work placement aim was to develop a system similar as the one used by the current terminals but for Android based devices. Therefore, the developped software has been created respecting some constraints as the use of existing databases. Some other decisions has been taken as the possibility to choose before the software s compilation a mode defining its target : either terminals (some actions being restricted in this case), or smartphones and touchpads. The software has also be designed to be alterable without having a deep knowledge of Android development, in order to be maintainable after the end of the work placement, and consists of several modules, allowing quick and easy modifications of its features. Another part of the work placement was to look for solutions allowing the developped software to be run on the hardware used by current terminals. In order to do that, Android-x86, which is a version of Android working with x86 CPU, was used.