Is `invokeOnCompletion` a good place to hide a progress bar if a Coroutine was either finished or ca...

# coroutines

[Florian]

Is invokeOnCompletion a good place to hide a progress bar if a Coroutine was either finished or cancelled?

.invokeOnCompletion {
    _loading.postValue(false)
}

[andylamax]

absolutely

[andylamax]

hey, are you the youtuber codeinflow?

[Florian]

yes 👍

[Florian]

thank you

[andylamax]

good content you creating. Good stuff

[Florian]

Thank you very much 🙏

[travis]

Here is a very long winded comment I had on a PR on the topic (of using invokeOnCompletion):
https://gist.github.com/twyatt/c61ebc97dd891ff7a888311df857f619

Hopefully it's helpful.

[Florian]

Thank you. Do you think it's a good idea to use it for my progress bar LiveData?

[travis]

For your progress bar example, it's a simple enough case that invokeOnCompletion should work just fine.

My personal preference is try-finally as it has more capabilities if needed. Allows for more consistency in codebases for cases that need the capabilities of try-finally approach (rather than having some invokeOnCompletion and some try-finally, just have all be try-finally). But that's just a preference.

[Florian]

hm but I have the try/catch in the repository layer

[Florian]

and the progress bar LiveData in the ViewModel

[andylamax]

if you have try catch on the repository, how do you present your errors to the UI? I suggest move your try catch to your viemodel, that way incase of any error, you can still handle it and display to the user what went wrong

[Florian]

well the catch block returns a Result.Error

[andylamax]

If you are already handling errors in the repo side, then invokeOnCompletion would be the best way to go for your progress bar

[Florian]

Thank you 👍