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 -- 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
