Dependency Injection (DI) in Android can sometimes feel like you’re trying to untangle a bowl of spaghetti – except the spaghetti is your code, and the sauce is… well, your dependencies. Fortunately, there are tools to help make DI a bit less messy. In this article, we’ll compare the veteran Dagger with its more opinionated, modern cousin Hilt. Spoiler: Hilt might just become your new best friend.

What’s the Deal with Dependency Injection?

Before we dive in, let’s quickly recap DI. The idea is simple: rather than having your classes create their own dependencies, you inject them from the outside. This makes your code easier to test and maintain. Imagine if your app’s classes were like eager beavers – they always asked for help rather than trying to do everything themselves.

Dagger: The Veteran Heavyweight

Dagger has been the go-to dependency injection framework for Android for years. It works by generating code at compile time, ensuring that every dependency is provided correctly before you even run your app. The upside? You get early error detection and highly optimized code. The downside? Its boilerplate can feel like you’re writing the manual for assembling IKEA furniture – if IKEA were known for cryptic instructions.

For example, with Dagger, you’d have to define modules and components to tell the framework how to create instances of your classes. It’s powerful, but sometimes the setup can be a bit overwhelming.

Enter Hilt: The Modern Simplifier

Hilt is built on top of Dagger (yep, it uses Dagger under the hood) but is designed specifically for Android. It offers a standard set of components and scopes out-of-the-box, dramatically reducing boilerplate. In other words, Hilt is like Dagger after a nice spa day – it’s relaxed, refreshed, and easier to work with.

Hilt removes the need for manually creating components and modules in many cases. All you have to do is annotate your Application, Activity, Fragment, or ViewModel, and Hilt takes care of the rest. It’s officially supported by Google and comes with comprehensive documentation, so if you’re new to DI (or even if you’re a veteran tired of Dagger’s boilerplate), Hilt is a great choice.

“Hilt: Because sometimes you just want DI without the DI-fficulty.”

A Practical Guide to Adopting Hilt

1. Setup Your Project

First things first: add Hilt dependencies to your Gradle files. Here’s a snippet to get you started:

// In your project-level build.gradle
buildscript {
  dependencies {
    classpath "com.google.dagger:hilt-android-gradle-plugin:+"
  }
}

// In your app-level build.gradle
plugins {
  id 'com.android.application'
  id 'kotlin-android'
  id 'kotlin-kapt'
  id 'com.google.dagger.hilt.android'
}

dependencies {
    implementation "com.google.dagger:hilt-android:+"
    kapt "com.google.dagger:hilt-compiler:+"
}

Pro tip: Hilt works best with Java 8 features. If you haven’t already, make sure to enable Java 8 compatibility.

2. Create Your Application Class

Every Hilt-powered app needs an Application class annotated with @HiltAndroidApp. This is where Hilt sets up its DI graph for you.

@HiltAndroidApp
class MyApplication : Application()

That’s it! With this annotation, Hilt generates the necessary components for your entire app.

3. Inject Dependencies in Your Android Classes

Let’s say you have a repository that fetches data from an API. With Hilt, you can inject that dependency into your Activity, Fragment, or even ViewModel.

Define a Repository with Constructor Injection

class MyRepository @Inject constructor(private val apiService: ApiService) {
  fun fetchData() {
    // Your API call logic here...
  }
}

Provide the API Service Using a Module

Even though Hilt simplifies many things, sometimes you need to tell it how to create instances of classes you don’t own (like a Retrofit service):

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

  @Provides
  @Singleton
  fun provideRetrofit(): Retrofit = 
    Retrofit.Builder()
      .baseUrl("https://api.example.com/")
      .addConverterFactory(GsonConverterFactory.create())
      .build()

  @Provides
  @Singleton
  fun provideApiService(retrofit: Retrofit): ApiService =
    retrofit.create(ApiService::class.java)
}

Injecting in a ViewModel

Hilt makes it super simple to inject dependencies into your ViewModel:

@HiltViewModel
class MainViewModel @Inject constructor(
  private val repository: MyRepository
) : ViewModel() {

  fun loadData() {
    // Call repository.fetchData() in a coroutine
  }
}

Finally, in Your Activity or Fragment

Annotate your Activity (or Fragment) with @AndroidEntryPoint and use the by viewModels() delegate to get your ViewModel:

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

  private val viewModel: MainViewModel by viewModels()

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
        
    viewModel.loadData()
  }
}

Real-World Examples: Hilt in Action

Imagine you’re building a weather app. You need to fetch weather data, display it on screen, and maybe even reset some state when the user logs out. With Hilt, your code might look something like this:

• WeatherRepository: Handles API calls.
• NetworkModule: Provides Retrofit and your API interface.
• WeatherViewModel: Injects WeatherRepository and exposes weather data to the UI.
• WeatherActivity: Simply observes ViewModel data and updates the UI accordingly.

This setup minimizes boilerplate while maintaining the benefits of compile-time safety provided by Dagger. In fact, many developers have reported that switching from Dagger to Hilt cut down on code and headaches alike – kind of like trading in a flip phone for a smartphone.

Why Choose Hilt Over Dagger?

• Less Boilerplate: With Hilt, you can kiss goodbye to a lot of the manual component wiring that Dagger requires.
• Standardized Components: Hilt comes with predefined components for Application, Activity, Fragment, etc., making it easy to follow best practices.
• Official Support: Being officially recommended by Google, Hilt integrates seamlessly with Android’s architecture components.
• Easier Onboarding: For new developers (and those who just want to avoid deciphering cryptic Dagger errors), Hilt provides a gentler learning curve.

Of course, if you have a project with very advanced DI needs, Dagger’s flexibility might still be the way to go. But for most modern Android apps, Hilt hits the sweet spot.

“Hilt is like the ‘set it and forget it’ for dependency injection in Android – almost like your morning coffee, but for your code.”

Conclusion

Dependency injection doesn’t have to be a dark art reserved for the most hardened developers. With Hilt, you get all the power of Dagger, minus the ceremony. It’s simple, it’s effective, and it makes your code cleaner. So whether you’re starting a new project or thinking of migrating from plain Dagger, Hilt is definitely worth a look.

For more in-depth discussions on DI frameworks, check out articles like Dependency Injection In Android: Dagger vs. Hilt and How Dagger, Hilt and Koin differ under the hood.

Happy coding – and may your dependencies always be injected!