Dagger- Should we create each component and module for each Activity/ Fragment

Declaring a separate module for each Activity is not a good idea at all. Declaring separate component for each Activity is even worse. The reasoning behind this is very simple – you don’t really need all these module/components (as you have already seen by yourself).

However, having just one component that is tied to Application‘s life-cycle and using it for injection into all Activities is also not the optimal solution (this is your friend’s approach). It is not optimal because:

1. It restricts you to just one scope (@Singleton or a custom one)
2. The only scope you’re restricted to makes the injected objects “application singletons”, therefore mistakes in scoping or incorrect usage of scoped objects can easily cause global memory leaks
3. You’ll want to use Dagger2 in order to inject into Services too, but Services can require different objects than Activities (e.g. Services don’t need presenters, don’t have FragmentManager, etc.). By using a single component you loose the flexibility of defining different object graphs for different components.

So, a component per Activity is an overkill, but single component for the entire application is not flexible enough. The optimal solution is in between these extremes (as it usually is).

I use the following approach:

1. Single “application” component that provides “global” objects (e.g. objects that hold global state which is shared between all components in the application). Instantiated in Application.
2. “Controller” subcomponent of “application” component that provides objects which are required by all user-facing “controllers” (in my architecture these are Activities and Fragments). Instantiated in each Activity and Fragment.
3. “Service” subcomponent of “application” component that provides objects which are required by all Services. Instantiated in each Service.

Following is an example of how you could implement the same approach.

---

Edit July 2017

I published a video tutorial that shows how to structure Dagger dependency injection code in Android application: Android Dagger for Professionals Tutorial.

---

Edit February 2018

I published a complete course about dependency injection in Android.

In this course I explain the theory of dependency injection and show how it emerges naturally in Android application. Then I demonstrate how Dagger constructs fit into the general dependency injection scheme.

If you take this course you will understand why the idea of having a separate definition of module/component for each Activity/Fragment is basically flawed in the most fundamental way.

Such an approach causes the structure of presentation layer from “Functional” set of classes to be mirrored into the structure of “Construction” set of classes, thus coupling them together. This goes against the main objective of dependency injection which is to keep the “Construction” and “Functional” sets of classes disjoint.

---

Application scope:

@ApplicationScope
@Component(modules = ApplicationModule.class)
public interface ApplicationComponent {

    // Each subcomponent can depend on more than one module
    ControllerComponent newControllerComponent(ControllerModule module);
    ServiceComponent newServiceComponent(ServiceModule module);

}


@Module
public class ApplicationModule {

    private final Application mApplication;

    public ApplicationModule(Application application) {
        mApplication = application;
    }

    @Provides
    @ApplicationScope
    Application applicationContext() {
        return mApplication;
    }

    @Provides
    @ApplicationScope
    SharedPreferences sharedPreferences() {
        return mApplication.getSharedPreferences(Constants.PREFERENCES_FILE, Context.MODE_PRIVATE);
    }

    @Provides
    @ApplicationScope
    SettingsManager settingsManager(SharedPreferences sharedPreferences) {
        return new SettingsManager(sharedPreferences);
    }
}

Controller scope:

@ControllerScope
@Subcomponent(modules = {ControllerModule.class})
public interface ControllerComponent {

    void inject(CustomActivity customActivity); // add more activities if needed

    void inject(CustomFragment customFragment); // add more fragments if needed

    void inject(CustomDialogFragment customDialogFragment); // add more dialogs if needed

}



@Module
public class ControllerModule {

    private Activity mActivity;
    private FragmentManager mFragmentManager;

    public ControllerModule(Activity activity, FragmentManager fragmentManager) {
        mActivity = activity;
        mFragmentManager = fragmentManager;
    }

    @Provides
    @ControllerScope
    Context context() {
        return mActivity;
    }

    @Provides
    @ControllerScope
    Activity activity() {
        return mActivity;
    }

    @Provides
    @ControllerScope
    DialogsManager dialogsManager(FragmentManager fragmentManager) {
        return new DialogsManager(fragmentManager);
    }

    // @Provides for presenters can be declared here, or in a standalone PresentersModule (which is better)
}

And then in Activity:

public class CustomActivity extends AppCompatActivity {

    @Inject DialogsManager mDialogsManager;

    private ControllerComponent mControllerComponent;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        getControllerComponent().inject(this);
        
    }

    private ControllerComponent getControllerComponent() {
        if (mControllerComponent == null) {

            mControllerComponent = ((MyApplication)getApplication()).getApplicationComponent()
                    .newControllerComponent(new ControllerModule(this, getSupportFragmentManager()));
        }
        
        return mControllerComponent;
    }
}

Additional information on dependency injection:

Dagger 2 Scopes Demystified

Dependency Injection in Android