Take the 2-minute tour ×

Recently I have started development in Java for Android.

My idea is to create one static class which will load ton of stuff on the beginning and store results for a lifetime of application.

I have been reading lot of how to share object between activities and I think the best will be to create one static class. What do you think? Should I use another approach? I am asking because I have read lot of counter opinions over the internet.

Thank you.

share|improve this question
The best way is to use SharedPreferences –  Pragnani Feb 26 '13 at 7:29
@Pragnani Shared preferences are good for some types of data- small amounts of data that fits a key/value model and doesn't take a long time to load into memory. It doesn't fit every problem. –  Gabe Sechan Feb 26 '13 at 7:30
Do you mean a singleton? A "static class" is an inner class that doesn't require an instance of its enclosing class, which has nothing to do with sharing application-wide data. –  Wyzard Feb 26 '13 at 7:32
@Wyzard, yes I meant singleton. My fault. :) –  Mihalko Feb 26 '13 at 7:49
add comment

3 Answers

up vote 7 down vote accepted

I'm assuming that you were referring to static fields of a class, as opposed to static class which, as Wyzard pointed out, is something completely different. As a general rule of thumb, holding information in static fields is not a good idea in Java. The reason for this is that it prevents the ability to instantiate multiple instances of whatever it is you store in the class.

In the specific case of an Android application, the best way to deal with the issue of having data stored associated with the application itself is to subclass the android.app.Application class and use it to handle application-global data:

class FooApplication extends Application
    private String privData;

    public String getPrivData() {
        return privData;

You then need to declare that this class is your main application class (instead of the default Application). In the application entry in AndroidManifest.xml add the following:

<application android:name="com.example.application.FooApplication"

You can then look up the application instance from anywhere inside your application using the method Context.getApplicationContext() which will be an instance of your Application subclass:

FooApplication app = (FooApplication)context.getApplicationContext();
String privData = app.getPrivData();
share|improve this answer
I was referring to static class. Ok, I there are more comments on this type of storing application data, so I will go this way. Thank you. –  Mihalko Feb 26 '13 at 7:47
add comment

Android provides a class called Application, which is will not be gc'ed as long as your Application isn't killed. Use this class for initialization, static classes as containers are somewhat ugly, but i can't pinpoint why that is.

I only use them as containers for constants such as bitmasks which can't be expressed as EnumSets.

As the other posts mention SharedPreferences: I think the preferences exist to store values, but not to load your structures that you need for you application. These structures should be loaded from a construct that represent or make up a model for your data's semantics.

share|improve this answer
add comment

The problem with your solution is that you're basically creating a huge stack of globals. It's sometimes unavoidable, but it has the same type of problems globals always have- you quickly end up with hard to read code that doesn't really have a good OO breakdown. You can use this, but use it sparingly- only with important data structures that are really going to be shared between many activities.

share|improve this answer
Any API you create or use eventually boils down to a reference that is static or always exists during application lifetime. It all depends on how well it's designed. –  ATrubka Feb 26 '13 at 7:35
add comment

Your Answer


