The "problem" only occurs with lazily initialized singletons. If you only perform the initialization check in *one* activity then this bug can occur, but it's an app issue. If activity A initializes the singleton, then launch activity B, then go to another app, your process might be killed. When you go back to the app, activity B is started (but NOT A) and your singleton is not initialized.
The correct way to do it is either to avoid lazy initialization or to perform the check on every access. On May 3, 2012 2:14 PM, "DebUggEr" <[email protected]> wrote: > I will get back with a test that can prove this, as soon as I lose Codejam > :) > > Thanks for all your time. > > On Thursday, 3 May 2012 11:01:37 UTC+5, DebUggEr 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/<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<https://groups.google.com/forum/?fromgroups#!topic/android-developers/2i82mjoM46M/overview> >> " >> >> Anxious. >> > > On Thursday, 3 May 2012 11:01:37 UTC+5, DebUggEr 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/<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<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 -- 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
