BroadcastReceiver : pourquoi avoir fait une classe pour ça ?

[Pierre87]

Je viens de découvrir la classe BrodcastReceiver (pour la découverte de périphériques bluetooth)

La seule méthode intéressante est onReceive (qui est abstract)

Pourquoi avoir fait une classe pour ça, alors qu'une simple interface aurait très bien pu faire l'affaire ???

Là j'avoue que j'ai un peu de mal à suivre le raisonnement des devs Android ...

Je trouve que ça s'éloigne pas mal de la philosophie Java...

[popolbx]

matte le source. ... ^^

je pense que le broadcast a une vie agitee dans le systeme est doit etre Parcelable, voir Bindable,et du coup c mort pour une interface.

[xma]

Je te mets +1 popolbx.

Par contre c'est quoi la philo java ? :D

[Pierre87]

@popolbx : ok, la classe (et le système qui va avec) a été conçue "comme ça"

donc on ne peut pas (plus) avoir une simple interface pour recevoir des broadcasts

je pense qu'il aurait été plus judicieux de penser l'architecture autrement ...

@xma : typiquement, ça aurait été de faire (dans ce cas) une interface pour les BroadcastReceiver,

au lieu de créer une nouvelle classe héritant de BroadcastReceiver,

dont on doit obligatoirement implémenter la méthode onReceive

Dans mon cas, ça m'aurait été utile :

j'aurais fait en sorte que mon Activity implements BroadcastReceiverInterface,

(au lieu de faire une inner class)

[Nivek]

Sinon, sans faire de classe interne, ton BroadcastReceiver peut simplement servir à lancer ton Activity avec les bons paramètres, sans que tu aies besoin de toucher au code de l'activity...

Chacun voit une "bonne" architecture à sa façon.

Je pense que si une simple interface avait été utilisée, il aurait fallu coder à la main et à chaque fois de la même façon le fait de s'enregister auprès du système pour recevoir les broadcasts.

D'une manière générale, j'aurais tout de même tendance à faire confiance aux architectes d'Android qui ont l'air de connaitre leur sujet et ont dû parfois faire des compromis... entre efficacité, simplicité pour les développeurs et "beauté" de l'architecture.

(ce qui n'empêche qu'ils peuvent pafois partir dans une mauvaise direction, mais bon...)

Modifié 4 avril 2010 par Nivek

[Pierre87]

@Nivek : je suis un peu obligé de faire une classe interne :P

Je fais une Activity qui lance la détection de devices bluetooth

Comme c'est asynchrone, je suis obligé d'avoir un BroadcastReceiver

Et ça aurait été sympa que mon Activity puisse implémenter une interface qui lui permette de recevoir directement les Broadcast ^^

De ce que j'ai vu de l'utilisation de BroadcastReceiver :

- c'est une classe abstract

- il est nécessaire d'implémenter onReceive()

- "d'après moi", on aurait pu se passer des autres méthodes, en utilisant l'Intent de onReceive. En effet, toutes les méthodes semblent interagir avec le dernier Intent reçu

Et donc on aurait pu en faire une interface :P

Enfin bon...

Ca ne risque pas de changer maintenant ^^

[popolbx]

public abstract class BroadcastReceiver {

public BroadcastReceiver() {

}

....

public IBinder peekService(Context myContext, Intent service) {

IActivityManager am = ActivityManagerNative.getDefault();

IBinder binder = null;

try {

binder = am.peekService(service, service.resolveTypeIfNeeded(

myContext.getContentResolver()));

} catch (RemoteException e) {

}

return binder;

}

c'est à cause de cette méthode que tu ne peux pas avoir une interface.

c'est son point de connection avec l'OS.

Modifié 4 avril 2010 par popolbx

[Pierre87]

ha... ok

même si j'ai un peu de mal à voir ce que ça fait :P

[Pierre87]

question à la con tant qu'on y est :

je viens de voir "intent filter" dans un fichier xml d'une Activity

ça sert à quoi ? :P

ça peut être utile dans mon cas ?

[Nivek]

Résumé rapide de http://developer.android.com/intl/fr/guide/topics/intents/intents-filters.html :

3 systèmes de propagation d'Intents :

- Context.startActivity*() : transmission d'infos à une Activity

- Context.startService()/bindService() : transmission d'infos à un Service

- Context.send*Broadcast() : transmission d'infos à un BroadCastReceiver

Il n'y a pas de chevauchements entre ces 3 systèmes d'envoi de messages : startActivity ne sera jamais transmis à un service ou un receiver, startService ne sera jamais transmis à une Activity ou un reveiver, sendBroadcast ne sera jamais transmis à une activity ou un service.

=> pas de réception de broadcast via les intent-filters d'une Activity.

En revanche, selon http://developer.android.com/intl/fr/reference/android/content/BroadcastReceiver.html tu peux déclarer dans ton manifest un dans lequel tu positionneras tes intent filters. Dans ce cas il ne s'agira pas d'une class interne d'une activity mais d'un composant indépendant. Le doit être déclaré au niveau immédiatement sous .

Cela peut être utile si ton receiver n'a pas besoin en lui-même d'une IHM d'une Activity pour réaliser son travail.

Quelques idées de l'intérêt des BroadcastReceivers vis à vis de ton utilisation :

- un Intent transmis via startActivity provoque généralement un redémarrage de l'activity (sauf si elle est déclarée 'singleTop' mais ce n'est pas forcément non plus ce que tu veux)

- un Intent transmis par broadcast n'a pas forcément vocation à être traité par l'utilisateur. Le mécanisme semble être beaucoup utilisé dans les couches basses du système pour déclencher des traitements lors d'événements bas niveau qui ne sont pas forcément visibles.

- il existe un mode de traitement des broadcasts plus spécifique qui déclenche l'exécution des receivers dans un ordre de priorité, un par un, chacun pouvant transmettre un résultat au suivant ou interrompre la chaine.

Visiblement, il y avait un besoin système de composants applicatifs (donc extensible via des applications tierces) réagissant à des événements en exécutant des tâches unitaires avec éventuellement un ordre bien défini. Le BroadcastReceiver a un cycle de vie très court pour être instancié, exécuté et détruit en utilisant peu de ressources.

Ce qui fait à mon avis que l'interface n'était pas suffisante est la présence des méthodes gérant les ordered broadcast. Il était impératif que les méthodes en question soient finales pour assurer la cohérence du système, leur implémentation se doit donc d'être figée dans une classe abstraite où seul un point d"entrée est donné au développeur d'applications tierces pour coder le traitement qui l'intéresse, à savoir la réaction de SON application à l'événement.

La méthode peekService rapportée par popolbx permet à un receiver de communiquer avec un service pour réaliser des traitements plus longs. Elle fait appel à l'ActivityManager qui est une API système privée. Cet outillage ne pouvait pas non plus être fourni dans une interface.

Une interface n'aurait donc pu répondre qu'au cas le plus simple de tous qui est le traitement d'un broadcast dans une activity... mais visiblement ce n'est qu'une utilisation marginale des broadcasts. Par ailleurs cette interface n'aurait pas pu assurer de façon garantie pour le système le mécanisme des ordered broadcasts.

Au final, on peut se demander si ils n'auraient pas pu définir une interface BroadcastListener, qui ne ferait qu'exécuter un traitement simple en réaction à un broadcast, pour traiter un cas comme le tiens... mais cela aurait compmlexifié inutilement le noyau du système pour juste éviter une classe interne dans une activity... (et tu peux très bien faire une classe externe si cette classe interne te fait mal au coeur)

[Pierre87]

ok, merci pour ton aide !

je n'avais pas encore eu le temps de me pencher sur ces composants (car je n'en avais pas encore besoin)

je vois mieux maintenant pourquoi il y a besoin d'une classe et non d'une interface

je croyais que la transmission de broadcast était similaire à la transmission d'évènement "touch" (où une interface suffit)

mais comme c'est utilisé dans l'OS lui même ...

merci encore pour ces explications !