Create a sample application that reliably reproduces your claimed behavior, and post it somewhere.
On Thu, May 3, 2012 at 12:40 PM, DebUggEr <[email protected]> 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 -- 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
