What is the purpose of the getter methods in Components in Dagger 2?

by

Usage in dependent components

In the context of a hierarchy of dependent components, such as in this example, provision methods such as Foo foo() are for exposing bindings to a dependent component. “Expose” means “make available” or even “publish”. Note that the name of the method itself is actually irrelevant. Some programmers choose to name these methods Foo exposeFoo() to make the method name reflect its purpose.

Explanation:

When you write a component in Dagger 2, you group together modules containing @Provides methods. These @Provides methods can be thought of as “bindings” in that they associate an abstraction (e.g., a type) with a concrete way of resolving that type. With that in mind, the Foo foo() methods make the Component able to expose its binding for Foo to dependent components.

Example:

Let’s say Foo is an application Singleton and we want to use it as a dependency for instances of DependsOnFoo but inside a component with narrower scope. If we write a naive @Provides method inside one of the modules of MyDependentComponent then we will get a new instance. Instead, we can write this:

@PerFragment
@Component(dependencies = {MyComponent.class }
           modules = { MyDependentModule.class })
public class MyDependentComponent {

    void inject(MyFragment frag);

}

And the module:

@Module
public class MyDepedentModule {

    @Provides
    @PerFragment
    DependsOnFoo dependsOnFoo(Foo foo) {
        return new DependsOnFoo(foo);
    }
}

Assume also that the injection site for DependentComponent contains DependsOnFoo:

public class MyFragment extends Fragment {
    
    @Inject DependsOnFoo dependsOnFoo

}

Note that MyDependentComponent only knows about the module MyDependentModule. Through that module, it knows it can provide DependsOnFoo using an instance of Foo, but it doesn’t know how to provide Foo by itself. This happens despite MyDependentComponent being a dependent component of MyComponent. The Foo foo() method in MyComponent allows the dependent component MyDependentComponent to use MyComponent‘s binding for Foo to inject DependsOnFoo. Without this Foo foo() method, the compilation will fail.

Usage to resolve a binding

Let’s say we would like to obtain instances of Foo without having to call inject(this). The Foo foo() method inside the component will allow this much the same way you can call getInstance() with Guice’s Injector or Castle Windsor’s Resolve. The illustration is as below:

public void fooConsumer() {
    DaggerMyComponent component = DaggerMyComponent.builder.build();
    Foo foo = component.foo();
}

More Related Contents:

  1. Dagger @Reusable scope vs @Singleton
  2. Ioc/DI – Why do I have to reference all layers/assemblies in application’s entry point?
  3. Is there a pattern for initializing objects created via a DI container
  4. Why not use an IoC container to resolve dependencies for entities/business objects?
  5. Why do I need an IoC container as opposed to straightforward DI code? [closed]
  6. What is a composition root in the context of dependency injection?
  7. Why does one use dependency injection?
  8. Singleton object becomes null after app is resumed
  9. Dependency Injection vs Factory Pattern
  10. Inversion of Control vs Dependency Injection
  11. Inversion of Control < Dependency Injection [closed]
  12. Dependency injection through constructors or property setters?
  13. Avoiding all DI antipatterns for types requiring asynchronous initialization
  14. How to set up DAGGER dependency injection from scratch in Android project?
  15. When to use PerThreadLifetimeManager?
  16. Comparing Castle Windsor, Unity and StructureMap
  17. When are .NET Core dependency injected instances disposed?
  18. How to extend a component with dependency injection?
  19. Dagger 2 injecting Android Application Context
  20. Meaning of bean discovery mode annotated in CDI 1.1
  21. Property Injection in ASP.NET Core
  22. MEF (Managed Extensibility Framework) vs IoC/DI
  23. ASP.Net Core Call a controller from another controller
  24. When to use Dependency Injection
  25. Passing constructor arguments when using StructureMap
  26. Net Core Dependency Injection for Non-Controller
  27. Resolving HttpControllerContext with Castle Windsor
  28. How do I handle classes with static methods with Ninject?
  29. Windsor castle Injecting properties of constructed object
  30. log4net with DI Simple Injector

Leave a Comment