title: What determines the lifecycle of a component (object graph) in Dagger 2?
body: <p>I'm trying to wrap my head around scopes in Dagger 2, specifically the lifecycle of scoped graphs. How do you create a component that will be cleaned up when you leave the scope.</p>
  
  <p>In the case of an Android application, using Dagger 1.x you generally have a root scope at the application level which you'd extend to create a child scope at the activity level.</p>
  
  <pre><code>public class MyActivity {
  
      private ObjectGraph mGraph;
  
      public void onCreate() {
          mGraph = ((MyApp) getApplicationContext())
              .getObjectGraph()
              .plus(new ActivityModule())
              .inject(this);
      }
  
      public void onDestroy() {
          mGraph = null;
      }
  }
  </code></pre>
  
  <p>The child scope existed as long as you kept a reference to it, which in this case was the lifecycle of your Activity. Dropping the reference in onDestroy ensured the scoped graph was free to be garbage collected.</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>Jesse Wilson recently posted a <a href="https://publicobject.com/2014/11/15/dagger-2-has-components/" rel="noreferrer">mea culpa</a></p>
  
  <blockquote>
    <p>Dagger 1.0 badly screwed up its scope names ... The @Singleton annotation is used for both root graphs and custom graphs, so it's tricky to figure out what the actual scope of a thing is.</p>
  </blockquote>
  
  <p>and everything else I've read/heard points towards Dagger 2 improving the way scopes work, but I'm struggling to understand the difference. According to @Kirill Boyarshinov's comment below, the lifecycle of a component or dependency is still determined, as usual, by concrete references. So is the difference between Dagger 1.x and 2.0 scopes purely a matter of semantic clarity?</p>
  
  <h2>My understanding</h2>
  
  <h3>Dagger 1.x</h3>
  
  <p>Dependencies were either <code>@Singleton</code> or not. This was equally true of dependencies in the root graph and subgraphs, leading to ambiguity as to which graph the dependency was bound to (see <a href="https://stackoverflow.com/questions/25953525/in-dagger-are-singletons-within-the-sub-graph-cached-or-will-they-always-be-recr">In Dagger are Singletons within the sub-graph cached or will they always be recreated when a new activity sub-graph is constructed?</a>)</p>
  
  <h3>Dagger 2.0</h3>
  
  <p>Custom scopes allow you to create semantically clear scopes, but are functionally equivalent to applying <code>@Singleton</code> in Dagger 1.x.</p>
  
  <pre><code>// Application level
  @Singleton
  @Component( modules = MyAppModule.class )
  public interface MyAppComponent {
      void inject(Application app);
  }
  
  @Module
  public class MyAppModule {
  
      @Singleton @Named("SingletonScope") @Provides
      StringBuilder provideStringBuilderSingletonScope() {
          return new StringBuilder("App");
      }
  }
  </code></pre>
  
  <hr>
  
  <pre><code>// Our custom scope
  @Scope public @interface PerActivity {}
  </code></pre>
  
  <hr>
  
  <pre><code>// Activity level
  @PerActivty
  @Component(
      dependencies = MyAppComponent.class,
      modules = MyActivityModule.class
  )
  public interface MyActivityComponent {
      void inject(Activity activity);
  }
  
  @Module
  public class MyActivityModule {
  
      @PerActivity @Named("ActivityScope") @Provides
      StringBuilder provideStringBuilderActivityScope() {
          return new StringBuilder("Activity");
      }
  
      @Name("Unscoped") @Provides
      StringBuilder provideStringBuilderUnscoped() {
          return new StringBuilder("Unscoped");
      }
  }
  </code></pre>
  
  <hr>
  
  <pre><code>// Finally, a sample Activity which gets injected
  public class MyActivity {
  
      private MyActivityComponent component;
  
      @Inject @Named("AppScope")
      StringBuilder appScope
  
      @Inject @Named("ActivityScope")
      StringBuilder activityScope1
  
      @Inject @Named("ActivityScope")
      StringBuilder activityScope2
  
      @Inject @Named("Unscoped")
      StringBuilder unscoped1
  
      @Inject @Named("Unscoped")
      StringBuilder unscoped2
  
      public void onCreate() {
          component = Dagger_MyActivityComponent.builder()
              .myApplicationComponent(App.getComponent())
              .build()
              .inject(this);
  
          appScope.append(" &gt; Activity")
          appScope.build() // output matches "App (&gt; Activity)+" 
  
          activityScope1.append("123")
          activityScope1.build() // output: "Activity123"
  
          activityScope2.append("456")
          activityScope1.build() // output: "Activity123456"
  
          unscoped1.append("123")
          unscoped1.build() // output: "Unscoped123"
  
          unscoped2.append("456")
          unscoped2.build() // output: "Unscoped456"
  
      }
  
      public void onDestroy() {
          component = null;
      }
  
  }
  </code></pre>
  
  <p>The takeaway being that using <code>@PerActivity</code> communicates your <em>intention</em> regarding the lifecycle of this component, but ultimately you can use the component anywhere/anytime. Dagger's only promise is that, for a given component, scope annotated methods will return a single instance. I also assume Dagger 2 uses the scope annotation on the component to verify that modules only provide dependencies that are either in the same scope or non-scoped.</p>
  
  <h3>In Summary</h3>
  
  <p>Dependencies are still either singleton or non-singleton, but <code>@Singleton</code> is now intended for application-level singleton instances and custom scopes are the preferred method for annotating singleton dependencies with a shorter lifecycle.</p>
  
  <p>The developer is responsible for managing the lifecycle of components/dependencies by dropping references that are no longer needed and responsible for ensuring that components are only created once in the scope for which they are intended, but custom scope annotations make it easier to identify that scope.</p>
  
  <h2>The $64k Question*</h2>
  
  <p>Is my understanding of Dagger 2 scopes and lifecycles correct?</p>
  
  <p><em>* Not actually a $64'000 question.</em></p>