16

Digging into Google's DI framework Dagger2 to decide for a DI Framewor to use it in an middle sized app, I also noticed Hilt

So according to its overview description:

Hilt works by code generating your Dagger setup code for you. This takes away most of the boilerplate of using Dagger and really just leaves the aspects of defining how to create objects and where to inject them. Hilt will generate the Dagger components and the code to automatically inject your Android classes (like activities and fragments) for you.

Hilt generates a set of standard Android Dagger components based off of your transitive classpath. This requires marking your Dagger modules with Hilt annotations to tell Hilt which component they should go into. Getting objects in your Android framework classes is done by using another Hilt annotation which will generate the Dagger injection code into a base class that you will extend. For Gradle users, extending this class is done with a bytecode transformation under the hood.

1. It does neither replace Dagger2 nor is it its successor?

2. Hilt is something additional to Dagger2, which then simplifies the Dagger2 usage?

3. Are there any disadvantages, other than it is still in Alpha?

Pavel Pipovic
  • 339
  • 1
  • 3
  • 12

2 Answers2

18

Does Hilt replace Dagger2?

No. Hilt still uses Dagger underneath the hood. You could think of it as an opinionated Dagger extension for Android. I say opinionated, because it has some limitations of what you could do with plain Dagger vs using Hilt, which has a rigid component structure, but at the same time this takes away most of the boilerplate of using Dagger.

Your questions can also serve as the answer...

  • It does neither replace Dagger2 nor is it its successor
  • Hilt is something additional to Dagger2, which then simplifies the Dagger2 usage

Are there any disadvantages, other than it is still in Alpha?

Well, it's in alpha and things might change. I'd definitely wait before using it in production.

The benefit over plain Dagger or dagger.android is that it should be simpler to set up due to the strict component relationship structure. This also allows Hilt to remove some boilerplate and make the setup less verbose. It should make integrations overall easier.
But at the same time this is also its drawback. You can build all sorts of dependency graphs with plain Dagger, whereas Hilt limits you to their predefined structure. So it might not be as powerful when it comes to big & complex projects.

David Medenjak
  • 33,993
  • 14
  • 106
  • 134
12

Hilt is based on the idea of a single central core. The core is ApplicationComponent, and each child subComponent contributes to it's generated code. Having some background of developing big projects with a big number of gradle modules wired up together using Dagger, here is some keypoints:

  • the build is very slow if you put everything into one single AppComponent. Dagger-Android and Hilt do that. Both just extend AppComponent with a bunch of Subcomponents, that provide their own bindings and entities. The more bindings, the larger subcomponents are -> the larger AppComponent and build times.

  • plain Dagger is highly configurable, on the other hand. You can choose to use component dependencies instead of subcomponents and avoid your AppComponent to be bloated with bindings of whatever feature. You can keep your features highly decoupled. And hence -> reduce build time. That matters, actually.

In my opinion, Hilt is a good option for novices and to start quickly to do some MVP.

Maxim Alov
  • 604
  • 4
  • 14