hello, Aaron!

how can I help you today?

Hey Mark. Today I have one question, about p.126 in the Architecture Components book

OK

In the last paragraph on that page, you say "Most developers will not be creating their own LifecycleObserver classes ... Instead, developers will tend to use observers created by others. Most notable among those is LiveData"

I'm confused by the terminology here

what version of the book are you looking at?

0.9

ah, OK, I was looking at 0.10

Oops. Must have missed that

Anyway

OK, I now have that open and I see your quoted passage

My understanding is that LiveData would be the "observable" and the "observer" would be your Observer object in which you override the onChanged() method. So why are we calling LiveData an observer?

yeah, that's poorly phrased

part of the confusion is that Google uses "observer" as a term in many different places

for example, a LiveData Observer is not a LifecycleObserver

a LiveData has a LifecycleObserver in its implementation

so the LiveData is observing lifecycle events and using them to control its operation, including what it passes along to its own observers

I have made a note to cover this more in the next update to this book

ok, I am reviewing documentation to make sure I understand, sec

the point that I'm trying to make is that while the Lifecycle stuff is available to everyone, it is relatively low level and you are more likely to use things that themselves use the Lifecycle stuff (LiveData, Uber's AutoDispose library for RxJava, etc.)

ok, that makes sense, I need to come back to this later after a break but I think that clears it up

and by "LiveData Observer" you mean android.arch.lifecycle.Observer<T>, correct?

yes

ok great.

That's all I've got, thanks

you're welcome!

also, in case you are interested, I figured out the last problem we discussed about logging inside of retrofit callbacks

The problem was using getClass().getSimpleName() for the tag argument. getSimpleName() returns an empty string when called in an anonymous inner class, and evidently that prevents logcat from displaying the message. Calling getClass().toString() instead resolved it

that's odd -- I use getSimpleName() a lot and I don't recall running into that

but, anonymous inner classes are odd beasts, so I'm not completely surprised

for temporary logging, I've taken to using the current date in YYYMMDD format, as it makes for a nice thing to filter on in the LogCat view

glad to hear that you got it worked out!

yeah, and I also learned how to do some better logging with an interceptor, very helpful

ok, thanks for your help

take care

you too!