Android BroadcastReceiver ou simple méthode de rappel?

C'est une question très intéressante et j'ai rencontré le même problème. À mon avis, les deux mécanismes peuvent être utilisés dans leur ensemble et la bonne approche dépend de votre cas d'utilisation. Voici quelques points à prendre en compte avant de se décider.

L'Utilisation du mécanisme de rappel présente certains avantages, mais il y a aussi des limites:

PRO

• Il est simple et facile à mettre en œuvre.
• vous obtenez type-sécurité entre les composants qui interagissent les uns avec les autres.
• Vous pouvez retourner des objets arbitraires.
• il simplifie les tests car vous n'avez qu'à injecter un appel simulé (par exemple généré par mockito ou quelque chose de similaire) dans les tests unitaires.

CONTRA

• vous devez passer au fil principal afin de faire des manipulations UI.
• vous ne pouvez avoir une relation qu'à 1 contre 1. Une relation de 1 À n (Modèle de l'observateur) n'est pas réalisable sans autre travail. Dans ce cas, je préférerais le mécanisme Observer / Observable D'Android.
• comme vous l'avez déjà dit, vous devez toujours vérifier pour null avant d'invoquer les fonctions de rappel si le rappel peut être facultatif.
• si votre composant doit offrir une sorte D'API de service avec un service différent fonctions et vous ne voulez pas avoir une interface de callback avec seulement quelques fonctions génériques de callback, vous devez décider si vous fournissez une interface de callback spéciale pour chaque fonction de service ou si vous fournissez une interface de callback simple avec beaucoup de fonctions de callback. Dans le dernier cas, tous les clients de callback utilisés pour les appels de service vers votre API doivent implémenter l'interface de callback complète, bien que la majorité des corps de méthode soient vides. Vous pouvez contourner cela en implémenter un talon avec des corps vides et faire hériter votre client callback de ce talon, mais ce n'est pas possible si déjà hériter d'une autre classe de base. Peut-être que vous pouvez utiliser une sorte de rappel par procuration dynamique (voir http://developer.android.com/reference/java/lang/reflect/Proxy.html ), mais alors il devient vraiment complexe et je penserais à utiliser un autre mécanisme.
• le client pour les appels de rappel doit être propagé à travers divers méthodes / composantes si elles ne sont pas directement accessibles à l'appelant du service.

Certains points concernant le BroadcastReceiver -approche:

PRO

• vous réalisez un assemblage lâche entre vos composants.
• vous pouvez avoir une relation 1-À-n (y compris 1-à-0).
• la méthode onReceive() est toujours exécutée sur le filetage principal.
• vous pouvez notifier des composants dans l'ensemble de votre application, de sorte que les composants communicants ne doivent pas" voir " l'un l'autre.

CONTRA

• il s'agit d'une approche très générique, de sorte que la mise en commun et la suppression des données transportées par le Intent est une source d'erreur supplémentaire.
• vous devez rendre les actions de votre Intent uniques (par exemple en préparant le nom du paquet) si vous voulez éliminer les corrélations avec d'autres applications, car leur but original est de faire des diffusions entre les applications.
• vous devez gérer le BroadcastReceiver - enregistrement et non-enregistrement. Si vous voulez le faire d'une manière plus confortable, vous pouvez mettre en œuvre une annotation personnalisée pour annoter votre activité avec les actions qui doivent être enregistrées et mettre en œuvre une classe de base Activity qui fait l'enregistrement et le non-enregistrement avec IntentFilter s dans son onResume() REEE. onPause() méthodes.
• comme vous l'avez déjà dit, les données qui est envoyé avec le Intent doit mettre en œuvre l'interface Parcelable , mais en outre, il ya une limite de taille stricte et il va causer des problèmes de performance si vous transportez une grande quantité de données avec votre Intent . Voir http://code.google.com/p/android/issues/detail?id=5878 pour une discussion à ce sujet. Donc, si vous voulez envoyer des images par exemple, vous devez les stocker temporaire dans un dépôt et envoyer un ID Ou URL correspondant pour accéder à l'image du récepteur de votre Intent qui la supprime du dépôt après utilisation. Cela entraîne d'autres problèmes s'il y a plusieurs récepteurs (quand l'image doit-elle être retirée du dépôt et qui doit le faire?).
• si vous abusez de ce type de mécanisme de notification le flux de contrôle de votre application peut se cacher et lors du débogage vous finissez par dessiner des graphiques avec séquences de Intent s pour comprendre ce qui a déclenché une erreur spécifique ou pourquoi cette chaîne de notification est brisée à un moment donné.

à mon avis, même une application mobile devrait avoir une architecture basée sur au moins 2 couches: la couche UI-layer et la couche core (avec logique d'affaires, etc.). En général, les tâches de longue durée sont exécutées dans un propre thread (peut-être via AsyncTask ou HandlerThread si vous utilisez MessageQueue s) à l'intérieur de la couche principale et L'interface utilisateur devrait être mise à jour une fois cette tâche terminée. En général, avec les callbacks, vous réalisez un couplage serré entre vos composants, donc je préférerais utiliser cette approche seulement à l'intérieur d'une couche et pas pour la communication à travers les limites de la couche. Pour la diffusion de messages entre la couche UI et la couche core, j'utiliserais l'approche BroadcastReceiver qui vous permet de découpler votre couche UI de la couche logique.