| Sep 27 |  7:25 PM | 
| Mark M. | has entered the room | 
| Mark M. | turned on guest access | 
| Sep 27 |  7:35 PM | 
| Ed T. | has entered the room | 
| Ed T. | Howdy Mark! | 
| Aaron | has entered the room | 
| Mark M. | hello, Ed and Aaron! | 
| Mark M. | Ed: you narrowly beat Aaron here, so... do you have a question? | 
| Aaron | howdy | 
| Ed T. | Curious your thought on the best way to sync background threads with the UI... would you use a Looper ? | 
| Sep 27 |  7:40 PM | 
| Mark M. | that depends a lot on what you mean by "sync" | 
| Mark M. | my default approach nowadays is LiveDataa | 
| Ed T. | was my question that crazy?  :-) | 
| Mark M. | er, LiveData | 
| Mark M. | not crazy, but "sync" could have a lot of different definitions | 
| Mark M. | could you explain a bit more about your scenario? | 
| Ed T. | sure...  JSON config file...   that we get via a payload | 
| Ed T. | has options which could be called states... I guess | 
| Ed T. | and all of these require logging or hitting a server for an action... if they are flipped on | 
| Ed T. | Was trying to find a nice clean way for a Background task to come back the UI | 
| Ed T. | and the UI handle it when it comes in cleanly and update state | 
| Ed T. | because 2 of these could be pending in the background | 
| Ed T. | not many | 
| Ed T. | basically a document with a few background updates based on the settings | 
| Mark M. | for that sort of background work, I'm mostly using RxJava (for the background "heavy lifting") and LiveData (for getting the results to the main application thread in a lifecycle-aware fashion) | 
| Mark M. | RxJava isn't a requirement, though -- you can use LiveData with any sort of background work | 
| Mark M. | Google will be steering developers towards WorkManager, which also delivers results via LiveData, but that's more of a 2019 thing | 
| Ed T. | I've not heard of LiveData... is it on GitHub? | 
| Ed T. | k | 
| Mark M. | it is part of the Architecture Components | 
| Mark M. | I have several chapters discussing LiveData in "Android's Architecture Components", part of your Warescription | 
| Sep 27 |  7:45 PM | 
| Ed T. | I'll check it out tomorrow... I'm on NYC time | 
| Ed T. | I set an alarm to ping you | 
| Ed T. | best $20 I've ever spent...  for my 2nd subscription | 
| Ed T. | cheers!  Have a great evening... | 
| Mark M. | thanks for the kind words! | 
| Mark M. | you too! | 
| Ed T. | yvw | 
| Mark M. | Aaron: your turn! do you have a question? | 
| Aaron | yes, here are my questions for today, descending order of priority | 
| Aaron | View paste
 (4 more lines)   | 
| Mark M. | regarding your 1st paragraph... unfortunately, <include> is only for layout resources, otherwise that would be a possible solution | 
| Mark M. | you could always cook up something yourself via custom Gradle tasks to assemble menu XML from pieces, but that's probably way more work than it is worth | 
| Mark M. | so, either only have one menu resource (and do something in code to change the UI as needed), or I think you're best off living with the duplication | 
| Aaron | OK | 
| Mark M. | regarding your second paragraph, I definitely steer clear of distribution issues in my books, as that is a sticky wicket | 
| Sep 27 |  7:50 PM | 
| Mark M. | but in terms of signing keys, I would use the same key that you plan on using "for realz" when you ship the app | 
| Sep 27 |  7:50 PM | 
| Aaron | OK | 
| Mark M. | you probably don't have a choice if you are using Play Store's beta system | 
| Mark M. | and if you are rolling your own beta system, using the same key (and application ID) means that beta users can seamlessly upgrade to your final release | 
| Aaron | have not actually researched that option yet, I will do so, currently the beta is limited to one person ;) | 
| Mark M. | let me switch back to Ed for a bit, and then I'll return to work through more of your list | 
| Aaron | OK | 
| Mark M. | Ed: back to you! do you have another question? | 
| Mark M. | Ed, if you have another question, chime in and I'll take it | 
| Mark M. | Aaron: in the meantime, back to your list... | 
| Mark M. | "Is there any way to determine what styles are applied to some given text on screen?" -- none that I know of | 
| Mark M. | "For 3rd party libraries like Retrofit, Picasso, Glide, etc, is it typically necessary to do anything manually to avoid leaking threads?" -- usually these libraries are set up for dealing with config changes, such as having a static thread pool | 
| Sep 27 |  7:55 PM | 
| Mark M. | however, certainly check for leaks from time to time, or integrate LeakCanary | 
| Aaron | OK | 
| Mark M. | in your fifth paragraph... that quoted sentence is probably obsolete | 
| Aaron | ok, p.3718 FYI | 
| Mark M. | in terms of your last paragraph, what is the WebViewClient doing? what methods are you overriding? | 
| Aaron | nothing too exciting:  | 
| Aaron | View paste
 (10 more lines)   | 
| Mark M. | I wouldn't expect that to break video playback, but ¯\_(ツ)_/¯ | 
| Sep 27 |  8:00 PM | 
| Ed T. | has left the room  | 
| Mark M. | you might put breakpoints or logging in there to see if it is getting invoked | 
| Aaron | yeah ok, no worries | 
| Mark M. | and that wraps up your list | 
| Aaron | it is, I was trying to do some debugging by hooking it into the Chrome developer tools but I don't know enough about web technologies to make sense of it, I may try posting this one on SO | 
| Aaron | yeah, that's all I've got | 
| Aaron | thanks! | 
| Mark M. | you're welcome! | 
| Aaron | has left the room | 
| Sep 27 |  8:30 PM | 
| Mark M. | turned off guest access | 
