hello, Jeff!

how can I help you today?

Hi Mike.

I'm going through my own View Pager right now. Its hosted by a Fragment Activity, and has a FragmentPagerAdapter within the pager.

I'm having an issue with config changes, where the old fragments do not reattach to the activity within the pager

(BTW, hello, Guarav -- be with you in a bit!)

Jeff: usually, that just works, as FragmentPagerAdapter sets the tags on the fragments

I'm setting setRetainInstance(true) on the fragments that the FragmentPagerAdapter inflates

I don't have tags set in the .xml files....

again, FragmentPagerAdapter defines the tags

i would think it would work as well...i'm just at a loss on why this doesn't work.

it's part of the stock implementation

what is the specific behavior that you are seeing, when there is a configuration change?

Its nothing more than a countdown timer for a crossfit application im working on.

just during the phone rotation. people are wanting me to go into the manfest and do the whole 'configchanges|orientation, but i know that is a bad idea

again, I need to know the specific symptoms that you are seeing

for example, are you crashing?

No...no crashing. whenever the phone rotates, it goes into a state like the application just started up fresh

if i'm counting down, or have a time set, it looses it, and looks like a fresh application start

the fragments do not reattach.

I have my code up on github.

um, well, bear in mind that retaining a fragment does *not* retain its views

so if i have an edit text and i rotate the phone, it won't replace it?

on the contrary, the configuration change *will* replace the EditText

and, for an EditText, the built-in onSaveInstanceState() logic will hold onto the entered text

by virtue of calling the super class?

or just not overriding it in the first place -- either way

no kidding...hmm...

for example, in the book, where I cover configuration changes, I have the sample app where you let the user pick and view a contact

the Button for viewing a contact will be enabled only after the user picks a contact (otherwise, there is nothing to view)

however, even though I retain the fragment, I still need to call setEnabled() on the Button, as "being enabled or not" is not automatically managed by onSaveInstanceState()

retaining the fragment retains the *contact*, though, so I can conditionally enable the Button in onCreateView(), depending upon whether or not the user has picked a contact

so I'm assuming that restoring the fragments does too much for me..

your guide has a countdown timer in it...if i was to roate the phone mid way through, would your application go back to a fresh state? I would have to restart the runnable?

off the top of my head, I do not remember, sorry

no issues, you have a ton of stuff in your book...impossible to remember everything.

a more general question then...would I have to restart any runnables that are called before the config change?

I don't know what "restart any runnables" means in this context

let me take a question from Guarav, and I'll be back with you in a bit

Guarav: do you have a question?

um, OK, back to Jeff, then

I have a Fragment within the Adapter that calls Runnable that is being used for my countdown timer, a postDelayed call comes in every so often to update the time.....if this runnable is not retained by the OS automatically...do i have to restart it?

whenver a config change happens?

where are you stopping the postDelayed() loop?

when the counter reaches 0.

if you are doing that in onDestroy(), you will need to start up a fresh one in the new activity instance

I'm not stopping it at all...not calling OnDestroy or anything...I had assumed the OS would reattach EVERYTHING....

bad assumption :)

I don't think I have tried your scenario specifically, but it should be easy enough for you to test, via log messages in your Runnable's run() method

understood. would the TextView content be saved upon screen rotation? doing the manifest trick (config|orientation) IS a bad idea, correct?

I would expect text in a TextView to be saved, though usually that's static and set in the layout file, so I don't know when I have last tried a configuration change on dynamic TextView text

using android:configChanges should be a last resort, for cases where it's flat-out impossible to hold onto state any better way (e.g., game trying to rebuild a GLContext)

I tried to save items in the onSaveInstanceState within the Fragment, and pull them back out in OnCreate...but the Bundle is empty for some reason...I am able to save items in a Bundle at the Activity level, but its like the items that I save in the Fragment never reach the Activity for saving...

I have an example demonstrating that working, in the same chapter where I cover the rest of the configuration changes

though I don't have a mash-up of using both a retained fragment *and* custom onSaveInstanceState() logic

let me swing back to the others, and I'll return to you in a bit

no problems

hi, Ollie: do you have a question?

Nothing right this sec

OK

if you think of something, let me know

Guarav: do you have a question?

OK, Jeff, back to you

appreciate the help. So if i save something at the Fragment level (contents of a Text View, values that give the current state), and I pass that to the super class...it should still be saved, correct? I save items at the Fragment level and never get them back in the OnCreateView in the Fragment...I can both save and extract items at the Activity level....

yes, that should work

I can't rule odd oddities based on you both retaining the fragment and trying to use onSaveInstanceState(), though

Hmmm...i guess I broke something alone the way... maybe missing a call somewhere.

ohhh...should I be using one and not the other?

in principle, I would not expect problems using both

in practice, I suspect that most developers that retain the fragment do not bother with onSaveInstanceState()

holding onto the "state" in data members of the fragment instead

why are you retaining the fragment?

I figured it would retain EVERYTHING...the Text Views, the state of visibily of certain ImageButtons, and the Runnables I have to count.

no

I'm learning that :)

*all* setRetainInstance() does is keep the Fragment instance itself around

and hence, anything it directly holds onto

it specifically does *nothing* with respect to retaining anything involving the UI, unless you do that yourself (e.g., my Button-and-contact scenario)

well....nuts.

unless you have a clear reason to retain the fragment (e.g., it's managing an AsyncTask), I'd skip retaining the fragment

if it retains the instance of something complex like an AsyncTask...why not the current values of a TextView?

you are comparing apples and apple crates

complexity is not the issu

er, issue

Is the Runnable, postDelayed that is currently running a reason to retain the fragment?

retaining a fragment does not *directly* have anything to do with managing an AsyncTask

however, *if* you have a retained fragment hold onto the AsyncTask, then the AsyncTask can safely interact with the fragment during a configuration change

because the fragment isn't being destroyed/recreated

gotcha

I would not consider a postDelayed() loop to be a reason to retain a fragment

understood.

(BTW, Guarav and Ollie -- if you have a question, chime in)

Yes, I'm monopolizing right now, but will step aside if you guys have anything.

Ok, I'll take a look at this tonight and redo that side of the application, in addition to why the Fragments Bundle onsavestate is not reaching the Activity.

Mark, thanks for your time.

you are very welcome

I am just here to learn all I can on fragments. Still haven't wrapped my head around them yet.

I take it the book chapter on them didn't help?

It did, but for some reason I just am having issues thinking sometimes lol

OK

It will click eventually I am sure

well, that's a wrap for today's chat

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

ok man, have a good evening

the next chat is Thursday, 7:30pm Eastern

have a pleasant day!