Daniel Perez

A Pragmatic Introduction To Dagger on Android - Why use Dagger?(Part 2)

2023-09-27T00:00:00+00:00

A Pragmatic Introduction To Dagger on Android Part 2: Setup with Retrofit

Note: This article assumes some familiarity with Retrofit.

Welcome back to "A Pragmatic Introduction to Dagger on Android". In the last article we discussed why you would want to use a Dependency Injection framework like Dagger 2. In this article, we're going to see how by configuring a custom OkHttpClient wired into a Retrofit instance, which is then used to create a TypicodeService. Our dependency chain will look like the following:

TypicodeService -> Retrofit -> OkHttpClient

In this article, we'll do the following to use Dagger and inject MainActivity with a TypicodeService:

Enable kapt
Configure Dagger 2 with gradle
Configure a custom Component
Configure a custom Application class
Set up our dependency chain with Dagger Modules
Inject our TypicodeService into an Activity

To start, you'll need to clone this guides code with the following command:

git clone --branch part-2-start https://github.com/danielPerez97/pragmatic-dagger.git

Once you've cloned the code, open it in Android Studio and sync with Gradle.

1) Enabling `kapt`

First, we'll need to enable kapt (Kotlin Annotation Processing Tool) in our app-module build.gradle.kts file.

In our plugins{} block, add the following line:

kotlin("kapt")

Sync your IDE with Gradle.

2) Configure Dagger 2 with Gradle

Add these lines to the dependencies {} block of your app-module build.gradle.kts file:

// Dagger - Use the correct version in the banner above for "2.x"
implementation("com.google.dagger:dagger:2.x")
kapt("com.google.dagger:dagger-compiler:2.x")

Sync your IDE with Gradle.

3) Configuring a custom Component and Generating Code

Next up, we're going to create something called a Component. Before we do that though, let's talk about what a Component is and what it's used for.

In the last article, we said this about Dagger:

"Is it actually this hard to set up?"
Yeah, I'd go ahead and say Dagger 2 is a bit hard to set up, but that's partly because it's based on 100% code generation instead of reflection. We make this tradeoff for major performance gains on mobile devices.

Compared to something like Spring Dependency Injection where it's an out-of-the-box solution, Dagger 2 is often configured manually and requires us to call into the generated code. I still think it's almost as easy to use as possible given this constraint because of Components and Annotations. Almost.*

A Component is just an interface that you define to begin using Dagger's generated code. Components are able to expose dependencies from the Dagger graph directly as well as perform members-injection on other classes. We will define a component for our Android application, use Dagger-specific annotations on it, then take a look at the generated code.

Let's go ahead and define a TypicodeAppComponent in the dev.danperez.typicode example, with nothing Dagger-specific yet:

// main/java/dev/danperez/typicode/TypicodeAppComponent.kt

package dev.danperez.typicode

interface TypicodeAppComponent
{
    fun inject(mainActivity: MainActivity)
}

We're going to be using Members Injection on MainActivity, so the fun inject(mainActivity: MainActivity) function is about as simple as we can make it. We won't provide the implementation for TypicodeAppComponent; instead, Dagger will generate it for us.

To make the Dagger Compiler aware of our TypicodeAppComponent, all we have to do is add the @dagger.Component and @javax.inject.Singleton annotations:

// main/java/dev/danperez/typicode/TypicodeAppComponent.kt
package dev.danperez.typicode

import dagger.Component
import javax.inject.Singleton

@Singleton
@Component
interface TypicodeAppComponent
{
    fun inject(mainActivity: MainActivity)
}

@Singleton is an annotation we will use for a feature called scopes. We can use this later to tell Dagger NOT to create expensive objects over and over again, but to cache it with the lifecycle of the Component.

In order for Dagger to begin generating code, we'll need to build the app module. You can use the hammer icon at the top of Android Studio's New UI to do this or use the following command:

./gradlew :app:clean :app:assembleDebug

Note: For this command to work, your JAVA_HOME environment variable MUST point to at least a Java 11 JDK.

This will generate DaggerTypicodeAppComponent at /app/build/generated/source/kapt/debug/dev/danperez/typicode/DaggerTypicodeAppComponent.java. You can also view it below.

Note: Up to this point, all of our code has been in Kotlin. Dagger generates Java code, so be prepared to read Java code if you're ever looking at what Dagger generates.

// Generated by Dagger (https://dagger.dev).
package dev.danperez.typicode;

import dagger.internal.DaggerGenerated;

@DaggerGenerated
@SuppressWarnings({
    "unchecked",
    "rawtypes",
    "KotlinInternal",
    "KotlinInternalInJava"
})
public final class DaggerTypicodeAppComponent {
  private DaggerTypicodeAppComponent() {
  }

  public static Builder builder() {
    return new Builder();
  }

  public static TypicodeAppComponent create() {
    return new Builder().build();
  }

  public static final class Builder {
    private Builder() {
    }

    public TypicodeAppComponent build() {
      return new TypicodeAppComponentImpl();
    }
  }

  private static final class TypicodeAppComponentImpl implements TypicodeAppComponent {
    private final TypicodeAppComponentImpl typicodeAppComponentImpl = this;

    private TypicodeAppComponentImpl() {


    }

    @Override
    public void inject(MainActivity mainActivity) {
    }
  }
}

This isn't doing anything yet, but it might be useful to see how this changes later. Note that it provides a static create()method we can use to retrieve our TypicodeAppComponent. It also has an internal, private TypicodeAppComponentImpl, but it's constructor and inject(MainActivity mainActivity) don't have anything in their bodies.

Nonetheless, we'll go ahead and configure this in a custom Application class where we can retrieve it from Activities, Fragments, Services, etc.

4a) Configuring a custom `Application` Class

The first time I ever saw a custom application class was in the context of learning Dagger, so I'm going to assume this is your first time seeing it too.

A custom application class is a class the Android OS will set up for you in place of the default android.app.Application class. It's similar to an activity in that you declare it in the manifest and has similar lifecycle methods(onCreate(), onDestroy(), etc.) you can hook into. Your custom Application class will be created before any of the 4 main Android OS components(Activities, BroadcastReceivers, ContentProviders, Services) and will be destroyed after.

First, create a new file called TypicodeApplication.kt in the dev.danperez.typicode package and use the following code:

package dev.danperez.typicode

import android.app.Application

class TypicodeApplication: Application()
{
    lateinit var typicodeAppComponent: TypicodeAppComponent
    
    override fun onCreate() {
        super.onCreate()
        typicodeAppComponent = DaggerTypicodeAppComponent.create()
    }
}

Then, to instruct the Android OS to use your custom application class instead of the default one, simply declare a name attribute on the <application> tag in your AndroidManifest.xml:

<application
        ...
        android:name=".TypicodeApplication"
        ...
>
</application>

4b) Inject MainActivity

Now, from our MainActivity, we'll be able to look up our TypicodeAppComponent to retrieve dependencies from the Dagger graph. Let's go ahead and try to inject a TypicodeService by adding the following lines to MainActivity:

...
import javax.inject.Inject// <-- ADD THIS
...
class MainActivity : ComponentActivity() {
@Inject lateinit var typicodeService: TypicodeService // <-- ADD THIS
var text by mutableStateOf("Hello!")
...
}

Try and build the app module like we did before. You should see a problem:

[Dagger/MissingBinding] dev.danperez.typicode.TypicodeService cannot be provided without an @Provides-annotated method.
public abstract interface TypicodeAppComponent {
                ^
  
  Missing binding usage:
      dev.danperez.typicode.TypicodeService is injected at
          dev.danperez.typicode.MainActivity.typicodeService
      dev.danperez.typicode.MainActivity is injected at
          dev.danperez.typicode.TypicodeAppComponent.inject(dev.danperez.typicode.MainActivity)

[Dagger/MissingBinding] is a well-known error, and it should immediately tell you one thing: Dagger could not find an object on its graph. This error is saying we're missing a binding for TypicodeService which is supposed to be injected at MainActivity. In this case, it's because we never told Dagger to put TypicodeService on the graph. Let's fix that.

5) Set up our dependency chain with Dagger Modules

Let's revisit our Dependency chain for TypicodeService:

TypicodeService -> Retrofit -> OkHttpClient

TypicodeService is another interface we will not be generating, Retrofit will. The difference between how Dagger and Retrofit does this is simple: Dagger uses code generation at compile-time, Retrofit uses reflection at runtime. For us, this means we now have 2 interfaces whose implementation we won't be writing out by hand.

Since TypicodeService has a dependency on Retrofit, we will need to tell Dagger how to use Retrofit to create TypicodeService. For classes and implementations whose code we cannot manually modify, we have to use Dagger modules.

Dagger Modules are the mechanism to say "hey Dagger, here's something I'd like for you to stick on your graph. When you retrieve this type for me, here's the code you'll need to run in order to retrieve it."

Let's create a brand new package called di at dev.danperez.typicode.di. In this package, create TypicodeModule.kt with the following code:

package dev.danperez.typicode.di

import dagger.Module
import dagger.Provides
import dev.danperez.typicode.TypicodeService
import okhttp3.OkHttpClient
import retrofit2.Retrofit
import javax.inject.Singleton

@Module
class TypicodeModule
{
    @Provides
    @Singleton
    fun provideOkHttpClient(): OkHttpClient
    {
        return OkHttpClient()
    }

    @Provides
    fun provideRetrofit(client: OkHttpClient): Retrofit
    {
        return Retrofit.Builder()
            .baseUrl("https://jsonplaceholder.typicode.com")
            .build()
    }

    @Provides
    fun provideTypicodeService(retrofit: Retrofit): TypicodeService
    {
        return retrofit.create(TypicodeService::class.java)
    }
}

Here we're using two new annotations, @Module and @Provides. If we look at the source code(CMD + B or CTRL + B) for these, we'll see these comments on them from the Dagger 2 maintainers:

@Module: "Annotates a class that contributes to the object graph."

@Provides: "Annotates methods of a module to create a provider method binding. The method's return type is bound to its returned value. The component implementation will pass dependencies to the method as parameters."

Essentially, @Module tells Dagger "Here's a class/interface that's going to provide some dependencies for your graph." and @Provides tells Dagger "Here is a specific dependency to add to your graph." The two go hand in hand very often.

Knowing this, we can quickly tell that provideOkHttpClient() binds an OkHttpClient type onto the Dagger graph. provideRetrofit(client: OkHttpClient) deserves a bit more attention though.

provideRetrofit(client: OkHttpClient) actually uses the Dagger graph to request an OkHttpClient type. This way, we can use our OkHttpClient binding multiple times to create different services throughout our Dagger code (or inject it into an Activity). If OkHttpClient wasn't on the graph already, we would have gotten another [MissingBinding] error. And as a bonus, @Singleton combined with @Provides tells Dagger, "Create this once and re-use it everywhere on the graph." Effectively, this is enforcing the Singleton pattern for us in Dagger's generated code.(It's also good practice to use one OkHttpClient for your entire app too)

The final thing we have to do is edit the @Component annotation on TypicodeAppComponentto the following:

@Component(modules = [TypicodeModule::class])

This "installs" our module into the TypicodeAppComponent. We MUST do this because an application can have multiple Components, and we have to specify which modules belong to which components.

6) Inject MainActivity: Round 2

Finally, we can attempt to inject MainActivity. Go ahead and build your app module again.

Now that we're past the compile error, we just have to actually inject MainActivity by calling Dagger's generated code. We're going to use a very common method to retrieve our Dagger Component: cast the applicationContext to our custom Application class, retrieve the Component, and call the inject() method. In our case, it looks like this:

(applicationContext as TypicodeApplication).typicodeAppComponent.inject(this)

Call this code before super.onCreate() in MainActivity:

package dev.danperez.typicode

import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity
import javax.inject.Inject

class MainActivity : AppCompatActivity() {
    @Inject lateinit var typicodeService: TypicodeService
    ...

    override fun onCreate(savedInstanceState: Bundle?) {
        (application as TypicodeApplication).typicodeAppComponent.inject(this) // INJECTION
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        // This is a coroutine that runs in the lifecycle scope of the activity. It's used to perform asynchronous tasks, 
        // like network requests, off the main thread. Here, we're using it to test our injected TypicodeService by 
        // requesting a post from an API and updating the 'text' state with the response.
        lifecycleScope.launch {
            text = typicodeService.getPost(1).string()
        }
    }
    ...
}

Now, you should be able to use TypicodeService throughout MainActivity. In the above code, I've provided some code that should display the result of the network request in the UI(it should just be a JSON String).

Recap

What have we achieved in this article?

We set up Dagger in our Gradle build
Created a custom Dagger Component and viewed generated code
Configured a custom Application class to provide access to our Dagger Component
Set up our dependency chain for TypicodeService and reviewed a Dagger MissingBinding error
Used Dagger to inject our TypicodeService into MainActivity

That's quite a bit to digest for one article, but I believe that Dagger pays off this upfront complexity with its early failures and runtime speed. Perhaps at a smaller scale, all this setup isn't worth it and Koin might be a better fit for your project. However, if your project consists of many thousands of lines of code and many, many modules, Dagger 2 is probably your best choice for validating your dependency graph at compile-time as well as its speed.

Part 3

Stay tuned for Part 3 where we'll discuss how to use the Factory pattern to inject Android ViewModel's.

Notes

"I still think it's almost as easy to use as possible. Almost."

By this, I mean using Dagger + Anvil to automatically install Modules into the Component. I wish it was built into Dagger itself.

A Pragmatic Introduction To Dagger on Android - Why use Dagger?(Part 1)

2023-09-19T00:00:00+00:00

A Pragmatic Introduction To Dagger on Android Part 1: Why use Dagger?

Dagger 2 is one of the most infamous tools in Android development and yet one of the most indispensable. Newcomers have struggled to understand why it's used, what Dependency Injection is, and how to set Dependency Injection up in their own projects. If you are currently struggling with this topic, you may share in some of these thoughts I used to have:

"What is Dagger?"

"Why would I ever use this?"

"Is it actually this hard to set up?"

In this article, I'll attempt to answer all of these questions before showing you how to implement Dagger in your own Android app in Part 2.

In order to answer "What is Dagger?", it would be helpful if we learned what Dependency Injection is first.

What is Dependency Injection?

James Shore worded it perfectly on his blog, "The Art of Agile":

“Dependency Injection” is a 25-dollar term for a 5-cent concept. "Dependency Injection" sounds scary, but it refers to an extremely simple concept we're all familiar with: taking parameters.

No really, it's just taking parameters. Taking parameters in functions, taking parameters in constructors, and setting mutable members (on a class).

In the next code sample, there are three demonstrations of different kinds of Dependency Injection:

Constructor Injection
Method Injection
Field Injection

// Constructor Injection
class NetworkHandler(val client: OkHttpClient)

fun doSomething() {
    val client = OkHttpClient()
    val networkHandler = NetworkHandler(client) // Here we "inject" an OkHttpClient by passing a parameter to the constructor
}

// Method Injection
fun setPet(pet: Pet) {
    this.pet = pet
}

// Members Injection
class MyActivity()
{
    lateinit var okHttpClient: OkHttpClient // <- Public, mutable member
}

class Injector(val appOkHttpClient: OkHttpClient)
{
    fun injectMyActivity(activity: MyActivity) {
        activity.okHttpClient = okHttpClient // <- Here we set the member, or "inject" it
    }
}

These are all examples of Dependency Injection in object-oriented programming.

Okay, but, why would I use this pattern? What are we getting out of it?

Dependency Injection has quite a few benefits when applied throughout a codebase, but testing is one of the most talked about especially with discussion around Dagger.

Note: From this point forward I will shorthand Dependency Injection with "DI".

Testing

Using DI consistently helps us write testable code. Suppose you have the following class and interface:

// Pet.kt
data class Pet(val id: Long, val name: String)

// PetDataSource.kt
interface PetDataSource
{
    fun getPets(): List<Pet>
}

Nothing special yet, but here's how we might use it in a PetListPresenter class:

// PetListPresenter.kt
class PetListPresenter(val petDataSource: PetDataSource) // Constructor Injection
{
    fun getPetByid(id: Long): Pet? {
        return petDataSource.getPets().find { it.id == id }    
    }
}


// SQLitePetDataSource.kt
class SQLitePetDataSource(val petDb: PetDb): PetDataSource {
    override fun getPets(): List<Pet> {
        ...
        return pets
    }
}

// PetActivity.kt
...
class PetActivity: AppCompatActivity()
{
    override fun onCreate() {
        super.onCreate()
        val sqlitePetDataSource = SQLitePetDataSource(db = context.getDatabase())
        val petListPresenter = PetListPresenter(petDataSource = sqlitePetDataSource) // Using constructor injection to satisfy the PetDataSource parameter in production code
    }

    fun Context.getDatabase(): PetDb {
        ...
        return db
    }
}

Still, nothing special is happening yet. All we did was abstract away where the data is coming from. We could have just as easily used a NetworkPetDataSource.kt to retrieve our pets. However, when it comes time to test PetListPresenter, this pattern has a clear benefit: we can pass fakes/mocks into our object under test quickly, especially if we leverage Kotlin's object keyword.

// TestPetListPresenter.kt

class TestPetListPresenter                                                      
{
    private lateinit var petListPresenter: PetListPresenter
    
    @Before
    fun setup() {
        val fakePetDataSource: PetDataSource = object: PetDataSource {
            override fun getPets(): List<Pet> {
                return listOf(Pet(id = 0, name = "Wheatley"))
            }   
        }
        
        petListPresenter = PetListPresenter(fakePetDataSource) // Using constructor injection to satisfy the PetDataSource parameter in test code
    }

    @Test
    fun testGetPetById() {
        val pet = petListPresenter.getPetById(0)
        assertTrue(pet != null)
        assertEquals("Wheatley", pet.name)
    }
}

Since our PetListPresenter has no idea where the data is coming from (or knowledge of the implementation), we were able to spin up a PetDataSource on the fly for our test. We have now used the DI pattern to make our testing significantly easier. Consider the case where PetListDataSource had defined SQLitePetDataSource as a constructor parameter:

// PetListPresenter.kt
class PetListPresenter(val petDataSource: SQLitePetDataSource)

In this case, our test would have had to do a bit more configuration to satisfy the constructor parameter for SQLitePetDataSource, which might involve setting up an SQLite database on the file system then making sure we delete it when the tests are done so we don't waste computer resources. Yuck.

I see. Dependency Injection is just a software pattern. But how come people use Dagger?

Dagger is a DI framework. It helps you facilitate this pattern in your code by building a graph of your dependencies, calling the constructors for you, and getting your objects exactly where you need them. In the above example, if one had used Dagger, our PetActivity would have looked like this:

class PetActivity: AppCompatActivity()
{
    @Inject lateinit var petListPresenter: PetListPresenter // Public mutable member that gets injected later 
    
    override fun onCreate() {
        getInjector().inject(this) // INJECTION
        super.onCreate()
        // You can use petListPresenter anywhere you need to now, as long as onCreate() was called
    }
    
    fun getInjector(): Injector {
        ...
        return injector
    }
}

Take note of the INJECTION comment and recall members injection from earlier. That Injector#inject(activity: PetActivity) is doing something like this under the hood:

// Injector.kt. Dagger will generate similar code to this but in Java.
class Injector(...)
{
    ...
    fun inject(activity: PetActivity) {
        // Note: sqlitePetDataSource could be a member of this Injector class, or it might be provided by a factory
        activity.petListPresenter = PetListPresenter(sqlitePetDataSource) // <- Here we set the member, or "inject" it
    }
}

Let's pause for a moment and look at our chain of dependencies for PetListPresenter:

PetListPresenter -> SQLitePetDataSource -> PetDb

Dagger takes care of this entire chain for you so your PetActivity doesn't have to care about PetDb and SQLitePetDataSource. It can focus entirely on PetListPresenter.

Satisfying dependency chains so you can focus on only the object you need is what DI frameworks are great for.

Okay, so Dagger is a DI Framework. But do we have to call `getInjector().inject(this)` all the time?

Yes. It is imperative that we call Dagger's generated code somewhere for every object we'd like to retrieve from the Dagger graph.* In the case of Members Injection, something called a MembersInjector gets generated for every object whose members are annotated with @Inject. We must call this generated MembersInjector in order to inject our objects.

In the case of Android Framework types like Activity, you cannot use constructor injection** because the Android OS will be creating these objects, not Dagger. Hence, Members Injection becomes the next best option.

Reflection Vs Code Generation

It isn't all sunshine and rainbows. One tradeoff for code generation vs reflection is that we have to call the generated code somewhere instead of a more automatic-feeling solution, like Guice or Spring Dependency Injection.

We also cannot inject private members using code generation, but reflection can. In some ways, Dagger 2 can be harder to use than a reflection-based DI framework. However, these sacrifices afford us an extremely fast dependency injector that's appropriate for Android.

Wrapping up

Let's revisit those 3 questions from the beginning of the article and give an answer for each of them now:

"What is Dagger?"
Dagger is a Dependency Injection Framework, and there are more like it including Guice and Spring Dependency Injection.

"Why would I ever use this?"
To help you facilitate the Dependency Injection pattern in your code, which helps you test and decouple your code.

Part 2

Stay tuned for Part 2 where we'll discuss how to configure Dagger 2 in an Android app.

Notes

"Yes. It is imperative that we call Dagger's generated code" somewhere for every object we'd like to retrieve from the Dagger graph."

This isn't to say we can't be more clever about calling our MembersInjector's. Slack largely hid this by using an extension to Dagger called Anvil.

"In the case of Android Framework types like Activity, you cannot use constructor injection..."

If you're using minSdk=28, you can use AppComponentFactory and FragmentFactory to use constructor injection on Activities, Fragments, Services, Content Providers, etc. This will require a feature we'll discuss in the future called Multibindings.

What makes Dagger2 Great

2023-09-18T00:00:00+00:00

Okay, so Dagger is a DI Framework. But do we have to call `getInjector().inject(this)` all the time?

Unfortunately, we do.* Lets take a look at the history of DI frameworks in Java to understand why.

Once upon a time, Dependency Injection frameworks like Guice(created by Bob Lee) used reflection to achieve their DI. At the time, these DI frameworks weren't built with mobile devices in mind, they were built for servers. Reflection has a runtime cost in performance, but it's an appropriate tradeoff for a server environment. When mobile devices came along, this was no longer the case and led to app slowdowns. We needed a DI framework that was blazing fast for mobile devices but used less or no reflection.

Dagger 1, originally created by Square(Block now), used a mixture of code generation and reflection to achieve DI. At compile-time, the injecting code was generated by using annotations (@Inject) in your own code that the Dagger compiler would look at and process. It worked, but the reflection that was hanging around left a desire for more. What if we could make a DI framework that completely ignored reflection and just used code generation at compile-time? This would also yield a major advantage for Dagger 2: failing early. When a dependency couldn't be satisfied(it wasn't on the DI frameworks graph), developers would find out at runtime what had happened instead of compile-time. Early failures lead to faster fixes.

Thus, Dagger 2 was born. Dagger 2 skipped reflection entirely. Instead of making your users pay a performance cost, our Gradle builds would eat the cost in build time and generate injecting code at compile time. It was now possible to use a Dependency Injection framework without reflection.

This made DI with the assistance of a framework blazing fast and appropriate for mobile. We could have clean code without having to call a ton of constructors ourselves. But we have to hook into that generated code somewhere.

So, yes, we do have to call getInjector().inject(this) because this is how we hook into Dagger's generated code. I'm skipping a lot for the sake of brevity but this is generally how injecting Fragments and Activities on Android goes. Since we can't have custom constructors for Fragments and Activities(unless you're using minSdk 28) either, this means we have to use Members Injection(not preferred).

Daniel Perez

A Pragmatic Introduction To Dagger on Android - Why use Dagger?(Part 2)

A Pragmatic Introduction To Dagger on Android Part 2: Setup with Retrofit

1) Enabling kapt

2) Configure Dagger 2 with Gradle

3) Configuring a custom Component and Generating Code

4a) Configuring a custom Application Class

4b) Inject MainActivity

5) Set up our dependency chain with Dagger Modules

6) Inject MainActivity: Round 2

Recap

Part 3

Notes

"I still think it's almost as easy to use as possible. Almost."

A Pragmatic Introduction To Dagger on Android - Why use Dagger?(Part 1)

A Pragmatic Introduction To Dagger on Android Part 1: Why use Dagger?

What is Dependency Injection?

Okay, but, why would I use this pattern? What are we getting out of it?

Testing

I see. Dependency Injection is just a software pattern. But how come people use Dagger?

Okay, so Dagger is a DI Framework. But do we have to call getInjector().inject(this) all the time?

Reflection Vs Code Generation

Wrapping up

Part 2

Notes

"Yes. It is imperative that we call Dagger's generated code" somewhere for every object we'd like to retrieve from the Dagger graph."

"In the case of Android Framework types like Activity, you cannot use constructor injection..."

What makes Dagger2 Great

Okay, so Dagger is a DI Framework. But do we have to call getInjector().inject(this) all the time?

1) Enabling `kapt`

4a) Configuring a custom `Application` Class

Okay, so Dagger is a DI Framework. But do we have to call `getInjector().inject(this)` all the time?

Okay, so Dagger is a DI Framework. But do we have to call `getInjector().inject(this)` all the time?