Dependency Injection: Dagger-Hilt vs Koin

Why Koin and Dagger-Hilt?

If you are an Android developer, chances are you might have used Dagger, which, undoubtedly, is a great library to implement DI.

But android development is evolving rapidly; with Kotlin, we can write platform-agnostic code in a common module. Meaning the business logic can be written in a single module that can be used by all the supported platforms. We can’t use Dagger2 in Kotlin multi-platform projects. So I did some digging and found this cool, lightweight library called?Koin(with multi-platform support). With less learning curve and boilerplate code, it seems better than Dagger2. Koin is written in pure Kotlin using functional resolution only: no proxy, no code generation, no reflection!

And what about Hilt??Hilt is the new dependency injection framework?built on top of Dagger.?The aim is to reduce the boilerplate code required for Dagger and make dependency injection less painful.

What is Koin?

Koin is a DI framework for Kotlin developers, completely written in Kotlin.

How Koin works ?

Koin works on a simple DSL model. Here we have to create a module first. In this module all the dependent objects are there, then we have to load one or more modules in Koin. Then, we are ready to use this object. Generally, we are loading the module into Koin in the application class by calling startKoin method, then we can inject the object wherever we want, this how the Koin works.

Setting up Koin

// koin
def latest_version = "2.1.6"
implementation "org.koin:koin-android-viewmodel:$latest_version"
implementation "org.koin:koin-android:$latest_version"        

Understanding Terminologies in Koin

• module?— it creates a module in Koin which would be used by Koin to provide all the dependencies.
• single?— it creates a singleton that can be used across the app as a singular instance.
• factory?— it provides a bean definition, which will create a new instance each time it is injected.
• get()?— it is used in the constructor of a class to provide the required dependency.

Now, we will create a package?di -> module?and inside it, we will create ViewModelModule.

we are using viewModel and inside it, we resolve the dependencies which we are providing from viewModelModule.

Now, we are done providing the dependencies. Let us start now by injecting the dependencies.

Now, we need to create the instance of ViewModel in the MainFragment so the values passed in the constructor of the ViewModel are passed to it.

To pass the instance of ViewModel we will create a variable called MainViewModel like,

private  val mainViewModel: MainViewModel by viewModel()        

Here,?by viewModel()?creates the instance for the ViewModel and it will also resolve the dependency required by it.

To initialize Koin in the project we will update the onCreate() of the application like,

class App : Application() {
    override fun onCreate() {
        super.onCreate()
      startKoin{
          androidContext(this@App)
          modules(viewModelModule)
      }
    }
}        

All the instances of required dependency full fill by using koin on kotlin platform in an easy way.

How Hilt Work?

Before starting with Dagger-Hilt we need to understand Dagger basics. In this section, we will help you understand the Dagger and its terminologies.

Basically, to understand Dagger we have to understand the 4 major annotations,

• Module
• Component
• Provides
• Inject

To understand it better in a basic way, think module as a provider of dependency and consider an activity or any other class as a consumer. Now to provide dependency from provider to consumer we have a bridge between them, in Dagger, Component work as that specific bridge.

Now, a module is a class and we annotate it with @Module for Dagger to understand it as Module.

A component is an interface, which is annotated with @Component and takes modules in it. (But now, this annotation is not required in Dagger-Hilt)

Provides are annotation which is used in Module class to provide dependency and,

Inject is an annotation that is used to define a dependency inside the consumer.

Thanks

Jitendra

Reference