Office Hours — Today, February 21

← Yesterday, February 20

Feb 21
7:25 PM
Mark M.
has entered the room
Mark M.
turned on guest access
Steve S.
has entered the room
Mark M.
hello, Steve!
how can I help you today?
Steve S.
Hi, Mark!
I have some questions about fragments. I
Here's the first one:
View paste 
1. In a fragment, is it ok to make a view a (non-static) member field if setRetainInstance() isn't used (i.e. called with true)?
Mark M.
sure
Steve S.
ok. but it wouldn't be if setRetainInstance were called with true?
Mark M.
it's even safe if you do call setRetainInstance(true), *if* you make sure that you *always* populate that field in onCreateView()/onViewCreated()
the risk comes from filling in the field, then not replacing it on a configuration change
you would get this from a lazy-retrieval pattern in a getter method, for example
so getButton() { if (button==null) button=findViewById(R.id.button); return button; } is not safe
Steve S.
i see. so onCreateView/onViewCreated are called regardless of whether setRetainInstance is set to true?
Mark M.
correct
you always get fresh views on a configuration change
Steve S.
but onCreate is not called in a fragment if setRetainInstance is set to true?
7:30 PM
Steve S.
i mean on a rotation
Mark M.
I'm pretty sure that's correct -- after all, the fragment instance is already created
Steve S.
great. got it
My next question:
In your fragment example Dynamic, you make a call to findViewById() in onCreateView(). I have seen some suggestions that calls to findViewById() should be made instead in onViewCreated(). Does it make any difference?
Mark M.
not especially
I've been moving more to onViewCreated(); that's an old example
you might inherit your onCreateView() (e.g., ListFragment) and only have an onViewCreated()
Steve S.
ok
i have another question pertaining to your Dynamic example:
View paste 
For a fragment, is there any reason to save state via onSaveInstanceState() rather than persisting state in onStop() and restoring in onStart() (as in an activity)?
Mark M.
you would use onSaveInstanceState() in a fragment for the same reasons you would in an activity
there's really no difference
Steve S.
ok
7:35 PM
Steve S.
my understanding is that persisting state in onStop() provides a more general solution to the problem of persisting state (though it's more work) since onSaveInstanceState() won't always be called. is that correct?
Mark M.
um, I wouldn't characterize it that way
first, persisting data to disk and onSaveInstanceState() aren't really the same thing
Steve S.
ok. what are use cases for onSaveInstanceState()?
ok
Mark M.
suppose you are writing a to-do app
or anything with a form
the user is on the activity or fragment with the form
the user partially fills in the form
and a phone call comes in, or a text message comes in, or something else distracts them and takes them to another app
the question is: what do you do with the partially filled-in form content?
the user has not clicked "save" to say that they want to save it to the main data store
a typical approach -- and the one that Android takes by default for most user-editable widgets -- is to stuff the form content into the saved instance state Bundle
if the user is gone from the app for several minutes, the app's process may be terminated, taking the activity along with it
if the user returns within 30 minutes, though, Android will re-create the activity and its fragments, handing each back their saved instance state Bundle
the framework will repopulate the widgets that had been filled in previously
7:40 PM
Mark M.
so, when the user returns, it is almost as if the app had been around that whole time, even though it hadn't
but, if the user leaves and does not return for quite some time, that state is discarded, on the grounds that the user probably doesn't care about that partially filled-in form a day later
and for most apps, this works well
most apps != all apps
for an app where the user would be pissed if the partially filled-in form is discarded after, say, 45 minutes, you would need to save that data, possibly via a thread kicked off by onStop()
and how you save that data, to take into account that it may be partial and the user never clicked "save", is up to you
so, the saved instance state Bundle is for smallish data (forms, object identifiers, etc.) that you would like to hold onto for a bit while the user is off doing something else, but you won't mind if you never get it back
Steve S.
that's a great explanation! very helpful
My last question:
View paste 
When do you need to check the return value of getActivity() for null in a fragment? Only when it's called from the non-UI thread?
Mark M.
that's a typical pattern
7:45 PM
Mark M.
most of the time, with regular callbacks, you already know whether or not there is an activity
(e.g., onDetach() there won't be; pretty much everything else, there will be)
a background thread can't make that assumption
Steve S.
makes sense
no more Android questions today.
Mark M.
OK
Steve S.
i did want to ask if you mind if i post some of the content of your answers on Stack Overflow. (for instance, there's a question about the difference between onViewCreated/onCreateView)
Mark M.
if you don't mind linking back to the chat transcript, go right ahead
Steve S.
cool.
thank you so much for all the great help. i really appreciate it!
Mark M.
you're welcome!
Steve S.
have a great rest of the day!
Mark M.
you too!
Steve S.
has left the room
8:25 PM
Mark M.
turned off guest access

← Yesterday, February 20

 

Office Hours

People in this transcript

  • Mark Murphy
  • Steve S