Hilt: custom entry points
Tags: android
Published: 2021-01-12 23:17:00

---
title: Hilt: custom entry points
published: true
date: 2021-01-12 23:14:03 UTC
tags: Android
canonical_url: https://www.rockandnull.com/hilt-entrypoint-example/
---

 ![Hilt: custom entry points](https://images.unsplash.com/photo-1506375516946-bd12bb039385?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MXwxMTc3M3wwfDF8c2VhcmNofDgzfHxlbnRyeSUyMHBvaW50fGVufDB8fHw&ixlib=rb-1.2.1&q=80&w=2000)

[Hilt](https://dagger.dev/hilt/) is a great dependency injection framework for Android. It has all the strengths of [Dagger](https://dagger.dev/dev-guide/), delivered in an [easy-to-use concise way](https://dev.to/rockandnull/hilt-the-shortest-guide-for-the-di-framework-for-anroid-5b0k).

You annotate your Android classes with just an `@AndroidEntryPoint` annotation and magically your `@Inject`-annotated class members are injected.

The `@AndroidEntryPoint` annotation [supports injection](https://www.rockandnull.com/hilt-entrypoint-example/Activity%20Fragment%20View%20Service%20BroadcastReceiver1) only for some basic system classes: Activities, Fragments, Views, Services, and BroadcastReceivers. But injection is all magic for you. You never see what injects your system classes. What happens when you encounter a system class (or anything that is not instantiated by you) but you need to inject?

That's what I encounter when migrating to Hilt when I figured out that I needed to inject my `Initializer` (from Jetpack's [App Startup](https://dev.to/mavris/jetpack-app-startup-keep-your-startup-logic-organized-3j0k-temp-slug-5922639) library) classes. Here's where the custom entry points come into play.

## Entry point interface

What would you `@Inject` to that class that you don't control? Add an "accessor" method to this `@EntryPoint`-annotated interface to get an instance.  

```
@EntryPoint
@InstallIn(SingletonComponent::class)
interface InitializerEntryPoint {
    fun myHelper(): MyHelper
}
```

Just note that you need to "install" this to the same [component](https://dagger.dev/hilt/components.html) that the injected instance belongs to. So if you need instances that might be Activity-scoped and Singleton-scoped, you might need more than one entry point interfaces.

## Where to add the entry point interface?

According to the [official docs](https://dagger.dev/hilt/entry-points.html), ideally these interfaces should be close to the objects they are used from, rather to the objects they are providing. For instance, in the Jetpack's App Startup `Initializer` example, these interfaces should be defined inside the initializers.

```
class MyCoolInitializer : Initializer<Unit> {

    [...]
    
    @EntryPoint
    @InstallIn(SingletonComponent::class)
    interface InitializerEntryPoint {
        fun myHelper(): MyHelper
    }
}

```

This is for making it obvious that these entry point interfaces exists only for these special-case classes that cannot be `@Inject`-ed. All other cases should use standard `@Inject` and `@AndroidEntryPoint` annotations.

## How to use them

Finally, to use those Entry Point interfaces, use a static Hilt method and access those "accessor" methods to get your instance!

```
val myHelper = EntryPoints.get(applicationContext, InitializerEntryPoint::class.java).myHelper()

```

Happy coding!