Realit´ e augment´ ee avec Google Android´deptinfo.unice.fr/twiki/pub/Minfo/Rapports09-10/TER-10bontempsga… · La fréquence utilisée par le NFC est de 13,56 MHz et peut atteindre

Realite augmentee avec Google Android

Anthony GAUDINO <[email protected]>Marc WADJAHDI <[email protected]>

Tiago TEIXEIRA <[email protected]>Xavier BONTEMPS <[email protected]>

Université de Nice-Sophia Antipolis, le 28 mai 2010

mailto:[email protected]




Résumé

Ce document constitue le rapport du Travail d’Etude et de Recherche de la 1ere année de forma-tion Master Informatique de l’Université de Nice-Sophia Antipolis. Ce projet s’est effectué à l’Universitéde Nice-Sophia Antipolisdu 23 mars au 31 mai sous la tutelle de Mr BENOUALI Hamine par le groupecomposé de Anthony GAUDINO, Marc WADJAHDI, Tiago TEIXEIRA et Xavier BONTEMPS. L’intituléde ce TER est "Réalité augmentée avec Google Android".

Remerciements

Tout d’abord nous souhaitons remercier, dans un premier temps, toute l’équipe pédagogique del’Université de Nice-Sophia Antipolisainsi que les intervenants professionnels responsables du Master IInformatique pour tous les enseignements qu’ils nous ont apportés.

Nous remercions également Mr BENOUALI Hamine, responsable de ce TER pour l’aide et lesconseils concernant les missions évoquées dans ce rapport, ainsi que pour la formation au NFC, ala programmation de Midlet et d’applications Android.

Mr MAISONOBE Alexandre et Mr GALLI Gregory, étudiants au MBDS, pour leur soutien et leuraide.

Mr MOPOLO MOKE Gabriel, directeur du MBDS, et tous les membres du MBDS pour nous avoiraccueillis chaleureusement au sein de leurs locaux.

Et Mr MIRANDA Serge, coordinateur du MBDS, pour ses idées et son enthousiasme, et l’intérêtqu’il nous a porté.

Table des matières

Résumé 2

Remerciements 3

Introduction 6

I Objectifs 7I.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

I.1.1 Description de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8I.1.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8I.1.3 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

I.2 Exigences Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11I.2.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11I.2.2 Twinlinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12I.2.3 Wikitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

II Conception 15II.1 Architecture 3-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16II.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

II.2.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17II.2.2 Réseaux Sociaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19II.2.3 Twinlinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21II.2.4 Wikitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

II.3 Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23II.3.1 GlassFish v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23II.3.2 JSF 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

II.4 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24II.4.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

II.5 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25II.5.1 Serveur-BDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25II.5.2 Client-Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

III Implémentation 29III.1 Persistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

III.1.1 Les entitées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30III.1.2 Pattern DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31III.1.3 Pattern Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

III.2 Interface d’administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32III.2.1 Java Server Faces Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Réalité augmentée avec Google Android 5/41

III.2.2 Connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33III.2.3 Le composant de gestion des types . . . . . . . . . . . . . . . . . . . . . . . . . . 34

III.3 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35III.4 Application TouchView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

III.4.1 NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35III.4.2 Realite Augmentée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Conclusion 40

Références 41

A. GAUDINO, M. WADJAHDI, T. TEIXEIRA, X. BONTEMPS

Introduction

Depuis quelques années, les fonctions du téléphone portable se multiplient et évoluent sans cesse.Aujourd’hui l’écart entre un téléphone et un ordinateur portable se resserre de plus en plus. Parexemple avec un téléphone portable dit «dernière génération» il est possible de consulter ses mails,naviguer sur internet, regarder des vidéos ... Et cela de manière très intuitive et rapide. C’est pourquoice dernier prend un rôle de plus en plus important dans notre poche.

L’enjeu étant bien sûr de repousser les limites du téléphone portable le plus loin possible, notreprojet s’inscrit dans le contexte de l’ensemble de projets «Nice Ville NFC». Pour les partisans de «NiceVille NFC» le but est de proposer aux utilisateurs d’un téléphone NFC une multitude de services : leremplacement de votre carte bancaire, la possibilité d’obtenir des informations supplémentaires surune oeuvre d’art ou même sur les horaires de votre prochain bus et bien d’autres...

Les perspectives offertes par cette technologie de pointe sont immenses pour les services publicslocaux, notamment en matière de santé, d’aide aux personnes âgées ou handicapées mais aussi ledomaine du développement économique et touristique.

Ainsi, c’est dans cette perspective que va s’inscrire notre TER ( Projet Android 2.0) où l’on vachercher à rajouter une sphère de services existant sur des SmartPhones (Android) grâce à cettetechnologie du NFC mais aussi en se servant de la réalité augmentée (superposition de modèlesvirtuels en 2D ou 3D sur la réalité et ceci en temps réel).

Première partie

Objectifs


I.1 Application

I.1.1 Description de l’application

Notre but est d’offrir à l’utilisateur un parcours de Valrose en touchant les différents Tags NFC si-tués sur le Campus et de lui proposer différentes méthodes d’interaction avec ces «points de contact»mais aussi de lui proposer une visite en réalité augmentée avec notamment la possibilité de comparerdes images de Valrose datant de 1913 avec les images du parc telle qu’on le connaît de nos jours.

Enfin, le projet s’est vu rajouté une extension visant les agences immobilières qui est de rajouter aucôté réalité augmentée la possibilité en filmant les façades des immeubles d’obtenir des informationssur les appartements à louer ou à vendre (si il y en a de référencés).

I.1.2 Client

Near Field Communication

Near Field Communication (NFC) est une nouvelle technologie de communication sans fil très pro-metteuse. Basé sur le RFID, NFC permet d’échanger des données entre un client mobile et des cartesà puces sans contact. La fréquence utilisée par le NFC est de 13,56 MHz et peut atteindre un débit de848 kbit/s.

Quelques exemples d’usages :– Paiement en utilisant un appareil mobile (téléphone portable, ordinateur portable, etc.) ;– Lecture d’une carte de visite électronique avec un PDA ;– Synchronisation de signets Internet et de contacts entre un PDA et un téléphone portable ;– Récupération de la clef WiFi d’un point d’accès en approchant son périphérique NFC de la

borne de diffusion.



Le NFC fonctionne sous trois différents modes :– Le mode émulation de carte, c’est-à-dire que le terminal mobile associé à un élément de sécurité

émule le fonctionnement d’une carte à puce sans-contact.– Le mode peer to peer, Ce mode permet à deux terminaux mobiles d’échanger de l’information,

par exemple des vCard, des photos, des vidéos, etc...– Le mode lecteur, Ce mode permet à un usager de lire des informations en approchant son

mobile devant des étiquettes électroniques.

Dans le cadre de notre projet l’un des objectifs est de placer des cartes NFC sur les différentesœuvres d’art exposées dans la parc ValroseLe but est de pouvoir avec un téléphone Android lire les cartes et ensuite avoir la possibilité d’obtenirplus d’informations sur l’œuvre et sur son créateur.De plus le fait de "toucher" l’œuvre doit permettre d’accéder à différents réseaux sociaux tels queFacebook, pour devenir fan de l’œuvre ou bien Twitter pour tweeter le fait que l’on se trouve devantcette œuvre en ce moment même.Un dernier objectif est de pouvoir laisser un commentaire sur cette œuvre et de lire les commentaireslaissés par les autres personnes ayant "touché" cette œuvre.

Réalité Augmentée

On en parle de plus en plus de ce concept de «réalité augmentée» notamment avec l’apparitiondes derniers SmartPhones tels qu’Android ou iPhone. Les applications se multiplient et il y a degrandes chances pour que ce concept révolutionne les interfaces Homme-Machine dans les annéesà venir. Tout d’abord une petite présentation de ce qu’est la réalité augmentée va être mise en placepour ensuite vous expliquer son implication dans le projet réalisé.

La réalité augmentée consiste à ajouter des objets virtuels sur une vidéo prise dans la réalité et àobtenir ainsi une interaction possible entre des personnes ou des objets réels et des objets virtuels.Tout cela est rendu possible par des calculs réalisés par un ordinateur ce qui permet d’assurer unrésultat en temps réel et ainsi avoir une vraie superposition entre la vue réelle et des modèles virtuels.

Pour le Projet Android 2.0, la réalité augmentée va permettre la superposition de POI (points d’in-térêts) sur la capture vidéo du téléphone lui même ce qui permettra à l’utilisateur d’avoir en plus



de la vidéo, des informations supplémentaires sur la campus Valrose, notamment des descriptionsdes lieux répertoriés ainsi que des images datant de 1913 de ces mêmes lieux afin que l’utilisateurpuisse faire la comparaison. Ainsi, il aura une vue d’ensemble du campus Valrose sans même avoirà se déplacer juste en filmant avec son téléphone et en cliquant sur les POI qu’il souhaite voir.

Mais aussi pour l’extension de notre projet visant l’immobilier, l’utilisateur pourra juste en filmantles façades des immeubles se trouvant a proximité de lui savoir quels appartements sont en vente ouen location, il pourra consulter les photos de ces derniers, avoir des descriptions et même prendrecontact directement avec les agences immobilières.

I.1.3 Backend

Comme évoqué précédemment l’application est divisée en deux parties le client et le backend. Lebackend doit remplir plusieurs objectifs



Le stockage Des données

L’application cliente étant déployée sur un système embarqué, le volume de l’application est alorsune contrainte. Dans cette optique le stockage des données est délégué à un serveur de base dedonnées distant.

La restitution des données au client

Le backend doit aussi fournir une solution pour la restitution des données a l’application cliente.La communication doit se faire par des web services (Servlets) déployés sur le serveur d’application.Ces web services renvoient les données formatées au client.

L’administration des données

Le backend doit fournir une interface d’administration permettant la gestions des données (créa-tion – modification – suppression). L’accès à cette interface d’administration ne doit être possiblequ’après authentification.

I.2 Exigences Techniques

I.2.1 Android

L’application étant destinée au nouveau système d’exploitation pour téléphone mobile (smart-phone) de la multinationale Google, une présentation et une réflexion sur ce système permettra demieux développer et de comprendre les mécanismes à la fois simples et complexes liés à ce nouveaumonde en plein développement : le monde de l’embarqué, du mobile.

Google se distingue dans le fait que le code source de son système d’exploitation est disponiblegratuitement. Cela fait partie de la philosophie et l’état d’esprit de l’Open Source avec ses avantageset ses inconvénients. Même le logo du système est libre de droit pour des créations infinies.

A travers cette décision importante, Google met en avant une politique de contribution autour deson système d’exploitation et compte sur la communauté des développeurs pour améliorer leur sys-tème ou tout simplement développer des applications pour enrichir leur plateforme AndroidMarket.

Étant développées par Google, les interactions avec les services web comme google maps, calendarsont très bien implémentées.

Google ne met pas seulement à disposition un SDK, mais aussi une documentation très pratiqueet un portail internet dynamique (vidéo, tutoriel etc...)



Android est divisé en 4 couches. Nous allons travailler lors du développement de notre applica-tion sur la couche applicative. En effet Android embarque une machine virtuelle java spécialementretouchée par google pour répondre aux contraintes de l’embarqué. Cette machine virtuelle nomméeDalvik permet l’exécution d’application java. On va bien sûr profiter de la technologie XML implé-mentée dans le SDK et conçue dans l’environnement de développement qui permet la séparation dela couche graphique du code fonctionnel pur. Ce point sera traité dans le paragraphe GUI.

De nombreuses Api (persistance, communication) connues et reconnues par la communauté dedéveloppeur sont disponibles et utilisables dans les applications destinées à être déployées sur An-droid. Cela est bien normal vu que le langage Java a été le choix de google pour attirer entre autresles développeurs mobiles déjà très à l’aise avec cette technologie. Les Api utilisées dans l’applicationsont traitées dans la suite de notre rapport.

Avant de développer, il est bien utile de se renseigner sur les moyens de distribution mis en œuvrepar Google, si par la suite l’application doit être distribué dans de bonnes conditions, nous seronsdépendants de leur plateforme même si il n’est pas obligatoire d’utiliser AndroidMarket.

Google demande à tout développeur désireux de distribuer son application par le biais d’Andro-mède Market d’ouvrir un compte spécial développeur (licence).

I.2.2 Twinlinx

A l’heure actuelle, les téléphones Android ne sont pas équipés de la technologie NFC. C’est pour-quoi Twinlinx à mis au point une plateforme logiciel combinée à un sticker permettant d’ajouter àn’importe quel téléphone la technologie NFC.

MyMax est le nom du sticker créé par TwinLinx, il permet de faire évoluer le bluetooth du télé-phone avec NFC. Le fonctionnement est simple, le sticker se colle sur le téléphone et est détecté parcelui-ci via bluetooth. Dès que le sticker est en contact avec une carte à puce NFC, il lit les informa-tions présentes sur la carte et les transmets au téléphone.



Le sticker est composé d’une partie active et d’une partie passive. La partie active permet de réveillerle sticker et d’établir la communication bluetooth avec le téléphone.

Twinlinx met à disposition un kit de développement pour son sticker. Il est donc possible de créersa propre application en J2ME en utilisant MyMax. Une documentation détaillée et de nombreuxexemples de code sont fournis avec le sticker notamment pour lire et écrire sur une carte à puce.

I.2.3 Wikitude

Pour le développement de la partie réalité augmentée sur Android, le choix de l’API Wikitude a étéimposé.

La réalité augmentée est de plus en plus exploitée sur les plate-formes mobiles, c’est pourquoiune jeune entreprise autrichienne, Mobilizy a mis à disposition sur son site une API pour le systèmed’exploitation Android, dédiée à la création d’applications de réalité augmentée.

Mobilizy s’était déjà illustrée sur ce terrain avec une application de géolocalisation de points d’in-térêts, Wikitude ( http://www.wikitude.org ), dont la majeure partie des informations visiblessur l’écran d’un mobile sont issues de l’encyclopédie Wikipedia.

Cette API de développement reprend le principe de l’application Wikitude et permet ainsi à l’uti-lisateur de créer ses propres points d’intérêts sur le plan en temps réel d’une application Android.Pour cela, il suffit d’entrer les coordonnées d’un point d’intérêt dans l’API et l’application chargerad’elle même les coordonnées, les affichant sur l’écran du téléphone portable.

En juillet dernier, une autre entreprise, Layar, a ouvert son API pour permettre aux utilisateurs deson application Android d’y ajouter des informations et des points d’intérêts. Mais jusqu’à présent,aucune société (excepte Wikitude) n’a mis à disposition une API gratuite compatible avec les autresapplications Android.


http://www.wikitude.org


De plus Wikitude se distingue des autres applications concurrentes par son approche ouverte,qui consiste à fournir cette API permettant à tout un chacun de développer des services de réalitéaugmentée pour Android, ou améliorer les existantes. D’autre part, avec Wikitude.me, ce sont lesutilisateurs qui sont appelés à compléter la base de données de points d’intérêts qui apparaîtrontensuite dans l’application sur les mobiles Android, sans nécessairement posséder l’un de ces mobilespuisque l’opération se fait sur le web, de façon très facile et intuitive.


Deuxième partie

Conception


Ce chapitre présente les différents choix de conception relatifs à notre projet.On présentera premièrement l’architecture 3-tiers qui est la base de notre application. Puis les 3 dif-férents tiers qui en decoulent. Et enfin les communications entre ces couches.

II.1 Architecture 3-tiers

L’architecture 3-tier est le modèle logique d’architecture applicative le plus adapté au projet. Ilvise à séparer très nettement trois couches logicielles au sein d’une même application, à modéliser etprésenter cette application comme un empilement de trois couches clairement défini :

– la présentation des données : correspondant à l’affichage, la restitution sur le poste de travail,le dialogue avec l’utilisateur. Dans ce projet il s’agit de l’application cliente android.

– le traitement métier des données : correspondant à la mise en oeuvre de l’ensemble des règlesde gestion et de la logique applicative (Les servlets ou l’interface d’administration web).

– l’ accès aux données persistantes : correspondant aux données qui sont destinées à être conser-vées sur la durée, voire de manière définitive, le SGBDR.

Ce modèle permet de répondre aux préoccupations suivantes :– Allégement du poste de travail client. Point très important puisqu’il s’agit de programmer une

application pour smart-phone.– La prise en compte de l’hétérogénéité des plates-formes (serveurs, clients, langages, etc.). Ce

qui réponds encore une fois à une problématique de notre application.– Une meilleure répartition de la charge entre différents serveurs d’application.



II.2 Client

II.2.1 Android

Description de la GUI (interface utilisateur)

Avant toute chose, il faut rappeler qu’Android n’est pas destiné seulement à un type de terminauxmais à une multitude et cela ne fera que progresser dans les années à venir. Les développeurs devronts’adapter.

Toutefois Android offre des solutions à cette hétérogénéité de manière simple et sans avoir à tou-cher le cœur du code source.

les ressources alternatives (Alternate Resources) et le filtrage au sein de l’Android Market. L’ap-plication n’étant pas destinée à être distribuée via Android Market, le package final ne tiendra pascompte du filtrage qui consiste à taguer son application, permettant ainsi de la cacher aux terminauxnon compatibles. Par contre, l’utilisation des ressources alternatives a permis d’organiser le dévelop-pement..Elles servent à définir :

– Les structures de l’interface graphique sous forme de fichier XML, contenues dans le répertoirelayouts.

– Les images utilisées, par exemple en arrière plan ou icône, contenues dans le répertoire dra-wable,

– Des jeux de valeurs (création de couleur, variable), contenus dans le répertoire values.

Pour le développement de l’interface utilisateur, l’équipe chargée de cette dernière a utilisé le fra-mework Android mis à disposition dans l’environnement de développement Eclipse. Pour construireune interface graphique, il existe des outils payants permettant un travail plus rapide et plus simple.

La représentation des écrans dans le format XML permet une plus grande souplesse notammentlors des modifications. Android dispose nativement de composants graphiques assez évolués etadaptés spécialement aux contraintes du téléphone portable.

Dans ce contexte, l’utilisation du composant Toast est particulièrement bien adaptée à l’informa-tion du client par le système sous forme de message concis et éphémère.

L’application est un ensemble d’écran graphique, chaque écran présenté à l’utilisateur est appeléune Activity, elle gère entre autre l’appui sur les touches physiques et les appuis tactiles.

Définition d’une Activity

Une Activity présente une interface visuelle pour une tâche que l’utilisateur peut entreprendre.Par exemple, une activity peut présenter une liste d’éléments de menu que l’utilisateur peut choisir,ou elle peut afficher des images avec leur légende. Une application de messagerie peut avoir une acti-vity montrant la liste des contacts à qui l’on peut envoyer des messages, et une seconde activity pourécrire le message au contact choisi, et d’autres activity pour voir les anciens messages ou modifierles paramètres. Bien qu’elles fonctionnent ensemble pour former une interface utilisateur cohérente,chaque activity est indépendante des autres. Chacune est implémentée en tant que dérivée de laclasse Activity.



Chaque activity contient une fenêtre par défaut pour dessiner dedans. Généralement, la fenêtreremplit l’écran, mais elle peut être plus petite que celui-ci ou même "flotter" au-dessus des autresfenêtres. Une activity peut aussi utiliser des fenêtres additionnelles - par exemple une fenêtre de dia-logue "pop-up" qui demande une réponse de l’utilisateur, ou une fenêtre qui présente aux utilisateursdes informations vitales quand ils sélectionnent un élément particulier sur l’écran.

Suivant le type d’écran (formulaire, écran d’information etc.. ) les activity sont habillées par descomposants plus simples et plus basiques comme label, textbox, button , list, le tout disposé harmo-nieusement dans des composants de type view pour une ergonomie cohérente niveau utilisateur.

Le contenu visuel de la fenêtre (activity) est fourni par une hiérarchie de vues, objet qui dérive dela classe View. Elle sont représentées par un espace rectangulaire permettant de répondre aux actionsde l’utilisateur. Donc les vues sont l’endroit où l’interaction avec l’utilisateur a lieu.

Pour faire passer des informations entre Activity, Android propose un composant nommé Intent.Ce composant permet de transmettre les choix de l’utilisateur, variable entre Activity.

Un intent est un objet Intent qui détient le contenu du message. Pour les activity et services, unintent contient le nom de l’action demandée et spécifie les URI des données sur lesquelles agir.

Le fichier Manifest

Avant qu’Android puisse démarrer un composant d’une application, il doit apprendre que lecomposant existe. Par conséquent, les applications déclarent leurs composants dans un fichier mani-fest qui est groupé dans le package Android, le fichier .apk qui contient aussi le code de l’application,les fichiers et les ressources.

Le manifest est un fichier XML et se nomme toujours AndroidManifest.xml pour toutes les appli-cations. Il permet de faire de nombreuses choses en plus de déclarer les composants de l’applicationcomme nommer les librairies dont l’application a besoin d’être liée (en plus de la librairie Android)et identifier les permissions dont l’application a besoin.

Pour que l’application soit autorisée à accéder à l’internet, la définition d’ une permission dans lefichier manifest est obligatoire :

<uses-permission Android:name="android.permission.INTERNET" />

remarque : Lors des tests en local, on s’est rendu compte qu’Android met à disposition une nouvelleadresse 10.0.2.2 permettant de travailler en local sans problème.

Les principaux Activity

Écran principal. La première que l’utilisateur aperçoit est l’écran de sélection du mode (sélectionde la technologie) NFC ou réalité augmentée, cet écran est composé de deux boutons disposés l’unen dessous de l’autre grâce à l’emploi d’un layout. Ces deux boutons sont reliés à un listener de clicqui va permettre de savoir quel bouton a été sélectionné.La touche physique MENU du téléphone est aussi, dans cet écran principal, rélié à un listener declic. Lors de son clic, un menu apparaît permettant de quitter l’application ou de s’informer sur lespersonnes ayant participé au développement.



Écran détail Objet NFC. L’écran permettant d’informer l’utilisateur sur ce qu’il vient de toucheravec son téléphone est composé d’une Image, son rôle est d’afficher l’image associée à l’objet touché.La description et le lien internet sont quant à eux affichés dans des labels classiques. Comme pourl’écran principal la touche menu est écoutée pour offrir différentes interactions surtout au niveau desréseaux sociaux (voir paragraphe réseaux sociaux).

Écran réalité augmentée. Avant de basculer en mode réalité augmentée, l’utilisateur doit sélection-ner un type d’objet à visualiser. Cet écran est composé seulement d’un composant List muni d’unescrollBar verticale. Ce composant List reçoit et permet de visualiser les types d’objets disponiblesdans la base de données

Lorsque le client bascule en mode réalité augmentée, l’interface est celle de l’application wikitudeavec la différence lors de la sélection d’un objet, une nouvelle activity s’ouvre en présentant unegalerie d’images associée à l’objet sélectionné implémenté grâce aux composants gallery et images-witcher, un label est aussi présent pour une bref description.

Écran Consulter commentaire Cet écran est constitué d’un composant List regroupant tous lescommentaires postés par les utilisateurs et présents dans la base de données. Un écouteur est placésur chaque ligne de la liste pour afficher une fenêtre permettant de visualiser la date et l’intégralitédu message.

II.2.2 Réseaux Sociaux

Un réseau social est un ensemble d’entités sociales ( par exemple des individus ou des organi-sations) reliées entre elles par des liens crées lors des interactions sociales(échange d’information ouautre entre deux agents au sein du même système). Il se représente par une structure ou une formedynamique d’un groupement social. Des réseaux sociaux peuvent être crées stratégiquement pouragrandir ou rendre plus efficient son propre réseau social(professionnel, amical).

Un réseau social représente une structure sociale dynamique se modélisant par des sommets etdes arêtes. Les sommets désignent généralement des gens et/ou des organisations et sont reliéesentre eux par des interactions sociales.

FIG. 1: Les six degrés de séparation (ou liaisons) : l’effet du petit monde.



On trouve sur Internet toutes sortes de réseaux sociaux. Certains regroupent des amis de la vieréelle, comme Donaki et les Copains d’avant. D’autres aident à se créer un cercle d’amis, à trouverdes partenaires commerciaux, un emploi ou autres. Il s’agit de Réseautague Social(ensemble desmoyens mis en oeuvre pour relier des personnes entre elles), comme Facebook, MySpace, Twitter,Linkedln, Habbo...

Pour Android 2.0, les réseaux sociaux qui ont été choisis sont : Facebook et Twitter. Grâce à cesdeux réseaux, les utilisateurs de l’application pourront «garder contact» et partager leurs avis sur lesoeuvres ou endroits de Valrose, et ainsi créer un réseau social autour du campus Valrose lui même.

facebook

Petit rappel : Facebook est un réseau social crée par Marc Zuckenberg et destiné a rassembler despersonnes proches ou inconnues.

Dans le cas d’Android 2.0, il va permettre aux utilisateurs de l’application de partager avec leurentourage l’endroit (ou oeuvre) devant lequel il se trouve en y incluant un descriptif de l’endroit(ou oeuvre) et de rajouter un commentaire personnel sur ce le message qu’ils veulent faire passer oupartager avec leur entourage.

Pour l’intégration de Facebook à Android plusieurs API ont été étudiés :– FBRocket– Facebook-java-api– fbconnect-android

C’est finalement fbconnect-android (API non officielle) qui a été intégrée au projet. Elle a été choisiede par la clarté de son code (comparé a l’API facebook en java), de son intégration sur Androiddéjà pré-codé, mais aussi de par ses interfaces intuitives pour l’utilisateur ainsi qu’un stockage dela session de l’utilisateur pour une ré-utilisation ultérieure (afin d’éviter a ce dernier de réécrire sasession et mot de passe à chaque fois).



twitter

Jtweeter. Pour répondre à l’intégration des réseaux sociaux dans l’application et concernant la fonc-tionnalité tweeter, l’utilisation de l’api jTwitter s’est montrée la plus naturelle et la plus simple.http://www.winterwell.com/software/jtwitter.php

Jtwitter est une petite libraire java permettant de communiquer avec le service twitter. Ces fonc-tionnalités permettent de définir son statut, récupèrent la liste de ces followers. D’après le site internetde l’api, tout ce qu’il est possible de faire avec twitter, peut être fait avec jTwitter.

Après le téléchargement de la version 1.6 les tests ont pu commencer en se basant sur le coded’exemple donné sur le site. Les résultats étant concluants, l’intégration de cette api fut complétéepar une interface graphique adéquate.

// Make a Twitter objectTwitter twitter = new Twitter("my-name","my-password");// Print Daniel Winterstein’s statusSystem.out.println(twitter.getStatus("winterstein"));// Set my statustwitter.setStatus("Messing about in Java");

II.2.3 Twinlinx

TWINLINX est aujourd’hui la seule société qui propose un sticker Passif et Actif (carte et lecteur),qui en plus est capable de communiquer avec le téléphone via BlueTooth. Les points forts de MyMax :


http://www.winterwell.com/software/jtwitter.php


– Sa simplicité de déploiement (on colle Mymax derrière son téléphone) va permettre aux opéra-teurs de proposer rapidement et simplement de nouveaux services (applications sans contact)aux utilisateurs.

– 80% du parc de téléphone mobile est compatible avec MyMax.– Une plate forme multi application (paiement, transport, contrôle d’accès) qui permet de mettre

dans le sticker des applications totalement indépendantes.– Chargement et modification des applications par le réseau GSM ! Plus besoin de passer à

la borne pour recharger son pass Navigo, de demander une carte d’autorisation d’accès, derecharger sa carte de paiement ! Les informations sont transmises à l’utilisateur par GSM et lacarte est mise à jour.

– La fonctionnalité lecteur de MyMax offre de nouvelles perspectives : le téléphone devientle support d’affichage des informations contenues dans des cartes externes ou tout autre objetsans contact. Le téléphone (via son clavier et son écran) permet aussi de changer les donnéesde la carte.

– La communication entre 2 MyMax, ce qui permet d’échanger des données entre 2 téléphones.

Le sticker permet de faire fonctionner la partie NFC de l’application mobile : Une connexion blue-tooth est établie entre le sticker et le téléphone lorsque l’utilisateur entre dans la partie NFC de l’ap-plication et approche le téléphone d’une carte à puce. Le sticker transmet alors l’Universally UniqueIdentifier (UUID) de la carte au téléphone.

Bien que Twinlinx soit compatible avec un grand nombre de téléphones, il n’est toujours pas opé-rationnel pour les téléphones Android, les stickers devraient sortir fin juin 2010.

II.2.4 Wikitude

Wikitude est l’une des nombreuses applications de réalité augmentée présente sur le marché.Contrairement à ses concurrents, Wikitude met à disposition une API de développement plus libre.Plus précisément, Layar qui est un concurrent direct de Wikitude ne permet pas la création de Pointof Interest (POI) directement au sein du code source. Pour utiliser Layar il faut créer et enregistrerces POIs dans leur propre base de données. De ce fait il est impossible de configurer des actionspersonnalisées au moment d’un clic sur un POI.

Wikitude à quand à lui mis à disposition un plus grand nombre de fonctionnalités. Il est possiblede créer des POIs personnelles sans les héberger sur le serveur de Wikitude. Un point fort de leurAPI est de permettre l’association d’une action personnalisée pour chaque POI.

Wikitude permet de faire fonctionner la partie réalité augmentée de l’application mobile. Lorsquel’utilisateur entre dans la partie réalité augmentée de l’application, il lui est possible de choisir untype de POI à afficher à l’écran (Oeuvre d’art du parc Valrose, Immobilier, etc.). Une fois sa sélectionfaite, les POIs sont créés à l’aide de l’api et une vue de réalité augmentée est lancée. Une fois danscette vue l’utilisateur a la possibilité de sélectionner un POI et d’afficher une nouvelle vue spécifiqueà ce POI.

Un bug réside encore dans l’api, au moment de changer de vue lors de la sélection d’un POI.Wikitude met à disposition des outils pour récupérer les informations liées à ce POI dans la vuesuivante. Malheureusement cette fonctionnalité ne sera opérationnelle que dans la prochaine versionde Wikitude qui devrait sortir à la mi juin.



II.3 Serveur

II.3.1 GlassFish v3

GlassFish est le nom du serveur d’applications Open Source Java EE 6 dans sa version 3.

Hitorique

– Mai 2006 : v1.0– Septembre 2007 : v2.0 | Ajout des fonctions de haute-dispo/clustering et support de Web Ser-

vices avancés et une performance accrue.– Décembre 2009 : v3.0 | Sortie en même temps que Java EE 6, elle apporte un découpage modu-

laire et des temps de démarrage de quelques secondes.

Fonctions

Avec GlassFish v3, c’est un support complet de Java EE 6 qui est proposé notamment ceux de :– JPA 2.0 : collections, verrou pessimiste, API de critères, l’utilisation d’EclipseLink, ...– JSF 2.0 : facelets/XHTML, AJAX intégré, composants composites, ...– Et Servlet 3.0 : web.xml optionnel, API asynchrone, ... de démarrage de quelques secondes.

C’est ce qui a motivé le choix d’un serveur Glassfish.

Tomcat VS GlassFish

Au delà des différences d’API disponibles (effectivement Tomcat n’offre qu’un sous-ensemble deJavaEE/J2EE), il y a des différences sur :

– Les outils d’administration (avantage à GlassFish)– Le clustering (avantage à GlassFish)– La "légèreté" du produit (avantage historique à Tomcat qui a moins de services à démarrer).

Cependant GlassFish v3 "prelude" vient de sortir et offre une architecture très modulaire (OSGiFelix) qui permet un temps de démarrage très rapide (3-5 secondes) et un démarrage des ser-vices à la demande.

II.3.2 JSF 2.0

La technologie JSF (Java Server Faces) représente un Framework basé sur les composantes utili-sateurs utilisées pour construire des applications web. L’API de JSF permet de représenter les com-posants, de gérer leur état et leur comportement. Elle facilite l’écriture d’interfaces utilisateurs enfournissant une bibliothèque de contrôles :

– Simples : zones de saisie classiques, boutons, liens hypertextes.– Complexes : tableaux de données– Elle permet même de créer ses propres composants, ou d’enrichir les composants existants.

JSF permet principalement de :



– Faciliter le développement de pages web grâce à un Framework basé sur les composants.– De fournir un framework simple pour gérer ces composants, leurs interactions et leurs cycles

de vie.– Gérer les événements.– Valider coté serveur.– Définir la navigation des pages.– Automatiser au maximum la génération de code du coté client afin de ne pas avoir à se soucier

des différences entre chaque navigateur.JSF étant une simple spécification il existe de nombreuses implémentations celle qui a été retenue estcelle de Sun.

II.4 Base de données

II.4.1 MySQL

Ce célèbre système de gestion de données est très connu, son utilisation fut donc indispensable pourla partie Backend de l’application, en effet un des critères de choix, fut en premier lieu un SGBD re-lationnel compte tenu du cursus universitaire certains membres du groupe possèdent déjà un bonneexpérience sur ce genre de service.Aussi Mysql possède une bonne documentation et une communauté active autour de ce moteur, cequi rend le tout très agréable. Après les phases de test en local qui ont été relativement pénibles auvu des configurations de nos stations de travail et pour plus de confort, une concertation avec l’ad-ministrateur réseau du mbds (Mr Harris DAHON) sur les besoins et contraintes en matière de base dedonnées à débouché sur une base accessible partout et à tout moment. En fin de journée, un serveurMySql était et est toujours disponible sur la machine : http://neptune.unice.fr

Le serveur de base de données est un point très critique de l’application. En effet il contient toutesles données utiles pour l’application mobile. Sans la base de données, l’application est inutilisable.C’est pour cela qu’il serait important et indispensable de mettre en place un système de réplicationde données, serveur miroir, configuration des backups des tables.

De même pour la configuration des droits des utilisateurs sur la base et des paramètres comme lenombre maximum de connexions simultanées sur la base, le nombre maximum de connexions d’unclient par heure (pour éviter certaines attaques automatiques de robot ou de hack).


http://neptune.unice.fr


La base est constituée de cinq tables qui ensemble constituent la partie persistante de l’applicationmobile. Le découpage en cinq tables semble tout a fait valable, en effet type, commentaire, poi, tagréprésentent quatre entités bien distinctes reliées grâce à une clé étrangère.

La table ter_android.poi décrit et représente l’objet virtuel affiché pendant la réalité augmentée. Unpoi est un point d’intérêt possédant absolument des coordonnées géographiques.

La table type permet de filtrer les poi suivant leur utilisation, immobilier, valrose1913 etc...

II.5 Communication

II.5.1 Serveur-BDD

JPA 2.0

La Java Persistence API est une interface de programmation Java permettant aux développeursd’organiser des données relationnelles dans des applications utilisant la plateforme Java.

La persistance dans ce contexte recouvre 3 zones :– L’API elle-même, définie dans le javax.persistence package– Le langage Java Persistence Query (JPQL)– L’objet/les métadonnées relationnelles

Principales propriétés de JPA :– Pas de code spécial lié à la persistance à implémenter dans le classes, les objets POJO (Plain Old

Java Object) peuvent être persistants.– L’utilisation d’annontations.– Des appels simples de haut niveau permettent de gérer la persistance, tels que persist(objet)

pour rendre un objet persistant.– Les données de la base peuvent être accédées avec une vision « objet ».



EclipseLink

EclipseLink est un framework open source de mapping objet-relationnel pour les développeurs Java.Il fournit une plateforme puissante et flexible permettant de stocker des objets Java dans une base dedonnées relationnelle et/ou de les convertir en documents XML.EclipseLink est dérivé du projet TopLink de la société Oracle. Il supporte un certain nombre d’APIrelatives à la persistance des données et notamment la JPA.

Pourquoi EclipseLink ?

Plusieurs raisons nous ont amenés a choisir EclipseLink comme Implémentation de JPA :– La raison principale est qu’il s’agit de l’implémentation de référence de JPA 2.0.– De plus c’est le framework supporté nativement par GlassFish v3.– C’était aussi le framework sur lequel nous avions le plus d’expérience. Ceci grâce à l’ensei-

gnement reçu au cours de notre formation durant l’UE "Persistence" délivrée par Mr RichardGRIN.

II.5.2 Client-Serveur

Web Services

Pour assurer la communication entre la base de données et le client mobile le choix s’est porté surle développement de servlets.

Les servlets ont de nombreux avantages par rapport aux autres technologies côté serveur. Toutd’abord, étant donné qu’il s’agit d’une technologie Java, les servlets fournissent un moyen d’amé-liorer les serveurs web sur n’importe quelle plateforme, d’autant plus que les servlets sont indépen-dantes du serveur web (contrairement aux modules apache ou à l’API Netscape Server).En effet, les servlets s’exécutent dans un moteur de servlet utilisé pour établir le lien entre la servlet etle serveur web. Ainsi le programmeur n’a pas à se soucier de détails techniques tels que la connexionau réseau, la mise en forme de la réponse HTTP, ...

Enfin une servlet étant une application Java, peut utiliser toutes les API Java afin de communiqueravec des applications extérieures, se connecter à des bases de données, accéder aux entrée-sorties(fichiers par exemple).



Quatre servlets sont accessibles à partir du serveur :– Servlet d’ajout de commentaire : Permet d’ajouter un commentaire dans la base de données en

spécifiant en paramètre l’id d’un POI.– Servlet de récupération des commentaires : Permet de récupérer tous les commentaires en spé-

cifiant en paramètre l’id d’un POI.– Servlet de récupération des POIs : Permet de récupérer soit tous les POIs soit un ensemble de

POIs en spécifiant en paramètre le type souhaité.– Servlet de récupération des types : Permet de récupérer tous les types de POIs à partir de la

base de données.Chaque servlet renvoie ses résultats au format XML.

Serialisation XML

La sérialisation XML possède plusieurs différences avec la sérialisation binaire. La plus évidenteest que les données générées le sont dans un format textuel (XML) et non binaire. Ensuite la séria-lisation XML a été spécialement conçue pour être utilisée avec les JavaBeans ce qui apporte certainsavantages mais aussi certaines limitations.

Avantages :– La portabilité : il n’y a aucune dépendance avec l’implémentation propre des classes qui peuvent

donc être échangées entre différentes VMs de différents fournisseurs.– Les documents XML générés sont compacts grâce à l’utilisation d’un algorithme d’élimination

des redondances (par exemple les attributs ayant leur valeur par défaut ne sont pas écrits).– La tolérance aux fautes : si une erreur non structurelle est détectée, la partie affectée n’est pas

prise en compte.– Étant un document XML, le résultat est lisible par l’humain et exploitable par d’autres pro-

grammes.

SAX

Simple API for XML ou SAX est une API générale pour la lecture d’un flux XML.



Il existe des implémentations de cette API dans tous des langages tels que C++, C#, Java, Pascal,perl, PHP, car XML s’est largement imposé aujourd’hui dans le monde du logiciel pour l’échanged’informations.

Il existe deux grandes API pour relire les flux XML : DOM et SAX.

SAX est événementielle alors que DOM transforme l’arborescence XML en arborescence du lan-gage cible. L’intérêt majeur de DOM est donc la possibilité qu’il offre d’aller et venir à votre gré dansl’arborescence, son inconvénient majeur reste la lourdeur du traitement. En effet, SAX étant événe-mentiel, son traitement se fait au fil du flux entrant.

La légèreté et la rapidité d’exécution du parseur SAX à été un choix majeur étant donné qu’il doits’exécuter sur une appareil mobile.


Troisième partie

Implémentation


Cette partie présente l’implémentation des différents choix de conception de manière non ex-haustive. Ils sont ordonnés par ordre de dépendances. La premiere section abordée est la persistancequi est utilisée par les webs services et l’interface d’administration présentés ensuite. Cette partie setermine par la présentation de l’implémentation du client mobile.

III.1 Persistance

L’implémentation de la persistence est basé sur l’utilisation des patterns les plus courants.

III.1.1 Les entitées

Les entitées sont déclarées dans le fichier « persistence.xml »<?xml version="1.0" encoding="UTF-8"?><persistence version="1.0"xmlns="http://java.sun.com/xml/ns/persistence"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/

xml/ns/persistence/persistence_1_0.xsd"><persistence-unit name="DAO_AndroidPU" transaction-type="RESOURCE_LOCAL">

<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider><class>persistence.entites.Commentaire</class><class>persistence.entites.POI</class><class>persistence.entites.Tag</class><class>persistence.entites.Type</class><class>persistence.entites.TerAndroidUser</class>...

</persistence-unit></persistence>

Et voici un exemple de comment ces entités sont définies, simplement en utilisant les annotationsde JPA.extrait de « POI.java » :

...@Entity@Table(name = "poi")public class POI implements Serializable {

@Id@GeneratedValueprivate int id;@ManyToOneprivate Type type;@OneToOne(cascade = CascadeType.PERSIST)private Tag tag;private double latitude;private double longitude;private double altitude;private String name;@Column(length=2000)private String description;private String link;private String detailAction;private String iconResource;private String iconUri;@OneToMany(mappedBy = "poi", cascade = CascadeType.ALL)private List<Commentaire> comments;

...



III.1.2 Pattern DAO

Ce pattern permet de faire le lien entre la couche d’accès aux données et la couche métier d’uneapplication. Il permet de mieux maîtriser les changements susceptibles d’être opérés sur le systèmede stockage des données, donc, par extension, de préparer une migration d’un système à un autre(BDD vers fichiers XML par exemple...).Ceci se fait en séparant accès aux données (BDD) et objets métiers (POJO).

III.1.3 Pattern Factory

L’utilisation de ces patterns nous permet de déléguer l’instanciation des DAOs a une factory etainsi de prévoir un possible changement de Base de données dans le futur.Ces modèles de conceptions améliorent l’indépendance vis-à-vis du type de persistance.



III.2 Interface d’administration

III.2.1 Java Server Faces Configuration

Comme beaucoup de framework Java JSF utilise le XML comme moyen de configuration.

web.xml

Il faut définir comme dans toute application web les paramètres de contexte de JSF dans le fichier« web.xml »

...<context-param>

<param-name>javax.faces.STATE_SAVING_METHOD</param-name><param-value>client</param-value>

</context-param><context-param>

<param-name>javax.faces.PROJECT_STAGE</param-name><param-value>developpement</param-value>


<param-name>com.sun.faces.resourceUpdateCheckPeriod</param-name><param-value>-1</param-value>


<param-name>com.sun.faces.validateXml</param-name><param-value>true</param-value>

</context-param><servlet>

<servlet-name>Faces Servlet</servlet-name><servlet-class>javax.faces.webapp.FacesServlet</servlet-class>

</servlet><servlet-mapping>

<servlet-name>Faces Servlet</servlet-name><url-pattern>/AndroidTer/*</url-pattern>

</servlet-mapping>...

faces-config.xml

Cependant JSF possède son propre fichier de configuration. Il sert a définir les règles de naviga-tion. Mais aussi a déclaré les Managed-Bean qui sont en fait nos composants.

<?xml version="1.0"?><faces-config xmlns="http://java.sun.com/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://java.sun.com/xml/ns/javaeehttp://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"version="2.0">

<managed-bean><managed-bean-name>defaultController</managed-bean-name><managed-bean-class>controller.Controller</managed-bean-class><managed-bean-scope>session</managed-bean-scope>

</managed-bean>...</managed-bean>

</faces-config>



III.2.2 Connexion

Login

Avant de pouvoir utiliser l’interface de gestion l’utilisateur doit se connecter à l’aide d’un login

mot de passe.

<h:form><h:outputLabel value="Login : " /><h:inputText value="#{userController

.login}" /><h:outputLabel value="Password : "

/><h:inputSecret value="#{

userController.password}" /><h:commandButton value="Connection"

action="#{userController.checkLogin}"/>

<br /><h:outputLabel value="#{

userController.message}" /></h:form>

Au moment de l’authentification seule le DAO des utilisateurs est instancié.

Singleton

Pour s’assurer qu’il n’y ai qu’une connexion d’ouverte par utilisateur, l’application utilise le pat-tern Singleton.

...public class ConnectionMySQL implements Serializable {

private static ConnectionMySQL connMySQL;

...

private ConnectionMySQL() {}

...

public static ConnectionMySQL getConnMySQL() {if (connMySQL == null) {

connMySQL = new ConnectionMySQL();}return connMySQL;}

...}

Session

Si l’authentification est reussi la connexion est mise en session. Pour celà il faut récuprer le contextde JSF le FacesContext et recupérer la session et y ajouter un attribut.

public static HttpSession getSession() {return (HttpSession) FacesContext.getCurrentInstance().getExternalContext

().getSession(true);}...getSession().setAttribute("connection", ConnectionMySQL.getConnMySQL());



III.2.3 Le composant de gestion des types

Cette sous section presente les deux parties d’un composant le controller et la vue.

Le controller

...@ManagedBean@SessionScopedpublic class TypeController extends Controller {

private Type type = null;private transient DataModel types = null;private transient DataModel superTypes = null;private String superTypeString = "";

public TypeController() {super();refreshTypes();

}

private void refreshTypes() {superTypes = new ListDataModel();types = new ListDataModel();if (UserController.getIsConnect(null)) {

types.setWrappedData(getSessionConnection().getTypeDAO().findAll());}}

public String index() {if (!UserController.getIsConnect(null)) {

return "index";}refreshTypes();type = null;return "typelist";}

...

La vue

<ui:composition template="typetemplate.xhtml"><ui:define name="pageTitre">Index Type</ui:define><ui:define name="contenuTitre">Index Type</ui:define><ui:define name="content">

<h:form styleClass="jsfcrud_list_form"><h:dataTable var="row" value="#{typeController.types}" border="0"

cellpadding="2" cellspacing="0" rowClasses="jsfcrud_odd_row,jsfcrud_even_row" rules="all"><h:column>

<f:facet name="header"><h:outputText value="Type"/>

</f:facet><h:outputText value="#{row}" /></h:column><h:column>

<f:facet name="header"><h:outputText value="Commande"/>

</f:facet> <h:commandLink action="#{typeController.modifierDetail}">



<h:graphicImage style="border: 0px" value="resources/img/icon/edit-icon.jpg"/>

</h:commandLink> <h:commandLink action="#{typeController.delete}">

<h:graphicImage style="border: 0px" value="resources/img/icon/delete-icon.png"/>

</h:commandLink></h:column>

</h:dataTable></h:form>

</ui:define></ui:composition>

III.3 Web Services

La servlet GetPOI :– Fonction : Cette servlet renvoie un ensemble de POIs en fonction du type passé en paramètre.– URL d’appel : http://neptune.unice.fr:8080/DAO_Servlet_Android/GetPOI?type=all

– Type de réponse : Renvoi la sérialisation en XML d’une liste de POI.

La servlet GetComment :– Fonction : Cette servlet renvoie un ensemble de Commentaire liés à un POI donc l’id est passé

en paramètre.– URL d’appel : http://neptune.unice.fr:8080/DAO_Servlet_Android/GetComment?poiId=3

– Type de réponse : Renvoi la sérialisation en XML d’une liste de Commentaire.

La servlet addComment :– Fonction : Ajoute un commentaire sur un POI dans la base de données.– URL d’appel : http://neptune.unice.fr:8080/DAO_Servlet_Android/AddComment?author=anthony&date=02/11/1988&comment=mon+message&poiId=3

– Type de réponse : Aucune.

La servlet GetType :– Fonction : Cette servlet renvoie tous les types des POIs présent dans la base de données.– URL d’appel : http://neptune.unice.fr:8080/DAO_Servlet_Android/GetType– Type de réponse : Renvoi la sérialisation en XML d’une liste de type.

Algorithme de fonctionnement : Chaque servlet instancie une connexion à la base de données,récupère un objet DAO et interroge la base de données. Enfin grâce à la classe XMLEncoder présentedans le langage Java, l’objet récupéré est sérialisé puis envoyé dans le flux de sortie de la servlet.

III.4 Application TouchView

III.4.1 NFC

Rappel : Cette partie n’est pas encore implémentée car les stickers TwinLinx ne sont pas encoredisponibles. Pour le moment l’application ne fait que simuler le contact d’une carte NFC.


http://neptune.unice.fr:8080/DAO_Servlet_Android/GetPOI?type=all

http://neptune.unice.fr:8080/DAO_Servlet_Android/GetPOI?type=all

http://neptune.unice.fr:8080/DAO_Servlet_Android/GetComment?poiId=3

http://neptune.unice.fr:8080/DAO_Servlet_Android/GetComment?poiId=3

http://neptune.unice.fr:8080/DAO_Servlet_Android/AddComment?author=anthony&date=02/11/1988&comment=mon+message&poiId=3

http://neptune.unice.fr:8080/DAO_Servlet_Android/AddComment?author=anthony&date=02/11/1988&comment=mon+message&poiId=3

http://neptune.unice.fr:8080/DAO_Servlet_Android/GetType


Lorsque TouchView est lancé et que l’utilisateur appuie sur le bouton Touch, une requête est en-voyée à une servlet pour interroger la BD est récupérer sous la forme d’un fichier XML le POI corres-pondant à l’UUID.Le POI est déserialisé coté mobile à l’aide du parser SAX puis l’Activity NFC est instanciée et affichetoute les informations liées au POI.

Exemple de l’Activity NFC avec le POI du château Valrose. On voit apparaître à l’écran le titredu POI, une image du château, une courte description et un lien internet correspondant au POI quipermet d’ouvrir le navigateur web du mobile.

Un menu est disponible pour pouvoir utiliser les deux réseaux sociaux disponibles dans Touch-View à savoir Facebook et Twitter mais aussi pour laisser un commentaire qui sera stocké sur la BDdu projet.

Le bouton "Ajouter Commentaire" ouvre une Activity présentant un formulaire l’utilisateur entreson nom et le commentaire puis valide.Le nom et le commentaire sont alors encodés au format HTML avec l’encodage "utf-8" et transmis enparamètre d’une servlet pour être stockés dans la base de données.



Le bouton "Voir Commentaires" ouvre une ListActivity répertoriant tous les commentaires liés auPOI. Les commentaires sont récupérés à l’aide d’une servlet hébergée sur le serveur d’application.

Exemple de code XML retournant une liste de commentaires :

<?xml version="1.0" encoding="UTF-8"?><java version="1.6.0_17" class="java.beans.XMLDecoder"><object class="java.util.Vector"><void method="add"><object class="dao_android.entites.Commentaire"><void property="author"><string>Anthony</string>

</void><void property="comment"><string>J’adore le chateaux de Valrose</string>

</void><void property="date"><object class="java.util.Date"><long>594428400000</long>

</object></void><void property="id"><int>201</int>

</void></object>

</void></object>

</java>

Le bouton "Facebook" lance une Activity déjà présente dans l’api fb-connect. L’api fournit tous lesoutils pour se connecter et publier sur son propre mur Facebook.

Intent intentFb = new Intent(Nfc.this, FacebookActivity.class);startActivity(intentFb);

Ce bout de code permet de lancer l’Activity Facebook à partir de la vue NFC.

Le bouton "Twitter" permet de lancer une boite de dialogue de connexion. Un objet Twitter estinstancié pour vérifier la connexion.Si la connexion est valide, l’utilisateur peut alors écrire le contenu de son Tweet et l’envoyer.

Twitter twitter = new Twitter(user,password);twitter.setStatus("Mon message");

Code permettant la connexion et l’envoi d’un tweet avec l’api Twitter.



III.4.2 Realite Augmentée

Pour la vue Réalité Augmentée, il a fallu tout d’abord enregistrer l’application auprès de Wiki-tude pour obtenir une clé afin de ne plus avoir l’inscription «BETA» visible sur la vue Caméra sil’application n’est pas enregistrée.

Lorsque l’application TouchView est lancée et que l’utilisateur appuie sur le bouton View, l’utili-sateur se retrouve dans l’activity AugmentedReality, ici, il a le choix entre les différents types de POIqui sont stockés dans la base de données (Immobilier, Valrose ...).

Une fois le type de POI selectionné, une requete est envoyée à une Servlet pour interroger la BD etrécuperer sous la forme d’un fichier XML les POI du type choisi présents dans la base de données. LesPOI sont déserialisés coté mobile à l’aide du parser SAX puis, la vue Wikitude (réalité augmentée)est lancée avec les POI de la base de données.

– La vue réalité augmentée est lancée avec la méthode : startARViewBasic(), et les POI sont ajou-tés à la vue avec le constructeur :

– new WikitudePOI(double latitude, double longitude, double altitude, String name, String des-cription, String link, String detailAction, String iconresource, String iconuri) les paramètresétant bien sûr ceux récuperes par la requete sur la base de donnees. Le detailAction est le nom

de l’activity qui sera lancé par le bouton visible lorsqu’un POI est selectionné.

wikiPoi.setDetailAction("wikitudeapi."+poi.getDetailAction());

Il est cependant obligatoire de préfixer les detailAction des POI par «wikitudeapi.» (définis parl’API Wikitude).



Dans cette vue l’utilisateur peut parcourir les différents POI, ces derniers representent la localisa-tion de l’objet réel, une fois selectionné l’utlisateur peut se rendre sur le site web du POI (clic sur le

bouton ), lancer l’activity du POI (clic sur le bouton ), ou bien faire défiler tous les POIprésents dans la vue.

Lors du lancement de l’activity du POI, l’utilisateur se retrouve sur une nouvelle activité où il aune galerie contenant les différentes images du POI ainsi que la description de ce dernier.


Conclusion

A la date de rendu le vendredi 27 mai, le cahier des charges global a été respecté, tout a long dudéveloppement du projet le planning et plus particulièrement les sous objectifs hebdomadaires ontété strictement tenus. La répartition des tâches entre les membres de l’équipe a joué un rôle crucialpermettant ainsi une bonne cohésion du groupe et un travail efficace.

Cependant certains problèmes techniques ont empêché de rendre l’application totalement fonc-tionnelle. Le plus important étant celui du sticker NFC, pour le système Android, de la société Twin-lix, qui est encore au stade de développement (Aucune version bêta disponible). De même pour l’APIWikitude.

Tout naturellement, l’application peut être sujet a des modifications et optimisation. Bien entendu,l’implémentation de la nouvelle version de l’API Wikitude et du Sticker NFC pourront faire l’objetde futurs travaux.

Une idée d’amélioration serait une utilisation en mode déconnecté. La conception d’une base in-terne au téléphone grâce a SQLite, permettant à l’utilisateur de se synchroniser avec le serveur etd’enregistrer tous les POIs disponibles sur son mobile. Cette nouvelle fonctionnalité est pratiquepour le client. En effet, suivant la situation géographique de l’utilisateur, la connexion 3G et un ré-seau Wifi ne sont pas toujours disponibles.

Étant donnée la motivation du groupe, ce projet de fin d’année fut une très bonne expériencehumaine et une découverte d’un domaine en pleine expansion, le monde de la mobiquité.

Références

Voici une liste non exhaustive des références des documentations utilisées pour l’étude et le dé-veloppement de ce projet :

– Eclipse, http://eclipse.org– Netbean, http://netbeans.org– GlassFish v3, https://glassfish.dev.java.net/– Java Server Faces 2.0, http://java.sun.com/javaee/javaserverfaces/– MySQL,http://www.mysql.com/– JPA, http://java.sun.com/developer/technicalArticles/J2EE/jpa/– EclipseLink, http://www.eclipse.org/eclipselink/– API Facebook, http://code.google.com/p/fbconnect-android/– API Twitter, http://www.winterwell.com/software/jtwitter.php– API Wikitude, http://www.wikitude.org/developers– Twinlix, http://www.twinlinx.com/– Android, http://android.comhttp://developer.android.com/index.html

– HTC, http://www.htc.com/www/product/desire/overview.html

http://eclipse.org

http://netbeans.org

https://glassfish.dev.java.net/

http://java.sun.com/javaee/javaserverfaces/

http://www.mysql.com/

http://java.sun.com/developer/technicalArticles/J2EE/jpa/

http://www.eclipse.org/eclipselink/

http://code.google.com/p/fbconnect-android/

http://www.winterwell.com/software/jtwitter.php

http://www.wikitude.org/developers

http://www.twinlinx.com/

http://android.com

http://developer.android.com/index.html

http://www.htc.com/www/product/desire/overview.html

Documents

Realit´ e augment´ ee avec Google Android´deptinfo.unice.fr/twiki/pub/Minfo/Rapports09-10/TER-10bontempsga… · La fréquence utilisée par le NFC est de 13,56 MHz et peut atteindre