The key thing to understand is that, unless you are doing something special, your .apk corresponds to a single process it runs in. Once the system needs to run a component in that .apk, its process is created. That process sticks around as long as those components are needed, and even after that if there is enough memory. For example, if you launch your app from home, hit back (so there is no nothing of it running), and then launch it again, more than likely your same process from the first time is still there and will be used to launch a new instance of the activity.
So a static is simply a global in your process, and will stick around for as long as your process does. Likewise any threads you create -- their lifecycle is tied to the process, unless you explicitly stop them. The duration your process will last is described here: http://developer.android.com/guide/topics/fundamentals.html#proclife This aspect of processes is extremely important to understand, because it is key to designing where your data goes (whether it is in a static associated with the process or local to a particular component) to minimize the amount of work you need to do as the user navigates your UI. The framework itself uses this extensively to maintain various caches in application processes to keep around data such as loaded resources for future use. On Thu, Jul 9, 2009 at 5:20 PM, Mark Murphy <mmur...@commonsware.com> wrote: > > > Hmmm...so, static class members are definitely always > > preserved through an orientation flip? > > Unless you manually null them out or something, yes. Static data, > services, Application subclasses, and the like all are unaffected by > rotations. > > > For example, I assume that doesn't necessarily apply to > > other sorts of changes, such as switching to another app. If an app > > goes to the background long enough and the user does enough other > > things with the device, it surely must get shunted from memory if the > > OS needs the RAM back, so in such a case statics would not survive the > > app coming back to the foreground, right? > > Correct. Static data, services, and Application subclasses are only good > for short-term storage. Anything that might need to survive a normal > closing of your activity should be saved either through > onSaveInstanceState() or your own files/database in a method like > onDestroy(). > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com > Android App Developer Books: http://commonsware.com/books.html > > > > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
