On 6/7/2010 9:43 AM, Mark Murphy wrote:
Leigh McRae wrote:
So are you saying that onSaveInstanceState() is always called before the
system needs to kill an activity?
I am saying:
1. onSaveInstanceState() is always called before onStop(), as that is
something both our docs references are in agreement upon
2. onStop() damn-near-always will be called before the process gets killed
Ergo, by the transitive property of bullet points, onSaveInstanceState()
damn-near-always will be be called before the process gets killed.
The "damn-near" part is the phone's-screwed-up condition that I
mentioned and really wouldn't worry about, any more than you worry about
meteor strikes.
:: briefly checks out office window ::
See! Nothing to be afraid of!
Gotcha. I am not concerned with the trivial case of normal app life
cycle and the case where the system is about to die. I am only
concerned with the case where the user exits my app using the HOME key
and then goes on to open many more apps and also leaves them using the
HOME key. At some point the system will run out of memory. I would
expect this to be a pretty come case and at some point I am going to be
the one kicked from memory. I want to be sure my game handles this with
the best possible experience for the user.
This is the source of my confusion. I want to detect this case. I don't
want to dump everything at onPause() if I don't have to. At this point
as far as I can tell that onSaveInstance() must always be called before
onStop() for this case (being put into the background) as I don't see
how it can know where I am just popping up a quick options screen and
then back to my app or leaving the app in the background as I wander off
into a trail of other apps. It would be nice to be able to simulate
this scenario with tools so that my app can be tested. Would using a
task killer have the same effect?
IMHO this whole activity life cycle topic and issues with static
variables could really use more literature or an IO session. Coming
from BlackBerry this has been the biggest learning curve. From what I
have seen game developers have taken a pass to this whole framework and
just killed their app at onPause().
If so that makes perfect sense and we
are done.
Who-hoo!
Is there a way to artificially force this scenario to happen so I can
test my app survives?
Which scenario? If you mean the process-gets-killed scenario, use a task
killer. By the time you get to the task killer activity and kill your
process, whatever activity of yours that was in the foreground will now
be stopped.
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.
Understood!
--
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
