Dagger/Hilt vs. Koin for Jetpack Compose Apps | by Patryk Kosieradzki | Mar, 2022

Photograph by Mateusz Wacławek on Unsplash
  • Code technology vs. no code technology
  • Impression on construct time vs. impression on runtime and injection time
  • And clearly Hilt is really useful and maintained by Google, whereas Koin will not be. In fact, Google doesn’t say that Koin is dangerous and to make use of what you suppose matches higher to your undertaking.

Google recommends Hilt for Android apps however that’s only a suggestion! Use what you suppose it’s good for you.

  • The primary case — when your app is written in pure Jetpack Compose, that’s, with out utilizing Fragments, so that you’re in all probability utilizing navigation-compose library.
  • And the second case — if you use Fragments and ComposeView (Interoperability), which for my part is your best option (at the least for now), largely due to the dangerous Navigation-Compose API and lack of sort security. That is fairly an enormous and controversial subject, however hey, that is what I like probably the most. Be sure you examine my article about this.

Jetpack and Assist

Simpler to implement than Dagger

Compile-time errors

Testing

@HiltAndroidTest
class SettingsActivityTest

@get:Rule
var hiltRule = HiltAndroidRule(this)

// UI assessments right here.

Course of dying

Slower construct time

Typically it’s a must to write Dagger code

You may’t inject something apart from ViewModel into Composables (at the least for now)

  • To delegate UI logic/work to different courses from Composables, so your code is extra reusable and concise.
  • To render UI in a different way, primarily based on knowledge you get from particular dependencies like AppConfig or one thing else that doesn’t actually make sense to place within the ViewModel’s logic (as a result of there’s no logic). Instance: I need to show extra textual content within the Composable if I’m at present in DEBUG mode. I’ve the isDebug: Boolean worth in AppConfig singleton.
  • One other instance: Let’s say you might want to have a number of Coil ImageLoaders and also you need to use them in a few of your Composables. You may’t inject them instantly into the Composable, so that you’d in all probability need to go them from the Exercise to the NavGraph after which both go it by way of Composable params or use CompositionLocalProvider.

Approach simpler to make use of than Dagger and Hilt

You may inject dependencies into Composables

@Composable
enjoyable SomeComposable(myService: MyService = get())
// ...

Extra informative error logs

[Hilt]

No code technology

Rather more DI code, particularly get(), get(), get()… get()

val appModule = module 
single DogRepository(get())

manufacturing facility GetDogUseCase(get())

viewModel
DogDetailsViewModel(get())

val appModule = module 
single
DogRepository(get(), get(), get(), get(), get())

manufacturing facility
GetDogUseCase(
repo = get()
cacheRepo = get(),
service = get(),
somethingElse = get()
)

viewModel
DogDetailsViewModel(
think about = get(),
a = get(),
lot = get(),
of = get(),
dependencies = get(),
right here = get()
)

Points with SavedStateHandle when not utilizing Fragments

Impression on runtime efficiency

Supply: https://github.com/Sloy/android-dependency-injection-performance

More Posts