Kotlin dependency injection: Koin vs. Hilt

Dependency injection is a extensively used approach that enables programmers to offer any class with its dependencies, as an alternative of getting the lessons get hold of them themselves. This system can also be thought of effectively suited to the Android growth ecosystem. As Android’s official documentation suggests, dependency injection permits programmers to put the groundwork for good app structure by permitting for a number of benefits just like the reusability of code, ease of refactoring, in addition to ease of testing.

Due to its many benefits, in addition to the decoupling nature of this sample, dependency injection is nearly a should for each trendy Android challenge. And with so many choices for libraries and instruments to attain dependency injection, or DI, it may be tough to determine what framework to make use of.

On this article, we’ll discover the 2 hottest DI libraries for Fashionable Android Improvement (MAD): Dagger’s Hilt, and newcomer, Koin.

To leap forward:

Hilt

The Hilt framework is a layer on high of the Dagger DI library. Extra particularly, Hilt is constructed on high of the Dagger 2 library, which is presently maintained by Google.

Aside from simplifying the Dagger implementation into Android apps, a few of the different targets that Hilt has are standardizing units of parts and scopes to make the Dagger setup simpler, and offering a simple strategy to provision binding for various construct varieties, as defined by its documentation.

In different phrases, utilizing Hilt inherently means utilizing Dagger 2, and so they can each concurrently reside in the identical challenge. Let’s check out Dagger earlier than we dive into Hilt.

A quick historical past of Dagger

In 2012, Sq. revealed the Dagger library for quick dependency injection. 4 years later, Google took up the challenge and launched the brand new and improved Dagger 2, the model of the library that Hilt is constructed on high of.

This open supply library is written in Java, and generates plain Java supply code at compile time to attain its injection evaluation.

How does Dagger work?

Dagger/Hilt makes use of a collection of annotations to point what sort of code to generate for its dependency injection. The principle distinction between Dagger and Hilt is that the Hilt framework routinely generates lots of the Dagger setup code that’s usually wanted by Android initiatives, which saves builders from encountering an excessive amount of boilerplate code.

Right here’s how you’d initialize the Hilt library in your Android utility utilizing the Software object:

@HiltAndroidApp
class App : Software() {
    // Do not forget to declare your Software object within the Manifest!
    ...
}

As soon as your Hilt utility has been initialized, we have to inform Hilt which lessons might be injected as dependencies.

To do that, we’ll want so as to add the @Inject annotation into the lessons’ constructors to ensure that Dagger to declare them for injection:

class InjectedClass @Inject constructor(
    personal val param: InjectedParam
) { ... }

class InjectedParam @Inject constructor() { ... }

Word that every one parameters in a category annotated for injection additionally must be annotated.

After annotating the lessons which are meant to be injected, you must first begin annotating entry factors, or dependency containers which are lifecycle-aware, which permit for dependencies to be injected into them.

It’s only then that we will use the @Inject annotation once more to carry over the dependencies as wanted:

@AndroidEntryPoint
class MainActivity: FragmentActivity() {
    @Inject lateinit var injectedClass: InjectedClass

    override enjoyable onCreate() {
        ...
    }
}

Hilt could make an entry level of many Android lessons, together with Software, BroadcastReceiver, View, Service, and Exercise, however provided that it extends FragmentActivity. Fragment will also be used as an entry level, however in response to Android codelab, it has to increase Jetpack’s Fragment class and never the previous Android one.

Dagger compile-time dependency

The Dagger Hilt framework is a compile-time dependency. Which means that all of the code that it generates occurs at compile time, in addition to all of the error checking, which might set off the construct to fail compilation. This makes it very simple to find out if the present DI technique is defective or not.

Hilt in Fashionable Android Improvement (MAD)

The most important benefit of Hilt is the truth that Google built-in it into their growth ecosystem.

Hilt is Android’s really useful means of reaching dependency injection, and it’s now packaged alongside Android Jetpack.

In keeping with Android’s official documentation, Hilt defines a normal strategy to obtain DI in your utility by offering containers for each Android class in your challenge and managing their lifecycles routinely.

What’s Koin?

Koin is an open supply library by Kotzilla that nearly serves because the antithesis of Dagger/Hilt. Created in 2017, Koin is absolutely written in Kotlin, and it offers a unique means of reaching dependency injection.

The best way Koin achieves dependency injection is so completely different from conventional dependency injection that some declare it isn’t dependency injection in any respect.

Koin makes use of a sample referred to as Service Locator, which, in response to Google, works by offering a registry the place lessons can get hold of their dependencies as an alternative of immediately developing them. In the meantime, conventional dependency injection has one other class offering the dependencies for you.

For extra data on this debate, try Elye’s deep dive on the subject. On this article, we’ll persist with dependency injection when speaking concerning the Koin library and its utilization.

How does Koin work?

As an alternative of guiding itself via annotations, Koin makes use of modules the place we declare all of the lessons, or factories, that will probably be injected as dependencies into different lessons.

Right here’s the way you initialize the Koin library on your Android utility utilizing the Software object:

class App : Software() {
    // Do not forget to declare your Software object within the Manifest!
  override enjoyable onCreate() {
    tremendous.onCreate()
    // Begin Koin
    startKoin {
      // Feed in Context
      androidContext(this)
            ...
    }
  } 
    ...
}

As soon as Koin is initialized, including and injecting dependencies is simple.

All dependencies have to reside in a module object, which you then feed on to the Koin occasion. We will do that within the following means:

class InjectedParam()
class InjectedClass(val subclass: InjectedParam)

val appModule = module {
    single { InjectedParam() }
    single { InjectedClass(get()) }
}

class App : Software() {
  override enjoyable onCreate() {
    tremendous.onCreate()
    // Begin Koin
    startKoin {
      // Feed in Context
      androidContext(this)
            // Load dependencies module
            modules(appModule)
    }
  } 
    ...
}

As soon as your dependencies are in a module, you possibly can inject immediately into your supply code through the use of the inject delegate perform:

class MainActivity : Exercise() {
    val injectedClass: InjectedClass by inject()

    override enjoyable onCreate() {
        ...
    }
}

Koin run-time dependency

Otherwise to Dagger/Hilt, Koin is a runtime dependency. Which means that not solely does it not generate any code in compile time, however it is not going to complain about lacking dependencies whilst you’re constructing your challenge.

As an alternative, an exception will probably be thrown in case your app is lacking dependencies, seemingly adopted by a crash.

Koin in Fashionable Android Improvement (MAD)

The most important benefit to Koin is that it’s absolutely written in Kotlin. With MAD transferring in the direction of a extra Kotlinized ecosystem, there are numerous benefits to utilizing Kotlin libraries in Kotlin-first initiatives.

Moreover, and since it doesn’t reside as a layer of one other library, Koin may be very light-weight, and doesn’t add extra compilation time to your challenge.

Evaluating Dagger and Koin options

Now that we’ve examined each of those libraries’ backgrounds and specs, let’s revisit a few of the specifics of their implementations, and examine them to get a greater sense of their variations.

Ease of use

I feel the primary and most essential query to ask when evaluating Dagger/Hilt and Koin is: which one is less complicated to make use of? We’ve already gone over the best of examples for the best way to initialize and use each of those libraries, so it actually is dependent upon private desire.

When you’re the form of developer that enjoys utilizing annotations throughout your challenge to higher seize intent, then Hilt may be the higher choice, with the intention to use that facet of growth.

However, the broader opinion is that Koin is less complicated to handle than Hilt. Not solely does Koin preserve the code fairly centralized, relatively than having to tag every particular person object, however it additionally makes use of Kotlin’s newest and best to facilitate the entry and injection of your dependencies. And in the event you merely love your annotations both means, Koin has an annotation technique that can be utilized instead or along side their common utilization.

Dealing with errors

Realizing when your dependency injection technique is incomplete, or if it fails, is essential. As a result of each Dagger/Hilt and Koin libraries are processed otherwise, this process additionally differs vastly between each choices.

Whereas Hilt compile-time dependency permits us to find errors rather a lot sooner via a compilation error, Koin will construct accurately, and solely categorical its runtime exception if the defective dependency is triggered.

Each libraries have their benefits and downsides, as Hilt’s compile-time evaluation additionally makes the construct time of the given utility slower in consequence.

Influence on efficiency

Every library’s dependency kind comes with completely different impacts on efficiency.

Hilt’s compile-time evaluation and sophistication era vastly impression the compile time of your utility, however every little thing will get sorted earlier within the construct lifetime as effectively, leaving your runtime efficiency intact.

However, Koin’s runtime dependency and code evaluation sightly impacts the runtime efficiency of your utility, as a result of all dependencies must be sorted whereas the applying is operating as an alternative of doing so a priori.

Dagger vs. Koin

At this level, you should be asking your self: So, which one is best? In the end, this is dependent upon the main points of your challenge, the scale, age, total expertise of the group. I can’t prescribe an answer for you — that’s a call every growth group should make for themselves!

When you’re studying this text in an try to determine between these libraries on your challenge, right here are some things I recommend contemplating:

1. If in case you have a relatively younger or new challenge, take into account selecting the library that shares the identical principal language as your challenge; i.e., Java initiatives can work with Dagger, whereas Kotlin initiatives as an alternative choose Koin
2. When you take into account your self to be extra of a novice developer and don’t wish to be bothered a lot with DI, Koin is be a very good choice as a result of it’s thought of simpler to be taught and use
3. When you’re a developer that loves studying documentation, Hilt could also be a greater resolution because the Android Builders web site has thorough documentation, use circumstances, and even an official codelab, so that you can comply with
4. Whereas I didn’t go over Dagger 2’s superior utilization on this piece, a challenge which will require extra superior utilization of DI ought to most likely select Hilt, as to have everything of Dagger obtainable when wanted
5. In case your challenge makes use of, or is meant to make use of, the Kotlin Multiplatform instruments for growing iOS apps that reuse your Kotlin code, Koin would most likely be a greater resolution, because it presently helps the DI sample as a part of Kotlin’s Multiplatform for iOS

And if these pointers aren’t convincing sufficient, right here’s a chart evaluating their attributes which you could comply with as an alternative:

Conclusion

Selecting a dependency injection library shouldn’t be a burden. Do not forget that selecting a DI library shouldn’t be an architectural determination, however part of implementation particulars. Which means that no matter you select on your challenge, make it possible for it’s built-in in a means that makes it simple to switch, within the case that the preliminary determination ages poorly, or the choice choices turn into extra handy over time!