Android Dagger 2 Tirant parti des sous-composants et des étendues

1. Définition des portées

AppScope et PaymentScope sont les deux portées. AppScope signifie la durée de vie de l’application et PaymentScope fait référence à celle de la fonction Paiement. La portée prend un sens lorsqu’elle est associée au composant 👇.

2. Création d’AppComponent

AppComponent est associé à l’AppScope. Il est créé dans le ShoppingApplication classe[Application-level]. Comme il est créé au niveau de l’application, son graphique n’est construit qu’une seule fois lorsque l’application est lancée et est utilisé jusqu’à ce que l’application soit détruite.

Vous trouverez ci-dessous la démonstration de l’utilisation d’AppComponent pour injecter les dépendances de HomePage. La même chose peut être faite pour la page Catégorie et Marque.

3. Création de PaymentComponent

Contrairement à AppComponent qui est créé au niveau de l’application, le composant Paiement est créé au niveau de la fonctionnalité de paiement. Ce composant peut être de 2 types.

• Premièrement les PaymentComponent peut demander des dépendances à un autre composant (AppComponent). Dans ce cas, le PaymentComponent serait un sous-composant de AppComponent.
• Deuxièmement, le PaymentComponent peut être un composant autonome et satisfaire toutes les dépendances par lui-même.

3.1 Lorsque PaymentComponent dépend d’AppComponent

AppComponent et PaymentSubcomponent avoir une relation parent-enfant. Certaines des dépendances requises par l’enfant sont fournies par le parent. Dans ce cas, le composant est défini comme un sous-composant.

@Subcomponent annotation signifie qu’il s’agit d’un composant enfant et qu’il doit être construit pour avoir un composant parent (AppComponent).

UserSession la dépendance nécessaire pour le PaymentSubcomponent doit être fournie par son AppComponent parent.

Remarque: le sous-composant n’a aucune idée de son parent. C’est la responsabilité du ParentComponent d’inclure le sous-composant et de fournir les dépendances nécessaires.

En conséquence, AppComponent doit déclarer qu’il satisfera les dépendances de PaymentSubcomponent. Les modifications ci-dessous sont nécessaires pour que AppComponent agisse en tant que composant parent. Notez qu’il fournit la UserSession nécessaire à son enfant.

Utiliser PaymentSubcomponent pour fournir des dépendances dans PaymentPage👇🏻.

3.2 Lorsque le composant de paiement est indépendant

C’est simple car il satisfait toutes les dépendances lui-même. Déclarez-le en tant que composant normal et créez-le dans la page Paiement.

Dans les deux cas ci-dessus,PaymentSubcomponent(3.1) & PaymentComponent(3.2) sont créés dans la page de paiement et existent jusqu’à ce que l’activité soit détruite. De cette façon, sa portée est limitée uniquement à la durée de vie de la page de paiement.

Conclusion

• AppComponent est créé au niveau de l’application (dans la classe Application). Ainsi, le temps nécessaire pour créer le graphique de l’AppComponent affectera l’heure de démarrage de l’App. Pour de meilleures performances, pensez à initialiser uniquement les enregistreurs, les clients API, Crashltics, Analytics, les sessions utilisateur, etc. au début.
• Notez que le PaymentComponent et PaymentSubcomponent est construit uniquement lorsque l’application accède à la page de paiement limitant sa durée de vie. Il est détruit lorsque le PaymentPage est détruit.
• Désormais, il est conseillé de séparer les dépendances en différents composants plutôt que de tout incorporer dans un seul AppComponent. De cette façon, vous avez la possibilité de contrôler leur durée de vie.

Vous pouvez également consulter Composants dépendants qui est similaire aux sous-composants. Mais inversement, le sous-composant connaît le composant parent et le composant parent n’a aucune idée de ses dépendants. Ceci est utile lorsque vous travaillez avec des modules Dynamic Feature.