Dagger- Should we create each component and module for each Activity/ Fragment
<p>I've been working with dagger2 for a while. And I got confused wether to create an own component/module for each Activity/ Fragment. Please help me clarify this:</p>

<p>For example, We have an app, and the app has about 50 screens.
We will implement the code following the MVP pattern and Dagger2 for DI. Suppose that we have 50 activities and 50 presenters. </p>

<p>In my opinion, usually we should organize the code like this :</p>

<ol>
<li><p>Create an AppComponent and AppModule which will provide all objects that will be used while the app is open.</p>

<pre><code>@Module
public class AppModule {

    private final MyApplicationClass application;

    public AppModule(MyApplicationClass application) {
        this.application = application;
    }

    @Provides
    @Singleton
    Context provideApplicationContext() {
        return this.application;
    }

    //... and many other providers 

}

@Singleton
@Component( modules = { AppModule.class } )
public interface AppComponent {

    Context getAppContext();

    Activity1Component plus(Activity1Module module);
    Activity2Component plus(Activity2Module module);

    //... plus 48 methods for 48 other activities. Suppose that we don't have any other Scope (like UserScope after user login, ....)

}
</code></pre></li>
<li><p>Create ActivityScope :</p>

<pre><code>@Scope
@Documented
@Retention(value=RUNTIME)
public @interface ActivityScope {
}
</code></pre></li>
<li><p>Create Component and Module for each Activity. Usually I will put them as static classes within the Activity class:</p>

<pre><code>@Module
public class Activity1Module {

    public LoginModule() {
    }
    @Provides
    @ActivityScope
    Activity1Presenter provideActivity1Presenter(Context context, /*...some other params*/){
        return new Activity1PresenterImpl(context, /*...some other params*/);
    }

}

@ActivityScope
@Subcomponent( modules = { Activity1Module.class } )
public interface Activity1Component {
    void inject(Activity1 activity); // inject Presenter to the Activity
}

// .... Same with 49 remaining modules and components.
</code></pre></li>
</ol>

<p>Those are just very simple examples to show how I would implement this.</p>

<p><strong>But a friend of mine just gave me another implementation:</strong></p>

<ol>
<li><p>Create PresenterModule which will provide all presenters:</p>

<pre><code>@Module
public class AppPresenterModule {

    @Provides
    Activity1Presenter provideActivity1Presentor(Context context, /*...some other params*/){
        return new Activity1PresenterImpl(context, /*...some other params*/);
    }

    @Provides
    Activity2Presenter provideActivity2Presentor(Context context, /*...some other params*/){
        return new Activity2PresenterImpl(context, /*...some other params*/);
    }

    //... same with 48 other presenters.

}
</code></pre></li>
<li><p>Create AppModule and AppComponent:</p>

<pre><code>@Module
public class AppModule {

    private final MyApplicationClass application;

    public AppModule(MyApplicationClass application) {
        this.application = application;
    }

    @Provides
    @Singleton
    Context provideApplicationContext() {
        return this.application;
    }

    //... and many other provides 

}

@Singleton
@Component(
        modules = { AppModule.class,  AppPresenterModule.class }
)
public interface AppComponent {

    Context getAppContext();

    public void inject(Activity1 activity);
    public void inject(Activity2 activity);

    //... and 48 other methods for 48 other activities. Suppose that we don't have any other Scope (like UserScope after user login, ....)

}
</code></pre></li>
</ol>

<p>His explaination is: <strong>He doesn't have to create components and modules for each activity.</strong>
I think my friends idea is absolutely not good at all, but please correct me if I am wrong. Here are the reasons:</p>

<ol>
<li><p><strong>A lot of memory leaks</strong> :</p>

<ul>
<li><strong>The app will create 50 presenters even if the user has only 2 Activities open.</strong> </li>
<li><strong>After the user closes an Activity, its presenter will still remain</strong></li>
</ul></li>
<li><p>What happens if I want to create two instances of one Activity ? (how can he create two presenters )</p></li>
<li><p>It will take a lot of time for the app to initialize (because it has to create many presenters, objects, ...)</p></li>
</ol>

<p><strong>Sorry for a long post, but please help me clarify this for me and my friend, I can't convince him.</strong>
Your comments will be very appreciated.</p>

<p>/<em>-----------------------------------------------------------------------</em>/</p>

<p>Edit after doing a demo. </p>

<p>First, thanks for @pandawarrior answer.
I should have created a Demo before I asked this question. I hope my conclusion here could help someone else.</p>

<ol>
<li>What my friend has done does not cause memory leaks unless he puts any Scope to the Provides-methods. (For example @Singleton, or @UserScope, ...)</li>
<li>We can create many presenters, if the Provides-method doesn't have any Scope. (So, my second point is wrong, too)</li>
<li>Dagger will create the presenters only when they are needed. (So, the app will not take a long time to initialize, I was confused by Lazy Injection)</li>
</ol>

<p>So, all the reasons I have said above are mostly wrong. But it does not mean that we should follow my friend idea, for two reasons:</p>

<ol>
<li><p>It's not good for the source's architecture, when he inits all presenters in  module / component. (It violates <a href="https://en.wikipedia.org/wiki/Interface_segregation_principle" rel="noreferrer">Interface segregation principle</a>, maybe <a href="https://en.wikipedia.org/wiki/Single_responsibility_principle" rel="noreferrer">Single Responsibility</a> priciple, too).</p></li>
<li><p>When we create a Scope Component, we will know when it's created and when it's destroyed which is a huge benefit for avoiding memory leaks. So, for each Activity we should create a Component with an @ActivityScope. Let's imagine, with my friends implementation, that we forgot to put some Scope in the Provider-method => memory leaks will occur.</p></li>
</ol>

<p>In my opinion, with a small app (just a few screens without many dependencies or with similar dependencies), we could apply my friends idea, but of course it's not recommended.</p>

<p>Prefer to read more on:
<a href="https://stackoverflow.com/questions/28411352/what-determines-the-lifecycle-of-a-component-object-graph-in-dagger-2">What determines the lifecycle of a component (object graph) in Dagger 2?</a>
<a href="https://stackoverflow.com/questions/35314682/dagger2-activity-scope-how-many-modules-components-do-i-need?rq=1">Dagger2 activity scope, how many modules/components do i need?</a></p>

<p>And one more note: If you want to see when the object are destroyed, you can call those of method together and the GC will run immediately:</p>

<pre><code>    System.runFinalization();
    System.gc();
</code></pre>

<p>If you use only one of these methods, GC will run later, and you may get wrong results.</p>