Conception et developpement d'une application mobile Android e-location

République du Sénégal
Un Peuple - Un But - Une foi
********************
MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR ET DE LA RECHERCHE
UNIVERSITÉ GASTON BERGER DE SAINT-LOUIS
__________________
U.F.R DE SCIENCES APPLIQUÉES ET DE TECHNOLOGIE
___________________
Mémoire de Maitrise Informatique
Sujet : ‹‹ Conception et développement d’une application Android e-location››
Réalisé par :
Aly SECK
Sous l’encadrement de :
Pr Moussa LO (UGB)
Année académique : 2014/2015 N° d’ordre :

1
Nous vivons encore aujourd’hui au Sénégal avec cette idée, de moins en moins
justifiée et de plus en plus arrogante, que notre capacité d’innovation, en raison de
l’excellence de nos enseignants, de nos chercheurs et de nos ingénieurs, et de la qualité de
nos infrastructures, serait bien supérieure à celle des pays du Nord et de l’Est. Souvenez-vous
de la suffisance avec laquelle, au moment de la crise pétrolière, nous déclarions : “Nous
n’avons pas de pétrole mais nous avons des idées.” Il faut se rendre à l’évidence : nous
n’avons toujours pas de pétrole, mais nous ne sommes plus seuls à avoir des idées et des
capacités à les exploiter sous la forme d’applications concrètes au bénéfice du développement
économique et social. Voilà la nouveauté. Il s’agit d’un changement radical et irréversible
auquel nous devrons nous adapter.

2
Table des matières
AVANT-PROPOS.......................................................................................................................................... 6
INTRODUCTION GENERALE .......................................................................................................................... 7
CHAPITRE 1 : ETAT DE L’ART DES SOLUTIONS E-LOCATION ............................................................................. 8
INTRODUCTION .......................................................................................................................................... 8
I. DESCRIPTION DE L’EXISTANT ............................................................................................................... 9
I.1 KAYMU ............................................................................................................................................ 9
I.2 LAMUDI............................................................................................................................................ 9
I.3 EXPAT-DAKAR .................................................................................................................................. 9
II. LES LIMITES DE L’EXISTANT.................................................................................................................. 9
II.1 RESPONSIVE WEB DESIGN ................................................................................................................. 9
II.2 MENU COMPLEXE .......................................................................................................................... 10
III. NOTRE SOLUTION ........................................................................................................................ 10
CONCLUSION............................................................................................................................................ 10
CHAPITRE 2 : CAPTURE DES BESOINS.......................................................................................................... 10
INTRODUCTION .................................................................................................................................... 10
I. LES ACTEURS ................................................................................................................................ 11
I.1 L’ADMINISTRATEUR......................................................................................................................... 11
I.2 LE CLIENT ....................................................................................................................................... 11
I.3 LE FOURNISSEUR DE SERVICES .......................................................................................................... 11
II. LES DIAGRAMMES ........................................................................................................................ 11
II.1 DIAGRAMMES DE CONTEXTE ........................................................................................................... 12
II.2 DIAGRAMME DE USE CASE .............................................................................................................. 12
CONCLUSION........................................................................................................................................ 13
CHAPITRE 3 : ANALYSES DES BESOINS ........................................................................................................ 14
INTRODUCTION .................................................................................................................................... 14
I. ANALYSE DU CAS D’UTILISATION « CREER COMPTE»............................................................... 14
I.1 DESCRIPTION .................................................................................................................................. 14
II. ANALYSE DU CAS D’UTILISATION « CONTACTER FOURNISSEUR» .................................................. 15
II.1 DESCRIPTION................................................................................................................................. 15
II.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « CONTACTER UN FOURNISSEUR D’OFFRES » ....... 16
III. ANALYSE DU CAS D’UTILISATION « RETIRER UNE OFFRE»............................................................... 17
III.1 DESCRIPTION................................................................................................................................ 17
III.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « RETIRER UNE OFFRE » .............................. 18

3
IV. ANALYSE DU CAS D’UTILISATION « PROPOSER UNE OFFRE»........................................................... 19
IV.1 DESCRIPTION................................................................................................................................ 19
IV.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « PROPOSER UNE OFFRE»................................. 19
CONCLUSION ............................................................................................................................................ 20
CHAPITRE 4 : IMPLEMENTATION................................................................................................................ 21
INTRODUCTION ........................................................................................................................................ 21
I. ENVIRONNEMENT MATERIEL ....................................................................................................... 21
II. TECHNOLOGIES.................................................................................................................................. 21
II.1 NIVEAU 1 : LE CLIENT ANDROID............................................................................................................. 21
II.2 NIVEAU 2 : LE SERVEUR WEB ................................................................................................................. 22
1. POINT SUR LES SERVICES WEB.......................................................................................................... 22
POURQUOI CHOISIR SOAP ..................................................................................................................... 23
POURQUOI CHOISIR REST ?.................................................................................................................... 23
2. BACKEND AVEC GOOGLE APP ENGINE( GAE) .................................................................................... 24
 PRESENTATION.......................................................................................................................... 24
 L’ENVIRONNEMENT D’EXECUTION JAVA ........................................................................................ 24
 LA BASE DE DONNEES (DATASTORE)............................................................................................. 24
 GOOGLE CLOUD ENDPOINTS....................................................................................................... 25
 DESCRIPTION ET ARCHITECTURE DE LA SOLUTION A DEVELOPPER....................................................... 26
 LA SOLUTION A DEVELOPPER ....................................................................................................... 26
3. LA CREATION DU SERVEUR ET SA MISE EN PLACE : COTE SERVEUR ........................................................ 27
 CREER LE SERVEUR APP ENGINE................................................................................................... 27
 CREER L’APPLICATION ET LES WEB SERVICES................................................................................... 27
 LES DIFFERENTES COUCHES DE L’APPLICATION ................................................................................ 30
 L’ARCHITECTURE EN COUCHES DE L’APPLICATION APP ENGINE.......................................................... 31
II.3 NIVEAU 3: LE SERVEUR DE BASE DE DONNEES........................................................................................... 32
II.3.1 LE DATASTORE: NOTRE SERVEUR DE BASE DE DONNEES NOSQL .......................................................... 34
A. DESCRIPTION............................................................................................................................. 34
B. LE DATASTORE N’EST PAS UNE BASE DE DONNEES RELATIONNELLE .................................................... 34
C. FONCTIONNEMENT .................................................................................................................... 34
D. MANIPULER LES DATASTORE AVEC OBJECTIFY................................................................................... 39
E. MISE EN CACHE AVEC MEMCACHE ................................................................................................. 43
F. LES TRANSACTIONS...................................................................................................................... 44
III. CONCEPTION DE L’APPLICATION....................................................................................................... 45
IV. QUELQUES COMPOSANTES APPLICATIVES REALISEES ............................................................... 45

4
CONCLUSION ............................................................................................................................................ 48
CONCLUSION ET PERSPECTIVES .................................................................................................................. 49
Références bibliographiques............................................................................................................... 51

5
Liste des figures
Figure 1: Diagramme de contexte e-location........................................................................................ 12
Figure 2: Diagramme de case d’utilisations général ............................................................................. 13
Figure 3: Diagramme de séquence du cas d’utilisation « créer compte »............................................ 15
Figure 4: Diagramme de séquence du cas d’utilisation « contacter un fournisseur ».......................... 17
Figure 5: Diagramme de séquence du cas d’utilisation « retirer une offre » ....................................... 18
Figure 6: Diagramme de séquence du cas d’utilisation « retirer une offre » ....................................... 19
Figure 7: Un seul backend Endpoints avec plusieurs clients (Android, IOS, Firefox) .......................... 25
Figure 8: Architecture de la solution à développer............................................................................... 26
Figure 9: Model en couches de l'application à développer................................................................... 31
Figure 10: L'architecture de l'application App Engine (le backend)..................................................... 31
Figure 11: LE SERVEUR DE BASE DE DONNEES: les possibilités offertes par GAE................................. 32
Figure 12: Tableau comparatif SQL vs NoSQL ....................................................................................... 33
Figure 13: Fonctionnement du Datastore avec Objectify ..................................................................... 40
Figure 14: Exécution d'une requête dans le Datastore......................................................................... 44

6
AVANT-PROPOS
La quatrième année d'études en Informatique (Maitrise Informatique) à l'UFR des
Sciences Appliquées et Technologie de l'Université Gaston Berger de Saint Louis du Sénégal
se termine par un mémoire. Il sera l'occasion pour l'étudiant de montrer qu'il a acquis une
connaissance non seulement théorique mais aussi pratique de ces conventions. Ainsi dans ce
travail de fin de la maitrise en informatique, on a voulu associer trois grandes activités qui sont,
à la base, très éloignées l'une de l'autre mais qui, avec l'amélioration croissante des nouvelles
technologies, sont vouées à être fusionnées. Il s'agit de la programmation mobile Android, le
NOSQL et les services web.
Notre défi est donc de réaliser un projet innovant, utile et lié à l’actualité. Nous devons
développer une application mobile Android e-location. D'où l'objet de la rédaction du présent
rapport

7
INTRODUCTION GENERALE
Le Sénégal est un pays qui compte 14 993 125 [1] habitants et 43,68% [2] de la
population vivent dans les villes, principalement dans la capitale. Cette concentration de la
population dans les villes comme Dakar est due essentiellement au facteur économique. Parce
que, là se trouve la majeure partie des activités industrielles et commerciales mais aussi les plus
grandes infrastructures administratives et sanitaires. Ceci engendre un sérieux problème de
logements des populations qui y vivent. Face à cette situation, les bailleurs investissent dans le
domaine de la location, une activité lucrative. Ils proposent des offres de locations et alors un
autre problème se pose: la communication et/ou la publicité. Dans ce secteur, d’une part, le
citadin se demande comment trouver un bon logement satisfaisant à ses besoins, un logement
qui le convient à merveille. Et d’autre part, le propriétaire de logements se demande comment
trouver un preneur rapidement pour sa location. Face à cette situation, il est nécessaire de
trouver quelque chose qui peut mettre en rapport le citadin avec le bailleur que nous appelons
le fournisseur d’offres de locations, à faire passer son information à ceux qui sont à la recherche
d’une location, les clients. Donc une plateforme qui va permettre à ces clients de trouver le
logement de ses rêves en mettant à leur disposition non seulement des informations sur le
marché immobilier, mais aussi en les mettant en contact avec les fournisseurs d’offres de
locations.
L’application Android e-location doit être la solution escomptée. E-location sera
destinée à deux utilisateurs: d’une part un fournisseur qui propose des offres de location via son
compte dans l'application, il donne toutes les informations concernant l'offre : photo, adresse,
position géographique, prix. D’autre part un client qui, grâce à l'application, pourra voir les
offres proposées, avec options de recherche par ville, par quartier, par type d’appartement
(simple, R+1 ou R+2 …), et d’autres options pertinentes.
Traditionnellement, la première phase dans la réalisation d’un projet est de percevoir les
fonctionnalités qu’offrira notre application afin de définir un plan de conception évident pour
chacune, et discerner quels types d’utilisateurs pourront utiliser notre produit.
E-location n’échappera pas cette règle et de plus nous débuterons ce travail par une étude
préalable des solutions existantes pour ensuite passer à la conception et à la réalisation de notre
application. Ainsi ce présent rapport sera structuré en quatre (4) chapitres :
Dans le premier chapitre « Etat de l’art des solutions e-location », nous décrivons des solutions
existantes à savoir leurs philosophies ainsi que les limites de ces solutions. Et enfin, nous
critiquons l’existant et proposons une solution.
Dans le second chapitre intitulé «Capture des besoins », nous identifions les acteurs du futur
système, les besoins fonctionnels et non fonctionnels ainsi que les diagrammes de cas
d’utilisation et de contexte.
Dans le troisième chapitre « Analyse des besoins», nous faisons une analyse détaillée et
complète des cas d’utilisation repérés à travers le chapitre «Capture des besoins». Nous
élaborons ensuite une conception détaillée des cas d’utilisation et les diagrammes de séquence.
Dans le dernier chapitre intitulé « Implémentation », nous présentons l’environnement matériel
et logiciel, les technologies utilisées le passage vers le NOSQL, les services web, le cloud

8
Google App Engine et quelques-uns de ses APIs. Nous terminons ce chapitre par donner
quelques composantes applicatives réalisées
Enfin, nous clôturons ce mémoire par une conclusion dans laquelle nous résumons notre
solution et ensuite nous exposons quelques perspectives.
CHAPITRE 1 : ETAT DE L’ART DES SOLUTIONS E-LOCATION
INTRODUCTION
Avec l’avancée des technologies et la concurrence entre les entreprises, des applications sont
développées pour solutionner le problème décrit plus haut. Quelques-unes d’entre elles sont les
plus utilisées dans notre pays. Il s’agit de Kaymu, Lamudi Sénégal, Expat-Dakar. Dans cette

9
partie nous allons d’abord essayer de décrire ces solutions. Ensuite nous identifions les limites
de ces solutions. Nous concluons enfin cette partie par une description de notre solution.
I. DESCRIPTION DE L’EXISTANT
I.1 KAYMU
Kaymu est considéré comme la communauté de shopping en ligne n° 1 au Sénégal [3]. Il Nous
offrons une plateforme de rencontre entre acheteurs et vendeurs mais ne possédant pas de stock
de marchandises. Les fondateurs sont portés par l’idée que l’Internet est en mesure d’effacer
les barrières économiques et de faire progresser les pratiques du commerce tel que nous le
connaissons. Ils ont pour objectif d’inviter le e-commerce dans la vie des africains, de valoriser
l’activité des entrepreneurs locaux en les aidant à développer leurs magasins en ligne, et de
rendre le shopping facile et accessible à tous.
I.2 LAMUDI
Lamudi [4] permet de trouver le logement, le terrain ou le local commercial de ses rêves. Leur
rôle est de vous aider à trouver la résidence idéale et de faire le lien avec l’agent immobilier
mandaté par le propriétaire du bien immobilier.
I.3 EXPAT-DAKAR
Expat-Dakar est un grand espace de vente, d’achat et d’échanges d’objets neufs ou d’occasions
pour particuliers et professionnels [5]. Expat-dakar.com est un lieu dans lequel les utilisateurs
peuvent échanger de l’information. Il ne fournit ni ne vend l’information et les produits ou
services décrits dans les annonces du site. Chaque jour, plusieurs centaines d’annonces sont
publiées sur le site, dans 47 catégories différentes. Celles-ci vont des objets plus courants
(véhicules, vêtements, mobiliers, appareils électroniques...) aux objets de collection (antiquités,
masques, œuvres d’art, tableaux...).
II. LES LIMITES DE L’EXISTANT
Les solutions décrites plus haut sont soit des sites mobiles ou des applications. Par site mobile
on entend un site internet classique mais optimisé pour s’afficher aussi sur votre téléphone. Et
par application, nous retenons que c’est un logiciel entièrement créé pour être visible
uniquement sur un smartphone. Voyons à présent quelques limites des solutions existantes :
II.1 RESPONSIVE WEB DESIGN
Depuis quelques années c’est une tendance que nous constatons: les applications web mobiles
sont de plus en plus prisées aux dépens des applications natives. L’avènement relativement
récent du responsive web design a beaucoup joué, car il permet de transformer l’apparence du
site en fonction des capacités d’affichage du terminal, via les media queries de CSS 3. Cela
signifie que c’est la même application web qui s’affiche que ça soit sur ordinateur ou sur
smartphone. Il n’y a donc pas à redévelopper. Ce pendant au lieu de développer une application
conçue entièrement pour une plateforme spécifique (Android, iPhone, Windows Phone, Klif),
les développeurs ont tendance à faire ce qu’on appelle « adaptation du site original » ceci laisse
des inconvénients à l’utilisation : la plupart du temps, les utilisateurs se trouvent dans
l'obligation de télécharger de manière inutile un code HTML/CSS [10]. De même, les images
sont souvent simplement allongées et non redimensionnées entrainant un impact négatif sur le

10
temps de chargement. D'autre part, le Responsive Design ne permet pas d'ajuster facilement les
titres, descriptions et autres contenus sur les téléphones mobiles. De plus, Il oblige à un
chargement de tous les éléments constituant la page pouvant trahir une performance moindre.
II.2 MENU COMPLEXE
Ces solutions que nous venons de décrire ne sont pas juste des applications ou sites mobiles
pour location de logements mais elles sont des communautés de shopping en ligne qui, de plus,
proposent des offres de logements dans le marché. On peut trouver des produits dans toute sorte
de catégories (beauté, santé, hygiène, mode, accessoires,…). Ainsi plusieurs fonctionnalités
sont offertes à l’utilisateur, avec des options parfois intitules pour ce dernier. De plus le client
aura du mal à faire la recherche et donc n’obtient guère le logement escompté. Ce qu’il lui
fallait c’était quelque chose plus simple à utiliser, très innovante, utile, liée à l’actualité et qui
satisfasse les utilisateurs.
III. NOTRE SOLUTION
Ce que nous proposons c’est quelque chose plus simple à utiliser, une application e-location,
destinée à deux utilisateurs un fournisseur d’offres et un client, qui non seulement offre les
fonctionnalités classiques (recherche de logement (en vente ou en location), contacter un
fournisseur d’offres, proposer des offres) mais de plus qui vous recommande des offres de
locations selon votre position (GPS). Et mieux encore plus léger si on utilise les mobiles et plus
facile de transmettre des données entre différentes plates-formes. La suite vous aidera à mieux
comprendre.
CONCLUSION
Dans cette partie nous avons pu faire une étude sur les solutions qui existent au Sénégal à savoir
leurs statuts et leurs limites. Nous avons ensuite proposé notre solution. Ce qui prépare le terrain
à une capture des futurs besoins qui seront étudiés et modélisés dans le chapitre suivant.
CHAPITRE 2 : CAPTURE DES BESOINS
INTRODUCTION
La capture des besoins consiste à recueillir (on dit aussi capturer) les besoins des utilisateurs
des actuelles ou futur. Pour cela, des modèles, à base de graphiques ou de scénarios, et des
logiciels ont été élaborés. Nous allons maintenant vous présenter les acteurs qui utiliseront
notre application, les fonctionnalités qu’ils pourront entreprendre, et notre système

11
d’information en général. Tout cela, de façon à comprendre clairement comment nous avons
perçu ce projet.
I. LES ACTEURS
Vue la description du projet nous pouvons distinguer trois acteurs externes : un administrateur,
un client et un fournisseur de service.
I.1 L’ADMINISTRATEUR
Ce type d’utilisateur sera mis en place afin de gérer les offres, les inscriptions et les demandes.
Il pourra gérer l’ensemble des comptes fournisseurs, contacter un fournisseur. Il pourra
modifier une offre en la mettant à jour ou en la supprimant.
I.2 LE CLIENT
En effet, l’application e-location est destinée à être accessible pour tout visiteur souhaitant
connaître les biens à louer ou acheter dans une région désirée. e-location est censée faire la
promotion des offres de locations, et inciter l’utilisateur à s’intéresser à un ou plusieurs offres.
Ce même client pourra contacter un fournisseur de services, faire des recherches et même
s’inscrire afin d’avoir accès à des fonctionnalités plus avancées comme la proposition d’une
offre (en vente ou en location).
I.3 LE FOURNISSEUR DE SERVICES
Le fournisseur de service possède les mêmes droits qu’un client. En plus il peut proposer une
offre et même retirer sa proposition.
Le diagramme ci-dessous fait apparaitre les différents acteurs du système et leurs principales
interactions avec celui-ci.
II. LES DIAGRAMMES

12
II.1 DIAGRAMMES DE CONTEXTE
Figure 1: Diagramme de contexte e-location
II.2 DIAGRAMME DE USE CASE
Chaque usage que les acteurs font du système est représenté par un cas d’utilisation. Chaque
cas d’utilisation représente une fonctionnalité qui leur est offerte afin de produire le résultat
attendu.
Ainsi, « le diagramme de cas d’utilisation décrit l’interaction entre le système et l’acteur en
déterminant les besoins de l’utilisateur et tout ce que doit faire le système pour l’acteur ».
Ci-dessous le diagramme de cas d’utilisation général de notre système: l’objectif visé est le suivi
d’un bien (offres de location) de sa proposition à sa validation ou l’annulation.

13
Figure 2: Diagramme de case d’utilisations général
Résumé: Notre application doit permettre :
A. Au client de rechercher ou consulter un bien, de s’inscrire dans le système et même de
contacter un fournisseur.
B. Au Fournisseur de service, de proposer un bien (vente ou location), consulter un bien, de
s’inscrire dans le système et même de contacter un autre fournisseur.
C. A l’administrateur de valider un compte client, de retirer une offre et de contacter un
fournisseur.
CONCLUSION
Ce chapitre nous a permis de faire un découpage fonctionnel de notre futur système par le biais
du diagramme de cas d’utilisation et d’anticiper sur les interfaces qui seront développées
ultérieurement. Dans le chapitre suivant, nous présentons une analyse détaillée pour les cas
d’utilisation de notre système.

14
CHAPITRE 3 : ANALYSES DES BESOINS
INTRODUCTION
Dans ce présent chapitre, nous nous proposons d’analyser les différents cas d’utilisation que
nous venons de repérer à travers l’activité de capture des besoins afin de déterminer les
différentes classes intervenant dans chacun des cas et de repérer le séquencement des flux pour
chaque scénario de réalisation.
I. ANALYSE DU CAS D’UTILISATION « CREER COMPTE»
I.1 DESCRIPTION

15
I.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « CREER COMPTE »
Figure 3: Diagramme de séquence du cas d’utilisation « créer compte »
II. ANALYSE DU CAS D’UTILISATION « CONTACTER FOURNISSEUR»
II.1 DESCRIPTION

16
II.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « CONTACTER UN
FOURNISSEUR D’OFFRES »

17
Figure 4: Diagramme de séquence du cas d’utilisation « contacter un fournisseur »
III. ANALYSE DU CAS D’UTILISATION « RETIRER UNE OFFRE»
III.1 DESCRIPTION

18
III.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « RETIRER UNE
OFFRE »
Figure 5: Diagramme de séquence du cas d’utilisation « retirer une offre »

19
IV. ANALYSE DU CAS D’UTILISATION « PROPOSER UNE OFFRE»
IV.1 DESCRIPTION
IV.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « PROPOSER UNE
OFFRE»
Figure 6: Diagramme de séquence du cas d’utilisation « retirer une offre »

20
CONCLUSION
Comme nous pouvons le constater, l’activité d’analyse a permis de livrer une spécification
complète des besoins issus du diagramme de cas d’utilisation, de les structurer sous une forme
qui facilite la compréhension et qui ébauche vers l’activité de conception. Cette dernière, par
les diagrammes de séquences, va beaucoup être utile dans la partie d’implémentation de notre
application. Ce qui va être le prochain chapitre.

21
CHAPITRE 4 : IMPLEMENTATION
INTRODUCTION
Dans ce chapitre, nous présentons l'architecture sur laquelle nous avons développé notre
application, les différents outils utilisés ainsi que les composantes applicatives réalisées.
I. ENVIRONNEMENT MATERIEL
E-location est une application embarquée qui se connecte à un serveur distant de bases de
données, via internet, afin de récupérer les données. Ce qui nécessite aussi l’intégration d’un
serveur web entre l’application client et le serveur de base de données. D’où l’architecture de
notre application est à 3 niveaux (Architecture 3-tiers), elle est partagée entre :
Le client Android : Conteneur d’application et demandeur de ressources,
Le serveur Web : Vue que les données serons communiquées entre deux environnements
hétérogènes, le rôle principale du serveur web est de gérer la communication entre le client
Android et le serveur de base de données,
Le serveur de base de données fournis les données au serveur web.
II. TECHNOLOGIES
E-location est une application est destinée à deux utilisateurs un fournisseur d’offres et un
client. Donc e-location est une application communicante, l’envoi et la récupération de donné
sont les fonctions indispensables. Comme nous l’avons dit e-location est une application à trois
niveaux qui nécessite chacun des technologies bien particuliers.
II.1 NIVEAU 1 : LE CLIENT ANDROID
Ce niveau est moins complexe que les autres. Pour réaliser notre Android nous avons utilisé les
technologies suivantes :
 ANDROID STUDIO
Android Studio est un nouvel environnement pour développement et programmation
entièrement intégré qui a été récemment lancé par Google pour les systèmes Android. Il a été
conçu pour fournir un environnement de développement et une alternative à Eclipse qui est
l'IDE le plus utilisé.
 ANDROID SDK
Android SDK, c'est le nom de code pour le kit de développement (SDK = Software
Development Kit) de Google pour développer les applications qui tourneront sur le nouveau-
futur OS de la prochaine génération de téléphones mobiles... conçu par Google (et l'Open
Handset Alliance). Le pack proposé inclut l'ensemble des APIs et outils nécessaires pour un
développement complet d'applications. Le kit permet de tester le tout.

22
 ANDROID
Quand on pense à Android, on pense immédiatement à Google, et pourtant il faut savoir que
cette multinationale n'est pas à l'initiative du projet. D'ailleurs, elle n'est même pas la seule à
contribuer à plein temps à son évolution. À l'origine, « Android » était le nom d'une PME
américaine, créée en 2003 puis rachetée par Google en 2005, qui avait la ferme intention de
s'introduire sur le marché des produits mobiles. La gageure, derrière Android, était de
développer un système d'exploitation mobile plus intelligent, qui ne se contenterait pas
uniquement de permettre d’envoyer des SMS et transmettre des appels, mais qui devait
permettre à l'utilisateur d'interagir avec son environnement (notamment avec son emplacement
géographique). C'est pourquoi, contrairement à une croyance populaire, il n'est pas possible de
dire qu'Android est une réponse de Google à l'iPhone d'Apple, puisque l'existence de ce dernier
n'a été révélée que deux années plus tard.
C'est en 2007 que la situation prit une autre tournure. À cette époque, chaque constructeur
équipait son téléphone d'un système d'exploitation propriétaire. Chaque téléphone avait ainsi
un système plus ou moins différent. Ce système entravait la possibilité de développer facilement
des applications qui s'adapteraient à tous les téléphones, puisque la base était complètement
différente. Un développeur était plutôt spécialisé dans un système particulier et il devait se
contenter de langages de bas niveaux comme le C ou le C++. De plus, les constructeurs faisaient
en sorte de livrer des bibliothèques de développement très réduites de manière à dissimuler
leurs secrets de fabrication. En janvier 2007, Apple dévoilait l'iPhone, un téléphone tout
simplement révolutionnaire pour l'époque. L'annonce est un désastre pour les autres
constructeurs, qui doivent s'aligner sur cette nouvelle concurrence. Le problème étant que pour
atteindre le niveau d'iOS (iPhone OS), il aurait fallu des années de recherche et développement
à chaque constructeur...
C'est pourquoi est créée en novembre de l'année 2007 l'Open Handset Alliance (OHA), et qui
comptait à sa création 35 entreprises évoluant dans l'univers du mobile, dont Google. Cette
alliance a pour but de développer un système open source (c'est-à-dire dont les sources sont
disponibles librement sur internet) pour l'exploitation sur mobile et ainsi concurrencer les
systèmes propriétaires, par exemple Windows Mobile et iOS. Cette alliance a pour logiciel
vedette Android, mais il ne s'agit pas de sa seule activité. L'OHA compte à l'heure actuelle 80
membres.
II.2 NIVEAU 2 : LE SERVEUR WEB
1. POINT SUR LES SERVICES WEB
La méthode la plus répandue de se connecter à une base de données MySQL à distance à partir
d'un appareil Android, est de mettre une sorte de service dans le milieu. MySQL est
habituellement utilisé avec PHP, donc la façon la plus simple et le plus évident d'écrire des
scripts PHP pour gérer la base de données et exécuter ces scripts en utilisant le protocole HTTP
du système Android. Mais cela suppose que notre application est destinée seulement à un client
spécifique. Pourquoi cette limite ? Pourquoi pas un client IOS ou encore un client web ?
Les services Web sont devenus, depuis quelque temps, la norme de facto pour intégrer des
applications internes ou offrir une interface externe aux clients. Un service web est un élément
de logique applicative informatique distribué permettant l’échange de données entre
applications et systèmes hétérogènes. C’est un objet avec un langage, c’est une classe avec des

23
méthodes qui peuvent être appelés à distance. Il est plus facile de transmettre des données entre
différentes plates-formes en utilisant ce moyen; plus facile de composer le message, plus facile
à déboguer, plus facile à comprendre. Alors un client développé avec n’importe quel langage
peut faire des appels aux méthodes du service web via des requêtes SOAP, REST, ou bien
même XML-RPC. Ainsi nous pouvons intégrer des parties du système écrites en Java, .NET,
PHP, ANDROID, IOS, etc. en utilisant un protocole bien connu et des messages textes
(généralement en XML).
Dès lors plusieurs technologies sont à notre disposition, il nous faut donc faire un tri. Nous
mettons d’un côté SOAP et XML-RPC qui permettent de transporter l’information XML à
travers d’une encapsulation XML. D’un autre côté, plaçons REST qui est plus une philosophie
du web et qui, pour résumer, propose de faire beaucoup plus simple que les services
traditionnels.
POURQUOI CHOISIR SOAP
En effet SOAP présente beaucoup d’avantages :
-Simple et extensible ;
-Adaptable à différents protocoles de transport ;
-Basé sur XML, il est indépendant des plates-formes cliente et serveur ;
Mais si on ne s’en tient qu’à cette liste, SOAP est fortement concurrencé par les autres formes
de services plus souples comme REST ou tout simplement par tous les mécanismes
requête/réponse sur http.
En ajoutant le point noir de SOAP, à savoir qu’il s’agit d’un protocole très verbeux et parfois
assez gourmand en ressources, beaucoup le déconseillent sur une plate-forme telle qu’Android,
qui proposera un environnement contraint sur des appareils mobiles. Enfin, même si sortis de
la boite Android ils ne proposent pas de fonctionnalités pour manipuler SOAP.
POURQUOI CHOISIR REST ?
REST est léger et simple : les messages sont courts, faciles à décoder par le navigateur et par le
serveur d’application.
REST est auto-descriptif : vous pouvez naviguer à travers ses ressources comme vous le feriez
avec une page Web. Il y a une URL intuitive unique pour chaque ressource. On peut facilement
en déduire la structure des ressources sans avoir besoin de beaucoup de documentation.
REST est « stateless » (il n’est pas adapté aux transactions longues et complexes) : il est parfait
pour les opérations simples (créer, lire, mettre à jour, effacer).
REST peut être géré en cache (antémémoire) : les ressources simples, identifiables sont aussi
faciles à mettre en cache qu’un article sur un site Internet. L’adaptation aux variations de charge
et la performance que cela apporte ne doivent pas être négligées.
REST n’est pas limité à XML: beaucoup d’implémentations utilisent JSON, un format encore
plus léger, moins verbeux.

24
2. BACKEND AVEC GOOGLE APP ENGINE( GAE)
PRESENTATION
App Engine est une plateforme PaaS, qui permet de créer des applications Web à l'aide des
technologies Java, Python ou encore JavaScript et de les exécuter sur l'architecture évolutive
de Google.
App Engine permet de développer en toute simplicité des applications qui s'exécutent de
manière fiable, même lorsqu'elles sont surchargées et doivent faire face à des volumes de
données importants. App Engine comprend les fonctionnalités suivantes :
 diffusion Web dynamique, avec prise en charge intégrale des technologies Web
courantes ;
 stockage permanent avec requêtes, tri et transactions ;
 équilibrage des charges et évolutivité automatique ;
 API qui permet d'authentifier les utilisateurs et d'envoyer des e-mails via Google
Accounts ;
 un environnement de développement local complet qui simule Google App Engine sur
votre ordinateur ;
 des files d'attente de tâches qui permettent d'effectuer du travail en dehors du champ
d'une requête Web ;
 des tâches planifiées qui déclenchent les événements aux moments spécifiés ou à
intervalles réguliers.
App Engine dispose d'un ensemble riche de services pour faciliter le développement
d'applications qui seront hébergées dans le Cloud de Google. Pour notre travail, nous allons
utiliser l'environnement d'exécution Java (JRE), la base de données (Datastore), et les outils
Google Cloud EndPoints.
L’ENVIRONNEMENT D’EXECUTION JAVA
L'environnement d'exécution Java d'App Engine fournit une machine virtuelle qui supporte
Java 8 et permet l'exécution des applications dans un environnement Cloud sécurisé (sandbox).
Le Runtine Java de la plateforme offre également une interface Servlet Java et la prise en charge
de l’interface standard avec le magasin de données et les services évolutifs App Engine tels que
JDO (Java Data Objects), JPA (Java Persistence API), JavaMail et JCache. La prise en charge
des normes facilite le développement des applications et permet de porter celles-ci vers et
depuis votre propre environnement de servlets.
LA BASE DE DONNEES (DATASTORE)
App Engine fournit un service performant de stockage distribué de données qui comprend un
moteur de recherche et la gestion des transactions. En même temps que les serveurs Web
distribués augmentent avec votre trafic, la base de données grossit avec vos données.
Le Datastore App Engine n'est pas comme une base de données relationnelle traditionnelle. Les
objets de données ou « entités » ont des propriétés. Les recherches peuvent retourner des entités
selon un filtre donné et les trier selon les propriétés de leurs valeurs.

25
Les entités Datastore n'ont pas de schéma. La structure de données des entités est fournie et
mise en place par le code de l'application. Les interfaces JDO/JPA incluent les dispositifs pour
mettre en place la structure à l'intérieur de l'application. L'application peut aussi accéder au
Datastore directement pour mettre en place une structure répondant plus précisément aux
besoins du développeur.
Le Datastore implémente les transactions à travers son réseau distribué en utilisant des
« groupes d'entités ». Une transaction manipule des entités à l'intérieur d'un simple groupe. Les
entités du même groupe sont enregistrées ensemble par souci d'efficacité d'exécution des
transactions.
GOOGLE CLOUD ENDPOINTS
Pour faciliter le développement d'applications mobiles utilisant App Egine, Google a développé
un ensemble d'API connu sous le nom de « Cloud Endpoints ».
Cloud Endpoints permet de définir la logique métier sur App Engine et d'y accéder via des API
RESTful ou RPC (Remote Procedure Call) sur de multiples plateformes, y compris Android,
iOS et sur le Web (JavaScript). Cloud Endpoints est construit en utilisant l'infrastructure de
Google API, ce qui facilite l'interopérabilité avec des services Google.
Cloud Endpoints a été construit pour simplifier la tâche aux développeurs [8], en permettant un
développement flexible et agile. Il permet de :
 libérer le développeur des travaux complexes de rédaction et de maintenance de code
pour les interactions et les protocoles client-serveur ;
 générer du code optimisé pour les opérations CRUD ;
 faciliter la création des API personnalisées (REST ou RPC).
Figure 7: Un seul backend Endpoints avec plusieurs clients (Android, IOS, Firefox)
Cloud EndPoints est un outil qui offre souplesse et simplicité au développeur qui souhaite créer
une application sur App Engine, dont les fonctionnalités seront exploitées par divers clients,
quelle que soit leur plateforme exécution.

26
DESCRIPTION ET ARCHITECTURE DE LA SOLUTION A DEVELOPPER
La solution que nous allons mettre sur pied sera constituée de deux applications. Une
application App Engine qui fera office de Backend et une application Android qui sera le client
(frontend). Les données seront stockées sur le Datastore d'App Engine. Le diagramme de
composants ci-dessous permet d'avoir une idée plus précise sur les composants de notre solution
et son architecture physique et statistique.
Figure 8: Architecture de la solution à développer
LA SOLUTION A DEVELOPPER
Deux étapes pour obtenir le résultat escompté :
 la création du serveur et sa mise en place

27
 la création de l'application Android pour le côté client et des Web services côté
serveur à l'aide de Restlet.
3. LA CREATION DU SERVEUR ET SA MISE EN PLACE : COTE SERVEUR
Tout d'abord nous allons créer notre serveur App Engine. Nous nous occuperons ensuite de
l'application web que nous déploierons sur le serveur App Engine. Enfin, nous mettrons en
place les Webservices Restlet.
CREER LE SERVEUR APP ENGINE
Pour créer le serveur App Engine, il suffit de vous connecter
sur https://appengine.google.com/ à l'aide de votre compte Google et suivre les options.
Vous disposez de 10 applications gratuites.
CREER L’APPLICATION ET LES WEB SERVICES
On crée l’application sous Android studio en créant un nouveau projet. Ensuite il nous faut
ajouter un nouveau module (Google Cloud Module) dans l’application.
Android Studio nous donne une intégration directe avec App Engine. Grâce à Android Studio,
nous pouvons générer automatiquement les bibliothèques Cloud Endpoints client nécessaires
pour accéder au backend ainsi que des classes pour notre serveur. Il faut alors commencer à
définir nos nouvelles classes. Et pour chaque classe d'entité, vous devez générer une classe de
Cloud Endpoints pour donner à notre client l'accès aux données de l'application backend.

28
Dès que le module backend est ajouté à notre projet et à synchroniser Gradle finitions, une
nouvelle configuration d'exécution avec le nom du module de votre backend doit être créé:
Pour nous assurer que notre backend démarré avec succès, accédons à http: // localhost: 8080.
Si tout va bien, nous devrions voir la page suivante:

29
Il reste à connecter notre application Android client avec le backend. Il vous suffit de faire une
requête HTTP. L'extrait de code suivant illustre comment créer un AsyncTask qui rend la
requête HTTP pour le backend et imprime le résultat chaîne entrant vers un toast dans un
contexte donné:
class ServletPostAsyncTask extends AsyncTask<Pair<Context, String>, Void,
String> {
private Context context;
@Override
protected String doInBackground(Pair<Context, String>... params) {
context = params[0].first;
String name = params[0].second;
HttpClient httpClient = new DefaultHttpClient();
HttpPost httpPost = new HttpPost("http://10.0.2.2:8080/hello"); // 10.0.2.2
//l’adresse ip de l’emulateur Android
try {
// Add name data to request
List<NameValuePair> nameValuePairs = new
ArrayList<NameValuePair>(1);
nameValuePairs.add(new BasicNameValuePair("name", name));
httpPost.setEntity(new UrlEncodedFormEntity(nameValuePairs));

30
Enfin, nous avons besoin d'invoquer cette AsyncTask d'un de nos activités Android. Par
exemple, pour exécuter de la classe MainActivity, ajoutons le code suivant à la méthode
LES DIFFERENTES COUCHES DE L’APPLICATION
L'application Android sera constituée des couches suivantes :
 la couche présentation (IHM - Interface Homme Machine) : elle correspond à la
partie visible de l'application. La couche présentation relaie les requêtes de l'utilisateur
à destination de la couche métier, et en retour lui présente les informations renvoyées
par les traitements de cette couche ;
 la couche métier (BLL - Business Logic Layer) : la couche métier sera utilisée pour
développer toute la logique métier de l'application Android. Elle est intercalée entre
l'IHM et la bibliothèque App Engine Client Lib, et permettra d'effectuer toutes les
manipulations de données nécessaires en fonction des requêtes effectuées par les
utilisateurs au travers de la couche présentation ;
 App Engine Backend Client Lib : cette couche fournit un accès simplifié à
l'application serveur hébergée sur App Engine via Google Cloud Endpoints ;
 le modèle objets : le modèle ici représente les ressources qui seront manipulées par
notre application et notre API.
// Execute HTTP Post Request
HttpResponse response = httpClient.execute(httpPost);
if (response.getStatusLine().getStatusCode() == 200) {
return EntityUtils.toString(response.getEntity());
}
return "Error: " + response.getStatusLine().getStatusCode() + " " +
response.getStatusLine().getReasonPhrase();
} catch (ClientProtocolException e) {
return e.getMessage();
} catch (IOException e) {
return e.getMessage();
}
}
@Override
protected void onPostExecute(String result) {
Toast.makeText(context, result, Toast.LENGTH_LONG).show();
}
}
MainActivity.onCreate=new ServletPostAsyncTask().execute(new Pair<Context, String>(this,
"elocation"));

31
Figure 9: Model en couches de l'application à développer
L’ARCHITECTURE EN COUCHES DE L’APPLICATION APP ENGINE
Les différentes couches que nous allons utiliser pour cette application sont les suivantes :
 les classes Endpoints : les classes Endpoints représentent en quelque sorte la couche
d'accès aux données. Les méthodes que chaque classe Endpoint possède permettent
d'insérer, mettre à jour et supprimer les objets dans le Datastore ;
 le modèle objets : le modèle ici représente les ressources qui seront manipulées par les
classes Endpoint
Figure 10: L'architecture de l'application App Engine (le backend)

32
II.3 NIVEAU 3: LE SERVEUR DE BASE DE DONNEES
II.3.1 DESCRIPTION
Nous avons l'habitude de stocker deux types de fichiers :
 Stocker des informations : on a très régulièrement besoin d'enregistrer des
informations. Ça peut être le nom d'un nouveau membre, un message qu'il laisse, une
commande qu'il effectue sur l’application...
 Stocker des fichiers : on a parfois besoin de stocker de nouveaux fichiers, que ce soient
des images, des .zip, etc. Ces fichiers sont le plus souvent uploadés par les utilisateurs
du site web.
Pour répondre à ces besoins, Google App Engine fournit différents services :
 Pour le stockage d'informations, on a en général besoin d'une base de données. C'est
en effet le moyen le plus sûr et le plus structuré pour "ranger" les informations. Google
App Engine propose 2 types de bases de données :
o Une base de données relationnelle SQL : c'est le service Google Cloud SQL. Il
s'agit en fait d'une base de données MySQL gérée en Cloud.
o Une base de données non relationnelle NoSQL : c'est le service Datastore. Il est
basé sur Big Table, le système de stockage créé par Google pour ses propres
services pour des besoins de performance (qui a d'ailleurs lui-même inspiré en
bonne partie le mouvement NoSQL).
Figure 11: LE SERVEUR DE BASE DE DONNEES: les possibilités offertes par GAE
Si on adapte une application qui existe déjà et dans laquelle on a utilisé une base de données
relationnelle comme MySQL, il est inutile de tout changer. Il faut utiliser la base de données
relationnelle Google Cloud SQL.

33
Si on est curieux de découvrir une nouvelle façon de stocker les données, qu’on a toujours
entendu parler de NoSQL mais qu’on n’a jamais eu l'occasion de s’y mettre, essayez-vous
au Datastore.
Voici un petit tableau comparatif SQL vs NoSQL :
Fonctionnalité
SQL
(ex : MySQL)
NoSQL
(ex : Datastore)
Avantage
Scalabilité
multi-serveurs
Limité à un serveur
principal pour les écritures.
Pour avoir plus de
puissance en écriture il faut
un plus gros serveur.
Multi-serveurs par défaut,
pas de limitations. La
charge est aisément
répartie sur plusieurs
serveurs.
NoSQL
Structuration
des données
Les données sont toujours
très structurées dans des
tables. Pratique quand on a
besoin d'une structure
précise.
Adapté pour les données en
structure arborescente (ex :
XML, JSON...) dont la
forme peut varier.
Dépend
des
besoins
Puissance du
langage SQL
Permet d'effectuer des
requêtes complexes et
précises (parfois assez
lentes).
Permet d'effectuer
seulement des requêtes
simples, mais rapides.
SQL
Schéma des
données
Le schéma est contraignant
: vous devez absolument
faire "rentrer" les données
dans les cases prévues.
Avantage : tout est toujours
proprement rangé.
Le schéma n'est pas
contraignant : vous pouvez
faire ce que vous voulez,
stocker comme vous le
voulez. Défaut : il faut
vérifier manuellement si
tout est bien rangé.
Dépend
des
besoins
Transactions Les transactions sont
strictes : les données sont
immédiatement
enregistrées et à jour.
Les transactions sont
possibles mais cela
demande plus de travail.
Les données peuvent être
enregistrées avec un léger
retard.
SQL
Figure 12: Tableau comparatif SQL vs NoSQL

34
II.3.1 LE DATASTORE: NOTRE SERVEUR DE BASE DE DONNEES NOSQL
A. DESCRIPTION
Le Datastore est la voie royale pour stocker des données sur Google App Engine [1]. C'est
clairement l'outil que Google nous conseille d'utiliser. Vous pouvez vous en servir gratuitement
(jusqu'à une certaine limite de trafic) et on ne vous en dit que du bien : il serait rapide, capable
de gérer de fortes charges, réparti sur de multiples Datacenter... On dit même qu'il serait basé
sur Big Table, la technologie qu'utilise Google pour stocker toutes ses données, notamment les
résultats d'indexation des milliards de pages web par le Google Bot. Le Datastore fonctionne
en mode High Replication Datastore (HRD). Ce système est très résilient aux erreurs : il fait en
sorte que vos données soient copiées sur de multiples Datacenter ! L'objectif est que votre
application puisse continuer à fonctionner même en cas d'évènement catastrophique.
Si le Datastore est alléchant, il est néanmoins très différent d'une base de données SQL comme
MySQL... Pour vous et moi qui sommes habitués aux bases SQL, c'est un changement très
important : le Datastore est ce qu'on appelle une base de données NoSQL.
En fait beaucoup de gens croient que "NoSQL" est une opposition au SQL, alors que c'est en
fait l'acronyme de "Not Only SQL" (pas seulement du SQL). On y reprend des principes de
SQL mais pas tous. L'objectif est de se débarrasser de tout ce qui empêche habituellement les
sites basés sur SQL de croître avec un fort trafic.
B. LE DATASTORE N’EST PAS UNE BASE DE DONNEES RELATIONNELLE
Le Datastore est à plusieurs égards beaucoup plus basiques et bas niveau qu'une base de données
classique. Il n'utilise pas de tables. Il n'y a pas de schéma SQL : on dit que le Datastore est
schemaless (sans schéma). Il faut l’imaginez comme un espace géant prêt à accepter des
données, n'importe quelles données. On lui envoie du contenu et il nous le stocke. Quand nous
en avons à nouveau besoin, il nous suffit de le lui demander.
C. FONCTIONNEMENT
Le Datastore peut être utilisé de façon massive, avec beaucoup de données et de requêtes
simultanées. Pourtant, à son plus bas niveau, il fonctionne de façon très simple : il accepte des
clés et des valeurs. Exactement comme une HashMap [8].
A son niveau le plus basique, le Datastore ressemble donc à ça :
Clé : valeur
Ex : pseudo Ex : Aly

35
Le Datastore stocke des paires clé-valeur et est capable d’en stocker beaucoup, beaucoup,
beaucoup de paires clé-valeur :
Si on en tien juste là vous pouvez penser que ce n'est pas structuré ! Ca fait juste un grand bazar
! On ne va quand même pas mélanger des noms de membres, des messages, des
commandes...En fait, le Datastore est un peu plus malin que ça. Il vous permet de regrouper les
données dans des entités.
 Les entités organisent (un peu) les données.
Le Datastore a un concept d'entités. C'est ce qui nous aide à structurer les informations. Les
entités sont des regroupements d'une ou plusieurs paires clé-valeur. Elles ressemblent à ceci :
Le Datastore est aussi capable d'associer les entités entre elles. Une entité peut avoir une entité
parente, qui peut elle-même avoir une entité parente, etc.
On peut aussi stocker des entités sans parent.

36
 Les entités comme des objets:
Un élément m'a aidé à bien comprendre le Datastore. Je me suis mis à imaginer que les
entités sont comme des objets en Java. Un objet possède plusieurs attributs : ce sont les
paires clé-valeur. La clé correspond au nom de l'attribut, et la valeur... à sa valeur.
Pour prendre un exemple, imaginons un Fournisseur d'offres. Il possède des attributs : un
nom, un numéro de téléphone,…Il possède aussi une offre de location qui a ses propres
caractéristiques (id_location, adresse,…) Les entités dans le Datastore pourraient être
représentées comme ceci :

37
Fournisseur
Location
 Comment identifier une entité :
Les entités sont des groupes de données qui vivent dans l'espace intersidéral du Datastore. Il
peut y en avoir une très grande quantité. Parfois, certaines entités sont reliées entre elles : elles
ont une relation de parenté. Les données (paires clé-valeur) au sein des entités sont appelées des
propriétés. Celles-ci stockent obligatoirement des données basiques, comme du texte ou des nombres.
La doc de Google nous donne tous les types autorisés [11]. Vu qu'il y en a des milliers, des millions
voire même des milliards qui vivent au sein du Datastore, il va falloir leur donner un nom unique pour
les repérer ! Une fois qu'on aura l'entité, on saura alors facilement lire et modifier toutes ses
propriétés.
Pour identifier une entité, Google utilise la combinaison de 3 informations :
 Un type (kind) : c'est le type de données de votre entité. Par exemple, on peut dire que
le type de données de mon fournisseur d’offre est... "Fournisseur". C'est ma classe
"Fournisseur".
 Un identifiant (identifier) : il peut s'agir soit d'une chaîne de caractères soit d'un nombre.
Vous pouvez le définir vous-mêmes ou bien laisser Google générer un nombre pour
vous.
 Un parent (ancestor path) : si l'entité possède un parent, celui-ci aidera à identifier
l'entité de façon unique. Si l'entité ne possède pas de parent, on dit que c'est une entité
racine (root). Dans ce cas l'ancestor path vaut null.
En résumé :
Nom : Aly
Téléphone : 77 123 45 67
Id_location : 0078
Adresse : Saint Louis

38
Ex : Fournisseur Ex : Aly Ex : null (pas de parents)
Si on le rapportait à notre exemple précédent avec des fournisseurs et des offres, ça donnerait
quelque chose de ce genre :
Fournisseur : aly : null
Location : id_location :(Fournisseur :aly)
 Les opérations:
Maintenant que nous savons comment le Datastore de Google stocke les entités, il ne nous
reste plus qu'une chose à voir avant de commencer à coder : quelles actions peut-on faire sur
une telle base ?
Il y a 4 opérations de base disponibles dans une base de données NoSQL comme le
Datastore [9]
 get() : récupère une entité en fonction de son identifiant
 put() : écrit une entité (ou en écrase une)
 delete() : supprime une entité via son identifiant
 query() : retrouve des entités en fonction de certains critères de recherche
Nom : Aly
Téléphone : 77 123 45 67
Id_location : 0078
Adresse : Saint Louis

39
Avant toute chose, vous devez importer les APIs du Datastore dans votre application :
import com.google.appengine.api.datastore.*;
Ensuite, vous devez récupérer un objet représentant le service du Datastore. On fait appel à une
factory qui nous renvoie l'objet dont nous allons avoir besoin. Cela se fait en une ligne :
DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();
Arrivé juste ici alors nous somme prêt à utiliser Datastore. Passons maintenant à la création
d’une entité.
Pour créer une entité trois opérations sont nécessaires :
1. Créez l'objet représentant l'entité, de type Entity
2. Assignez-lui une ou plusieurs propriétés (ce sont les paires clé-valeur)
3. Demandez l'écriture de l'entité au Datastore avec la méthode put()
Essayons de recréer l'entité Fournisseur que j'avais inventée pour vous expliquer le
fonctionnement du Datastore :
D. MANIPULER LES DATASTORE AVEC OBJECTIFY
On vient de le voir : le Datastore est un système puissant mais son API bas niveau est assez
délicate à utiliser, notamment son système de requêtes. De l'avis de plusieurs développeurs (y
compris des gens de chez Google !), il est recommandé d'utiliser la bibliothèque Objectify pour
travailler avec le Datastore aujourd'hui.
Contrairement au Datastore lui-même, la lib Objectify n'est pas maintenue par Google lui-même
mais par un développeur externe. Objectify est particulièrement suivi et maintenu, c'est donc
un excellent choix pour développer avec le Datastore. Objectify se veut être une API "ni trop
bas niveau, ni trop haut niveau". Elle (heureusement) plus haut niveau que l'API de base que
nous venons de découvrir, mais elle ne nous empêche pas d'effectuer des actions basiques si
nécessaire. Objectify est un peu comme un ORM pour le Datastore : son rôle est de persister
(stocker) vos objets dans le Datastore.
// Crée l'entité de type (kind) "Fournisseur"
Entity fournisseur = new Entity("Fournisseur");
// Assigne des propriétés à l'entité
fournisseur.setProperty("nom", "Aly");
fournisseur.setProperty("telephone", "777777777" );
// Enregistre l'entité dans le Datastore
datastore.put(fournisseur);

40
Figure 13: Fonctionnement du Datastore avec Objectify
Objectify s'occupe de la création d'entités et de clés et de la relation entre ces éléments. Mieux:
il utilise automatiquement le service Memcache de Google qui permet de mettre en cache des
données pour aller encore plus vite et vous éviter d'appeler systématiquement le Datastore.
Objectify est suffisamment simple à comprendre et pourtant très puissant. La plupart des vraies
applications sur App Engine l'utilisent aujourd'hui. Objectify est une bibliothèque créée par un
développeur tiers. Elle n'est pas installée automatiquement avec le plugin App Engine pour Eclipse.
Heureusement, son installation et sa configuration sont simples. Le projet Objectify est hébergé sur
Google Code à l'adresse suivante : https://github.com/objectify/objectify.
i. CREER DES OBJETS PERSISTANTS
Comme l'API bas niveau du Datastore, Objectify nous permet d'effectuer des opérations
basiques sur les entités via leurs clés :
 Ecrire une entité
 Récupérer une entité grâce à sa clé
 Supprimer une entité grâce à sa clé
Nous nous intéressons ici à ces opérations simples. Nous verrons juste après comment effectuer des
requêtes, ce qui est un poil plus complexe mais quand même bien plus lisible que l'API bas niveau.
Pour travailler avec Objectify, on doit d'abord récupérer son instance. Cela se fait comme ceci:
ObjectifyService.ofy()
Le principe d'Objectify est que vous pouvez enchaîner plusieurs appels sur cette instance. Par
exemple, pour charger un objet en fonction de sa clé on ferait :
Objet monObjet = ObjectifyService.ofy().load().key(cle).now();
Comme vous allez devoir écrire ObjectifyService.ofy() de nombreuses fois, il est
recommandé d'effectuer une définition statique au début du fichier :
import static com.googlecode.objectify.ObjectifyService.ofy;
Vous pouvez alors écrire simplement ofy() au lieu de ObjectifyService.ofy():
Objet monObjet = ofy().load().key(cle).now();

41
- ECRIRE UNE ENTITE
Objectify travaille sur des objets. La première chose à faire est donc, dans votre servlet, de créer
des objets comme vous avez l'habitude de le faire en Java :
Fournisseur f = new Fournisseur ("aly", ("77 777 77 77");
Notre Personnage p peut ensuite être persisté dans le Datastore avec cette simple commande :
ofy().save().entity(f); // Asynchrone (pas enregistré immédiatement)
Par défaut, les sauvegardes sont asynchrones. Cela signifie que le Datastore rend la main à votre
programme avant d'avoir enregistré les données. C'est la méthode la plus rapide mais, si vous
avez besoin des données que vous venez d'enregistrer immédiatement après, vous voudrez peut-
être forcer l'enregistrement de façon synchrone comme c'est le cas en SQL. Pour ça, rajoutez
juste un appel à now () à la chaîne :
ofy().save().entity(f).now(); // Synchrone (enregistré immédiatement)
- RECUPERER UNE ENTITE
Pour récupérer une entité, vous devez connaître sa clé. Je vous rappelle qu'une clé est
simplement un identifiant constitué du type + de l'ID + du parent.
- LES CLES
Le Datastore nous fournissait déjà la classe Key qui représente une clé. Cette classe s'utilise
comme ceci pour rappel :
Key clePersonnage = KeyFactory.createKey("Fournisseur", "aly"); // API bas niveau
Mais Objectify fournit une légère variante : la classe Key<?> (qui indique en plus le type d'objet
stocké). On peut l'utiliser comme ceci :
Key<Fournisseur> cleFournisseur = Key.create(Fournisseur.class, "aly");
Les deux types de clés sont utilisables dans Objectify. A noter qu'il existe aussi le type Ref<?>
qui fonctionne comme Key<?> mais qui permet de manipuler les sous-objets plus facilement.
ii. CHARGER L'INSTANCE OBJECTIFY
- CHARGER UN OBJET GRACE A SA CLE

42
Pour charger un objet, on crée d'abord sa clé (soit avec la classe Key bas niveau du Datastore,
soit avec la classe Key<?> d'Objectify) puis on demande son chargement :
Key<Personnage> cleFournissseur = Key.create(Fournisseur.class, "aly");
Fournisseur r = ofy().load().key(cleFournisseur).now();
Plus fort que le Roquefort, Objectify nous permet aussi de charger un objet sans passer par
l'étape préalable de création d'une clé :
Fournisseur r = ofy().load().type(Fournisseur.class).id("aly").now();
Il s'agit juste d'une syntaxe plus pratique créée par Objectify. Elle a le même effet que si vous
étiez passés par la création d'une clé.
Si on veut récupérer une entité qui a un parent, il faudra ajouter un appel à parent() dans la
chaîne comme ceci :
Location a =
ofy().load().type(Location.class).parent(fournisseur).id("maison").now();
- SUPPRIMER UNE ENTITE
En tant que roi du Datastore, vous avez droit de vie et de mort sur vos entités. Il n'y a rien de
plus simple : indiquez en paramètre l'objet que vous voulez supprimer du Datastore.
ofy().delete().entity(objetASupprimer).now();
Si vous voulez varier les plaisirs, vous pouvez aussi supprimer l'entité via sa clé :
ofy().delete().key(cleObjetASupprimer).now();
Ou utiliser la syntaxe offerte par Objectify qui vous évite d'avoir à créer une clé :
ofy().delete().type(Fournissuer.class).id("aly").now();
iii. LES REQUETES
Exécuter des requêtes avec Objectify est beaucoup plus pratique que l'API bas niveau du
Datastore. En fait, la syntaxe de base est la même que le chargement via une clé. Il vous suffit
de rajouter des filtres via filter() et d'indiquer que vous voulez qu'on vous retourne une liste
avec list():
Retourne tous les fournisseurs dont le nom est aly
List<Fourniseur> fournisseur = ofy().load().type(Fournisseur.class).filter("
nom","aly").list();
On peut aussi rechercher parmi les ancêtres via leur clé avec la même méthode :

43
List<Arme> armes =
ofy().load().type(Location.class).ancestor(KeyFactory.createKey(
"Fournisseur.class", "aly")).list();
Il faut noter que Vous ne pouvez effectuer des requêtes que sur des propriétés indexées par le
Datastore. Par défaut Objectify n'indexe pas les attributs des classes, sauf si vous utilisez
l'annotation @Index. Vérifiez donc que vous avez correctement défini vos index avant
d'effectuer des requêtes !
E. MISE EN CACHE AVEC MEMCACHE
App Engine offre un service de Memcache. Pour ceux qui ne connaissent pas Memcache, il
s'agit d'un logiciel qui tourne uniquement en mémoire vive (RAM) sur des serveurs et qui stocke
des paires clé-valeur. Memcache se révèle en fait un excellent complément au Datastore.
Puisqu'il ne nécessite pas d'accéder à des disques, il est beaucoup plus performant que le
Datastore (en gros, une requête Memcache va 10 fois plus vite qu'une requête dans le
Datastore). On serait tenté de tout mettre dans Memcache mais il ne faut pas oublier que les
données peuvent vraiment être perdues à tout moment : si le serveur redémarre tout est perdu
et s'il n'y a plus de place en mémoire Memcache supprime arbitrairement de vieilles données
en cache.
Il faut savoir que le service Memcache chez Google est gratuit. Google veut nous encourager
à utiliser intensivement Memcache pour alléger la charge des serveurs du Datastore. Nous
n'allons donc pas nous en priver.
En pratique, l'utilisation combinée de Memcache et du Datastore se fait comme ceci :
1. On s'apprête à faire une requête dans le Datastore pour récupérer des données
2. On demande d'abord à Memcache s'il possède déjà ces données
3. Si Memcache les possède, on aura récupéré les données 10x plus rapidement et sans
passer par le Datastore
4. Si Memcache ne les possède pas, on fait une requête classique au Datastore et on stocke
le résultat dans Memcache pour que la prochaine requête aille plus vite.

44
Figure 14: Exécution d'une requête dans le Datastore
F. LES TRANSACTIONS
Les transactions sont indispensables dans un grand nombre d'applications. Elles vous
permettent d'exécuter plusieurs requêtes d'affilée et de vous assurer qu'elles ont bien fonctionné
avant de réellement enregistrer les données.
Objectify fournit un système très pratique pour effectuer des transactions. On pourrait aussi le
faire avec l'API bas niveau.
Il y a 2 cas :
 Soit votre transaction doit retourner des données (sous forme d'un objet)
 Soit votre transaction ne doit pas retourner de données
Si la transaction ne doit pas retourner de données, voici comment on l'écrirait avec Objectify :
import com.googlecode.objectify.VoidWork;
ofy().transact(new VoidWork() {
public void vrun() { // Tout ce qui est exécuté dans cette méthode appartient à la
même transaction

45
Objet objet = ofy().load().key(cle).now();
/* Modification de l'objet... */
ofy().save().entity(objet);
}
}
Si la transaction doit retourner de données, voici comment on l'écrirait avec Objectify
import com.googlecode.objectify.Work;
Objet monObjet = ofy().transact(new Work<Objet>() {
public Objet run() {
Objet objet = ofy().load().key(cle).now();
/* Modification de l'objet... */
ofy().save().entity(objet);
return objet;
}
});
III. CONCEPTION DE L’APPLICATION
La création de notre application se fera selon les étapes suivantes :
 création de l'application Android ;
 génération du Backend App Engine ;
 création des classes Entity ;
 création des classes Endpoints ;
 génération de l'API Client ;
 création des méthodes d'accès sous Android ;
 test ;
 déploiement.
On crée l’application avec Android Studio. Ensuite il nous faut ajouter un nouveau module
(Google Cloud Module) dans l’application afin de créer notre backend. Le backend créé il nous
faut passer à la création des classes Entity qui vont être le model de l’application. Les classes
Entity créées, il faut maintenant générer les classes Cloud Endpoints pour chaque classe d'entité
et bien sûr des modifications seront faites sur les classes Endpoints. Il ne reste plus qu’à générer
l’API client et créer des méthodes d’accès sous Android afin de pouvoir tester l’application et
passer au déploiement.
IV. QUELQUES COMPOSANTES APPLICATIVES REALISEES
Pour plus simplicité dans l’utilisation de l’application E-location, l’interface de l’application
doit présenter 2 onglets : un onglet pour la liste de toutes les offres disponibles et l’onglet pour
les recommandations. De plus on a un bouton de recherche et un bouton pour ajouter une
nouvelle offre. En haut de l’application on a une barre de titre affichant le nom de l’application
et un bouton nous conduisant au menu de l’application. L’accueil sera comme suite :

46
Ainsi si on clique sur le menu on obtient l’interface suivant qui nous offre la possibilité de se
connecter via son compte Gmail, de créer un compte ou même de sélectionner les offres selon
leurs statuts (en location ou en vente)

47
Si l’application est lancée pour la première fois et on clique sur l’option se connecter, l’interface
ci-dessous se présente au client Elle lui demande d’autoriser à e-location d’accéder à vos
contacts

48
Après avoir accepté la demande, le fournisseur d’offre peut se connecter et ainsi il pourra
ajouter une offre.
CONCLUSION
Cette partie est la partie est plus délicate dans le développement de notre application. Beaucoup
de technologies sont utilisés notamment les API de Google App Engine dans la réalisation du
backend. Enfin, nous nous intéressons à tester l’application.

49
CONCLUSION ET PERSPECTIVES
Notre sujet de mémoire a consisté en la conception et le développement d’une
application Android « e-location» afin d’apporter la solution aux problèmes détectés dans le
marché immobilier du Sénégal.
Dans une dynamique de promouvoir une bonne gestion des ressources et un très bon
management moderne, dans un monde où le vent des progrès de la technologie souffle avec
force, dans un milieu où les clients utilisent des devises de plateformes différentes (ordinateurs,
mobile Android, mobile IOS, mobile Firefox,…), nous avons jugé nécessaire de faire deux
applications : une application App Engine qui fera office de Backend et une application Android
qui sera le client (frontend). Nous sommes arrivés à développer les fonctionnalités les plus
essentielles de l’application backend dans les temps (l’ajout d’une nouvelle offre, la recherche
d’une offre, les recommandations suivant la position géographique courante de l’utilisateur) et
nous avons pu développer quelques fonctionnalités de l’application client Android.
Ce mémoire nous a permis d’approfondir nos connaissances théoriques, acquises tous
le long de notre formation, par la pratique des nouvelles technologies. Cette expérience nous a
permis de maîtriser le langage de modélisation UML et les outils de développement Android à
savoir le SDK Android. Il nous a permis aussi de découvrir les langages comme JSP, XML,
JSON.
Le mémoire nous a également permis de découvrir comment fonctionne l’architecture
3-tiers. Nous nous sommes beaucoup instruits, notamment dans des domaines que nous
connaissions peu tels que la programmation sur Smartphone, la technologie NOSQL ou encore
la technologie Google APP Engine sur lequel, le développement n’a pas été une tâche facile du
fait qu’il y a peu du support puisque c’est récent.
Les plus grandes difficultés que nous avons rencontrées durant la conception de
l’application ont été d’utiliser le backend réalisé avec Google App Engine dans le client
Android et de trouver de la documentation sur cette technologie. En effet, la recherche de
renseignement demande de la patience car il est parfois difficile de trouver des informations sur
quelque chose de peu commun ou nouveau. Il a également été difficile de configurer
l’environnement sur lequel on travailler.
Nous avons également appris à surmonter une difficulté et de savoir prendre des
décisions lorsque plusieurs solutions présentent. Cela nous a permis de développer des
méthodes de recherche d’informations, notamment sur Internet.
Enfin, l’application que nous avons développée pourrait être enrichie par des
fonctionnalités avancées telles que l’intégration de la technologie kanel dans l’application
permettant ainsi de recevoir des sms de la part des fournisseurs et faire des recherches d’offres
de locations ou de ventes de par l’envoi d’un simple sms. Après avoir fini le client Android, les
IOS, WEB et Firefox resteront à finir. Nous pouvons aussi, rendre l’application compatible

50
avec plusieurs plateformes mobile, en la développant avec l’outil Adobe Flash qui génère des
programmes d’extension SWF et qui est la tendance actuellement dans le développement des
applications embarquées pour mobile.

51
Références bibliographiques
[1] http://countrymeters.info/fr/Senegal dernière visite 14/07/2015
[2] http://perspective.usherbrooke.ca/bilan/tend/SEN/fr/SP.URB.TOTL.IN.ZS dernière visite
14/07/2015
[3] www.kaymu.com, dernier visite le 08/12/2015
[4] www.lamudi.com , dernier visite le 08/12/2015
[5] www.Expat-Dakar.com , dernier visite le 08/12/2015
[6] http://www.commentcamarche.net/faq/34876-responsive-design-avantages-et-
inconvenients, dernier visite le 02/12/2015
[7] https://sites.google.com/site/omtrouhana/googleappengine/le-datastore , dernier visite
le 25 01 2016
[8] https://openclassrooms.com/courses/montez-votre-site-dans-le-cloud-avec-google-
app-engine/manipuler-le-datastore-avec-objectify , dernier visite le 25/01/2016
[9] https://cloud.google.com/datastore/ , dernier visite le 25/01/2016
[10] http://www.commentcamarche.net/faq/34876-responsive-design-avantages-et-
inconvenients , dernière visite le 21/12/2015
[11] https://developers.google.com/appengine/docs/java/datastore/entities#Properties_and_
Value Types.
[12] Wiiid A, Espiau F., Créez des applications pour Android, Licence Créative Commons
6 2.0, 2012.
[13] Damien Guignard, Julien Chable, Emmanuel Robles, Programmation Android de la
conception au déploiement, Edition Eyrolles.

Conception et developpement d'une application mobile Android e-location

Contenu connexe

Tendances (20)

Similaire à Conception et developpement d'une application mobile Android e-location (20)

Conception et developpement d'une application mobile Android e-location