Polytech`Nice Sophia DÉPARTEMENT SCIENCE INFORMATIQUE ...

quaggaholeInternet και Εφαρμογές Web

15 Αυγ 2012 (πριν από 5 χρόνια και 1 μήνα)

352 εμφανίσεις

Polytech`Nice Sophia

DÉPARTEMENT SCIENCE INFORMATIQUE

RAPPORT DE SEMAINE DE PROJET
SESSION 2009 - 2010

Il s'agit de développer une application de co-voitu rage. Le service sera accessible aux clients
iPhone. Un serveur gère les données relatives au co -voiturage.


Présenté par :
Mikaël Ribas
Anthony Roux
Jérémy Templier
Dylan Varenne



Sous la direction de :
M. Peter Sander

2

Sommaire
I. Introduction ................................................................................................................................... 3
II. Remerciements ............................................................................................................................ 4
III. Cahier des charges ..................................................................................................................... 5
1) Objectifs ................................................................................................................................... 5
2) Spécification ............................................................................................................................. 5
3) Fonctionnalités ......................................................................................................................... 5
4) Environnement ......................................................................................................................... 5
5) Technologie .............................................................................................................................. 5
IV. Planning ...................................................................................................................................... 6
1) Planning prévisionnel ............................................................................................................... 6
2) Planning réel ............................................................................................................................ 6
V. Technologies utilisées ................................................................................................................. 7
1) Google App Engine .................................................................................................................. 7
2) Objective C ............................................................................................................................... 7
3) Property list .............................................................................................................................. 7
VI. Partie serveur ............................................................................................................................. 8
1) Choix du serveur ...................................................................................................................... 8
2) Mise en place ........................................................................................................................... 8
3) Fonctionnement du serveur ...................................................................................................... 8
4) Tâches automatiques (Cron Jobs) ........................................................................................... 9
5) Cas particulier de la répétition d’un même traje t (Périodicité) .................................................. 9
VII. L’interface de l’application ....................................................................................................... 10
VIII. Liaison iPhone – serveur ........................................................................................................ 12
IX. Perspectives ............................................................................................................................. 13
X. Conclusion ................................................................................................................................. 14
XI. Bibliographie ............................................................................................................................. 15


3

I. Introduction

La société de consommation nous amène de plus en pl us à la pollution. Les voitures sont souvent
utilisées à tort et même avec le développement des transports en commun, le changement de la
situation n’est pas souvent significatif.
Nous ne nous voulons pas sauver la planète, mais y contribuer à notre échelle en proposant d’unir
les gens et de tisser petit à petit, un réseau soci al où le covoiturage serait la pierre fondatrice.
L’iPhone étant le téléphone tendance sur le marché, nous pensions toucher un maximum de
personnes en proposant une application sur ce support. C’est ainsi qu’est né iCovoit.


4

II. Remerciements
Nous tenions à remercier M. Peter SANDER pour son s outien, son suivi et ses bons conseils pour
la rédaction du rapport ainsi que du diaporama de l ’oral.
Nous remercions également Mappy de nous avoir fourn i le kit de développement gratuitement et
en avant-première.
Nous remercions l’école Polytech’Nice-Sophia d’avoir mis à notre disposition un ordinateur MAC,
indispensable pour développer sous iPhone.
5

III. Cahier des charges

1) Objectifs
Il d’agit de développer une application iPhone afin de contribuer à sauver la planète.
2) Spécification
Il y a deux catégories d’utilisateurs :
• Ceux qui ont une voiture et qui proposent un covoiturage,
• Ceux qui n’ont pas de voiture et qui cherchent un covoiturage.
N’importe quel utilisateur peut :
• Consulter les covoiturages disponibles,
• Modifier les informations, proposer un covoiturage, s’enregistrer sur un covoiturage…
3) Fonctionnalités
Trajet proposé :
• Point de départ,
• Point d’arrivée,
• Heure de départ,
• Fréquence du trajet,
• Nombre de places disponibles,
• Informations relatives à la personne qui propose le trajet.
Trajet demandé :
• Point de départ,
• Point d’arrivé,
• Heure de départ,
• Fréquence du trajet,
• Nombre de places disponibles,
• Informations relatives à la personne qui a besoin du trajet.
Les informations peuvent être :
• Postées sur le site,
• Modifiées,
• Supprimées.
Seulement la personne qui est à l’origine du traje t a le droit de modifier les informations ou de les
supprimer.
4) Environnement
• Accès client par navigateur web (avec code généré par Google Web Toolkit (GWT),
• Utilisation de Google App Engine pour le serveur.
Il serait vraiment appréciable de pouvoir afficher les trajets sur Google Maps.
5) Technologie
• Apple iPhone développement kit.

6

IV. Planning

1) Planning prévisionnel
Nous avions prévu une répartition du travail et des taches comme ceci :

2) Planning réel
Nous avons été assez fidèles à notre planning, même si bien sur nous avons eu des imprévus :

Ce qui n’apparait pas sur le calendrier et qui doit être souligné est une initiative que nous avons
voulu prendre au début du projet et qui tout au lon g de celui-ci nous a quelque peu retardé.
En parcourant sur internet les différentes façons d e gérer l’affichage de la carte et parce que
l’affichage avec Google Maps ne permet pas de tracer des itinéraires et de faire de décomposer
un trajet en étapes, nous avons trouvé un kit de dé veloppement en version de test chez Mappy.
Des le deuxième jour du projet nous avons téléphoné à Mappy afin d’obtenir leur kit de
développement, même s’ils avaient l’air réceptifs à notre demande et devaient nous rappeler,
nous n’avions aucune réponse le lendemain c’est pourquoi nous les avons relancés tous les jours
de la semaine. Il s’en est suivi de nombreux problèmes tel qu’une mauvaise coordination de leur
coté entre le service commercial et le service tech nique, l’activation de notre compte qui ne
marchait pas mais aussi un problème avec leur serve ur. Ce n’est qu’en fin de la deuxième
semaine de projet (le 29 janvier) que nous avons enfin la possibilité de commencer à développer
avec leur API.

7

V. Technologies utilisées

1) Google App Engine
Dans un premier temps il a fallu comprendre comment marchait Google App Engine, ce n’est pas
une base de donnée au sens SQL, le stockage des don nées nous est masqué, pour nous ce sont
des objets JAVA sérializables ( datastore). Il est possible d’envoyer des mails via le compte
Google avec lequel on a créé l’application.
2) Objective C
Ensuite il nous a fallu appréhender un nouveau lang age de programmation, l’Objective C.
L'Objective C est un langage de programmation orienté objet réflexif. C'est une extension du C
ANSI, comme le C++, mais qui se distingue de ce dernier par sa distribution dynamique des
messages, son faible typage, son typage dynamique et son chargement dynamique.
Contrairement au C++, il ne permet pas l'héritage m ultiple mais il existe toutefois des moyens de
combiner les avantages de C++ et d'Objective C.
3) Property list
Un fichier pList est un fichier XML avec une DTD spécifique fournie par Apple. La balise racine
doit être nommée
pList
et contenir une balise
dict
(pour dictionnaire). Ensuite le fichier doit être
formé d’une succession de clés/valeurs, et peut également contenir des tableaux de valeurs (mis
en place grâce à la balise
array
).
Ces fichiers sont généralement utilisés pour sauvegarder les propriétés d’une application.

8

VI. Partie serveur

1) Choix du serveur
Pour le serveur il a fallu faire un choix. Nous pensions utiliser un serveur MySQL, mais après
réflexion et la découverte de Google App Engine nou s avons opté pour celui-ci car c’est une
technologie novatrice qui, nous le pensons, a un avenir très prometteur. De plus elle ne demande
aucune installation, pas de configuration d’une base de données ou d’un serveur web et propose
une version gratuite le tout avec la performance et la sécurité de Google.
2) Mise en place
Google App Engine est un service de Google proposé depuis peu en Java. Il permet dans la
même optique que Google Web Toolkit de développer s on application en java ou en python puis
de les mettre sur les serveurs de Google. Afin d’utiliser cette technologie il faut créer un compte
Google puis activer ce compte pour Google App Engine. Alors dans la rubrique Gestion du
compte apparait un lien vers « My Applications ». O n y voit les applications qu’on a déjà mises en
ligne.
Afin de développer des applications il faut télécha rger la SDK ou installer le plugin éclipse. Nous
avons utilisé le plugin éclipse. Il suffit ensuite de créer un nouveau projet de type « Web
Application ». L’utilisation de Google Web Toolkit en même temps est possible.
A l’aide des tutoriaux et exemples disponibles sur le site de Google il est possible d’utiliser les
différentes fonctionnalités proposées.
http://code.google.com/intl/fr/appengine/docs/java/gettingstarted/introduction.html
Grâce à éclipse il est possible de tester en local l’application avec une simulation de la base de
données (Visible à localhost/_ah/admin). Lorsque to ut fonctionne on clique sur « Deploy » et
grâce à nos identifiants l’application est « déploy ée » sur internet.
3) Fonctionnement du serveur
Le serveur reçoit un événement de l’iPhone par une requête HTTPS en GET (avec tous les
paramètres et le type de la requête). Le code JAVA du serveur (servlet) s’occupe de récupérer les
paramètres et d’appeler la bonne méthode du Datastore. C’est cette méthode qui est alors
chargée d’effectuer l’action demandée (en interract ion avec la base de données), de créer le
fichier pList et de le renvoyer à l’iPhone.
Par exemple, pour obtenir les trajets d’un utilisateur, l’iPhone envoi la requête suivante :
https://icovoitur.appspot.com/user?type=getTrajets&pseudo=lambda
Le but de la requête est donc d’obtenir tous les tr ajets d’un utilisateur. C’est le champ type qui
détermine l’action à effectuer, le pseudo de la per sonne étant « lambda ».
Le UserServlet est chargé de récupérer le type de la méthode à ap peler ainsi que les paramètres
dont elle a besoin et d’appeler cette méthode (se t rouvant dans DataBase). La méthode getTrajets
avec comme paramètre le string « lambda » sera alor s déclenchée. La méthode va alors
récupérer la liste des trajets de l’utilisateur dan s la base de données et créer le fichier pList qui
contiendra tous ces trajet, triés selon le fait qu’ il soit en conducteur ou en passager, elle
s’occupera ensuite de le renvoyer à l’iPhone.
9

Pour la gestion des trajets, nous avons mis en place le TrajetServlet et le fonctionnement sera le
même que décrit ci-dessus pour n’importe quelle act ion souhaitée.
4) Tâches automatiques (Cron Jobs)
Google App Engine permet de créer des tâches appelé es « Cron Jobs », qui se lanceront
automatiquement au moment voulu. Le « Cron Job » es t facile à mettre en place, on créé une
classe contenant le servlet qui s’occupe des traitements avec ou sans utilisation de la base de
donnée. Ensuite, il faut inscrire les informations relatives à la tâche dans le fichier web.xml servant
à déclarer les servlet et de les associer à une URL. Enfin, on créé (ou c omplète s’il existe déjà) un
fichier cron.xml où l’on déclare pour chaque tâche son URL (la même que celle qui est déclarée
dans web.xml), une description, une fréquence (quand se lancera la tâche) et enfin, il est aussi
possible la zone horaire dans laquelle on souhaite se positionner.
Nous avons voulu nous servir de cette technologie pour faciliter la gestion de l’application :
- tous les jours à 17h, on récupère tous les trajet s prévus le lendemain et un mail est envoyé à
tous les participants de chaque trajet.
- tous les jours à minuit, on supprime de la base d e données tous les trajets terminés. Cela évite
donc une surcharge de la base de données.
- tous les vendredis 23h59, on met à jour les traje ts périodiques pour la semaine suivante comme
décrit dans le paragraphe « Périodicité ».
5) Cas particulier de la répétition d’un même traje t (Périodicité)
La périodicité est sûrement le point sur lequel nou s avons le plus réfléchi. En effet, un trajet qui s e
répéterait plusieurs fois par semaine et sur 2 ou 3 risque de surcharger la base de données si l’on
ajoute tous les tuples d’un coup. Nous avons également pensé à ajouter une seul tuple avec une
liste de date, mais l’utilisateur aurait été obligé de s’ajouter à tous les trajets (le même trajet su r
les jours différents).
Nous avons donc opté pour une solution alternative : ajouter les trajets périodiques sur une
semaine seulement, supprimer les trajets terminés a u fur et à mesure et mettre à jour toutes les
semaines (pour le rajout des nouveaux trajets). Dans la classe Trajet, nous avons mis en place
trois attributs qui combinés, permettent une gestio n de la répétition du même évènement : jour,
dateEvenement et dateFin. jour est un entier décimal représentant un nombre binai re (sur 7 bits
donc jour peut prendre des valeurs entre 0 et 127). Si jour est égal à 0, il n’y a aucune périodicité,
on a donc la dateEvenement égale à la dateFin. Sinon, la démarche se fait en deux étapes :
- à l’ajout du trajet, on créé tous les trajets pou r la semaine courante (jusqu’au dimanche) en
parcourant bit à bit la variable jour convertie en binaire au préalable (si le bit est à 1, on ajoute le
trajet). On vérifie toujours que l’on ne dépasse pa s la date de fin du trajet périodique. Enfin, pour
les trajets ajoutés (qui sont la copie du trajet or iginal), on met la variable jour à 0 (pour éviter q u’ils
soient re-traités lors de la mise à jour hebdomadai re de la périodicité (voir paragraphe suivant)), et
la date de fin du trajet sera égale à la date du tr ajet pour que ce trajet soit considéré comme
unique (et ainsi être supprimé lors de la suppressi on quotidienne des trajets terminés ; on évite
une surcharge de la base de données).
- une fois par semaine, on met à jour la périodicit é des trajets. Pour cela on applique la même
démarche qu’à l’ajout, mais pour la semaine suivant e (du lundi au dimanche). Comme cette mise
à jour est faite le vendredi, cela laisse 2 jours a u minimum de latence pour que les utilisateurs
s’inscrivent au covoiturage.
10

VII. L’interface de l’application

Nous avons essayé de réaliser l’interface la plus e rgonomique possible en profitant des
fonctionnalités qu’offre l’iPhone, mais aussi qu’elle soit esthétique. L’icône de l’application est un e
voiture sur fond vert, le vert étant la couleur de l’écologie. Au lancement de l’application vous
pourrez voir un splash screen avec le nom du logiciel ainsi que son slogan. Vous arrivez ensuite
automatiquement sur la page de recherche de covoiturage.


Comme le montre l’image pour effectuer la recherche d’un covoiturage il faut spécifier la ville de
départ, la ville d’arrivée ainsi que la date à laqu elle on désire voyager. Le bouton situé à droite du
champ de « start town » permet de mettre comme lieu de départ l’endroit ou nous nous situons. Il
est possible d’effectuer une recherche de covoiturage sans être identifié au préalable (et donc
avoir créé un compte).
L’onglet « Profil » permet de se connecter à notre compte (et de le créer si cela n’a pas été encore
fait).
Après être identifié sur l’application nous avons l a possibilité de consulter la liste des covoiturage s
auxquels nous participons et ainsi pouvoir se supprimer d’un trajet, en consulter les participants et
ainsi obtenir des informations sur ces derniers. L’onglet « My covoits » permet aussi d’ajouter un
trajet que nous allons effectuer en tant que conducteur et ainsi proposer a des passagers de
s’ajouter, mais aussi l’inverse.
11

L’ajout d’un trajet nous demande donc de spécifier si nous sommes conducteur ou passager (si
nous proposons un trajet ou si nous en cherchons un), un titre, la ville de départ ainsi que la ville
d’arrivée, la date et l’heure de celui-ci, le nombre de places disponibles, la périodicité du trajet e t
sa description.
Le créateur d’un trajet (et seulement lui) a la pos sibilité de modifier les informations d’un trajet.
Un bouton « GPS » permet de tracer le trajet sur un e carte à l’aide de l’API de Mappy.
L’onglet « GPS » permet de consulter tous les covoi turages disponibles dans une ville et ainsi, s’y
ajouter si l’un d’eux nous intéresse.
Afin de faciliter la recherche de ville dans toute l’application nous avons mis en place un
correcteur d’adresse. Cela permet également une coh érence dans la base de données puisqu’il
ne peut donc pas y avoir d’erreur de saisie (on pourrait alors se retrouver avec des noms de villes
saisis différemment et cela poserait problème lors des recherches de trajets).
Un système de mail automatique a aussi été mis en p lace, il gère l’envoi systématique d’un mail la
veille du trajet à tous les participants du trajet afin de le leur rappeler.

12

VIII. Liaison iPhone – serveur

La communication entre un serveur et un iPhone peut se faire de différentes manières.
La première solution est d’utiliser la base de donn ées interne de l’iPhone (en SQLlite). Afin
d’utiliser cette solution le serveur doit traiter les données avant de les afficher et renvoyer une
succession de requêtes SQLlite qui permettront à la réception côté iPhone de reconstruire une
partie de la base de donnée. L’affichage côté serve ur ressemblera donc à du texte du type :
« CREATE TABLE trajet(id INTEGER PRIMARY KEY ASC,titre VARCHAR); INSERT INTO … »
Une autre alternative consiste à afficher des donné es en brut à la sortie du serveur et de les traiter
coté iPhone. Cette solution a l’avantage de limiter l’activité du serveur mais entraine un temps
supplémentaire côté iPhone pour traiter les données.
La dernière solution est de traiter les données côt é serveur et de les afficher sous forme XML.
Coté serveur le traitement n’est pas lourd et côté iPhone il sera faible. De plus Apple a favorisé le
traitement d’un type particulier de fichier XML (car il est utilisé pour les préférences dans leurs
applications) appelé « XML property list» ( pList).
Nous avons choisi cette dernière solution car après tests elle semble être la plus rapide.
Coté serveur nous avons implémenté une classe Parser qui permet de retourner un fichier pList
qui sera affiché sur la sortie standard du serveur. Sur l’iPhone on utilise des dictionnaires
(NSDictionnary) qui peuvent être initialisés à partir d’une URL.
Si le dictionnaire est nul c’est que le serveur ne répond pas. Si une erreur en rapport avec la
demande a lieu un dictionnaire contenant une clé error est retourné. Quand tout s’est bien passé
le dictionnaire contient les informations demandées accessibles par leurs clés ou si aucun retour
n’est attendu un dictionnaire vide pour confirmer que l’action a eu lieu.

13

IX. Perspectives

Avec du temps nous aurions voulu rajouter des fonctionnalités à l’application telle que pouvoir
décomposer un trajet en étape (comme sur le site de Mappy), et ainsi pouvoir guider l’utilisateur
avec une voix comme sur un GPS. Nous voulions aussi pouvoir laisser la possibilité au créateur
d’un trajet de pouvoir le modifier étape par étape (et ainsi pouvoir changer le trajet pour passer
prendre un nouveau passager par exemple).
Avec l’achat de la SDK de Mappy nous pourrions publier l’application sur l’Apple store et ainsi
diffuser mondialement notre application.
Nous avons essayé de mettre en place en plus des ra ppels par mail, l’envoi d’un SMS. Il n’existe
pas de service qui permet cela gratuitement, nous avons alors pensé à utiliser notre propre
numéro de téléphone (avec l’option SMS illimité) af in de gérer l’envoi, mais ce fut sans succès,
cependant il existe une API SFR qui permettrait cela, mais les prix sont très élevés.

14

X. Conclusion

Ce projet fut fort intéressant et enrichissant puis qu’il nous a permis de découvrir et d’utiliser de
nouvelles technologies telles que l’Objective C, Google App Engine et le kit de développement
Mappy.
Quant à l’application, elle est opérationnelle et t elle que nous la voulions (voire plus). Des
modifications pourront être apportées par la suite (voir paragraphe « Perspectives »), notre
principale ambition étant de la publier sur l’Apple Store afin que le projet universitaire devienne
concret et réel.

15

XI. Bibliographie

- www.programmez.com, Rubrique GAE
-
www.developer.apple.com

-
www.icodeblog.com

-
www.code.google.com/appengine

-
www.otierney.net/objective-c.html

- Projet « Touch engine »
Et tous les forums accessibles via le moteur de recherche Google.