Cours pour apprendre le developpement web mobile

Aller au Téléchargement

Programmation mobile avec Android

Pierre Nerzic -

février-mars 2018

Abstract

Il s’agit des transparents du cours mis sous une forme plus facilement imprimable et lisible.

Ces documents ne sont pas totalement libres de droits. Ce sont des supports de cours mis à votre disposition pour vos études sous la licence Creative Commons Attribution - Pas

d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Version du 04/06/2018 à 12:06

Table des matières

1.1 Introduction .. 16

1.1.1 Android 16

1.1.2 Définition 16

1.1.3 Composants d’Android 18

1.1.4 Programmation d’applications 18

1.2 SDK Android et Android Studio .. 18

1.2.1 SDK et Studio 18

1.2.2 Android Studio 18

1.2.3 SDK Manager 18

1.2.4 Choix des éléments du SDK .. 20

1.2.5 Dossiers du SDK .. 20

1.3 Première application 20

1.3.1 Objectif de la semaine 1 . 20

1.3.2 Assistant de création d’application .. 20

1.3.3 Choix de la version 21

1.3.4 Choix de la version 21

1.3.5 Choix du type d’application .. 21

1.3.6 Points à configurer 24

1.3.7 Noms des packages et classes . 24

1.3.8 Résultat de l’assistant .. 24

1.3.9 Fenêtre du projet .. 24

1.3.10 Éditeurs spécifiques .. 24

1.3.11 Exemple .. 27

1.3.12 Exemple .. 27

1.3.13 Source XML sous-jacent .. 27

1.3.14 Reconstruction du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 .

1.3.15 Gradle 29

1.3.16 Structure d’un projet AndroidStudio 29

1.3.17 Mises à jour 29

1.3.18 Mises à jour (suite) . 30

1.3.19 Utilisation de bibliothèques .. 30

1.4 Première exécution .. 30

1.4.1 Exécution de l’application . 30

1.4.2 Assistant de création d’une tablette virtuelle . 31

1.4.3 Caractéristiques d’un AVD 31

1.4.4 Lancement d’une application .. 32

1.4.5 Application sur l’AVD 32

1.5 Communication AVD - Android Studio 32

1.5.1 Fenêtres Android 32

1.5.2 Fenêtre Logcat . 32

1.5.3 Filtrage des messages .. 32

1.5.4 Émission d’un message pour LogCat 34

1.5.5 Logiciel ADB .. 34

1.5.6 Mode d’emploi de ADB .. 34

1.5.7 Mode d’emploi, suite .. 35

1.5.8 Système de fichiers Android 35

1.5.9 Mode d’emploi, suite .. 35

1.6 Création d’un paquet installable 36

1.6.1 Paquet . 36

1.6.2 Signature d’une application . 36

36

1.6.4 Création d’une clé . 36

1.6.5 Création du paquet .. 36

1.6.6 Et voilà . 37

2.1 Applications et activités . 40

2.1.1 Composition d’une application .. 40

2.1.2 Création d’un écran .. 40

2.2 Ressources . 40

2.2.1 Identifiant de ressource . 40

2.2.2 La classe R .. 41

2.2.3 Rappel sur la structure d’un fichier XML 41

2.2.4 Espaces de nommage dans un fichier XML .. 41

2.2.5 Création d’une interface par programme . 42

2.2.6 Programme et ressources . 42

2.2.7 Ressources de type chaînes . 42

) .. 43

2.2.9 Référencement des ressources texte .. 43

2.2.10 Identifiants et vues . 43

2.2.11 @id/nom ou @+id/nom ? .. 44

2.2.12 Images : 44

2.2.13 Tableau de chaînes : .. 44

2.2.14 Autres 45

2.3 Mise en page 45

2.3.1 Structure d’une interface Android 45

2.3.2 Arbre des vues . 45

2.3.3 Représentation en XML .. 45

2.3.4 Paramètres de positionnement . 46

2.3.5 Paramètres généraux .. 46

2.3.6 Autres paramètres géométriques . 46

2.3.7 Marges et remplissage 47

2.3.8 Groupe de vues LinearLayout . 47

2.3.9 Pondération des tailles 47

2.3.10 Exemple de poids différents .. 48

2.3.11 Groupe de vues TableLayout . 48

2.3.12 Largeur des colonnes d’un TableLayout . 49

2.3.13 Groupe de vues RelativeLayout .. 49

2.3.14 Utilisation d’un RelativeLayout 49

2.3.15 Autres groupements . 49

2.4 Composants d’interface . 50

2.4.1 Vues .. 50

2.4.2 TextView . 50

2.4.3 Button .. 50

2.4.4 Bascules .. 50

2.4.5 EditText 51

2.4.6 Autres vues 51

2.5 Styles 51

2.5.1 Styles et thèmes . 51

2.5.2 Définir un style 51

2.5.3 Utiliser un style 52

2.5.4 Utiliser un thème 52

2.5.5 C’est tout 52

3.1 Applications et activités . 53

3.1.1 Composition d’une application .. 53

3.1.2 Déclaration d’une application . 53

3.1.3 Sécurité des applications (pour info) .. 54

3.1.4 Autorisations d’une application . 54

3.1.5 Démarrage d’une application .. 54

3.1.6 Démarrage d’une activité et Intents 55

3.1.7 Lancement d’une activité par programme .. 55

3.1.8 Lancement d’une application Android 55

3.1.9 Lancement d’une activité d’une autre application .. 55

3.2 Applications .. 56

3.2.1 Fonctionnement d’une application .. 56

3.2.2 Navigation entre activités . 56

3.2.3 Lancement sans attente . 56

3.2.4 Lancement avec attente de résultat 56

3.2.5 Lancement avec attente, suite 58

3.2.6 Terminaison d’une activité 58

3.2.7 Méthode onActivityResult 58

3.2.8 Transport d’informations dans un Intent .. 59

3.2.9 Extraction d’informations d’un Intent 59

3.2.10 Contexte d’application . 59

3.2.11 Définition d’un contexte d’application 59

3.2.12 Définition d’un contexte d’application, suite 60

3.2.13 Définition d’un contexte d’application, fin 60

3.3 Activités .. 60

3.3.1 Présentation . 60

3.3.2 Cycle de vie d’une activité . 61

3.3.3 Événements de changement d’état . 61

3.3.4 Squelette d’activité .. 61

3.3.5 Terminaison d’une activité 62

3.3.6 Pause d’une activité . 62

3.3.7 Arrêt d’une activité .. 62

3.3.8 Enregistrement de valeurs d’une exécution à l’autre . 62

3.3.9 Restaurer l’état au lancement . 63

3.4 Vues et activités . 63

3.4.1 Obtention des vues .. 63

3.4.2 Propriétés des vues .. 63

3.4.3 Actions de l’utilisateur . 64

3.4.4 Définition d’un écouteur 64

3.4.5 Écouteur privé anonyme 65

3.4.6 Écouteur privé . 65

3.4.7 L’activité elle-même en tant qu’écouteur . 65

3.4.8 Distinction des émetteurs . 66

3.4.9 Événements des vues courantes 66

3.4.10 C’est fini pour aujourd’hui . 66

4.1 Présentation . 67

4.1.1 Principe général .. 67

4.1.2 Schéma global . 68

4.1.3 Une classe pour représenter les items 68

4.1.4 Données initiales 69

4.1.5 Données initiales dans les ressources . 69

4.1.6 Données dans les ressources, suite . 69

4.1.7 Copie dans un ArrayList .. 70

4.1.8 Rappels sur le container ArrayList<type> . 70

4.1.9 Remarques 70

4.2 Affichage de la liste .. 71

4.2.1 Activité spécialisée ou standard . 71

4.2.2 Mise en œuvre 71

4.2.3 Layout de l’activité pour afficher une liste 71

4.2.4 Mise en place du layout d’activité 71

4.3 Adaptateurs .. 72

4.3.1 Relations entre la vue et les données . 72

4.3.2 Rôle d’un adaptateur .. 72

4.3.3 Adaptateurs prédéfinis 73

4.3.4 ArrayAdapter<Type> pour les listes . 73

4.3.5 Exemple d’emploi .. 73

4.3.6 Affichage avec une ListActivity 73

4.3.7 Layout pour un item . 74

4.3.8 Autre layouts 74

4.3.9 Layouts prédéfinis . 75

4.3.10 Exemple avec les layouts standards .. 75

4.4 Adaptateur personnalisé 75

4.4.1 Classe Adapter personnalisée . 75

4.4.2 Classe Adapter perso, suite .. 76

4.4.3 Réutilisation d’une vue 76

4.4.4 Méthode getView personnalisée .. 76

4.4.5 Méthode PlaneteView.create . 76

4.4.6 Layout d’item .. 77

4.4.7 Classe personnalisée dans les ressources . 77

4.4.8 Classe PlaneteView pour afficher les items . 78

4.4.9 Définition de la classe PlaneteView . 78

4.4.10 Créer des vues à partir d’un layout XML . 78

4.4.11 Méthode PlaneteView.create .. 79

4.4.12 Méthode findViews 79

4.4.13 Pour finir, la méthode PlaneteView.setItem . 79

4.4.14 Récapitulatif .. 80

4.4.15 Le résultat 80

4.5 Actions utilisateur sur la liste .. 80

4.5.1 Modification des données . 80

4.5.2 Clic sur un élément 81

4.5.3 Clic sur un élément, suite .. 81

4.5.4 Clic sur un élément, suite .. 81

4.5.5 Clic sur un élément, fin 82

4.5.6 Liste d’éléments cochables .. 82

4.5.7 Liste cochable simple .. 82

4.5.8 Liste à choix multiples . 83

4.5.9 Liste cochable personnalisée .. 83

4.6 RecyclerView 83

4.6.1 Présentation . 83

4.6.2 Principes . 83

4.6.3 Méthode onCreate de l’activité . 84

4.6.4 Disposition des éléments .. 84

4.6.5 Mise en grille 84

4.6.6 Séparateur entre items .. 85

4.6.7 Adaptateur de RecyclerView 85

4.6.8 Adaptateur de RecyclerView, suite .. 85

4.6.9 Adaptateur de RecyclerView, suite .. 86

4.6.10 Adaptateur de RecyclerView, suite 86

4.6.11 Affichage d’un item PlaneteView 86

4.6.12 Affichage d’un item PlaneteView, suite .. 87

4.7 Réponses aux sélections d’items 87

4.7.1 Clics sur un RecyclerView .. 87

4.7.2 Afficher la sélection .. 88

4.7.3 Afficher la sélection, suite . 88

4.7.4 Ouf, c’est fini 88

5.1 Barre d’action et menus . 89

5.1.1 Barre d’action .. 89

5.1.2 Réalisation d’un menu . 89

5.1.3 Spécification d’un menu . 90

5.1.4 Icônes pour les menus . 90

5.1.5 Écouteurs pour les menus . 90

5.1.6 Réactions aux sélections d’items .. 91

5.1.7 Menus en cascade . 91

5.1.8 Menus contextuels 91

5.1.9 Associer un menu contextuel à une vue 92

5.1.10 Callback d’affichage du menu .. 92

5.1.11 Callback des items du menu .. 92

5.1.12 Menu contextuel pour un RecyclerView . 93

5.1.13 Menu contextuel pour un RecyclerView, suite 93

5.1.14 Menu contextuel pour un RecyclerView, fin . 93

5.2 Annonces et dialogues 94

.. 94

5.2.2 Annonces personnalisées .. 94

5.2.3 Dialogues 95

5.2.4 Dialogue d’alerte 95

5.2.5 Boutons et affichage d’un dialogue d’alerte 95

5.2.6 Autres types de dialogues d’alerte 96

5.2.7 Dialogues personnalisés . 96

5.2.8 Création d’un dialogue 96

5.2.9 Affichage du dialogue .. 97

5.3 Fragments et activités . 97

5.3.1 Fragments .. 97

5.3.2 Tablettes, smartphones . 97

5.3.3 Structure d’un fragment . 97

5.3.4 Différents types de fragments 98

5.3.5 Cycle de vie des fragments 99

5.3.6 ListFragment . 99

5.3.7 ListFragment, suite 99

5.3.8 Menus de fragments . 100

5.3.9 Intégrer un fragment dans une activité .. 100

5.3.10 Fragments statiques dans une activité . 100

5.3.11 FragmentManager 101

5.3.12 Attribution d’un fragment dynamiquement .. 101

5.3.13 Disposition selon la géométrie de l’écran 101

5.3.14 Changer la disposition selon la géométrie .. 102

5.3.15 Deux dispositions possibles . 102

5.3.16 Communication entre Activité et Fragments . 103

5.3.17 Interface pour un écouteur . 103

5.3.18 Écouteur du fragment 103

5.3.19 Écouteur de l’activité . 104

5.3.20 Relation entre deux classes à méditer, partie 1 104

5.3.21 À méditer, partie 2 .. 105

5.4 Préférences d’application .. 105

5.4.1 Illustration .. 105

5.4.2 Présentation .. 105

5.4.3 Définition des préférences . 106

5.4.4 Explications . 106

5.4.5 Accès aux préférences .. 106

5.4.6 Préférences chaînes et nombres . 107

5.4.7 Modification des préférences par programme 107

5.4.8 Affichage des préférences .. 107

5.4.9 Fragment pour les préférences 108

5.5 Bibliothèque support . 108

5.5.1 Compatibilité des applications . 108

5.5.2 Compatibilité des versions Android .. 108

5.5.3 Bibliothèque support 109

5.5.4 Versions de l’Android Support Library . 109

5.5.5 Mode d’emploi . 109

5.5.6 Programmation 109

5.5.7 Il est temps de faire une pause 110

6.1 Plugin Lombok .. 111

6.1.1 Présentation .. 111

6.1.2 Exemple 111

6.1.3 Nommage des champs . 112

6.1.4 Installation du plugin . 112

6.2 Realm . 112

6.2.1 Définition de Realm 112

6.2.2 Configuration d’un projet Android avec Realm .. 113

6.2.3 Initialisation d’un Realm .. 113

6.2.4 Ouverture d’un Realm .. 113

6.2.5 Fermeture du Realm . 114

6.2.6 Autres modes d’ouverture du Realm 114

6.2.7 Migration des données 114

6.3 Modèles de données Realm .. 115

6.3.1 Définir une table .. 115

6.3.2 Table Realm et Lombok 115

6.3.3 Types des colonnes 115

6.3.4 Empêcher les valeurs null 115

6.3.5 Définir une clé primaire 116

6.3.6 Exclure une variable membre .. 116

6.3.7 Définir une relation simple . 116

6.3.8 Relation multiple . 117

6.4 Création de n-uplets .. 117

6.4.1 Résumé . 117

6.4.2 Création de n-uplets par createObject 117

6.4.3 Création de n-uplets par new 118

6.4.4 Modification d’un n-uplet .. 118

6.4.5 Suppression de n-uplets .. 118

6.5 Requêtes sur la base .. 118

6.5.1 Résumé . 118

6.5.2 Sélections 119

6.5.3 Conditions simples . 119

6.5.4 Nommage des colonnes .. 119

6.5.5 Conjonctions de conditions 119

6.5.6 Disjonctions et négation de conditions 120

6.5.7 Classement des données . 120

6.5.8 Agrégation des résultats . 120

6.5.9 Chaînage de requêtes 121

6.5.10 Jointures 1-1 121

6.5.11 Jointures 1-N .. 121

6.5.12 Suppression par une requête . 122

6.6 Requêtes et adaptateurs de listes .. 122

6.6.1 Adaptateur Realm pour un RecyclerView .. 122

6.6.2 Adaptateur Realm, suite . 122

6.6.3 Adaptateur Realm, suite . 122

6.6.4 Adaptateur Realm, fin .. 123

6.6.5 Mise en place de la liste .. 123

6.6.6 Réponses aux clics sur la liste 123

6.6.7 C’est la fin 124

7.1 Dessin en 2D .. 125

7.1.1 But .. 125

7.1.2 Principes .. 125

7.1.3 Layout pour le dessin 126

7.1.4 Méthode onDraw 126

7.1.5 Méthodes de la classe Canvas .. 127

7.1.6 Peinture Paint 127

7.1.7 Quelques accesseurs de Paint .. 127

7.1.8 Motifs 127

7.1.9 Shaders . 128

7.1.10 Shaders, suite et fin . 128

7.1.11 Quelques remarques .. 128

7.1.12 «Dessinables» . 129

7.1.13 Images PNG étirables 9patch . 129

7.1.14 Drawable, suite . 129

7.1.15 Variantes .. 130

7.1.16 Utilisation d’un Drawable . 130

7.1.17 Enregistrer un dessin dans un fichier . 130

7.1.18 Coordonnées dans un canvas . 131

7.2 Interactions avec l’utilisateur 131

7.2.1 Écouteurs pour les touchers de l’écran 131

7.2.2 Modèle de gestion des actions 131

7.2.3 Automate pour gérer les actions 132

7.2.4 Programmation d’un automate .. 132

7.2.5 Programmation d’un automate, suite . 132

7.3 Boîtes de dialogue spécifiques . 133

7.3.1 Sélecteur de couleur . 133

7.3.2 Version simple .. 133

7.3.3 Concepts .. 133

7.3.4 Fragment de dialogue .. 134

7.3.5 Méthode onCreateDialog 134

7.3.6 Vue personnalisée dans le dialogue .. 135

7.3.7 Layout de cette vue 135

7.3.8 Écouteurs . 135

7.3.9 Utilisation du dialogue . 136

7.3.10 Sélecteur de fichier . 136

7.4 AsyncTasks .. 136

7.4.1 Présentation .. 136

7.4.2 Tâches asynchrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

7.4.3 Principe d’utilisation d’une AsyncTask . 138

7.4.4 Structure d’une AsyncTask . 138

7.4.5 Autres méthodes d’une AsyncTask 138

7.4.6 Paramètres d’une AsyncTask 138

7.4.7 Exemple de paramétrage 139

7.4.8 Paramètres variables . 139

7.4.9 Définition d’une AsyncTask 139

7.4.10 AsyncTask, suite 140

7.4.11 Lancement d’une AsyncTask .. 140

7.4.12 Schéma récapitulatif .. 141

7.4.13 execute ne retourne rien . 141

7.4.14 Récupération du résultat d’un AsyncTask 141

7.4.15 Simplification .. 142

7.4.16 Recommandations .. 142

7.4.17 Autres tâches asynchrones . 142

7.5 OpenStreetMap 143

7.5.1 Présentation .. 143

7.5.2 Documentation 143

7.5.3 Pour commencer . 143

7.5.4 Layout pour une carte OSM .. 145

7.5.5 Activité pour une carte OSM . 145

7.5.6 Positionnement de la vue 145

7.5.7 Calques . 146

7.5.8 Mise à jour de la carte .. 146

7.5.9 Marqueurs .. 146

7.5.10 Marqueur personnalisés .. 146

7.5.11 Réaction à un clic .. 147

7.5.12 Itinéraires . 147

7.5.13 Position GPS 147

7.5.14 Mise à jour en temps réel de la position .. 148

7.5.15 Positions simulées 148

7.5.16 Clics sur la carte . 148

7.5.17 Traitement des clics 149

7.5.18 Autorisations .. 149

8.1 Réalité augmentée . 150

8.1.1 Définition . 150

8.1.2 Applications 150

8.1.3 Principes .. 150

8.1.4 Réalité augmentée dans Android 151

8.2 Permissions Android .. 151

8.2.1 Concepts .. 151

8.2.2 Permissions dans le manifeste . 151

8.2.3 Raffinement de certaines permissions . 152

8.2.4 Demandes de permissions à la volée 152

8.2.5 Test d’une autorisation 152

8.2.6 Demande d’une autorisation 152

8.2.7 Préférences d’application .. 153

8.2.8 Dialogue de demande de droits .. 153

8.2.9 Affichage du dialogue 153

8.2.10 Justification des droits 154

8.3 Capteurs de position . 154

8.3.1 Présentation .. 154

8.3.2 Présentation, suite . 154

8.3.3 Utilisation dans Android .. 155

8.3.4 Récupération de la position .. 155

8.3.5 Abonnement aux changements de position . 155

8.3.6 Événements de position .. 156

8.3.7 Remarques . 156

8.4 Caméra . 156

8.4.1 Présentation .. 156

8.4.2 Vue SurfaceView . 157

8.4.3 Fonctionnement du SurfaceView 157

8.4.4 Événements d’un SurfaceHolder . 157

8.4.5 Écouteur surfaceCreated . 158

8.4.6 Écouteur surfaceCreated, fin 158

8.4.7 Écouteur surfaceChanged .. 158

8.4.8 Choix de la prévisualisation 159

8.4.9 Suite de surfaceChanged . 159

8.4.10 Orientation de la caméra . 159

8.4.11 Orientation de l’écran 160

8.4.12 Fin de surfaceChanged .. 160

8.4.13 Écouteur onResume 160

8.4.14 Écouteur onPause 161

8.4.15 Écouteur surfaceDestroyed . 161

8.4.16 Organisation logicielle 161

8.4.17 Organisation logicielle, suite .. 162

8.5 Capteurs d’orientation . 162

8.5.1 Présentation .. 162

8.5.2 Angles d’Euler 162

8.5.3 Matrice de rotation 163

8.5.4 Accès au gestionnaire 163

8.5.5 Accès aux capteurs . 163

8.5.6 Abonnement aux mesures . 164

8.5.7 Réception des mesures 164

8.5.8 Atténuation des oscillations .. 165

8.5.9 Atténuation des oscillations, suite . 165

8.5.10 Orientation avec TYPE_ROTATION_VECTOR .. 165

8.5.11 Orientation sans TYPE_ROTATION_VECTOR .. 166

8.5.12 Orientation sans TYPE_ROTATION_VECTOR, suite . 166

8.5.13 Orientation sans TYPE_ROTATION_VECTOR, fin .. 166

8.5.14 Orientation avec TYPE_ORIENTATION .. 166

8.6 Réalité augmentée . 167

8.6.1 Objectif . 167

8.6.2 Assemblage 167

8.6.3 Transformation des coordonnées .. 167

8.6.4 Transformation des coordonnées, suite . 167

8.6.5 Transformation des coordonnées, fin .. 168

8.6.6 Dessin du POI . 168

8.6.7 C’est la fin 168

Semaine 1

Environnement de développement

Le cours de cette semaine présente l’environnement de développement Android :

•   Le SDK Android et Android Studio

•   Création d’une application simple • Communication avec une tablette.

 1

né en 2004,

racheté par Google en 2005, publié en 2007, version 1.5, de nombreuses versions depuis, on en est à la 8, Oreo (octobre 2017).

Système complet pour smartphones et tablettes

•   Gestion matérielle : système d’exploitation Linux sous-jacent

•   API de programmation : interfaces utilisateur, outils

•   Applications : navigateur, courrier

Évolution et obsolescence très rapides (c’est voulu)

•   Ce que vous allez apprendre sera rapidement dépassé (1 an)

–  syntaxiquement (méthodes, paramètres, classes, ressources )

–  mais pas les concepts (principes, organisation )

•   Vous êtes condamné(e) à une autoformation permanente, mais c’est le lot des informaticiens.

Figure 1: Constituants d’Android

Voir la figure , page 17.

Une application Android est composée de :

•   Sources Java (ou Kotlin) compilés pour une machine virtuelle «Dalvik » (versions ? 4.4) ou «ART » depuis la version 5

•   Fichiers appelés ressources :

–  format XML : interface, textes – format PNG : icônes, images

•   Manifeste = description du contenu du logiciel

–  fichiers présents dans l’archive

–  demandes d’autorisations

–  signature des fichiers, durée de validité, etc.

Tout cet ensemble est géré à l’aide d’un IDE (environnement de développement) appelé Android Studio qui s’appuie sur un ensemble logiciel (bibliothèques, outils) appelé SDK Android.

Le SDK contient :

•         les librairies Java pour créer des logiciels

•         les outils de mise en boîte des logiciels

•         AVD : un émulateur de tablettes pour tester les applications

•         ADB : un outil de communication avec les vraies tablettes Android Studio offre :

•         un éditeur de sources et de ressources

•         des outils de compilation : gradle

•         des outils de test et de mise au point

Pour commencer, il faut installer Android Studio selon la procédure expliquée sur cette page. Il est déjà installé à l’IUT, mais en version un peu plus ancienne.

AndroidStudio s’installe avec, automatiquement, le SDK Android.

Faites attention à ce que l’installateur vous propose (versions des API et images), sinon vous aurez beaucoup de choses inutiles sur votre disque dur.

AndroidStudio livré avec un gestionnaire du SDK. C’est une application qui permet de choisir les composants à installer.

Figure 2: Gestionnaire de paquets Android Voir la figure 2, page 19.

Le gestionnaire permet de choisir les versions à installer, ex. :

•   Android 8.1 (API 27) • Android 8.0 (API 26)

•   Android 7.0 (API 24) • Android 6 (API 23)

•  

Choisir celles qui correspondent aux tablettes qu’on vise. Il faut cocher “Show Package Details”, puis choisir élément par élément. Les suivants sont indispensables :

•   Android SDK Platform

•   Intel x86 Atom_64 System Image

Le reste est facultatif (Google APIs, sources, exemples et docs).

Le gestionnaire installe environ 1 Go de fichiers :

•   SDK Tools : indispensable, contient le gestionnaire,

•   SDK Platform-tools : indispensable, contient adb,

•   SDK Platform : indispensable, contient les librairies,

•   System images : pour créer des AVD,

•   Android Support : divers outils pour créer des applications,

•   Exemples et sources.

C’est déjà installé à l’IUT, dans des versions antérieures correspondant aux tablettes dont on dispose.

Cette semaine, ce sera seulement un aperçu rapide des possibilités :

•   Création d’une application «HelloWorld » avec un assistant,

•   Tour du propriétaire,

•   Exécution de l’application, • Mise sous forme d’un paquet.

Android Studio contient un assistant de création d’applications :

Voir la figure 3, page 21.

Figure 3: Assistant de création de projet

Chaque version d’Android, dénotée par son API level, ex: 25, apporte des améliorations et supprime des dispositifs obsolètes.

Toute application exige un certain niveau d’API :

•   Minimum SDK : il faut au moins cette API car on utilise certaines classes et méthodes absentes des précédentes APIs,

Il y a aussi deux notions à connaître :

•   Target SDK : l’application sera testée et marchera correctement jusqu’à ce niveau d’API,

•   Compile With : c’est le niveau maximal de fonctionnalités qu’on se limite à employer. Si on fait appel à quelque chose de plus récent que ce niveau, le logiciel ne se compilera pas.

Voici comment choisir le Minimum SDK :

Voir la figure 4, page 22.

Ensuite, on choisit le type de projet. Pour un premier essai, on se limite au plus simple, Blank Activity :

Figure 4: Choix de la version

Figure 5: Choix du type d’activité Voir la figure 5, page 23.

L’assistant demande ensuite plusieurs informations :

•   Nom de l’application, ex : HelloWorld,

•   Nom de la classe principale : MainActivity,

•   Nom du layout de la classe principale : activity_main,

•   Nom du layout du menu principal : menu_main.

Tout peut être renommé ultérieurement, voir refactor/rename.

Le package du logiciel a été défini dans le premier écran.

Voici où on indique ces informations :

Voir la figure 6, page 25.

L’assistant a créé de nombreux éléments visibles dans la colonne de gauche de l’IDE :

•   manifests : description et liste des classes de l’application

•   java : les sources, rangés par paquetage,

•   res : ressources = fichiers XML et images de l’interface, il y a des sous-dossiers :

–  layout : interfaces (disposition des vues sur les écrans)

–  menu : menus contextuels ou d’application

–  mipmap et drawable : images, icônes de l’interface

–  values : valeurs de configuration, textes

•   Gradle scripts : c’est l’outil de compilation du projet.

NB: on ne va pas chercher à comprendre ça cette semaine.

Voir la figure 7, page 26.

Les ressources (disposition des vues dans les interfaces, menus, images vectorielles, textes ) sont définies à l’aide de fichiers XML.

Studio fournit des éditeurs spécialisés pour ces fichiers, par exemple :

•   Formulaires pour :

Figure 6: Choix du type d’activité

Figure 7: Éléments d’un projet Android – : textes de l’interface.

•   Éditeurs graphiques pour :

– res/layout/*.xml : disposition des contrôles sur l’interface.

Figure 8: Éditeur du manifeste

Voir la figure 9, page 28.

Ces éditeurs sont beaucoup plus confortables que le XML brut, mais ne permettent pas de tout faire (widgets custom et plantages).

Assez souvent, il faut éditer le source XML directement :                                                                           

Vous avez remarqué le namespace des attributs défini dans la racine.

Figure 9: Éditeur graphique

Chaque modification d’un source ou d’une ressource fait reconstruire le projet. C’est automatique.

Dans certains cas (travail avec un gestionnaire de sources comme Subversion ou Git), il peut être nécessaire de reconstruire manuellement. Il suffit de sélectionner le menu Build/Clean Project.

Ces actions lancent l’exécution de Gradle.

Gradle est un outil de construction de projets comme (projets C++ sur Unix), Ant (projets Java dans Eclipse) et .

De même que make se sert d’un fichier Makefile, Gradle se sert d’un fichier nommé build.gradle pour construire le projet.

C’est assez compliqué car AndroidStudio permet de travailler avec des projets regroupant plusieurs applications ou modules. Donc en réalité, il y a deux build.gradle :

•   un script build.gradle dans le dossier racine du projet. Il indique quelles sont les dépendances générales des applications.

•   un dossier app contenant les applications du projet.

•   un script build.gradle dans le dossier app pour compiler les applications.

Un projet AndroidStudio est constitué ainsi :

|                     +-- main

|                   |                 +-- STRUCTURE DE L'APPLICATION

|                   |          +-- java                                              SOURCES

|                          | `-- res                                                    RESSOURCES

|                       `-- test                                                           TESTS JUNIT

+-- build                                                                                FICHIERS TEMPORAIRES

+-- build.gradle                                                                DEPENDANCES

`-- gradle                                                                               FICHIERS DE GRADLE

Le SDK ainsi que Gradle sont régulièrement mis à jour, automatiquement avec AndroidStudio. Cependant, vous devrez parfois éditer les build.gradle à la main pour en tenir compte.

Par exemple, ce build.gradle fait appel à Gradle 3.0.1 et Realm 4.3.2.

buildscript { repositories { } dependencies { classpath 'com.android.tools.build:gradle:3.0.1' classpath 'io.realm:realm-gradle-plugin:4.3.2' }

}

Il faudra changer les numéros de version manuellement en cas de mise à jour, puis reconstruire le projet (sync now ou try_again).

C’est fréquent d’avoir à modifier le build.gradle situé dans le dossier app.

apply plugin: 'com.android.application'

android { compileSdkVersion 27

                 buildToolsVersion "27.0.3"                       <<== PAS PAR DEFAUT

} dependencies { compile 'com.android.support:appcompat-v7:27+'

}

Cette application dépend du SDK API 27 et de l’outil de compilation 27.0.3. Ça sera à changer lors d’une mise à jour.

Certains projets font appel à des bibliothèques externes. Cela fait généralement rajouter quelques lignes dans les deux build.gradle.

Par exemple, Realm (une base de données distribuée), voir prerequisites :

•   dans le build.gradle du dossier app :

apply plugin: 'realm-android'

•   dans le build.gradle à la racine du projet :

dependencies { classpath "io.realm:realm-gradle-plugin:4.3.2" }

La reconstruction du projet fait automatiquement télécharger la bibliothèque.

Le SDK Android permet de :

•   Installer l’application sur une vraie tablette connectée par USB

•   Simuler l’application sur une tablette virtuelle AVD

AVD = Android Virtual Device

C’est une machine virtuelle comme celles de VirtualBox et VMware, mais basée sur QEMU.

QEMU est en licence GPL, il permet d’émuler toutes sortes de CPU dont des ARM7, ceux qui font tourner la plupart des tablettes Android.

Figure 10: Création d’un AVD

L’assistant de création de tablette demande :

•   Modèle de tablette ou téléphone à simuler,

•   Version du système qu’il doit contenir, • Orientation et densité de l’écran

•   Options de simulation : – Snapshot : mémorise l’état de la machine d’un lancement à l’autre, mais exclut Use Host GPU,

–  Use Host GPU : accélère les dessins 2D et 3D à l’aide de la carte graphique du PC.

•   Options avancées :

–  RAM : mémoire à allouer, mais est limitée par votre PC,

–  Internal storage : capacité de la flash interne,

–  SD Card : capacité de la carte SD simulée supplémentaire (optionnelle).

Bouton vert pour exécuter, bleu pour déboguer :

Figure 11: Barre d’outils pour lancer une application

NB: les icônes changent selon la version d’AndroidStudio.

Voir la figure 12, page 33.

L’apparence change d’une version à l’autre du SDK.

Android Studio affiche plusieurs fenêtres utiles indiquées dans l’onglet tout en bas :

Logcat Affiche tous les messages émis par la tablette courante

Messages Messages du compilateur et du studio

Terminal Shell unix permettant de lancer des commandes dans le dossier du projet.

Des messages détaillés sont affichés dans la fenêtre LogCat :

Voir la figure 13, page 34.

Figure 12: Résultat sur l’AVD

Figure 13: Fenêtre LogCat

Ils sont émis par les applications : debug, infos, erreurs comme syslog sur Unix : date, heure, gravité, source (code de l’émetteur) et message.

Il est commode de définir des filtres pour ne pas voir la totalité des messages de toutes les applications de la tablette :

•   sur le niveau de gravité : verbose, debug, info, warn, error et assert,

•   sur l’étiquette TAG associée à chaque message, • sur le package de l’application qui émet le message.

Une application émet un message par ces instructions :                                                                             

Fonctions Log.* :

•   Log.i(String tag, String message) affiche une info,

•   Log.w(String tag, String message) affiche un avertissement,

•   Log.e(String tag, String message) affiche une erreur.

Android Debug Bridge est une passerelle entre une tablette (réelle ou virtuelle) et votre PC

•   Serveur de connexion des tablettes

•   Commande de communication

ADB emprunte à FTP (transfert de fichiers) et SSH (connexion à un shell).

En ligne de commande : adb commande paramètres

• Gestion du serveur

–  adb start-server : démarre le serveur,

–  adb kill-server : arrête le serveur,

–  adb devices : liste les tablettes connectées.

Exemple :

~/CoursAndroid/$ adb devices List of devices attached emulator-5554           device c1608df1b170d4f device ~/CoursAndroid/$

Chaque tablette (device) possède un identifiant, ex: c1608df1b170d4f ou emulator-5554 qu’il faut fournir aux commandes adb à l’aide de l’option -s.

Par défaut, c’est la seule tablette active qui est concernée.

• Connexion à un shell

–  adb -s identifiant shell commande_unix exécute la commande sur la tablette

–  adb -s identifiant shell ouvre une connexion de type shell sur la tablette.

Ce shell est un interpréteur sh simplifié (type busybox) à l’intérieur du système Unix de la tablette. Il connaît les commandes standard Unix de base : ls, cd, cp, mv, ps

On retrouve l’architecture des dossiers Unix, avec des variantes :

•   Dossiers Unix classiques : /usr, /dev, /etc, /lib, /sbin

•   Les volumes sont montés dans /mnt, par exemple /mnt/sdcard (mémoire flash interne) et /mnt/extSdCard (SDcard amovible)

•   Les applications sont dans :

–  /system/app pour les pré-installées

–  /data/app pour les applications normales

•   Les données des applications sont dans /data/data/ Ex: /data/data/fr.iutlan.helloworld/

NB : il y a des restrictions d’accès sur une vraie tablette, car vous n’y êtes pas root enfin en principe.

•   Pour échanger des fichiers avec une tablette :

–    adb push nom_du_fichier_local /nom/complet/dest envoi du fichier local sur la tablette

–    adb pull /nom/complet/fichier récupère ce fichier de la tablette • Pour gérer les logiciels installés :

–    adb install

–    adb uninstall

•   Pour archiver les données de logiciels :

–    adb backup -f fichier_local

enregistre les données du/des logiciels dans le fichier local

–    adb restore fichier_local restaure les données du/des logiciels d’après le fichier.

Un paquet Android est un fichier .apk. C’est une archive signée (authentifiée) contenant les binaires, ressources compressées et autres fichiers de données.

La création est relativement simple avec Studio :

1.    Menu contextuel du projet Build , choisir Generate Signed APK,

2.    Signer le paquet à l’aide d’une clé privée,

3.    Définir l’emplacement du fichier .apk.

Le résultat est un fichier .apk dans le dossier spécifié.

Lors de la mise au point, Studio génère une clé qui ne permet pas d’installer l’application ailleurs. Pour distribuer une application, il faut une clé privée.

Les clés sont stockées dans un keystore = trousseau de clés. Il faut le créer la première fois. C’est un fichier crypté, protégé par un mot de passe, à ranger soigneusement.

Ensuite créer une clé privée :

•   alias = nom de la clé, mot de passe de la clé

•   informations personnelles complètes : prénom, nom, organisation, adresse, etc.

Les mots de passe du trousseau et de la clé seront demandés à chaque création d’un .apk. Ne les oubliez pas.

Voir la figure 14, page 37.

Figure 14: Création d’un trousseau de clés

Voir la figure 15, page 38.

Ensuite, Studio demande où placer le .apk :

Voir la figure 16, page 39.

C’est fini pour cette semaine, rendez-vous la semaine prochaine pour un cours sur les interfaces Android.

Figure 15: Création d’une clé

Figure 16: Création du paquet

Semaine 2

Création d’interfaces utilisateur

Le cours de cette semaine explique la création d’interfaces utilisateur :

•   Activités

•   Relations entre un source Java et des ressources

•   Layouts et vues

•   Styles

On ne s’intéresse qu’à la mise en page. L’activité des interfaces sera étudiée la semaine prochaine.

NB: les textes fuchsia sont des liens cliquables.

L’interface utilisateur d’une application Android est composée d’écrans. Un écran correspond à une activité, ex :

•   afficher des informations

•   éditer des informations

Les dialogues et les pop-up ne sont pas des activités, ils se superposent temporairement à l’écran d’une activité.

Android permet de naviguer d’une activité à l’autre, ex :

•   une action de l’utilisateur, bouton, menu ou l’application fait aller sur l’écran suivant

•   le bouton back ramène sur l’écran précédent.

Chaque écran est géré par une instance d’une sous-classe perso de Activity. Sa méthode onCreate définit, entre autres, ce qui doit être affiché sur l’écran :

L’interface est mise en place par setContentView(identifiant de ressource).

La méthode setContentView spécifie l’identifiant de l’interface à afficher dans l’écran : . C’est un entier, identifiant d’une disposition de vues : un layout.

Le SDK Android (aapt) construit automatiquement une classe statique appelée R. Elle ne contient que des constantes entières groupées par catégories : id, layout, menu :

}

Cette classe R est générée automatiquement par ce que vous mettez dans le dossier res : dispositions, identifiants, chaînes Certaines de ces ressources sont des fichiers XML, d’autres sont des images PNG.

Par exemple, :

Un fichier XML : nœuds racine, éléments, attributs, valeurs, texte.

Voir le cours XML.

Dans le cas d’Android, il y a un grand nombre d’éléments et d’attributs normalisés. Pour les distinguer, ils ont été regroupés dans le namespace android. Dans la norme XML, le namespace par défaut n’est jamais appliqué aux attributs, donc il faut mettre le préfixe sur chacun d’eux.

Vous pouvez lire cette page et celle-ci sur les namespaces.

Il est possible de créer une interface par programme, comme avec JavaFX et Swing, mais c’est assez compliqué :

Il est donc préférable de stocker l’interface dans un fichier :

qui est référencé par son identifiant R.layout.nom_du_fichier (ici c’est main) dans le programme Java :

protected void onCreate(Bundle bundle) { super.onCreate(bundle); setContentView();

}

Dans , on place les chaînes de l’application, au lieu de les mettre en constantes dans le source :

Intérêt : pouvoir traduire une application sans la recompiler.

Lorsque les textes sont définis dans , il suffit de faire des copies du dossier values, en values-us, values-fr, values-de, etc. et de traduire les textes en gardant les attributs name. Voici par exemple :

Le système android ira chercher automatiquement le bon texte en fonction des paramètres linguistiques configurés par l’utilisateur.

Voici comment affecter une ressource chaîne à une vue en Java :

TextView tv = _newTextView(ctx); tv.setText(R.string.bonjour);

R.string.bonjour désigne le texte de <string name="bonjour"> dans le fichier res/values*/strings.x Voici comment spécifier un titre de label dans un :

@string/nom est une référence à une ressource, la chaîne de ayant ce nom.

La méthode setContentView fait afficher le formulaire défini par l’identifiant R.layout indiqué. Lorsque l’application veut manipuler l’une de ses vues, elle doit faire utiliser R.id.symbole, ex :

TextView tv = (TextView) findViewById(R.id.message);

NB: remarquez la conversion de type, findViewById retourne une View, superclasse de TextView. avec la définition suivante dans :

La notation @+id/nom définit un identifiant pour le TextView.

Il y a les deux notations :

@id/nom pour référencer un identifiant déjà défini (ailleurs)

@+id/nom pour définir (créer) cet identifiant

Exemple, le Button btn désigne le TextView titre :

De la même façon, les images PNG placées dans res/drawable et res/mipmaps-* sont référençables :

La notation @drawable/nom référence l’image portant ce nom dans l’un des dossiers.

NB: les dossiers res/mipmaps-* contiennent la même image à des définitions différentes, pour correspondre à différents téléphones et tablettes. Ex: mipmap-hdpi contient des icônes en 72x72 pixels.

Voici un extrait du fichier :

Dans le programme Java, il est possible de faire :

Resources res = getResources();

String[] planetes = res.getStringArray(R.array.planetes);

D’autres notations existent :

•         @style/nom pour des définitions de res/style

•         @menu/nom pour des définitions de res/menu

Certaines notations, @package:type/nom font référence à des données prédéfinies, comme :

•         @android:style/TextAppearance.Large

•         @android:color/black Il y a aussi une notation en ?type/nom pour référencer la valeur de l’attribut nom, ex : ?android:attr/textColorSecondary.

Un écran Android de type formulaire est généralement composé de plusieurs vues. Entre autres :

•   TextView, ImageView : titre, image

•   EditText : texte à saisir

•   Button, CheckBox : bouton à cliquer, case à cocher

Ces vues sont alignées à l’aide de groupes sous-classes de ViewGroup, éventuellement imbriqués :

•   LinearLayout : positionne ses vues en ligne ou colonne

•   RelativeLayout : positionne ses vues l’une par rapport à l’autre

•   TableLayout : positionne ses vues sous forme d’un tableau

Les groupes et vues forment un arbre :

Voir la figure 17, page 46.

Cet arbre s’écrit en XML :

Figure 17: Arbre de vues

La plupart des groupes utilisent des paramètres de placement sous forme d’attributs XML. Par exemple, telle vue à droite de telle autre, telle vue la plus grande possible, telle autre la plus petite.

Ces paramètres sont de deux sortes :

•   ceux qui sont demandés pour toutes les vues : android:layout_width et android:layout_height,

•   ceux qui sont demandés par le groupe englobant et qui en sont spécifiques, comme

android:layout_weight, android:layout_alignParentBottom, android:layout_centerInParent..

Toutes les vues doivent spécifier ces deux attributs :

android:layout_width largeur de la vue android:layout_height hauteur de la vue Ils peuvent valoir :

•   "wrap_content" : la vue est la plus petite possible

•   "match_parent" : la vue est la plus grande possible

•   "valeurdp" : une taille fixe, ex : "100dp" mais c’est peu recommandé, sauf 0dp pour un cas particulier, voir plus loin

Les dp sont une unité de taille indépendante de l’écran. 100dp font 100 pixels sur un écran de 100 dpi (100 dots per inch) tandis qu’ils font 200 pixels sur un écran 200dpi. Ça fait la même taille apparente.

Il est possible de modifier l’espacement des vues :

Padding espace entre le texte et les bords, géré par chaque vue Margin espace autour des bords, géré par les groupes

Figure 18: Bords et marges

On peut définir les marges et les remplissages séparément sur chaque bord (Top, Bottom, Left, Right), ou identiquement sur tous : 

<Button android:layout_margin="10dp" android:layout_marginTop="15dp" android:padding="10dp" android:paddingLeft="20dp" _/>

Il range ses vues soit horizontalement, soit verticalement                                                                          

Il faut seulement définir l’attribut android:orientation à "horizontal" ou "vertical". Lire la doc Android.

Une façon intéressante de spécifier les tailles des vues dans un LinearLayout consiste à leur affecter un poids avec l’attribut android:layout_weight.

•   Un layout_weight égal à 0 rend la vue la plus petite possible

•   Un layout_weight non nul donne une taille correspondant au rapport entre ce poids et la somme des poids des autres vues

Pour cela, il faut aussi fixer la taille de ces vues (ex : android:layout_width) soit à "wrap_content", soit à "0dp".

•   Si la taille vaut "wrap_content", alors le poids agit seulement sur l’espace supplémentaire alloué aux vues.

•   Mettre “0dp” pour que ça agisse sur la taille entière.

Voici 4 LinearLayout horizontaux de 3 boutons ayant des poids égaux à leurs titres. En 3^e ligne, les boutons ont une largeur de 0dp

Figure 19: Influence des poids sur la largeur

C’est une variante du LinearLayout : les vues sont rangées en lignes de colonnes bien tabulées. Il faut construire une structure XML comme celle-ci. Voir sa doc Android.

NB: les <TableRow> n’ont aucun attribut.

Ne pas spécifier android:layout_width dans les vues d’un TableLayout, car c’est obligatoirement toute la largeur du tableau. Seul la balise <TableLayout> exige cet attribut.

Deux propriétés intéressantes permettent de rendre certaines colonnes étirables. Fournir les numéros (première = 0).

•   android:stretchColumns : numéros des colonnes étirables

•   android:shrinkColumns : numéros des colonnes reductibles

<TableLayout android:stretchColumns="1,2" android:shrinkColumns="0,3" android:layout_width="match_parent" android:layout_height="wrap_content" _>

C’est le plus complexe à utiliser mais il donne de bons résultats. Il permet de spécifier la position relative de chaque vue à l’aide de paramètres complexes : (LayoutParams)

•   Tel bord aligné sur le bord du parent ou centré dans son parent :

–  android:layout_alignParentTop, android:layout_centerVertical

•   Tel bord aligné sur le bord opposé d’une autre vue :

–  android:layout_toRightOf, android:layout_above, android:layout_below

•   Tel bord aligné sur le même bord d’une autre vue :

–  android:layout_alignLeft, android:layout_alignTop

Pour bien utiliser un RelativeLayout, il faut commencer par définir les vues qui ne dépendent que des bords du Layout : celles qui sont collées aux bords ou centrées.

<_TextViewandroid:id="@+id/titre" android:layout_alignParentTop="true" android:layout_alignParentRight="true" android:layout_alignParentLeft="true" _/>

Puis créer les vues qui dépendent des vues précédentes.

<_EditTextandroid:layout_below="@id/titre" android:layout_alignParentRight="true" android:layout_alignParentLeft="true" _/>

Et ainsi de suite.

Ce sont les sous-classes de ViewGroup également présentées dans cette page. Impossible de faire l’inventaire dans ce cours. C’est à vous d’aller explorer en fonction de vos besoins.

Android propose un grand nombre de vues, à découvrir en TP :

•   Textes : titres, saisies

•   Boutons, cases à cocher

•   Curseurs

Beaucoup ont des variantes. Ex: saisie de texte = n^o de téléphone ou adresse ou texte avec suggestion ou

Consulter la doc en ligne de toutes ces vues. On les trouve dans le package android.widget.

À noter que les vues évoluent avec les versions d’Android, certaines changent, d’autres disparaissent.

Le plus simple, il affiche un texte statique, comme un titre. Son libellé est dans l’attribut android:text.

On peut le changer dynamiquement :                                                                                                         

TextView tvTitre = (TextView) findViewById(R.id.tvtitre); tvTitre.setText("blablabla");

L’une des vues les plus utiles est le Button :

•   En général, on définit un identifiant pour chaque vue active, ici : android:id="@+id/btn_ok"

•   Son titre est dans l’attribut android:text.

•   Voir la semaine prochaine pour son activité : réaction à un clic.

Les CheckBox sont des cases à cocher :

Les ToggleButton sont une variante : . On peut définir le texte actif et le texte inactif avec android:textOn et android:textOff.

Un EditText permet de saisir un texte  :

L’attribut android:inputType spécifie le type de texte : adresse, téléphone, etc. Ça définit le clavier qui est proposé pour la saisie.

Lire la référence Android pour connaître toutes les possibilités.

On reviendra sur certaines de ces vues les prochaines semaines, pour préciser les attributs utiles pour une application. D’autres vues pourront aussi être employées à l’occasion.

Un style permet de modifier l’apparence d’une vue :

•   Police de caractères et tailles pour les textes

•   Couleurs, images

•   Géométrie par défaut des vues : taille, espacement, remplissage

Un thème est un style appliqué à toute une activité ou application.

Consulter la documentation Android.

Il faut créer un fichier XML dans res/value :                                                                                                

L’attribut name identifie le style, et parent le rattache à un autre pour héritage des propriétés non définies ici. Voir les styles et les thèmes prédéfinis.

Il suffit de le préciser dans la définition de la vue :                                                                                      

<TextView style="@style/Elegant" android:text="@string/titre" _/>

Un thème est simplement un style appliqué partout dans l’application. Cela se spécifie dans le fichier :          

Attention, si votre style n’est pas complet, vous aurez une erreur.

C’est fini pour cette semaine, rendez-vous la semaine prochaine pour un cours sur les écouteurs et les activités.

Semaine 3

Vie d’une application

Le cours de cette semaine concerne la vie d’une application :

•   Applications et activités, manifeste : bibliographie

•   Cycles de vie : voir cette page

•   Vues, événements et écouteurs : voir ce lien et celui-ci

Une application est composée d’une ou plusieurs activités. Chacune gère un écran d’interaction avec l’utilisateur et est définie par une classe Java.

Une application complexe peut aussi contenir :

•   des services : ce sont des processus qui tournent en arrière-plan,

•   des fournisseurs de contenu : ils représentent une sorte de base de données, voir la semaine 5,

•   des récepteurs d’annonces : pour gérer des événements globaux envoyés par le système à toutes les applications.

Le fichier déclare les éléments d’une application, avec un ’.’ devant le nom de classe des

<application> est le seul élément sous la racine <manifest> et ses filles sont des <activity>.

Chaque application est associée à un UID (compte utilisateur Unix) unique dans le système. Ce compte les protège les unes des autres. Cet UID peut être défini dans le fichier :

<_?xmlversion="1.0" encoding="utf-8"_?><manifest android:sharedUserId="fr.iutlan.demos"_>

</manifest>

Définir l’attribut android:sharedUserId avec une chaîne identique à une autre application, et signer les deux applications avec le même certificat, permet à l’une d’accéder à l’autre.

Une application doit déclarer les autorisations dont elle a besoin : accès à internet, caméra, carnet d’adresse, GPS, etc.

Cela se fait en rajoutant des élements dans le manifeste :

Consulter cette page pour la liste des permissions existantes.

NB: les premières activités que vous créerez n’auront besoin d’aucune permission.

L’une des activités est marquée comme démarrable de l’extérieur :

Un <intent-filter> déclare les conditions de démarrage d’une activité, ici il dit que c’est l’activité principale.

Les activités sont démarrées à l’aide d’Intents. Un Intent contient une demande destinée à une activité, par exemple, composer un numéro de téléphone ou lancer l’application.

•   action : spécifie ce que l’Intent demande. Il y en a de très nombreuses :

– VIEW pour afficher quelque chose, EDIT pour modifier une information, SEARCH

•   données : selon l’action, ça peut être un numéro de téléphone, l’identifiant d’une information

•   catégorie : information supplémentaire sur l’action, par exemple, LAUNCHER pour lancer une application.

Une application a la possibilité de lancer certaines activités d’une autre application, celles qui ont un intent-filter.

Soit une application contenant deux activités : Activ1 et Activ2. La première lance la seconde par :

Intent intent = _newIntent(_this, Activ2.class); startActivity(intent);

L’instruction startActivity démarre Activ2. Celle-ci se met devant Activ1 qui se met alors en sommeil.

Ce bout de code est employé par exemple lorsqu’un bouton, un menu, etc. est cliqué. Seule contrainte :

que ces deux activités soient déclarées dans .

Il n’est pas possible de montrer toutes les possibilités, mais par exemple, voici comment ouvrir le navigateur sur un URL spécifique :    

String url =

";; intent = _newIntent(Intent.ACTION_VIEW, Uri.parse(url)); startActivity(intent);

L’action VIEW avec un URI (généralisation d’un URL) est interprétée par Android, cela fait ouvrir automatiquement le navigateur.

Soit une seconde application dans le package fr.iutlan.appli2. Une activité peut la lancer ainsi :

"fr.iutlan.appli2.MainActivity"); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); startActivity(intent);

Cela consiste à créer un Intent d’action MAIN et de catégorie LAUNCHER pour la classe MainActivity de l’autre application.

Au début, le système Android lance l’activité qui est marquée action=MAIN et catégorie=LAUNCHER dans .

Ensuite, d’autres activités peuvent être démarrées. Chacune se met «devant» les autres comme sur une pile. Deux cas sont possibles :

•   La précédente activité se termine, on ne revient pas dedans.

Par exemple, une activité où on tape son login et son mot de passe lance l’activité principale et se termine.

•   La précédente activité attend la fin de la nouvelle car elle lui demande un résultat en retour. Exemple : une activité de type liste d’items lance une activité pour éditer un item quand on clique longuement dessus, mais attend la fin de l’édition pour rafraîchir la liste.

Voici un schéma (Google) illustrant les possibilités de navigation parmi plusieurs activités.

Voir la figure 20, page 57.

Rappel, pour lancer Activ2 à partir de Activ1 :                                                                                             

Intent intent = _newIntent(_this, Activ2.class); startActivity(intent);

On peut demander la terminaison de this après lancement de Activ2 ainsi :                                             

Intent intent = _newIntent(_this, Activ2.class); startActivity(intent); finish();

finish() fait terminer l’activité courante. L’utilisateur ne pourra pas faire back dessus, car elle disparaît de la pile.

Figure 20: Navigation parmi les activités d’une application

Le lancement d’une activité avec attente de résultat est plus complexe. Il faut définir un code d’appel RequestCode fourni au lancement.  

private static final int APPEL_ACTIV2 = 1; Intent intent = _newIntent(_this, Activ2.class); startActivityForResult(intent, APPEL_ACTIV2);

Ce code identifie l’activité lancée, afin de savoir plus tard que c’est d’elle qu’on revient. Par exemple, on pourrait lancer au choix plusieurs activités : édition, copie, suppression d’informations. Il faut pouvoir les distinguer au retour.

Consulter cette page.

Ensuite, il faut définir une méthode callback qui est appelée lorsqu’on revient dans notre activité :

L’activité lancée par la première peut se terminer pour deux raisons :

•   Volontairement, en appelant la méthode finish() :    

setResult(RESULT_OK); finish();

•   À cause du bouton «back» du téléphone, son action revient à faire ceci :    

setResult(RESULT_CANCELED); finish();

Dans ces deux cas, on revient dans l’activité appelante (sauf si elle-même avait fait finish().

Quand on revient dans l’activité appelante, Android lui fait exécuter cette méthode :

onActivityResult(int requestCode, int resultCode, Intent data) • requestCode est le code d’appel de startActivityForResult

•   resultCode vaut soit RESULT_CANCELED soit RESULT_OK, voir le transparent précédent

•   data est fourni par l’activité appelée et qui vient de se terminer.

Ces deux dernières viennent d’un appel à setResult(resultCode, data)

Les Intent servent aussi à transporter des informations d’une activité à l’autre : les extras.

Voici comment placer des données dans un Intent :                                                                                   

Intent intent = new Intent(_this, DeleteInfoActivity.class);

intent.putExtra("idInfo", idInfo); intent.putExtra("hiddencopy", hiddencopy); startActivity(intent);

putExtra(nom, valeur) rajoute un couple (nom, valeur) dans l’intent. La valeur doit être sérialis-

able : nombres, chaînes et structures simples.

Ces instructions récupèrent les données d’un Intent :                                                                                

Intent intent = getIntent();

Integer idInfo = intent.getIntExtra("idInfo", -1); bool hidden = intent.getBooleanExtra("hiddencopy", _false);

•   getIntent() retourne l’Intent qui a démarré cette activité.

•   getTypeExtra(nom, valeur par défaut) retourne la valeur de ce nom si elle en fait partie, la valeur par défaut sinon.

Pour finir sur les applications, il faut savoir qu’il y a un objet global vivant pendant tout le fonctionnement d’une application : le contexte d’application. Voici comment le récupérer :

Application context = _this.getApplicationContext();

Par défaut, c’est un objet neutre ne contenant que des informations Android.

Il est possible de le sous-classer afin de stocker des variables globales de l’application.

Pour commencer, dériver une sous-classe de Application :                                                                        

Ensuite, la déclarer dans , dans l’attribut android:name de l’élément <application>, mettre un point devant :

Enfin, l’utiliser dans n’importe laquelle des activités :                                                                                 

Remarquez la conversion de type du contexte.

Voyons maintenant comment fonctionnent les activités.

•   Démarrage (à cause d’un Intent)

•   Apparition/masquage sur écran

•   Terminaison

Une activité se trouve dans l’un de ces états :

•   active (resumed) : elle est sur le devant, l’utilisateur peut jouer avec,

•   en pause (paused) : partiellement cachée et inactive, car une autre activité est venue devant,

•   stoppée (stopped) : totalement invisible et inactive, ses variables sont préservées mais elle ne tourne plus.

Ce diagramme résume les changement d’états d’une activité :

Figure 21: Cycle de vie

La classe Activity reçoit des événements de la part du système Android, ça appelle des fonctions appelées callbacks.

Exemples :

onCreate Un Intent arrive dans l’application, il déclenche la création d’une activité, dont l’interface. onPause Le système prévient l’activité qu’une autre activité est passée devant, il faut enregistrer les informations au cas où l’utilisateur ne revienne pas.

3.3.4.           Squelette d’activité

@Override signifie que cette méthode remplace celle héritée de la superclasse. Il faut quand même l’appeler sur super en premier.

Voici la prise en compte de la terminaison définitive d’une activité, avec la fermeture d’une base de données :       

En fait, il se peut que cette méthode ne soit jamais appelée. Voir onStop plutôt.

Cela arrive quand une nouvelle activité passe devant, exemple : un appel téléphonique. Il faut libérer les ressources qui consomment de l’énergie (animations, GPS ).  

Cela se produit quand l’utilisateur change d’application dans le sélecteur d’applications, ou qu’il change d’activité dans votre application. Cette activité n’est plus visible et doit enregistrer ses données.

Il y a deux méthodes concernées :

•   protected void onStop() : l’application est arrêtée, libérer les ressources,

•   protected void onStart() : l’application démarre, allouer les ressources.

Il faut comprendre que les utilisateurs peuvent changer d’application à tout moment. La votre doit être capable de résister à ça.

Il est possible de sauver des informations d’un lancement à l’autre de l’application (certains cas comme la rotation de l’écran ou une interruption par une autre activité), dans un Bundle. C’est un container de données quelconques, sous forme de couples (“nom”, valeur).

La méthode onRestoreInstanceState reçoit un paramètre de type Bundle (comme la méthode onCreate, mais dans cette dernière, il peut être null). Il contient l’état précédemment sauvé.

Ces deux méthodes sont appelées automatiquement (sorte d’écouteurs), sauf si l’utilisateur tue l’application. Cela permet de reprendre l’activité là où elle en était.

La méthode setContentView charge une mise en page (layout) sur l’écran. Ensuite l’activité peut avoir besoin d’accéder aux vues, par exemple lire la chaîne saisie dans un texte. Pour cela, il faut obtenir l’objet Java correspondant.   

EditText nom = (EditText) findViewById(R.id.edt_nom);

Cette méthode cherche la vue qui possède cet identifiant dans le layout de l’activité. Si cette vue n’existe pas (mauvais identifiant, ou pas créée), la fonction retourne null.

Un mauvais identifiant peut être la raison d’un bug.

NB: le changement de type (cast) est facultatif depuis peu.

La plupart des vues ont des setters et getters Java pour leurs propriétés XML. Par exemple TextView.

En XML :                                                                                                                                                        

En Java :                                                                                                                                                        

TextView tvTitre = (TextView) findViewById(R.id.titre); tvTitre.setLines(2); tvTitre.setText(R.string.debut);

Consulter leur documentation pour les propriétés, qui sont extrêmement nombreuses.

Prenons l’exemple de ce Button. Lorsque l’utilisateur appuie dessus, cela déclenche un événement «onClick», et appelle automatiquement la méthode Valider de l’activité.  

<Button android:id="@+id/btn_valider" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="@string/valider" android:onClick="Valider" _/>

Il faut définir la méthode Valider dans l’activité :                                                                                        

public void Valider(View btn) { }

Il y a une autre manière de définir une réponse à un clic : un écouteur (listener). C’est une instance de classe qui possède la méthode public void onClick(View v) ainsi que spécifié par l’interface View.OnClickListener.

Cela peut être :

•   une classe privée anonyme,

•   une classe privée ou public dans l’activité,

•   l’activité elle-même.

Dans tous les cas, on fournit cette instance en paramètre à la méthode setOnClickListener du bouton :          

btn.setOnClickListener(ecouteur);

Il s’agit d’une classe qui est définie à la volée, lors de l’appel à setOnClickListener. Elle ne contient qu’une seule méthode.         

Dans la méthode onClick, il faut employer la syntaxe pour manipuler les variables et méthodes de l’activité sous-jacente.

Cela consiste à définir une classe privée dans l’activité ; cette classe implémente l’interface OnClickListener ; et à en fournir une instance en tant qu’écouteur.

Il suffit de mentionner this comme écouteur et d’indiquer qu’elle implémente l’interface OnClickListener.        

Ici, par contre, tous les boutons appelleront la même méthode.

Dans le cas où le même écouteur est employé pour plusieurs vues, il faut les distinguer en se basant sur leur identitifiant obtenu avec getId() :    

Vous devrez étudier la documentation. Voici quelques exemples :

•   Button : onClick lorsqu’on appuie sur le bouton, voir sa doc

•   Spinner : OnItemSelected quand on choisit un élément, voir sa doc • RatingBar : OnRatingBarChange quand on modifie la note, voir sa doc

•   etc.

Heureusement, dans le cas de formulaires, les actions sont majoritairement basées sur des boutons.

C’est assez pour cette semaine, rendez-vous la semaine prochaine pour un cours sur les applications de gestion de données (listes d’items).

Plus tard, nous verrons comment Android raffine la notion d’activité, en la séparant en fragments.

Semaine 4

Application liste

Durant les prochaines semaines, nous allons nous intéresser aux applications de gestion d’une liste d’items.

•   Stockage d’une liste

•   Affichage d’une liste, adaptateurs

•   Consultation et édition d’un item

Figure 22: Liste d’items

On veut programmer une application pour afficher et éditer une liste d’items.

•   Cette semaine, la liste est stockée dans un tableau type ArrayList ; en semaine 6, ça sera dans une BDD Realm.

•   L’écran est occupé par un ListView ou un RecyclerView. Ce sont des vues spécialisées dans l’affichage de listes quelconques.

Consulter cette documentation sur les ListView et celle-ci, très compliquée, sur les RecyclerView, mais surtout celle là sur les adaptateurs.

On va d’abord parler des ListView, les plus simples, puis des RecyclerView un peu plus complexes mais plus polyvalents.

L’intermédiaire entre la liste et la vue est géré par un adaptateur, objet qui sait comment afficher un item dans le ListView.

Figure 23: Vue, adaptateur et données

Pour commencer, une classe pour représenter les items :                                                                          

Deux solutions pour initialiser la liste avec des items prédéfinis :

•   Un tableau constant Java comme ceci :          

final Planete[] initdata = { new Planete("Mercure", 58), new Planete("Vénus", 108), new Planete("Terre", 150),

};

final signifie constant, sa valeur ne changera plus.

•   Un tableau dans les ressources, pages suivantes

On crée deux tableaux dans le fichier :                                                                    

Ensuite, on récupère ces tableaux pour remplir le ArrayList :                                                                     

Intérêt : traduire les noms des planètes dans d’autres langues.

L’étape suivante consiste à recopier les valeurs initiales dans un tableau dynamique de type ArrayList<Planete> :  

C’est un type de données générique, c’est à dire paramétré par le type des éléments mis entre < > ; ce type doit être un objet.

import .ArrayList;

ArrayList<TYPE> liste = _newArrayList<>();

NB: le type entre <> à droite est facultatif.

Quelques méthodes utiles :

•   () : retourne le nombre d’éléments présents,

•   liste.clear() : supprime tous les éléments,

•   (elem) : ajoute cet élément à la liste,

•   liste.remove(elem ou indice) : retire cet élément

•   (indice) : retourne l’élément présent à cet indice,

•   liste.contains(elem) : true si elle contient cet élément,

•   liste.indexOf(elem) : indice de l’élément, s’il y est.

Cette semaine, les données sont représentées dans un tableau. Dans les exemples précédents, c’est une variable membre de l’activité. Pour faire mieux que cela, il faut définir une Application comme en semaine 3 et mettre ce tableau ainsi que son initialisation dedans. Ainsi, le tableau devient disponible dans toutes les activités de l’application. Voir le TP4.

En semaine 6, nous verrons comment utiliser une base de données Realm locale ou distante, au lieu de ce tableau dynamique, ce qui résout proprement le problème de manière à la fois élégante et persistante d’une exécution à l’autre.

Deux possibilités :

•   employer la classe ListActivity,

•   employer la classe Activity de base.

Ces deux possibilités sont très similaires : leur layout contient un ListView, il y a un layout pour les items de la liste et un adaptateur pour accéder aux données.

La ListActivity prépare un peu plus de choses pour gérer les sélections d’items. Par exemple, si on rajoute un TextView particulier, on peut avoir un message «La liste est vide».

Tandis qu’avec une simple Activity, c’est à nous de tout faire, voir page 80.

Dans tous les cas, deux layouts sont à définir :

1.    Un layout pour l’activité ; il doit contenir un ListView identifié par @android:id/list,

2.    Un layout d’item ; il contient par exemple un TextView identifié par @android:id/text1, ce layout est affiché pour chaque item des données.

Consulter la documentation de ListActivity.

Voici le layout . J’ai rajouté le TextView qui affiche «Liste vide». Notez les identifiants spéciaux list et empty.           

On peut rajouter d’autres vues : boutons

Classiquement :                                                                                                                                            

Un ListView affiche les items à l’aide d’un adaptateur (adapter).

Figure 24: Adaptateur entre les données et la vue

L’adaptateur répond à la question que pose le ListView : «que dois-je afficher à tel endroit dans la liste ? ». Il va chercher les données et instancie le layout d’item avec les valeurs.

C’est une classe qui :

•   accède aux données à l’aide de méthodes telles que getItem(int position), getCount(), isEmpty() quelque soit le type de stockage des éléments : tableau, BDD

•   crée les vues d’affichage des items : getView( ) à l’aide du layout des items. Cela consiste à instancier le layout — on dit expanser le layout, inflate en anglais.

Android propose quelques classes d’adaptateurs prédéfinis, dont :

•   ArrayAdapter pour un ArrayList simple,

•   SimpleCursorAdapter pour accéder à une base de données SQLite (on ne verra pas).

En général, dans une application innovante, il faut définir son propre adaptateur, voir page 75, mais commençons par un ArrayAdapter standard.

Il permet d’afficher les données d’un ArrayList, mais il est limité à une seule chaîne par item, par exemple le nom d’une planète, fournie par sa méthode toString(). Son constructeur :

ArrayAdapter(Context context, int item_layout_id, int textview_id, List<T> données)

context c’est l’activité qui crée cet adaptateur, mettre this

item_layout_id identifiant du layout des items, p. ex. android.R.layout.simple_list_item_1 ou

textview_id identifiant du TextView dans ce layout, p. ex. .text1 ou R.id.item_nom données c’est la liste contenant les données (List est une surclasse de ArrayList)

Suite de la méthode onCreate de l’activité, on fournit la ArrayList<Planete> mListe au constructeur d’adaptateur :

La classe Planete doit avoir une méthode toString(), cf page 68. Cet adaptateur n’affiche que le nom de la planète, rien d’autre.

Si l’activité est une ListActivity, la fin est peu plus simple :                                                                         

Vous devez définir le layout pour afficher un item :                                                                     

Ce layout est réduit à un TextView dont l’identifiant Java est R.id.item_nom. Retrouvez les dans la création de l’adaptateur :

new ArrayAdapter<Planete>(this, , R.id.item_nom, mListe);

Il est possible de créer des dispositions plus complexes pour les items mais alors il faudra programmer un adaptateur spécifique.

Figure 25: Layout complexe

Voir les adaptateurs personnalisés, page 75.

Android définit deux layouts pour des éléments de listes simples :

•   android.R.layout.simple_list_item_1 C’est un layout qui affiche un seul TextView. Son identifiant est .text1,

•   android.R.layout.simple_list_item_2

C’est un layout qui affiche deux TextView : un titre en grand et un sous-titre. Ses identifiants sont .text1 et .text2.

Il suffit de les fournir à l’adaptateur. Il n’y a pas besoin de créer des fichiers XML, ni pour l’écran, ni pour les items.

Avec les layouts d’items standards Android, cela donne :                                                                           

// créer un adaptateur standard pour mListe

ArrayAdapter<Planete> adapter = new ArrayAdapter<Planete>(this, android.R.layout.simple_list_item_1, .text1, mListe);

// associer la liste affichée et l'adaptateur setListAdapter(adapter);

Le style d’affichage est minimaliste, seulement la liste des noms. On ne peut pas afficher deux informations avec un ArrayAdapter.

Parce que ArrayAdapter n’affiche qu’un seul texte, nous allons définir notre propre adaptateur : PlaneteAdapter.

Il faut le faire hériter de ArrayAdapter<Planete> pour ne pas tout reprogrammer :                                  

Source biblio :

Sa principale méthode est getView qui crée les vues pour le ListView. Elle retourne une disposition, p. ex. un RelativeLayout contenant des TextView et ImageView.       

public

View getView(int position, View recup, ViewGroup parent);

•   position est le numéro, dans le ListView, de l’item à afficher.

•   recup est une ancienne vue devenue invisible dans le ListView. Voir transpa suivant.

NB: ce paramètre s’appelle convertView dans les docs.

•   parent : le ListView auquel sera rattaché cette vue.

À l’écran, un ListView ne peut afficher que quelques éléments en même temps. On peut faire défiler vers le haut ou vers le bas pour voir les autres.

Au lieu d’instancier autant de layouts que d’éléments dans la liste, un ListView réutilise ceux qui deviennent invisibles à cause du défilement. Par exemple, quand on défile vers le haut pour voir plus bas, les éléments du haut disparaissent de la vue ; on peut donc les réutiliser en changeant leur contenu et en les affichant en dessous.

C’est comme un escalator : les marches qui arrivent à un bout reviennent au début.

Le paramètre appelé recup (ou convertView) est une telle vue réutilisée. S’il est null, on doit créer la vue pour cet item, sinon on doit reprendre recup et changer son contenu.

Voici donc la surcharge de cette méthode :                                                                                                 

Cette méthode crée une instance de PlaneteView qui est un groupe de vues pour afficher un item des données.

•   La méthode PlaneteAdapter.getView crée des PlaneteView à la demande du ListView,

•   Un PlaneteView est une sorte de RelativeLayout contenant des TextView et ImageView

Figure 26:

•   Cette disposition est définie par un fichier layout XML .

L’ensemble des données est affiché par plusieurs instances de PlaneteView dans le ListView.

C’est subtil : on va remplacer la racine du layout des items, un RelativeLayout par une classe personnalisée :          

Et cette classe PlaneteView hérite de RelativeLayout :                                                                               

Android permet d’utiliser les classes de notre application à l’intérieur d’un layout. Il suffit de les préfixer par le package.        

La classe MaVuePerso doit hériter de View et implémenter certaines méthodes.

Cette classe a pour but de gérer les vues dans lesquelles il y a les informations des planètes : nom, distance, image.

On la met à la place de la balise RelativeLayout :                                                                                        

Les propriétés de placement restent les mêmes. PlaneteView est seulement une sous-classe de RelativeLayout avec quelques variables d’instance et méthodes de plus.

Le constructeur de PlaneteView est nécessaire, mais quasi-vide :                                                              

public class PlaneteView extends RelativeLayout

{ public PlaneteView(Context context, ) { super(context, attrs); }

Tout se passe dans la méthode de classe PlaneteView.create appelée par l’adaptateur. Rappel de la page 76 :

Cette méthode create génère les vues du layout .

La génération de vues pour afficher les items repose sur un mécanisme appelé LayoutInflater qui fabrique des vues Android à partir d’un layout XML :          

LayoutInflater li = (context); View vueItem = li.inflate(, parent);

On lui fournit l’identifiant du layout, p. ex. celui des items. Elle crée les vues spécifiées dans .

•   context est l’activité qui affiche toutes ces vues,

•   parent est la vue qui doit contenir ces vues, null si aucune.

La méthode de classe PlaneteView.create expanse le layout des items à l’aide d’un LayoutInflater :

static signifie qu’on appelle cette méthode sur la classe elle-même et non pas sur une instance. C’est une méthode de classe.

Cette méthode a pour but de récupérer les objets Java des TextView et ImageView de l’item. Elle les recherche avec leurs identifiants et affecte des variables d’instance.

Son rôle est d’afficher les informations d’une planète dans les TextView et ImageView de l’item.

Elle utilise les getters de la classe Planete : getNom

Voici la séquence qui amène à l’affichage d’un item dans la liste :

1.    Le ListView appelle la méthode getView(position, ) de l’adaptateur, position est le n^o de l’élément concerné,

2.    L’adaptateur appelle éventuellement PlaneteView.create :

a.  PlaneteView.create fait instancier = une sous-classe de RelativeLayout appelée PlaneteView.

b.  Cela crée les vues nom, distance et image pour lesquelles PlaneteView.findViews récupère les objets Java.

3.    L’adaptateur appelle la méthode setItem du PlaneteView avec les données à afficher.

a.  PlaneteView.setItem appelle setText des vues pour afficher les valeurs.

Figure 27: Liste d’items

Les modifications sur les données doivent se faire par les méthodes add, insert, remove et clear de l’adaptateur. Voir la doc.

Si ce n’est pas possible, par exemple parce qu’on a changé d’activité et modifié les données sans adaptateur, alors au retour, par exemple dans onActivityResult, il faut prévenir l’adaptateur par la méthode suivante :    adapter.notifyDataSetChanged();

Voyons le traitement des sélections utilisateur sur une liste. La classe ListActivity définit déjà un écouteur pour les clics. Il suffit de le surcharger :    

Par exemple, créer un Intent pour afficher ou éditer l’item. Ne pas oublier d’appeler adapter.notifyDataSetChanged(); au retour.

Si votre activité est une simple Activity (parce qu’il y a autre chose qu’une liste, ou plusieurs listes), alors c’est plus complexe :

•   Votre activité doit implémenter l’interface AdapterView.OnItemClickListener,

•   Vous devez définir this en tant qu’écouteur du ListView,

•   Votre activité doit surcharger la méthode onItemClick.

4.5.4.             Clic sur un élément, suite

Et voici sa méthode onItemClick :                                                                                                                

Il existe aussi la méthode boolean onItemLongClick ayant les mêmes paramètres, installée par setOnItemLongClickListener.

Android offre des listes cochables comme celles-ci :

Figure 28: Éléments cochables

Le style de la case à cocher dépend du choix unique ou multiple.

Android propose un layout prédéfini pour items cochables :                                                                     

ListView lv = findViewById(); lv.setChoiceMode(ListView.CHOICE_MODE_SINGLE);

}

Toujours avec des listes prédéfinies, c’est une simple variante :

•   mettre simple_list_item_multiple_choice à la place de simple_list_item_checked,

•   mettre ListView.CHOICE_MODE_MULTIPLE au lieu de ListView.CHOICE_MODE_SINGLE.

La méthode onListItemClick est appelée sur chaque élément cliqué.

Si on veut un layout personnalisé comme PlaneteView, il faut que sa classe implémente l’interface Checkable càd 3 méthodes :

•   public boolean isChecked() indique si l’item est coché

•   public void setChecked(boolean etat) doit changer l’état interne de l’item

•   public void toggle() doit inverser l’état interne de l’item

Il faut rajouter un booléen dans chaque item, celui que j’ai appelé état interne.

D’autre part, dans le layout d’item, il faut employer un CheckedTextView même vide, plutôt qu’un CheckBox qui ne réagit pas aux clics (bug Android).

Ce type de vue affiche également une liste, comme un ListView. Il s’appuie également sur un adaptateur, et repose sur un mécanisme très similaire à la classe PlaneteView qu’on appelle view holder.

Les concepts du RecyclerView sont repris dans de nombreux autres contrôles Android : les boîtes à onglets, etc.

NB: cette vue appartient à la bibliothèque support, voir au prochain cours. Il faut rajouter ceci dans le build.gradle du projet :

compile 'com.android.support:recyclerview-v7:25.3.1'

NB: dans la version 3 d’AndroidStudio, il faut mettre implementation à la place de compile.

Comme pour un ListView, vous devez définir deux layouts :

•   pour l’activité. Mettez RecyclerView au lieu de ListView

•   pour les items de la liste.

Comme précédemment, la méthode onCreate de l’activité crée un adaptateur pour les données et l’associe au RecyclerView. Ce qui change, c’est l’adaptateur PlaneteAdapter et la classe liée aux items PlaneteView.

4.6.3.            Méthode onCreate de l’activité

Pour un affichage correct des éléments, il manque quelques instructions. Il faut spécifier un gestionnaire de mise en page :         

On peut indiquer l’axe de défilement de la liste :                                                                                        

Au lieu d’un LinearLayoutManager, on peut créer un GridLayoutManager qui fait une grille d’un certain nombre de colonnes indiqué en paramètre :

import android.support.v7.widget.GridLayoutManager;

GridLayoutManager glm = _newGridLayoutManager(_this, 2); recyclerView.setLayoutManager(glm); recyclerView.setHasFixedSize(_true);

On peut aussi indiquer l’axe de défilement de la liste :                                                                               

Par défaut, un RecyclerView n’affiche pas de ligne de séparation entre les élements. Pour en avoir :

Voir ce lien sur stackoverflow pour un séparateur dans une grille.

Voici la nouvelle définition pour un RecyclerView :                                                                                     

C’est une classe qui hérite de RecyclerView.Adapter. Son constructeur mémorise la liste des données dans une variable privée.

Parmi les méthodes à définir, il faut surcharger la méthode getItemCount ; elle retourne le nombre d’éléments de la collection :  @Override

public int getItemCount()

{ return (); }

Dans un cas général, si les données ne sont pas stockées dans une liste, cela peut entraîner un calcul plus complexe.

Deux autres méthodes doivent être surchargées, voici la première :                                                         

Son rôle est de remplir un PlaneteView avec la donnée spécifiée par la position. La classe PlaneteView est légèrement différente de la version pour ListView, voir plus loin.

La dernière méthode à surcharger est très simple :                                                                                    

Le rôle de cette méthode est le même que getView des adaptateurs vus au début de ce cours. Elle expanse les vues pour afficher un item. La réutilisation d’un item est gérée automatiquement par Android.

C’est une variante de celle du ListView, les explis sont après :                                                                    

class PlaneteView _extendsRecyclerView.ViewHolder { private TextView tvNom;

•   Son constructeur reçoit une View en paramètre. En réalité, c’est la racine du layout d’item, donc un RelativeLayout ici.

•   La méthode findViews permet d’associer des objets Java aux vues du layout d’item.

•   Il devient donc inutile de mentionner une classe perso dans le layout d’item. Ce layout redevient «normal» :       

Petit problème : il n’y a pas d’écouteur pour les clics sur les éléments, comme avec un ListView. Une solution simple passe par la méthode onBindViewHolder de l’adaptateur :

Pour mettre un item en évidence dans un RecyclerView, il faut gérer la position désignée par un clic :           

Ensuite, on modifie onBindViewHolder :                                                                                                     

C’est tout pour cette semaine. La semaine prochaine nous parlerons des menus, dialogues et fragments.

Semaine 5

Ergonomie

Le cours de cette semaine concerne l’ergonomie d’une application Android.

•   Menus et barre d’action

•   Popup-up : messages et dialogues

•   Activités et fragments

•   Préférences (pour info)

•   Bibliothèque support (pour info)

La barre d’action contient l’icône d’application (1), quelques items de menu (2) et un bouton pour avoir les autres menus (3).

Figure 29: Barre d’action

Avant Android 3.0 (API 11), les actions d’une application étaient lancées avec un bouton de menu, mécanique. Depuis, elles sont déclenchées par la barre d’action. C’est presque la même chose.

Le principe général : un menu est une liste d’items qui apparaît soit quand on appuie sur le bouton menu, soit sur la barre d’action. Certains de ces items sont présents en permanence dans la barre d’action. La sélection d’un item déclenche une callback.

Docs Android sur la barre d’action et sur les menus

Il faut définir :

•   un fichier res/menu/nom_du_menu.xml,

•   des thèmes pour afficher soit la barre d’action, soit des menus,

•   deux callbacks pour gérer les menus : création et activation.

Créer res/menu/nom_du_menu.xml :                                                                                                          

L’attribut showAsAction vaut "always", "ifRoom" ou "never" selon la visibilité qu’on souhaite dans la barre d’action. Cet attribut est à modifier en app:showAsAction si on utilise la bibliothèque support (appcompat).

Android distribue gratuitement un grand jeu d’icônes pour les menus, dans les deux styles MaterialDesign : HoloDark et HoloLight.

Figure 30: Icônes de menus

Consulter la page Downloads pour des téléchargements gratuits de toutes sortes de modèles et feuilles de styles.

Téléchargez Action Bar Icon Pack pour améliorer vos applications.

Il faut programmer deux méthodes. L’une affiche le menu, l’autre réagit quand l’utilisateur sélectionne un item. Voici la première :       

@Override

public boolean onCreateOptionsMenu(Menu menu)

{ getMenuInflater().inflate(R.menu.nom_du_menu, menu); return true;

}

Cette méthode rajoute les items du menu défini dans le XML.

Un MenuInflater est un lecteur/traducteur de fichier XML en vues ; sa méthode inflate crée les vues.

Voici la seconde callback, c’est un aiguillage selon l’item choisi :                                                               

Définir deux niveaux quand la barre d’action est trop petite :                                                                    

Voir la figure 31, page 92.

Ces menus apparaissent lors un clic long sur un élément de liste. Le principe est le même que pour les menus normaux :

•   Attribuer un écouteur à l’événement onCreateContextMenu. Cet événement correspond à un clic long et au lieu d’appeler la callback du clic long, ça fait apparaître le menu.

Figure 31: MenuContextuel

•   Définir la callback de l’écouteur : elle expanse un layout de menu.

•   Définir la callback des items du menu.

Cela se passe par exemple dans la méthode onCreate d’une activité :                                                       

Au lieu de registerForContextMenu(lv), on peut aussi faire :                                                                      

lv.setOnCreateContextMenuListener(_this);

Un clic long sur un élément de la liste déclenche cette méthode :                                                             

@Override

public void onCreateContextMenu(ContextMenu menu, View v, ContextMenuInfo menuInfo)

{ super.onCreateContextMenu(menu, v, menuInfo); getMenuInflater().inflate(R.menu.main_context, menu);

}

Son rôle est d’expanser (inflate) le menu res/menu/main_context.

Pour finir, si l’utilisateur choisit un item du menu :                                                                                     

L’objet AdapterContextMenuInfo info permet d’avoir l’identifiant de ce qui est sélectionné.

Dans le cas d’un RecyclerView, c’est un peu plus compliqué car le menu ne se déclenche pas. Il faut ajouter un écouteur à l’adaptateur :

View.OnCreateContextMenuListener mMenuListener;

public void setMenuListener(

View.OnCreateContextMenuListener listener) { mMenuListener = listener;

}

Cet écouteur est affecté lors de la création de l’adaptateur, et en général, c’est l’activité.

La suite est dans onBindViewHolder, voir le cours précédent :                                                                   

Enfin, on modifie l’écouteur :                                                                                                                       

NB: ce n’est encore pas une bonne solution quand les items ont un identifiant et non une position, voir le TP sur Realm.

Un «toast » est un message apparaissant en bas d’écran pendant un instant, par exemple pour confirmer la réalisation d’une action. Un toast n’affiche aucun bouton et n’est pas actif.

Figure 32: Toast

Voici comment l’afficher avec une ressource chaîne :                                                                                 

La durée d’affichage peut être allongée avec LENGTH_LONG.

Il est possible de personnaliser une annonce.           Il faut seulement définir un layout dans . La racine de ce layout doit avoir un identifiant, ex : toast_perso_id qui est mentionné dans la création :      

// créer le toast et l'afficher

Toast toast = _newToast(getApplicationContext()); toast.setDuration(Toast.LENGTH_LONG); toast.setView(layout); ();

Un dialogue est une petite fenêtre qui apparaît au dessus d’un écran pour afficher ou demander quelque chose d’urgent à l’utilisateur, par exemple une confirmation.

Figure 33: Dialogue d’alerte

Il existe plusieurs sortes de dialogues :

•   Dialogues d’alerte

•   Dialogues généraux

Un dialogue d’alerte AlertDialog affiche un texte et un à trois boutons au choix : ok, annuler, oui, non, aide

Un dialogue d’alerte est construit à l’aide d’une classe nommée AlertDialog.Builder. Le principe est de créer un builder et c’est lui qui crée le dialogue. Voici le début :

// import .AlertDialog;

AlertDialog.Builder confirm = _newAlertDialog.Builder(_this); confirm.setTitle("Suppression");

confirm.setIcon(android.R.drawable.ic_dialog_alert); confirm.setMessage("Vous confirmez la suppression ?");

Ensuite, on rajoute les boutons et leurs écouteurs.

Le builder permet de rajouter toutes sortes de boutons : oui/non, ok/annuler Cela se fait avec des fonctions comme celle-ci. On peut associer un écouteur (anonyme privé ou ) ou aucun.

Dans un dialogue d’alerte, au lieu de boutons, il est possible d’afficher une liste de propositions prédéfinies. Pour cela :

•   Définir une ressource de type tableau de chaînes :   

•   Appeler la méthode confirm.setItems(R.array.notes, écouteur). L’écouteur est le même que pour un clic. Il reçoit le numéro du choix en 2^e paramètre idBtn.

Dans ce cas, ne pas appeler confirm.setMessage car ils sont exclusifs. C’est soit une liste, soit un message.

Lorsqu’il faut demander une information plus complexe à l’utilisateur, mais sans que ça nécessite une activité à part entière, il faut faire appel à un dialogue personnalisé.

Figure 34: Dialogue perso

Il faut définir le layout du dialogue incluant tous les textes, sauf le titre, et au moins un bouton pour valider, sachant qu’on peut fermer le dialogue avec le bouton back.

Ensuite cela ressemble à ce qu’on fait dans onCreate d’une activité : setView avec le layout et des setOnClickListener pour attribuer une action aux boutons.

5.2.9.           Affichage du dialogue

Depuis Android 4, les dialogues doivent être gérés par des instances de DialogFragment qui sont des sortes de fragments, voir cette page. Cela va plus loin que les dialogues. Toutes les parties des interfaces d’une application sont susceptibles de devenir des fragments :

•   liste d’items

•   affichage des infos d’un item

•   édition d’un item

Un fragment est une sorte de mini-activité. Dans le cas d’un dialogue, elle gère l’affichage et la vie du dialogue. Dans le cas d’une liste, elle gère l’affichage et les sélections des éléments.

Une interface devient plus souple avec des fragments. Selon la taille d’écran, on peut afficher une liste et les détails, ou séparer les deux.

Figure 35: Différentes apparences

Un fragment est une activité très simplifiée. C’est seulement un arbre de vues défini par un layout, et des écouteurs. Un fragment minimal est :    

Il existe différents types de fragments, voici quelques uns :

•   ListFragment pour afficher une liste d’items, comme le ferait une ListActivity.

•   DialogFragment pour afficher un fragment dans une fenêtre flottante au dessus d’une activité.

•   PreferenceFragment pour gérer les préférences.

En commun : il faut surcharger la méthode onCreateView qui définit leur contenu.

Les fragments ont un cycle de vie similaire à celui des activités, avec quelques méthodes de plus correspondant à leur intégration dans une activité.

Figure 36: Cycle de vie d’un fragment

Par exemple, voici l’attribution d’un layout standard pour la liste :                                                            

Voici la suite, le remplissage de la liste et l’attribution d’un écouteur pour les clics sur les éléments :

Un fragment peut définir un menu. Ses éléments sont intégrés à la barre d’action de l’activité. Seule la méthode de création du menu diffère, l’inflater arrive en paramètre :  

NB: dans la méthode onCreateView du fragment, il faut rajouter setHasOptionsMenu(true);

De lui-même, un fragment n’est pas capable de s’afficher. Il ne peut apparaître que dans le cadre d’une activité, comme une sorte de vue interne. On peut le faire de deux manières :

•   statiquement : les fragments à afficher sont prévus dans le layout de l’activité. C’est le plus simple à faire et à comprendre.

•   dynamiquement : les fragments sont ajoutés, enlevés ou remplacés en cours de route selon les besoins.

Dans ce cas, c’est le layout de l’activité qui inclut les fragments, p. ex. .

Ils ne peuvent pas être modifiés ultérieurement.                                                                                        

Chaque fragment doit avoir un identifiant et un nom complet.

Pour définir des fragments dynamiquement, on fait appel au FragmentManager de l’activité. Il gère l’affichage des fragments. L’ajout et la suppression de fragments se fait à l’aide de transactions. C’est simplement l’association entre un «réceptacle» (un FrameLayout vide) et un fragment.

Soit un layout contenant deux FrameLayout vides :                                                                                    

On peut dynamiquement attribuer un fragment à chacun.

En trois temps : obtention du manager, création d’une transaction et attribution des fragments aux «réceptacles».           

// gestionnaire

FragmentManager manager = getFragmentManager();

// transaction

FragmentTransaction trans = manager.beginTransaction();

// mettre les fragments dans les réceptacles (R.id.frag_liste, _newListeFragment()); (R.id.frag_infos, _newInfosFragment()); trans.commit();

Les FrameLayout sont remplacés par les fragments.

Le plus intéressant est de faire apparaître les fragments en fonction de la taille et l’orientation de l’écran (application «liste + infos»).

Figure 37: Un ou deux fragments affichés

Pour cela, il suffit de définir deux layouts (définition statique) :

•   en portrait :         

•   en paysage :         

Lorsque la tablette est verticale, le layout de layout-port est affiché et lorsqu’elle est horizontale, c’est celui de layout-land.

L’activité peut alors faire un test pour savoir si le fragment frag_infos est affiché :                                  

Lorsque l’utilisateur clique sur un élément de la liste du fragment frag_liste, cela doit afficher ses informations :

•   dans le fragment frag_infos s’il est présent,

•   ou lancer une activité d’affichage séparée si le fragment n’est pas présent (layout vertical).

Cela implique plusieurs petites choses :

•   L’écouteur des clics sur la liste est le fragment frag_liste. Il doit transmettre l’item cliqué à l’activité.

•   L’activité doit déterminer si le fragment frag_infos est affiché :

–  s’il est visible, elle lui transmet l’item cliqué

–  sinon, elle lance une activité spécifique, InfosActivity.

Voici les étapes.

D’abord la classe ListeFragment : définir une interface pour gérer les sélections d’items et un écouteur :          

Ce sera l’activité principale qui sera cet écouteur, grâce à :                                                                        

Toujours dans la classe ListeFragment, voici la callback pour les sélections dans la liste :                         

Elle va chercher l’item sélectionné et le fournit à l’écouteur, c’est à dire à l’activité principale.

Voici maintenant l’écouteur de l’activité principale :                                                                                  

Une classe «active» capable d’avertir un écouteur d’un événement. Elle déclare une interface que doit implémenter l’écouteur.

Une 2^e classe en tant qu’écouteur des événements d’un objet de Classe1, elle implémente l’interface et se déclare auprès de l’objet.

Les préférences mémorisent des choix de l’utilisateur entre deux exécutions de l’application.

Figure 38: Préférences de l’application

Il y a deux concepts mis en jeu :

•   Une activité pour afficher et modifier les préférences.

•   Une sorte de base de données qui stocke les préférences,

–  booléens,

–  nombres : entiers, réels , – chaînes et ensembles de chaînes.

Chaque préférence possède un identifiant. C’est une chaîne comme "prefs_nbmax". La base de données stocke une liste de couples (identifiant, valeur).

Voir la documentation Android

D’abord, construire le fichier :                                                                             

Ce fichier xml définit à la fois :

•   Les préférences :

–  l’identifiant : android:key

–  le titre résumé : android:title

–  le sous-titre détaillé : android:summary

–  la valeur initiale : android:defaultValue

•   La mise en page. C’est une sorte de layout contenant des cases à cocher, des zones de saisie Il est possible de créer des pages de préférences en cascade comme par exemple, les préférences système.

Consulter la doc pour connaître tous les types de préférences.

NB: le résumé n’affiche malheureusement pas la valeur courante. Consulter stackoverflow pour une proposition.

Les préférences sont gérées par une classe statique appelée PreferenceManager. On doit lui demander une instance de SharedPreferences qui représente la base et qui possède des getters pour chaque type de données.      

Les getters ont deux paramètres : l’identifiant de la préférence et la valeur par défaut.

Pour les chaînes, c’est getString(identifiant, défaut).

String hostname = prefs.getString("prefs_hostname","localhost");

Pour les entiers, il y a bug important (février 2015). La méthode getInt plante. Voir stackoverflow pour une solution. Sinon, il faut passer par une conversion de chaîne en entier :           

Il est possible de modifier des préférences par programme, dans la base SharedPreferences, à l’aide d’un objet appelé editor qui possède des setters. Les modifications font partie d’une transaction comme avec une base de données.

Voici un exemple :                                                                                                                                        

Il faut créer une activité toute simple :                                                                                                        

Le layout contient seulement un fragment :                                                                  

Mettre le nom du package complet devant le nom du fragment.

Le fragment PrefsFragment hérite de PreferenceFragment :                                                                      

C’est tout. Le reste est géré automatiquement par Android.

Android est un système destiné à de très nombreux types de tablettes, téléphones, lunettes, montres et autres. D’autre part, il évolue pour offrir de nouvelles possibilités. Cela pose deux types de problèmes :

•   Compatibilité des matériels,

•   Compatibilité des versions d’Android.

Sur le premier aspect, chaque constructeur est censé faire en sorte que son appareil réagisse conformément aux spécifications de Google. Ce n’est pas toujours le cas quand les spécifications sont trop vagues. Certains créent leur propre API, par exemple Samsung pour la caméra.

Concernant l’évolution d’Android (deux versions du SDK par an, dont une majeure), un utilisateur qui ne change pas de téléphone à ce rythme est rapidement confronté à l’impossibilité d’utiliser des applications récentes.

Normalement, les téléphones devraient être mis à jour régulièrement, mais ce n’est quasiment jamais le cas.

Dans une application, le manifeste déclare la version nécessaire :

<_uses-sdkandroid:minSdkVersion="17" android:targetSdkVersion="25" _/>

Avec ce manifeste, si la tablette n’est pas au moins en API niveau 17, l’application ne sera pas installée. L’application est garantie pour bien fonctionner jusqu’à l’API 25 incluse.

Pour créer des applications fonctionnant sur de vieux téléphones et tablettes, Google propose une solution depuis 2011 : une API alternative, «Android Support Library ». Ce sont des classes similaires à celles de l’API normale, mais qui sont programmées pour fonctionner partout, quel que soit la version du système installé.

C’est une approche intéressante qui compense l’absence de mise à jour des tablettes : au lieu de mettre à jour les appareils, Google met à jour la bibliothèque pour que les dispositifs les plus récents d’Android (ex: ActionBar, Fragments, etc.) fonctionnent sur les plus anciens appareils.

Il en existe plusieurs variantes, selon l’ancienneté qu’on vise. Le principe est celui de l’attribut minSdkVersion, la version de la bibliothèque : v4, v7 ou v11 désigne le niveau minimal exigé pour le matériel qu’on vise.

•   v4 : c’est la plus grosse API, elle permet de faire tourner une application sur tous les appareils depuis Android 1.6. Par exemple, elle définit la classe Fragment utilisable sur ces téléphones. Elle contient même des classes qui ne sont pas dans l’API normale, telles que ViewPager.

•   v7-appcompat : pour les tablettes depuis Android 2.1. Par exemple, elle définit l’ActionBar.

Elle s’appuie sur la v4.

•   Il y en a d’autres, plus spécifiques, v8, v13, v17.

La première chose à faire est de définir le niveau de SDK minimal nécessaire dans le manifeste. Depuis l’été 2017, c’est 14 :

<uses-sdk android:minSdkVersion="14" />

Ensuite, il faut modifier le script build.gradle :

dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:support-compat:25.1.1' compile 'com.android.support:support-core-utils:+' }

On rajoute les éléments nécessaires. C’est assez compliqué. Il y a à la fois le nom : support-compat, support-core-ui, support-core-utils, support-fragment, appcompat-v7 et un numéro de version complet, ou seulement + pour la plus récente.

Enfin, il suffit de faire appel à ces classes pour travailler. Elles sont par exemple dans le package android.support.v4.

import .FragmentActivity; public class MainActivity extends FragmentActivity

Il y a de très nombreuses classes et paquetages, c’est difficile à comprendre quand on débute. Le problème, c’est qu’elles ont parfois le même nom que les classes normales d’Android, ex: Fragment, FragmentActivity et parfois pas du tout, ex: AppCompatActivity. Il y a aussi des conflits inextricables entre ces classes, ex: LoaderManager (voir la semaine prochaine).

C’est fini pour cette semaine, rendez-vous la semaine prochaine pour un cours sur les adaptateurs de bases de données et les WebServices.

Semaine 6

Realm

Le cours de cette semaine va vous apprendre à stocker des informations dans un SGBD appelé Realm. Ce système utilise de simples objets Java pour représenter les n-uplets et offre de nombreuses possibilités d’interrogation.

•   Principes

•   Modèles de données

•   Requêtes

•   Adaptateurs

NB: à l’IUT on utilisera une version un peu ancienne, la 3.3.2, ayant moins de possibilités que l’actuelle.

Avant tout, on va commencer par un plugin pour AndroidStudio bien pratique, Lombok.

Le plugin Lombok, c’est son nom, regroupe un ensemble de fonctions qui se déclenchent lors de la compilation d’un source Java. Elles effectuent des transformations utiles sur le source.

Pour cela, on rajoute des annotations sur la classe ou sur les variables membres.

Une annotation Java est un mot clé commençant par un @. Il déclenche une méthode dans ce qu’on appelle un Annotation Processor. La méthode fait certaines vérifications ou génère du source Java d’après votre programme.

@Override, @SuppressWarnings("unused"), @Nullable, @NonNull sont des annotations prédéfinies dans Java (package android.support.annotation). Lombok en ajoute d’autres.

Voici comment générer automatiquement les setters et getters et la méthode toString() :                      

import lombok.ToString; import lombok.Getter; import lombok.Setter;

@ToString @Setter @Getter public class Personne

{

private int id; private String nom; private String prenom;

}

L’avantage principal est que la classe est réduite à ses variables.

Lombok est adapté à un nommage simple des champs, en écriture de chameaux et non pas en écriture hongroise. Il génère les setters et getters en ajoutant set ou get devant le nom, avec sa première lettre mise en majuscule.

•   private int nbProduits; génère

–    public void setNbProduits(int n)

–    public int getNbProduits() Dans le cas des booléens, le getter commence par is

•   private boolean enVente; génère

–    public setEnVente(boolean b)

–    public boolean isEnVente()

Voir cette page.

Il faut passer par les settings d’Android Studio, onglet Plugins, il faut chercher Lombok Plugin dans la liste.

À l’IUT, cause internet coupé, il faudra installer le plugin à l’aide d’un fichier zip. Voir le TP5.

Ensuite, dans chaque projet, il faut rajouter deux lignes dans le fichier app/build.gradle :                       

annotationProcessor 'org.projectlombok:lombok:1.16.20' compile 'org.projectlombok:lombok:1.16.20'

NB: dans Studio 3.x, il faut mettre implementation à la place de compile

Realm est un mécanisme permettant de transformer de simples classes Java en sortes de tables de base de données. La base de données est transparente, cachée dans le logiciel. Le SGBD tient à jour la liste des instances et permet de faire l’équivalent des requêtes SQL.

C’est ce qu’on appelle un ORM (object-relational mapping).

Chaque instance de cette classe est un n-uplet dans la table. Les variables membres sont les attributs de la table.

Il est très bien expliqué sur ces pages Ce cours suit une partie de cette documentation.

Avant toute chose, quand on utilise Realm, il faut éditer les deux fichiers build.gradle :

•   celui du projet, ajouter sous l’autre classpath :

classpath 'io.realm:realm-gradle-plugin:3.3.2'

•   celui du dossier app :

apply plugin: 'realm-android' android {

} dependencies { compile 'io.realm:android-adapters:2.1.0'

NB: versions et directives pour les TP à l’IUT

Vous devez placer ces instructions dans la méthode onCreate d’une sous-classe d’Application associée à votre logiciel :         

avec <application android:name=".MyApplication" dans le manifeste.

Ensuite, dans chaque activité, on rajoute ceci :                                                                                           

Il faut également fermer le Realm à la fin de l’activité :                                                                              

La méthode précédente ouvre un Realm local au smartphone. Les données seront persistantes d’un lancement à l’autre, mais elles ne seront pas enregistrées à distance.

Il existe également des Realm distants, sur un serveur appelé Realm Object Server. On les appelle des Realms synchronisés. Cela impose l’installation d’un tel serveur ainsi que l’établissement d’une connexion et d’une authentification de l’utilisateur. Ce n’est pas compliqué, mais hors propos de ce cours, voir cette page.

Il existe également des Realms en mémoire, pratiques pour faire des essais. L’ouverture se fait ainsi :

RealmConfiguration conf = new RealmConfiguration.Builder().inMemory().build();

realm = Realm.getInstance(conf);

Autre point crucial à savoir : quand vous changez le modèle des données, il faut prévoir une procédure de migration des données. C’est à dire une sorte de recopie et d’adaptation au nouveau modèle. Cette migration est automatique quand vous ne faites qu’ajouter de nouveaux champs aux objets, mais vous devez la programmer si vous supprimez ou renommez des variables membres.

Pour cela, il suffit de faire dériver une classe de la superclasse RealmObject :                                          

Cela a automatiquement créé une table de Produit à l’intérieur de Realm. Par contre, cette table n’est pas visible en tant que telle.

On peut employer le plugin Lombok sur une classe :                                                                                  

Elle reste donc extrêmement lisible. On peut se concentrer sur les algorithmes.

NB: dans la suite, l’emploi du plugin Lombok sera implicite.

Realm gère tous les types Java de base : boolean, byte, short, int, long, float, double, String, Date et byte[].

Il faut savoir qu’en interne, tous les entiers byte, short, int, long sont codés en interne par un long.

Il y a aussi tous les types Java emballés (boxed types) : Boolean, Byte, Short, Integer, Long, Float et Double. Ceux-là peuvent tous avoir la valeur null.

Si une variable objet ne doit pas être indéfinie, rajoutez l’annotation @Required :                                  

Si vous tentez d’affecter designation avec null, ça déclenchera une exception.

Dans l’exemple précédent, il y a une variable d’instance id qui est censée contenir un entier unique. Pour le garantir dans Realm, il faut l’annoter avec @PrimaryKey : 

Si vous tentez d’affecter à id la même valeur pour deux achats différents, vous aurez une exception.

Dans certains cas, on ne veut pas que toutes les variables membre soient transformées en colonnes dans la base de données. Dans ce cas, il faut les annoter avec @Ignore :   

La variable nb_tmp ne sera pas mémorisée dans la base de données.

NB: les variables de classe, static ne sont pas mémorisées.

En Realm, une relation est simplement une référence sur un autre objet Realm :                                    

La variable produit pourra soit contenir null, soit désigner un objet. Malheureusement, on ne peut pas (encore) appliquer @Required sur une référence d’objet.

Dans le transparent précédent, un Achat n’est associé qu’à un seul Produit. Si on en veut plusieurs, il faut utiliser une collection RealmList<Type> :          

Le champ produit est relié à plusieurs produits.

Le type RealmList possède les méthodes des List et Iterable entre autres : add, clear, get, contains, size

Un n-uplet est simplement une instance d’une classe qui hérite de RealmObject.

Cependant, les variables Java ne sont pas enregistrées de manière permanente dans Realm. Il faut :

• soit créer les instances avec une méthode de fabrique de leur classe, • soit créer les instances avec new puis les ajouter dans Realm.

Dans tous les cas, il faut initialiser un Realm au début de l’application.

Une fois le realm ouvert, voici comment créer des instances. Dans Realm, toute création ou modification de données doit être faite dans le cadre d’une transaction, comme dans SQL :

realm.beginTransaction();

Produit produit = realm.createObject(Produit.class, 1L); produit.setDesignation("brosse à dent"); produit.setPrixUnitaire(4.95); realm.commitTransaction();

Le second paramètre de createObject est l’identifiant, obligatoire s’il y a une @PrimaryKey.

Si vous oubliez de placer les modifications dans une transaction, vous aurez une IllegalStateException.

Une autre façon de créer des n-uplets consiste à utiliser new puis à enregistrer l’instance dans realm :

Produit produit = _newProduit(); produit.setId(1L);

produit.setDesignation("brosse à dent"); produit.setPrixUnitaire(4.95);

realm.beginTransaction();

Produit realmProd = realm.copyToRealm(produit); realm.commitTransaction();

Le problème est que ça crée deux objets, seul le dernier est connu de Realm.

Là également, il faut placer tous les changements dans une transaction :                                                 

realm.beginTransaction();

produit.setDesignation("fil dentaire");

produit.setPrixUnitaire(0.95); realm.commitTransaction();

On ne peut supprimer que des objets gérés par realm, issus de createObject ou copyToRealm :

realm.beginTransaction(); produit.deleteFromRealm(); realm.commitTransaction();

Il est possible de supprimer plusieurs objets, en faisant appel à une requête.

Une requête Realm retourne une collection d’objets (tous appartenant à Realm) sous la forme d’un RealmResults<Type>.

Ce qui est absolument magique, c’est que cette collection est automatiquement mise à jour en cas de changement des données, voir auto-updating results.

Par exemple, si vous utilisez un Realm distant, tous les changements opérés ailleurs vous seront transmis. Ou si vous avez deux fragments, une liste et un formulaire d’édition : tous les changements faits par le formulaire seront répercutés dans la liste sans aucun effort de votre part.

Les RealmResults ne sont donc pas comme de simples ArrayList. Ils sont vivants.

La requête la plus simple consiste à récupérer la liste de tous les n-uplets d’une table :                           

Cette manière d’écrire des séquences d’appels à des méthodes Java s’appelle désignation chaînée, fluent interface en anglais.

La classe du RealmResults doit être la même que celle fournie à where.

En fait, la méthode where est très mal nommée. Elle aurait due être appelée from.

Comme avec SQL, on peut rajouter des conditions :                                                                                   

La méthode equalTo(nom_champ, valeur) définit une condition sur le champ fourni par son nom et la valeur. D’autres comparaisons existent, voir cette page :

•   pour tous les champs : equalTo, notEqualTo, in

•   pour les nombres : between, greaterThan, lessThan, greaterThanOrEqualTo, lessThanOrEqualTo

•   pour les chaînes : contains, beginsWith, endsWith, like

Cet exemple montre le gros défaut, à mon sens, de Realm : on doit nommer les champs à l’aide de chaînes. Si on se trompe sur le nom de champ, ça cause une exception.

Il aurait été intéressant que Realm génère automatique une classe statique pour représenter les noms des colonnes à l’aide de symboles. Il est très conseillé de faire ceci :         

Il est possible de faire des conjonctions de conditions :                                                                              

Voici un exemple de disjonction :                                                                                                                 

beginGroup et endGroup jouent le rôle de parenthèses.

La méthode not() permet d’appliquer une négation sur la condition qui la suit.

On peut trier sur l’un des champs :                                                                                                              

Le second paramètre de sort est optionnel. S’il est absent, c’est un tri croissant sur le champ indiqué en premier paramètre.

La méthode findAll() retourne tous les objets vérifiant ce qui précède. C’est en fait cette méthode qui retourne le RealmResults.

On peut aussi utiliser findFirst() pour n’avoir que le premier. Dans ce cas, on ne récupère pas un RealmResults mais un seul objet.

Pour les champs numériques, il existe aussi min(nom_champ), max(nom_champ) et sum(nom_champ) qui retournent seulement une valeur du même type que le champ.

La classe RealmResults permet de rajouter d’autres conditions :                                                               

On arrive au plus intéressant, mais hélas frustrant comparé à ce qui est possible avec SQL. On reprend cette classe :  

public class Achat extends RealmObject { private Produit produit; private Date date;

}

On utilise une notation pointée pour suivre la référence :                                                                          

Mieux : Achat.FIELD_PRODUIT+"."+Produit.FIELD_DESI

Cela marche aussi avec cette classe :                                                                                                           

Cette requête va chercher parmi tous les produits liés et retourne les achats qui sont liés à au moins un produit dentifrice :           

Le résultat d’une requête peut servir à supprimer des n-uplets. Il faut que ce soit fait dans le cadre d’une transaction et attention à ne pas supprimer des données référencées dans d’autres objets :

realm.beginTransaction(); achats_dentif.deleteAllFromRealm(); dentifrices.deleteAllFromRealm(); realm.commitTransaction();

Realm simplifie énormément l’affichage des listes, voir le cours 4 pour les notions. Soit par exemple un RecyclerView. Le problème essentiel est la création de l’adaptateur. Il y a une classe Realm pour cela, voici un exemple d’emploi sur le TP des planètes :

Le booléen true indique à l’adaptateur que les données se mettent à jour automatiquement.

Ensuite, il faut programmer la méthode de création des vues :                                                                  

En fait, c’est la même méthode que vu dans le cours n°3.

Ensuite, il faut programmer la méthode qui place les informations dans les vues :                                   

Elle non plus ne change pas par rapport au cours n°3.

Dans le cas d’une classe avec identifiant, il faut rajouter une dernière méthode :                                     

@Override

public long getItemId(int position)

{ return getItem(position).getId(); }

Dans la méthode onCreate de l’activité qui gère la liste :                                                                            

Ces mêmes instructions seraient à mettre dans onCreateView d’un fragment le cas échéant.

L’écouteur de la liste doit transformer la position du clic en identifiant :                                                   

Le paramètre position donne la position dans la liste, tandis que id est l’identifiant de la vue cliquée dans la liste – ce n’est hélas pas l’identifiant de l’élément cliqué.

C’est fini pour cette semaine, rendez-vous la semaine prochaine pour un cours sur les applications graphiques : dessins 2D et cartes routières.

Semaine 7

Dessin 2D interactif et Cartes

Le cours de cette semaine concerne le dessin de figures 2D et les interactions avec l’utilisateur, ainsi que, pour finir sur quelque chose d’utile, les cartes géographiques en ligne.

•   CustomView et Canevas

•   Un exemple de boîte de dialogue utile

•   OpenStreetMap, la carte mondiale libre

•   et les AsyncTasks

Figure 39: Application de dessin

Une application de dessin 2D doit définir une sous-classe de View et surcharger la méthode onDraw. Voici un exemple :     

Pour voir ce dessin, il faut l’inclure dans un layout :                                                                                    

Il faut mettre le package et le nom de la classe en tant que balise XML.

L’identifiant permettra d’ajouter des écouteurs pour les touchers et déplacements.

La méthode onDraw(Canvas canvas) doit effectuer tous les tracés. Cette méthode doit être rapide.

Également, elle ne doit faire aucun new. Il faut donc créer tous les objets nécessaires auparavant, par exemple dans le constructeur de la vue.

Son paramètre canvas représente la zone de dessin. Attention, ce n’est pas un bitmap. Un canvas ne possède pas de pixels ; c’est le bitmap associé à la vue qui les possède. Voici comment on pourrait associer un canvas à un bitmap :      

C’est déjà fait pour le canvas fourni à la méthode onDraw. On obtient le bitmap de la vue avec getDrawingCache().

La classe Canvas possède de nombreuses méthodes de dessin :

•   drawColor(int color) : efface le canvas avec la couleur indiquée. Cette couleur est un code

32 bits retourné par la classe statique Color :

–  Color.BLACK, : couleurs prédéfinies,

–  (int r, int v, int b) : convertit des composantes RVB 0..255 en un code de couleur.

•   drawLine (float x1, float y1, float x2, float y2, Paint peinture) :          trace une

ligne entre (x1,y1) et (x2,y2) avec la peinture

•   drawCircle (float cx, float cy, float rayon, Paint paint) dessine un cercle.

•   etc.

Cette classe permet de représenter les modes de dessin : couleurs de tracé, de remplissage, polices, lissage C’est extrêmement riche. Voici un exemple d’utilisation :

mPeinture = _newPaint(Paint.ANTI_ALIAS_FLAG); mPeinture.setColor((128, 255, 32)); mPeinture.setAlpha(192);

mPeinture.setStyle(Paint.Style.STROKE); mPeinture.setStrokeWidth(10);

Il est préférable de créer les peintures dans le constructeur de la vue ou une autre méthode, mais surtout pas dans la méthode onDraw.

Parmi la liste de ce qui existe, on peut citer :

•   setColor(Color), setARGB(int a, int r, int v, int b), setAlpha(int a) : définissent

la couleur et la transparence de la peinture,

•   setStyle(Paint.Style style) : indique ce qu’il faut dessiner pour une forme telle qu’un rectangle ou un cercle :

–  Paint.Style.STROKE uniquement le contour

–  uniquement l’intérieur

–  Paint.Style.FILL_AND_STROKE contour et intérieur

•   setStrokeWidth(float pixels) définit la largeur du contour.

Il est possible de créer une peinture basée sur un motif. On part d’une image dans le dossier res/drawable qu’on emploie comme ceci :

mPaintMotif = _newPaint(Paint.ANTI_ALIAS_FLAG); mPaintMotif.setShader(shaderMotif); mPaintMotif.setStyle(Paint.Style.FILL_AND_STROKE);

Cette peinture fait appel à un Shader. C’est une classe permettant d’appliquer des effets progressifs, tels qu’un dégradé ou un motif comme ici (BitmapShader).

Voici la réalisation d’un dégradé horizontal basé sur 3 couleurs :                                                               

Figure 40: Dégradé horizontal

Le dégradé précédent est base sur trois couleurs situées aux extrémités et au centre du rectangle. On fournit donc deux tableaux, l’un pour les couleurs et l’autre pour les positions des couleurs relativement au dégradé, de 0.0 à 1.0.

Le dégradé possède une dimension, 100 pixels de large. Si la figure à dessiner est plus large, la couleur sera maintenue constante avec l’option CLAMP. D’autres options permettent de faire un effet miroir, MIRROR, ou redémarrer au début REPEAT.

Cette page présente les shaders et filtres d’une manière extrêmement intéressante. Comme vous verrez, il y a un grand nombre de possibilités.

Lorsqu’il faut redessiner la vue, appelez invalidate. Si la demande de réaffichage est faite dans un autre thread, alors il doit appeler postInvalidate.

La technique montrée dans ce cours convient aux dessins relativement statiques, mais pas à un jeu par exemple. Pour mieux animer le dessin, il est recommandé de sous-classer SurfaceView plutôt que View. Les dessins sont alors faits dans un thread séparé et déclenchés par des événements.

Mais pour les jeux, autant faire appel à OpenGL (ou Unity, etc.), mais son apprentissage demande quelques semaines de travail acharné.

Les canvas servent à dessiner des figures géométriques, rectangles, lignes, etc, mais aussi des Drawable, c’est à dire des «choses dessinables» telles que des images bitmap ou des formes quelconques. Il existe beaucoup de sous-classes de Drawable.

Un Drawable est créé :

                 • par une image PNG ou JPG dans res/drawable                                                                          

Bitmap bm = BitmapFactory

.decodeResource(getResources(), R.drawable.image); Drawable d = _newBitmapDrawable(getResources(),bm);

Android a défini une norme pour des images PNG étirables, les «9patch».

Il s’agit d’images PNG nommées en * qui peuvent être dessinées de différentes tailles. À gauche, l’image d’origine et à droite, 3 exemplaires étirés.

Figure 41: Image étirable

Une image «9patch» est bordée sur ses 4 côtés par des lignes noires qui spécifient les zones étirables en haut et à gauche, et les zones qui peuvent être occupées par du texte à droite et en bas.

Il faut utiliser l’outil draw9patch pour les éditer. Ça demande un peu de savoir-faire.

• Un drawable peut également provenir d’une forme vectorielle dans un fichier XML. Ex :

                   :                                                                                                                

Voir la figure 42, page 130.

Figure 42: Dessin vectoriel XML

Android permet de créer des «dessinables» à variantes par exemple pour des boutons personnalisés.

L’une ou l’autre des images sera choisie en fonction de l’état du bouton, enfoncé, relâché, inactif.

Ces objets dessinable peuvent être employés dans un canvas. Puisque ce sont des objets vectoriels, il faut définir les coordonnées des coins haut-gauche et bas-droit, ce qui permet d’étirer la figure. Les tailles qui sont indiquées dans le xml sont pourtant absolues.        

Drawable drw = getResources().getDrawable(R.drawable.carre); drw.setBounds(x1, y1, x2, y2); // coins (canvas);

Remarquez le petit piège de la dernière instruction, on passe le canvas en paramètre à la méthode draw du drawable.

NB: la première instruction est à placer dans le constructeur de la vue, afin de ne pas ralentir la fonction de dessin.

C’est très facile. Il suffit de récupérer le bitmap associé à la vue, puis de le compresser en PNG.

Un dernier mot sur les canvas. Il y a tout un mécanisme permettant de modifier les coordonnées dans un canvas :

•   déplacer l’origine avec translate(dx,dy) : toutes les coordonnées fournies ultérieurement seront additionnées à (dx,dy)

•   multiplier les coordonnées par sx,sy avec scale(sx,sy)

•   pivoter les coordonnées autour de (px,py) d’un angle a^o avec rotate(a, px, py)

En fait, il y a un mécanisme de transformations matricielles 2D appliquées aux coordonnées, ainsi qu’une pile permettant de sauver la transformation actuelle ou la restituer.

•   save() : enregistre la matrice actuelle

•   restore() : restitue la matrice avec celle qui avait été sauvée

Il existe beaucoup d’écouteurs pour les actions de l’utilisateur sur une zone de dessin. Parmi elles, on doit connaître onTouchEvent. Son paramètre indique la nature de l’action (toucher, mouvement ) ainsi que les coordonnées.    

Souvent il faut distinguer le premier toucher (ex: création d’une figure) des mouvements suivants (ex: taille de la figure).     

L’algo précédent peut se représenter à l’aide d’un automate de Mealy à deux états : repos et en cours d’édition d’une figure. Les changements d’états sont déclenchés par les actions utilisateur et effectuent un traitement.

Figure 43: Automate

Pour coder l’automate précédent, il faut une variable qui représente son état.                                        

Ensuite, à chaque événement, on se décide en fonction de cet état, voir transparent suivant.

7.2.5.              Programmation d’un automate, suite

Android ne propose pas de sélecteur de couleur, alors il faut le construire soi-même.

Figure 44: Sélecteur de couleur

En TP, on va construire une version simplifiée afin de comprendre le principe :

Voir la figure 45, page 134.

Plusieurs concepts interviennent dans ce sélecteur de couleur :

Figure 45: Sélecteur de couleur simple

•   La fenêtre dérive de DialogFragment, elle affiche un dialogue de type AlertDialog avec des boutons Ok et Annuler,

•   Cet AlertDialog contient une vue personnalisée contenant des SeekBar pour régler les composantes de couleur,

•   Les SeekBar du layout ont des callbacks qui mettent à jour la couleur choisie en temps réel, • Le bouton Valider du AlertDialog déclenche un écouteur dans l’activité qui a appelé le sélecteur.

Le fragment de dialogue doit définir plusieurs choses :

•   C’est une sous-classe de FragmentDialog public class ColorPickerDialog extends DialogFragment

•   Il définit une interface pour un écouteur qu’il appellera à la fin :

public interface OnColorChangedListener { void colorChanged(int color);

}

•   Une méthode onCreateDialog retourne un AlertDialog pour bénéficier des boutons ok et annuler. Le bouton ok est associé à une callback qui active l’écouteur en lui fournissant la couleur.

7.3.5.           Méthode onCreateDialog

Voici la définition de la classe ColorPickerView qui est à l’intérieur du dialogue d’alerte. Elle gère quatre curseurs et une couleur :       

Le layout contient quatre SeekBar, rouge, vert, bleu et alpha :                                 

Tous ces SeekBar ont un écouteur similaire :                                                                                              

Celui-ci change seulement la composante rouge de la variable mColor. Il y a les mêmes choses pour les autres composantes.

Pour finir, voici comment on affiche ce dialogue, par exemple dans un menu :                                         

Cela consiste à définir un écouteur qui reçoit la nouvelle couleur du sélecteur. L’écouteur peut la transmettre à la classe qui dessine une nouvelle figure.

Dans le même genre mais nettement trop complexe, il y a le sélecteur de fichiers pour enregistrer un dessin.

Voir la figure 46, page 137.

Une activité Android repose sur une classe, ex MainActivity qui possède différentes méthodes comme onCreate, les écouteurs des vues, des menus et des chargeurs.

Ces fonctions sont exécutées par un seul processus léger, un thread appelé «Main thread». Il dort la plupart du temps, et ce sont les événements qui le réveillent.

Ce thread ne doit jamais travailler plus de quelques fractions de secondes sinon l’interface paraît bloquée et Android peut même décider que l’application est morte (App Not Responding).

Figure 46: Sélecteur de fichier

Figure 47: Application bloquée Voir la figure 47, page 137.

Pourtant dans certains cas, une callback peut durer longtemps :

•   gros calcul

•   requête réseau

La solution passe par une séparation des threads, par exemple à l’aide d’une tâche asynchrone AsyncTask. C’est un autre thread, indépendant de l’interface utilisateur, comme un job Unix.

Lancer un AsyncTask ressemble à faire commande & en shell.

L’interface utilisateur peut être mise à jour de temps en temps par la AsyncTask. Il est également possible de récupérer des résultats à la fin de l’AsyncTask.

Ce qui est mauvais :

1.    Android appelle la callback de l’activité, ex: onClick

2.    La callback a besoin de 20 secondes pour faire son travail,

3.    Mais au bout de 5 secondes, Android propose de tuer l’application.

Ce qui est correct :

1.    Android appelle la callback de l’activité,

2.    La callback crée une AsyncTask puis sort immédiatement, 3. Le thread de l’AsyncTask travaille pendant 20 secondes,

4.    Pendant ce temps, l’interface est vide, mais reste réactive,

5.    L’AsyncTask affiche les résultats sur l’interface ou appelle un écouteur.

Une tâche asynchrone est définie par au moins deux méthodes :

doInBackground C’est le corps du traitement. Cette méthode est lancée dans son propre thread. Elle peut durer aussi longtemps que nécessaire.

onPostExecute Elle est appelée quand doInBackground a fini. On peut lui faire afficher des résultats sur l’interface. Elle s’exécute dans le thread de l’interface, alors elle ne doit pas durer longtemps.

Trois autres méthodes peuvent être définies :

Constructeur Il permet de passer des paramètres à la tâche. On les stocke dans des variables d’instance privées et doInBackground peut y accéder.

onPreExecute Cette méthode est appelée avant doInBackground, dans le thread principal. Elle sert à initialiser les traitements. Par exemple on peut préparer une barre d’avancement (ProgressBar).

onProgressUpdate Cette méthode permet de mettre à jour l’interface, p. ex. la barre d’avancement. Pour ça, doInBackground doit appeler publishProgress.

Ce qui est difficile à comprendre, c’est que AsyncTask est une classe générique (comme ArrayList).

Elle est paramétrée par trois types de données : AsyncTask<Params, Progress, Result>

•   Params est le type des paramètres de doInBackground,

•   Progress est le type des paramètres de onProgressUpdate,

•   Result est le type du paramètre de onPostExecute qui est aussi le type du résultat de doInBackground.

NB: ça ne peut être que des classes, donc Integer et non pas int, et Void au lieu de void (dans ce dernier cas, faire return null;).

Soit une AsyncTask qui doit interroger un serveur météo pour savoir quel temps il va faire. Elle va retourner un réel indiquant de 0 à 1 s’il va pleuvoir. La tâche reçoit un String en paramètre (l’URL du serveur), publie régulièrement le pourcentage d’avancement (un entier) et retourne un Float. Cela donne cette instanciation du modèle générique :

class MyTask extends AsyncTask<String, Integer, Float>

et ses méthodes sont paramétrées ainsi :

Float doInBackground(String urlserveur) void onProgressUpdate(Integer pourcentage) void onPostExecute(Float pluie)

Alors en fait, c’est encore plus complexe, car doInBackground reçoit non pas un seul, mais un nombre quelconque de paramètres tous du même type. La syntaxe Java utilise la notation « » pour signifier qu’en fait, c’est un tableau de paramètres.

Float doInBackground(String urlserveur)

Ça veut dire qu’on peut appeler la même méthode de toutes ces manières, le nombre de paramètres est variable :

doInBackground();

doInBackground(""); doInBackground("", "","");

Le paramètre urlserveur est équivalent à un String[] qui contiendra les paramètres.

Il faut dériver et instancier la classe générique. Pour l’exemple, j’ai défini un constructeur qui permet de spécifier une ProgressBar à mettre à jour pendant le travail.

Par exemple :                                                                                                                                                

Voici la suite avec la tâche de fond et l’avancement :                                                                                 

C’est très simple, on crée une instance de cet AsyncTask et on appelle sa méthode execute. Ses paramètres sont directement fournis à doInBackground :

execute va créer un thread séparé pour effectuer doInBackground, mais les autres méthodes du AsyncTask restent dans le thread principal.

Figure 48: Méthodes d’un AsyncTask

En revanche, il manque quelque chose pour récupérer le résultat une fois le travail terminé. Pourquoi n’est-il pas possible de faire ceci ?

float pluie = new PrevisionPluie(mProgressBar).execute("");

Ce n’est pas possible car :

1.    execute retourne void, donc rien,

2.    l’exécution de doInBackground n’est pas dans le même thread, or un thread ne peut pas faire return dans un autre,

3.    execute prend du temps et c’est justement ça qu’on veut pas.

Solutions : définir le thread appelant en tant qu’écouteur de cet AsyncTask ou faire les traitements du résultat dans la méthode onPostExecute.

Pour recevoir le résultat d’un AsyncTask, il faut généralement mettre en place un écouteur qui est déclenché dans la méthode onPostExecute. Exemple :       

public interface PrevisionPluieListener { public void onPrevisionPluieConnue(Float pluie);

}

// écouteur = l'activité qui lance l'AsyncTaskprivate PrevisionPluieListener ecouteur;

// appelée quand c'est fini, réveille l'écouteur

protected void onPostExecute(Float pluie) { ecouteur.onPrevisionPluieConnue(pluie);

}

L’écouteur est fourni en paramètre du constructeur, par exemple :

new PrevisionPluie(this, ).execute( );

On peut simplifier un peu s’il n’y a pas besoin de ProgressBar et si le résultat est directement utilisé dans onPostExecute :

Il faut faire extrêmement attention à :

•   ne pas bloquer le thread principal dans une callback plus de quelques fractions de secondes,

•   ne pas manipuler une vue ailleurs que dans le thread principal.

Ce dernier point est très difficile à respecter dans certains cas. Si on crée un thread, il ne doit jamais accéder aux vues de l’interface. Un thread n’a donc aucun moyen direct d’interagir avec l’utilisateur. Si vous tentez quand même, l’exception qui se produit est :

Only the original thread that created a view hierarchy can touch its views

Les solutions dépassent largement le cadre de ce cours et passent par exemple par la méthode

Activity.runOnUiThread

Il existe une autre manière de lancer une tâche asynchrone :                                                                    

Le handler gère le lancement immédiat (post) ou retardé (postDelayed) de la tâche. Elle peut elle-même se relancer.

Au contraire de Google Maps, OSM est vraiment libre et OpenSource, et il se programme extrêmement facilement.

Voir la figure 49, page 144.

Nous allons utiliser deux librairies :

•   OSMdroid : c’est la librarie de base, super mal documentée. Attention à ne pas confondre avec un site de piraterie.

•   OSMbonusPack, un ajout remarquable à cette base. Son auteur s’appelle Mathieu Kergall. Il a ajouté de très nombreuses fonctionalités permettant entre autres d’utiliser OpenStreetMap pour gérer des itinéraires comme les GPS de voiture et aussi afficher des fichiers KML venant de Google Earth.

Lire cette suite de tutoriels pour découvrir les possibilités de osmbonuspack.

Il faut d’abord installer plusieurs archives jar :

•   OSMbonusPack. Il est indiqué comment inclure cette librairie et ses dépendances dans votre projet AndroidStudio. Voir le TP7 partie 2 pour voir comment faire sans connexion réseau.

•   . C’est la librairie de base pour avoir des cartes OSM.

•   GSON : c’est une librairie pour lire et écrire du JSON,

•   OkHTTP et OKio : deux librairies pour générer des requêtes HTTP.

L’inclusion de librairies est à la fois simple et compliqué. La complexité vient de l’intégration des librairies et de leurs dépendances dans un serveur central, «maven».

Figure 49: Google Maps

Ce n’est pas un fragment, mais une vue personnalisée :                                                                             

Vous pouvez rajouter ce que vous voulez autour.

Voici la méthode onCreate minimale :                                                                                                         

Pour modifier la vue initiale de la carte, il faut faire appel au IMapController associé à la carte :

// récupérer le gestionnaire de carte (= caméra)

IMapController mapController = mMap.getController();

// définir la vue initiale mapController.setZoom(14); mapController.setCenter(_newGeoPoint(48.745, -3.455));

Un GeoPoint est un couple (latitude, longitude) représentant un point sur Terre. Il y a aussi l’altitude si on veut. C’est équivalent à un LatLng de GoogleMaps.

Les ajouts sur la carte sont faits sur des overlays. Ce sont comme des calques. Pour ajouter quelque chose, il faut créer un Overlay, lui rajouter des éléments et insérer cet overlay sur la carte.

Il existe différents types d’overlays, p. ex. :

•   ScaleBarOverlay : rajoute une échelle

•   ItemizedIconOverlay : rajoute des marqueurs

•   RoadOverlay, Polyline : rajoute des lignes

Par exemple, pour rajouter un indicateur d’échelle de la carte :                                                                

// ajouter l'échelle des distances

ScaleBarOverlay echelle = _newScaleBarOverlay(mMap); mMap.getOverlays().add(echelle);

Chaque fois qu’on rajoute quelque chose sur la carte, il est recommandé de rafraîchir la vue :               

// redessiner la carte mMap.invalidate();

Ça marche sans cela dans la plupart des cas, mais y penser s’il y a un problème.

Un marqueur est représenté par un Marker :                                                                                              

Marker mrkIUT = _newMarker(mMap);

GeoPoint gpIUT = _newGeoPoint(48.75792, -3.4520072); mrkIUT.setPosition(gpIUT);

mrkIUT.setSnippet("Département INFO, IUT de Lannion"); mrkIUT.setAlpha(0.75f);

mrkIUT.setAnchor(Marker.ANCHOR_CENTER, Marker.ANCHOR_BOTTOM); mMap.getOverlays().add(mrkIUT);

•   snippet est une description succincte du marqueur,

•   alpha est la transparence : 1.0=opaque, 0.0=invisible,

•   anchor désigne le hot point de l’image, le pixel à aligner avec la position.

Pour changer l’image par défaut (une main dans une poire), il vous suffit de placer une image png dans res/drawable. Puis charger cette image et l’attribuer au marqueur : 

Drawable fleche = getResources().getDrawable(R.drawable.fleche); mrkIUT.setIcon(fleche); mrkIUT.setAnchor(Marker.ANCHOR_RIGHT, Marker.ANCHOR_BOTTOM);

Voir la figure 50, page 147.

Figure 50: Marqueur personnalisé

On peut définir un écouteur pour les clics sur le marqueur :                                                                      

Ici, je fais afficher le snippet du marqueur dans un Toast.

Il est très facile de dessiner un itinéraire sur OSM. On donne le GeoPoint de départ et celui d’arrivée dans une liste, éventuellement des étapes intermédiaires :

Seul problème : faire cela dans un AsyncTask ! (voir le TP7)

Un dernier problème : comment lire les coordonnées fournies par le récepteur GPS ? Il faut faire appel au LocationManager. Ses méthodes retournent les coordonnées géographiques.

NB: ça ne marche qu’en plein air (réception GPS). Consulter aussi cette page à propos de l’utilisation du GPS et des réseaux.

Si on veut suivre et afficher les mouvements :                                                                                            

On peut utiliser la localisation par Wifi, mettre NETWORK_PROVIDER.

Le dernier paramètre est un écouteur, ici this. Il doit implémenter les méthodes de l’interface LocationListener dont :         

Pour tester une application basée sur le GPS sans se déplacer physiquement, il y a moyen d’envoyer de fausses positions avec Android Studio.

Il faut afficher la fenêtre Android Device Monitor par le menu Tools, item Android. Dans l’onglet Emulator, il y a un panneau pour définir la position de l’AVD, soit fixe, soit à l’aide d’un fichier GPX provenant d’un récepteur GPS de randonnée par exemple.

Cette fenêtre est également accessible avec le bouton en bas du panneau des outils de l’AVD.

C’est le seul point un peu complexe. Il faut sous-classer la classe Overlay afin de récupérer les touchers de l’écran. On doit seulement intercepter les clics longs pour ne pas gêner les mouvements sur la carte. Voici le début :

Pour installer ce mécanisme, il faut rajouter ceci dans onCreate :

mMap.getOverlays().add(new LongPressMapOverlay());

Le cœur de la classe traite les clics longs en convertissant les coordonnées du clic en coordonnées géographiques :         

Par exemple, elle crée ou déplace un marqueur.

Pour finir, Il faut autoriser plusieurs choses dans le Manifeste : accès au GPS et au réseau, et écriture sur la carte mémoire :           

Semaine 8

Capteurs

Le cours de cette semaine est consacré aux capteurs des smartphones, et en particulier à leur application à la réalité augmentée

Cela consiste à ajouter des informations à ce qu’on perçoit autour de nous : afficher des mesures sur un écran invisible, ajouter des sons positionnés en 3D autour de nous, etc.

Figure 51: Affichage tête haute

Il ne faut pas confondre réalité augmentée et réalité virtuelle. Cette dernière consiste à simuler un environnement 3D ; ce qu’on voit n’existe pas ou est re-créé de toutes pièces.

•   Aide à la conduite de véhicules : avions, voitures, etc.

•   Médecine : assistance à la chirurgie

•   Tourisme : informations sur les lieux de visites, traduction

•   Architecture : visualiser un futur bâtiment, visualiser les risques en cas de tremblement de terre

•   Ateliers, usines : aider au montage de mécanismes complexes

•   Cinéma : simuler des décors coûteux ou imaginaires

•   Visioconférences : rendre visibles les participants à distance

•   Loisirs : jeux, arts, astronomie

Dessiner par dessus la vue réelle implique d’avoir :

•   un écran transparent ou un couple écran-caméra reproduisant la réalité visible derrière,

•   un capteur de position et d’orientation 3D,

•   un système de dessin capable de gérer des positions dans l’espace.

Le logiciel calcule les coordonnées 3D exactes de l’écran et des dessins, afin de les superposer avec précision sur la vue réelle.

Ce sont les mêmes types de calculs qu’en synthèse d’images 3D, mais inversés : au lieu de simuler une caméra, on doit retrouver ses caractéristiques (matrices de transformation), et ensuite dans les deux cas, on dessine des éléments 3D utilisant ces matrices.

Les tablettes et téléphone contiennent tout ce qu’il faut pour une première approche. Les capteurs ne sont pas très précis et l’écran est tout petit, mais ça suffit pour se faire une idée et développer de petites applications.

La suite de ce cours présente les capteurs et la caméra, puis leur assemblage, mais avant cela, il faut se pencher sur le mécanisme des permissions, afin d’avoir le droit d’utiliser les capteurs.

Certaines actions logicielles sont liées à des permissions. Ex : accès au réseau, utilisation de la caméra, enregistrement de fichiers, etc.

Dans les premières versions d’Android, les applications devaient spécifier toutes les demandes d’autorisations dans le fichier manifest. Ces demandes étaient examinées lors de l’installation de l’application. Elles devaient être intégralement acceptées par l’utilisateur, ou alors l’application entière n’était pas installée.

Depuis l’API 23, les permissions sont demandées au moment où elles sont nécessaires. L’utilisateur peut les accepter ou les refuser. Dans le cas de refus, l’application peut, si elle est programmée correctement, partiellement continuer à fonctionner.

Les droits demandés par une application sont nommés à l’aide d’une chaîne, par exemple "android.permission.CAMERA". Ils doivent être déclarés dans le à l’aide d’une balise <uses-permission android:name="permission"/>.

Certains dispositifs demandent des droits plus fins. C’est le cas de la caméra. Cela fait rajouter d’autres éléments :      

<_{uses-permission}android:name="android.permission.CAMERA"/>

<_uses-featureandroid:name="android.hardware.camera"/>

<_uses-featureandroid:name="android.hardware.camera.autofocus"/>

À partir de Android 6 Marshmallow, API 23, les permissions ne sont plus vérifiées seulement au moment d’installer une application, mais en permanence. Et d’autre part, l’utilisateur est maintenant relativement libre d’en accepter certaines et d’en refuser d’autres.

Certaines permissions sont automatiquement accordées si on décide d’installer l’application, mais d’autres qui concernent la vie privée des utilisateurs (carnet d’adresse, réseau, caméra, etc.) font l’objet d’un contrôle permanent du système Android. Une application qui n’a pas une autorisation ne peut pas utiliser le dispositif concerné, et se fait interrompre par une exception (plantage si pas prévu).

Cela impose de programmer des tests à chaque opération concernant un dispositif soumis à autorisation.

Au plus simple, ça donne ceci :                                                                                                                     

L’activité this regarde simplement si elle peut utiliser la caméra. La réponse est oui (PERMISSION_GRANTED) ou non.

L’exemple précédent se contentait de tester l’autorisation. Ce qui est plus intéressant, c’est de demander à l’utilisateur de bien vouloir autoriser l’application à utiliser la caméra. Android va afficher un dialogue :

Voir la figure 52, page 153.

L’utilisateur est libre d’accepter ou de refuser. S’il refuse, checkSelfPermission ne renverra jamais plus PERMISSION_GRANTED (sauf si on insiste, cf plus loin).

Figure 52: Demande de droit

Les droits sont stockés dans les préférences de l’application (Applications/application/Autorisations).

Figure 53: Préférences

Ils peuvent être révoqués à tout moment. C’est pour cette raison que les applications doivent tester leurs droits en permanence.

C’est en deux temps :

1.    l’activité émet une demande qui fait apparaître un dialogue :

// l'activité n'a pas encore le droit mais fait une demande requestPermissions(_newString[] {Manifest.permission.CAMERA}, );

2.    Lorsque l’utilisateur a répondu, Android appelle cet écouteur :

On doit appeler la méthode requestPermissions en fournissant un tableau de chaînes contenant les permissions demandées, ainsi qu’un entier requestCode permettant d’identifier la requête. Cet entier sera transmis en premier paramètre de l’écouteur.

requestPermissions(String[] permissions, int requestCode)

L’écouteur reçoit le code fourni à requestPermissions, les permissions demandées et les réponses accordées :

En fait, si on rajoute les tests simples de droits devant chaque appel sensible, on n’a rien à programmer dans l’écouteur.

Android a ajouté une sophistication supplémentaire : une application qui demande un droit et qui se le voit refuser peut afficher une explication pour essayer de convaincre l’utilisateur d’accorder le droit. Quand on constate qu’un droit manque, il faut tester shouldShowRequestPermissionRationale(String permission). Si elle retourne true, alors il faut construire un dialogue d’information pour expliquer les raisons à l’utilisateur, puis retenter un requestPermissions.

Les tablettes et smartphones sont généralement équipés d’un capteur GPS.

Figure 54: GPS

La position sur le globe peut être déterminée par triangulation, c’est à dire la mesure des longueurs des côtés du polyèdre partant du capteur et allant vers trois ou quatre satellites de position connue. Les distances sont estimées en comparant des horloges extrêmement précises (1µs de décalage = 300m d’écart).

À défaut d’un GPS (droit manquant ou pas de capteur), on peut obtenir une position grossière (coarse en anglais) à l’aide des réseaux de téléphonie ou Wifi.

Dans tous les cas, on fait appel à un singleton Java, un LocationManager qui gère les capteurs de position, appelés «fournisseurs de position» et identifiés par les constantes GPS_PROVIDER et NETWORK_PROVIDER.

Le principe est de s’abonner à des événements, donc de programmer un écouteur pour ces événements. Chaque fois que la position aura changé, l’écouteur sera appelé avec la nouvelle position.

Les positions sont représentées par la classe Location. C’est essentiellement un triplet (longitude, latitude, altitude).

La position étant une information sensible, personnelle, il faut demander la permission à l’utilisateur. C’est l’objet de deux droits :

•   Manifest.permission.ACCESS_FINE_LOCATION pour la position GPS, très précise, donnée par le GPS_PROVIDER,

•   Manifest.permission.ACCESS_COARSE_LOCATION pour la position imprécise du NETWORK_PROVIDER.

Rappel : les mettre dans le manifeste et les tester à chaque demande au gestionnaire.

Une fois les permissions obtenues, l’activité peut récupérer le gestionnaire :                                           

On peut obtenir la position actuelle, ou la dernière connue par :                                                               

Location position = locationManager.getLastKnownLocation(FOURNISSEUR);

• FOURNISSEUR vaut LocationManager.GPS_PROVIDER ou LocationManager.NETWORK_PROVIDER.

Le résultat est une instance de Location dont on peut utiliser les getters :                                                

float lat = location.getLatitude(); float lon = location.getLongitude(); float alt = location.getAltitude();

Pour l’abonner aux événements :                                                                                                                

•   PERIODICITE donne le temps en millisecondes entre deux événements, mettre 2000 pour toutes les 2 secondes.

•   DISTANCE donne la distance minimale en mètres qu’il faut parcourir pour faire émettre des événements.

•   this ou un écouteur qui implémente les quatre méthodes de LocationListener.

Appeler locationManager.removeUpdates(this); pour cesser de recevoir des événements.

La méthode la plus importante est onLocationChanged(Location location). Son paramètre est la position actuelle détectée par les capteurs. Par exemple :

@Override

public void onLocationChanged(Location location)

{ tvPosition.setText(String.format(Locale.FRANCE, "lon: %.6f\nlat: %.6f\naltitude: %.1f", location.getLongitude(), location.getLatitude(), location.getAltitude()));

}

Les autres méthodes sont onStatusChanged, onProviderEnabled et onProviderDisabled qui peuvent rester vides.

Normalement, une activité ne doit demander des positions que lorsqu’elle est active. Quand elle n’est plus visible, elle doit cesser de demander des positions :    

La quasi totalité des smartphones possède au moins une caméra capable d’afficher en permanence un flot d’images prises à l’instant (live display en anglais). Cette caméra est dirigée vers l’arrière de l’écran. On ne se servira pas de la caméra dirigée vers l’avant.

La direction de la caméra est représentée par une constante, ex: Camera.CameraInfo.CAMERA_FACING_BACK.

Comme pour la position, l’utilisation de la caméra est soumise à autorisations. Voir le début de ce cours. Elles sont à tester à chaque phase du travail.

NB: on va utiliser une API dépréciée, car elle fournit des méthodes utiles pour la réalité virtuelle qui ne sont pas dans la nouvelle.

Pour commencer, il faut une vue spécialisée dans l’affichage d’un flot d’images. Cette vue 2D est d’un type spécial, évoqué dans le cours précédent, un SurfaceView, voir ce tutoriel. C’est une vue associée à une Surface : un mécanisme matériel pour produire des images, ex: caméra ou OpenGL, voir cette documentation pour comprendre l’architecture.

Donc, le layout de l’activité contient :                                                                                                          

<SurfaceView android:id="@+id/surface_view" android:layout_width="match_parent" android:layout_height="match_parent" _/>

Il faut fournir un écouteur à cette vue, via une classe SurfaceHolder dont on appelle la méthode ‘addCallback :

La méthode addCallback indique que this va réagir aux événements de la SurfaceView (écouteur à 3 méthodes).

Il faut programmer trois méthodes :

•   surfaceCreated : ouvrir la caméra

•   surfaceChanged : paramétrer la dimension de l’écran

•   surfaceDestroyed : libérer la caméra

D’autre part, il faut gérer les événements de l’activité :

•   onResume : démarrer l’affichage de la vue caméra

•   onPause : mettre l’affichage de la caméra en pause

NB: chacune de ces méthodes devra tester les permissions.

La caméra est représentée par une instance de Camera (package android.hardware.Camera, attention il y a un autre package android.graphics.Camera) :

Avant de commencer à afficher les images, il faut modifier le paramètre de l’autofocus :                        

Il n’y a pas besoin d’autre chose (reconnaissance faciale, zoom, etc.) pour la réalité augmentée.

Cet écouteur est appelé pour indiquer la taille de la SurfaceView. On s’en sert pour configurer la taille des images générées par la caméra. Il faut demander à la caméra ce qu’elle sait faire comme prévisualisations, et on doit choisir parmi cette liste :         

Voici un extrait de getOptimalPreviewSize :                                                                                                 

Il parcourt toutes les resolutions d’affichage et choisit celle qui est proche de la taille de l’écran.

Un autre réglage doit être fait dans la méthode surfaceChanged : prendre en compte l’orientation de l’écran, afin de faire pivoter la caméra également. 

Pour simplifier, on fait pivoter la caméra si son angle n’est pas celui de l’écran :                                      

Remarquez l’emploi de getCameraInfo, notamment son second paramètre. On sent que ce n’est pas tout à fait du Java derrière.

Il suffit de traduire un identifiant en valeur d’angle :                                                                                  

Cette méthode sert également pour construire le bon changement de repère en réalité augmentée.

Enfin, il reste à activer l’affichage des images :                                                                                            

Cette méthode est appelée quand l’activité est prête à fonctionner. Elle demande à la caméra d’afficher les images :

Inversement, onPause est appelé quand l’activité est recouverte par une autre, temporairement ou définitivement. Il faut juste arrêter la prévisualisation :      

Si l’activité revient au premier plan, le système Android appellera onResume. Ces deux fonctions forment une paire. Il en est de même avec le couple surfaceCreated et surfaceDestroyed.

Son travail consiste à fermer la caméra, au contraire de surfaceCreated qui l’ouvrait :                            

Il est préférable de confier la gestion de la caméra à une autre classe, implémentant ces 5 écouteurs. Cela évite de trop charger l’activité. L’activité se contente de relayer les écouteurs onPause et onResume vers cette classe.

Idem pour onPause.

On arrive à une catégorie de dispositifs assez disparates, intéressants mais parfois difficiles à utiliser : accéléromètre, altimètre, cardiofréquencemètre, thermomètre, etc.

Il faut savoir qu’un smartphone n’est pas un instrument de mesure précis et étalonné. Les valeurs sont assez approximatives (et parfois décevantes, il faut bien l’avouer).

On s’intéresse aux capteurs qui indiquent l’orientation, c’est à dire une information sur la direction dans laquelle est orientée la tablette par rapport au nord. Ça peut être un vecteur 3D orienté comme la face supérieure de l’écran, un triplet d’angles, une matrice de rotation ou un quaternion.

L’information d’apparence la plus simple est un triplet d’angles (cap, tangage, roulis) :

Voir la figure 55, page 163.

•   cap ou azimut (azimuth en anglais) = angle à plat donnant la direction par rapport au nord,

Figure 55: Angles d’Euler

•   tangage (pitch) = angle de bascule avant/arrière,

•   roulis (roll) = angle d’inclinaison latérale.

Le problème de ces angles est le blocage de Cardan : quand le tangage vaut 90°, que signifie le cap ?

Une matrice représente un changement de repère. Elle permet de calculer les coordonnées d’un point ou d’un vecteur qui sont exprimées dans un repère de départ, les obtenir dans un autre repère qui est transformé par rapport à celui de départ.

Le calcul des coordonnées d’arrivée se fait à l’aide d’un produit entre la matrice et les coordonnées de départ. Android offre tout ce qu’il faut pour manipuler les matrices dans le package android.opengl.Matrix (faite pour OpenGL) et on n’a jamais à construire une matrice nous-même.

Une matrice est le meilleur moyen de représenter une rotation, il n’y a pas de blocage de Cardan, mais ça semble rebutant d’y faire appel.

Voyons d’abord comment récupérer des mesures, puis comment les utiliser.

Comme pour la position GPS, l’activité doit s’adresser à un gestionnaire :                                                

Il n’y a aucune permission à demander pour les capteurs. Ils ne fournissent pas des informations jugées sensibles.

Chaque capteur est représenté par une instance de Sensor et il y en a de plusieurs types identifiés par un symbole, comme TYPE_ROTATION_VECTOR, TYPE_ACCELEROMETER, TYPE_MAGNETIC_FIELD. Il est possible d’ouvrir plusieurs capteurs en même temps :

Il manque des tests pour savoir si certains sont null.

Comme pour les positions, on demande au gestionnaire de nous prévenir à chaque fois qu’une mesure est faite :      

Le troisième paramètre est un code indiquant la périodicité souhaitée (très fréquente ou moins).

L’abonnement implique la programmation d’un écouteur :                                                                       

Les données event.values sont un tableau de float qui dépend du capteur. Il y a un calcul spécifique et la documentation n’est pas toujours assez précise.

La plupart des capteurs fournissent une information bruitée : les mesures oscillent aléatoirement autour d’une moyenne. Il faut filtrer les valeurs brutes de event.values à l’aide d’un algorithme mathématique : un filtre passe-bas.

Cela consiste à calculer V_ok = ? ? V_brute + (1 ? ?) ? V_ok avec ? étant un coefficient assez petit, entre

0.01 et 0.2 par exemple, à choisir en fonction du capteur, de la vitesse d’échantillonnage et de la volonté d’amortissement voulu.

Cette formule mélange la valeur brute du capteur avec la valeur précédemment mesurée. Si ? est très petit, l’amortissement est très lent mais la valeur est stable. Inversement si ? est assez grand, l’amortissement est faible, la valeur peut encore osciller, mais c’est davantage réactif.

Le filtrage se fait facilement avec une petite méthode :                                                                             

Le calcul a été programmé pour optimiser les calculs.

Voici comment on utilise cette méthode :

private float[] gravity = _newfloat[3]; lowPass(0.05f, event.values, gravity);

C’est le meilleur capteur pour fournir l’information d’orientation nécessaire pour la réalité augmentée. Il permet de calculer la matrice de transformation en un seul appel de fonction. Nous en avons besoin pour calculer les coordonnées écran de points qui sont dans le monde 3D réel et pivotés à cause des mouvements de l’écran.           

La variable rotationMatrix est une matrice 4x4. Elle représente la rotation à appliquer sur un point 3D pour l’amener dans le repère du smartphone, donc exactement ce qu’il nous faut.

Le capteur de rotation est le plus précis et celui qui donne la meilleure indication de l’orientation du smartphone. Hélas, tous n’ont pas ce capteur. Ce n’est pas une question de version d’Android, mais d’équipement électronique interne (prix).

Quand ce capteur n’est pas disponible, Android propose d’utiliser deux autres capteurs : l’accéléromètre TYPE_ACCELEROMETER et le capteur de champ magnétique terrestre (une boussole 3D) TYPE_MAGNETIC_FIELD.

L’accéléromètre mesure les accélérations 3D auxquelles est soumis le capteur. La pesanteur est l’une de ces accélérations, et elle est constante. Si on arrive à filtrer les mesures avec un filtre passe-bas, on verra où est le bas ; c’est la direction de l’accélération de 9.81m.s^?2.

La boussole nous donne une autre direction 3D, celle du nord relativement au smartphone. En effet, le capteur géomagnétique est capable d’indiquer l’intensité du champ magnétique dans toutes les directions autour du smartphone.

Android propose même une méthode pour lier l’accélération et le champ magnétique, et en déduire l’orientation 3D du téléphone. Il faut mémoriser les valeurs fournies par chacun des deux capteurs, après filtrage.

private float[] gravity = _newfloat[3]; private float[] geomagnetic = _newfloat[3];

Ensuite, dans onSensorChanged :                                                                                                                

Quand, enfin, aucun de ces précédents capteurs n’est disponibles, on peut tenter d’utiliser le plus ancien, mais aussi le plus imprécis, un capteur d’orientation. Les valeurs qu’il fournit sont des angles d’Euler, et voici comment les combiner pour obtenir une matrice de rotation :

On voudrait visualiser des points d’intérêt (Point(s) Of Interest, POI en anglais) superposés en temps réel et en 3D sur l’image de la caméra. mettre une copie écran, mais de préférence avec un joli fond faire une photo devant Open ?

Il faut assembler plusieurs techniques :

•   la caméra nous fournit l’image de fond.

•   Une vue est superposée pour dessiner les icônes et textes des POIs. C’est une vue de dessin 2D comme dans le cours précédent.

•   Le GPS donne la position sur le globe terrestre permettant d’obtenir la direction relative des POIs.

•   Le capteur d’orientation permet de déterminer la position écran des POIs, s’ils sont visibles.

Le lien entre les trois derniers points se fait avec une matrice de transformation. Le but est de transformer des coordonnées 3D absolues (sur le globe terrestre) en coordonnées 2D de pixels sur l’écran.

Ce sont des mathématiques assez complexes, les mêmes que pour définir une caméra avec OpenGL :

•   Déterminer l’orientation 3D du smartphone sous forme d’une matrice : R₁, elle vient du capteur d’orientation.

•   Déterminer la rotation de l’écran du smarphone (s’il est en portrait ou paysage, la visualisation est renversée), c’est également une rotation : R₂, elle vient de la caméra.

•   Déterminer le champ de vision de la caméra, c’est une projection en perspective : P, elle vient de la caméra.

Les points 3D sont à transformer par : P ⁰ = M ? P avec M = P ? R₂? R₁. Le point P ⁰ peut être dessiné sur l’écran si ses 3 coordonnées sont entre -1 et +1 (en fait, c’est un peu plus complexe car ce sont des coordonnées homogènes).

Pour cela, il faut connaître les coordonnées P du POI à dessiner. On dispose de ses coordonnées géographiques, longitude, latitude et altitude.

Il existe un repère global 3D attaché à la Terre. On l’appelle earth-centered, earth-fixed. C’est un repère dont l’origine est le centre de la Terre, l’axe X passe par l’équateur et le méridien de Greenwich, l’axe Y est 90° à l’est.

Connaissant le rayon de la Terre, et son excentricité (elle est aplatie), on peut transformer tout point géographique en point 3D ECEF. Le calcul est complexe, hors de propos ici, voir cette page.

On n’a pas encore tué la bête : les coordonnées ECEF ne sont pas utilisables directement pour notre application, en effet, la rotation R₁ est relative au point où nous nous trouvons en particulier à la direction du nord et de l’est locale, et surtout à l’orientation du smartphone.

Il faut encore transformer les coordonnées ECEF dans un repère local appelé ENU (East, North, Up). C’est un repère 3D lié à l’emplacement local, voir ce lien.

L’algorithme devient :

•   Transformer la position du smartphone dans le repère ECEF,

•   Transformer la position du POI dans le repère ECEF,

•   Calculer les coordonnées relatives ENU du POI par rapport au smartphone, c’est P à multiplier par M.

Il reste à dessiner un bitmap et écrire le nom du POI sur l’écran, à l’emplacement désigné par P ⁰.

La projection fournit des coordonnées entre -1 et +1 qu’il faut modifier selon le système de coordonnées de l’écran. Le coin (0,0) est en haut et à gauche. Il faut tenir compte de la largeur et la hauteur de l’écran.

Le tout est assez difficile à mettre au point et demande beaucoup de rigueur dans les calculs.

C’est fini, nous avons étudié tout ce qu’il était raisonnable de faire en 8 semaines.

---