4

well most of us familiar with this pattern:

   public class MySingeltone {

    public String mSomeReferenceTypeData;
    public int mSomeValueTypeData;

    private static MySingeltone mInstance;

    private MySingeltone() {

    }

    public static MySingeltone getInstance() {
        if (mInstance == null) {
            mInstance = new MySingeltone();
        }

        return mInstance;
    }
 }

my problem is that I've found recently that the mInstance don't equal null after activity using him been destroyed, or when the whole application suppose to be clause, for example:

public class SomeActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        MySingeltone mySingeltone = MySingeltone.getInstance();
        mySingeltone.mSomeReferenceTypeData = "some value";
    }
}

when launching "SomeActivity" next time after closing the whole applications running activities (say 10 seconds after..) the mInstance still holds the same reference, with the same values on his fields.

why does it happening?

what am I missing?

when android garbage collecting static members belongs to application?

Tal Kanel
  • 10,475
  • 10
  • 60
  • 98
  • Where do you check to see that the singleton is the same instance? – Jazzy Josh May 25 '12 at 21:28
  • @Jazzy Josh: you can see it simply by getting the value before setting a new one.in my example it would be between the getInstance method, to the next line. just need to check it don't equal null, because first launch the value would be still be null.. – Tal Kanel May 25 '12 at 21:32
  • I specifically mean where in the application. If your Activity is never killed, then you will go from onStop to onRestart and onStart instead of going through onDestroy and being killed and your Singleton will still be alive. – Jazzy Josh May 25 '12 at 21:36
  • @Jazzy Josh: I'm going through onDestroy() for sure. then I'm opennning the applcation again – Tal Kanel May 25 '12 at 21:47
  • This is what that supposed to be. So it is static singleton. But i had opposite situation: when reference holding Activity has been destroyed, singletons was gone either! Why? – Arvis Dec 15 '12 at 09:46
  • @Arvis: what do you mean when you say "singelton gone also"? it became null? anyway - it is possible that after onDestroy() called, and no other activity from your application is forground, the system decided it is the time to complitly "close" your app, and by that - to free all it resources and memory. – Tal Kanel Dec 15 '12 at 09:52
  • @TalKanel, i mean instance become null and has been re-instiated when next time referencing to it. Application process was still active. If application has been killed too, then there is no matter - in this case all variables are reinitilized and instatiated as firt time. – Arvis Dec 15 '12 at 09:56
  • @Arvis: then maybe it a bug in your code... ? :-< I can have a look if you want – Tal Kanel Dec 15 '12 at 10:03
  • @TalKanel I'm not the only one take a look at this poust: http://www.devahead.com/blog/2011/06/extending-the-android-application-class-and-dealing-with-singleton/ at lower part : " sometimes some static variables bound to activities happened to be uninitialized even though they’ve previously been initialized!....." – Arvis Dec 15 '12 at 10:14
  • @Arvis: ok. I'll read it later today. thanks.. it sounds intersting – Tal Kanel Dec 16 '12 at 05:08

3 Answers3

5

Since "mInstance" is a static variable it will not get null when you close your application. Closing of application doesn't means that your application got destroyed.

Also there is no concept of Closing your Android app. If you get out of your app it will not get destroyed at the same time. Android OS handles it internally when to close the app when it is no more in use. In case of memory shortage when android decides to destroy the app then this static variable will also got null.

rizzz86
  • 3,862
  • 8
  • 35
  • 52
  • 3
    This answer is wrong, if the memory is full and android os decides to evacuate his application then this variable WILL be null as well next time he tries to use it. – Ofek Ron Apr 29 '14 at 05:54
2

You can not control when exactly Java objects become garbage collected. An object becomes eligible for garbage collection when there are no more (non-circular) references to it. With Android, further, you can not control when your Activity gets removed from memory.

Alexander Kulyakhtin
  • 47,782
  • 38
  • 107
  • 158
  • so does it mean that if I'm expect my singelton class to be null when some activity creates - I need to set it to be null in the onDestroy() method or something like that? – Tal Kanel May 25 '12 at 21:39
  • @Tan Kanel Yes. But it is strange you want to destroy a singleton as singletons are supposed to represent something which always exist. Maybe you might have some open()/close()/isOpened() methods in your singleton instead, or maybe it should be a Service. – Alexander Kulyakhtin May 26 '12 at 06:13
  • yah, you right, that's what I'm doing sort of, but I asked it more for the principle.. – Tal Kanel May 26 '12 at 06:24
0

why does it happening?

what am I missing?

when android garbage collecting static members belongs to application?

Ok first, as others said, there is no close application concept on Android as the android OS manages lifecycle of your application process on their own.

Second, you did the wrong test - if instead of closing all apps you would do the opposite - that is - fill up memory by starting more and more apps, then eventually your application's memory would be cleaned up to be used by other applications and this includes all static mebers as well as instance members! then, you will see that the static variable WILL BE NULL as you expected.

They just "lazily" clean up memory, if there's enough memory then you application might never get cleaned up.

Actually, there is no way around it, as far as i know, there is no way to grauntee an object would not be cleaned up at any point from the device memory. in somecases it leads to bad behaviour. such as if the singleton does heavy processing on its creation, calling getInstance might get your UI stuck, or even make your app crash due to irresponsibleness.

Ofek Ron
  • 8,354
  • 13
  • 55
  • 103