Is not Dagger 2 pour Android n'est pas le cadre DI, mais glorifié Service Locator?

Question

Par exemple, supposons que mon adaptateur Rest créé avec Retrofit réside dans la classe Application. J'aimerais obtenir à l'intérieur de l'activité, donc j'écrire le code suivant:

public class MainActivity extends Activity { 
    @Inject MyRestAdapter mRestAdapter; 

    @Override 
    public void onCreate(Bundle savedInstanceState) { 
     super.onCreate(savedInstanceState); 
     ((GlobalApplication) getApplication()).getComponent().inject(this); 
    } 
} 

Accordée, il fera le travail. Mais ... En quoi est-ce différent de l'appel de getApplication(), puis explicitement le MyRestAdapter à MainActivity? Oui, Dagger 2 simplifiera la configuration en envoyant automatiquement tout à l'activité, mais vous devez toujours indiquer explicitement d'où vous avez besoin de ces dépendances, et cela, si je comprends bien, va à l'encontre du but de DI. Ai-je raison de dire que Dagger 2 est un "localisateur de services semi-automatique", ou que ce sont les didacticiels qui m'ont induit en erreur et qu'il y a moyen d'injecter des dépendances avec Dagger 2 dans la vue ou l'activité?

Answer 1

Il n'y a pas de "but de DI", mais l'un d'eux est certainement de séparer la configuration de ce qui est requis par les objets configurés. L'idée est que vos objets de niveau supérieur, tels que Activity s dans Android, peuvent demander tous les objets dont ils ont besoin sans se soucier d'où ils viennent, comment ils sont construits, et toute sémantique sur leurs relations. Similaire à la façon dont un Activity ne traite pas le dessin du texte à l'écran (et délègue à la place à TextView [0]), DI aide à empêcher vos objets de connaître trop de choses qui ne sont pas pertinentes à la logique qu'ils doivent exécuter.

L'inhérence dans le "localisateur de services semi-automatique" que vous décrivez est l'analyse statique et la gestion des erreurs. Au fur et à mesure que les applications deviennent plus grandes, il devient encore plus difficile d'obtenir une DI manuelle correcte. Dagger aide à rendre votre code moins sujet aux erreurs (et moins fastidieux à maintenir). Considérez le cas où vous possédez une version interne de votre application pour les employés, dans laquelle vous consignez beaucoup d'informations sur l'utilisation de l'application pour vous assurer que vous pouvez identifier les problèmes éventuels. Dans votre produit actuel, cependant, vous ne voulez pas suivre les informations personnellement identifiables comme cela lorsque ce n'est pas nécessaire. Maintenant, votre MainActivity a besoin d'un AnalyticsLogger - lequel devrait-il avoir? Plus vous avez de cas, plus il est facile pour Dagger d'assembler les choses ensemble que pour vous de le faire vous-même.

[0] qui délègue à un objet Paint

Answer 2

J'ai expérimenté avec Dagger et il semble certainement brouiller les lignes entre le localisateur de services et l'injection de dépendance. C'est au moins vrai lorsqu'il est utilisé avec des activités Android. Avec la version actuelle de Dagger, il est possible d'écrire AndroidInjection.inject(this) dans la méthode onCreate d'une activité. C'est essentiellement comme dire "trouver tous les services dont j'ai besoin et les injecter en moi". So Dagger est une combinaison d'un localisateur de service central/mondial qui sait où obtenir les services et d'un injecteur qui sait où (quelles variables d'instance) mettre ces services dans l'activité. Il semble que les activités Android forcent le recours à une sorte d'objet singleton/global.