Coder Legion - Recent posts tagged dependecyinjection

Koin vs Dagger 2 vs Hilt: Which should we use?

Wed, 23 Apr 2025 04:26:52 +0000

Have you ever heard about Dependency Injection? If you haven’t heard it before, let’s break down Dependency Injection (DI) in the simplest way possible.

Imagine you’re building a coffee machine. Instead of the machine creating its own coffee beans and water, you provide them from the outside. This way, you can easily swap out different types of beans or water sources without rebuilding the entire machine.

In coding, Dependency Injection (DI) works the same way. Instead of a class creating its own dependencies, they’re injected from the outside. This makes your code more flexible, testable, and easier to manage. Android frameworks like Dagger 2, Hilt, and Koin help automate this process, so you don’t have to manually pass everything around.

These three are popular DI frameworks used in Android development. They help manage object creation and dependency resolution, making code cleaner, more modular, and easier to maintain. Let’s deep dive into among of these three and compare them by performance, usability, and community support.

Performance

When comparing Koin, Dagger 2, and Hilt for dependency injection in Android development, performance plays a crucial role. Dagger 2 is a compile-time dependency injection framework, meaning it generates code at build time, leading to optimal runtime performance with minimal overhead. Hilt, built on top of Dagger 2, maintains the same compile-time benefits while simplifying its setup. Koin, on the other hand, is a runtime dependency injection framework that uses reflection and service locators, making it slightly slower than Dagger 2 and Hilt, especially in large-scale applications. While the difference may not be significant for smaller apps, it can impact performance in more complex dependency graphs.

Let say we demonstrate a “hello world” app using among of them and this is the result:

from the illustration above we can conclude:

Koin: Koin’s compile-time is the fastest because it primarily relies on Kotlin’s reflection and doesn’t involve extensive code generation.
Dagger 2: Dagger 2’s compile-time is significantly longer due to the code generation process, even for a simple app.
Hilt: Hilt, being built on Dagger 2, also involves code generation, but it’s often more optimized for Android and might have slightly faster compile times than raw Dagger 2 in a very small project.

Usability

In terms of usability, Koin is the easiest to implement, requiring minimal boilerplate code with a simple DSL for defining dependencies. Dagger 2 is more complex due to its annotation-based approach, requiring knowledge of components, modules, and generated code. Hilt simplifies Dagger 2’s complexity by introducing annotations like @HiltAndroidApp and @Inject, making dependency injection easier to manage while still leveraging compile-time validation.

Community Support and Documentation

Regarding community support and documentation, Dagger 2 has been widely adopted in the Android ecosystem for years and has extensive documentation. Hilt, as an official AndroidX library, benefits from strong Google backing and comprehensive guides. Koin, while popular among Kotlin developers, has a smaller but growing community. Its documentation is clear but not as extensive as Google’s offerings. Ultimately, Dagger 2 and Hilt are preferred for performance-sensitive and large-scale projects, while Koin is an excellent choice for developers seeking simplicity and faster integration.

Below are example implementations of Koin, Dagger 2, and Hilt:

Koin Implementation

// Define a module
val appModule = module {
    single { UserRepository() }
}

// Start Koin
class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            modules(appModule)
        }
    }
}

// Inject dependency
class MyViewModel(private val repository: UserRepository)

Dagger 2 Implementation

// Define a module
@Module
class AppModule {
    @Provides
    fun provideUserRepository(): UserRepository {
        return UserRepository()
    }
}

// Define a component
@Component(modules = [AppModule::class])
interface AppComponent {
    fun inject(activity: MainActivity)
}

// Inject dependency
class MainActivity : AppCompatActivity() {
    @Inject lateinit var repository: UserRepository
}

Hilt Implementation

// Define a module
@InstallIn(SingletonComponent::class)
@Module
object AppModule {
    @Provides
    fun provideUserRepository(): UserRepository {
        return UserRepository()
    }
}

// Inject dependency
@HiltAndroidApp
class MyApplication : Application()

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    @Inject lateinit var repository: UserRepository
}

Choose wisely what framework you want to use, these trio have pros and cons. You can choose and implement it based on your need. Happy coding :)

If you want to know more about Koin framework setup, refer this

Documentation:
Dagger2,
Hilt,
Koin

Koin vs Hilt

Sun, 16 Mar 2025 07:37:25 +0000

In object-oriented programming (OOP), especially in Android Development, to make our program code cleaner and maintainable, one of the principles we are used to apply is SOLID. one of the points in the SOLID principle is Dependency Inversion.

One should depend upon abstractions, not concretions.

Inversion of Control (IoC) is a design pattern used to represent Dependency Inversion in real software.

That makes Dependency Injection popular.

What is Dependency Injection?

Dependency injection (DI) is a software engineering technique that involves making the interactions between objects as thin as possible through specific dependencies. This allows for loosely coupled code — or code that only depends on the required portion of a separate class — to run. And it reduces hard-coded dependencies and allows for cleaner, more flexible code.

some of most popular Dependency Injection frameworks are Koin and Hilt.

Then what's different between Koin and Hilt?

Let’s start by talking about Koin first.

Koin stands out for its simplicity and flexibility. It is a simple DI framework that does not require annotations or code generation. Instead, it makes use of the Domain Specific Language (DSL) provided by Kotlin to specify dependencies and modules.

Koin’s ease of use is one of its benefits. Its minimum setup requirements and its ability to create dependencies with a clear, readable syntax are the aspects that make it stand out. Therefore, Koin is easy for developers who are new to DI.

On the other hand, this features of Koin might come with trade-offs in certain scenarios. Its runtime resolution might lead to potential issues during compile-time if dependencies are not properly configured. Additionally, Koin might not offer the same level of performance optimizations that some other DI frameworks, like Hilt, provide.

How to use Koin?

First, add dependencies to our project’s build.gradle file,

dependencies {
    // Koin core features
    implementation 'org.koin:koin-core:3.2.0'

    // Koin Android features
    implementation 'org.koin:koin-android:3.2.0'
    implementation 'org.koin:koin-androidx-viewmodel:3.2.0'
}

Then, create Koin modules,

import org.koin.dsl.module

val myKoinModule = module {
    single { UserRepository() } 
    factory { UserViewModel(get()) }
    // Define other dependencies...
}

single: create an object that persistent with the entire container lifetime. It does not create a new instance with each call.
factory: create a new object each time. Short live. No persistence in the container

Then in Application class, initialize Koin by loading the modules,

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

This is how we call at Activity

class HomeActivity : AppCompatActivity() {
    private val viewModel by viewModel<UserViewModel>()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Use viewModel or other dependencies...
    }
}

how about Hilt?

Hilt, developed by Google and built on top of Dagger, is a powerful dependency injection (DI) framework tailored for Android. It simplifies DI by leveraging annotations and compile-time checks to ensure correctness and performance. Additionally, it integrates seamlessly with Jetpack libraries like ViewModel and WorkManager, making it easier to manage dependencies across different Android components.

One of Hilt’s biggest advantages is its strong alignment with the Android development ecosystem, making it a preferred choice for larger projects following architectural patterns like MVVM or Clean Architecture. However, its learning curve can be steep due to its reliance on Dagger and the specific annotations required. Compared to Koin, Hilt may also involve a more complex setup, but it offers better compile-time safety and performance benefits.

How to use Hilt

Add Hilt dependency at our project’s build.gradle file,

dependencies {
    // Other dependencies...
    implementation "com.google.dagger:hilt-android:$hilt_version"
    kapt "com.google.dagger:hilt-compiler:$hilt_version"
    implementation "androidx.hilt:hilt-lifecycle-viewmodel:$hilt_lifecycle_version"
    kapt "androidx.hilt:hilt-compiler:$hilt_lifecycle_version"
}

Enable Hilt to our Application

@HiltAndroidApp
class MyHiltApplication : Application()

Creating Hilt modules

@Module
@InstallIn(ApplicationComponent::class)
object MyModule {
    @Provides
    fun provideMyRepository(): MyRepository {
        return MyRepository()
    }
    
    @Provides
    fun provideMyViewModel(repository: MyRepository): MyViewModel {
        return MyViewModel(repository)
    }
}

Using dependencies in Activity/Fragment,

@AndroidEntryPoint
class MyActivity : AppCompatActivity() {
    private val viewModel: MyViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
    }
}

There is 3 different characteristics between Koin and Hilt:

Syntax and Configuration: Koin offers a simple and readable syntax without relying on annotations or code generation, while Hilt heavily depends on annotations like @Inject and @Module for dependency injection.

Learning Curve and Complexity: Koin is beginner-friendly with minimal setup, making it easier to adopt. In contrast, Hilt has a steeper learning curve due to its integration with Dagger and required annotations.

Performance and Optimization: Koin has faster build times and a smaller APK size since it doesn’t generate code, but it is slightly slower at runtime due to resolving dependencies dynamically. Hilt, using code generation, ensures better runtime performance but can lead to longer build times and a larger APK.

So when to use Koin and Hilt?

_Koin _is ideal for smaller projects due to its simplicity and flexibility, making code more modular and maintainable. However, for larger projects requiring deep integration with Android components, _Hilt _is preferable for its performance optimizations and alignment with Android architecture.

references:
_https://medium.com/ibtech/hilt-vs-koin-f3532b5796eb
https://en.wikipedia.org/wiki/Dependency_injection
https://simple.wikipedia.org/wiki/SOLID_(object-oriented_design)_
https://medium.com/@srimanikandan92/hilt-vs-koin-a-simple-guide-to-android-dependency-injection-ef77d00e7cf6

Koin on modularization: How to use it?

Sat, 15 Mar 2025 20:05:51 +0000

What is Modularization in Android?

Modularization in Android means breaking an app into smaller, independent modules instead of keeping all code in a single project. Each module has its own responsibility and can be developed, tested, and maintained separately.

Basic Prerequisites to Understand Modularization

Before learning modularization, you should be familiar with:

Android Project Structure – Understanding how an app is built using
app/src/main.
Gradle & Dependencies – Knowing how dependencies are
managed in build.gradle.kts.
Packages & Code Organization – Basics
of organizing files using packages.
Types of Android Modules – App
Module (Main application)
Library Module (Reusability across
projects)
Feature Module (For dynamic delivery in large apps)

Why Modularization?

✅ Faster Build Times – Only modified modules get compiled.
✅ Better
Code Maintainability – Easier to manage and scale.
✅ Reusability –
Common features like networking or authentication can be shared
across projects.
✅ Parallel Development – Teams can work on different
modules independently.

Today we are going to set up step by step how to use Koin in modularization with viewModel.

Before we get started. Create some new modules and structured them like this:

Step 1

You have to determine what koin gradle version you want to use. For this tutorial, I use 2.2.2 version. Define the gradle into di module

implementation "io.insert-koin:koin-android:2.2.2"
implementation "io.insert-koin:koin-androidx-viewmodel:2.2.2"
implementation "io.insert-koin:koin-androidx-scope:2.2.2"

Step 2

After you have decided koin version you'd use, add other dependency your project would need for injecting to koin in di module as well. In this tutorial I want to inject Retrofit for network, AndroidX Room for local DB, Shared Preferences, ViewModel for managing data, and Coroutine for threading

implementation "io.insert-koin:koin-android:2.2.2"
implementation "io.insert-koin:koin-androidx-viewmodel:2.2.2"
implementation "io.insert-koin:koin-androidx-scope:2.2.2"
implementation "javax.inject:javax.inject:1"

implementation "com.squareup.okhttp3:logging-interceptor:4.9.0"
implementation "com.squareup.retrofit2:retrofit:2.9.0"
implementation "com.squareup.retrofit2:converter-moshi:2.9.0"
implementation "com.squareup.retrofit2:converter-gson:2.9.0"

implementation "com.jakewharton.retrofit:retrofit2-kotlin-coroutines-adapter:0.9.2"

implementation "androidx.room:room-runtime:2.4.2"
kapt "androidx.room:room-compiler:2.4.2"
implementation "androidx.room:room-ktx:2.4.2"

Step 3

Define Network Module, Api Module, Shared Preferences Module, Room Module, and ViewModel Module (we also use UseCase and Repository module for clean architecture principle)

class ApiModule {
    companion object {
        val apiModule = module(override = true) {
            single { provideDisneyApi(get()) }
        }

        fun provideDisneyApi(retrofit: Retrofit): Api {
            return retrofit.create(Api::class.java)
        }
    }
}

class NetworkModule  {
    companion object {
        private fun httpInterceptor() = HttpLoggingInterceptor().apply {
            return HttpLoggingInterceptor { _ ->
            }.apply {
                level = HttpLoggingInterceptor.Level.BODY
            }
        }

        fun provideNetworkHandler(context: Context) = NetworkHandler(context)

        fun provideOkHttpClient() : OkHttpClient {
            return Builder.initInterceptor(httpInterceptor())
        }

        fun provideRetrofitService(okHttpClient: OkHttpClient): Retrofit {
            return Builder.initRetrofit(okHttpClient)
        }
    }
}

class SharedPrefModule {
    companion object {
        fun providePreference(context: Context) : SharedPreferences {
            return context.getSharedPreferences("SharedPreferenceName", Context.MODE_PRIVATE)
        }
    }
}

class RoomModule {
    companion object {
        fun provideRoom(context: Context) : DBConfig {
            return Room.databaseBuilder(context, DBConfig::class.java, "db_sample")
                .fallbackToDestructiveMigration()
                .build()
        }
    }
}

class RepositoryModule {
    companion object {
        val repositoryModule = module(override = true) {
            single<CharacterRepository> { return@single CharacterRepositoryImpl(get(), get()) }
        }
    }
}

class UseCaseModule {
    companion object {
        val useCaseModule = module(override = true) {
            single<CharacterUseCase> { return@single CharacterUseCaseImpl(get()) }
        }
    }
}

class ViewModelModule {
    companion object {
        val viewModelModule = module(override = true) {
            viewModel { GamesListVM(get(), get()) }
            viewModel { GamesDetailVM(get(), get()) }
            viewModel { GamesFavoriteVM(get(), get(), get()) }
        }
    }
}

After you add them all, locate and categorize module that you prioritize as a 'core' module and wrap them into AppModule class. In this tutorial I'll wrap retrofit, room, and shared preferences module like this:

val MainAppModule = module(override = true) {
    single { NetworkModule.provideOkHttpClient() }
    single { NetworkModule.provideRetrofitService(get()) }
    single { NetworkModule.provideNetworkHandler(androidContext()) }
    single { RoomModule.provideRoom(androidContext()) }
    single { SharedPrefModule.providePreference(androidContext()) }
}

Step 4

Call them with StartKoin in Application Class in App Module (default module). I will call ViewModel, Repository, Usecase, and Api module as same level with MainApp Module

class DisneyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidLogger(Level.ERROR)
            androidContext(this@DisneyApp)
            modules(MainAppModule, ApiModule.apiModule, RepositoryModule.repositoryModule,
                UseCaseModule.useCaseModule, ViewModelModule.viewModelModule
            )
        }
    }
}

And Voila! Congratulation you've built Koin in modular version. it's easy isn't it?

Happy Coding :)

Sample project: Github link