is it common practice to pass around a coroutine context? I come from the C# world, and I’m trying t...

# coroutines

[dorf]

is it common practice to pass around a coroutine context? I come from the C# world, and I’m trying to figure out how to actually call suspend functions

[ephemient]

kotlin.coroutines.CoroutineContext is pretty low level, you generally don't need to think about it

[ephemient]

kotlinx.coroutines.CoroutineScope uses kotlin.coroutines.CoroutineContext as a building block for structured concurrency; there's other users too

[ephemient]

but assuming you're working with kotlinx.coroutines, about whether to pass a kotlinx.coroutines.CoroutineScope or not, see https://medium.com/@elizarov/coroutine-context-and-scope-c8b255d59055

[gildor]

To call suspend function you need a suspend block, the easiest way to create is use any of default coroutine builders, such as launch/async/runBlocking

[ursus]

for me I divider objects into those who have state and scope, and those who "do" things

the first own their own coroutine scope
and the latter just has suspend functions, no state, no dispatchers, just pure suspend functions

the first objects own the second types

[gildor]

Not sure that it's correct separation. It's completely fine for suspend function to has blocks with scopes and dispatchers inside

[ursus]

well, different view, worked for me. Repos do stuff. ViewModels / Managers own state/scope/disposables