What’s new in Hilt and Dagger 2.31
Hilt is a dependency injection tool that has been introduced by Google in the last year. Hilt makes our projects cleaner and reduces setup time for constructing our DI environment than Dagger-Android. It has been steadily getting feedback and developing for several months. Now Hilt is more stable than the earliest was. In this post, we will take a look at what is the main difference between the earliest version of Hilt and the newest one.
Previous post
HiltAndroidApp
There is no difference in using HiltAndroidApp annotation for building the base DI environment. The role of the HiltAndroidApp is kicking off the code generation of the Hilt components of our project in the compile-time and generates the base classes that need to construct our DI structure. So we don’t need to create a bunch of boilerplates like ActivityModule, ViewModelModule, ViewModelFactory, etc.
Components
The most noticeable difference between Dagger-Android and Hilt is that we don’t need to create the base components. Instead, Hilt provides predefined components that are generated for our projects. Each component has a corresponding scope that is integrated into the lifecycles of the Android application, and their providing rules are depending on the lifecycles. In Hilt 2.31, the previous ApplicationComponent has been removed. We should migrate to SingletonComponent instead. This is intended to be a pure rename/functional no-op. Also the ViewModelComponent and ViewModelScoped are newly introduced.
ViewModelComponent
The ViewModelComponent is newly introduced in Hilt 2.31. Now ViewModels are injected from a ViewModelComponent with accompanying the ViewModelScope. It means all Hilt ViewModels are provided y the ViewModelComponents which follows the same lifecycle as a Jetpack’s ViewModel . (Survives screen rotations)
A
@ViewModelScopedtype will make it so that a single instance of the scoped type is provided across all dependencies injected into the Hilt View Model. Other instances of aViewModelthat requests the scoped instance will receive a different instance. Scoping to theViewModelComponentallows for flexible and granular scope since View Models surive configuration changes and their lifecycle is controlled by the activity or fragment.
So If we want to provide some business instances related to network, database which has their own loading status, we have to provide it via the ViewModelComponent.
HiltViewModel
Previously, we used ViewModelInject with Assisted annotation for getting a SavedStateHandle in ViewModels. But in Hilt 2.31, HiltViewModel is newly introduced and we use it and inject instead of the ViewModelInject and Assisted.
Assisted Inject
Dagger 2.31 now supports assisted injection.
Assisted injection is a dependency injection (DI) pattern that is used to construct an object where some parameters may be provided by the DI framework and others must be passed in at at creation time (a.k.a “assisted”) by the user.
We have been used Square’s AssistedInjection and Google’s AutoFactory before. But now we don’t need to add more third-party dependencies and we can reduce a few extra boilerplates to integrate with Dagger. We can implement it using the AssistedInject and Assisted annotations. Furthermore, we don’t need to install AssistedInject_AssistedInjectModule. Here is an example of injecting specific parameters into ViewModel manually using the assisted injection.
And now we can inject the Factory and ViewModels in DetailActivity .
Hilt + Navigation + Compose + ViewModel
The other news is that the Google team is preparing to release the compose & navigation supports using Hilt. This is good news for the compose and navigation users.
HiltWorker
Hilt-worker extension also will be changed soon. If you are using the worker extension, hold on a bit before releasing the next version. It is scheduled to be released on January 27th or after. Workers can be injected using the HiltWorker and AssistedInject annotations.
Conclusion
The goal of Hilt is to make it easier to set up DI environments and enable developers to focus on their business codes and Dagger binding definitions. Also, Hilt provides specific predefined components and corresponding scopes for developers, so it prevents misusages and reduces much of the initial setup time. Simplicity that comes from Hilt using monolithic components and its results in reducing time for constructing DI environments is the most powerful side of Hilt. It’s still alpha, but it seems good to use in the real project. And I’m more looking forward to the next releases and future.
You can check out the full usage source code of Hilt in the below link.
