In this post I’m going to show the basic steps to extend the Android Application class and I’m also going to talk about why it could be useful to extend it in dealing with the Singleton design pattern.

The first thing to do is to create a MyApplication class that extends android.app.Application.

package com.devahead.extendingandroidapplication;

import android.app.Application;

public class MyApplication extends Application
{
	@Override
	public void onCreate()
	{
		super.onCreate();

		// Initialize the singletons so their instances
		// are bound to the application process.
		initSingletons();
	}

	protected void initSingletons()
	{
		// Initialize the instance of MySingleton
		MySingleton.initInstance();
	}

	public void customAppMethod()
	{
		// Custom application method
	}
}

In this class you can, for example, override the onCreate method to perform your initializations at the application startup and you can also implement your own methods to make them available to the rest of your application components. As you can see here we initialize also the singletons in case there are some in our application. I’ll talk later about why I do this here, but now let’s go on with the custom Application class.

The next thing we need to do is to open the AndroidManifest.xml file of our application and add a reference to MyApplication in the android:name attribute of the application tag, so in the end the manifest file will look similar to this one:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
	package="com.devahead.extendingandroidapplication"
	android:versionCode="1"
	android:versionName="1.0">

	<uses-sdk android:minSdkVersion="7"/>

	<application android:icon="@drawable/icon" android:label="@string/app_name"
		android:name="com.devahead.extendingandroidapplication.MyApplication">

		<activity android:name=".MainActivity"
			android:label="@string/app_name">
			<intent-filter>
				<action android:name="android.intent.action.MAIN"/>
				<category android:name="android.intent.category.LAUNCHER"/>
			</intent-filter>
		</activity>

	</application>
</manifest>

That’s it. We now have a custom Application class that can be used to suit our needs. We can access to it from any Activity through the getApplication method (the same getApplication method is available also in a Service).

package com.devahead.extendingandroidapplication;

import android.app.Activity;
import android.os.Bundle;

public class MainActivity extends Activity
{
	protected MyApplication app;

	@Override
	public void onCreate(Bundle savedInstanceState)
	{
		super.onCreate(savedInstanceState);
		setContentView(R.layout.main);

		// Get the application instance
		app = (MyApplication)getApplication();

		// Call a custom application method
		app.customAppMethod();

		// Call a custom method in MySingleton
		MySingleton.getInstance().customSingletonMethod();

		// Read the value of a variable in MySingleton
		String singletonVar = MySingleton.getInstance().customVar;
	}
}

As you can see there are references to the MySingleton class also here as an example like there were in the MyApplication class, but we haven’t seen the singleton yet, so here it is:

package com.devahead.extendingandroidapplication;

public class MySingleton
{
	private static MySingleton instance;

	public String customVar;

	public static void initInstance()
	{
		if (instance == null)
		{
			// Create the instance
			instance = new MySingleton();
		}
	}

	public static MySingleton getInstance()
	{
		// Return the instance
		return instance;
	}

	private MySingleton()
	{
		// Constructor hidden because this is a singleton
	}

	public void customSingletonMethod()
	{
		// Custom method
	}
}

The initInstance method lets the internal instance be initialized only once and this is done in the MyApplication class as we saw earlier. The getInstance method allows to access the instance from every part of our application and the MySingleton constructor is kept private because we don’t want to allow the creation of multiple instances. Read the rest of this entry »

Example 1 (without importing the singleton class in the main application – module-wide singleton):

Example 2 (singleton class imported in the main application – application-wide singleton):

This is something I recently discovered during some tests and it’s something to consider when using the singleton design pattern inside Flex modules. First of all, here is an example implementation of the singleton pattern in Flex:

public class SingletonClass
{
	protected static var _instance: SingletonClass = null;

	public static function getInstance(): SingletonClass
	{
		if (_instance == null)
		{
			_instance = new SingletonClass();
		}

		return _instance;
	}
}

This class can be simply used to get the singleton instance with a line like this:

var theInstance: SingletonClass = SingletonClass.getInstance();

This is what we already knew. But what could happen if we try to get a singleton instance inside a Flex module? It could happen that our SingletonClass represents in fact a singleton in two different ways: application-wide singleton or module-wide singleton. In the application-wide case, the instance of SingletonClass is unique across the entire application that uses some Flex modules, while in the module-wide case, the instance in unique only inside a single module, but different across different modules. This is really important to know because we may have undesired behaviors of our application and it could be difficult to figure out what happens without knowing this.

Now, the question is: how do we know when we have an application-wide singleton instead of a module-wide singleton? You may have guessed the answer from the examples links at the beginning of this post. We have an application-wide when the SingletonClass is imported in the main application while we have a module-wide singleton when the SingletonClass is used only inside the modules and never imported in the main application. An example will be useful to clarify everything. Read the rest of this entry »