5

I am aware of the technique of extending the Application class to provide global storage. However in my case I am writing a class for a library function, so do not wish to force users of the class down this path. I have a requirement for some static class variables. I have seen passing references in StackOverflow that these might not be safe. However I've tried two different applications using the same class, and even when running both applications side by side on a Galaxy S3 in multi-window mode, the static class variables remain separate.

So, can someone with an in depth knowledge of Android internals confirm if this is safe or not.

If it is not safe, I can wrap the variables in a nested class and add them to a Serializable static HashMap, using the application package name as the key. This will force them to be safe. However if this is not necessary, then I'd rather not do it.

Steve Waring
  • 2,882
  • 2
  • 32
  • 37
  • This might be helpful to you - http://stackoverflow.com/a/16736271/2114852 – Sam May 24 '13 at 22:57
  • You're over thinking this one. Why would you need to use the static variables? There isn't another way to code it? – mrres1 May 24 '13 at 23:01

4 Answers4

10

I have seen passing references in StackOverflow that these might not be safe.

They are not "safe" insofar as your process will be terminated from time to time, wiping out your static data members (and your custom Application, for that matter). Hence, static data members are good for a cache and not much else.

Within that scope, they are "safe".

You just need to make sure that this data is either stored somewhere persistent (e.g., file) or otherwise can be regenerated once the process is terminated and later is started up again. This is no different than with Application.

However I've tried two different applications using the same class, and even when running both applications side by side on a Galaxy S3 in multi-window mode, the static class variables remain separate.

Correct. Those are separate processes, with separate copies of your class and objects.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thanks. In my case a call to a method in my class has to perform a fair bit of initialisation, parsing xml, etc. I can set a static Boolean initialised to true and parse the xml into static variables etc. When it is called, if initialised is true, it can skip the parsing etc. – Steve Waring May 25 '13 at 08:57
  • @user2202013: That is a fine use of a static cache. Just be careful to watch your memory consumption, to avoid leaks and not run out of heap space. – CommonsWare May 25 '13 at 08:58
5

If your goal is to store persistant data across the twists and turns of the application lifecycle, then I would recommend not using static variables to do so. The obvious problem with this approach is that they could easily be garbage collected by the system when the operating system decides to reclaim memory (i.e. when the screen sleeps or a different application starts a memory-intensive task). I'm not sure what kind of data you are looking to "store", but I would recommend saving the state in SharedPreferences or an SQLiteDatabase instead.

Community
  • 1
  • 1
Alex Lockwood
  • 83,063
  • 39
  • 206
  • 250
1

I'm a little confused about what you're trying to do. You're trying to create a utility library in Java to be used by other applications? You're trying to create a whole Activity intended for use by other applications?

At any rate, as other posters have mentioned, applications can be killed at almost any time when resources become tight. There's simply no way to guarantee that static global values will remain resident in memory. You must provide a way to back it up on onPause() or onSaveInstanceState().

If you're writing a utility library, I presume that it returns some master object which holds all of its state. Add saveState(Bundle), restoreState(Bundle) methods to that object, and optionally saveToSharedPreferences() and restoreFromSharedPreferences() methods as well.

If it's an Activity you're writing, you're probably already familiar with the ways of saving state.

Me, I'm fond of combining the "singleton pattern" with shared preferences: https://stackoverflow.com/a/13673178/338479

Community
  • 1
  • 1
Edward Falk
  • 9,991
  • 11
  • 77
  • 112
  • In short yes, an activity to greatly extend managing settings with either sharedPreferenceFragments or sharedPreferencActivity depending upon the release of Android. When invoked, there is some set up that needs doing, parsing XML, etc. So I can use a static Boolean to tell if the initialisation has loaded data into static variables. If garbage collection has not taken place between the first call and the next call, then there is no need to parse the XML etc again. Many thanks. – Steve Waring May 25 '13 at 09:07
0

You seem to have a deep misconception of how classes work.

Even if two classes are in the same package in two separate apps (by default) those apps run on separate VMs (i.e., processes). They literally have nothing to do with each other (as it should be, since otherwise you might get cross-app name collisions which is unacceptable).

What you're looking for is not a way to use static variables but a way to do inter-process communication (IPC). Android's Services are ideal for this, though there is a bit of a steep learning curve there.

Delyan
  • 8,881
  • 4
  • 37
  • 42
  • I understand how classes work, I think it is the authors of the comments I have occasionally seen who were confused. I just wanted to check that there was not something very very weird in the dalvic VM. – Steve Waring May 25 '13 at 08:52
  • The only weird thing is that the base classloader may be destroyed and reinitialized due to memory pressure, removing your static instances. – Delyan May 25 '13 at 10:18