title: Dagger 2 on Android @Singleton annotated class not being injected
body: <p>I am currently trying to integrate Dagger 2 into an Android application. My project setup is as follows:</p>
  
  <ul>
  <li>library</li>
  <li>app (depends on library)</li>
  </ul>
  
  <p>In my library project I defined a class that I'll later inject into other classes that need it (Activities and regular classes) in the library as well as the app project.</p>
  
  <pre><code>@Singleton
  public class MyManager{
    @Inject
    public MyManager(){
      //Do some initializing
    }
  }
  </code></pre>
  
  <p>Now - for instance in my Fragments or Activities or regular classes I'd inject the above Singleton as follows:</p>
  
  <pre><code>public class SomeClass{
  
    @Inject
    MyManager myManager;
  }
  </code></pre>
  
  <p>Or so I thought, because in practice myManager is always null. And apparently it's constructor is never called either, so I guess I must be missing something configuration-wise? Or maybe I misunderstood the documentation and it's not meant to work this way at all? The purpose of MyManager class is to be an application-wide accessible component-accumulating entity - that's why I went for the @Singleton.</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>To avoid confusion: I mentioned my having components somewhere in a comment I think - this refers to components in the sense of "component based design" and has nothing to do with dagger. The dagger-based code I have is all listed above - there is nothing else related to dagger in my code. </p>
  
  <p>When I started adding @Component I had some compiler issues, because my dagger2 was not setup properly - check out this really helpful thread on how to setup dagger2 correctly: <a href="https://stackoverflow.com/a/29943394/1041533">https://stackoverflow.com/a/29943394/1041533</a></p>
  
  <p><strong>UPDATE 2</strong></p>
  
  <p>Here is my updated code, based on G. Lombard's suggestions - I changed the code as follows - the original Singleton is in the library project:</p>
  
  <pre><code>@Singleton
  public class MyManager{
    @Inject
    public MyManager(){
      //Do some initializing
    }
  }
  </code></pre>
  
  <p>Also in the library project is the bootstrap class:</p>
  
  <pre><code>@Singleton
  @Component
  public interface Bootstrap {
      void initialize(Activity activity);
  }
  </code></pre>
  
  <p>Then I use the above Bootstrap class in my activity (in my concrete app, <strong>NOT</strong> in the library project! I do however also have Classes/Activities in the library that'll access Bootstrap to inject MyManager):</p>
  
  <pre><code>public class MyActivity extends Activity{
  
      @Inject
      MyManager manager;
  
  
      @Override
      protected void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
  
          //DONT DO THIS !!! AS EXPLAINED BY EpicPandaForce
          DaggerBootstrap.create().initialize(this);
      }
  }
  </code></pre>
  
  <p>But even after this line:</p>
  
  <pre><code>        DaggerBootstrap.create().initialize(this);
  </code></pre>
  
  <p>the manager instance is still null, i.e. not injected.</p>
  
  <p>I just found this: <a href="https://stackoverflow.com/a/29326023/1041533">https://stackoverflow.com/a/29326023/1041533</a></p>
  
  <p>Which if I don't misread, implies I need to specify every single class in the Bootstrap class that will use @Inject to have stuff injected. Sadly - this is not an option, as I have more than 40 classes and activities for which I'd have to do that. </p>
  
  <p>Meaning my Bootstrap interface apparently would have to look something like this:</p>
  
  <pre><code>@Singleton
  @Component
  public interface Bootstrap {
      void initialize(ActivityA activity);
      void initialize(ActivityB activity);
      void initialize(ActivityC activity);
      void initialize(ActivityD activity);
      void initialize(ActivityE activity);
      void initialize(ActivityF activity);
      //and so on and so forth...
  }
  </code></pre>
  
  <p>If the above is true, that would not be worth it for my use case. Plus: Seems there is no compile-time check, if I forgot to specify one of my 40+ classes here? It just wont work - i.e. crash the app at runtime.</p>