Nouveau injecteur Android avec Dagger 2 – partie 3

Si vous n’avez pas lu la partie 1 et la partie 2, je vous suggère de les lire d’abord. Vous pouvez trouver les liens en bas de page.

TLDR;

Vous pouvez utiliser DaggerActivity, DaggerFragment, DaggerApplication pour réduire le boilerplate dans votre Activity/Fragment/Application.

Aussi, vous pouvez utiliser AndroidInjector<T> dans vos composants dagger pour réduire boilerplate aussi.

Rappellez-vous que nous appelons AndroidInjection.inject() chaque activité ou fragment que nous voulions utiliser dagger. Et aussi, Si vous voulez utiliser l’injection dans votre fragment, vous devriez également mettre en œuvre l’interface HasSupportFragmentInject et surcharger l’injecteur de fragment dans votre activité.

Récemment, j’ai déplacé ce code vers mon activité de base et mon fragment de base. Pourquoi devrais-je avoir besoin de déclarer cela pour chaque activité unique ? Je pense que les déplacer vers la classe de base est acceptable.

Puis je vois certaines classes dans le projet dagger en faisant des recherches, DaggerAppCompatActivity et DaggerFragment. Ces classes font exactement ce que j’ai fait. Android aime l’héritage. Donc nous pouvons prétendre que nous l’aimons aussi 😛

Voyons ce qui se passe à l’intérieur de ces classes de bibliothèque.

DaggerAppCompatActivity

Rien de différent en fait. Nous pouvons réduire le code boilerplate dans notre activité en étendant notre activité à partir de DaggerAppCompatActivity.

Notre classe DetailActivity était comme suit;

Etendons-la à partir de DaggerAppCompatActivity et supprimons HasSupportFragmentInjector et la méthode surchargée de notre activité.

Maintenant, c’est mieux.

DaggerApplication, AndroidInjector, AndroidSupportInjectionModule

Voyons ce que nous pouvons faire d’autre pour réduire le code boilerplate. AndroidInjector nous aide à simplifier notre composant d’application. Vous pouvez consulter la documentation d’AndroidInjector à partir d’ici.

Voyons notre composant d’application et notre classe d’application.

build() et seedInstance() est déjà défini dans la classe AndroidInjector.Builder. Donc nous pouvons nous en débarrasser et étendre notre Builder à partir de AndroidInjection.Builder<Application>.

Et aussi, l’interface AndroidInjector a la méthode inject() en elle. Donc, nous pouvons supprimer la méthode inject() et étendre notre interface AppComponent à partir de AndroidInjector<Application>

Donc, notre interface AppComponent mise à jour et réduite à la chaudière ressemblera à ce qui suit

Vous avez réalisé que nous avons changé nos modules aussi. J’ai supprimé AndroidInjectionModule.class dans les modules de composants et ajouté AndroidSupportInjectionModule.class. Ceci est ajouté parce que nous avons utilisé le support Fragment. AndroidInjectionModule lie votre app.Fragment à dagger. Mais si vous voulez utiliser l’injection dans v4.fragment alors vous devez ajouter AndroidSupportInjectionModule.class à vos modules AppComponent.

Nous avons changé la façon dont nous injectons dans notre AppComponent. Voyons donc ce qui est changé dans notre classe d’application.

Comme dans la DaggerActivity et le DaggerFragment, nous devons également étendre notre classe d’application à partir de DaggerApplication.

Notre classe Application ressemblait à ce qui suit;

Nous l’avons changé en…

Source

Vous pouvez trouver cette implémentation simplifiée comme une branche dans ma page github. Je ne la fusionne pas dans master car je veux montrer la manière old school d’utiliser dagger dans chaque branche. Ainsi, les lecteurs peuvent suivre un chemin de la manière old-school à la manière simplifiée.

PS.

Leave a Reply