Intentions, récepteurs d’événements et services

Introduction

Ce chapitre aborde trois notions étroitement liées : les intentions, les récepteurs d’événement et les services.

Les intentions ont déjà été utilisées dans les chapitres précédents, notamment pour lancer une activité ou pour préciser une action. La première section expose en détail le fonctionnement des intentions ainsi que les notions de filtre d’intention et d’intention en attente.

Ensuite, nous verrons comment les récepteurs d’événements s’appuient sur la notion d’intention et de filtre d’intention pour permettre aux applications de s’intégrer au système.

La dernière section, enfin, présente les services, briques applicatives ne possédant pas d’interface graphique.

Intention

L’une des grandes forces d’Android est de permettre de ne pas lier statiquement les composants applicatifs les uns aux autres et de les rendre de ce fait les plus indépendants possible. Ce principe est poussé si loin qu’il permet même d’utiliser des composants applicatifs d’une application depuis une autre application sans les connaître lors de l’écriture du code. Ils seront choisis lors de l’exécution de l’application, soit par le système, soit par l’utilisateur.

Pour pouvoir réaliser cela et faire communiquer dynamiquement ces composants entre eux, Android fournit les objets de type Intent (intention). Comme son nom l’indique, une intention désigne une action à réaliser. Mais une intention peut également décrire un événement qui vient de se produire, comme c’est le cas pour les récepteurs d’événements, abordés dans la section suivante.

Il faut distinguer deux types d’intentions, selon que la classe qui doit réaliser l’action est connue ou pas. Lorsque la classe est réputée connue par le développeur, l’intention est qualifiée d’intention explicite. Dans le cas contraire, lorsque le développeur précise uniquement l’action à réaliser, l’intention est définie comme étant une intention implicite.

1. Intention explicite

Une intention explicite désigne précisément le composant cible auquel elle est destinée. De fait, elle choisit aussi l’action à réaliser. L’intention peut également contenir explicitement l’action à réaliser, dans le cas où le composant peut en réaliser plusieurs.

Un des usages les plus courants des intentions explicites est le lancement de composants applicatifs, notamment d’activités, à l’intérieur d’une même application.

Le composant destinataire est recherché parmi les composants déclarés dans le manifeste. En conséquence, si le composant n’apparaît pas dans le fichier, il ne pourra pas être invoqué.

Concrètement, pour créer une intention explicite, il faut créer un objet de type Intent et lui fournir...

Récepteur d’événements

Un récepteur d’événements est un composant applicatif indépendant dont le rôle consiste uniquement à réceptionner des événements et à les traiter comme il l’entend.

À l’instar d’un service, un récepteur d’événements ne possède pas d’interface graphique. Lorsqu’il reçoit un message et souhaite en informer l’utilisateur, il peut, par exemple, utiliser la barre de notifications ou lancer une activité.

Comme pour l’activité et le service, l’exécution d’un récepteur d’événements s’opère dans le thread principal du processus de l’application dont il fait partie.

Un récepteur d’événements ne doit donc pas bloquer le thread principal plus de dix secondes (cf. chapitre Concurrence, sécurité et réseau - Programmation concurrente).

Pour définir un récepteur d’événements, il faut créer une classe qui hérite de la classe BroadcastReceiver et implémenter uniquement la méthode onReceive. Il faut ensuite spécifier quels sont les événements auxquels le récepteur d’événements doit réagir.

Syntaxe

@Override 
   public void onReceive(Context context, Intent intent)

Exemple

BroadcastReceiver monBroadcastReceiver = new BroadcastReceiver() {
   @Override 
   public void onReceive(Context context, Intent intent) {  
 
   }  
};

1. Événement

Les événements sont produits soit par le système, soit par les applications elles-mêmes. Ils sont envoyés à destination de tous les récepteurs d’événements filtrant l’événement donné.

Concrètement, ces événements sont des objets de type Intent désignant l’action qui vient d’être réalisée ou l’événement...

Service

Un service est un composant applicatif indépendant qui ne possède pas d’interface graphique et qui s’exécute en arrière-plan. Comme son nom l’indique, ce composant applicatif peut représenter un service, au premier sens du terme. Celui-ci peut être proposé à l’application qui le contient et/ou à d’autres applications.

Un service fournit une interface permettant aux autres composants applicatifs de communiquer avec lui.

Pour définir un service, il faut créer une classe qui hérite de la classe Service et implémenter la méthode abstraite onBind.

Comme pour l’activité, l’exécution d’un service s’opère dans le thread principal du processus de l’application dont il fait partie.

Un service ne s’exécute pas dans un processus séparé, ni dans un thread concurrent du thread principal. Il ne doit donc pas bloquer le thread principal plus de dix secondes, tout comme pour une activité. Dans le cas de traitements longs, le service peut créer un thread concurrent pour cela (cf. chapitre Concurrence, sécurité et réseau - Programmation concurrente). Ou, pour plus de commodité, le service peut hériter de la classe IntentService qui facilite la gestion de traitements asynchrones.

Il est possible d’utiliser un service de multiples façons : soit directement, soit en établissant une connexion avec lui, soit en combinant ces deux modes.

1. Déclaration

Pour être utilisé, un service doit être déclaré au système dans le manifeste via la balise service.