hello, Jan!

how can I help you today?

Hi, Mark!

if you have a question, go right ahead and ask!

I'm working with Retrofit as I posted on the forum. I'm wondering if there's a way not to have as many classes. I have my view model - no problem. Then my view state model. Then for Retrofit, I have a Result that also has Content and Error (like the View State). And it adds up fast - hundreds of server requests/responses. So any way to reduce all these classes?

well, if you are going based on the Weather example, I added in some extra classes to demonstrate a point

(OK, "demonstrate" might be the wrong word -- "illustrate" might be better)

in a larger app, it is not necessarily safe to assume that the Web service response is both stable and something that you want to use for the rest of your app

so I introduced the idea of the repository doing some adjustments to the raw results (e.g., wrapping in result classes)

you can get away without those if you're willing to deal with the rippling impacts of when the server team changes their Web service responses

and, if it so happens that you *are* the server team, well, you can control how frequently that happens :-)

and there are some libraries that can help package some of that stuff up, such as https://github.com/slackhq/EitherNet

so, some of what I show in Weather can be avoided, but in the end, you still will wind up with a fair number of classes

you always need Retrofit and classes that model the server response, and you always need a viewmodel

The web server team seems to write some buggy code. Currently my view "waits" on the response using the model's view state. The class that makes the call to the server sets either Content or Error in its "WeatherResponse" clone.

well, network I/O may take time, particularly for users with poor Internet connections

so, a loading/content/error UI pattern is reasonably common

where you're showing a loading state while the I/O happens, after which you either have your content or info about the error

How about the use of Content/Error in the cloned Response? Maybe I just need a wrapper on the data class for the JSON response?

that is not required, and when I next rewrite Weather, I might switch to using https://github.com/slackhq/EitherNet or perhaps will get rid of it

but, again, isolation is important -- you do not want to be stuck having to rewrite vast quantities of code because the server team changed the JSON on you

(or whatever your data format is)

so, technically, nothing is stopping you from saying that the Retrofit response classes roll right on to you fragment... but that magnifies the scope of those server changes

in the context of the literal Weather app, WeatherResult is a bit silly, but it's there to illustrate a point

Using EitherNet could work well for me. And the sealed classes are small so I could keep them in because I do like isolating impact of changes away from viewmodel. It's just crazy how fast all these classes build up. It looks like EitherNet suggests a better way of handling errors too.

yeah, I can't argue with the explosion in classes that you get from having a wide Web service API

if you're able to work in Kotlin, at least the class definitions usually are pretty small

Yes. I wish there were more examples of Retrofit with Kotlin. Thanks. I might be back on Saturday with questions on EitherNet. lol

I haven't had a chance to put EitherNet into practice yet -- it's on my to-do list -- but it looks promising, which is why I mentioned it

Sure. I understand.