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
etPaymentSubcomponent
est construit uniquement lorsque l’application accède à la page de paiement limitant sa durée de vie. Il est détruit lorsque lePaymentPage
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.