hello, Aaron!

how can I help you today?

hello again Aaron!

how can I help you today?

hey Mark! I have 4 questions today, though I didn't get a chance to type them up ahead of time, so I'll go one at a time, should be pretty straightforward today

OK

I'm adding a settings screen to my app, using SharedPreferences. The official docs say this: "The preferences you create probably define some important behaviors for your app, so it's necessary that you initialize the associated SharedPreferences file with default values for each Preference when the user first opens your app." It says to use setDefaultValues(). They use the word "necessary" but I noticed you don't call setDefaultValues() in EmPubLite - so are the official docs wrong on this?

there is more than one way to skin a cat

in the particular case of EmPubLite, I think that the overall defaults of "false" for the preferences was fine

Ok, that's simple and makes sense

Second question

At one point, one of the libraries I was using must have been relying on an older version of the support library internally, as my Gradle was saying: "All com.android.support libraries must use the exact same version". The library seems to have been updated since then, but I temporarily "fixed" the problem this way:

My question is, that seems like a sort of tenuous solution. Would something like that ever be used in production code, and if not, how do developers deal with situations where the libraries they are using lag behind?

Contact the library's author and hassle them to update it? Override it like that and test to see if it breaks? or...?

this specific problem -- needing to have consistent support library versions -- should be going away as part of the move to AndroidX, if I understand correctly

I'm sure that some people use your solution, and so long as it works, ¯\_(ツ)_/¯

OK

if you don't like the Gradle syntax, you could add your own explicit dependency on the offending support library, to pull it up to the newer version

if the lagging library is open source, you could fork the library, add the fork as a module, and use the newer support library

nagging is certainly a possibility, including "nag by pull request" for an open source project

for a proprietary library, using Gradle to force the upgrade is your only real option

OK, cool, good variety of ways to deal with it, that's a helpful answer

last question, so I've gotten most of the core functionality working in my app, the next big thing I am tackling are the activity/fragment lifecycles, debugging them all and ensuring I am following best practices as best I can

the biggest bug I know I currently have in relation to that, is this:

on rotation, the screen doesn't actually clear out, a phantom image of the RecyclerView sticks around in the background like that

off the cuff, is it obvious where that's coming from? if not, don't worry about it

I'm not clear from the screenshot what phantom image you are referring to -- however, one common way to have this sort of duplicated-content effect is to add fragments blindly in onCreate() of your activity, rather than seeing if they exist already

it would be nice if the AVD could do a video screencap. No worries, I need to spend some time debugging it and I'll come back with a more specific question if needed

that's all I've got - thanks

screen recording works with the emulator

there's a toolbar button for it in the LogCat view of Android Studio, and there are command-line options

oh, I just saw this

now, a screen recording with an orientation change might get strange -- I've never tried that

ok, I launched the app, rotated to landscape, and started recording then. For some reason it still saved the video in portrait, but this shows more clearly what's happening

I understand it's difficult to provide guidance without code, like I said just running this by you in case there is an obvious answer

you have two RecyclerViews, possibly from two fragments

one is higher on the Z axis, so that's the one that your finger is interacting with

for fragment-related work, the typical recipe in onCreate() is to see if the passed-in Bundle is null, and only initialize the fragments if it is

OK, yeah I wasn't sure if I had 2 RV's or if it was some kind of display artifact, I guess I should have hit it with the Layout Inspector to check. that gives me a good place to start looking into it, thanks

yes, the Layout Inspector probably shows two RecyclerViews with their respective rows

fragments, not being views/viewgroups, won't show up in the Inspector

OK, got it. Cool, I'm hoping to get this code cleaned up as best I can in the next week and get ready to publish the first version of this app, and when I do I will try to catch you on a day where no one else is in the chat, and hopefully identify some areas for improvement

OK

by the way, does this chat support a typing indicator?

nope

nuts

it doesn't support those either

OK, I am out, enjoy the rest of your weekend!

:-)

Lol

you too!

take care

that's a wrap for today's chat

the transcript will go up on https://commonsware.com/office-hours/ shortly

the next chat is tomorrow, also at 4pm US Eastern