Dagger 2, scopes + annotation

Question

I never worked with such a confusing DI-framework like dagger! - However, I try to wrap my head around it.

I have two scopes: ActivityScope and FragmentScope

On some of the samples provided StatisticsFragment.java you see e.g. the fragment annotated with the scope

@ActivityScoped
public class StatisticsFragment extends DaggerFragment implements 
StatisticsContract.View {
...
}

Question 1: Is this just documentation or not? In my app it makes no difference if I annotate the concrete fragment or not.

Question 2: Where in the generated code can I see which scope is used? My fragment injects a Presenter and an AuthProvider. The AuthProvider is annotated with Singleton (in AppModule), the Presenter is defined in UIModule -> LoginModule

looks like this:

UIModule.java:

@Module(includes = AndroidSupportInjectionModule.class)
public abstract class UIModule {

    @ActivityScope
    @ContributesAndroidInjector(modules = LoginModule.class)
    abstract LoginActivity loginActivity();

    @ChildFragmentScope
    @ContributesAndroidInjector(modules = LoginModule.class)
    abstract LoginFragment loginFragment();

    @Binds
    //@ChildFragmentScope
    public abstract LoginContract.View loginView(final LoginFragment fragment);
}

LoginModule.java

@Module
public abstract class LoginModule {

    @Provides
    //@ChildFragmentScope
    static LoginContract.Presenter provideLoginPresenter(final LoginContract.View view, final BaseStore store) {
        return new LoginPresenter(view,store);
    }

}

LoginFragemt.java

public class LoginFragment extends DaggerFragment {
   @Inject
   LoginContract.Presenter presenter;

   @Inject
   Provider<MyAuthClass> myAuthClass;

   ... 
}

presenter is created every time the Fragment gets created, myAuthClass gets created only once and is singleton. Perfect - but I have no idea HOW this works!!!

DaggerFragment#onAttach must somehow know that Presenter is a "local" singleton and MyAuthClass is a global-singleton ...

score 1 · Answer 1 · answered Mar 12 '18 at 20:32

Scope is one of two ways you can tell Dagger to always bind the same object, rather than returning a newly-created one on each injection request. (The other way is the manual way: Just return the same object in a @Provides method.)

First, a scope overview: Let's say you have a component, FooComponent, which has a @FooScope annotation. You define a subcomponent, BarComponent, which has a @BarScope annotation. That means that using a single FooComponent instance, you can create as many BarComponent instances as you want.

@FooScoped
@Component(modules = /*...*/)
public interface FooComponent {
  BarComponent createBarComponent(/* ... */);  // Subcomponent factory method
  YourObject1 getYourObject1();  // no scope
  YourObject2 getYourObject2();  // FooScoped
}

@BarScoped
@Subcomponent(modules = /*...*/)
public interface BarComponent {
  YourObject3 getYourObject3();  // no scope
  YourObject4 getYourObject4();  // BarScoped
  YourObject5 getYourObject5();  // FooScoped
}

When you call fooComponent.getYourObject1(), YourObject1 is unscoped, so Dagger does its default: create a brand new one. When you call fooComponent.getYourObject2(), though, if you've configured that YourObject2 to be @FooScoped, Dagger will return exactly one instance for the entire lifetime of that FooComponent. Of course, you could create two FooComponent instances, but you'll never see multiple instances of a @FooScoped object from the same @FooScoped component (FooComponent).

Now onto BarComponent: getYourObject3() is unscoped, so it returns a new instance every time; getYourObject4() is @BarScoped, so it returns a new instance for each instance of BarComponent; and getYourObject5() is @FooScoped, so you'll get the same instance along the instance of FooComponent from which the BarComponent was created.

Now to your questions:

Question 1: Is this just documentation or not? In my app it makes no difference if I annotate the concrete fragment or not.

In classes that have an @Inject-annotated constructor like StatisticsFragment does, adding a scope annotation is not simply documentation: Without the scope annotation, any requests to inject a StatisticsFragment will generate a brand new one. If you only expect there to be a single instance of StatisticsFragment per Activity, this may be surprising behavior, but it might be hard to notice the difference.

However, adding an @Inject annotation to a Fragment may be something of a controversial move, because the Android infrastructure is able to create and destroy Fragment instances itself. The object that Android recreates will not the scoped one, and it will have its members reinjected onAttach due to DaggerFragment's superclass behavior. I think a better practice is to drop the @Inject annotation from the constructor and stick with field injection for your Fragment. At that point you can drop the scope, because Dagger will never create your Fragment, so it'll never decide whether to create a new one or return an existing one.

Question 2: Where in the generated code can I see which scope is used? My fragment injects a Presenter and an AuthProvider. The AuthProvider is annotated with Singleton (in AppModule), the Presenter is defined in UIModule -> LoginModule

The generated code and scoping is always generated in the Component; subcomponents will have their implementations generated as an inner class of the Component. For each scoped binding, there will be a place in the initialize method where the Provider (e.g. AuthProvider) is wrapped in an instance of DoubleCheck that manages the double-checked locking for singleton components. If nobody asks Dagger to create an object (like StatisticsFragment), Dagger can determine the lack of component factory methods or injections in the graph, and can avoid adding any code generation for it at all—which might be why you're not seeing any.

Dagger 2, scopes + annotation

1 Answers1