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.