Florian
09/27/2020, 7:34 AM_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 functionsShawn Witte
09/27/2020, 9:52 AMviewModelScope
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.createTask
and updateTask
aren't suspending functions. They are regular blocking functions that launch coroutines (which may be suspended) and then return a Job
and Unit
respectively. A suspending function must literally have the suspend
modifier.Florian
09/27/2020, 10:15 AMsaveTask
is a suspending functionShawn Witte
09/27/2020, 10:58 AMlifecycleScope
instead)Florian
09/27/2020, 11:00 AMNonCancelable
. I know there are some warnings against but for a simple Room operation it should be fineShawn Witte
09/27/2020, 11:08 AMFlorian
09/27/2020, 11:15 AM