@groostav is the way you’re solving the issue of parallelism just by using the main dispatcher in both places? if so, that’s kind of out of the question, as that suspension function sometimes does work that cannot be handled on Android’s main thread

joining a job would maybe work, but is also kind pointless: the coroutines are meant to be fired and forgotten, but they affect state changes which are then observed

yeah so, Firstly you can use the code I wrote below to make it concurrent bug single-threaded. Then you need to find some way to synchronize on the

submitEvent

call to ensure its gone off. As the untaggable Allen Wang suggested, you could return a `Job?`:

fun submitAppSelection(app: App): Job? {
  if (!selectionsCanBeMade()) return null

  return launch { app.submitEvent(AppSelected) }
}

then, in your test, call

mainActivity.submit()?.join()

would it be bad practice to just

delay

for some short amount in the test to ensure that the coroutine is launched?

is the way you’re solving the issue of parallelism just by using the main dispatcher in both places?

Exactly, through a great deal of effort I can honeslty say this is the best approach. Start off writing single-threaded concurrent code. Parallelize when you need the performance.

that’s kind of out of the question, as that suspension function sometimes does work that cannot be handled on Android’s main thread

this is really odd. This style of suspend-funs-may-return-fast is in C# but was intentionally made more difficult (ie removed) in kotlinx because of the subtle concurrency bugs it can introduce. Typically we statically know if you will suspend or not, the runtime does not get a say in that.

I wouldnt do any of this, I'll make a gist with what I owould do

but regarding the

submitEvent

function, is it blocking or is it suspending? Is that an android API call?

android will throw exceptions if things like network and database io are done on the main thread

can you explain a little more what you mean by your comment `// 2. synchronize on the result, only after

submitEvent

returns (not suspends) will

submitAppSelection

return.`

alternatively put, if you had

println("before withContext!")
withContext(Dispatchers.Anything){
  println("before submitEvent!")
  submitEvent()
  println("after submitEvent!")
}
println("after withContext!")

you would only ever see the exact sequence

before withContext!
before submitEvent!
after submitEvent!
after withContext!

lastly,

submitEvent

is technically marked as a suspending function, but it never actually suspends anything. i guess i’ve been using the suspend modifier to also indicate functions that need to happen off the main thread

I think you should follow that

suspend

up with a

withContext

. This is exactly what I do with my database facade.

class SuspendingTable {
  suspend fun get(id: UUID): T   {
    return withContext(<http://Dispatchers.IO|Dispatchers.IO> + Trace){
      backingDb.getBlocking(id)
    }
  }
}