hey Mark! Just two questions today

hello!

fire away!

1. P.758 of BCG says OkHttp is a modified clone of HttpUrlConnection, but then it says that a version of OkHttp powers HttpUrlConnection in Android 4.4+... Can you clarify which one is a derivative of the other?

that sentence on page 758 needs work

it was correct once upon a time

OkHttp has moved on since then

I'll fix it

AFAIK, the platform still uses its own fork of the OkHttp code for its own HttpUrlConnection implementation

ok, but your point is that they are quite different from one another now?

OkHttp does not much resemble the HttpUrlConnection of ~5 years ago, back when OkHttp was introduced

and it probably does not much resemble the HttpUrlConnection in pure Java, though I haven't looked

OkHttp started with the Apache Harmony HttpUrlConnection that was in Android, used the guts under a new API, then heavily rewrote the guts

(at least IIRC -- five years is a relatively long time)

OK, that's a good enough answer, I was just trying to understand what was going on with the back-and-forth forking, but it sounds like it's mostly irrelevant now

thanks

yup, relatively ancient history

but it illustrates why my books need an overhaul

my other question is in reference to the pattern shown in the "LiveData in repositories" section of this article, about halfway down the page: https://medium.com/androiddevelopers/viewmodels...

specifically: https://cdn-images-1.medium.com/max/1000/1*Ptw2...

that's the first picture under the heading?

yeah

I am using that pattern in my app now, namely, repository exposing LiveData which is mirrored into the ViewModel with switchMap, and then the UI observes the mirrored LiveDatas in the VM

however...

I am not actually sure what the benefit is of mirroring the LiveData with switchMap like that, instead of just having the Observers in the UI layer observe reference variables in the VM which point directly to the existing LiveDatas in the repository. I think I'm missing something obvious. At the time I set this up it made sense but now I'm not sure if I need it at all

I think I am missing something obvious

well, I haven't used LiveData in a repository

I tend to use RxJava there, converting it to LiveData in the ViewModel, because RxJava is a much richer framework (albeit heinously complex)

the net effect, though, is a bit reminiscent of that diagram, in that you're converting one reactive data source to another

in my case, it would be a Single or Observable being converted to LiveData via LiveDataReactiveStreams

but in my case, there is a clear reason for that conversion: I want lifecycle awareness at the UI layer, but I have no need for it deeper in the app

in your case, I'm not completely clear what the switchMap() value is

and the prose in that section is not very illuminating

so, I'd take that particular post's recommendation with a large grain of salt

hmm. I'll bring this up again once my code is cleaned up and ready for you to take a look at. I think right now I am not able to ask the right question, and once you look at the code, you will probably be able to help me ask the right one

your answers there may provide clues, but right now I don't have an effective follow up question, so I'll leave it

research some more and ask again if needed.

well, I interpreted your question as "am I missing something obvious?" -- the answer to that is "no, the recommendation in that post is genuinely confusing"

my long-winded explanation was mostly to emphasize that I haven't tried the LiveData-in-a-repository approach, and there may be very practical reasons for the recommendation that I'm just not thinking of

OK, I get you

the LiveDatas in my repository are all being created out of the results of Retrofit calls. My initial reason for exposing LiveDatas was because I figured if I did not, then I would have to do some kind of polling loop or something in my ViewModel, which sounded bad. I have not looked into RxJava yet, but it sounds like you are basically using it to overcome that same problem, if I understand correctly

yes

just as you can add a plugin to Retrofit to get it to support LiveData, there is an equivalent to get Retrofit to support RxJava

I see

your ViewModel could also use just good old-fashioned callbacks, if you prefer

the point behind an Architecture Components ViewModel is that it is retained across configuration changes, so it is a relatively stable base for such callbacks

the trend nowadays is to use reactive frameworks to get away from such callbacks

whether that is RxJava, LiveData, or a combination of the two

meaning, the repository would call methods to fill the ViewModel with data everytime it completes a network call?

fresh data*

oh, wait, sorry

the callbacks approach would imply that the ViewModel is making the Retrofit call

that gets ickier with a singleton repository, and that ickiness is what reactive frameworks are designed to address

OK, let me just try to get the code cleaned up enough in the next few days, to where I am not ashamed to post it here (lol), as I think it would greatly clarify everything

OK

BTW, a new Warescription site is going live on Saturday

I am likely misunderstanding some things without realizing and/or misleading you with regard to what is actually there, I think it will be very helpful to discuss in the context of a concrete example instead of me trying to ask abstract questions

ah, cool

new chat software?

no, same basic feature set as what's there now, but a fresh code base (Kotlin, as it turns out)

the chat isn't mine -- this is Campfire from the Basecamp folks

sounds good, look forward to checking it out

yeah, I was wondering if you rolled your own this time

if you run into problems, yell at me :-)

I will let you know!

talk to you soon

thanks!

see you next time!