Hi Mark, how are you?

hello, Leora! I'm doing fine -- and you?

Ok, just bewildered as usual hahaha

welcome to the world of Android app development! :-)

I've been in it 6 years and still bewildered

2 questions

fire away!

First one, if there is a way to save fragments...without viewpager, since viewpager2 which I wasted a day implementing with it's spiffy toolbar...cannot disable the transition animation

what do you mean by "save fragments"?

I mean, my boss (also the developer of the iphone version) doesn't like the flicker that can be seen the first one or 2 times clicking on the tab for that fragment

it takes a while to populate the recyclerview grid

a while meaning a split second, but it is noticable

are you caching the data that is used to populate the RecyclerView?

he claims in iphone you can pre-load

i am caching the images loaded into the cards using glide

how about the model data that you use for the RecyclerView.Adapter?

i don't think i am

it 'settles' after the third click on the same tab...but first 2 are jolty

you can tell ViewPager to be more aggressive about caching pages via setOffscreenPageLimit(): https://developer.android.com/reference/android...

(that link didn't go to the method -- Campfire's URL parsing rules need work...)

i did that...but viewpager 2 can only disable user swipe

transitions from page 5 back to one is awful

oh hahaha

oh, sorry, I misread your earlier comment and though you were using ViewPager instead of ViewPager2

no, i posted this last week

but since then realized the class is final anywayz

I have not used ViewPager2 yet, so I don't have any recommendations on that

so i removed the viewpager

(though ViewPager2 also has setOffscreenPageLimit() FWIW)

any way to cache the fragments without ft.add() and hide()/show()?

there is the attach()/detach() pair as well

yes it caches nicely. but i can't disable the animation page transitions

though I think those will force you to regenerate your views

i think so too

in terms of disabling the animation page transitions, will setPageTransformer(null) do that? or perhaps setPageTransformer(someTransformerThatDoesNothing)?

hmmm i dunno. i threw it out

what about when you asked if i cache the model data for the RecyclerView.Adapter

how would i do that?

that would depend a bit on your architecture, where the data is coming from, etc.

for example, if you are using the Arch Components ViewModel, you might have an activity-level ViewModel that can load and cache the data

that way, even if the fragment gets recreated, it can get the cached data from that activity-level ViewModel (e.g., by activityViewModels() in Kotlin)

or, perhaps add caching in your repository layer, if you have one

if your fragment is hitting a database or network API directly... then you would need to add a viewmodel or repository that can handle the caching

i don't think retrieving the list of max 12 items is the problem though....would it?

where is the list coming from? a server? a local database? something else?

or is it the retrieving/renderring the images?

no network. the lists are pre-defined

pre-defined, meaning they are hard-coded in the app code?

it's literally Category.getList()

not hard-coded, but defined in onCreate() in Main

so those objects are already around by the time that your fragment is created?

yes they are

OK, that's not going to be a problem then

and i would think glide would cache those images the first time around...not the 3rd

if there is other stuff in the cache, perhaps the LRU algorithm is getting confused

you might want to check your Glide memory cache settings and see if they need tweaking: https://bumptech.github.io/glide/doc/configurat...

ok i'll look

is there any way to pre-cache all fragments images before the fragment is loaded?

Glide has a pre-load API

but then it will still be new fragment.replace?

or create all fragments at once and then show/hide?

that's up to you

(BTW, use preload() with Glide to load the image into the memory cache, or downloadOnly() to download it just to the disk cache)

then what's the default?

"what's the default" for what?

when you don't specify glide options -

isn't that loading into memory cache?

yes, but you asked "is there any way to pre-cache all fragments images before the fragment is loaded?"

if you are relying on load() to populate the memory cache, at that point you are displaying the image in an ImageView (or whatever)

so, for example, suppose you wanted to preload the images in Glide back where you define these objects for Category.getList()

you don't have an ImageView there for those images

so, you use preload() to get Glide to download the images and load them into the memory cache

so, the next time you call load(), if those images are still in cache, they are used from the cache

oh! this sounds promissing!

by golly, i think that' it

thanks so much Mark

frequently, we do not know the image URLs in advance, so preload() is not an option -- in your case, probably it is an option

you're welcome!

yes it seems like it is!

ok, shall we move on to preferences, settings, or whatever android makes us call them now?

sure!

ok, in my main flavor I have base preferences xml. then in my say, other flavors, i add to the prefs

up to here, all is good

however

i want the flavor options to merge with the base categories...doesn't work

more so, android studio tells me i have a duplicate category key :/

are you getting that at compile time or at runtime?

runtime

i can ignore it, but anyway the flavor prefs are separated from the base prefs by a divider line

instead of extending them like i want

are you calling addPreferencesFromResource() twice, once for the base and once for the flavor?

if not, how are you arranging to get both the base and the flavor preferences into your PreferenceFragmentCompat object?

yes, addPreferencesFromResource() is twice

and you have a PreferenceCategory with the same key in both preference XML resources?

yes

I'm not surprised at the error -- I do not think that the loading mechanism here is that sophisticated

merges are probably beyond the capabilities of the loader

so is there any way to include flavor prefs in the same category as base prefs?

probably manually

what do you mean? duplicate xml?

or is include supported?

(i think not)

I mean making addPreference() calls on the PreferenceCategory to add the extra preferences

I don't think <include> is supported here -- AFAIK, that is just for layouts

ahhhh, i can call the actual preference category by it's key and then add it?

add to it i mean

after loading the base, you should be able to call findPreference(), passing in your key, to get to the PreferenceCategory defined in the base

then, you would call addPreference() to add additional preferences to that

that's a really good idea

I do not know if there is a way to accomplish that by inflating your flavor preference XML though

I cannot rule it out, but I am not seeing an option for that in the API

oh

so you mean, literally code the flavor prefs in

oh gawd

or parse the XML yourself, which is equally "oh gawd"

yessireee indeed

there is setPreferencesFromResource(), which takes a resource ID and a key, but I think it does a complete replace, based on the docs

what you are trying to do isn't crazy, but I suspect that it is beyond the stock abilities of the preference stuff (both the deprecated framework stuff and AndroidX)

yes, it replaces...my extended class with addPreferencesFromResource completely overrides the base class setPreferencesFromResource

beyond the capabilities....as usual hahaha

it seems so obvious to be able to do this!

well, in fairness, while what you are trying to do isn't crazy, I will argue that it *is* a bit of an edge case

i argue it is not sir! :)

well thanks for the discussion

sorry that I didn't have a better option for you for that one

as usual it was both enlightening (you), comforting (you), and frustrating (android)

:)

I try to be useful!

that's all for today's office hours chat

listen, i made it to the android dev summit in october, and was shocked that the android api devs themselves didn't have answers to several questions i asked them directly!

thanks so much, take care!

the next chat is Thursday at 7:30pm US Eastern, and the next 8:30am chat is 5 March

have a pleasant day!