15

(Title is misleading since garbage collectors collect only objects, but I found this title more straightforward)

Suppose I have an Android application with a static variable named "userid" inside a class called Global (which is null at initialization time).

If I set "userid" variable to some value duing Android application lifecycle, say Global.userid = "myid", is it possible for this variable to become null while Android application is still alive?

In other words, is it possible for Android VM to unload Global class and "kill" this global static variable due to low-memory issue without killing the whole Android application?

I am worried about the situation that userid becomes suddenly null while application is running (due to low memory issue), therefore crashing the whole app.

Edit I was misunderstanding some concepts (between application process vs activities). Thanks for all answers!

Seki
  • 11,135
  • 7
  • 46
  • 70
SHH
  • 3,226
  • 1
  • 28
  • 41
  • 1
    I think static for temp storage is discouraged in Andriod. I couldn't find that link right nwo. – kosa Nov 06 '13 at 23:06
  • Why would you think that would happen? Do you have any indication that it does? – Thilo Nov 06 '13 at 23:06
  • 1
    Absolutely not. Your whole application would have to be killed. However, it is possible that your application restarted without you much noticed, if you go to another application for some reason. – njzk2 Nov 06 '13 at 23:13

2 Answers2

24

If I set "userid" variable to some value duing Android application lifecycle, say Global.userid = "myid", is it possible for this variable to become null while Android application is still alive?

If you set it to null yourself, yes.

In other words, is it possible for Android VM to unload Global class and "kill" this global static variable due to low-memory issue without killing the whole Android application?

For normal cases, no.

If you play around with custom classloaders, it is conceivable that there may be scenarios in which classes get unloaded (and hence any static data members on them go poof) -- I seem to recall there was discussion about this scenario, but I forget the conclusion. However, very few apps should be messing around with custom classloaders.

I am worried about the situation that userid becomes suddenly null while application is running (due to low memory issue), therefore crashing the whole app.

That should not happen.

What can happen is that the user is in your app, leaves the app via HOME (or a notification, or an incoming call, or the recent-tasks list, etc.), then later returns to your app via the recent-tasks list. If your process had been terminated during the time it was not in the foreground, your static data member will be null when your activity is started up from the recent-tasks list. Since the activity the user returns to may not necessarily be your launcher activity, your app may behave as though the static data member spontaneously turned null, even though it was because your process had been terminated and restarted.

This is one of several reasons why static data members need to be used very carefully.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 1
    "Since the activity the user returns to may not necessarily be your launcher activity..." is this really the true case? Can you tell me exactly what happens when the application re-runs from recent-tasks list? – SHH Nov 06 '13 at 23:29
  • 1
    @SHH: "is this really the true case?" -- sure. "Can you tell me exactly what happens when the application re-runs from recent-tasks list?" -- Android returns control to whatever activity was on top of the back stack for that task. If the process hosting that activity had been terminated, Android starts up a fresh process and creates a new instance of the activity, before passing control to that new instance. – CommonsWare Nov 06 '13 at 23:31
  • 1
    So BackStack stays alive even after application terminates? Do you know whether applcation context stays alive as well? – SHH Nov 06 '13 at 23:39
  • 1
    @SHH: "So BackStack stays alive even after application terminates?" -- a representation of the back stack "stays alive". "Do you know whether applcation context stays alive as well?" -- only if your process is not terminated. – CommonsWare Nov 06 '13 at 23:41
  • 1
    So, even if android application terminates (hence releasing all resources used), the application process may still be alive? (which contains backstack and other information?) – SHH Nov 06 '13 at 23:46
  • 1
    @SHH: "So, even if android application terminates (hence releasing all resources used), the application process may still be alive?" -- no. "(which contains backstack and other information?)" -- that is not maintained in your application process. It is maintained in an OS process. After all, a task may span several applications (e.g., yours plus Google Maps, or yours plus a Web browser). – CommonsWare Nov 06 '13 at 23:48
  • 1
    My last question is, in http://developer.android.com/training/basics/activity-lifecycle/recreating.html, it says "However, if the system destroys the activity due to system constraints..., the system remembers that it existed such that if the user navigates back to it, the system creates a new instance of the activity using a set of saved data... " Do you know how Android manages to save application status after app process has been terminated? (does it maintain a datastructure at OS level or something?) You can give me a link too. Thank you very much! – SHH Nov 06 '13 at 23:56
  • 1
    @SHH: "Do you know how Android manages to save application status after app process has been terminated?" -- primarily, that is the `Bundle` you use with `onSaveInstanceState()` and `onRestoreInstanceState()`. – CommonsWare Nov 07 '13 at 00:19
  • "Android returns control to whatever activity was on top of the back stack for that task." Ahh! I started Android development at the time when fragments where "invented" and never used more then one activity in an app (except for splash in some of them). It was the right descision, I think. :D – The incredible Jan Nov 26 '21 at 14:00
1

If you are making the variable static so that you can access it from anywhere in your app without creating a new instance of the class every time I believe this is a good candidate for the Singleton pattern. 

String userid = Global.getInstance().userid;
Сорен Палмундь
  • 51
  • 3
  • How does this add anything important to the topic? I don't really like singletons because it's more to write for zero benefit. I don't see any advantage of Global.getInstance().userid over Global.userid. Singleton is only cool if you have a bunch of different data to be able to reset it quickly or you really need getter and setter. – The incredible Jan Nov 26 '21 at 14:15