Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why? And what about failures? #8

Open
LouisCAD opened this issue Mar 16, 2021 · 5 comments
Open

Why? And what about failures? #8

LouisCAD opened this issue Mar 16, 2021 · 5 comments

Comments

@gastsail
Copy link
Owner

Since is a suspend function, inside Resource.success you are callind the API which is another suspend function, any exceptions thrown by that call in the Resource.Success will propagate the error to the catch block in the viewmodel

@LouisCAD
Copy link
Author

But why use callbackFlow, and why make it a Flow at all?

@LouisCAD
Copy link
Author

And why wrap into Resource.Success if you don't wrap it in unsuccessful cases?

@gastsail
Copy link
Owner

gastsail commented Mar 17, 2021

The reason of using callbackFlow there is that in this repo

override suspend fun getCocktailByName(cocktailName: String): Flow<Resource<List<Cocktail>>> =
I don't want to return Livedata to emit cache data before the concrete call to the server which brings up the latest data.

About the failure, is beign handled in the viewmodel when that success operation returns an exception, it will be propagated to the viewmodel catch block of the calling function

@gastsail
Copy link
Owner

Any improvements in the code will be more than welcome @LouisCAD 💯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants