Why would I use Android Hilt (Dagger2) when Koin is available

user_423199 0
Viewed 8751

I like to keep the number of third party libraries used in my Android Apps to an absolute minimum.

I had started using Dagger2, then switched to Koin.

Koin is such a great improvement on Dagger2.

Koin has builtin ViewModel support and doesnt need anything "extra" for Workers.

Koin allows you to inject anything anywhere with minimal effort, its superb.

On the Android Hilt announcement I completed a spike to evaluate it, as it would reduce my dependencies on 3rd party libraries.

On completion of my spike efforts I do not see why anyone would use Hilt.

For example:

For Koin to inject into a Worker I have the worker implement KoinComponent, for Hilt to inject into a worker I need to disable the default WorkerManager initialisation, and employ two annotations @WorkerInject & @Assisted.

Am I missing something?

koin dagger-hilt android
2 Answers

I think you have partially answered your question by saying: On the Android Hilt announcement I completed a spike to evaluate it, as it would reduce my dependencies on 3rd party libraries.

But to help you more in your decision, will try to list out the few pointers for both Koin and Hilt below.

Koin:

  1. All written in Kotlin, super-easy to learn, developer-friendly, and very similar to manual dependency injection.
  2. It is a lightweight DSL dependency injection framework written with a service locator pattern.
  3. No annotations used, which means no code generation, this helps in build speed.
  4. Uses scope to manage android component lifecycles.
  5. Resolves dependencies at run-time, as they are loaded lazily, which can lead to RuntimeException later in the application.

Hilt:

  1. Built on top of the dagger, a standard framework for dependency injection, and officially recommended for android development.
  2. Uses annotation to generate code. Official annotations cheat sheet to help you.
  3. It knows about the android component lifecycle.
  4. If you have basic knowledge of Dagger then learning Hilt will be easy.
  5. Hilt resolves dependencies at compile-time, which means it helps with build-time correctness.

Choosing between Koin and Hilt depends on multiple factors for the given scenario, both have their acknowledgeable amount of advantages and disadvantages.

For example: As you said you have already written your project in Koin then if you want to use Hilt, then you might have to re-write all your dependencies graph. If you are using Dagger, then migrating to Hilt will be less difficult.

user_47043270

Stability and available Documentation would be two more reasons to choose Hilt over Koin.

Since I first worked with Koin I became a big fan of it. Especially compared to Dagger. However in my recent (big) project, we decided in favor of Koin (vs. Hilt/Dagger). But we also ran into an (yet unresolved) bug using koins viewModel features in conjuction with latest navigation components from google.

Hilt is officially supported by Google, which means it should have less integration issues and higher stability compared to 'outsider' frameworks.

Also a lot of standard documentation and examples you will find are based on hilt, so if you are using koin you might need to spend some time adapting them for your setting. Fortunately, Koin is pretty straightforward.

As others already have written: Another important difference you should understand: a lot of daggers magic happens during compile time vs Koin working on runtime only. Both strategies come with their pros and cons.

Compile-time has better type safety. And the performance impact is moved to the build time instead of run time[1]. Runtime can lead to late discovery of errors (when Casting or Null Pointer Exception) but makes the framework also more flexibel (but slighty more dangerous).

[1] But I think performance impact of DI is minimal in most settings and mostly overrated by developers trapped in pre-mature optimization.

user_6697720
Related