I'll just leave this here in case you've missed it...

# android

[Erik]

I'll just leave this here in case you've missed it, but it looks pretty new to me!
https://dagger.dev/hilt

[Roger Home-Martinsen]

But is it better than Koin?

[jw]

It generates the code that you write manually so, yes

[henrikhorbovyi]

But you write twice more 😄

[OG]

It looks interesting... I was chatting about this at work today. It brought up the convo of alternatively just writing your own DI all in Kotlin and rid the dependency of yet another 3rd party lib... Instead of migrating from Dagger to Hilt.... Decisions decisions.... 🙄

[krtko]

It's awesome they are updating dagger to something easier to use, but Koin working with kotlin MP is a huge win for me

[jw]

Good thing "they" also announced #ksp today

[krtko]

KSP is faster annotation processor for Kotlin?

[Joost Klitsie]

@Roger Home-Martinsen in terms of speed it is better than koin, but I guess usability-wise Koin is easier, but never really used koin (now only using dagger at work, and kodein for something multiplatform at home). @OG I am going to guess that writing your own DI will open up a jar of hurt. Using a library where dedicated people work on sounds like less effort 🙂

[Roger Home-Martinsen]

Our app is currently using Dagger, but we have tested Koin for our new modules. Dagger Hilt seems to solve a lot of the pain I got when we started breaking ut a monolitic application into modules. It will be interesting to see if it is as easy as you suggest @jw.

[OG]

@Joost Klitsie you're most likely right 😂😂... But it's google... They're going to just deprecate it in a few months, create something else and write up yet another migration headache... Don't get me wrong Hilt looks wicked cool but I try to operate with the whole "if it ain't broke, don't fix it" mind of thinking and if you build something in house that works, there's overheard up front but you then built something you can maintain and customize as you see fit. And you don't feel pressured to just switch and migrate to yet another google lib where who knows if they choose to support it or deprecate it later on.

Take their Volley library for ex. Many folks jumped on that bandwagon because it was made by "google" and it's last commit was like years ago and still no support for coroutines etc. So if you ended up going with that networking library, now you will need to wrap your volley calls with coroutines manually or migrate to another networking library like retrofit which added support out the box.

Maybe this is me just venting my frustrations with some past experiences that might not always be the case with using Google libs. 🙄🙄.. let me stop hating.... Lol.... Hilt for the WIN?!

[Joost Klitsie]

@OG Well if you have a functioning and understandable Dagger implementation, I don't think it is really worth to migrate (or to write your own solution for that matter 😛 ). Also I think that Volley was never meant to be that advanced, but more as a support for simple app development. For advanced usage okhttp with retrofit usually will do the trick, and it is also easy to use like that. So I don't think Google had the need to improve much on Volley, as it did its job so now they just support it. In general Dagger now exists for many years and they still didn't kill it 😄 So I guess Hilt is just a next step and it will probably be supported as long as Dagger will be supported. However, I am curious to see which Kotlin DI frameworks might take over. Especially if Kotlin Symbol Processing has these capabilities then it might just be that Hilt will be obsolete, as a multiplatform and high performance dependency injection framework would be a better horse to bet on (kodein is a bit slow and I guess that the performance of Koin once it is multiplatform will never be as good as that of Dagger with a form of code generation)

[OG]

@Joost Klitsie yes very true about volley and what you said about retrofit and okttp is def the way to go. That was the only example that popped in my mind upon waking up and starting my early morning with some slack news lol. Another that comes to mind is ButterKnife, kotlin extensions or view binding. But regardless, I agree with everything you mentioned.. It might also be just a sense of fulfillment I enjoy when building things in house that I sometimes try to shy away from using so many 3rd party libs. But DI can be quite the beast... I use Dagger on all the projects I'm on and although it had many pain points it's working fine and is stable so I will prob hold off on the migrating to Hilt. But KSP and kotlin DI is definitely something I'm really intrigued about.

[jw]

Also I think that Volley was never meant to be that advanced, but more as a support for simple app development.

Volley was built for the Play Store, arguably the most important app in all of Android.

[Joost Klitsie]

I did not know that 🙂 from my outside perspective, I always categorized the Volley into the "I wanna do some simple things and I don't not bothered with setup"-group and Okhttp into the "I wanna do some more advanced stuff and be bothered with setup"-group, so combined with Retrofit the latter was always the obvious choice for my company.

[OG]

@jw no way... Never knew that.. neat fact if that's really true. I wonder if newer versions still use it. I guess an app like that probably wouldn't switch to kotlin just for the sake of using kotlin and leveraging coroutines.

[OG]

@Joost Klitsie I sort of operated with that same thinking between the two networking libs. That and the image caching that was built in within volley... Side note: I feel bad for adding stuff to this thread that doesn't relate directly to the main post. Lol.

[Adam Powell]

Can confirm, it's true