abbic
02/25/2023, 11:12 AMval AppScope = CoroutineScope(window.asCoroutineDispatcher())
which is a browser thing, but it also makes me wonder what would happen if this coroutine was cancelled for any reason (at a guess, the window as coroutine dispatcher prevents that from happening?)factory { CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO> + SupervisorJob()) }
"ought to" work, because SupervisorJob means its not getting cancelled on its own any time soon. I just wonder if its at all important for the scope to be explicitly scoped to the App.
On one hand, logically i would assume that it doesnt matter because the process is killed when the app closes anyway. but on the other, in that case why would there be alternate solutions like window.asCoroutineDispatcher()
or rememberCoroutineScope
? as this should be achievable enough without Koin, though maybe it isntCasey Brooks
02/25/2023, 2:42 PMfactory
or single
if you are treating your repositories as Singletons. But if you want them scoped more locally than that, for example, on a rememberCoroutineScope
, then that will need to be passed in.
So for the specific question of how to provide a Router with Koin, you need to decide what “global” means for your application. If it’s truly global and spans multiple renderComposable
, then you’ll likely want the Router to be truly global and running on window.asCoroutineDispatcher()
or your custom injected coroutineScope. But if you want your Router to be tied to the lifecycle of a Composable instead of the Window, then you may want to create the Koin injector directly within the composition as well so that you can manually provide the rememberCoroutineScope
to a ModuleKoinApplication
, but it’s easy to forget that and end up using the global instance, and it becomes cumbersome to use a specific KoinApplication everywhere. So lately, I’ve just been doing everything with manual DI and have had less confusion about how to provide values where I need them.
That’s not to say Koin is bad, but rather I’ve found (kind of unintentionally) that Ballast encourages you to think about aspects of your application that you didn’t before, like what does “global” really mean for your application. It was always a problem, even without using Ballast or Compose, but we tended to not think about it, and in doing so could cause some subtle issues with scoping and lifetimes in our apps. Ballast just gives you some tools to help you define those boundariesabbic
02/25/2023, 3:26 PMremember(CoroutineScope) {
get<ViewModel>(paramsOf(coroutineScope) )
and still let koin provide global components.
I suppose the real difficulty comes when some components are scoped longer than others, and would like to be injected in, but are not global.
at that point i would just not provide them with koin, seems like you can mix and match ok