Hello people, do you use a Result type wrapper in ...

# android-architecture

[koufa]

Hello people, do you use a Result type wrapper in the return types of your components? What if you use Clean Architecture. Would you use a Result type in Repositories, UseCases and ViewModels?

[Anastasia Finogenova]

It is actually in the Google's guide to clean architecture as a part of the example, but I don't use in any of my mvvm/mvp projects as imo it just created additional "noise" and don't see much value added

[tschuchort]

I mostly use RxJava Single or do you mean something different?

[Anastasia Finogenova]

I thought you mean this one?

[Pablichjenkov]

I use it very often the pattern in the screenshot above. But instead of calling it Resource I name it Event. I also move the constructor fields from the base class to the subclasses. I don't use it with generic since I create one inner Event class per remote resource class. Maybe generics make it a clearer design.

[ghedeon]

I ended up using Kotlin Result for api calls. It's quite common for http request to fail, so a constant reminder that you have to handle the error is good. With exceptions it was too easy to skip/forget the handling. But doing it for everything might be an overengineering. As for google attempt, idk, having Loading in Result always felt like a very poor decision.

[Anastasia Finogenova]

My error handling is either in rx onError (and it will actually crash if you don't implement it which will help not to forget) or in the catch block of a coroutine which is something you just have to know will throw an exception for multiple reasons and you need to catch it including your network errors. Now when you actually wanna add custom logic for failure like in the case when the request was successful but the response from the server is "failure" then having that Error in the Resource situation makes more sense.

[dino9]

I use mvvm + clean arch + RxJava in one of my recent project. I do handle this result type in repository.

[koufa]

Yes I was talking about a type like the Kotlin Result type or the Resource from Google ( but without loading etc).

[koufa]

The thing is when I have an architecture like: ViewModel ---> UseCase ---> Repository and then Repository returns type Result I may have to use a when statement in UseCase then do my actions and return a new Result object and maybe use also when statement in ViewModel. Seems a little bit too much "when" overhead. This could be mitigated though by writing extensions methods.

[ghedeon]

no need for extra conversions. Repository gives you domain level Result with exceptions that are wrapped in some sort of domain Error. What's left is handling, probably in ViewModel and generating success/error state for the view.

[koufa]

Not always. There could be following scenario. We defined we could have for example a GetUserMovieListUseCase that combines data from 2 Repositories like: UserRepository and MoviesRepository where both of them return their data wrapped in some Result type. Then you have to check them both to combine them in a new `Result`type.

[ghedeon]

Yes, you might need to merge the errors. Frankly speaking, there are not that many errors that user can do anything about. Most of them will end up in a silent log to your monitoring tool, or a generic Try again button. So, at least in my case, the when statement stays pretty lean and doesn't bother me much.

[Pablichjenkov]

Excesive use of when is fine. Is the way. Think of it as a discontinuous function in math.