Avoir un gestionnaire de délégués est-il une bonne idée de conception?

Question

De nombreuses applications Android incluent leur propre classe BaseActivity, que toutes les activités dans l'application étendent. Cela est utile car cela donne un endroit central pour mettre en place des fonctionnalités communes à la plupart/toutes les activités. Le principal inconvénient d'avoir une BaseActivity est que vous ne pouvez alors pas utiliser les sous-classes d'Activity (ListActivity, etc.).

Une alternative est d'avoir un ActivityDelegate. Cela donne un endroit central pour les fonctionnalités tout en vous permettant d'utiliser les sous-classes d'Activity. C'est aussi vraisemblablement plus testable, car cela utilise la composition plutôt que l'héritage.

Ces deux solutions peuvent potentiellement conduire à beaucoup de code spaghetti lorsque BaseActivity/ActivityDelegate devient trop grand et complexe. Une solution possible à cela est d'utiliser le modèle de délégué, mais de diviser les fonctionnalités en plusieurs délégués différents. Cela réduit le code spaghetti dans les délégués, mais les activités deviennent alors plus compliquées - elles essaient maintenant de faire avancer leurs méthodes on* vers de nombreux délégués différents au lieu d'un seul.

Une solution possible à tous ces problèmes est d'utiliser un Gestionnaire de Délégués. Le Gestionnaire de Délégués garde une trace de tous les petits délégués dans l'application. Les activités font avancer leurs méthodes on* vers le Gestionnaire de Délégués, qui les transmet à tous les délégués individuels. Cela accomplit tout ce qui suit:

• Élimination du code en double - toutes les fonctionnalités communes sont placées dans l'un des délégués
• Permet l'utilisation des sous-classes d'Activity
• Code simple dans toutes les activités - toutes les méthodes on * sont avancées vers une seule classe
• Facilement testable - il est simple de simuler tout ce qui entoure les délégués et le gestionnaire de délégués pour les tests unitaires

Quelqu'un a-t-il déjà essayé d'utiliser ce schéma auparavant? Si c'est le cas, comment cela s'est-il passé?

Answer 1

D'après ce que je comprends, vous parlez d'un seul objet DelegateManager pour toute l'application. Si c'est le cas, vous pouvez utiliser registerActivityLifecycleCallbacks, voir http://developer.android.com/reference/android/app/Application.html#registerActivityLifecycleCallbacks%28android.app.Application.ActivityLifecycleCallbacks%29

Si vous êtes sur un niveau d'API < 14 vous devez jeter un œil à: https://github.com/BoD/android-activitylifecyclecallbacks-compat.

registerActivityLifecycleCallbacks vous permet de vous brancher sur les méthodes de cycle de vie des activités onXXX.

Faire cela a certainement tous les avantages que vous avez décrits :

• le découplage est utile uniquement lorsque vous avez réellement besoin de répéter un comportement, ce qui est assez rare pour la logique contrôleur+vue liée de la manière dont fonctionne une activité.
• La suppression de l'héritage est utile si vous avez des activités que vous pourriez réutiliser - mais je n'ai jamais eu à le faire auparavant. Mais je suppose qu'un bon cas d'utilisation serait une activité personnalisée pour gérer les paramètres ou quelque chose de similaire qui nécessite un aspect et un comportement globaux de l'application.

À première vue, je pense à ces inconvénients :

• L'utilisation de listeners partout peut rendre flou le chemin de hiérarchie d'appel des activités de l'application et rendre le code difficile à comprendre. Cela est vrai pour toute programmation de type listener/dispatcher. C'est un outil puissant, mais manipulez-le avec soin.
• Cela peut introduire beaucoup de code en trop (comme vous le mentionnez) s'il ne sert qu'à passer aux écouteurs/delegates du cycle de vie.
• Il est de votre responsabilité de vous désinscrire de l'Application avec Application.unregisterActivityLifecycleCallbacks. Je ne pense pas qu'il y ait de bonne solution pour éviter cela,

Personnellement, je n'ai pas beaucoup utilisé ce modèle de conception pour les cycles de vie, mais cela peut être utile dans certains cas d'utilisation. Par exemple :

• ApplicationLifecycleLogger : À chaque fois que vous créez/reprenez/met... une activité, vous utilisez logcat ou autre chose pour faciliter un peu le débogage des cycles de vie.
• Si par exemple quelqu'un entre dans une activité à laquelle il/elle n'a pas le droit d'accéder en raison de l'état du modèle de quelque sorte (par exemple, une alarme qui sonne -> impossible d'aller dans AlarmEditActivity), vous pourriez faire finish() ici.
• Transmettre l'état de l'objet à travers les frontières des activités sans Parcelable et sans changements de rotation d'écran. Habituellement, cela est mis en œuvre avec une carte dans l'Application ou un champ statique quelque part. Vous pouvez le faire en laissant les délégués contenir l'état.

Jetez également un œil à : Y a-t-il un modèle de conception pour réduire la duplication de code lors de la sous-classe des activités dans Android ?

J'espère que cela a été utile =)