the only difference is the source code calling convention

I'm not sure what memory leaks you're worried about, coroutines become unreachable after they finish executing -> GC can clean them up

unfortunately I'm not very well versed in android MVVM so I'm not quite sure what the exact issue is, but hopefully this clears some stuff up

I edited post

Regarding leaks, I know how coroutines work, however, I have my doubts about passing coroutine context into regular classes. I have not seen such examples. But it does make sense in our case, because that execute function is actually much larger with more context switching and even async await call.

I posted an answer to the question of why it's not accessible

Will create a gist for this case

Here, I will write test for this code, but so far it executes what I need. Create a long running task with withContext, wait for result and then spawn 3 parallel tasks. 2 of them are needed for await because I need results for starting a network request. 1 is not needed for await. It can take longer time for running. And then after all is done notify my repository about some changes

it is some ancestor of `viewModelScope`'s

Job

, but it may not necessarily have anything else in common with it (such as dispatcher)

if you want that to continue in parallel, you will need to get some sort of application scope (maybe

viewModelScope

is appropriate here) and

launch

it there

but running it based on the

coroutineScope {}

-created scope will cause your function to suspend at the end of the block until every child Job is done

Thanks.. now I get it! Like really,.. you should write some medium posts 😄 Now that you said, I still need to pass viewModelScope(same as applicationScope) as function argument to make sure that last one job is done in parallel instead of using coroutineScope, which requires to wait... yes? :D