On 6/7/2010 6:50 AM, Mark Murphy wrote:
Leigh McRae wrote:
Looks like it says both :) Still whether it's before onPause() or
onStop() doesn't matter much.
"To capture that state before the activity is killed, you can implement
an ||onSaveInstanceState()
<http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState%28android.os.Bundle%29>||
method for the activity. Android calls this method before making the
activity vulnerable to being destroyed — that is, before |onPause()| is
called. "
http://developer.android.com/guide/topics/fundamentals.html#lcycles
:: sigh ::
I still wouldn't count on it happening before onPause(). Meantime, I've
filed a bug:
http://code.google.com/p/android/issues/detail?id=8900
For the BACK button that is trivial and very clear. What happens I
launch the browser from my app and it covers my app as in my example. I
would go through onPause() and onStop(). Both docs say that
onSaveInstanceState() would have been called by now but the system
doesn't know if it will run out of memory at some point with the
browser.
It doesn't care whether "it will run out of memory at some point with
the browser", any more than Microsoft Word, saving a temp file of your
in-progress edits, cares whether or not Windows will run out of pagefile
space. Word saves the temp file because that's what Word does, to deal
with any number of scenarios, such as Word simply crashing. Similarly,
Android will call onSaveInstanceState() so that if it kills the process,
or continues sometime to onDestroy(), that you will have had a chance to
save your instance state.
So are you saying that onSaveInstanceState() is always called before the
system needs to kill an activity? If so that makes perfect sense and we
are done. The thing is that the docs state, as have you, that it must
come sometime before onStop(). Forget the very trivial case where the
user starts an activity and ends it. Pretty clear stuff. For all the
other cases, either onSaveInstanceState() is always called before
onStop() as it can never know for sure if it has to kill you to quite
possible much later. Or onSaveInstanceState() isn't always called
before onStop(). Which is it?
Correct. Unlikely, but correct.
If it can happen it needs to be handled.
Not necessarily. I suspect the vast majority of apps aren't specifically
worrying about it, mostly because nothing much needs to be done for them
for that scenario.
4) Since the system has enough memory onSaveInstance() doesn't get
called.
I have no idea where you came up with this.
I would expect onSaveInstanceState() to have been called in this
scenario, before onStop(), and around the time of onPause().
It's been inferred since the system has no way of knowing for SURE if it
will have to kill the activity, at which time I have already been put in
the background and received onStop(). Now for the trivial case where the
system starts another activity and needs more memory it makes sense.
Like I said, you will have received a call to onSaveInstanceState() in
and around the times of your onPause()/onStop() calls. If you have
evidence to the contrary, I'm certainly interested to see it. As your
documentation counter-example demonstrates, it's not like we can
necessarily count on the docs.
The 99.44% pattern for your use case is:
-- The activity receives onPause() and onSaveInstanceState(), in some order
-- The activity receives onStop()
-- Time elapses (seconds, weeks, whatever)
-- The activity receives onDestroy()
The next-most-common pattern is:
-- The activity receives onPause() and onSaveInstanceState(), in some order
-- The activity receives onStop()
-- Time elapses (seconds, weeks, whatever)
-- The process is killed, either by Android (low memory) or by the user
(task killer)
While in principle the process could be killed before onStop(), if that
happens, the user has much bigger problems than your app not correctly
cleaning up. After all, this means that the device's memory is screwed
up so bad that Android feels it needs to kill the process *immediately*
upon it losing the foreground, before it can get to onStop(). The user's
phone is going to need a reboot, plain and simple. The user can't
readily invoke a task-killer before onStop() gets called, because to get
to the task-killer activity to pick your process, you'll wind up being
called with onStop().
If you have concrete evidence that the scenarios I list above ain't
happenin' for you, please let me know!
Is there a way to artificially force this scenario to happen so I can
test my app survives? The reason that this is such an issue is that
most games will do a one time loading of all it's resources upfront and
it's not to the users benefit if I am forced to dump this when it's not
required. So I want to get this right.
--
Leigh McRae
www.lonedwarfgames.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
