So I'm still new to koin. How would I convert this Dagger/Hilt AppModule providing a single class to...

# koin

[Colton Idle]

So I'm still new to koin. How would I convert this Dagger/Hilt AppModule providing a single class to be injectable to whoever wants it?

@InstallIn(SingletonComponent::class)
@Module
class AppModule {
  @Singleton
  @Provides
  fun provideApiService(): ApiService {
    return ApiServiceBuilder()
      .build(//baseUrl Will GO here)
  }

[Colton Idle]

Would that just be

val appModule = module {
  single { ApiServiceBuilder().build() }
}

?

[Javier]

Yes

[Colton Idle]

Awesome... and then on the ViewModel side of it... I currently have this:

@HiltViewModel
class MyScreenViewModel
@Inject
constructor(
    val apiService: ApiService,
    val savedStateHandle: SavedStateHandle
) : ViewModel() {

[Colton Idle]

Not sure actually what I would do to convert that^

[Colton Idle]

The docs talk about a viewModel {} keyword... but it makes it seem like those deps would be viewModel scoped (like a viewmodel scope in hilt)

[Javier]

I think there is a viewModel dsl similar to that single. Koin docs are very good as they are oriented with examples

[Colton Idle]

Yeah. im reading https://insert-koin.io/docs/reference/koin-android/viewmodel

[Colton Idle]

but it sounds like thats not what I want?

[Colton Idle]

it makes it seem like its a scope

[Javier]

you must use viewmodel inside the module dsl and later when you fetch it too, with by viewModel and so on

[Colton Idle]

interesting...

[Colton Idle]

okay. lemme give it a whirl. lol

[Colton Idle]

i feel like there are a few different things to learn with the annotation approach (thats sorta new AFAIK?) and then also theres compile time safety, which is also new from what ive seen.

[Colton Idle]

Alright. This seemed to work.

Feel free to critique my very small impl for now

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

val appModule = module {
  single { buildApiService("<https://myapiUrl>") }
  factory { CloseableCoroutineScope() }
  viewModel { MyViewModel(get(), get()) }
}

class MyViewModel (
  private val apiService: ApiService,
  private val closeableCoroutineScope: CloseableCoroutineScope
) : ViewModel(closeableCoroutineScope) {

and

@Composable
fun MyScreen() {
  val myViewModel = koinInject<MyViewModel>()

The only thing I'm sorta worried about is whether or not my ViewModel will be properly scoped to the nav graph like how hilt + compose + AAC nav works.

[Colton Idle]

also not sure if i should wrap the koinInject in a remember{}

[ascii]

I'm curious as to why you're moving from Hilt to Koin.

The way I see it, most people want to migrate to Hilt because it's AndroidX and integrates better with pretty much any other AndroidX lib. Plus, Hilt does its magic compile-time, while Koin is fully-runtime I think? Meaning Hilt just offers better performance.

Feel free to correct me.

[Vlad]

The only reason I see to migrate from hilt to koin - is that koin is KMP.

[Colton Idle]

@ascii yeah. thats pretty much it. i do think that hilt/dagger will overall have better support for how it integrates with compose/navigation/lifecycle/etc. + i invested a lot of time to understand dagger. it made sense to use.

im still not a fan of the syntax of koin, but I want to do kmp compose and so i want something that can do that.

[Colton Idle]

so yeah, @Vlad is right on that

[Matt Rea]

There is the koin-androidx-compose-navigation artifact that exposes koinNavViewModel(), which uses LocalViewModelStoreOwner.

However I don’t think this is set automatically by androidx navigation? You could always inspect your app at runtime and see if that CompositionLocal is populated. But you may need to set it yourself

https://stackoverflow.com/questions/69002018/why-a-new-viewmodel-is-created-in-each-compose-navigation-route

[Matt Rea]

Also, there’s other ways to declare your dependencies, if you don’t like the syntax

I prefer singleOf(::MyObject), viewModelOf(::MyViewModel), etc. This allows you to avoid writing get() at all. For most objects, you just declare your dependency once and never have to update the declaration again
https://insert-koin.io/docs/reference/koin-android/dsl-update

But there’s also the KSP codegen stuff, which works pretty well. But I like a little more control. Sometimes I want to put a small bit of code in my DI - like instantiating OkHttpClient.Builder() for example
https://insert-koin.io/docs/reference/koin-annotations/start

[arnaud.giuliani]

The way I see it, most people want to migrate to Hilt because it's AndroidX and integrates better with pretty much any other AndroidX lib. Plus, Hilt does its magic compile-time, while Koin is fully-runtime I think? Meaning Hilt just offers better performance.

@ascii Koin is using the same Android API, and save up to 75% of your compilation time. It's also far more easy to lear and use, and doesn't constraint you in terms of development paradigm

[arnaud.giuliani]

In terms of time access, an instance in Koin is retrieve in around 0,01ms thanks to optimized tree searching.

[arnaud.giuliani]

Scalability is neither a problem, as you can organize scale over hundreds of modules easily. Big company are using it 👍

[arnaud.giuliani]

and if you need compilation safety, look at Koin Annotations