Dagger 2 subcomponentes vs dependencias de componentes

El método Dagger 1’s plus() es algo que utilicé con bastante frecuencia en aplicaciones anteriores, así que entiendo situaciones en las que es posible que desee tener un subcomponente con pleno acceso a los enlaces de gráficos primarios.

¿En qué situación sería beneficioso usar una dependencia de componentes en lugar de una dependencia de subcomponentes y por qué?

Dependencias de componentes: use esto cuando:

  • quieres mantener dos componentes independientes.
  • desea mostrar explícitamente qué dependencias de un componente utiliza el otro

Subcomponentes: use esto cuando:

  • quieres mantener dos componentes cohesivos
  • es posible que no le interese mostrar explícitamente qué dependencias de un componente utiliza el otro

Trataré de mostrar esto por ejemplo. Dado que tenemos los siguientes módulos y clases. SomeClassB1 depende de SomeClassA1 . Observe el método provideSomeClassB1 en el ModuleB que muestra esta dependencia.

 @Module public class ModuleA { @Provides public SomeClassA1 provideSomeClassA1() { return new SomeClassA1(); } } @Module public class ModuleB { @Provides public SomeClassB1 provideSomeClassB1(SomeClassA1 someClassA1) { return new SomeClassB1(someClassA1); } } public class SomeClassA1 { public SomeClassA1() {} } public class SomeClassB1 { private SomeClassA1 someClassA1; public SomeClassB1(SomeClassA1 someClassA1) { this.someClassA1 = someClassA1; } } 

Tenga en cuenta los siguientes puntos en el ejemplo de Dependencia de componentes a continuación:

  • SomeClassB1 depende de SomeClassA1 . ComponentB tiene que definir explícitamente la dependencia.
  • ComponentA no necesita declarar el ModuleB . Esto mantiene los dos componentes independientes.
 public class ComponentDependency { @Component(modules = ModuleA.class) public interface ComponentA { SomeClassA1 someClassA1(); } @Component(modules = ModuleB.class, dependencies = ComponentA.class) public interface ComponentB { SomeClassB1 someClassB1(); } public static void main(String[] args) { ModuleA moduleA = new ModuleA(); ComponentA componentA = DaggerComponentDependency_ComponentA.builder() .moduleA(moduleA) .build(); ModuleB moduleB = new ModuleB(); ComponentB componentB = DaggerComponentDependency_ComponentB.builder() .moduleB(moduleB) .componentA(componentA) .build(); } } 

Tenga en cuenta los siguientes puntos en el ejemplo del Subcomponente:

  • SomeClassB1 depende de SomeClassA1 . ComponentB no necesita definir explícitamente la dependencia.
  • ComponentA tiene que declarar ModuleB . Esto hace que los dos componentes estén acoplados.
 public class SubComponent { @Component(modules = ModuleA.class) public interface ComponentA { ComponentB componentB(ModuleB moduleB); } @Subcomponent(modules = ModuleB.class) public interface ComponentB { SomeClassB1 someClassB1(); } public static void main(String[] args) { ModuleA moduleA = new ModuleA(); ComponentA componentA = DaggerSubComponent_ComponentA.builder() .moduleA(moduleA) .build(); ModuleB moduleB = new ModuleB(); ComponentB componentB = componentA.componentB(moduleB); } } 

De acuerdo con la documentación :

Component Dependency le da acceso solo a los enlaces expuestos como métodos de provisión a través de dependencias de componentes, es decir, usted tiene acceso solo a los tipos que se declaran en el Component principal.

SubComponent le da acceso a todo el gráfico vinculante desde su elemento principal cuando se declara, es decir, tiene acceso a todos los objetos declarados en su Module s.

Digamos que tienes un ApplicationComponent contiene todo lo relacionado con Android ( LocationService , Resources , SharedPreference , etc.). También querrás tener tu DataComponent donde gestiones los aspectos de la persistencia junto con WebService para tratar con las API. Lo único que le falta en DataComponent es Application Context que reside en ApplicationComponent . La forma más sencilla de obtener un Context desde DataComponent sería una dependencia en ApplicationComponent . Debe asegurarse de tener un Context explícitamente declarado en ApplicationComponent porque solo tiene acceso a las cosas declaradas. En este caso, no hay trabajo manual, lo que significa que no necesita especificar Submodules en el Component principal y agregar explícitamente su submódulo a un módulo principal como:

 MySubcomponent mySubcomponent = myComponent.plus(new ChildGraphModule("child!")); // No need! 

Ahora considere el caso en el que desee inyectar WebService desde DataComponent y LocationService desde ApplicationComponent en su Fragment que se enlaza usando la característica @Submodule plus anterior. Lo bueno de esto es que el componente al que está vinculando ( ApplicationComponent ) no necesita exponer WebService ni LocationService porque tiene acceso a todo el gráfico de inmediato.

Otra cosa de la que no me había dado cuenta hasta ahora es que:

  • Una instancia de @Subcomponent tiene exactamente un componente principal (aunque diferentes componentes pueden instanciar ese mismo @Subcomponent y ser el principal de esa instancia)
  • Un @Component puede tener cero, uno o muchos componentes principales declarados a través de dependencias de componentes

Aquí está el ejemplo de código con captura de pantalla para una mejor comprensión de Componente y Subcomponente:

Componente: enter image description here

  1. AppComponent contiene dos declaraciones.
  2. AppComponent se inicializa en la clase de la aplicación.
  3. HomeActivityComponent depende de AppComponent.
  4. En HomeActivity en la inicialización de DaggerHomeActivityComponent, estoy dando el objeto AppComponent como una composición.

Subcomponente:

enter image description here

  1. AppComponent contiene SubComponent o SubComponents.
  2. AppComponent se inicializa en la clase de la aplicación.
  3. SubComponent no sabe acerca de su ParentComponent. Eso solo proporciona sus propias dependencias al incluir el Módulo.
  4. En HomeActivity, estoy inyectando SubComponent usando su Parent Component.

Y el diagtwig pictórico: enter image description here

Fuente: enlace

    Intereting Posts