Create a sample application that reliably reproduces your claimed
behavior, and post it somewhere.
On Thu, May 3, 2012 at 12:40 PM, DebUggEr <sjkliteral.work@gmail.com> 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 <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
--
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