This is from Google's sample. I'm particularly interested in the

_taskUpdatedEvent

, which triggers the back navigation in the fragment. They navigate back from the screen after the insert operation is finished. Isn't this pretty similar to blocking the UI thread? It won't freeze the UI, but you can't actually do anything on that screen until the operation is finished and it's not really necessary to not navigate back immediately. I know that this operation will only take a few milliseconds but still, there is a reason why we execute queries on a background thread in the first place. Also, this could take longer depending on what happens in the repository. What is your opinion? Edit:

createTask

and

updateTask

are suspending functions

Waiting until the insert is complete before navigating back ensures that the

viewModelScope

isn't canceled before it's complete. It's not the same as blocking the UI thread because the user won't experience an actually frozen screen (which is still frustrating even if you think there's nothing left on the screen) and they won't get an ANR prompt to close the app. If you are worried about the user thinking the app isn't doing anything while you wait for an action to finish, then you can present a loading indicator (e.g. use a pulltorefresh layout snd manually set its

refreshing

value). Also, waiting for the data layer to finish doing its thing gives you a chance to listen for errors (as a return value, for example) and display a failure to the user.

Right, I mean

saveTask

is a suspending function

Using a wider scope (probably an application level scope) would allow you to navigate back safely. This means you won't be able to communicate the result of the call to the user without extra work, though. One solution that is often used to prevent a double button press is to disable the button when it is pressed. You can re-enable it after an operation if necessary (which would probably mean launching your coroutine from

lifecycleScope

instead)

thanks

"acceptable for a small app" is a concerning phrase. A small app is only small until it's not. It's usually best to just do things properly from the beginning. As for the "simple Room operation", you shouldn't be making assumptions about the data layer at the viewmodel level. Maybe one day we add a remote call to save to some online source.

ok I see