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 |