The scarce resource here is memory, NOT time to save and load. If it is taking you too long to save, then you probably have too much memory in use for a good mobile application.
If you are careful about how much memory you're using, treating memory as a cache, and writing out changed things as you go, very little work will need to be done when you switch out. Designing for scarce memory is very similar to designing for high scalability. In general, you're going to be better off spending CPU cycles to persist your data, and abandoning the details, reloading only if needed again. Aggressively hanging onto data to save CPU will generally backfire. Delaying saving data will generally backfire as well. Your first priority is to make your data size as small as possible. That's your hard constraint. Then, if there's sufficient memory available, you can use it to improve the CPU performance and responsiveness. But if you're using your memory as a cache -- you need to limit the amount of dirty data in the cache, or you'll kill responsiveness when the cache has to be flushed. Responsiveness is also a matter of not doing a lot of work all at once. Even if the lifecycle were to wait until it's about to kill your app before asking it to save -- you would still have a problem, if you need to save a lot to passivate your activity. The 1/5 second that String refers to below is a reasonable limitation. You should never be doing anything in that large of a chunk. One design pattern is to reference all your major data items via very thin proxies. These can load the data, retain it, but allow it to be GC'd (via WeakReference, etc.) On modification, you can queue up to a work queue to persist the data. Being on this queue will protect the data from being GC'd before it gets saved. Then in your onSaveInstanceState() method, you simply flush the queue, persisting the remaining items. You then satisfy the 1/5 second constraint by limiting the length of this persist queue. If it reaches this length limit, then any additional entries force saving one or more items before placing the additional item on the queue. This queue also serves to reduce the number of redundant writes of data which is modified multiple times. If two modifications occur before the data is saved, they will be combined and the data item will only be saved once. Sometimes you can take this to an even greater extreme, and maintain a pool of proxies, rather than allocating and GCing them. A small number of proxy objects can then effectively provide access to far more data than will fit into memory. This is very similar to how ListView and Adapter work together to make a small number of views provide a display for huge amounts of data. Think of it this way -- you think your application would be better if Android worked differently, because you have so much data. I suggest thinking, instead, of your application as being just a small toy. How would it have to work if you were working with 1000x as much data? 1000000x as much? Because, in effect, that's the design case that Android is optimized to handle -- not your little huge application. :=) Or, alternatively, much less memory than you expect. But it's a very different design paradigm, and it takes some getting used to. On Jun 7, 8:38 pm, 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 McRaewww.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
