(1) Cross-cutting concerns like DI are really hard...

# compose

[jim]

(1) Cross-cutting concerns like DI are really hard to unwind. Reducing cross cutting dependencies is an important part of modularization. Personally, I'd avoid any sort of DI to the maximum extent possible (t/1425842587357773832).  But if you really must use DI, I've heard good things about Koin (https://insert-koin.io/) which is MPP-friendly and AFAIK doesn't rely on ViewModel.

(2) Without knowing the specifics of your situation, it's hard to comment on exactly what would be recommended for your particular situation, but generally your composables themselves probably shouldn't know about coroutines.  There are a couple common situations:
• If you are using SideEffects, stop.  Those are almost always a sign of abuse.  Composable functions should be pure functional transforms from data to UI.  Anything else you are doing (ie. side effects) is an indication you are not following this rule.
• If you are launching a coroutine as part of a callback, the question is, why is the widget driving this coroutine?  That is to say, callbacks should generally be plain vanilla lambdas invoked by the composable.  If the callback which is passed in will use coroutines, that's fine/reasonable, but the scope of the module creating the callback will typically have an appropriate coroutine scope.  If the callback is created in the activity (which is a reasonable place for such events to bubble up to, then using the ViewModel scope associated with that activity is perfectly reasonable (t/1455147100883226624).