I think I got my bit to research further more into it! But just look at this one final argument.
I am not telling the solution in my above mentioned post is correct. But the only solution that ensured that my static data was consistent was to convert it from static data to an object of Application class. (The solution that is mentioned in the blog post). Consider this scenario 1) Activity A(SingleTask) launches Activity B 2) Activity B uses static Data containing boolean, int and arraylist. 3) send it to background, and return after 45 mins. Returned to Activity A . 4) Check static Data. int initialized to garbage. Boolean to false. arraylist to null. No, the application wasn't killed or restarted, my logs also show the PID(dosen't change). I am performing absolutely nothing when the app is in background so I am giving android no reason to clear memory or close activity. Convert static data to a object of application class and no logical change at all(I did a Tit for Tat). This issue is fixed. If you think this bit I mentioned is impossible just direct me to a resource/book that makes me design more definite tests to prove this or gives me an insight to static data handling inside the DVM, JVM etc. It cant be possible Mobile OS that has cases of sleep, hibernate, lock and low memory conditions will just make sure that static data stays there. Even if the application is marked as always running. Appreciate your time. On Thursday, 3 May 2012 16:02:37 UTC+5, Mark Murphy (a Commons Guy) wrote: > > 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
