Is there a way to block on a scope to finish it’s jobs while not causing a deadlock, if they’re on the same thread? I have cleanup code in the finally block that needs to run on the same thread before onStop completes.

Idk if you can without potentially blocking in

onStop

. The question is: do you really need these fragment transactions to happen? It might be the case that you depend too tightly on the lifecycles of your components to execute certain stuff. I'd look into moving that dependency elsewhere, so that these transactions can happen, or not, at the Android system's will

I was hoping that this could be a usable pattern for creating and destroying fragments while the activity is visible. But as usual, saveInstanceState and activity lifecycle causes a horrible mess when trying to do asynchronous code.

this is a terrible idea. Try to avoid this and work around it

The problem is that if you do a fragment transaction from a coroutine, there is no way to guarantee that the fragments were left in a consistent state since a coroutine can be canceled by onStop then process death. The work around ends up being tightly coupled code in different methods. The only work around that doesn’t require splitting up coupled code, is to discard the onSaveInstanceState bundle in onCreate() if the activity was recreated from process death. This way the fragment state will be known. To handle configuration changes the coroutine can be moved to the ViewModel.

Or use a fragmetnless pattern

I think the same issue will come up with views if the view is responsible for saving it’s state in onSaveInstanceState()

I've also adopted a fully VM-based state source. There is also a VM variant that handles saved instance state, but idk the details as I haven't needed it yet

I wanted to have UI effects in my coroutine so that the business logic would be clear. Show dialgo1 then show dialog2 then show dialog3 etc… But having to model everything in a VM just to support serialization is tedious.

This is not a solution tho, but would using Dispatchers.Main.immediate instead help? Might solve your problem.

Yes. That solves the original issue. The finally block gets runs before .cancel() returns. Interesting.

yes. because Dispatchers.Main will get delayed in the event queue. Immediate is like in the same frame whenever possible.

This will come in handy for finally blocks that need to run immediately. Is there a way to just use Dispatchers.Main.immediate only when doing .cancel()? It's fine if there isn't. I think I'm going to be using Main.immediate for all my coroutines that run on the UI thread.

not sure about first one. About second one, yes use immediate whenever possible. Be careful tho, it’s not just simply change the dispatchers. You need to try it out, there might be side effects

For sure. This at least might make cleanup of UI effects using fragments/views work with onSaveInstanceState.