0

I found and read a lot of articles talking about global variables in Android, some of them suggests using an subclass of Application + declare it in the manifest file as a glbal variable container.

But some articles mentioned that This class could also be killed when system memory gets low, is this correct?

So, is it 100% reliable to use an Application subclass as a global variable container? And could somebody give me a link to some documents explaining the life cycle of an application in Android (not activity)?

EDIT:

Thanks for the answers, I think I need to explain a bit more of my question.

The situation is, I just want to share a global String variable, Activity A modifies it, and activity B reads it.

When B is currently visible and user receives a call, If A and B are killed but Application keep untouched (is this what Google calls an empty process?), I'm OK with it. If A, B, and Application class are all killed and when user come back my app gets a clean start, I'm OK with it.

Which I'm not OK with it is, everything was killed including the Application class, when user come back my app doesn't start fresh, I mean, it starts from Activity B, will this happen? then should I start A manually or let Application class to do the initiation? none of these ideas looks good to me...

agou
  • 728
  • 1
  • 10
  • 24
  • Thanks for the clarification on your question. I believe it is a very important concept to understand for any app with substance. See the edit to my answer... – Jim Nov 14 '14 at 05:07

2 Answers2

2

The answer is both "YES" and "NO" - the Application class can be used as a "global variable container" in that all activities and classes can rely on it.

However, you cannot rely on the Application class (or any other class) to persist indefinitely. In other words, if the user answers their phone, your application could be destroyed and then re-created when the user completes the call and returns to your app. So, you definitely cannot rely on it to persist data, but you can rely on it to provide global access to data when you app is active.

This is the Android documentation:

http://developer.android.com/training/basics/activity-lifecycle/index.html

This is a really good post on it - read the SECOND highest voted response, in addition to the "accepted" response:

Using the Android Application class to persist data

It explains pretty clearly how your app can be killed/destroyed whether you expect it or not.

EDIT:

To clarify, if you have a variable (call it "myVar") in the Application class and a user sets it in Activity A, then proceeds to Activity B, Activity B will be able to read the change.

If Android "destroys" the application class, which can occur anytime the user is not in your app (and in rare instances even if they are...), the app will be reconstructed so that the Activity Stack is still valid but "myVar" is not set, unless you persist the data.

In other words, Android will recreate the Application class and Activity B, but there is no guarantee that it will recreate Activity A until the user does something to destroy Activity B. Also, it will certainly not "replay" the user actions in Activity A in order to recreate the app state, and in your case that means "myVar" is not reliable.

If you read the references provided, you will see that this is the case (and also I have tested it).

EDIT 2:

To persist data, consider SQLite (which is pretty complicated and there are many references) or SharedPreferences:

How to use SharedPreferences in Android to store, fetch and edit values

Community
  • 1
  • 1
Jim
  • 10,172
  • 1
  • 27
  • 36
  • Thanks, I read that, but just not sure what happens when system restores a killed process (not activity)? (see my edited question for details), and is Application class the reliable global class to count on as long as the process is alive? (not activity) – agou Nov 14 '14 at 05:02
  • Thanks, it sounds unbelievable... but I'll go with sqlite storage first and when I get time I'll re-investigate into this issue. – agou Nov 14 '14 at 05:21
  • The core of the issue is that devs could store lots of data in the Application class which might be needed for more pressing purposes. See the edit to my post. And do look into it... – Jim Nov 14 '14 at 05:25
1

This class could also be killed when system memory gets low, is this correct?

Yes.

So, is it 100% reliable to use an Application subclass as a global variable container?

If you want to use it to pass values it is not reliable. why?

EDIT:

Which I'm not OK with it is, everything was killed including the Application class, when user come back my app doesn't start fresh, I mean, it starts from Activity B, will this happen?

yes. It is possible that you set a value in your application from activity A and then when you are in Activity B user leaves your app and after a while android kills your process. then user comes back wants to look at your app. android again recreates application and activity B but not Activity A and instead of fill the application variable with what has passed Activity A to it, it recreates it from default initialization. So simply you missed what has passed or set by Activity A.

Don’t Store Data in the Application Object

mmlooloo
  • 18,937
  • 5
  • 45
  • 64