AFAIK, the quoted passage is mostly incorrect. Classes are not unloaded once loaded.
There can be issues with static data members if you use multiple ClassLoaders -- AFAIK, you get the same effect in traditional Java. However, you should only encounter that when you create your own ClassLoader for one reason or another. And, of course, when the process goes away, static data members go away, but so do custom Application subclasses. If you examine the Android frameworks' source code, it is littered with static data members. Furthermore, based on a quick survey, only about half of the AOSP apps have a custom Application subclass, and half of those simply use it to initialize static data members. On Thu, May 3, 2012 at 2:01 AM, DebUggEr <[email protected]> wrote: > I have been testing and experimenting with android low end devices and > trying to find a consistent solution for singletons in android. I beleive I > have gone through most posts addressing this issue and I am pretty sure that > I have a good solution. > > http://www.devahead.com/blog/2011/06/extending-the-android-application-class-and-dealing-with-singleton/ > > " I found that sometimes some static variables bound to activities happened > to be uninitialized even though they’ve previously been initialized! I > thought that when a static variable is initialized it stays so for the > entire life of the application, but this doesn’t seem to be the case. Among > all the information I found on the web, I tried to find out a safe and > reliable way to initialize static variables (and you know that the singleton > design pattern requires the use of a static variable). The explanation of > the weird behavior I saw that makes more sense to me is that the static > variables instances are bound to the class loader of the class that first > initialized them. So what does this mean? This means that if a static > variable inside any class has been initialized by an activity, when that > activity is destroyed also its class might be unloaded and so the variable > becomes uninitialized again! While if the variable is initialized by the > application class, it’s life is the same as the application process so we’re > sure that it will never become uninitialized again. That’s why I chose to > initialize all the singletons in the MyApplication class." > > I want experts to look into this and confirm that this dosent has any > serious drawbacks. I am opposing this solution as previously discussed in > this same group > "https://groups.google.com/forum/?fromgroups#!topic/android-developers/2i82mjoM46M/overview"; > > Anxious. > > -- > 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 -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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
