Hi all, I have a weird behaviour regarding coroutines on Android and I hope that you can help me: I ...

# coroutines

[svenjacobs]

Hi all, I have a weird behaviour regarding coroutines on Android and I hope that you can help me:
I have a suspending function that performs some UI logic

suspend fun showSnackbar() {
    val snackbar = Snackbar.make(...)
    snackbar.show()
    delay(4000)
    snackbar.setAction("...", null) // crash here
    snackbar.dismiss()
}

The functions is called via launch(Dispatchers.Main) { showSnackbar() }. Please don't ask why I have to null the action. It is required to prevent a false positive memory leak warning. Anyway, the call snackbar.setAction() crashes the app with android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views. and I wonder if delay() might change the Dispatcher?? 🤔 Thanks for your help!

[svenjacobs]

Coroutines version 1.4.3
Kotlin 1.4.31

[svenjacobs]

Wrapping the code after delay() in a withContext(Dispatchers.Main) fixes the crash but I did not expect this behaviour 😕

[uli]

Pretty sure no dispatcher is changed here. Feel free to throw some logging in there:

Log.d("Thread", "On Thread ${Thread.currentThread}")

[uli]

If you really end up on another thread that would be a bug. But with such a bug, none of my coroutines based code would work

[uli]

There might be something going wrong in the code you abstracted away for the example?

[svenjacobs]

This is pretty much all there is of the code. I just abstracted away building the snackbar UI 🤷🏼‍♂️

[uli]

Did you throw in some logging? You could also add:

Log.d("Thread", "My Dispatcher is ${coroutineContext[CoroutineDispatcher]}")

[louiscad]

This has nothing to do with coroutines, it's an Android restriction that you can only fix by running the UI code interacting with Views APIs on the main thread.

[svenjacobs]

I'm aware of this restriction 😉 I run this suspending function like this: launch(Dispatchers.Main) { showSnackbar() }

[uli]

@louiscad @svenjacobs writes:
The functions is called via launch(Dispatchers.Main) { showSnackbar() }

[svenjacobs]

@uli I added logging right after delay() and this is the output:

Thread: Thread[DefaultDispatcher-worker-2,5,main]
Dispatcher: Dispatchers.Main

but the next UI code definitely crashes.

[uli]

do you have a stack trace?

[louiscad]

It looks like the thread is one of Dispatchers.Default while the coroutineContext has Dispatchers.Main 🤔

[svenjacobs]

Hm, okay, I will check the "backend" code which calls the UI function. Maybe something weird is going on there.

[louiscad]

To be sure, instead of wrapping the call to showSnackbar(), I'd wrap the body of the function itself with Dispatchers.Main { … }

[svenjacobs]

You mean withContext(Dispatchers.Main) { ... }?

[louiscad]

Both work, there's an operator fun invoke for CoroutineDispatcher.

[svenjacobs]

Okay, sorry for the confusion but it actually was a problem of the backend code. It's a bit more complex. There are cascading coroutine calls and I was of the impression that launch inherits the dispatcher...

It looked like this

launch(Dispatchers.Main) { someFunc() }

and in someFunc

...
launch { showSnackbar() }
...

However adding Dispatchers.Main to the second launch fixes this.

[uli]

;-)

[uli]

good you found it

[svenjacobs]

Thanks for your help, Uli & Louis!

[svenjacobs]

However, still "interesting" that the UI code before the delay did not crash 🤷🏼‍♂️ Maybe just coincidence?

[uli]

But it did say Dispatchers.Main while being on a default dispatcher’s thread?

Thread: Thread[DefaultDispatcher-worker-2,5,main]
Dispatcher: Dispatchers.Main

[svenjacobs]

Yes, after fixing the second launch it now says

Thread[main,5,main]

[uli]

I am more concerned as to why thread and dispatcher did not match

[svenjacobs]

Maybe because of

launch(Dispatchers.Main) {
  launch { ... }
}

?

[louiscad]

@svenjacobs Not all UI calls check for the main thread on Android, that's why it didn't crash earlier.