Well this really depends on the game. For smaller scale games the
time to load from scratch is so short you might not realize that the
game is actually being restarted.
The framework is what it is and we can discuss this to the cows come
home. The original point was knowing the order of all the calls and now
it's clear enough that I can work with it.
Oddly enough on BlackBerry I just have to pause my game when being put
into the background and I resume when put back into focus. I don't
loose my OpenGL context and I am not forced to do anything. The end
user experience is better as there are no forced loads. I would have
thought a newer API would be easier for the developer.
On 6/8/2010 4:49 AM, Sean Hodges wrote:
There are a lot of large successful games available on Android, and
they all appear to be using the activity lifecycle without much
problem. I would start by taking a look at how they work.
My experience is that a game might "pause" when I leave to answer a
phone call or run another app. When I return, the app offers to resume
gameplay, and very occasionally an app will present a "loading" screen
as the game is re-loading its state. The resume time never takes long
(if it is needed at all), which suggests that most existing mobile
games strive to ensure there is not a lot of game state to save. This
is the common case, and the one mobile gamers are used to.
The worst case for the end user is if the game developer has worked
around the app lifecycle to keep their game in memory, and it causes
incoming phone calls to become unresponsive or drop completely.
Adhering to the activity lifecycle is the most efficient way to make
sure that this doesn't happen. The key is not to think of the activity
lifecycle as a set of unwieldy rules forcing you to do this and
that... Think of it as the environment that you are working in. You
are writing for a multitasking OS running on a range of devices, most
of which have very limited resources, and many require real-time
interruptions such as phone calls and text messages. The requirements
on how you store and retrieve your state is how Android handles the
resources, a bit like how OpenGL restricts how you handle textures to
meet resources of the graphics card.
I agree with Frank, Mark and String; if your
onSaveInstanceInstanceState() is going to take a long time to
complete, then you need to reduce the amount of data you are trying to
store. Perhaps if you describe the kind of content you are dealing
with (e.g. textures, 3D map data, etc), you might get some suggestions
on how to handle them more efficiently within Android.
On Tue, Jun 8, 2010 at 4:38 AM, Leigh McRae
<[email protected]> wrote:
The common case is where an activity is put into the background and isn't
killed for memory. Forcing an Activity to save it's state when it's not
required is a waste of resources on a resource scarce platform.
On 6/7/2010 10:38 PM, Frank Weiss wrote:
Hmm. I'm trying to grok how a world simulation that needs lots of memory
is a common case instead of an extreme case for a handheld mobile device.
--
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
--
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
--
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
