there's an issue for Result support. it was blocked on Result being stable but could probably be added to the core now

okhttp only considers 200-300 as success. Why not 304 not modified as success?

because you cannot read the body of that response to get access to the data

Shouldn't the http client give me back the "cached" body, though? Or am I missing something here

in response to a 304, the http client will read the cached body and change the status to 200

Oh okay. So in my application code, I never have to do anything with a 304 as the client just exposes it as a 200 success.

Is there a way in my client code to know that my 200 was caused by a 304

I believe you can track the Last-Modified header value and see if it differs. But that may only be for time-based caching and not things like ETag. I'm not sure

Thanks. I assume in general cases your calling code doesn't actually need to know how the data came back (fresh data or cached).

Think

response?.networkResponse?.code = 304

should work

Oh right. I've been doing ktor client 🤮 and forget all the handy things in OkHttp

Oh very cool that there's a distinction vs the response and the network response. I dig it.

I'm using retrofit + moshi (and slacks eithernet too, but I'm putting that aside for right now) and working with a new api that'll always have this as a response wrapper essentially. What actually comes down inside of the nested

data

model is a model that is unique for each network call.

{
  "ok": true,
  "data": {
    ...
  }
}

Should I try to use generics or a polymorphic type adapter? So something like

suspend fun callOne(): BaseResponse<ActualOneResponse>
suspend fun callTwo(): BaseResponse<ActualTwoResponse>

or should I use

PolymorphicJsonAdapterFactory

and ask my backend to send back down a discriminator/labelKey?

another thing you could do is automatically unwrap the envelope with a custom adapter. this would validate

.ok == true

and otherwise propagate the error with an exception (or whatever mechanism you want, like an either type)

that would allow your signature to be

suspend fun callOne(): ActualOneResponse

So this would be a custom retrofit adapter right? Not a moshi adapter?

Here’s an example of this https://speakerdeck.com/jakewharton/making-retrofit-work-for-you-droidcon-uk-2016?slide=123

I'm using an SDK which uses Moshi underneath to provide some data, and the fields aren't being escaped. I'm trying to figure out if this is standard behavior or not.. JSON returned from the server:

{
  "body": "This is a test",
  "body_html": "<div class=\"body\">This is a test</div>"
}

gets deserialized into a model by Moshi with a codegen'd adapter, and at this point what would you expect the string value of

model.bodyHtml

to be?: 1.

<div class=\"body\">This is a test</div>

2.

<div class="body">This is a test</div>

I feel like I'm having a mind blank here. I thought Moshi escaped it for us, but that's not the behavior I'm currently seeing? or am I remembering all wrong?

I would expect 1 but without the escaped quotes

Moshi does not understand HTML entities

Nor are encoded HTML entities any part of the JSON spec

ahh I think I know what my brain has done.. in my mind I'm conflating string escaping with HTML escaping

Yeah make a @EscapedHtml JSON qualifier annotation and write an adapter for @EscapedHtml String which reads a string from the JSON and then does a single pass HTML entity replacement

just starting to look at doing almost exactly that right now, thanks mate

next step will be to find a fast and competent html escaper.. building my own sounds fun but time consuming. I think I remember Android's

fromHtml()

uses some library internally to assist with this, but there's also

kotlinx.html

these days which might be useful any recommendations?

hmm.. maybe I'm wrong and building my own escaper isn't that scary. from some initial digging I only need to handle

&

,

<

,

>

and

"

🤔

If you are just unescaping I would build my own

IIRC There used to be limitation around the max number of fields returned from a table. Does that limitation still exist?

256 i think

With the adoption of Compose in Android, do you see Contour as still necessary or preferable in some cases (above Compose)? i.e. is Compose encouraged above Contour, or do both co-exist nicely in CashApp code? In your experience, what has worked better in Contour, or Compose in building dynamic UI? Any pitfalls or pain points?