DEV Community: Patryk Kosieradzki

Dagger/Hilt vs Koin for Jetpack Compose apps

Patryk Kosieradzki — Mon, 14 Mar 2022 22:03:15 +0000

See the original article on my website

Intro

Ahh, here we go again. The eternal struggle between Dagger/Hilt and Koin. I expect a lot of arguments again in the comments about which one is better, but don’t worry guys, this article was created only to show you the main differences between them. Both of them are great, so you have to choose which one you want to use on your own, BUT I hope I’ll make this choice a little easier for you by showing you their advantages and disadvantages for Jetpack Compose apps!

For the purposes of this article I’m gonna assume that you already know what Dependency Injection is and what are the main differences between Dagger/Hilt and Koin, for example:

Code generation VS no code generation
Impact on build time VS impact on runtime and injection time
And obviously Hilt is recommended and maintained by Google, while Koin is not. Of course, Google does not say that Koin is bad and to use what you think fits better to your project.

Here’s Manuel Vivo’s opinion about Koin, for example:

Google recommends Hilt for Android apps but that’s just a recommendation! Use what you think it’s good for you.

Source: medium.com

If none of this sounds familiar then you should probably stop reading for a moment and first figure out what Dependency Injection, Dagger, Hilt and Koin are before continuing.

Let’s roll

Okay, so now let’s compare Dagger/Hilt and Koin.

To best present the PROS and CONS of each of these tools, I will consider two cases where you can use Jetpack Compose to write Android Apps:

The first case — when your app is written in pure Jetpack Compose, that is, without using Fragments, so you’re probably using navigation-compose library.
And the second case — when you use Fragments and ComposeView (Interoperability), which in my opinion is the best choice (at least for now), mostly because of the bad Navigation-Compose API and lack of type safety. This is quite a big and controversial topic, but hey, this is what I like the most 😎

Be sure to check my article about this.

Also, if you’re a Polish speaker, you can listen to my “Android Talks” Podcast episode about it: https://androidtalks.buzzsprout.com/1820265/9680778

PROS of using Hilt in your app

So what are some of the good things about Hilt?

Jetpack and Support

First of all, Hilt is a part of Jetpack and currently Google recommends that you use it in your Android Apps. Of course, that’s not a big deal, but I must say it’s really nice that Google created it, as some of you may know, using Dagger was not always as nice and enjoyable as we would like it to be — especially for programmers who were just starting to learn Dependency Injection in Android.

Easier to implement than Dagger

Second thing, like I’ve just mentioned, if you were using Dagger before and you liked it, you’re gonna LOVE using Hilt!

New annotations like @AndroidEntryPoint or @HiltViewModel make it much easier to manage DI code in your Android classes.
Creating modules is now less complicated with Generated components for Android classes like SingletonComponent, ViewModelComponent, etc.
And much more! Check out everything here.

Compile time errors

Dagger and Hilt are compile-time dependency injection frameworks. It means that if we accidentally forget to provide some dependency or we mess something up the build is gonna fail and our app won’t run at all.

Koin will behave differently in this situation. As you know Koin does not generate any code, so if we mess something up with DI the project will build anyway, but it will crash at start or later on some specific screen.

The developer would have to check whether the dependencies in this specific part of the app are working well and the app does not crash. Dagger/Hilt is much safer to use in that case.

Testing

The next big thing is TESTING. For sure, writing Unit, UI, E2E, etc. tests was already possible with Dagger, BUT what we get from Hilt now is much, much more! Forget about complicated tests with Dagger. Now you have HiltAndroidRule to manage the component’s state and to inject different dependencies to tests easier.

@HiltAndroidTest
class SettingsActivityTest {

  @get:Rule
  var hiltRule = HiltAndroidRule(this)

  // UI tests here.
}

You can easily replace and mock dependencies or even the whole modules on the fly. Also, you can launch your Fragments (if you’re using them) in a special test container launchFragmentInHiltContainer. If you’re not using Fragments or you want to test only the Composable, you can easily do that with ComposeTestRule, where you can pass your ViewModel and other dependencies directly to the Composable Function (example on my Github). It is also possible to automatically mock every ViewModel in your UI tests, so the test setup is only a few lines of code 😉.

Process death

Securing your app against process death is also a lot easier with Hilt. You can simply inject SavedStateHandle to the ViewModel (which is just a fancy StateHandle map) to store and restore data that needs to be saved in case of process death.

CONS of using Hilt

Is Hilt flawless? Let’s find out 🤔

Slower build time

As most of you probably know Hilt generates some files during build time, which means that the bigger the app and the more modules, components and dependencies you have, the longer your build time is gonna get 🐢.

Sometimes you have to write Dagger code

While using Hilt is much easier than it was with Dagger, sometimes you will still need use Dagger code in your app. If you want to create separate android modules per features in your app then you’ll have to write some of your code in the old fashioned way with Dagger. First, you have to create a custom EntryPoint module, combine it inside the component’s builder and then programatically inject it into the Activity or Fragment that hosts the feature. You can read more about it here.

You can’t inject anything other than ViewModel into Composables (at least for now)

One of the major flaws for me is the fact that if you’re writing a Compose only app without Fragments you can’t inject dependencies into the Composables, other than ViewModels.

Probably a lot of you are wondering now, why would you even need something like that at all?

Well, first of all this is certainly a loss of functionality, because before Compose we were able to inject dependencies into Fragments, Activities, etc. and now as Fragments were “replaced” by Composables you’d expect that this feature should be still there, right?

So can you give me some examples when it would be useful?

Sure. Here are a few examples:

To delegate UI logic/work to other classes from Composables, so your code is more reusable and concise.
To render UI differently, based on data you get from specific dependencies like AppConfig or something else that doesn’t really make sense to put in the ViewModel’s logic (because there’s no logic). Example: I want to display additional text in the Composable if I’m currently in DEBUG mode. I have the isDebug: Boolean value in AppConfig singleton.
Another example: Let’s say you need to have multiple Coil ImageLoaders and you want to use them in some of your Composables. You can’t inject them directly into the Composable, so you’d probably have to pass them from the Activity to the NavGraph and then either pass it through Composable params or use CompositionLocalProvider.

Can this problem be solved easily? Yes.

As I told you before, I prefer using Compose with Fragments and this is another reason why I still use them. You can just inject dependencies inside Fragments and then pass them along to Composables.

And what if I want to pass the dependency really deep into the Composable tree?

Well, first think twice if you really need to pass it. If the answer is still yes then you can either pass the variable through each Composable down the tree or you can think about using CompositionLocalProvider. This requires you to write additional code, but it’s still an option.

And how does this relate to Koin?

Let’s star with PROs.

Way easier to use than Dagger and Hilt

First of all, Koin is definitely much simpler to use and to learn than Dagger or Hilt. It can be a good choice for novice programmers that want to learn Dependency Injection.

You can inject dependencies into Composables

Unlike Dagger or Hilt, Koin allows us to inject dependencies into Composables.

For example:

@Composable
fun SomeComposable(myService: MyService = get()) {
   // ...
}

This solves the problem I’ve mentioned before and is really nice to have when we don’t use Fragments.

More informative error logs

If you used Dagger or Hilt before (especially Dagger) you may have noticed that they don’t give much info in the logs about errors that occur and you often have to guess and figure out what is really wrong.

For example, in some cases Hilt would just tell you

[Hilt]

and that’s all.

Of course over time these problems were fixed and you’ll see more info now, but still Koin wins this fight and has more informative logs when errors happen.

No code generation

Koin won’t generate any code at all. This means that your build times will be quicker 🏃

CONS

Much more DI code, especially get(), get(), get()… get()

As I mentioned before, Koin is much easier to implement, but it comes with a price — much more code. Every singleton, factory, viewModel, etc. you want to inject you have to add to your modules first.

For example:

val appModule = module {
   single { DogRepository(get()) } 

   factory { GetDogUseCase(get()) }
   viewModel {
      DogDetailsViewModel(get())
   }
}

So if you have a lot of arguments in your dependencies your modules could end up like this:

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

   factory { 
      GetDogUseCase(
         repo = get()
         cacheRepo = get(),
         service = get(),
         somethingElse = get()
      ) 
   }
   viewModel {
      DogDetailsViewModel(
         imagine = get(),
         a = get(),
         lot = get(),
         of = get(),
         dependencies = get(),
         here = get()
      )
   }
}

And this is only one ViewModel and one Repo / UseCase. Imagine how bad it will look in a bigger app…

Issues with SavedStateHandle when not using Fragments

Currently it’s not possible to inject SavedStateHandle to your ViewModels if you don’t use Fragments and inject your viewmodels straight to the Composables. If you try to do that you’ll get an error. This should be fixed soon, but it is something you have to consider if you want to preserve screen state in case of process death.

Impact on runtime performance

As I mentioned before Dagger/Hilt has a significant impact on build time due to code generation. On the other hand Koin also affects time, but not build, but runtime. Koin has slightly worse runtime performance, because it resolves dependencies at runtime.

You can find all of the results here

Summary

So which DI should you choose to use? You have to decide yourself. I must admit I’m not a huge fan of Dagger (sorry Dagger lovers), but I would still recommend learning it.

At the end of the day it’s not about which one is better but which one allows you to write clean code that is easy to test and maintain. I used all of them (Dagger, Hilt, Koin) in a few projects before and I think all of them (especially Hilt and Koin) match this criteria.

Check out my other articles:

Why using Navigation-Compose in your Jetpack Compose app is a bad idea

Patryk Kosieradzki — Tue, 01 Mar 2022 23:03:11 +0000

See the original article on Medium:

Why using Navigation-Compose in your Jetpack Compose app is a bad idea | by Patryk Kosieradzki | Feb, 2022 | Medium

Patryk Kosieradzki ・ Feb 14, 2022 ・
Medium

And other articles about Android on my website:
https://patrykkosieradzki.com

Intro

If you’re reading this article, you’re probably thinking:

“Hmm I wonder what to use to navigate in my Jetpack Compose app. Should I use navigation-compose as sugested by Google or stick with Fragments and use Compose only for rendering views?”

In this article, I’m going to talk about my experience with both Navigation-Compose and Fragments in a Jetpack Compose app. You will learn which approach is better (in my opinion) and what obstacles may await you by using each of them.

Podcast!

If you’re a Polish speaker, you can listen to a podcast I’ve made about this topic:
https://www.buzzsprout.com/1820265/9680778

Let’s start

If you Google “Jetpack Compose Navigation” you will probably see the Navigation-Compose library as one of the first results. Google describes it as a new navigation component that supports apps written in Compose and claims that thanks to it we can navigate between composables while taking advantage of the Navigation component’s infrastructure and features.

Sounds perfect, but is it? We should talk about what the new navigation looks like…

Google really wanted to create a Framework that would be able to manage lifecycles, navigation and everything around it while eliminating the need to use Fragments. They came up with the idea to create a navigation graph as Composable (NavHost) instead of an XML file, where we can define routes to which the application can navigate. In fact, if you look closely, Fragments are replaced by navBackstackEntry in this way. Unfortunately, it doesn’t work very well and there are a lot of issues with it.

Route paths

First of all — route paths.

Google probably envied Flutter, React and other similar Frameworks and thought that the best solution for Android would be to define screen routes as in a web app — despite the fact that we create mobile applications, not web ones, right?

What does this mean for us?

This means that each route looks like an URL ending, e.g.

/users — for the user list screen
/users/2 — for the detail screen for user with id = 2.

From now on, the developer must maintain the order of the paths and their parts, remember them and their params, or create constants for individual screens, which already means that we have a lot more work to start than before.

What comes next is even more confusing.

Navigation arguments

Earlier, using Fragments and Safe Args, we could define in XML what arguments a given Fragment takes. When creating an action from one screen to another, we had an automatically generated code that asked us for arguments of the correct type and packed them into the Bundle. Next, to extract these arguments in the target Fragment, we can use the by navArgs() delegate for example, which will do it for us automatically.

We were able to pass a lot of different types as parameters, such as Int, String, Boolean, etc. but also custom ones, such as Enums, Serializables and Parcelables. The full list of supported types can be found here.

Is it just as convenient in navigation compose? NOT AT ALL

Arguments can be passed only in the URL path of a given route, for example:

Path params /users/{arg1}/details/{arg2}
Or to make it even more complicated, you can also pass query params and optional parameters after the question mark /users/{arg1}/details?{arg2}={arg2_value}&{arg3}={arg3_value}

Oh, and don’t forget that for each destination and param that you want to use, YOU are responsible for all of the type safety. Compose navigation is not going to tell you that you mistook an Int param as a String. It will just crash the app.

Each param has to be declared in composable in the NavHost:

And also extracted with a proper type later:

So now, not only that the programmer has to manage all routes himself, he also has to remember what arguments are taken by a particular screen and what are the keys and data types of parameters and their order.

Will you get the errors at compile time that you messed something up? Nope. You will get an error or an app crash only while the app is running.

Everything is a String

Also, don’t forget that since the screen route is like an url, each parameter must be passed anyway as a String and must be encoded.

Let’s say we want to pass this String as a param:
val urlParam = "https://translate.google.com/?hl=en&tab=TT"

To navigate with it we have to write this:
navController.navigate("path/arg=${URLEncoder.encode(urlParam)}")

And then receive it like this:
URLEncoder.decode(bundle.getString("arg_key"))

Even better, if you use URLEncoder.encode(…) over a String that contains a ‘\n’ character, it will crash because of the ‘%0A’, so the only way to make it work is to use Base64 encoding first.

This makes the Navigation-Compose API completely NON type safe.

What about Enums, Serializables and Parcelables?

Like I’ve mentioned before, any argument we want to pass, regardless of type, has to be converted to a String in order to add it to the path.

Enums
Compose navigation won’t let you pass Enums as params, but this can be done differently. In theory, we can convert it into a String, and call the valueOf method on the target screen to find the value in the enum that we previously passed as String.

Parcelables and Serializables
This is where the fun begins. Passing Serializable and Parcelable as a navigation param in Compose-Navigation is not supported too.

I see a lot of people on the Internet saying that it is possible to get into the backStackEntry arguments and manually pass the object there that extends Serializable or Parcelable.

HOWEVER
This is just a hack that Google does not recommend and does not give any guarantee that this will work.

Personally, I have had a lot of situations where passing arguments in this way caused the app to crash.

Don’t believe me? Just go here and read:
https://issuetracker.google.com/issues/182194894

Is there anything we can do?
Well, theoretically… yeah. We could convert our Serializable or Parcelable object to JSON and pass it as a String. I feel sorry for anyone who would like to pass params this way. This is a way to do it, but it’s so stupid and brings so much unnecessary boilerplate and complexity that I won’t even consider using it.

UPDATE!
Since Compose version 1.0.3 and NavigationX 2.4.0-alpha10 we are now able to create a custom NavType:

Let’s say you have a class like this:

You can define the NavType like this:

And use it:

This seems better than what we had before BUT still requires us to use JSON inside. Also imagine creating a new custom NavType every time you want to pass a Parcelable. This just adds more boilerplate code to our app. Moreover there is no mention in the documentation from Google that this solution will work with Compose-Navigation too.

BUT WHY?

And now the main question arises — why?

Why is Navigation-Compose like that? Why doesn’t it support Serializables, Parcelables and why does it have so many issues?

It is very possible that Google wants to encourage developers to pass only id of the object and not the static copy of it. It would make sense if, for example, we were operating on the Room database and observing the data using Flow. For example, if something in the meantime changed this data, then the user would automatically see the current values on the screen.

Indeed, maybe in a few cases like this, it would make sense. Unfortunately, there are often situations in which we want to consciously pass a static object, or at least some part of it so that the user immediately sees the data on the screen. After that, we could load some details in the background or simply check if the data is up-to-date.

Just use Fragments

Okay, then how should I use Compose to avoid these problems? The answer is simple. Use Fragments and old navigation.

Reasons why you should still use Fragments
You can use whatever you want: XML, Compose, you choose. The easiest way is to add ComposeView to the Fragment view and set Composable of the given Fragment there.

Not a fan of LaunchedEffect, DisposableEffect and so on? You don’t have to use them as you can write some code the old way, just like it was in Fragments.

Depending on what DI Framework you are using, you may also run into some issues with SavedStateHandle if you use Navigation-Compose.
In my current project, we are using Koin and unfortunately SavedStateHandle cannot be injected into the ViewModel in the new navigation. This problem, of course, has to be fixed by Koin Team, but for now, it disappears if you use Fragments and inject the ViewModel using by viewModel() delegate.

Of course, Fragments aren’t perfect. What issues with them should you consider in this case?

First of all, you are using Fragments. This may seem funny at first, but some people don’t like them, for example Jake Wharton. In short, he says you can use Fragments, but the backstack is a nightmare.

You have a little more code. After all, for each screen, you have to write both Fragment and Composable.

Another thing is that you have two lifecycles that you need to manage — Fragment and Composable lifecycle. This may seem problematic at first, but fortunately, there is a quick way to deal with it. Just use the setViewCompositionStrategy method on a ComposeView and set how the Composable’s lifecycle should behave in relation to the Fragment’s lifecycle.

Last but not least, you must remember that when passing a Parcelable object as a Safe Args argument, you must also add it to the proguard configuration, otherwise you will get a crash on production.

Summary

So is using Fragments the best solution? Probably not.

In my opinion, it would be best if Google provided us with a ready, working and good API for navigation in Compose. Unfortunately, as I mentioned before, we can forget about it for now. At the moment, the solution that I presented is something that I use myself and I’m OK with it, at least for now.

We should also remember that many libraries and tools do not yet have 100% support with Compose and sometimes the ability to write something in the old way, in a Fragment or even in XML is exactly what we need.

Thanks for reading!
That’s it for this article. I hope you like it and should you have any questions, do not hesitate to comment or reach out to me :)

DEV Community: Patryk Kosieradzki

Dagger/Hilt vs Koin for Jetpack Compose apps

Intro

Let’s roll

PROS of using Hilt in your app

Jetpack and Support

Easier to implement than Dagger

Compile time errors

Testing

Process death

CONS of using Hilt

Slower build time

Sometimes you have to write Dagger code

You can’t inject anything other than ViewModel into Composables (at least for now)

And how does this relate to Koin?

Way easier to use than Dagger and Hilt

You can inject dependencies into Composables

More informative error logs

No code generation

CONS

Much more DI code, especially get(), get(), get()… get()

Issues with SavedStateHandle when not using Fragments

Impact on runtime performance

Summary

Check out my other articles:

Why using Navigation-Compose in your Jetpack Compose app is a bad idea

Why using Navigation-Compose in your Jetpack Compose app is a bad idea | by Patryk Kosieradzki | Feb, 2022 | Medium

Patryk Kosieradzki ・ Feb 14, 2022 ・ Medium

Intro

Podcast!

Let’s start

Route paths

Navigation arguments

Everything is a String

What about Enums, Serializables and Parcelables?

BUT WHY?

Just use Fragments

Summary

Patryk Kosieradzki ・ Feb 14, 2022 ・
Medium