Question

Simple question. Reviewing my code, I’ve noticed that I’ve got a lot of variables declared multiple times in my classes or methods…for example:

public Long dbInsertCheckin(final String Class) {
final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
...
}

And

public class SmashDataSource {
    final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    final SimpleDateFormat sdf = new SimpleDateFormat("EEEE");
    final SimpleDateFormat timeFormat = new SimpleDateFormat("HHmm");
...
}

this got me thinking that instead of declaring “dateformat”, “sdf”, or “timeformat” or others i use in multiple places, would it not make more sense for me to declare these globally in my application class, then refer to them wherever I wanted like

public class MyApp extends Application {
public final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    public final SimpleDateFormat sdf = new SimpleDateFormat("EEEE");
    public final SimpleDateFormat timeFormat = new SimpleDateFormat("HHmm");

and refer to them later in other classes as such:

MyApp.dateformat
Myapp.sdf

Would this be better from a performance/memory usage point of view? Is there any reason not to do this? To me, it would seem that having declared them multiple times would consume more memory, vs. a final declaration once…. but I don’t know how the compiler does it’s optimizations.

Answer 1

There is nothing wrong with using global variables. Generally they are avoided to keep things flexible and encapsulated. But some design patterns like the Factory Pattern go well with static/global classes. It also avoids code duplication.

(However I might avoid using my Application class so my global fields are only used when needed, but that’s an implementation detail.)

I would do something like this probably. It keeps things flexible while also putting things in one place so they are consistent across your app.

public class MyGlobals
{
    private static SimpleDateFormat dateFormat;


    public static SimpleDateFormat getDateFormat()
    {
        if(dateFormat== null)
        {
            dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        }
        return dateFormat;

    }
}

Then you can use this in other classes:

MyGlobals.getDateFormat();

====

Here’s some info from the dev docs about it:

http://developer.android.com/guide/faq/framework.html#3

For sharing complex non-persistent user-defined objects for short
duration, the following approaches are recommended:

Singleton class

You can take advantage of the fact that your application components
run in the same process through the use of a singleton. This is a
class that is designed to have only one instance. It has a static
method with a name such as getInstance() that returns the instance;
the first time this method is called, it creates the global instance.
Because all callers get the same instance, they can use this as a
point of interaction. For example activity A may retrieve the instance
and call setValue(3); later activity B may retrieve the instance and
call getValue() to retrieve the last set value.

A public static field/method

An alternate way to make data accessible across Activities/Services is
to use public static fields and/or methods. You can access these
static fields from any other class in your application. To share an
object, the activity which creates your object sets a static field to
point to this object and any other activity that wants to use this
object just accesses this static field.

A HashMap of WeakReferences to Objects

You can also use a HashMap of WeakReferences to Objects with Long
keys. When an activity wants to pass an object to another activity, it
simply puts the object in the map and sends the key (which is a unique
Long based on a counter or time stamp) to the recipient activity via
intent extras. The recipient activity retrieves the object using this
key.

Persistent Objects

Even while an application appears to continue running, the system may
choose to kill its process and restart it later. If you have data that
you need to persist from one activity invocation to the next, you need
to represent that data as state that gets saved by an activity when it
is informed that it might go away.

For sharing complex persistent user-defined objects, the following
approaches are recommended:

Application Preferences
Files
contentProviders
SQLite DB

If the shared data needs to be retained across points where the
application process can be killed, then place that data in persistent
storage like Application Preferences, SQLite DB, Files or
ContentProviders. Please refer to the Data Storage for further details
on how to use these components.