Hi

hello, Shawn!

how can I help you today?

I am having an issue with using a ViewStub

I can try to help, but I have limited experience with ViewStub

I tried to read about it in the latest book, but I couldn't find a section describing it

did I mention that I have limited experience with ViewStub? :-)

Lol

So do I

so... what is your issue?

I can replace with ViewStub with a LinearLayout and to the happy, removeAllViews, getLoutInflater, addView thing

And that works

But I am trying to learn how to do it the right way

So my problem with the ViewStub is that after onResume of a Fragment, the ViewStub seems to lose it viewParent

And that makes things... well sad, inflates fail (because no viewParent)

do you mean, after a configuration change, like a screen rotation?

Nope

Switch to different app and come back

I have the screen rotation happily taken care of

do you know if your process is being terminated between when you leave the app and come back to it?

Process is not being terminated

So no onCreateView() being called, etc... just onResume when I come back

OK, give me a moment to do a bit of research

Sure, I've been fighting it all day in various ways.

Thanks

just to confirm, you

er, let's try that again...

just to confirm, you are setting up a fragment that, in whatever it is returning from onCreateView(), has a ViewStub

you are not inflating the ViewSTub

you are switching to another app (e.g., recent-tasks list)

you are returning to your app

you are then trying to inflate the ViewStub

and then you go BOOM due to the missing parent

A little different but not much

do I have that right?

Setting up a OnCreateView() which has a layout that contains a ViewStub

In onResume, based on a state, I am inflating the ViewStub

I am switching to another app

I am returning to the app

Then I am trying to inflate the view stub again (since onResume is being called)

why are you trying to inflate the ViewStub again?

And Boom, due to missing mParent

or, are you saying you didn't inflate it the first time, and now the state has changed and you're trying to inflate it?

I did inflate it the first time, but the state has changes and I need to inflate it again (differently)

I think that's your problem right there

AFAIK, you can't inflate it again

a ViewStub is a one-time deal

"When a ViewStub is made visible, or when inflate() is invoked, the layout resource is inflated. The ViewStub then replaces itself in its parent with the inflated View or Views. Therefore, the ViewStub exists in the view hierarchy until setVisibility(int) or inflate() is invoked."

hence, I would expect there to be a null parent after an inflate()

Ok I understand, but I don't know of a work around besides only inflating in the onCreateView

you would either need N ViewStubs (one per state) and get rid of the results of any previous inflation, or go with some other solution entirely for your circumstance

Or not using a viewStub

how many states are there, for which you want different content?

3

How would I switch them after I inflate one

well, to be honest, I'm unconvinced that ViewStub is really designed for your use case

Me too

Didn't design it unfortunately

to get rid of the results of an inflate(), call removeView() on the parent, passing in the root of what got inflated

As a side note, I don't like Fox Entertainment :)_

Ah

or, leave the inflated stuff there and make it GONE from a setVisibility() standpoint

True

Inflate all 3 and make them all gone, until I need one?

there are a variety of possibilities

if they're all fairly simple, you might just have them all in the layout, set visible or gone as appropriate for your initial state, and toggle visibility

Okay

I can give that a shot

if they are moderately expensive, you might inflate them as needed, but then just make them GONE (and make them VISIBLE again if you need them again)

if they are heinously expensive, you might inflate them as needed, then remove them when you do not need them

it's the classic RAM-vs.-CPU tradeoff

Thanks, I understand

in terms of inflating them, either have three ViewStubs, or just use LayoutInflater directly and skip the ViewStub

BTW, if you have another question, go right ahead -- it's a quiet chat room tonight

Thanks :)

Organization of jniLibs, native library directories

Oooo! Am I on "Jeopardy!" ?

If you have several SDKs included in an application and many of them contain different processor folders

"What is... stuff that I don't do much with either?"

Sorry

:-)

go ahead

Basically, I have a ton of video players in the app I work on.

I have been putting all the jniLibs, native files in the main project

Under their different processors

However, now that I have so many

The fallback logic for some specific ones is messed up

I was wondering if I made a separate project for each SDK

So that the jars that reference the native libs

were in the same project, but separated from the other SDKs

If that would straighten out the native library fail over logic

By that I mean, if you have an armeabi folder

are they all going into one app?

Yep

then I really doubt that it will make a difference

Yep, that is what others were saying in my group

I just wasn't sure how all that gets organized

it's more that, by the time it gets to the APK, where the stuff came from (library module, app, etc.) all gets lost

Makes sense

there may be code organization reasons for separation, but there should be no change in runtime behavior

that being said, if you're shipping a "fat APK" with all the CPU architectures, have you considered switching to per-architecture APKs, using splits in Gradle?

I have but even doing that the jars are so big, that they dwarf the size of the native files

ah

The armeabi is hugs

huge

but all of the other processor folder are somewhat small

but most of the processors (I think, I could be wrong) try to "emulate" the arm

clearly, you need to convince management to standardize better on video formats... :-)

If they can't find the proper architecture folder. X86 will fall over to the armeabi folder if there is no x86 folder...

I'm an integrator

for many x86 devices, yes, via libhoudini

The reason for the many different types is for the many different content providers, FOX, ABC, CBS, NBC, ESPN

ah

And even some of the networks use different providers.

Right now, NBC is using three different formats: One for normal, One for local, and one for regional sports

Crazy folks, every one of them

Thank you for the first answer. It worked out fine. parent.removeAllViews(), parent.addView(viewStub), viewStub.setLayoutResources(), viewstub.inflate()

Fixes the issue.

I'm not quite certain what using a ViewStub there dynamically buys you over just using a LayoutInflater

that being said, if it is working, I'm glad to hear it

It doesn't buy my anything, but what I inflate connects to a library which handles clicks and opens a webview for ads

If I replace the viewStub with any type of normal layout, the ad click handler in the library doesn't work

right, but you could inflate it via a LayoutInflater, bypassing the extra baggage of the ViewStub

parent.removeAllViews(); inflater.inflate(R.layout.whatever, parent, true);

anyway, just a thought

I will try it

that's a wrap for today's chat

the transcript will be posted to https://commonsware.com/office-hours/ shortly

Have a good night.

Thanks for the help.

you are very welcome

the next chat is Monday at 4pm US Eastern

have a pleasant day!

You too.