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:
-- 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 scenario1) Activity A(SingleTask) launches Activity B2) 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 <sjkliteral.work@gmail.com> 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 android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment