I have plenty of these types of constructs in my code and I've never ever seen static variables becoming un-initialized. The only times they are uninitialized is when the process (DalvikVM) has been killed and restarted.
Are you sure that the code in your onDestroy (or some other life-cycle callback) doesn't un-initialize these static variables? Or, if these static variables are public, that some other code un-initializes them? On Thursday, May 3, 2012 12:40:19 PM UTC-4, DebUggEr wrote: > > 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
