Developpe Ment Des Applications Mobiles

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/355904199
Polycopié de Cours : Développement des applications mobiles
Book · June 2021
CITATIONS READS
0 1,204
1 author:
Kabou Salheddine
University Ahmed Draia - Adrar
10 PUBLICATIONS 12 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Privacy Preserving Data Publishing View project
WSN Security View project
All content following this page was uploaded by Kabou Salheddine on 04 November 2021.
The user has requested enhancement of the downloaded file.

REPUBLIQUE ALGERIENNE DEMOCRATIQUE & POPULAIRE
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR & DE LA RECHERCHE SCIENTIFIQUE
Université Ahmed Draia Adrar

Faculté des Sciences et de la Technologie
Département des Mathématiques et Informatique
Polycopié de Cours :
Développement des applications

mobiles
Préparé par:
Dr: KABOU Salheddine
Kabou.salaheddine@yahoo.fr
2020/2021
Avant- propos
Ce polycopié de cours, conforme au programme enseigné, s’adresse aux étudiants de 3ème

année informatique. C’est un travail personnel qui émane de ma propre expérience lors de
mes activités pédagogiques dans le module de développement des applications mobiles.
Le contenu de ce polycopié est adapté avec le programme du canevas du socle commun

pour présenter les notions principales du développement d’une application mobile.
L’objectif majeur du module est de présenter les systèmes d’exploitation mobiles ainsi que
les plateformes de développement des applications mobiles. L’étudiant, à travers ce
polycopié, aura l’occasion de découvrir le développement d’applications dédiées aux réseaux
sans fil.
Connaissances requises : algorithmique, connaissance sur le web, POO
Evaluation : Contrôle continu : 40% ; Examen : 60%.
Ce document de cours s’articule autour de sept chapitres :
- Le premier chapitre contient une généralité de tous ce qui concerne le concept d’une
application mobile.
- Le deuxième chapitre est consacré à voir les notions du système embarqué, système
d’exploitation mobile et plus particulièrement le système Android.
- Le troisième chapitre est dédié à l’étude sur les principaux composants constitutifs
d'une application Android.
- Le quatrième chapitre illustre le principe et l’utilité des ressources ainsi que les
éléments principaux qui construisent une interface graphique.
- Le cinquième chapitre traite la création et l’utilisation des bases des données sous le
système d’exploitation mobile Android.
- Le sixième chapitre est réservé aux différentes étapes et moyens pour le déploiement
d’une application mobile.
- Le dernier chapitre vise à donner un exemple pratique pour le développement d’une
application sous le système d’exploitation mobile Android.
Table des matières
1 Généralités 6
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Terminaux mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Les assistants personnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Les téléphones intelligents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Les tablettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Les montres intelligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Application mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Les types d’application mobile . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3 Comparaison entre les types d’application mobile . . . . . . . . . . . . . . 9
1.3.4 Les domaines d’application d’une application mobile . . . . . . . . . . . . . 10
1.3.5 Les statistiques sur le marché mondiale . . . . . . . . . . . . . . . . . . . . 10
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Les systèmes d’exploitation mobile 13

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Les systèmes embarqués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Caractéristiques d’un système embarqué . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Architecture d’un système embarqué . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 L’application du système embarqué . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Système d’exploitation mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Nécessité d’un système d’exploitation . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.3 Caractéristiques d’un système d’exploitation mobile . . . . . . . . . . . . . 16
2.3.4 Les systèmes d’exploitations mobile dans le marché . . . . . . . . . . . . . . 16
2.4 Le Système d’exploitation mobile : Android . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.3 Les avantages d’Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.4 Les versions d’Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.5 Architecture d’Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 L’environnement de développement sous Android . . . . . . . . . . . . . . . . . . . 21
2.5.1 Méthodes de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1
TABLE DES MATIÈRES 2
2.5.2 Stucture d’un projet android studio . . . . . . . . . . . . . . . . . . . . . . 23

2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Les composants fondamentaux des applications mobiles 27

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 État d’une activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 Cycle de vie d’une activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Les services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Les types des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.2 Cycle de vie d’un service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Fournisseur de contenu (Content provider) . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Récepteur de diffusion (Broadcast receivers) . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Construction de l’interface utilisateur 36

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Les ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.2 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.4 Les types des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.5 Organisation des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.6 Récupérer une ressource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Les vues ( Widget) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.3 La gestion des événements sur les Widgets . . . . . . . . . . . . . . . . . . . 48
4.3.4 Identification et récupération des vues . . . . . . . . . . . . . . . . . . . . . 49
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Les bases des données sous Android 51

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Notions de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3.2 Architecture de SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4 SQLite en Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.1 Le package android.database.sqlite . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.2 La classe SQLiteOpenHelper . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 Les curseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5.1 Les lignes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5.2 Les colonnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
TABLE DES MATIÈRES 3
6 Déploiement d’une application mobile 56

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 Étape de préparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.1 Réalisation des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.2 Le nom de package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.3 Le nettoyage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.4 Le numéro de version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.5 Le fichier manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.6 Les serveurs de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.7 Icône de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3 Les moyens de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.1 Google Play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.2 E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.3 Un site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.4 Les autres marchés d’applications . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4 Les étapes de déploiement sur Google Play . . . . . . . . . . . . . . . . . . . . . . 60
6.4.1 Création d’un compte développeur . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.2 Création de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.3 Le remplissage des informations de l’application . . . . . . . . . . . . . . . 62
6.4.4 Téléchargement de l’APK de l’application . . . . . . . . . . . . . . . . . . . 64
6.4.5 Questionnaire de l’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.4.6 Le prix et la distribution de l’application . . . . . . . . . . . . . . . . . . . 64
6.4.7 Période d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7 Développement d’une application mobile (cas pratique) 67

7.1 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2 Préparation du projet android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.3 Préparation de l’interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.4 Réalisation de code Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Table des figures
1.1 Un assistant personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Les téléphones intelligents (smartphones) . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Une tablette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Les montres intelligentes (smartwatches) . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Les types d’application mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Le nombre de téléchargement d’application mobile . . . . . . . . . . . . . . . . . . 11
1.7 Les applications mobiles les plus téléchargées 2010-2019 . . . . . . . . . . . . . . . 11
2.1 Architecture générale d’un système embarqué . . . . . . . . . . . . . . . . . . . . . 14

2.2 Topologie d’un système embarqué . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Utilisation des SE mobile en 2019 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Architecture android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 La machine virtuelle Dalvik (MVD) . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Le SDK d’Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7 La page d’accueil d’Android studio . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8 L’arborescence globale d’un projet Android . . . . . . . . . . . . . . . . . . . . . . 25
2.9 Gradle Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Ensemble d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Architecture d’une activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Fonctionnement de la pile des activités . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Le cycle de vie d’une activé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Le cycle de vie d’un service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 Résolveur de contenu (ContentResolver) . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 Syntaxe d’un fichier XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Emplacement des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Syntaxe d’un quantificateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Structure de la classe R (exemple) . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5 Hiérarchie des éléments d’une interface graphique . . . . . . . . . . . . . . . . . . 43
4.6 Les principaux Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.7 fichier XML d’un LinearLayout avec sa représentation graphique . . . . . . . . . . 44
4.8 fichier XML d’un RelativeLayout avec sa représentation graphique . . . . . . . . . 45
4.9 Représentation graphique d’un TableLayout . . . . . . . . . . . . . . . . . . . . . 45
4.10 Les principales vues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.11 Exemple d’un Textview en XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4
TABLE DES FIGURES 5
4.12 Exemple d’un EditText en XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.13 fichier XML d’un Button avec sa représentation graphique . . . . . . . . . . . . . 48
4.14 XML d’un CheckBox avec sa représentation graphique . . . . . . . . . . . . . . . 48
4.15 Fichier XML d’un RagioGroup qui englobe des Radiogroup . . . . . . . . . . . . . 49
4.16 Fichier XML d’un TextView contenant un identifiant . . . . . . . . . . . . . . . . 50
5.1 Exemple d’une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 Architecture de SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Le package android.database.sqlite . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.1 fichier XML décrivant l’ancienne version . . . . . . . . . . . . . . . . . . . . . . . 58

6.2 fichier XML décrivant la nouvelle version . . . . . . . . . . . . . . . . . . . . . . . 58
6.3 La création d’un compte développeur . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4 L’étape de création d’une application . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.5 Le choix de la langue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.6 L’étape de description de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.7 L’étape d’ajouter des captures pour l’application . . . . . . . . . . . . . . . . . . . 63
6.8 L’étape de catégoriser l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.9 L’étape d’ajouter les moyens de contact . . . . . . . . . . . . . . . . . . . . . . . . 64
6.10 L’étape de définir une politique de confidentialité . . . . . . . . . . . . . . . . . . 64
6.11 L’étape de téléchargement de l’APK . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.12 Le questionnaire à remplir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.13 La distribution de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.1 Le choix de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.2 La configuration du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.3 L’activité principale de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.4 Liste des périphériques installés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.5 Le choix du terminal mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.6 L’exécution d’émulateur virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.7 La première interface de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.8 La version XML de première interface de l’application . . . . . . . . . . . . . . . . 72
7.9 L’interface finale de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.10 Convertissement de Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.11 Insertion des vues -1- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.12 Insertion des vues -2- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.13 L’emplacement des vues ProgressBar et ListView . . . . . . . . . . . . . . . . . . 75
7.14 La fonction initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.15 Les instructions du test de jeu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.16 L’exécution de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Chapitre 1
Généralités
1.1 Introduction
De nos jours, et après l’innovation de l’Internet, les nouveaux terminaux mobiles ( Téléphones
intelligents, tablettes,..etc) ont occupé une place importante dans notre vie quotidien. Cet afflux
technologique change radicalement notre rapport à l’informatique en affranchissant de l’utilisation
d’un micro-ordinateur classique.
Le présent chapitre porte ce contexte. Dans la première partie, on va aborder une généralités
sur les différents types des terminaux mobiles. La deuxième partie sera consacré à présenter une
description générale de tous ce qui concerne la notion d’une application mobile.
1.2 Terminaux mobiles

1.2.1 Les assistants personnelles
Un assistant personnel ou un PDA (Personal Digital Assistant) est un périphérique portable qui
s’intéresse pour la gestion des informations personnelles. Leurs utilisations est généralement pour la
navigation sur le Web, les vidéos, les photos, les applications bureautique ou les téléphones mobiles.
Les PDA ont différentes fonctionnalités tel que : les écrans tactiles, la connectivité Bluetooth et
Wifi, etc (la figure 1.1).
Figure 1.1 – Un assistant personnel
6
CHAPITRE 1. GÉNÉRALITÉS 7
Figure 1.2 – Les téléphones intelligents (smartphones)
Figure 1.3 – Une tablette
1.2.2 Les téléphones intelligents

Un smartphone (téléphone intelligent) est un téléphone mobile offrant des capacités très avan-
cées par rapport à un téléphone mobile simple. Un smartphone typique possède un écran tactile
de haute résolution, une connectivité WIFI, des capacités de navigation Web et de la capacité
d’accepter des applications sophistiquées (la figure 1.2).
La plupart de ces appareils fonctionnent sur l’un de ces systèmes d’exploitation mobiles popu-
laire : Android, Symbian, IOS, BlackBerry OS et Windows.
1.2.3 Les tablettes

Une tablette est un intermédiaire entre l’ordinateur portable et le téléphone intelligent. Il se
présente sous la forme d’une interface à écran tactile et qui possède généralement une application
logicielle utilisée pour exécuter un clavier virtuel. Elle offre à peu près les mêmes fonctionnalités
qu’un ordinateur personnel tels que la consultation et l’envoi de courrier électronique, la navigation
sur le web et tout ce qui concerne la bureautique (la figure 1.3).
1.2.4 Les montres intelligentes

Une montre intelligente ( smartwatch ), aussi appelée « montre connectée » est une montre
bracelet électronique qui intègre des fonctions allant au-delà du simple affichage de l’heure et du
chronométrage. Elle présente des fonctions de communication élaborées telles que la réception-
émission d’appels téléphoniques. Ce type de montre, est souvent équipé d’un écran tactile et qui
Figure 1.4 – Les montres intelligentes (smartwatches)
offre des caractéristiques comparables à celles d’un Smartphone (la figure 1.4).
1.3 Application mobile

1.3.1 Définition
Une application mobile est un logiciel applicatif conçu pour s’exécuter à partir du système
d’exploitation d’un dispositif mobile tel qu’un smartphone, une tablette ou PDA. Les applications
mobiles servent souvent à offrir aux utilisateurs des fonctionnalités similaires à ceux du PC [3].
Une application mobile peut être soit installée directement sur l’appareil dès sa construction en
usine soit téléchargée depuis un magasin d’applications dit « application store » telles que Google
Play, l’App Store ou encore le Windows Phone Store. Une partie des applications disponibles sont
gratuites tandis que d’autres sont payantes. Il existe plusieurs systèmes d’exploitation mobile dont
les plus répondu sont :
• iOS (Apple) utilisé sur iPhone et iPad.
• Android (Google) qui anime un grand nombre de smartphones tels que Samsung, HTC, LG,
Motorola. . .
• Blackberry OS.
• Windows Phone (Microsoft)
• Symbian (Nokia)
Remarque 1.3.1.1 Dans le deuxième chapitre, on va présenter une description détaillée sur le
système d’exploitation mobile le plus célèbre au monde (Android).
1.3.2 Les types d’application mobile

La conception d’applications mobiles peut se faire suivant trois stratégies de développement
distinctes.
Application native
Il s’agit d’application conçue pour une grande partie de systèmes d’exploitation fiables par les
Smartphones en se référant à un langage particulier à chacun d’eux. Ce mode d’application est
accessible seulement sur les plateformes d’applications (AppStore IOS, PlayStore pour Android,
...) et qui retirent 25 % du prix de vente pour une application native payante.
Le développement de l’application native nécessite le recours à la mémoire du Smartphone sans

omettre les options reliées au système d’exploitation en question. De cette façon, le résultat se
résume dans l’aboutissement à des applications mobiles avec des fonctions plus professionnelles,
développées et performantes au même niveau que les applications en HTML5/CSS3 et les applica-
tions hybrides. Le souci des applications natives est que les utilisateurs doivent avoir un système
d’exploitation mobile donné pour qu’ils peuvent les utiliser. Pour assurer un usage plus exponentiel
de ces applications mobiles, il faut penser à lancer la même application mobile compatible à tout
système d’exploitation mobile.
Application web
Contrairement à une application native, une application web est une application mobile dé-
veloppée avec les outils de développement web actuel : HTML5, CSS3 et JavaScript. C’est une
application qui une fois développée est accessible et exécutable sur tous les smartphones via leur
navigateur web.
L’avantage de ces applications est : le gain de temps et d’argent réalisé grâce à leur déve-
loppement unique et leur déploiement multiplateformes. Dans un cas, vous développez une seul
application alors que dans l’autre (application native), vous développez trois applications (pour
Android, IOS et Windows Phone).
Application hybride
Une application hybride est une application qui combine les deux types d’applications précé-
dentes. Elle sert essentiellement de faire une passerelle entre le langage web et le natif.
L’avantage de ces applications c’est qu’elles nous permette d’utiliser un seul et même outil
pour le développement et les langages issus du développement Web pour tous les mobiles (IOS,
Android et Windows Phone). Notons que les applications hybrides sont accessibles exclusivement
sur iPhone et Android.
1.3.3 Comparaison entre les types d’application mobile

La comparaison entre ces types d’application se fait à travers deux critères essentiels dans la
conception d’une application mobile.
• Le coût :Il représente un critère très important lors du choix de type d’application mo-
bile dans la phase du développement. Le coût sera très cher si on a choisi de développer
une application native pour plusieurs systèmes d’exploitation mobile. Selon le nombre de
plateformes cibles, une technologie web ou même hybride sera souvent moins coûteuse.
• La rapidité :Les applications web qui sont accessibles via des navigateurs web sont toujours
moins rapides dues que leurs complexités par rapport aux différentes plateformes, tandis
que les applications natives sont toujours plus rapides car ils sont développées et adaptés
spécialement pour une seule plateforme.
Figure 1.5 – Les types d’application mobile
1.3.4 Les domaines d’application d’une application mobile

Le domaine d’utilisation des applications mobiles est très vaste, on peut citer par exemple :
• la géolocalisation.
• Itinéraire
• Payement mobile.
• Les jeux
• Les réseaux sociaux
• etc
1.3.5 Les statistiques sur le marché mondiale

Le nombre de téléchargement des applications mobiles pour les différentes plateformes est en
augmentation pour chaque année. Le nombre a atteint 178 milliards en 2017 et 205 milliards en
2018 et il sera augmenté de presque 45% ( sur cinq années) pour qu’il atteigne 258 milliards en
2022 [10].
Le nombre de téléchargement des applications issues des deux plateformes Play Store et App
Store a atteint un record de plus de 120 milliards seulement pour l’année 2019 sachant que les
réinstallations et les mises à jours n’ont pas été prises en considération lors du statistiques. La
figure 1.7 présente les applications les plus téléchargées sur Android et iOS entre 2010 et 2019.
Figure 1.6 – Le nombre de téléchargement d’application mobile
Figure 1.7 – Les applications mobiles les plus téléchargées 2010-2019

1.4 Conclusion
Le premier chapitre de ce cours est dédié à l’illustration tous ce qui touche le concept de l’in-
formatique mobile. Dans la première partie, on a montré les différents supports physique sur la
quelle, une application mobile va s’exécuter tels que les assistants personnelles et les tablettes.
La deuxième partie est réservée à présenter une généralité sur l’application mobile. Au début,
on a commencé par définir la notion d’une application mobile, ensuite on a classifié les trois types
d’applications mobiles et les comparé selon certains critères. Enfin on a étudié les dernières sta-
tistiques sur le marché mondiale par rapport au nombre de téléchargement pour les différentes
plateformes.
Dans le prochain chapitre, on va s’intéresser à présenter le support logiciel qui va se charger de

faire fonctionner les composants matériels (composants physique) et logiciels (composants logique)
de l’univers mobile. Ce support est s’appelle : un système d’exploitation mobile
Chapitre 2
Les systèmes d’exploitation mobile
2.1 Introduction
Un système d’exploitation mobile (SEm) joue le rôle d’une passerelle entre les composants
matériels d’un terminal mobile et les composants logiciels qui représentent les applications mobile.
Il est considéré comme une plateforme sur laquelle, une application mobile va s’exécuter. Le présent
chapitre va se baser sur tous ce qui touche le concept d’un SEm et plus particulièrement le système
Andrdoid. Ce chapitre vise également une étude sur les différents méthodes de développement
d’une application mobile sous le SEm Andrdoid.
2.2 Les systèmes embarqués

2.2.1 Définitions
Il est difficile de donner une définition précise pour le concept d’un système embarqué, mais on
peut citer quelques définitions qui vont nous éclairer ce concept :
• Un Système Embarqué : est une combinaison de matériels et logiciels permettant de
remplir une ou plusieurs fonctions spécifiques avec des contraintes plus ou moins sévères tel
que la consommation, la température, la taille, les performances... etc [6].
• Un Système Embarqué :est susceptible d’être utilisé dans un environnement matériel
de faibles performances (si l’on compare au PC de bureau d’aujourd’hui). Si l’ajout de
quelques Mo de mémoire sur un PC de bureau n’a pas une grosse influence sur le budget
d’un utilisateur, le gain de quelques Mo sur un produit de grande consommation (téléphone,
équipement auto mobile) a une énorme influence sur le coût final [7].
2.2.2 Caractéristiques d’un système embarqué

• Faible coût : Les développeurs des systèmes embarqués cherchent à trouver l’équilibre
entre l’augmentation du prix et la performance des produits pour donner aux clients plus
de chance à avoir la possibilité d’acheter des produits performants et chers.
• Faible consommation :Pour qu’une appareil doté d’un système embarqué reste autonome
le plus possible, il faut qu’elle ait une bonne gestion de consommation d’énergie. Le défit
est d’avoir une bonne gestion d’énergie avec des batteries de faible capacité.
13
CHAPITRE 2. LES SYSTÈMES D’EXPLOITATION MOBILE 14
Figure 2.1 – Architecture générale d’un système embarqué
Figure 2.2 – Topologie d’un système embarqué
• Faible encombrement et faible poids : Il est très important de minimiser la taille

et le poids pour un système embarqué. Ce qui revient que les composants électroniques
(analogique et/ou numérique) doivent cohabiter sur une faible surface.
• Fonctionnement en temps réel : Les opérations de calcul dans les systèmes embar-
qués doivent être faites en réponse aux évènements internes ou externes. La validité et la
pertinence d’un résultat dépendent du moment où il est délivré [7].
• Environnement : Un système embarqué doit être adapté à un ensemble de contraintes
environnementales. On peut citer [7] :
- La température.
- L’humidité.
- Les vibrations.
- Les chocs.
2.2.3 Architecture d’un système embarqué

L’architecture d’un système embarqué est similaire à l’architecture d’un ordinateur simple. Elle
est composée de trois couches principales : La couche application et la couche du système d’exploi-
tation qui constituent la partie Software et la matériel qui forme la partie hardware. La différence
entre les deux architectures réside dans les composants de chaque couche et particulièrement dans
la couche matériel. Cette dernière contient un ensemble des éléments physiques qui cohabitent
entre eux sur une faible surface dans le but de traitement de données [7].
On peut classifier les composants matériels d’un système embarqué comme suivant (la figure
2.2) :
• Équipements permanents : qui représentent l’unité centrale qui est formée de :
- CPU : microprocesseur(s) ou des microcontrôleurs.
- RAM : mémoire centrale.
• Équipements supplémentaires : ces équipements ne sont pas exhaustives et elles dé-
pendent toujours de l’application dédiée.
- Mémoire de masse : le disque dur, la mémoire flash, l’utilisation de ROM, le disque à
distant,. . . ,etc.
- Entrées : les capteurs/convertisseurs, le clavier, télécommandes (infrarouge, Bluetooth,
radio...),. . . ,etc.
- Sorties : les écrans et afficheurs LCD, le système d’alarme ou synthèse vocale. L’impri-
mante en tous genres comme papier, étiquettes, photos,. . . ,etc.
- IHM (Interface Homme Machine) : c’est un dispositif qui sert à communiquer entre
l’humain et la machine (exemple : les dispositifs «TouchScreen») [7].
2.2.4 L’application du système embarqué

Les systèmes embarqués font plus que jamais partie de notre vie quotidienne. Ils peuvent être
remarqués par toute utilisation d’une machine à base de microprocesseurs et nécessitent une fiabilité
impeccable du fait du coût élevé de leur fabrication. Les systèmes embarqués sont introduites dans
divers domaines, à savoir [7] :
• Le transport : Automobile, Aéronautique (avionique), etc.
• L’astronautique : fusée, satellite artificiel, sonde spatiale, etc.
• Militaire : missile
• Télécommunication : Set-top box, téléphonie, routeur, pare-feu, serveur de temps, téléphone
portable, etc.
• Électroménager : télévision, four à micro-ondes.
• L’impression : imprimante multifonctions, photocopieur, etc.
• L’informatique : disque dur, lecteur de disquette, etc.
• Le multimédia : console de jeux vidéo, assistant personnel
• Guichet automatique bancaire (GAB)
• Équipement médical
2.3 Système d’exploitation mobile

2.3.1 Nécessité d’un système d’exploitation
Comme on a vu dans la partie précédente, un système embarqué contient des composants logi-
ciels et matériels qui doivent fonctionner ensemble.Pour que ces éléments logiciels se fonctionnent,
ils doivent s’exécuter sur un système d’exploitation [4].
Remarque 2.3.1.1 un système d’exploitation embarqué ne doit pas avoir toutes les fonctionnalités
et caractéristiques d’un système d’exploitation pour ordinateur.
Figure 2.3 – Utilisation des SE mobile en 2019
2.3.2 Définitions
• Un système d’exploitation mobile est un ensemble de programmes responsable de la gestion
des opérations, du contrôle, de la coordination, de l’utilisation du matériel et du partage
des ressources d’un dispositif entre divers programmes tournant sur ce dispositif.
• Un système d’exploitation mobile est une plateforme logicielle sur laquelle les autres pro-
grammes appelés « programmes d’applications » peuvent s’exécuter sur des appareils mo-
biles tels que les PDA (personnal digital assistant), les téléphones cellulaires, smartphones,. . . ,etc.
Remarque 2.3.2.1 Les systèmes d’exploitation mobiles se diffèrent en fonction des fonctionnali-
tés qu’ils soutiennent. Par exemple un système d’exploitation pour PDA est différent d’un OS pour
Smartphone
2.3.3 Caractéristiques d’un système d’exploitation mobile

Un système d’exploitation mobile regroupe un ensemble des fonctionnalités ; dont :
• La gestion de la mémoire.
• La gestion des microprocesseurs et l’ordonnancement.
• La gestion de système de fichiers La gestion des I/O.
• La gestion de sécurité.
• La gestion de fonctionnalités multimédia.
• ...
2.3.4 Les systèmes d’exploitations mobile dans le marché

A l’échelle mondiale, le marché des SE mobile se réduit à quatre grands acteurs : iOS (iPhone),
Android (Google), KaiOS ( Mozilla) et Windows (Microsoft). La figure 2.3 présente le pourcentage
de l’utilisation de ces quatre SE mobile durant l’année 2019.
2.4 Le Système d’exploitation mobile : Android

2.4.1 Définition
Android est un système d’exploitation mobile basé essentiellement sur le noyau Linux et conçu
par l’entreprise americaine Google. En premier lieu, il était utilisé seulement par les smartphones et
tablettes tactiles, puis s’est diversifié dans les objets connectés et ordinateurs comme les télévisions
(Android TV), les voitures (Android Auto) et les montres intelligentes,...,etc.
2.4.2 Historique
En 2003, la création d’une entreprise américaine nommée : Android Incorporated qui était ra-
chetée par Google en 2005 dans le but de s’introduire sur le marché des produits mobiles.
le défi essentiel d’Android n’était pas de développer un système d’exploitation mobile qui permet
uniquement de transmettre des appels et d’envoyer des SMS, mais qui devait offrir à l’utilisateur la
possibilité d’interagir directement avec son environnement (particulièrement avec son emplacement
géographique). Les systèmes d’exploitation mobile les plus répondus à l’époque étaient Windows
Mobile et Symbian. 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.
En janvier 2007, l’entreprise Apple a dévoilé un nouveau produit ( téléphone intelligent) qui est
tout simplement révolutionnaire pour l’époque. L’annonce représente une apparition d’une nou-
velle concurrence pour les autres fabricateurs. Le problème étant que pour atteindre le niveau
d’iOS (iPhone OS, le système d’exploitation pour iPhone), il aurait fallu des années de recherche
et développement à chaque constructeur.
En novembre 2007 et par l’initiative de Google, 35 entreprises évoluant dans l’univers du mo-
bile, dont Google ont créé l’Open Handset Alliance (OHA). Le but primordiale de cette alliance
est de développer un nouveau SE mobile open source qui doit concurrencer les autres systèmes
propriétaires, en particulier iOS. OHA compte à l’heure actuelle 80 membres.
C’est au quatrième trimestre 2010 qu’Android devient le système d’exploitation mobile le plus
utilisé au monde cite2013-android.
2.4.3 Les avantages d’Android

• Open source : Dans l’univers Android, chacun peut à tout moment télécharger les sources
et les modifier selon son goûts en utilisant des bibliothèques open source puissantes, telles
que par exemple OpenGL pour la gestion d’images 2D et 3D et SQLite pour les bases de
données,...,etc.
• Gratuit : Android est gratuit ou presque pour les différents types de consommateurs. Pour
poster des applications sur le Play Store, il coûtera presque 25 dollars (équivalent à 3300
DA). Il faut noter aussi que 70 % du prix de gain pour chaque application revient au
développeur et 30 % a Google.
• Facile à développer : Le développement sous l’univers d’Android est très simple grâce
aux différentes API mises à disposition qui facilitent et accélèrent grandement le travail. Le
point fort de ces APIs c’est qu’ils sont très complètes et très faciles d’accès.
• Facile à vendre : Une application dédiée au plateforme Play Store a plus d’opportunités
d’être téléchargée et diffusée grâce au nombre croissant de visiteurs qui utilisent et profitent
de cette plateforme
• Flexible : Le système est extrêmement portable, il s’adapte à beaucoup de structures
différentes. Android est construit de manière à faciliter le développement et la distribution en
fonction des composants en présence dans le terminal (si une application nécessite d’utiliser
le Bluetooth, seuls les terminaux équipés de Bluetooth pourront la voir sur le Play Store).
2.4.4 Les versions d’Android

La première version d’Android a été distribuée en novembre 2007. Depuis, de nombreuses ver-
sions ont vu le jour. À partir de la sortie de la version 1.5, les versions d’Android deviennent avoir
des noms de sucreries selon un ordre alphabétique ( le nom de la version 1.5 est Cupcake). Depuis
la version 10, Google a décidé d’abandonner les noms de desserts (table 2.1).
Il faut noter qu’il y a aussi des versions alternatives qui s’appellent : ROM Custom. Il s’agit
d’un nouveau logiciel créé à partir du code source d’un logiciel existant lorsque les droits accordés
par les auteurs le permettent. Ces systèmes modifiés offrent de nouvelles fonctions (photos, écran
d’accueil, apparence de l’interface, autonomie, etc.). Le développement sous ce contexte est appelé
un développement participatif où un ensemble de développeurs décident de concevoir leur propre
système.
2.4.5 Architecture d’Android

Comme illustré dans la figure 2.4 , l’architecture du système Android s’appuie essentiellement
sur quatre principaux niveaux qui sont les suivants [1] :
• Le noyau Linux
• Les librairies ( bibliothèques) et l’environnement d’exécution
• Le module de développement d’applications
• Les différentes applications
Le noyau (Kernel)
Le système d’exploitation Android se base sur un noyau Linux (Kernel), régulièrement mis à
jour selon les versions du système : si les anciennes versions utilisaient la version 2.6.x du noyau
Linux, les actuelles dernières versions (Android 10) sont basées sur la version 4.14 de Linux. Le
noyau est l’élément du système d’exploitation qui représente la passerelle entre la partie matérielle
et la partie logicielle.
Cette première couche prend en charge la gestion des couches basses (gestion des processus, de
la mémoire, de la couche matérielle) ainsi que les droits utilisateurs ( comme montré dans la figure
2.4, la couche Kernel est la seule couche qui gère le matériel). Il faut noter que la version du noyau
utilisée avec Android est une version développée spécialement pour l’environnement mobile, avec
une gestion avancée de la batterie et une gestion particulière de la mémoire.
Numéro de version Nom de version Date de sortie

1.0 Aucun 11 novembre 2007
1.1 Petit Four 22 octobre 2008
1.5 Cupcake 30 avril 2009
1.6 Donut 15 septembre 2009
2.0 Éclair 26 octobre 2009
2.2 Froyo 20 mai 2010
2.3 Gingerbread 06 décembre 2010
3.0 Honeycomb 22 février 2011
4.0 Ice Cream Sandwich 19 octobre 2011
4.1 09 juillet 2012
4.2 Jelly Bean 13 novembre 2012
4.3 24 juillet 2013
4.4 KitKat31 octobre 2013
5.0 03 novembre 2014
Lollipop
5.1 09 mars 2015
6.0 Marshmallow 5 octobre 2015
7.0 22 août 2016
Nougat
7.1 05 décembre 2016
8.0 21 août 2017
Oreo
8.1 05 décembre 2017
9.0 Pie 6 août 2018
10.0 Android 10 3 septembre 2019
Table 2.1 – Les versions d’Android
Figure 2.4 – Architecture android

Figure 2.5 – La machine virtuelle Dalvik (MVD)
Les bibliothèques (librairies)
Les bibliothèques utilisées dans Android sont open sources ( écrites en C et/ou C++ ). Elles
offrent des services de qualité tels que la bibliothèque d’affichage en 2D (SGL) et de 3D (OpenGL),
la bibliothèque de base de données (SQLite), la lecture et l’enregistrement audio et vidéo (Media
Framework), un moteur de navigation Web (WebKit),...,etc.
L’environnement d’exécution ( Android Runtime)
l’environnement d’exécution d’Android, qui est basé sur une technologie Java et sur le concept
de machine virtuelle, se trouve dans le même niveau que l’ensemble des bibliothèques. Vue que
les contraintes matériels des dispositifs mobiles (peu de mémoire et la vitesse du processeur), il
était difficile d’utiliser une machine virtuelle Java standard. Google a pris la décision de créer une
nouvelle machine virtuelle Dalvik, afin de mieux répondre à ces limitations.
Les applications Java, développées pour Android, doivent être compilées au format Dalvik
exécutable (.dex) avec l’outil (dx). Cet outil compile les (.java) en (.class) et ensuite il convertit
ces (.class) en (.dex).
Le module de développement d’applications ( Application framework)
Les fonctionnalités fournis par les bibliothèques d’Android sont ensuite utilisées par cette couche
sous forme de bibliothèques Java. Celles-ci offrent des composants réutilisables spécifiques à des
domaines particuliers qui permettent aux développeurs de créer des applications riches. À ce niveau
on distingue deux types de service :
• Les services cœurs de la plateforme (Core Plateform Services) : Un service est une
application, qui s’exécute en arrière-plan et qui n’a aucune interaction avec l’utilisateur (
voir le chapitre 03). Les services cœurs de la plateforme (Core Plateform Services) apportent
des services importants au fonctionnement de la plateforme :
- Activity Manager : il prend en charge de la gestion du cycle de vie des applications ainsi
que le maintien de la pile de navigation qui permet d’aller d’une application à une autre.
- Package Manager : il est utilisé, par l’Activity Manager, pour charger les informations
provenant des fichiers (.apk) (Android package file).
- Window Manager : il s’occupe de la gestion des fenêtres des applications (quelle fenêtre
doit être affichée devant une autre à l’écran).
- Resource Manager : Il s’intéresse pour la gestion de tous ce qui n’est pas du code, toutes
les ressources (images, fichier audio, etc.).
- Content Provider : Il gère le partage de données entre applications.
- View System : Il fournit tous les composants graphiques : listes, grilles, boutons,etc...
• Les services matériels (Hardware Services) : ce type de service fournit un accès vers les
API matérielles :
- Telephony Service : il permet d’accéder aux interfaces téléphoniques (GSM, 3G, etc.).
- Location Service : il permet d’accéder au GPS.
- Bluetooth Service : il permet d’accéder à l’interface Bluetooth.
- Wi-Fi Service : il permet d’accéder à l’interface Wifi.
- USB Service : il permet d’accéder aux interfaces USB.
- Sensor Service : il permet d’accéder aux capteurs (capteur de luminosité, de proximité,
d’accélération,etc.).
Les applications ( Applications and Widgets)
Il s’agit d’un ensemble d’applications que l’on peut trouver sur Android. Ces applications
peuvent être, soit téléchargées à partir du magasin d’application officiel, soit installées par défaut
telles que l’application d’accueil (aussi appelée Launcher), le navigateur web, les applications de
SMS et téléphonie, etc.
2.5 L’environnement de développement sous Android

2.5.1 Méthodes de développement
Afin de développer des applications sous Android, un ensemble d’outils est nécessaire. Généra-
lement il y a deux manières pour développer une application Android :
- Méthode classique : en utilisant un IDE (Eclipse) + JDK + SDK
- Méthode moderne : en utilisant Android Studio
JDK (Java Developpment Kit)
Les applications développées sous Android sont essentiellement écrites en langage Java qui est
un langage de programmation orienté objet et qui se caractérise par la portabilité ( signifie qu’une
application écrite en Java, s’exécutant sur Windows (par exemple), pourra facilement tourner sur
Mac ou GNU/Linux ).
Cette particularité ( portabilité) vient du fait que l’exécution d’une n’importe quelle application
écrite en Java a besoin d’une machine virtuelle appelée JVM. Pour avoir une JVM sur un ordina-
teur, il faut télécharger le JRE qui contient, en plus de la JVM, des bibliothèques Java standards [3].
Figure 2.6 – Le SDK d’Android
La JVM ne lit pas directement le code Java. Elle lit un code compilé (le byte code). Pour
passer du code Java, que le développeur écrit, au code compilé, lu par la JVM, des outils spéciaux
sont nécessaires. Ces outils sont inclus dans le JDK. De plus, le JDK contient le JRE (et donc la
machine virtuelle), ce qui est bien pratique. Pour résumer, on dira que :
- Pour un simple utilisateur de Java : il doit avoir le JRE.
- Pour un développeur : il aura besoin des outils du JDK.
SDK (Software Development Kit) Android
Un SDK (un kit de développement logiciel), est un ensemble d’outils que met à disposition un
éditeur afin de permettre de développer des applications pour un environnement précis. Le SDK
Android permet, donc, de développer des applications pour Android et uniquement pour Android.
Au premier lancement du SDK, un écran semblable à la figure 2.6.
En regardant bien le nom des paquets, on remarquera qu’ils suivent tous un même motif.
Il est écrit à chaque fois : Android [un nombre] (API [un autre nombre]). La présence de ces
nombres s’explique par le fait qu’il existe plusieurs versions de la plateforme en circulation. Le
premier nombre correspond à la version d’Android et le second à la version de l’API Android
associée. Quand on développe une application, il faut prendre en compte ces numéros, puisqu’une
application développée pour une version précise d’Android ne fonctionnera pas pour les versions
antérieures [3].
Eclipse
Eclipse IDE est un environnement de développement intégré libre, extensible, universel et po-
lyvalent, permettant potentiellement de créer des projets de développement mettant en œuvre
n’importe quel langage de programmation. Eclipse IDE est principalement écrit en Java (à l’aide
de la bibliothèque graphique SWT d’IBM), et ce langage, grâce à des bibliothèques spécifiques, est
également utilisé pour écrire des extensions.
De plus, Eclipse est conçu pour pouvoir être complété avec des plugins (extension) tel que ADT
(Android Development Tools), la fonction principale de ce plugin est de créer un pont entre Eclipse
et le SDK Android.
Andriod studio
Jusqu’au debut de Mai 2013, pour développer des applications Android, Google mettait en
avant l’utilisation d’Eclipse couplé avec le Plugin ADT (Android Development Tools). Cette pre-
mière solution a tout de même permis à Google de posséder le Store d’application le plus riche. Le
15 mai, Google a montré la première version d’Android Studio. En Access preview au départ pour
sa version 0.1, puis passé en bêta en juin 2014 pour la version 0.8, jusqu’à l’arrivée à la version 3.5
utilisée dans nos séances de TP.
Android studio n’a pas été développé de zéro mais il est basé sur l’IDE de JetBrains, IntelliJ
IDEA. Cette société propose de nombreux IDE pour différents langages (PHP Storm, RubyMine,
...) mais qui sont tous payant. Dans sa dernière version, Android Studio offre toutes les possibilités
nécessaires pour développer une application Android complète (la figure 2.7).
Android Studio permet principalement d’éditer les fichiers Java/Kotlin et les fichiers de confi-
guration XML d’une application Android. Il propose entre autres des outils pour gérer le dévelop-
pement d’applications multilingues et permet de visualiser rapidement la mise en page des écrans
sur des écrans de résolutions variées simultanément. Il intègre par ailleurs un émulateur permettant
de faire tourner un système Android virtuel sur un ordinateur [3].
2.5.2 Stucture d’un projet android studio

Les projets de développement sous Android ont changé d’architecture depuis le passage à An-
droid Studio. La structure générale d’un projet Android se compose de deux répertoires principaux :
- App.
- Gradle Scripts.
Dans la suite de ce cours, on va détailler chaque répertoire.
Le répertoire App
Tout comme bon nombre de technologies actuelles, les sources d’une application Android pos-
sèdent une structure bien définie qui doit être respectée (la figure 2.8). Ces arborescences permettent
non seulement de rendre les projets plus lisibles et organisés, mais aussi de simplifier le dévelop-
pement. Lors de la création d’un nouveau projet, il existe trois principaux répertoires constituant
l’arborescence globale d’un projet Android :
Figure 2.7 – La page d’accueil d’Android studio
• AndroidManifest.xml : c’est le premier fichier qui va être lu dans le démarrage d’Android.

Manifest est un fichier XML décrivant l’application et ses composants, tels que les activités,
les services, etc. Ce fichier permet de spécifier différentes options pour un projet Android,
comme le matériel nécessaire pour les faire fonctionner, certains paramètres de sécurité ou
encore des informations plus ou moins triviales telles que le nom de l’application ainsi que
son icône .
C’est une étape indispensable pour le fonctionnement de l’application. Le Manifest est, en
quelque sorte, la carte d’identité de l’application, et permet aussi d’autoriser l’exécution des
activités et autres actions de l’application.
• Java : c’est un répertoire contenant tous ce qui concerne le code source de l’application,
que ce soit avec le langage java ou bien le langage Kotlin.
• Res : c’est un répertoire contenant toutes les ressources telles que les images, les vues de
l’interface graphique, etc. Cette partie sera détaillée dans la partie : Ressources (Chapitre
04)
Gradle Scripts
Un projet Android Studio est un projet java basé sur Gradle. Gradle est un outil qui permet
l’automatisation des opérations de construction d’une application java comme e Make (projets
C++ sur Unix), Ant (projets Java dans Eclipse).
De même que make se sert d’un fichier Makefile, Gradle se sert d’un fichier nommé build.gradle
Figure 2.8 – L’arborescence globale d’un projet Android
Figure 2.9 – Gradle Scripts
pour construire le projet. Au moment de la compilation du projet, l’application finale est générée
au format APK, dans le répertoire bin de l’arborescence. C’est ce fichier qu’il faut ensuite déployer
sur les équipements, afin de pouvoir faire tourner l’application (la figure 2.9).
2.6 Conclusion
En premier lieu et avant de commencer à montrer le principe d’un système d’exploitation mo-
bile, on a abordé une généralités sur le système embarqué qui représente la notion de base d’un
SEm. Ce dernier est présenté d’une façon détaillée dans la seconde partie de ce chapitre. La troi-
sième partie était consacré à illustrer le chemin du lancement d’Andrdoid, ses différentes versions
ainsi qu’une présentation simplifié de son architecture. Dans la dernière partie, on s’est focalisé sur
l’environnement de développement sous Android, les différentes méthodes pour pouvoir développer
une application sous Andrdoid, ainsi qu’une description générale des deux répertoires construisant
la structure d’un projet Android Studio.
Le troisième chapitre sera consacré à l’étude des éléments essentiels qui composent une appli-
cation mobile. Ces éléments sont considérés comme le noyau principale qui permet de construire
une application mobile.

Chapitre 3
Les composants fondamentaux des

applications mobiles
3.1 Introduction
Les composants de l’application représentent les objets constitutifs d’une application Android.
Chaque composant est chargé d’une mission bien défini dans l’application Android et sert un objec-
tif distinct par rapport aux autres composants. La description de chaque composant et l’interaction
entre eux est déterminée dans le fichier de manifestation de l’application AndroidManifest.xml (voir
le chapitre précédant).
Les composants élémentaires qu’une application Android peut utiliser sont les suivants :
• Activité
• Service
• Récepteur de diffusion
• Fournisseur de contenu
3.2 Activité
La plupart des applications Android ont des architectures similaires. Penons par exemple, l’ar-
chitecture de l’application PlayStore qui est composée de plusieurs fenêtres, une fenêtre pour la
recherche des applications stockées dans PlayStore, une autre fenêtre, qui s’est ouvert une fois on
clique sur le résultat d’une recherche pour la description de l’application sélectionnée. Au bout
du compte, on peut dire qu’une application est un assemblage de fenêtres entre lesquelles il est
possible de naviguer.
Ces différentes fenêtres sont appelées activités. Pour pouvoir différencier une activité par rapport
à une autre, il faut juste comparer leurs interface graphique : si elles ont des interfaces différents,
c’est qu’il s’agit d’activités différentes (la figure 3.1). Il faut noter qu’une application ne peut jamais
afficher plus qu’une activité à la fois [5].
Il est très important de signaler que ce n’est pas la tâche de l’activité de créer les objets
27
CHAPITRE 3. LES COMPOSANTS FONDAMENTAUX DES APPLICATIONS MOBILES 28
Figure 3.1 – Ensemble d’activités
Figure 3.2 – Architecture d’une activité
graphiques, elle n’est que l’outil qui sert à faire le lien entre l’interface graphique et la logique
programmatique.
En outre, une activité comporte des informations sur l’état actuel de l’application : ces infor-
mations s’appellent le context. Ce context représente un lien avec le système Android ainsi que les
autres activités de l’application (la figure 3.2).
3.2.1 État d’une activité

Dans les systèmes d’exploitations et plus particulièrement dans l’univers Android, il peut qu’à
chaque instant, une application est remplacée par une autre application, qui a une priorité su-
périeure. Si une application exige assez de ressources système, alors elle bloquera le système de
fonctionner correctement et Android sera obligé de l’arrêter. Par exemple : si un utilisateur reçoit
un appel, il devient plus important qu’il puisse y répondre que de faire en sorte qu’il puisse écouter
la chanson que l’application diffuse.
Comme illustrée dans la figure 3.3, quand une application se lance, elle se positionne tout en
haut de ce qu’on appelle la pile d’activités.
L’activité qui se trouve toujours au-dessus de la pile est celle que l’utilisateur interagit avec.
Lorsqu’une nouvelle activité qui a une priorité supérieure arrive, elle se place directement au som-
met de la pille et c’est elle qui va s’afficher à la place de l’application courante, qui n’est plus qu’à la
Figure 3.3 – Fonctionnement de la pile des activités
deuxième place. L’ancienne activité ne réapparaîtra qu’à partir du moment où toutes les activités
qui se trouvent au-dessus d’elle seront arrêtées et sorties de la pile [5].
Une activité peut se présenter dans trois états qui se distinguent surtout par leur visibilité :
• Active : dans cet état, la position de l’activité est sur le dessus de la pile et elle peut être
utilisée en globalité. Une activité active doit être visible en totalité et elle représente l’appli-
cation qui possède tout le focus ( c’est à dire l’application courante sur-laquelle l’utilisateur
agit).
• Suspendue (paused) : les utilisateurs n’agissent pas directement sur une activité suspen-
due. Généralement, elle est partiellement visible pour l’utilisateur ( par exemple quand on
reçoit un SMS et qu’une fenêtre semi-transparente se pose devant notre activité pour afficher
le contenu du message et nous permettre d’y répondre). Dans cet état, l’application n’a plus
le focus, c’est l’application au-dessus qui l’a. Pour que l’application reprenne le focus, l’uti-
lisateur devra se débarrasser de l’application qui se trouve au-dessus et il pourra à nouveau
par la suite interagir directement avec l’activité. Si le système a besoin de mémoire, il peut
très bien tuer l’application.
• Arrêtée (stopped) : l’activité est complètement invisible à l’écran et certainement, l’ap-
plication n’a plus le focus. Le système retient son état pour pouvoir reprendre, mais il peut
arriver que le système tue l’application pour libérer de la mémoire système.
3.2.2 Cycle de vie d’une activité

Par défaut, une activité n’a pas de contrôle direct sur son propre état, il s’agit plutôt d’un
cycle rythmé par les interactions avec le système et d’autres applications. La figure 3.4 présente
un cycle de vie d’une activité qui montre l’ensemble des phases qu’elle va passer pendant sa vie,
de sa naissance à sa mort ( chaque phase est représentée par une méthode). Le cycle de vie d’une
activité est assez complexe et sa compréhension est essentielle dans le développement Android.
Lors du démarrage d’une activité, la première méthode qui est lancée est appelée onCreate.
Elle représente l’endroit privilégié pour initialiser les vues et pour démarrer les tâches d’arrière-plan
qui s’exécuteront pendant toute la durée de vie de l’activité. Cette méthode prend en paramètre
un Bundle (pile) qui contient l’état précédent de l’activité.
Cet appel est suivi par la méthode onStart afin d’indiquer le démarrage effectif de l’application
(pendant cet appelle, l’activité est visible). Cette méthode peut aussi être appelée par la méthode
onRestart.
Puis la méthode onResume est appelée dans le but d’exécuter tous les traitements nécessaires
au fonctionnement de l’activité (thread, processus, traitement), initialiser des variables et les lis-
teners. Ces traitements devront être coupées lors de l’appel à la méthode onPause et relancés si
besoin lors d’un futur appel à la méthode onRésume.
Après l’exécution de ces trois méthodes, l’activité devient exploitable et peut être en interaction
avec les utilisateurs. Si une autre activité passe au premier plan, l’activité en cours d’exécution
passera en pause. Il faut noter que juste avant l’appel à la méthode onPause, la méthode on-
SaveInstanceState doit être appelée dans le but de sauvegarder les informations importantes
portées par l’activité. Ces informations pourront être utilisées aux prochains démarrages de l’acti-
vité lors de l’appel à la méthode onRestoreInstanceState ou de l’appel à onCreate.
La méthode onPause permet d’arrêter tous les traitements réalisés (traitement non nécessaire
si l’activité n’est pas visible) par l’activité (traitement, thread, processus). Si l’activité devient
visible à nouveau, cela correspondra à un appel à la méthode onResume. Le passage de l’activité
à l’état “stopper” correspond à un appel à la méthode onStop. Dans cette méthode, il faut arrêter
tous les traitements restants. Une fois stoppée, l’activité peut :
• Soit être relancée : cela s’effectue par un appel à la méthode onRestart suivi du cycle de
vie normal de l’activité.
• Soit être tuée : cela s’effectue par un appel à la méthode onDestroy, dans laquelle vous
devez arrêter tous les traitements restants, fermer toutes les connexions à la base de données,
tous les threads, tous les fichiers ouverts, etc [5].
3.3 Les services

Un service est un composant qui s’exécute en arrière-plan pour réaliser des traitements sur une
longue période du temps. À l’opposé de l’activité, un service ne possède pas d’interface graphique,
il s’exécute uniquement en arrière-plan avec l’entrée de l’utilisateur. Par exemple, un service peut
jouer de la musique en arrière-plan lorsque l’utilisateur se trouve dans une autre application, ou il
peut récupérer des données sur le réseau sans bloquer l’interaction de l’utilisateur avec une activité
[5].
3.3.1 Les types des services

Il existe deux types de services :
Figure 3.4 – Le cycle de vie d’une activé

• les services locaux (started ou unbound service) : sont les services les plus courants, où
l’activité qui lance le service et le service en lui-même appartiennent à la même application.
• Les services distants (bound service) : Il s’agit d’un service qui est lancé par un composant
qui appartient à une autre application. Dans ce cas, il existe toujours une interface qui
permet la communication entre le processus qui a appelé le service et le processus dans
lequel s’exécute le service. Cette communication permet d’envoyer des requêtes ou récupérer
des résultats.
Il est aussi possible d’avoir un service qui applique les deux orientations à la fois. Ainsi, on peut
démarrer un service local et lui permettre d’accepter les connexions distantes par la suite.
3.3.2 Cycle de vie d’un service

La figure 3.5 est un schéma qui résume le fonctionnement d’un cycle de vie d’un service.
Pratiquement, on a deux cycles différents :
• Un cycle de vie pour un service locale où le service est lancé depuis l’application.
• Un cycle de vie pour un service distant où le service est lancé depuis un processus différent.
Les services locaux
Le lancement d’un service local est fait à travers une activité en utilisant la méthode startSer-
vice(). C’est la méthode onCreate() qui permet de créer un service dans le cas où il n’existait
pas. Une fois le service est crée, la méthode onStartCommand () est appelée pour permettre le
lancement de ce service.
Remarque 3.3.2.1 si le service existait déjà au moment d’appeler la méthode startService(),

la méthode onStartCommande() est appelée directement sans passer par onCreate().
Juste comme le cas d’activité, Un service poursuivra son fonctionnement jusqu’à son arrêt, soit
à travers la décision de l’utilisateur, soit à travers l’Android qui décide de l’arrêter pour libérer
la mémoire RAM. Les services sont plus susceptibles d’être stoppés qu’une activité qui se trouve
au premier plan, mais plus favorisés que les autres processus qui ne sont pas visibles. La priorité
a néanmoins tendance à diminuer avec le temps : plus un service est démarré depuis une longue
période du temps, plus il est susceptible d’être arrêté.
Similairement aux activités où la méthode OnDestroy() permettant de tuer une application, on

peut aussi tuer un service en utilisant soit :
• La méthode stopSelf() : dans le cas où l’arrêt est fait depuis un service.
• la méthode stopService(Intent service) : dans le cas où l’arrêt est fait depuis une activité
( il faut utiliser un service qui doit décrire le service à stopper)
Les services distants
Pour utiliser un service distant, il faut prendre en considération d’avoir une connexion persis-
tante avec le service. Pour réaliser cette connexion, on appel la méthode bindService en utilisant
un paramètre de type ServiceConnection qui représente une interface pour le contrôle de l’exé-
cution du service.
Figure 3.5 – Le cycle de vie d’un service
La méthode onBind() reçoit un service de connexion à travers la méthode onServiceConnec-

ted() qui contient en paramètre un Ibinder qui représente un pont entre le service et l’activité,
mais au niveau du service.
Pour qu’un client puisse se libérer d’un service, il est possible utiliser la méthode onUnbind()
[5].
3.4 Fournisseur de contenu (Content provider)

Un fournisseur de contenu gère les données d’application partagée, Il encapsule les données et
offre des mécanismes pour définir la sécurité des données. Un fournisseur de contenu représente
une liaison qui fait connecter les données dans un processus avec du code réalisé dans un autre
processus [2].
Pour accéder aux données d’un fournisseur de contenu, l’objet ContentResolver qui est uti-
lisé et qui permet de faire la communication en tant que Client avec le fournisseurs. Les tâches
essentielles réalisées d’un fournisseur sont les suivants :
• La réception des demandes de données pour les Clients.
• La réalisation des actions demandées.
Figure 3.6 – Résolveur de contenu (ContentResolver)
• L’envoi des résultats.

Comme illustré dans la figure 3.6, les clients accèdent aux données stockées dans un fournisseur
de contenu à travers un résolveur de contenu qui :
• Présente une interface de type base des données (méthodes tels que query, insert, update,
delete,..ect).
• Fournit des services additionnels tels que la notification et la mise à jour des données.
Remarque 3.4.0.1 Il faut juste noter qu’il n’est pas nécessaire de développer un fournisseur des
données dans le cas où l’application à réaliser ne partage pas ses données avec d’autres applications.
Un fournisseur de contenu est implémenté comme une sous-classe de la classe ContentProvi-

der et doit implémenter un ensemble standard d’API permettant à d’autres applications d’effectuer
des transactions .
3.5 Récepteur de diffusion (Broadcast receivers)

Un récepteur de diffusion permet de notifier un certain nombre d’événements au niveau de sys-
tème Android ( par exemple : une notification annonçant que l’écran a été tourné, que la batterie
est faible,...,etc) ou bien au niveau de l’application ( par exemple : le pourcentage de télécharge-
ment d’une application) [2].
Les récepteurs de diffusion jouent généralement le rôle d’une passerelles vers d’autres com-
posants de l’application, principalement des activités et des services. Ils sont implémentés sous
la forme d’une sous-classe de la classe BroadcastReceiver et chaque message est un diffuseur
comme objet Intent.
3.6 Conclusion
Dans ce chapitre, on a présenté une explication détaillée sur les principaux composants d’une
application Android. D’abord, on a clarifié la notion de l’activité qui représente l’élément basique
d’une application mobile, ensuite on a passé à présenter le concept de service qui se caractérise par
son exécution en arrière plan. Le composant fournisseur de contenu a été aussi présenté comme
étant le gestionnaire des données d’application partagée, en enfin on s’est mis l’accent sur l’élément
récepteur de diffusion qui est le responsable pour la notification d’événements au niveau de système
Android.
Dans le prochain chapitre, on va essayer de simplifier la notion de ressources et la raison pour

laquelle on en aurait besoin, ainsi de montrer les éléments essentiels construisant une interface
graphique d’une application Android.
Chapitre 4
Construction de l’interface
utilisateur
4.1 Introduction
Selon les statistiques présentées dans le premier chapitre, Android est le système le plus utilisé
au monde et par conséquent il s’est installé sur plusieurs supports ayant des volumes différents.
Le défi qui se pose à ce niveau est comment faire pour adapter les applications sous le système
Android à ces différents supports.
Sous la problématique mentionnée au dessus, que la première partie de ce chapitre se focalise.

Dans cette partie, on va clarifier tous ce qui touche la notion de ressource ainsi que l’utilité et
l’avantage d’utiliser le langage XML. La deuxième partie est consacrée à la présentation des deux
types essentiels qui composent une interface graphique pour les applications Android ( Layout et
Vues), ainsi que la gestion de différentes interactions qui peuvent exister entre l’utilisateur et les
différents composants.
4.2 Les ressources

4.2.1 Motivation
Les ressources sont des fichiers qui contiennent des informations qui sont :
• Stockées en dehors du code Java.
• Statiques (le contenu d’une ressource restera inchangé entre le début de l’exécution de
l’application et la fin de l’exécution).
Avec la variété des terminaux sous lesquelles s’installe Android, il faut vraiment trouver une solution
qui va permettre à une application Android de tourner sur la plupart des terminaux. Les ressources
sont les moyens efficaces qui permettent d’adapter facilement une application android à toutes ces
situations différentes.
Exemple 4.2.1.1 Étant donnée l’application Galerie qui contient un ensemble d’album pour l’af-
fichage des photos. Il faut adapter la taille de chaque photo de l’album à l’écran de chaque terminal
36
CHAPITRE 4. CONSTRUCTION DE L’INTERFACE UTILISATEUR 37
utilisant cette application. Si par exemple la photo est très petite, il faudra l’agrandir et par consé-
quent, elle va perdre totalement sa qualité.
La solution optimale est de préparer antérieurement plusieurs images à afficher en fonction de la

résolution de l’écran. Un des moyens d’adapter les applications Android à tous les terminaux est
d’utiliser les ressources.
4.2.2 Définition
Les ressources sont des fichiers structurés d’une sorte qu’Android ait la possibilité de choisir
une ressource, parmi d’autres, qui va être utilisée pour s’adapter au matériel sur lequel s’exécute
l’application. L’objectif est de faciliter l’exécution des applications pour toutes les situations diffé-
rentes.
Le seule moyen qui permet aux ressources d’être adaptées aux différentes types de terminaux est
l’utilisation du langage de description XML [5].
4.2.3 XML
Définition
Le principe d’un langage de programmation (Java, C++, etc.) est de donner des instructions
au terminal pour qu’il puisse réaliser des calculs, et par la suite, mettre en forme le résultat de ces
calculs dans une interface graphique.
Contrairement aux langages de programmation, un langage de balisage (XML) ne s’intéresse

pas pour le calcul, mais il met l’accent sur la façon de mettre en forme l’information pour faciliter
la lecture et la maîtrise de cette information ( si on arrive à déterminer l’architecture d’un fichier, il
sera très facile de retrouver l’emplacement des informations contenues dans ce fichier et de pouvoir
les exploiter).
La syntaxe d’XML
Similairement au format HTML, un fichier XML commence par une déclaration signifiant l’uti-
lisation d’un langage XML. La première ligne dans la figure 4.1 permet d’indiquer que :
• On utilise la version 1.0 de XML.
• On utilise l’encodage des caractères qui s’appelle utf-8 qui est une façon de décrire les
caractères que contiendra le fichier.
la balise représente la composante la plus basique dans un format XML. Elle débute par le signe
< et se termine par >. On peut avoir deux types de balises :
• Une balise ouvrante : par exemple <bibliotheque>.
• Une balise fermante : Il faut noter que chaque balise ouvrante doit être fermée. Il existe
deux façon pour fermer une balise ouvrante :
- Soit par une balise fermante (exemple </bibliotheque>), auquel cas on peut avoir du
texte ou d’autres balises entre la balise ouvrante et la balise fermante.
- Soit on ferme la balise directement dans son corps :<bibliotheque />. La seule différence
est qu’on ne peut pas mettre de contenu entre deux balises puisqu’il n’y en a qu’une.
Figure 4.1 – Syntaxe d’un fichier XML
Ce type d’informations, qu’il soit fermé par une balise fermante ou qu’il n’en n’ait pas besoin,
s’appelle un nœud. On remarque dans la figure 4.1, que l’on a un nœud appelé bibliotheque, deux
nœuds appelés livre, etc.
la racine représente le nœud qui fait rejoindre tous les autres nœuds ( le nœud <bibliotheque>).
Dans le fichier XML, on peut avoir au moins une racine et au plus une racine dans laquelle on peut
établir toute une hiérarchie. Pratiquement, il est possible d’ajouter d’autres nœuds entre la balise
ouvrante et la balise fermante d’un nœud. Ces nœuds s’appellent des enfants, et le nœud encapsu-
lant s’appelle le parent. Les nœuds aussi peuvent avoir des attributs pour décrire des informations.
Dans la figure 4.1, le nœud <prix> a l’attribut devise (dans le douzième ligne).
4.2.4 Les types des ressources

Puisque le système Android est un système qui s’est installé sur différents terminaux, il était
obligé d’adapter l’affichage d’une application ( elle doit être affichée de la même manière sur un
écran 7 pouces comme un écran 10 pouces ), ou faire en sorte que les textes conviennent aux choix
de la langue de l’utilisateur. C’est pour cette raison qu’il faut organiser les différentes ressources
selon des répertoires, de façon à ce que Android aurait le choix d’utiliser tel élément pour tel types
de terminaux [5].
Les ressources sont classifiées dans une hiérarchie particulière de répertoires selon leurs types.
Pour qu’Android puisse retrouver facilement ces ressources, il faut que chaque type de ressource
soit associé à un répertoire particulier. Ces différents répertoires sont rassemblés dans un répertoire
globale nommé res. Ce répertoire est structuré de la manière suivante :
• Dessin et image (res/drawable) : contient les ressources de type image ( les images de
type PNG, JPEG et GIF) ainsi que des fichier XML décrivant des dessins ( ce qui donne
des images vectorielles qui ne se dégradent pas quand on les agrandit).
• Interface graphique (res/layout) : contient des fichiers XML qui représentent la dispo-
sition des interfaces graphique ( vues).

• Icônes de lancement (res/mipmap) : contient les ressources de différentes densités pour
les icônes de lancement.
• Différentes variables (res/values) : contient diverses ressources tels que des variables
standards, comme des chaînes de caractères, des dimensions, des couleurs, etc.
• Données brutes (res/raw) : contient des données diverses au format brut. Ces données
ne sont pas des fichiers de ressources standards, on pourrait y mettre de la musique ou des
fichiers HTML par exemple.
• Menu (res/menu) : contient des fichiers XML pour pouvoir constituer des menus.
4.2.5 Organisation des ressources

Le répertoire res contient les emplacements des ressources par défaut (la figure 4.2 ), c’est-à-
dire qu’il s’agit des emplacements qui visent le matériel le plus commun ( prenant un exemple que
le matériel le plus utilité est « Condor », alors les sous répertoires par défaut du répertoire res
doivent contenir tous les fichiers qui correspondent à ce type de matériel. Pour ajouter d’autres
ressources destinées à d’autres appareils, il faut créer d’autres sous répertoires et préciser qu’elles
sont destinées à ces types d’appareils.
En d’autres termes, en partant du nom du répertoire par défaut, il est possible de créer d’autres
répertoires qui permettent de déterminer à quels types de matériels les ressources contenues dans ce
répertoire sont destinées. Les restrictions sont représentées par des quantificateurs qui permettent
de préciser le matériel pour lequel les fichiers dans ce répertoire sont destinés. La syntaxe des
quantificateurs est présentée dans la figure 4.3 [5].
Remarque 4.2.5.1 On n’a pas besoin de créer des quantificateurs si on veut utiliser uniquement
l’emplacement par défaut.
Ces quantificateurs sont séparés par un tiret. Si Android n’arrive pas à trouver l’emplacement
dont le nom corresponde exactement aux spécifications techniques du terminal, il cherchera parmi
les autres répertoires ayant la solution la plus proche. Les principaux quantificateurs avec leurs
priorités sont les suivants :
• Langue et région (priorité 2) : Ce quantificateur représente la langue du système. Il faut
au debut indiquer une langue, ensuite, il y aura le choix d’ajouter une région en utilisant le
symbole « -r », voici quelques exemples :
- En pour l’anglais ;
- Fr pour le français ;
- Fr-rFR pour le français mais uniquement celui utilisé en France ;
- Fr-rCA pour le français mais uniquement celui utilisé au Québec ;
- ect
• Taille de l’écran (priorité 3) : Il s’agit de la taille de la diagonale de l’écran :
- Small pour les écrans de petite taille ;
- Normal pour les écrans standards ;
- Large pour les grands écrans (par exemple les tablettes tactiles) ;
- Xlarge pour les très grands écrans (par exemple téléviseurs).
• Orientation de l’écran (priorité 5) : Il existe deux valeurs :
Figure 4.2 – Emplacement des ressources
Figure 4.3 – Syntaxe d’un quantificateur

- port : c’est le diminutif de portrait, quand le terminal est en mode portrait ;

- land : c’est le diminutif de landscape, quand le terminal est en mode paysage
• Résolution de l’écran (priorité 8)
- ldpi : environ 120 dpi ;
- mdpi : environ 160 dpi ;
- hdpi : environ 240 dpi ;
- xhdpi : environ 320 dpi (disponible à partir de l’API 8 uniquement) ;
- nodpi : pour ne pas redimensionner les images matricielles (vous savez, JPEG, PNG et
GIF !).
• Version Android (priorité 14) : Il s’agit du niveau de l’API (v3, v5, v7, v13, etc.)
Exemple 4.2.5.1 Si un utilisateur a un terminal avec une grande résolution, Android cherchera
dans le répertoire res/drawable-hdpi !. Si il a un terminal avec une résolution moyenne, le système
cherchera dans le répertoire res/drawable-mdpi/. Si il a un terminal avec une petite résolution,
Android cherchera dans le répertoire res/drawable-ldpi puisqu’il s’agit de la solution la plus
proche de la situation matérielle réelle.
Exemples et règles à suivre pour les quantificateurs
• res/drawable-small : pour avoir des images spécifiquement pour les petits écrans.
• res/drawable-large : pour avoir des images spécifiquement pour les grands écrans.
• res/layout-fr : pour avoir une mise en page spécifique destinée à tous ceux qui ont un
système en français.
• res/layout-fr-rFR : pour avoir une mise en page spécifique destinée à ceux qui ont choisi
la langue Français (France).
• res/values-fr-rFR-port : pour des données qui s’afficheront uniquement à ceux qui ont
choisi la langue Français (France) et dont le téléphone se trouve en orientation portrait.
• res/values-port-fr-rFR : n’est pas possible, c’est à ça que servent les priorités : il faut
impérativement mettre les quantificateurs par ordre croissant de priorité (La priorité de la
langue est 2, celle de l’orientation est 5).
• res/layout-fr-rFR-en : n’est pas possible puisqu’on a deux quantificateurs de même prio-
rité et qu’il faut toujours respecter l’ordre croissant des priorités. Il nous faudra créer un
répertoire pour le français et un répertoire pour l’anglais.
Il faut noter que tous les répertoires de ressources qui sont différenciés par des quantificateurs
devront avoir le même contenu.
4.2.6 Récupérer une ressource

Puisque les ressources sont indépendants du traitement ( code java), la question qui se pose à
ce niveau : Comment arriver à accéder à ces ressources à partir du code Java ?
La réponse est tout simplement grâce à la classe R qui se trouve dans le fichier R.java. Cette
classe est définit comme :
• Classe en lecture seule : il s’agit de générer automatiquement le code java (le code est définit
automatiquement par Android).
• Classe statique : il s’agit de déclarer des constantes dont les valeurs représentent des iden-
tifiants des ressources [2].
Figure 4.4 – Structure de la classe R (exemple)
Comme la figure 4.4 montre, la classe R se compose d’un ensemble des classes internes qui
représentent les ressources crées dans le répertoire res.
Le type de ces classes est public static final.

• Un élément public est un élément auquel tout le monde peut accéder sans aucune restriction.
• Le mot-clé static, dans le cas d’une classe interne, signifie que la classe n’est pas liée à une
instanciation de la classe qui l’encapsule. ( par exemple, pour accéder à la classe String, on
n’est pas obligé de créer un objet de type R. On peut y accéder par R.String).
• Le mot-clé final signifie que l’on ne peut pas créer de classe dérivée d’une classe interne.
4.3 Interface graphique

Dans la partie précédente, on a illustré le principe et l’utilité des ressources, et on a clarifié que
l’interface graphique fait une partie des ressources.
Grâce au langage XML qu’une application mobile peut s’adapter facilement au volume de
chaque écran. À titre exemple, si une application est destinée à être utilisée dans les terminaux
ayant des petits écrans, les utilisateurs de tablettes ne pourront pas l’utiliser à cause de l’illisibilité
de l’application. Dans la deuxième partie de ce chapitre, on va mettre l’accent sur les composants
fondamentaux (les vues et les layouts) d’une interface graphique, la façon avec laquelle on peut
créer, récupérer et manipuler ces composants à partir du code Java.
L’utilisation du langage XML dans la partie interface doit être séparée par rapport au code
Java ( partie traitement). Toutes les opérations concernant la création d’interface graphique en
utilisant XML pourront être faite à travers l’utilisation du code Java, cependant le code sera plus
complexe à maintenir. Il existe essentiellement deux types d’éléments qui construisent une interface
graphique (la figure 4.5) :
• Layout(View groupe) : des éléments qui mettent en forme un contenu
Figure 4.5 – Hiérarchie des éléments d’une interface graphique
Figure 4.6 – Les principaux Layout
• Vue (view) : des éléments qui fournissent un contenu
4.3.1 Layout
Un layout (gabarit) est une vue particulière qui n’a pas l’objectif d’offrir un contenu, mais qui
peut contenir d’autres vues. Il s’intéresse pour l’organisation des vues (un bouton, un texte, une
image, etc...) et permet aussi de les positionner d’une manière cohérente.
Les vues contenues sont les enfants, la vue englobante est le parent. Une vue qui ne peut pas
en englober d’autres est appelée un widget (composant).
Il existe plusieurs types de layout, dans ce cours ,on va présenter les principaux layout qui sont
les plus utilisés dans la construction d’une interface graphique sous Android (la figure 4.6).
Figure 4.7 – fichier XML d’un LinearLayout avec sa représentation graphique
LinearLayout
Ce type de Layout permet de mettre les vues les unes après les autres ( sur une même ligne) selon
une certaine orientation ( verticalement ou horizontalement). L’attribut qui permet de préciser la
façon dont les éléments contenus ( les vues) seront alignés est appelé android :orientation. Deux
options sont disponibles :
• Vertical : permet d’orienter les vues sur une ligne verticale.
• Horizontal : permet d’orienter les vues sur une ligne horizontale.
Il existe aussi deux autres attributs qui fournissent une taille de largeur et hauteur pour les
vues contenues dans ce type de layout, les attributs sont :
• android :layout_width : fournit une taille de largeur
• android :layout_height : fournit une taille de hauteur
Ces deux attributs peuvent prendre trois types de valeurs :
• wrap_content : la taille de layout dépend directement de la taille des composants qu’il
contient. Pour demander au Widget d’occuper une taille naturelle (la taille de son contenu
pour le texte par exemple). S’il est trop gros par rapport à la taille disponible. Android
s’occupera par exemple de couper le texte s’il n’y a plus de place.
• fill_parent : dans ce cas on demande au composant d’occuper tout l’espace disponible chez
son layout (après le placement des autres widgets).
• Une taille fixe : par exemple 50 px (pixels). Donc quel que soit la taille de l’écran, l’élément
occupera exactement 50 px [5].
RelativeLayout
Il permet d’organiser les vues les unes par rapport aux autres. Elles peuvent également être
placées par rapport au RelativeLayout parent. Par exemple, on peut centrer une vue dans le
RelativeLayout à l’aide des attributs suivants :
• android :layout_centerInParent="true" : permet de placer une vue au centre d’un Relati-
veLayout
Figure 4.8 – fichier XML d’un RelativeLayout avec sa représentation graphique
Figure 4.9 – Représentation graphique d’un TableLayout
• android :layout_centerHorizontal="true" : permet de centrer une vue, mais uniquement sur

l’axe horizontal.
• android :layout_centerVertical="true" : permet de centrer une vue, mais uniquement sur
l’axe vertical.
TableLayout
Le TableLayout défini un tableau (sans bordures), dans lequel on peut rajouter des lignes (Ta-
bleRow) qui contiendront les composants (vues). La figure 4.9 représente un exemple d’utilisation
de ce type de Layout
FrameLayout
Il permet d’afficher une seule vue. Il n’est destiné à afficher qu’un élément, mais il est possible
d’en mettre plusieurs dedans puisqu’il s’agit d’un ViewGroup.
Exemple 4.3.1.1 Quand on veut faire un album photo, il suffit de mettre plusieurs éléments dans
le FrameLayout et de ne laisser qu’une seule photo visible, en laissant les autres invisibles grâce à
l’attribut android :visibility
Figure 4.10 – Les principales vues
Remarque 4.3.1.1 Tous ces type de Layout seront pris d’une façon détaillée dans la séance de
TP.
4.3.2 Les vues ( Widget)

Un widget est un élément basique qui permet à un utilisateur la possibilité d’interagir directe-
ment avec une application. Chaque widget se caractérise par un ensemble d’attributs XML et de
méthodes Java.
Il existe plusieurs types de widgets, dans ce cours , on va présenter les principales vues qui sont
les plus utilisées dans la construction d’une interface graphique sous Android (la figure 4.10).
Textview
Il permet d’afficher une chaîne de caractères que l’utilisateur ne peut modifier. La figure 4.11
présente un exemple d’un fichier XML qui décrit une vue de type Textview. Le fichier contient
la syntaxe @stringtextView qui implique l’utilisation d’une ressource de type string. L’attribut
android :textSize permet de préciser la taille des caractères, et l’attribut android :textColor permet
également de préciser la couleur du texte. Cette notation avec un ] permet de décrire des couleurs
à l’aide de nombres hexadécimaux.
EditText
L’utilisation de ce type de widget permet aux utilisateurs d’interagir avec des textes ( ce sont
des TextView éditables). Un EditText hérite de TextView ce qui implique d’avoir les mêmes attri-
buts en XML et ils peuvent utiliser les mêmes méthodes Java.
Figure 4.11 – Exemple d’un Textview en XML
Figure 4.12 – Exemple d’un EditText en XML
D’après la figure 4.12, on constate que l’utilisation de l’attribut android :hint est faite au lieu
de l’attribut android :text qui est utilisé dans la figure 4.11. La différence essentielle entre ces deux
attributs c’est qu’avec android :text le remplissage de EditText est fait par le text demandé, alors
qu’avec android :hint le remplissage doit être accompagné par un autre attribut android :inputType
qui permet de préciser le type de texte à remplir dans l’EditText et permet aussi d’adapter le clavier
selon ce type de text.
Exemple 4.3.2.1 Si on précise dans le fichier XML que l’attribut EditText va servir à écrire une
adresse e-mail en utilisant l’attribut android :inputType , alors l’arobase sera proposé tout de suite
à l’utilisateur sur le clavier.
Button
Un simple bouton, même s’il s’agit en fait d’un TextView cliquable (la figure 4.13).
CheckBox
Une case qui peut être dans deux états : cochée ou pas. Dans la figure 4.14, l’attribut an-
droid :checked="true" signifie que la case est cochée par défaut.
RadioButton RadioGroup
Les RadioButton ont la même base que la CheckBox, à la différence que l’utilisateur n’a la
possibilité de cocher qu’une seule case à la fois. Il est toujours conseillé de les regrouper dans un
Figure 4.13 – fichier XML d’un Button avec sa représentation graphique
Figure 4.14 – XML d’un CheckBox avec sa représentation graphique
RadioGroup.
Un RadioGroup est pratiquement un layout, mais il n’est utilisé qu’avec des RadioButton. Son
objectif est de faire en sorte qu’il puisse n’y avoir qu’un seul RadioButton sélectionné dans tout le
groupe.
4.3.3 La gestion des événements sur les Widgets

Les différentes interactions ( entrer un texte, cliquer sur un bouton, etc) qui permettent à
un utilisateur de réagir directement avec une interface graphique s’appelle des évènements. Pour
qu’un utilisateur puisse faire cela, il est obligé d’utiliser un objet de type listener qui permettra de
détecter et de traiter l’évènement. Un listener est une interface qui oblige un utilisateur à redéfinir
des méthodes de callback et chaque méthode sera appelée au moment où se produira l’évènement
associé.
Pour pouvoir associer un listener à une vue, il est recommandé d’utiliser une des méthodes
suivantes :
• Héritage : à travers une implémentation de l’interface au niveau de la classe, auquel cas il
faudra réécrire les méthodes de callback directement dans la classe.
• Classe anonyme : en donnant directement une implémentation unique à la vue.
• Attribut : cette méthode est utilisée dans le cas, où un utilisateur veut réutiliser un listener
sur plusieurs vues.
Figure 4.15 – Fichier XML d’un RagioGroup qui englobe des Radiogroup
4.3.4 Identification et récupération des vues

Comme on a vu précédemment dans la partie « Ressource » où chaque ressource a un identifiant,
il est possible d’accéder à une ressource à partir de son identifiant à l’aide de la syntaxe @X/Y :
• @ : signifie qu’on va parler d’un identifiant
• X : est la classe où se situe l’identifiant dans R.java
• Y : est le nom de l’identifiant
Dans la figure 4.16, et plus particulièrement, dans la douzième ligne, l’instruction signifie que
le TextView va afficher le texte de la ressource qui se trouve dans la classe String de R.java et qui
s’appelle hello_world.
4.4 Conclusion
La première partie de ce chapitre vise à illustrer le concept de ressource, la raison pour laquelle
ce concept a été réalisé, ses différents types ainsi que la notion de quantificateur qui est le respon-
sable pour l’organisation des ressources. Enfin, on a expliqué l’utilité de la classe R qui représente
le moyen permettant de récupérer une ressource à partir du code Java.
La deuxième partie de ce chapitre porte sur les éléments de base qui construisent une interface
graphique (les vues et les layouts), la façon avec laquelle on peut créer, récupérer et manipuler ces
éléments à partir du code Java.
Dans le chapitre suivent, le concept d’une base des données sous Android va être abordé, la
notion du moteur SQlite ainsi que la projection de cette notion sur l’univers Android.
Figure 4.16 – Fichier XML d’un TextView contenant un identifiant

Chapitre 5
Les bases des données sous

Android
5.1 Introduction
De nombreuses applications mobiles manipulent des données complexes et il est souvent né-
cessaire de trouver un moyen efficace de stocker ces données et d’y accéder. Par exemple une
bibliothèque qui contient plus de 100 000 ouvrages et on doit chercher en moins d’une seconde un
ouvrage bien précis. C’est pour cela qu’il est indispensable d’avoir une base des données qui est
optimisée pour ce type de traitements.
Les bases de données pour Android sont réalisées à l’aide d’un SGBD très efficace pour les
applications embarquées dénommé SQLite ( Il est aussi utilisé dans d’autres applications telles que
Skype, Adobe Reader, Firefox, etc).
5.2 Notions de base

Une base de données (database) est un conteneur dans laquelle il est possible de stocker et de
retrouver l’intégralité de données brutes ou d’informations. Dans la très grande majorité des cas,
ces informations sont très structurées, et elles sont localisées dans un même lieu et sur un même
support. Les informations dans une base des données doivent être :
• Cohérentes.
• Non redondante ou de redondance minimale.
• Indépendante par rapport au traitement.
L’unité de base de cette structure s’appelle la table. Une table regroupe des ensembles d’infor-
mations qui sont composés de manière similaire. Une entrée (ligne) dans une table s’appelle un
enregistrement, ou un tuple. Chaque entrée est caractérisée par plusieurs renseignements distincts,
appelés des champs ou attributs.
Exemple 5.2.0.1 Une table peut contenir le prénom, le nom et le métier de plusieurs utilisateurs,
on aura donc pour chaque utilisateur les mêmes informations. Il est possible de représenter une
51
CHAPITRE 5. LES BASES DES DONNÉES SOUS ANDROID 52
Figure 5.1 – Exemple d’une table
table par un tableau, où les champs seront symbolisés par les colonnes du tableau et pour lequel
chaque ligne représentera une entrée différente (la figure 5.1).
Une base de données relationnelle est une base de données où l’information est organisée dans
des tableaux à deux dimensions.
Pour pouvoir manipuler les données, il est nécessaire d’avoir un système appelé SGBD ( Sys-
tème de Gestion de Base des Données) : un logiciel moteur qui permet de manipuler la base des
données et de diriger l’accès à son contenu en utilisant des règles bien précises .
Pour utiliser un SGBD et pour avoir la possibilité d’interroger une base des données, il est
indispensable d’utiliser un langage SQL (Structured Query Language). Ce langage permet de faire
des opérations telles que La recherche, l’ajout, la modification et la suppression des données dans
les bases de données.
5.3 SQLite
5.3.1 Introduction
A la base, SQLite est un moteur de base de données relationnelle, sa particularité par rapport à
d’autres moteurs est qu’il est indépendant d’un système de gestion de base de données. Cela dit une
base de données SQLite peut être intégrée facilement dans le code d’un programme, d’où l’usage
récurrent de cette base dans le contexte des applications mobiles sous Android , iOS ou Windows
Phone. Intégrer cette base dans les applications peut donc se faire dans un fichier appartenant au
programme et indépendant de la plateforme en question. SQLite est open source et écrit en C.
5.3.2 Architecture de SQLite

SQLite est composé de plusieurs modules dont chacun représente une fonctionnalité spécifique.
Ces modules possèdent plusieurs couches en elles mêmes (la figure 5.2).
L’élément le plus essentiel dans cette architecture est le compilateur SQL . C’est là ou ré-
side toute la magie de SQLite. Le séquenceur Tokenizer récupère les commandes à traiter et les
organisent en des ensembles de requêtes traitables. Le parseur analyse quant à lui s’occupe de
parser les requêtes en différents objets du langage SQL. Le générateur de code ensuite va créer
le code bas niveau correspondant qu’on appelle le bytecode. L’objectif fondamental de SQLite est
Figure 5.2 – Architecture de SQLite
de surtout créer une base de donnée indépendante qui est facile à utiliser et qui peut en même
temps fonctionner sur n’importe quelle plateforme ou environnement. Pour cette raison, SQLite
dépasse en fait les autres bases de données mais seulement lorsqu’il s’agit de petites ou moyennes
applications. Et cela se manifeste surtout en termes de vitesse d’exécution. En termes de langages,
SQLite s’incorpore avec n’importe quel langage pratiquement. Même si ce dernier est écrit en C, il
en existe plusieurs extensions permettant de l’utiliser avec d’autres langages. Ces extensions vont
du coup fournir des curseurs ou des objets de connections spécifiques au langage en question. Ce
qui facilite encore plus l’usage de SQLite [9].
5.4 SQLite en Android

5.4.1 Le package android.database.sqlite
L’avantage avec la plateforme Android est que SQLite y est déjà implémenté. On retrouve dans
la SDK d’Android tout un package qui regroupe l’implémentation de SQLite. Ce package s’appelle
android.database.sqlite (la figure 5.3).
On retrouve dans ce package en premier lieu la classe SQLiteOpenHelper qui est l’élément de
base pour créer une instance de base de donnée. Ensuite , on retrouve toutes les objets permettant
la manipulation et la gestion des requêtes vis à vis de la base en question. Parmi ces objets, on
cite le SQLiteDatabase avec les méthodes de manipulation (insert(), delete() ...), le Cursor qui
récupère le résultat d’une requête a un objet SQLiteDatabase et aussi surtout le SQLiteQuery qui
représente la requête en question [9].
Figure 5.3 – Le package android.database.sqlite
5.4.2 La classe SQLiteOpenHelper

La classe SQLiteOpenHelper est une classe Helper permettant la création et la gestion d’une
base de données SQLite, l’idée est de créer une classe qui hérite de SQLiteOpenHelper tout en
surchargeant les méthodes qui définissent à peu prés le cycle de vie de l’instance en question. Ces
méthodes sont [5] :
• onCreate() lors de la création de l’instance la première fois.
• onUpgrade() qui est appelée quand la base migre d’une version ancienne à une nouvelle
version.
• onOpen() qui est appelée à chaque ouverture de l’instance.
5.5 Les curseurs

Les curseurs sont des variables (zone mémoire) utilisées pour récupérer le résultat de requêtes
de type SELECT.
Les curseurs sont des objets qui contiennent les résultats d’une recherche dans une base de
données. Ce sont en fait des objets qui fonctionnent comme les tableaux .Ils contiennent les colonnes
et les lignes qui ont été renvoyées par la requête. Un objet de type Curseur possède un pointeur
sur l’enregistrement courant. À la réception de cet objet, le pointeur se trouve devant le premier
enregistrement.
5.5.1 Les lignes

Pour parcourir les résultats d’une requête, il faut procéder ligne par ligne. Pour naviguer parmi
les lignes, on peut utiliser les méthodes suivantes :
• boolean moveToFirst() : pour aller à la première ligne.
• boolean moveToLast() : pour aller à la dernière ligne.
• boolean moveToPosition(int position) : pour aller à la position voulue (on peut savoir le
nombre de lignes avec la méthode int getCount().
Un Cursor est capable de retenir la position du dernier élément que l’utilisateur a consulté, il
est donc possible de naviguer d’avant en arrière parmi les lignes grâce aux méthodes suivantes :
• boolean moveToNext() : pour aller à la ligne suivante. Par défaut on commence à la ligne
-1, donc, en utilisant un moveToNext() sur un tout nouveau Cursor, on passe à la première
ligne.
• boolean moveToPrevious() pour aller à l’entrée précédente.
Les booléens utilisées avec ces méthodes valent true si l’opération s’est déroulée avec succès,
sinon false (auquel cas la ligne demandée n’existe pas).
5.5.2 Les colonnes

Pour récupérer le contenu d’une colonne, il suffit d’utiliser une méthode du style : X getX(int
columnIndex) avec :
• X : représente le type de la valeur à récupérer.
• columnIndex : représente la colonne dans laquelle se trouve cette valeur
5.6 Conclusion
Ce cinquième chapitre porte sur tous ce qui concerne la base des données sous Android. Dans
ce chapitre, on a commencé à présenter quelques notions de bases (généralités) sur les bases des
données, ensuite on a donné une explication générale du monteur SQlite ainsi que son architecture.
Après avoir expliqué le concept de SQlite, on s’est focalisé sur la projection de ce moteur par rap-
port au système Android, le principe de base du package android.database.sqlite qui est chargé du
regroupement de l’implémentation de SQlite, ainsi que la classe SQLiteOpenHelper qui représente
l’élément de base pour créer une instance de base de donnée.
Le prochain chapitre visera à résumer toutes les étapes et les recommandations nécessaires pour
un déploiement fiable d’une application Android.
<
Chapitre 6
Déploiement d’une application

mobile
6.1 Introduction
Une fois les différentes étapes de développement et de test sont réalisées, il est le moment de
présenter l’application aux différents utilisateurs qui vont télécharger et utiliser cette application.
La manière dont l’application est présentée au publique joue un rôle crucial dans l’augmentation
du nombre de téléchargement. C’est pour cette raison que cette étape représente une partie indis-
pensable, celle pour laquelle un développeur d’application mobile a tant travaillé.
Dans ce chapitre, on va mettre l’accent sur l’étape de préparation de l’application avant de

pouvoir la déployer, puis on présentera les supports essentiels qui permettent de distribuer une
application mobile et on terminera par expliquer les différentes étapes nécessaires pour un déploie-
ment d’une application Android sur Google Play.
6.2 Étape de préparation

Avant de faire le déploiement d’une application android, il faut savoir que ce type d’application
a une forme APK .
Un APK est un format de fichier qui permet de distribuer (déployer) et d’installer des appli-
cations Android. Pratiquement, un APK est une archive (comme les ZIP ou les RAR) qui porte
tous les fichiers essentiels pour l’exécution d’une application. Ces fichiers doivent s’organiser d’une
manière particulière.
Avant la distribution de l’application Android au publique, Il est toujours recommandé de faire

une certaine préparation ( vérification) pour assurer une fiabilité du produit. Les vérifications
importantes sont les suivantes [5] :
56
CHAPITRE 6. DÉPLOIEMENT D’UNE APPLICATION MOBILE 57
6.2.1 Réalisation des tests

Pour distribuer une application, il faut être sur que tout fonctionne correctement à travers des
testes sur une grande variété de périphériques. Pour réaliser cette étape, il vaut mieux utiliser
l’AVD (Android Virtual Device), puisqu’il permet de simuler de nombreux matériels différents. Le
plus important étant surtout de supporter le plus d’écrans possible.
6.2.2 Le nom de package

Il faut toujours prendre en considération le nom de package dans lequel l’application va être
publiée. Il représente l’identifiant pour l’application à chaque soumission, il faut qu’il soit unique
et qu’il ne soit pas changé entre deux soumissions. Si l’application est mise à jour, ce sera toujours
dans le même package.
6.2.3 Le nettoyage
Il se peut parfois qu’il existe des fichiers qui ne sont pas nécessaires pour la version finale, et qui
ne feront qu’alourdir l’application. Les répertoires les plus susceptibles d’avoir des fichiers inutiles
sont souvent les répertoires : res ou encore assets.
6.2.4 Le numéro de version

Le numéro de version est une information essentielle, autant pour le développeur que pour
l’utilisateur. Pour ce dernier, il permet de lui informer pour la mise à jour de l’application, et le
rassure quant à l’intérêt d’un achat qu’il a effectué si l’application est régulièrement mise à jour.
Pour le développeur, il lui permet de tracer les progrès de son application, de lui placer des jalons
et ainsi de mieux organiser le développement de son projet.
Comme, il est illustré dans les figures 6.1 et 6.2, il existe deux attributs : android :versionName
et android :versionCode. Le premier attribut permet de définir la version d’application en utilisant
une chaîne de caractères (par exemple « 1.0 alpha » ou « 2.8.1b »). Cet attribut sera celui qui
est visible pour l’utilisateur, à l’opposé de android :versionCode qui ne sera pas visible pour l’uti-
lisateur et qui ne peut contenir que des nombres entiers. Ainsi, si l’ancien android :versionCode
de l’application était « 1 », le nouveau code doit avoir un nombre supérieur à « 1 » pour que le
marché d’applications sache qu’il s’agit d’une version plus récente.
6.2.5 Le fichier manifest

Il est possible que ce fichier contient des informations inutiles et qui ont été, peut être, oubliées
d’être nettoyées. Il faut assurer que les permissions mentionnées dans ce fichier doivent être accep-
tables pour éviter n’importe quelle suspicions (justifiée) de la part des utilisateurs. Pour augmenter
le nombre d’utilisation de l’application à distribuer, il est recommandé d’indiquer une version co-
hérente de android :minSdkVersion de façon à cibler le plus d’utilisateurs possible et à éviter le
plus d’utilisateurs qui ne pourraient pas l’utiliser.
Figure 6.1 – fichier XML décrivant l’ancienne version
Figure 6.2 – fichier XML décrivant la nouvelle version

6.2.6 Les serveurs de test

Les serveurs de test doivent être bien vérifiés ( il faut changer les URL pour faire appel aux
serveurs de production). Il faut aussi assurer une sécurité fiable pour ces services ainsi qu’une
configuration qui doit être destinée pour l’entrée de production.
6.2.7 Icône de l’application

La performance d’une application dépend parfois de certains détails particuliers. Il faut savoir
que la première communication entre l’utilisateur et l’application est faîte à travers l’icône de cette
application. C’est pour cette raison qu’il est conseillé de réaliser une icône qui doit être attractive
sur le point de vue esthétique, résolution,...,etc.
6.3 Les moyens de déploiement

6.3.1 Google Play
Parmi les avantages d’utiliser google play est le nombre énorme des applications qu’il contient
de sorte qu’il existe plus qu’un milliard d’applications qui sont téléchargées dans chaque mois ( par
conséquent, il est visité par un très grand nombre d’utilisateurs). Ce moyen de distribution offre
un ensemble d’outils qui permettent d’analyser le comportement des consommateurs. Les étapes
qui permettent de déployer une application sur Google Play seront prises en détail dans la suite
de ce cours.
6.3.2 E-mail
Ce type de distribution est rarement utilisé par ce qu’il est très possible de pirater une ap-
plication déployée par un e-mail (l’utilisateur doit accepter les applications provenant de sources
inconnues). Il n’est pas recommandé d’utiliser la distribution par e-mail que pour des personnes
confiants. Il est aussi important de savoir que Google a fait le possible pour anticiper cette situation
en incluant un module qui détecte si un e-mail contient un APK en fichier joint.
6.3.3 Un site
C’est une solution qui permet de toucher un plus large public : il suffit de mettre l’APK de
l’application à disposer sur le site, gratuitement ou contre une certaine somme, et l’utilisateur
pourra l’installer. Cette méthode souffre des mêmes défauts que la distribution par e-mail, puisque
l’utilisateur devra accepter les applications provenant de sources inconnues et que le risque de
piratage est toujours aussi élevé.
6.3.4 Les autres marchés d’applications

Il existe d’autres moyens de déploiement qui permettent de mettre à disposition une application
Android, tels que AndroidPit, l’Appstore d’Amazon ou encore AppsLib qui est lui plutôt destiné
aux applications pour tablettes.
Figure 6.3 – La création d’un compte développeur
6.4 Les étapes de déploiement sur Google Play

6.4.1 Création d’un compte développeur
Pour pouvoir déposer une application sur Google Play, il faut d’abord avoir un compte Google
et par la suite créer un compte développeur avec lequel, on peut distribuer une application sur cette
plateforme.
Une fois le compte développeur est crée, une signature virtuelle de l’accord de distribution des
applications Android est obligatoire pour pouvoir par la suite payer les frais d’enregistrement (une
somme de 25 $) (la figure 6.3). Le nom du développeur sera affiché aux utilisateurs, comme il y a
la possibilité d’ajouter d’autres informations de contact telles que : email de contact, site web,...,etc.
En outre, si l’application à disposer est considérée comme une version payante, il est nécessaire
de configurer un profil de paiement qui va permettre d’administrer tous les opérations de paiements
mensuels ainsi qu’avoir la possibilité d’accéder aux différents rapports de ventes à partir de Play
Console [8].
6.4.2 Création de l’application

Dès que le compte développeur a été bien configuré, il est le moment de disposer l’application
mobile sur la plateforme Google Play.
Pour faire cela, il faut sélectionner "Toutes les applications" (all aplications) dans le menu, et
cliquer par la suite sur "Créer une application" (create application) (la figure 6.4). Il est aussi
indispensable de choisir une langue et mettre un titre de l’application qui va être affiché dans la
plateforme PlayStore (la figure 6.5).
Figure 6.4 – L’étape de création d’une application
Figure 6.5 – Le choix de la langue

Figure 6.6 – L’étape de description de l’application
6.4.3 Le remplissage des informations de l’application

Avant de disposer l’application, il est obligatoire de remplir une liste des informations qui se
trouvent dans l’onglet "Play Store". Cette liste contient les informations affichées à un utilisateur.
Il est aussi important de noter que selon ces informations, un utilisateur peut trouver l’application
à disposer lors d’un résultat de recherche.
Il est recommandé de remplir tous l’ensemble d’informations même si quelques champs ne sont
pas obligatoires. Plus, les informations sont riches, plus il sera facile que l’application soit affichée
lors d’un résultat de recherche.
Détails du produit
Il joue un rôle très intéressant dans le point de vue commerciale. Il faut mettre d’abord un
titre de l’application qui ne doit pas dépasser 50 caractères, une description abrégée qui doit se li-
miter à 80 caractères et une description détaillée qui ne dépasse pas 4 000 caractères (la figure 6.6).
Pour que l’application soit attirante et par conséquent elle aura plus de visiteurs, il est recom-
mandé de faire une étude qui permet de choisir un mot-clé qui doit générer plus de trafic dans
le titre de l’application. Il est déconseillé de mettre des mots-clés qui n’ont aucune relation avec
l’application, sinon l’application sera suspendue complètement sur Google Play [8].
L’utilisation des vidéos et des captures
Il faut faire attention aux différentes captures d’écran et aux vidéos utilisées dans la description
détaillée de l’application. Il est possible d’utiliser jusqu’à 8 captures d’écran, une pour chaque type
d’appareil compatible (la figure 6.7). Il faut prendre en considération que ces captures doivent
présenter les caractéristiques essentielles de l’application et être attrayants afin d’attirer l’attention
de l’utilisateur.
Figure 6.7 – L’étape d’ajouter des captures pour l’application
Figure 6.8 – L’étape de catégoriser l’application
Langues
l’Anglais est la langue utilisée par défaut, mais il est possible de la personnaliser et même de
l’annexer avec des traductions pour l’application. Il est préférable d’ajouter une traduction pour
assurer une bonne expérience surtout dans le cas où l’application sera utilisable dans différents
pays.
Catégorie
Dans cette phase, il faut choisir le type d’application à disposer et la catégorie selon laquelle elle
s’est classifiée ( météo, jeux, outils,..,etc) (la figure 6.8), comme Il est possible aussi de sélectionner
une catégorie supplémentaire ( information facultative).
Coordonnées de contact
Pour avoir la possibilité de contacter avec les utilisateurs, il est indispensable de mettre au
moins une adresse électronique. Il est recommandé d’ajouter d’autres moyens de contacts pour que
les utilisateurs puissent avoir plus de l’aide par rapport à l’utilisation de l’application (la figure
Figure 6.9 – L’étape d’ajouter les moyens de contact
Figure 6.10 – L’étape de définir une politique de confidentialité
6.9).
Politique de confidentialité
À ce niveau, il faut assurer une URL avec une politique de confidentialité bien déterminée afin
que les utilisateurs aient une connaissance concernant l’utilisation de leurs données sensibles et
celles de leur appareil (la figure 6.10). De plus, le lien vers la politique de confidentialité doit être
placé à la fois sur la liste de PlayStore et dans l’application dans le cas où l’application exige un
accès à des contenus sensibles.
6.4.4 Téléchargement de l’APK de l’application

Une fois les informations sont remplis correctement, il est temps de télécharger la version APK
de l’application.
Il est possible de publier plusieurs types de tests à choisir tels que (la figure 6.11) :
• Un test interne.
• Un test fermé seulement pour un nombre restreint de testeurs.
• Un test ouvert dans le cas de choisir une version de production qui sera disponible pour
tous les utilisateurs de l’application.
6.4.5 Questionnaire de l’évaluation

Les applications Google Play doivent apporter aux utilisateurs des informations par rapport
à leur âge. Une fois le format APK est téléchargé, il sera essentiel de remplir le questionnaire
d’évaluation, sinon la demande de déploiement de l’application pourra être rejetée et retirée du
magasin (la figure 6.12).
6.4.6 Le prix et la distribution de l’application

Avant de déterminer le prix de l’application, il faut d’abord décider si l’application est gratuite
ou payante. Il est important de savoir qu’il y a une possibilité de convertir une application payante
Figure 6.11 – L’étape de téléchargement de l’APK
Figure 6.12 – Le questionnaire à remplir

Figure 6.13 – La distribution de l’application
en application gratuite et impossible de faire l’inverse. À ce niveau, on peut choisir les pays dans
lesquels l’application sera disponible (la figure 6.13).
6.4.7 Période d’attente

Une fois, les étapes mentionnées au dessus sont réalisées, il suffit d’attendre pendant que la
version de distribution sera disponible dans le point de vente. Si la demande de déploiement est
faite pour la première fois, la procédure de validation peut durer quelques jours, sinon (dans le cas
où plusieurs applications sont déjà téléchargées) le processus peut se réduire à quelques heures [8].
6.5 Conclusion
Dans ce chapitre, on s’est focalisé sur une phase qui est importante pour un développeur
d’application mobile. Le fait d’avoir une bonne application ne signifie pas forcement qu’elle sera
téléchargées et utilisées par un très grand nombre d’utilisateurs. En plus, le défis n’est pas seule-
ment que l’application soit téléchargée par le plus grand nombre d’utilisateurs possible, mais aussi
qu’ils continuent à l’utiliser au fil du temps.
C’est pour ces raisons qu’on s’est intéressé par cette étape dans le cycle de vie du développement
d’une application Android. Au début, on a montré quelques vérifications qui sont obligatoires avant
la distribution de l’application dans le but d’assurer une fiabilité du produit. Ensuite on a passé
à présenter quelques supports de déploiement qui représentent les moyens les plus utilisés pour
distribuer une application Android. Enfin on a conclu par une description de différentes phases
nécessaires pour la distribution d’une application Android sur Google Play.
Chapitre 7
Développement d’une application

mobile (cas pratique)
7.1 Objectif
L’objectif de cette partie est de guider l’étudiant à maîtriser les processus essentiels permettant
de créer une simple application mobile. L’application à créer, est un simple jeu qui permet de :
• Générer un nombre secret aléatoire entre 1 et 100.
• L’utilisateur doit deviner le nombre secret en plusieurs tentatives.
• Pour chaque tentative, le jeu répond par l’une des indications suivantes :
- Votre nombre est plus petit
- Votre nombre est plus grand
- BRAVO
• Le numéro de la tentative est affiché et aussi indiqué par une ProgressBar
• Pour chaque partie gagnée, le score incrémente de 5 points
• L’historique des essais est affiché dans ListView
7.2 Préparation du projet android

Après avoir installé tous les éléments nécessaires pour le développement d’une application an-
droïde ( voir le deuxième chapitre) et après la création du projet de l’application, l’étudiant est
invité à choisir le type de l’activité pour l’application (la figure 7.1). Dans ce cas, on choisit une
activité vide (empty).
La deuxième étape porte sur la configuration du projet. Durant cette étape, l’étudiant doit
spécifier un ensemble d’informations (la figure 7.2) :
• Name : le nom de l’application
• Package name : identifier l’organisation dans laquelle vous travaillez
• Save location : le chemin de l’application.
• Langague : Le langage de programmation choisi pour le développement de l’application.
Une fois la configuration du projet est faite avec succès, il apparaitra une figure similaire à la
67
CHAPITRE 7. DÉVELOPPEMENT D’UNE APPLICATION MOBILE (CAS PRATIQUE) 68
Figure 7.1 – Le choix de l’activité
Figure 7.2 – La configuration du projet

Figure 7.3 – L’activité principale de l’application
figure 7.3 qui est considérée comme la première page qui va être affichée indiquant le premier code
source généré de l’activité choisi lors de la première étape.
Il faut noter que pour pouvoir exécuter une application android, il faut utiliser un émulateur.
Pour faire ça, en suivant le chemin (Tools/AVD Manager), il apparaitra une fenêtre similaire à
celle présentée dans la figure 7.4. Vous devez cliquer sur le bouton Create Virtual Device (Créer un
périphérique virtuel) pour avoir la possibilité de choisir le type de terminal mobile sur lequel vous
devez exécuter l’application. Dans la partie gauche de la figure 7.5, il y a un ensemble de catégories
des terminaux mobiles à choisir avec leurs caractéristiques et la partie droite le nombre de pixel
approprié pour le terminal choisi.
Après avoir choisi le type de terminal, il apparaitra une fenêtre indiquée dans la figure 7.6 et qui
présente le démarrage d’un émulateur qui va nous permettre par la suite d’exécuter l’application
comme si elle est exécutée dans un terminal physique.
7.3 Préparation de l’interface graphique

Dans cette étape, l’étudiant doit former l’interface de l’application en choisissant les éléments
qui ont été présentés dans le chapitre 04 ( layout et vues). Pour y faire, il faut tout d’abord cliquer
sur le répertoire layout puis sur l’onglet Design et on obtiendra la première interface générée de
l’application ( la figure 7.7 ). En cliquant sur l’onglet text on aura la version XML de cette interface
(la figure 7.8 ).
Pour pouvoir réaliser l’interface finale de l’application, qui doit être similaire à celle indiquée
dans la figure 7.9, il faut suivre les étapes suivantes :
Comme on a vu dans la deuxième partie du chapitre 04, pour avoir la possibilité d’ajouter les
différents composants de l’interface d’une application mobile, il faut d’abord insérer un Layout, qui
est considéré comme un conteneur qui se charge de faire l’organisation de différents composants
(vues). Suivant, les différents types de Layout ainsi que leurs caractéristiques et leurs particula-
Figure 7.4 – Liste des périphériques installés
Figure 7.5 – Le choix du terminal mobile

Figure 7.6 – L’exécution d’émulateur virtuel
Figure 7.7 – La première interface de l’application

Figure 7.8 – La version XML de première interface de l’application
Figure 7.9 – L’interface finale de l’application
rités, expliqués dans le chapitre 04, dans cet exemple on va utiliser le conteneur RelativeLayout
qui va nous donner la possibilité de faciliter l’organisation des vues, les unes par rapport aux autres.
Généralement le layout généré par default est ConstraintLayout ( voir la partie gauche de la
figure 7.7). Pour changer le type de conteneur, il suffit de cliquer à droite sur l’interface de l’ap-
plication et de faire convertir le conteneur généré vers le conteneur RelativeLayout (la figure 7.10 ).
Une fois le conteneur RelativeLayout est ajouté, il est le moment d’insérer les différents com-
posants (vues) formant l’interface de notre application. On commence par les étiquettes : Deviner,
score et la zone où la valeur de score va être affichée. Ces trois étiquettes sont considérées comme
des vues de type TextView qu’on peut les insérer par un simple glissement via la palette qui se
trouve dans la partie gauche de la figure 7.11. Il faut noter que la partie droite de la même figure
(attributes) présente les différentes caractéristiques des composants telles que : l’identificateur du
composant, la zone d’édition, la couleur, la taille....etc.
Après avoir ajouté les TextView, on doit insérer une vue de type EditText qui représente le
Figure 7.10 – Convertissement de Layout
Figure 7.11 – Insertion des vues -1-

Figure 7.12 – Insertion des vues -2-
composant sur lequel l’utilisateur devine le nombre secret. Pour y faire, il faut glisser le composant
Number qui se trouve dans l’onglet Text dans la palette . En suite et avec la même façon, on ajoute
un composant de type Button qui se trouve dans l’onglet Common dans le quel l’utilisateur valide
le nombre qu’il vient de deviner ( la figure 7.12 ).
En suivant les mêmes étapes pour finaliser l’interface finale de l’application. La figure 7.13
présente les emplacements des vues : ProgressBar et ListView.
7.4 Réalisation de code Java

Après avoir complété l’interface de l’application, l’étudiant est invité à réaliser le code source
java approprié. Il faut noter que l’ensemble de code de l’application est dans la classe MainActi-
vity.java.
Au début il faut créer une fonction qu’on l’appelle initialisation (figure 7.14) qui permet de :
• Générer un nombre aléatoire entre 1 et 100 qui sera stocké dans la variable secret et qui
sera incrémenté à chaque appel de la fonction ( première instruction).
• Accéder au nombre de tentatives en fonction de la variable compteur nommée conter (troi-
sième instruction).
• Faire avancer le ProgresBar à chaque tentative via l’incrémentation de la variable conter
(quatrième instruction).
Une fois la fonction initialisation est crée, on passe directement à la phase qui permet de tester
le nombre deviné par l’utilisateur. Les instructions qui font ce test sont présentées dans la figure
Figure 7.13 – L’emplacement des vues ProgressBar et ListView
Figure 7.14 – La fonction initialisation

Figure 7.15 – Les instructions du test de jeu
7.15.
Premièrement, on doit récupérer le nombre saisie par l’utilisateur qui est stocké dans la variable
number. En suite on fait le test par rapport au nombre secret qui a été crée dans la fonction
initialisation et selon le résultat du test, on affiche le message approprié qui est soit :
• Le nombre est inférieur par rapport au nombre secret
• Le nombre est supérieur par rapport au nombre secret
• Le nombre est égale au nombre secret, qui signifie que l’utilisateur a gagné le jeu. Dans ce
cas le score doit s’incrémenter de 5 et stocké dans la variable score.
Le score doit être affiché dans un textView et aussi dans le ProgressBar.
Une fois l’interface de l’application est faite avec succès et après avoir complété le code source
de l’application, l’étudiant sera prêt à exécuter l’application à travers l’émulateur et il devra avoir
une fenêtre équivalente à celle de la figure 7.16.
Figure 7.16 – L’exécution de l’application

Bibliographie
[1] Hébuterne, S. (2018). Android Guide de développement d’applications Java pour Smartphones
et Tablettes. 4ème édition.
[2] Nazim, B. (2017). Android 7, Les fondamentaux du développement d’applications Java. Édi-
tions ENI.
[3] Hébuterne, S. (2017). Développez une application Android programmation en Java sous An-
droid Studio. 2ème édition.
[4] Michel, M. (2013). Créez des applications iPhone, iPad et iPod Touch. Édition OpenClass-
Rooms.
[5] Frédéric, F. (2013). Créez des applications pour Android. Édition OpenClassRooms.
[6] Patrice, K. (2010). Les systèmes embarqués complexes. Note de cours. École Nationale Supé-
rieure d’électronique, Informatique, Télécommunications, Mathématique et Mécanique. Bor-
deaux.
[7] Pierre, F. (2005). Linux embarqué 2ème édition. Éditions EYROLLES
[8] https ://fr.yeeply.com/blog/publier-application-google-play-store/. Consulté le 15/10/2020.
[9] http ://tutorielandroid.francoiscolin.fr/bdd.php. Consulté le 05/04/2020.
[10] https ://www.statista.com/statistics/271644/worldwide-free-and-paid-mobile-app-store-
downloads/. Consulté le 18/03/2020.
78
ANNEXE
Annexe
Exemple d’examen corrigé

Q1. Quelles sont les types d'applications mobiles les moins rapides ?
- Natives
- Web (*)
- Hybrides
Q2. Quelles sont les types d'applications mobiles les plus couteuses ?
- Natives (*)
- Web
- Hybrides
Q3. Quelle est la couche la plus haute dans l'architecture des systèmes Android ?
- Librairies
- Application Framework
- Autres (*)
Q4. Quelle est la couche responsable pour la mise à jour des versions Android ?
- Librairies
- Application (*)
- Autres
Q5. Une activité contient des informations sur :
- Etat historique de l'application

- Etat actuelle de l'application (*)
- Etat complète de l'application
Q6. Pourquoi on s’intéresse à créer une application mobile ?
Créer une application mobile est le moyen idéal d’être proche

des clients et de les connaître dans leur intimité et surtout se faire connaître et vendre.
Q7. Expliquez les répertoires principaux dans un projet Android studio
- Manifest : un répertoire qui contient le fichier AndroidManifest.xml qui estle premier fichier
qui va être lu dans le démarrage d’Android et qui est considéré comme une carte d’identité
d’une application mobile.
- Java : un répertoire qui contient l’ensemble du code source de l’application.
- Res : un répertoire qui contient toutes les ressources nécessaires de l’application ( layout,
valeurs,…etc.)
Q8. Expliquez la différence entre les termes suivants : JDK, SDK, JRE.
ANNEXE
- JRE : les composants nécessaires pour exécuter une application JAVA

- JDK : les composants nécessaires pour compiler une application JAVA
- SDK :les composants nécessaires pour développer une application mobile pour Android
Q9. Quelle est la différence entre une version Android et une version ROM Custom ?
La version ROM Custom est un système créé à partir du code source d'un système Android
existant à condition que les droits accordés par les auteurs le permettent.
Q10. Quelle est la différence essentielle entre une activité et un service ?
Contrairement à une activité, un service ne propose pas d’interface utilisateur, il s'exécute

uniquement en arrière-plan avec l'entrée de l'utilisateur.
View publication stats

Developpe Ment Des Applications Mobiles

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Developpe Ment Des Applications Mobiles

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Polycopié de Cours : Développement des applications mobiles

Book · June 2021

Privacy Preserving Data Publishing View project

WSN Security View project

The user has requested enhancement of the downloaded file.

Université Ahmed Draia Adrar

Développement des applications

Ce polycopié de cours, conforme au programme enseigné, s’adresse aux étudiants de 3ème

Le contenu de ce polycopié est adapté avec le programme du canevas du socle commun

Connaissances requises : algorithmique, connaissance sur le web, POO

Evaluation : Contrôle continu : 40% ; Examen : 60%.

Ce document de cours s’articule autour de sept chapitres :

2 Les systèmes d’exploitation mobile 13

2.5.2 Stucture d’un projet android studio . . . . . . . . . . . . . . . . . . . . . . 23

3 Les composants fondamentaux des applications mobiles 27

4 Construction de l’interface utilisateur 36

5 Les bases des données sous Android 51

6 Déploiement d’une application mobile 56

7 Développement d’une application mobile (cas pratique) 67

1.1 Un assistant personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Architecture générale d’un système embarqué . . . . . . . . . . . . . . . . . . . . . 14

3.1 Ensemble d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Syntaxe d’un fichier XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.12 Exemple d’un EditText en XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.1 Exemple d’une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1 fichier XML décrivant l’ancienne version . . . . . . . . . . . . . . . . . . . . . . . 58

7.1 Le choix de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

1.2 Terminaux mobiles

Figure 1.1 – Un assistant personnel

Figure 1.2 – Les téléphones intelligents (smartphones)

Figure 1.3 – Une tablette

1.2.2 Les téléphones intelligents

1.2.3 Les tablettes

1.2.4 Les montres intelligentes

Figure 1.4 – Les montres intelligentes (smartwatches)

1.3 Application mobile

1.3.2 Les types d’application mobile

Le développement de l’application native nécessite le recours à la mémoire du Smartphone sans

1.3.3 Comparaison entre les types d’application mobile

Figure 1.5 – Les types d’application mobile

1.3.4 Les domaines d’application d’une application mobile

1.3.5 Les statistiques sur le marché mondiale

Figure 1.6 – Le nombre de téléchargement d’application mobile

Figure 1.7 – Les applications mobiles les plus téléchargées 2010-2019

Dans le prochain chapitre, on va s’intéresser à présenter le support logiciel qui va se charger de

Les systèmes d’exploitation mobile

2.2 Les systèmes embarqués

2.2.2 Caractéristiques d’un système embarqué

Figure 2.1 – Architecture générale d’un système embarqué

Figure 2.2 – Topologie d’un système embarqué

• Faible encombrement et faible poids : Il est très important de minimiser la taille

2.2.3 Architecture d’un système embarqué

2.2.4 L’application du système embarqué

2.3 Système d’exploitation mobile

Figure 2.3 – Utilisation des SE mobile en 2019

2.3.3 Caractéristiques d’un système d’exploitation mobile

2.3.4 Les systèmes d’exploitations mobile dans le marché

2.4 Le Système d’exploitation mobile : Android

2.4.3 Les avantages d’Android

2.4.4 Les versions d’Android

2.4.5 Architecture d’Android

Numéro de version Nom de version Date de sortie