Quelques notions pour vous familiariser avec la plateforme Android et améliorer les applications que vous y développez. Vous pouvez toujours m’écrire pour des commentaires ou questions ing.josephdavid@gmail.com
2. PLAN
• Les principaux composants Android
• Intent
• View
• Activity
• Service
• ContentProvider
• BroadcastReceiver
• Cycle de vie d’une activité
• Etats d’une activité
3. INTRODUCTION
• Le développement sur Android s’appuie sur des classes importantes du
framework. Ces classes sont, en quelque sorte, les « briques » élémentaires
sur lesquelles vos futures applications reposeront. Elles sont tellement
indispensables qu’il est tout simplement impossible de construire votre
application sans passer par au moins l’une d’elles. Cette partie tente de
décrire de façon globale et succincte ces différentes « briques ».
4. INTENT
• Les Intents sont des objets permettant de faire passer des messages
contenant de l’information entre composants principaux. La notion d’Intent
peut être vue comme une demande de démarrage d’un autre composant,
d’une action à effectuer. La raison d’être des Intents provient du modèle de
sécurité d’Android. Chaque application est en effet sandboxée. Cela veut dire
qu’une application A ne peut accéder aux données d’une application B. Grâce
aux Intents, les applications ont la possibilité de fournir leurs services ou
données si elles le souhaite.
5. VIEW
• Les Views sont les composants de base de l’interface graphique. Elles permettent de
construire l’interface utilisateur. Les widgets (nom donné à des composants graphiques
« avancés » : une barre de progression, par exemple, est un widget), composants graphiques
ou autres layout (composant permettant de placer les différents composants graphiques à
l’écran) héritent en fait de cette classe élémentaire. Le rendu/dessin d’une View s’effectue par
l’intermédiaire d’un Canvas (qu’on peut assimiler à une feuille transparente sur laquelle on
dessine avec un crayon (Paint). Pour finir, la vue est le principal composant qui s’occupe de
gérer les actions utilisateurs (appui sur l’écran, sur le clavier, etc.).
• Lorsqu’on créé une application à l’aide du framework Android, le développeur doit hériter
d’au moins une des 4 classes brièvement décrites dans les diaporamas qui suivent.
• Les vues héritent de la classe View. On les trouve dans le package android.view.View.
6. ACTIVITY
• Le concept d’Activity repose sur la notion d’interaction utilisateur. Une
Activity représente la fenêtre ou tout simplement l’écran qui sera affiché à
l’utilisateur. Elle permet également de gérer des fonctionnalités telles que
l’appui sur la touche [MENU] ou l’affichage de messages d’alerte (Toast). Faites
bien attention à ne pas confondre la notion d’Activity et de View. Il est
évident que faire la différence entre ces deux notions est difficile à ce stade
de compréhension du framework. Rappelez vous que vos premières
réalisations vous permettront de dissocier les deux.
7. SERVICE
• Un Service est en fait un programme tournant en tâche de fond et n’ayant pas
d’interface graphique (ce qui n’est pas réalisable, à l’heure où j’écris ces
lignes, sur iPhone OS). L’exemple commun illustrant au mieux cette notion est
celui du lecteur mp3. Un lecteur mp3 ne nécessite pas, pour la plupart du
temps, d’interface graphique et doit tourner en tâche de fond laissant la
possibilité aux autres applications de travailler/s’exécuter librement.
8. CONTENTPROVIDER
• Les ContentProvider sont, comme l’exprime leurs noms, des gestionnaires de
données. Ils permettent de partager l’information entre applications.
Imaginons une application qui permette de conserver les cartes de visite
virtuelles d’un ensemble de personnes. Ces cartes de visite contiennent
généralement le nom, le prénom et un moyen de contact de la personne. Un
tel programme peut être créé sous forme de ContentProvider ce qui lui
permettra de fournir à d’autres applications présentes sur le système les
informations sur une personne. Une application tierce d’envoi de courriel
peut par exemple interroger ce ContentProvider afin d’obtenir l’adresse
courriel d’un contact.
9. BROADCAST RECEIVER
• Un BroadcastReceiver est une application qui est à « l’écoute » des autres
applications. Ce type d’application tente de répondre aux Intents qui lui sont
adressés. Il ne fait donc rien d’autres que d’être à l’écoute des Intents envoyés
par d’autres composants applicatifs.
10. CYCLE DE VIE D’UNE ACTIVITÉ (ACTIVITY)
• Une activité n'a pas de contrôle direct sur son propre état (et par conséquent
vous non plus en tant que programmeur), il s'agit plutôt d'un cycle rythmé par
les interactions avec le système et d'autres applications. Voici un schéma qui
présente ce que l'on appelle le cycle de vie d'une activité, c'est-à-dire qu'il
indique les étapes que va traverser notre activité pendant sa vie, de sa
naissance à sa mort. Vous verrez que chaque étape du cycle est représentée
par une méthode. Nous verrons comment utiliser ces méthodes en temps
voulu.
13. • Les activités héritent de la classe Activity.
public class MainActivity extends Activity { // instructions; }
• Or, la classe Activity hérite de l'interface Context dont le but est de représenter tous les
composants d'une application. On les trouve dans le package android.app.Activity.
• On surcharge certaines méthodes qui sont appelées par Android pour définir le
comportement (même principe que les applets) :
onCreate: lors de la création
onDestroy: lorsque l’activité se termine
onStart: lorsque l’activité démarre ou redémarre
onPause: lorsque l’activité n’est plus en premier plan
onResume: lorsque l’activité revient en premier plan
onStop: lorsque l’activité n’est plus visible
onRestart: lorsque l’activité redevient visible
15. REMARQUE
• Le petit @Override permet d'indiquer que l'on va redéfinir une méthode qui
existait auparavant dans la classe parente, ce qui est logique puisque vous
saviez déjà qu'une activité avait une méthode void onCreate() et que notre
classe héritait de Activity.
• L'instruction @Override est facultative. Elle permet au compilateur
d'optimiser le bytecode, mais, si elle ne fonctionne pas chez vous, n'insistez
pas, supprimez-la.
16. A NOTER
• Android se réserve le droit de tuer le processus UNIX d’une activité s’il n’y a plus assez de
ressources (mémoire). Les règles sont les suivantes:
1. Une activité en premier plan n’est tuée que si c’est elle qui consomme trop de
ressources.
2. Une activité en arrière plan ou non visible peut être tuée.
• Lorsqu’une activité a été tuée, si on revient dessus elle est relancée (onCreate). On peut
sauvegarder l’état (c’est-à-dire les propriétés) d’une activité (dans onPause) pour le retrouver
lorsqu’elle elle est recréée par le paramètre transmis à onCreate.
17. ETATS D’UNE ACTIVITÉ (ACTIVITY)
• Quand une application se lance, elle se met tout en haut de ce qu'on appelle
la pile d'activités.
• Une pile est une structure de données de type « LIFO », c'est-à-dire qu'il n'est
possible d'avoir accès qu'à un seul élément de la pile, le tout premier
élément, aussi appelé sommet. Quand on ajoute un élément à cette pile, le
nouvel élément prendra la première place et deviendra le nouveau sommet.
Quand on veut récupérer un élément, ce sera le sommet qui sera récupéré,
sorti de la liste et l'objet en deuxième place deviendra le nouveau sommet,
comme illustré à la figure suivante.
18.
19. FONCTIONNEMENT
• L'activité que voit l'utilisateur est celle qui se trouve au-dessus de la pile.
Ainsi, lorsqu'un appel arrive, il se place au sommet de la pile et c'est lui qui
s'affiche à la place de votre application, qui n'est plus qu'à la deuxième place.
Votre activité ne reviendra qu'à partir du moment où toutes les activités qui
se trouvent au-dessus d'elle seront arrêtées et sorties de la pile. On retrouve
ainsi le principe expliqué précédemment, on ne peut avoir qu'une application
visible en même temps sur le terminal, et ce qui est visible est l'interface
graphique de l'activité qui se trouve au sommet de la pile.
20. LES 3 ÉTATS QUI DIFFÉRENCIENT LA VISIBILITÉ D’UNE
ACTIVITÉ (ACTIVITY)