state.myList.forEachIndexed { index, it ->
  viewModelScope.launch {
    it.isDone.value = apiService.isDone(it.id)
  }
}

I thought I'd be able to add a

.await()

to the end of the launch block to know when all of those parrallel api calls are done, but that doesn't compile. Is there a more idiomatic way to do what I'm trying to do?

You could use map instead of forEach to get a list of Jobs and then use

joinAll

. https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/join-all.html

I believe you can wrap all those calls into a List of defers and then call awaitAll on the list in a coroutine context

Something like this?

viewModelScope.launch {
  state.myList.map { it ->
    val job = viewModelScope.launch {
      it.isDone.value = apiService.isDone(it.id)
    }
    job
  }.joinAll()

  //Do my thing that can only happen after all are done
}

If you are already in a launch, then easiest way is to use

coroutineScope

.

viewModelScope.launch {
  coroutineScope {
     state.myList.forEachIndexed { index, it ->
         launch {
             it.isDone.value = apiService.isDone(it.id)
         }
     }
   }
}

Do I need that cocourine scope acround the forEach/map?

The coroutineScope function call will suspend until all jobs launched inside of it are completed. So it makes the outer launch wait for all the inner jobs to complete.

oooh. so I don't need the joinAll after all?

no joinAll.

So I could do

viewModelScope.launch {
  coroutineScope {
     state.myList.forEachIndexed { index, it ->
         launch {
             it.isDone.value = apiService.isDone(it.id)
         }
     }
   }
  //Do some work that requires all of the above to be completed first
}

Yes

Any reason to use that vs this

viewModelScope.launch {
  state.myList.map { it ->
    val job = viewModelScope.launch {
      it.isDone.value = apiService.isDone(it.id)
    }
    job
  }.joinAll()

  //Do my thing that can only happen after all are done
}

Using

coroutineScope

creates a structured relationship between the inner jobs and the outer job. With the

joinAll

and multiple uses of the

viewModelScope

cancelling the code joining will not cancel the calls to

isDone

or the updating of

isDone.value

.

Interesting! Thanks for teaching! So in this case, if I use the structured relationship route, then what happens if one of the launches, fails? does the entire thing get cancelled?

be default they will all get cancelled if one fails. You can use SupervisorJobs to prevent that or handle the exceptions in the launch block.

Thanks!

the

coroutineScope

approach is likely the simplest and most readable, but you could also use

async

instead to map the list to a a list of Deferred and then use

awaitAll

on that list

I originally only knew of await() and so thats what I was trying to do at first, but the coroutineScope approach does make sense. ANd for structured concurreny i think it also makes sense

that's the

async

alternative

val deferred = state.myList.map { it ->
            viewmodelScope.async {
                it.isDone.value = apiService.isDone(it.id)
            }
        }

        deferred.awaitAll()

launch

and

joinAll

would the the same. Not much point in doing

async

if you are not using the returned value.

Hm. This didn't seem to work at runtime.

viewModelScope.launch {
  coroutineScope {
     state.myList.forEachIndexed { index, it ->
         launch {
             it.isDone.value = apiService.isDone(it.id)
         }
     }
   }
  //Do some work that requires all of the above to be completed first
}

the //Do some work, didn't get called. hm.

that would mean there are still jobs running

actually. i spoke too soon.

or a job failed

android studio didn't deploy changes.

happens all too often, I've resorted to building on the command line because I was tired of that issue

viewModelScope.launch {
  val deferred = state.myList.mapEach { index, it ->
    async {
      it.isDone.value = apiService.isDone(it.id)
    }
  }
  deferred.awaitAll()
  //Do some work that requires all of the above to be completed first
}

@Francesc so this would be your approach correct? I have to wrap the whole thing in a scope.launch{} I believe?

that's an option, yes. You need the

launch

for the

awaitAll

only, you don't need it for the

async

call. And doesn't look like you use the

index

so use

map

instead of

mapEach

. But for your use case,

coroutineScope

is simpler

I actually feel like "awaitAll" approach is easier, but only because thats what I was reaching for initially. Is there one of these 3 approaches that works better or more idiomatically? I know @mkrussel said

Using

coroutineScope

creates a structured relationship between the inner jobs and the outer job. With the

joinAll

and multiple uses of the

viewModelScope

cancelling the code joining will not cancel the calls to

isDone

or the updating of

isDone.value

.

Any update to your opinion mkrussel? I know its probably vauge. but yeah. with like 3 options. all of em seem pretty darn good. I do like a structured relationship tho 😄

it all depends on your use case.

launch

is for "fire and forget",

async

is for when you need the result of your task, and

coroutineScope

is helpful when you want to wait for all the children to finish or cancel all when one fails

So in this case. CoroutineScope seems to make sense for me. Thanks! I guess none of them are necessarily "wrong", right. they all work. so yeah. coroutineScope makes sense to me.

yes, like in so many other cases, there is more than one way to skin this cat

🙃 this is the only thing i hate about programming. sometimes im just like "but what is the right way" hahaha

Of the options listed, I think the one that looks like

viewModelScope.launch {
    // ...
    viewModelScope.launch {
        
    }
}

where there are nested

launch

on some external scope is the most “wrong” in the sense that it starts breaking down structured concurrency in harder to understand ways. Fire and forget is sometimes what you want, but that makes it more difficult to reason about ordering and cancellation.

Agreed! Nested viewModelScope.launch's make me cringe!