A New Android Dependency Injection Framework

We’ve used a lot of dependency injection libraries in the short history of Android tablet development. RoboGuice was the first. It was ported from Google’s Java DI system “Guice,” which had some bugs but gained a lot of traction among Android developers. Then there was Dagger, who was introduced by Square. Dagger does not rely so much on reflection as RoboGuice does, because of its precompiler which makes it much faster and more mobile. Many Android developers were persuaded to migrate due to the performance advantage.

The Google team subsequently published Dagger 2. In comparison to its predecessor, it improved performance even further. Dagger 2 creates its dependence graph for compilation time, which completely eliminates the need for reflection. The library of Google is already the preferred framework of the developer community. Dagger is the dependency injection solution used by over 50 thousand apps on Google Play.

Dagger 2 is a fast and trustworthy system but has certain imperfections. There’s a steep learning curve and a lot of boilerplate. It’s really difficult to manage. Google has created Hilt, a new DI solution, to fix these problems.

The hilt is a library based on Dagger 2, which promises to facilitate development.


Why do we use a Dagger-like dependency injection system in Android?

Consider how difficult it becomes to construct a large number of objects that are dependent on a large number of other objects as the project grows larger. We would need some strong external help to handle the code base as it grows. One of the use-cases for which we employ a dependency system for Android tablet development is this.. Let’s look at an example to better understand this use-case.

Hilt Integration

If you know Dagger, you know that you need to create suitable components and modules to integrate DI in your application. You would need some boilerplate to inject your dependencies in Android classes such as activity, fragment, service or customized views. Fortunately this is much easier integration with Hilt.


First, create a custom application class and then properly annotate it.



class HiltApplication : Application() {



The only thing we have to do, as you see, is to include annotation @HiltAndroidApp. Once that has been done, we must annotate correctly Android classes in which some dependencies need to inject.



class MainActivity : AppCompatActivity() {


Here, with @AndroidEntryPoint annotation, we annotated our main activity. We can now inject certain fields into our activity. Let’s build a dependency that we might want to inject.


class FileLogger @Inject constructor() {


Now thanks to @Inject annotation, we can inject our FileLogger to MainActivity class.



class MainActivity : AppCompatActivity() {


lateinit var fileLogger: FileLogger



Hilt Components

In our application the basic integration of Hilt was completed. Now, we will deal with their approach to part management as the main distinction between Hilt and Dagger.

For each application screen, Dagger proposed creating different components and modules. Although there are benefits to this approach, such as loose coupling and a high degree of modularisation, the resulting code is often complex and difficult to understand. Hilt, on the other hand, uses a small number of predefined components and discourages the production of new ones.

You have the same ActivityComponent both of your operations, and your fragments have the same FragmentComponent all of them. It implies that if there is dependency in one activity, it is there in all.

The hilt also provides predefined scopes in addition to predefined components for Android tablet development. Hill will deliver the same instance of the dependency under the specified activity component if a dependency is annotated with @ActivityScope.

To clarify it, let’s examine some code.

We will first define an ActivityComponent module to be installed.

Hilt-related problems

We believe Hilt is a very promising framework, and we want to start using it in production as soon as possible. Unfortunately, there are some issues with it that we should discuss.

  • The hilt is currently in alpha, and the API has not been finalized. Future API changes could necessitate a significant amount of additional work from our development team, which could be expensive.
  • The hilt is currently not the most secure library, and odd bugs are popular. Injection to custom views, for example, is currently broken at the time of writing this post.
  • There’s also the option of a longer compilation period. Hilt introduces a number of new functionality to the Dagger library, which could necessitate extra processing. If you plan to move to the Hilt platform, we recommend that you profile your build time.


Final thoughts

This article should have given you a clear idea of what Hilt can do for your Android tablet development and how you should use it in your ventures. Unfortunately, as previously reported, Hilt is not yet ready for release, so we chose to wait for the beta version.


About the author


Add Comment

Click here to post a comment





CopyAMP code