here i am with more questions. just want to be cautious, i am planning to implement a provider for the coroutine scope with koin like so

single { CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO> + SupervisorJob()) }

that should make it easy to similarly provide ballast components with koin, which require this coroutine scope? im worrying because it seems like compose scope is great for managing the lifecycle of components like viewmodels already (leaving the composition discards the instance), so maybe koin is overkill for this

For Compose, I’d recommend scoping Ballast ViewModels to the composition itself, using

rememberCoroutineScope()

as the VM scope. This makes sure that a VM is only running when that part of the composition is actually needed, and releases those resources when the composition goes away. For managing data across multiple screens, yes you’ll need to scope the VMs them to something more global than a point in the composition. I consider these “Repositories”, but the same Ballast MVI pattern works great for managing the data in your “Repository layer”

makes sense! i might use koin for Repositories only, looking forward to trying the ballast ones (though theyre a little alien to me coming from android mvvm)

Yup, holding onto the Ballast Repositories as

single { }

in Koin would be a good way to do it. Those Repositories can then be injected into your UI ViewModels, but they all share the same instance and get updated whenever the Repository’s state changes

sounds nice and easy :) thank you!

Anytime! And your questions are not aimless, but encouraged! That’s why I have this channel, to answer any questions you might have, which can then be helpful for others with similar questions