@gammax I perhaps have something regarding the maven central part: https://github.com/uniflow-kt/uniflow-kt/blob/master/gradle/publish-maven-central.gradle

Seems that it’s deploying on maven central: https://github.com/InsertKoinIO/koin/tree/maven_central

Hello! I created two issues with some proposals to Koin. Can you provide some feedback, please. Issue one and issue two.

Hello, I created an issue to add inject for Screen in order to work with Android Auto without doing workarounds. What do you think ?

@arnaud.giuliani my plan on using ksp to generate tests for the leaves of the graph ( scanning activities/fragments for properties that use

inject()

) is not going to work. I'd need ideas/alternatives, is there anything on your mind besides arrow-meta? Btw if we used something like

@Inject val coffeMaker:CoffeeMaker

then ksp could help with that, but that's a big change. https://kotlinlang.slack.com/archives/C013BA8EQSE/p1617015188066500?thread_ts=1616440343.040500&cid=C013BA8EQSE https://kotlinlang.slack.com/archives/C013BA8EQSE/p1617020934066700?thread_ts=1616440343.040500&cid=C013BA8EQSE

Hello! I'd like to do the following with Koin. We have: 1. isolated Koin component, 2. an interface with getters (or properties) for other interfaces:

interface Dependencies {
    val dependency0: Dependency0
    val dependency1: Dependency1
...
}

The interface is provided to Koin outside. We want to use DependencyX as a usual singleton dependency. For now, we have to wrap each dependency into single() function. But this is not convenient: if we change Dependencies interface, we must change the module. It would we great if Koin can use externally provided dependencies as his dependencies. Motivation: component holder pattern https://proandroiddev.com/modularization-of-android-applications-in-2021-a79a590d5e5b I tried to implement it, but the solution is weird. At least because I had to use internal property "definitions": https://github.com/PavelSidyakin/WeatherForecast/blob/koin_experiments/feature/city_list/src/main/java/com/example/city_list/di/CityListComponentImpl.kt Would you implement the functionality in the library? Or I can try to implement it. Can you recommend how to do it better?

@jossiwolf @arnaud.giuliani made a draft PR to get some discussion started with generating modules with KSP: https://github.com/InsertKoinIO/koin/pull/1059

was looking to enabled Kotlin/JS IR compiler but getting following

- Variant 'jsApiElements-published' capability io.insert-koin:koin-core:3.0.1 declares a component, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'js':
              - Incompatible because this component declares a usage of 'kotlin-api' of a component, as well as attribute 'org.jetbrains.kotlin.js.compiler' with value 'legacy' and the consumer needed a usage of 'kotlin-runtime' of a component, as well as attribute 'org.jetbrains.kotlin.js.compiler' with value 'ir'

Is anything particular needed to build/try out koin locally.....I've cloned repo and when I run

./install_all.sh

I get errors like following

Cannot perform signing task ':koin-gradle-plugin:signReleasePublication' because it has no configured signatory

Also, I think I remember that snapshot builds where published somewhere?

@arnaud.giuliani do you know roughly when you're hoping to create new release that includes that JS IR support?

3.0.2 is just near publish

from https://android-developers.googleblog.com/2021/05/whats-new-in-jetpack.html "Hilt is now integrated with Navigation and Compose: you can obtain an annotated Hilt ViewModel that is scoped to a destination or the navigation graph itself." Not sure to what extent Koin supports this (or if it's something being added)?

I Finally managed to make KSP works with Koin 🎉 I have some heavy work in progress, but greatly promising 👍

Hello I would like to do the following with koin ( for android ) and any help would be really helpful..

class Navigator(fragmentManager:FragmentManager{
//some specific logic using fragmentManager
}

class NavigatorTaker(navigator:Navigator){
  fun test(){
      navigator.someFunction()
   }
}

class VIewModdel(vall navigatorTaker:NavigatorTaker){
   fun onLoad(){
     navigatorTaker.test()
   }
}

I cannoot just create my module like below:

module {
single<Navigator>(????how to provide the fragmentManager here as its available with my activity)
single<NavigatorTaker>(get())
  viewmodel {.VIewModdel(get()) }
}

did anyone has already managed to tackle this issue... any help would be highly useful for me 🙇

Hello everyone! Recently I updated Koin to 3.1.0 in our project and faced with problem described in https://github.com/InsertKoinIO/koin/issues/1121. Later i also see https://github.com/InsertKoinIO/koin/issues/1125 and figure out that this problem occurred in few our dependencies too. Seems like new parameter injection mechanism can't fully do same things that deprecated descructuring declaration. https://github.com/InsertKoinIO/koin/issues/1121 is can be easily fixed, but https://github.com/InsertKoinIO/koin/issues/1125 a bit more complicated, e.g. it can be fixed with parameter qualifiers, but it sounds like DI for DI, overkill. Maybe descructuring declaration is not bad idea? What you think about this problems?

I’ve reached out code generation for Koin. It’s instant code code generation (even with 1000's of definitions). Super easy annotations usage ... It should be a super great dev experience - https://github.com/InsertKoinIO/koin-compiler-playground

Hi We are working on a Ktor & Koin project and we at start we had one Koin module but as with the time we added more and more components into it and now we decided to split into 2 modules but it looks like for testing purpose it will be easy to have one component in each module. I wondering if there are some rules of thumb on how to split components into modules Thanks

Hi me again 👋 Any good documentation of testing a ktor+ koin project ?

I’m opening this to discuss about the problem Koin is facing with the usage of ViewModel + Compose + Navigation component on Android. See https://kotlinlang.slack.com/archives/C67HDJZ2N/p1628005816001100 for further info.

Hey guys, how can we use Koin Component in Compose? Like traditions views, we cant extend Fragment/View with KoinComponent. How does one do that with compose?

Hey! I’ve been working with Koin for Compose for a while now and have a proposal to improve how

KoinContext

management works in

@Composable

functions. I believe the configuration of the Application should be done in the top level composable. This way it is not dependent on Koin initialization in the application class, which allows for easy

KoinContext

replacement in

@Preview

composables and tests. It introduces a new API -

Koin

and

KoinScope

composables:

@Composable
fun Koin(
    appDeclaration: KoinAppDeclaration? = null,
    content: @Composable () -> Unit
) {
    val koinApplication = koinApplication(appDeclaration)
    CompositionLocalProvider(LocalKoin provides koinApplication.koin) {
        content()
    }
}

@Composable
fun KoinScope(
    getScope: Koin.() -> Scope,
    content: @Composable () -> Unit
) {
    val koin = getKoin()
    val scope = remember {
        koin.getScope()
    }
    CompositionLocalProvider(LocalScope provides scope) {
        content()
    }
}

I’ve opened PR here with implementation and instrumented tests: https://github.com/InsertKoinIO/koin/pull/1178 On the screenshot there is an example how to use new API with Scope and Preview. Pros: - scopes works - easy

KoinContext

replacement in tests - easy

KoinContext

replacement in

@Preview

composables - no need to use application class (which may help with Compose Multiplatform support in the future) - backward compatibility (using GlobalContext as default value)

I didn't find any issue regarding apple silicon support so I created one. Has anyone maybe worked on such thing so far? I'm not sure if it's just adding 1.5.30 and missing apple silicon targets, or if it might be harder for koin for some reason?

I’m reworking ViewModel API to fix scope handling with them. It will also unlock koinGraphViewModel() API 🎉 I will publish a 3.1.3 Koin version with all those fixes. Koin annotation processing compiler is done at 80% I will introduce some deprecation in 3.1.3 (APIs that need to be moved) that will be cleaned out in 3.2.0

Is this a suitable way to initiate some work at startup?

single { CoroutineScope(Dispatchers.Default + SupervisorJob() ) }

    single<PeopleInSpaceRepositoryInterface>(createdAtStart = true) {
        PeopleInSpaceRepository()
            .also {
                get<CoroutineScope>().launch {
                    it.fetchAndStorePeople()
                }
            }
    }

Just made

koinNavGraphViewModel()

function to scope a ViewModel to a given Nav Graph

Hey all! What is the recommended approach to "group modules"? For example: I have a root package called feed and two subpackage called list and details - I wanted to have one module per package and include the two in the root one (feed). Right now, looks like you need to create them separated and introduce a "list" grouping them. Is that correct?

Hey all! I see Koin supports

FragmentFactory

but I don’t find a way to inject the Koin’s

ViewModelProvider.Factory

. The whole point of using

FragmentFactory

is to be able to do constructor injection. Is there any way to inject the

ViewModelProvider.Factory

in a

Fragment

constructor using Koin?

This message was deleted.

Hey @arnaud.giuliani - thank you for following up on that. I’m right now playing around with that to see how it goes (I can do a PR in the next days with my changes after I add comments, etc). In total, the new API would add 33 new methods (

single

,

factory

,

viewModel

) to reduce the

new

. I think that is OK because I don’t foresee many new binding definitions to be created in the future. That is how it would look like (see the picture for comparison):

factory(::RecoveryReminderViewModel)

Locally is already working, there is only one points that still concerns me: the namespace / auto complete might be a little polluted (see picture below). What do you think? If you don’t see a problem I think we can move forward and I can do PRs with it next days. Maybe someone else has other opinions here too. 🙂