devahead BLOG

Saving the Android WebView cache on the SD card

Andrea Bresolin — Thu, 26 Jan 2012 23:27:11 +0000

It could be useful to save the cache of an Android WebView on the SD card (or integrated external memory) especially for devices with a limited amount of internal memory, but how can you do that? Well, it’s simple. You know that some Android browsers already do it and here I’m going to tell you a way to do it in your own app as well. This solution is made to work with Android 2.1 and higher, so I’m not going to use the API that was introduced only in a later version of the OS.

The key is the getCacheDir method of the ContextWrapper class. This is what is used by the cache manager to decide where to store the cache files. The behavior is slightly different for Android 2.1 and Android 2.2 and higher, so we’ll also keep this in mind.

I’ll explain everything going through the source code of the example application that you can download through the link on top of this post. Let’s start with the mainfest file:

Here we have the permissions to write to the SD (the external storage) and access the web. We also have a custom Application class extension called ApplicationExt and a couple of activities, MainActivity and SecondActivity.

The ApplicationExt class is where most of the things are done to have the cache on the SD:

package com.devahead.androidwebviewcacheonsd;

import java.io.File;

import android.app.Application;
import android.os.Environment;

public class ApplicationExt extends Application
{
	// NOTE: the content of this path will be deleted
	//       when the application is uninstalled (Android 2.2 and higher)
	protected File extStorageAppBasePath;

	protected File extStorageAppCachePath;

	@Override
	public void onCreate()
	{
		super.onCreate();

		// Check if the external storage is writeable
		if (Environment.MEDIA_MOUNTED.equals(Environment.getExternalStorageState()))
		{
			// Retrieve the base path for the application in the external storage
			File externalStorageDir = Environment.getExternalStorageDirectory();

			if (externalStorageDir != null)
			{
				// {SD_PATH}/Android/data/com.devahead.androidwebviewcacheonsd
				extStorageAppBasePath = new File(externalStorageDir.getAbsolutePath() +
					File.separator + "Android" + File.separator + "data" +
					File.separator + getPackageName());
			}

			if (extStorageAppBasePath != null)
			{
				// {SD_PATH}/Android/data/com.devahead.androidwebviewcacheonsd/cache
				extStorageAppCachePath = new File(extStorageAppBasePath.getAbsolutePath() +
					File.separator + "cache");

				boolean isCachePathAvailable = true;

				if (!extStorageAppCachePath.exists())
				{
					// Create the cache path on the external storage
					isCachePathAvailable = extStorageAppCachePath.mkdirs();
				}

				if (!isCachePathAvailable)
				{
					// Unable to create the cache path
					extStorageAppCachePath = null;
				}
			}
		}
	}

	@Override
	public File getCacheDir()
	{
		// NOTE: this method is used in Android 2.2 and higher

		if (extStorageAppCachePath != null)
		{
			// Use the external storage for the cache
			return extStorageAppCachePath;
		}
		else
		{
			// /data/data/com.devahead.androidwebviewcacheonsd/cache
			return super.getCacheDir();
		}
	}
}

In the onCreate method we start by checking if the external storage is actually mounted and we can write on it, then we build the base path of the app on the external storage. This path is {SD_PATH}/Android/data/com.devahead.androidwebviewcacheonsd because com.devahead.androidwebviewcacheonsd is the package declared in the manifest file and using this path structure makes sure that the entire path and all its content will be automatically deleted by Android 2.2 and higher in case the app is uninstalled avoiding to have garbage files on the SD. Note that this works only in Android 2.2 and higher, while in Android 2.1 the path will not be deleted by the OS so you’ll have to deal with it on your own. The full path for the cache files will be {SD_PATH}/Android/data/com.devahead.androidwebviewcacheonsd/cache, so the base path plus the cache directory. We must also make sure that the path is actually available before using it, so we create all the directories with the mkdirs method in case they don’t already exist.

Now that we have the cache path on the SD, we’re ready to use it and all we have to do is override the getCacheDir method inside our ApplicationExt class. This method is invoked by the cache manager when the application is started so basically we’re saying that the cache will be stored on the SD if it’s available and writeable, while we use the default path in case we’re allowed to use only the internal memory. Android stores all the cache data for our app in the /data/data/com.devahead.androidwebviewcacheonsd/cache directory by default on the internal memory.

We’re done with the implementation for Android 2.2 and higher, but what about Android 2.1? For that version of the OS the cache manager doesn’t use the getCacheDir method of the Application context, but it uses the one of the Activity context instead. So to make our solution work also with Android 2.1, we must override the getCacheDir method inside our activities.

To immediately understand how it works with Android 2.1, let’s take a look at the activities of the example application. We start with the MainActivity:

There’s simply a button to start the SecondActivity and a WebView to test our solution. The code for MainActivity looks like this:

package com.devahead.androidwebviewcacheonsd;

import java.io.File;

import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.webkit.WebView;
import android.webkit.WebViewClient;
import android.widget.Button;

public class MainActivity extends Activity implements OnClickListener
{
	protected WebView webView;
	protected Button startSecondActivityBtn;

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

		webView = ((WebView)findViewById(R.id.webView));
		startSecondActivityBtn = ((Button)findViewById(R.id.startSecondActivityBtn));

		// Set the listener
		startSecondActivityBtn.setOnClickListener(this);

		// Initialize the WebView
		webView.getSettings().setSupportZoom(true);
		webView.getSettings().setBuiltInZoomControls(true);
		webView.setScrollBarStyle(WebView.SCROLLBARS_OUTSIDE_OVERLAY);
		webView.setScrollbarFadingEnabled(true);
		webView.getSettings().setLoadsImagesAutomatically(true);

		// Load the URLs inside the WebView, not in the external web browser
		webView.setWebViewClient(new WebViewClient());

		webView.loadUrl("http://www.google.com");
	}

	@Override
	protected void onDestroy()
	{
		// Clear the cache (this clears the WebViews cache for the entire application)
		webView.clearCache(true);

		super.onDestroy();
	}

	@Override
	public File getCacheDir()
	{
		// NOTE: this method is used in Android 2.1

		return getApplicationContext().getCacheDir();
	}

	@Override
	public void onClick(View v)
	{
		if (v == startSecondActivityBtn)
		{
			Intent intent = new Intent(this, SecondActivity.class);
			startActivity(intent);
		}
	}
}

As you can see, the getCacheDir method inside the activity simply calls the same method in the Application context, that means that the ApplicationExt method is called. We’ll have to do this for every activity in the app to make sure the cache path is redirected correctly in Android 2.1, but actually in my tests I found that it looks like the cache manager calls the getCacheDir method inside the first activity that initializes a WebView (if MainActivity doesn’t use a WebView, but only SecondActivity does, then the getCacheDir method of SecondActivity will be called by the cache manager and not the one of MainActivity), anyway I think it’s a good idea to make sure the cache directory is consistent across all the activities of the application.

In MainActivity there’s a button that starts SecondActivity. This is just another activity with a WebView that I used to test the calls to the getCacheDir method in Android 2.1 and see what happens if there’s a WebView also in MainActivity or not. This is the layout of SecondActivity:

And this is its source code:

package com.devahead.androidwebviewcacheonsd;

import java.io.File;

import android.app.Activity;
import android.os.Bundle;
import android.webkit.WebView;
import android.webkit.WebViewClient;

public class SecondActivity extends Activity
{
	protected WebView webView;

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

		webView = ((WebView)findViewById(R.id.webView));

		// Initialize the WebView
		webView.getSettings().setSupportZoom(true);
		webView.getSettings().setBuiltInZoomControls(true);
		webView.setScrollBarStyle(WebView.SCROLLBARS_OUTSIDE_OVERLAY);
		webView.setScrollbarFadingEnabled(true);
		webView.getSettings().setLoadsImagesAutomatically(true);

		// Load the URLs inside the WebView, not in the external web browser
		webView.setWebViewClient(new WebViewClient());

		webView.loadUrl("http://www.google.com");
	}

	@Override
	public File getCacheDir()
	{
		// NOTE: this method is used in Android 2.1

		return getApplicationContext().getCacheDir();
	}
}

It looks similar to the one of MainActivity and we override the getCacheDir method here as well. The main difference is that in MainActivity the cache of the WebViews is cleared inside the onDestroy method. Remember that whenever you call the clearCache method you’re actually clearing the cache for all the WebViews of your application, not only the one that you used to invoke the method, so you must implement your own logic to clear the cache depending on the structure of your app.

This is all you have to do to write the cache of an Android WebView to the external memory. Remember that you’ll probably have to manage also the case when the external storage is unmounted during your app extecution by detecting the event and maybe giving a warning to the user. I hope you found this post useful and in case you’ve got more suggestions about this topic, feel free to write a comment.

Preserving the state of an Android WebView on screen orientation change

Andrea Bresolin — Sun, 22 Jan 2012 14:58:41 +0000

Source code

If you’ve tried to use a WebView inside your app, you know that the standard behavior on screen orientation change is not satisfactory in most cases because the full state of the WebView is not preserved. Here I’m going to show you a possible implementation to keep the full state of the WebView every time you rotate the screen. This is the same implementation I used in my own app (FWebLauncher) for the internal web browser.

Standard implementation (the state is not completely preserved)

Let’s start by taking a look at what a standard implementation would look like. This is how you would usually implement the state saving for a WebView according to the Android documentation:

public class StandardImplActivity extends Activity
{
	protected WebView webView;

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

		// Retrieve UI elements
		webView = ((WebView)findViewById(R.id.webView));

		// Initialize the WebView
		webView.getSettings().setSupportZoom(true);
		webView.getSettings().setBuiltInZoomControls(true);
		webView.setScrollBarStyle(WebView.SCROLLBARS_OUTSIDE_OVERLAY);
		webView.setScrollbarFadingEnabled(true);
		webView.getSettings().setLoadsImagesAutomatically(true);

		// Load the URLs inside the WebView, not in the external web browser
		webView.setWebViewClient(new WebViewClient());

		if (savedInstanceState == null)
		{
			// Load a page
			webView.loadUrl("http://www.google.com");
		}
	}

	@Override
	protected void onSaveInstanceState(Bundle outState)
	{
		super.onSaveInstanceState(outState);

		// Save the state of the WebView
		webView.saveState(outState);
	}

	@Override
	protected void onRestoreInstanceState(Bundle savedInstanceState)
	{
		super.onRestoreInstanceState(savedInstanceState);

		// Restore the state of the WebView
		webView.restoreState(savedInstanceState);
	}
}

So we call the saveState and the restoreState methods in the onSaveInstanceState and the onRestoreInstanceState methods of the Activity.

The WebView is declared directly in the layout file for the activity:

The main problem with this implementation is that, whenever you rotate the screen, the WebView is created again because the activity is destroyed and its saveState method doesn’t save the full state, but only a part of it like the URL of the page that was loaded and the browsing history. So it happens that for example the zoom and the scroll position are not preserved after the screen orientation change and sometimes the page is reloaded from the web.

State preserving implementation (a possible solution)

I tried many different solutions to preserve the full state of the WebView on screen rotation and the following one proved to be a reliable one that solves our problem. The main point is that the activity must not be destroyed and we must handle the screen orientation change by ourselves. Let’s start by taking a look at the layout file:

You immediately notice the difference with the standard implementation. Here we don’t declare the WebView inside the layout file, but we declare a placeholder instead. It is the position where our WebView will be placed inside the activity.

Also the code inside the activity will be different of course and here it is:

public class StatePreservingImplActivity extends Activity
{
	protected FrameLayout webViewPlaceholder;
	protected WebView webView;

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

		// Initialize the UI
		initUI();
	}

	protected void initUI()
	{
		// Retrieve UI elements
		webViewPlaceholder = ((FrameLayout)findViewById(R.id.webViewPlaceholder));

		// Initialize the WebView if necessary
		if (webView == null)
		{
			// Create the webview
			webView = new WebView(this);
			webView.setLayoutParams(new ViewGroup.LayoutParams(LayoutParams.FILL_PARENT, LayoutParams.FILL_PARENT));
			webView.getSettings().setSupportZoom(true);
			webView.getSettings().setBuiltInZoomControls(true);
			webView.setScrollBarStyle(WebView.SCROLLBARS_OUTSIDE_OVERLAY);
			webView.setScrollbarFadingEnabled(true);
			webView.getSettings().setLoadsImagesAutomatically(true);

			// Load the URLs inside the WebView, not in the external web browser
			webView.setWebViewClient(new WebViewClient());

			// Load a page
			webView.loadUrl("http://www.google.com");
		}

		// Attach the WebView to its placeholder
		webViewPlaceholder.addView(webView);
	}

	@Override
	public void onConfigurationChanged(Configuration newConfig)
	{
		if (webView != null)
		{
			// Remove the WebView from the old placeholder
			webViewPlaceholder.removeView(webView);
		}

		super.onConfigurationChanged(newConfig);

		// Load the layout resource for the new configuration
		setContentView(R.layout.state_preserving_impl);

		// Reinitialize the UI
		initUI();
	}

	@Override
	protected void onSaveInstanceState(Bundle outState)
	{
		super.onSaveInstanceState(outState);

		// Save the state of the WebView
		webView.saveState(outState);
	}

	@Override
	protected void onRestoreInstanceState(Bundle savedInstanceState)
	{
		super.onRestoreInstanceState(savedInstanceState);

		// Restore the state of the WebView
		webView.restoreState(savedInstanceState);
	}
}

We need to change also the AndroidManifest.xml file to intercept the configuration changes inside the activity:

In the android:configChanges attribute we are telling the system that we don’t want the activity to be restarted when the declared configuration changes happen, but we want to handle the configuration changes by ourselves through the onConfigurationChanged method that will be called every time there is a change.

When the activity is created we initialize its content with the current layout and we initialize the user interface with the initUI method. That’s where the WebView is created, stored in the webView class field and then attached to the webViewPlaceholder element filling its space completely. Every time the screen is rotated, the onConfigurationChanged method is called so we remove the WebView from its current placeholder first, then we load the new activity layout (we can define a different layout for the portrait and the landscape configuration) and reinitialize the UI. After a configuration change, the activity instance is still the same because it has not been destroyed. The initUI method retrieves the new placeholder instance while the WebView instance is still the same because the webView class field is not changed, so the WebView is not created again and all we have to do is attach the old WebView to the new webViewPlaceholder instance.

This implementation is very useful in case you defined a different layout depending on the screen orientation. For example, you could have a my_activity_layout.xml file in the res/layout folder of your Android project for the portrait orientation and another my_activity_layout.xml file in the res/layout-land folder with a different content for the landscape orientation. When onConfigurationChanged is called, the system already has the appropriate resources for the new configuration and when you call the setContentView method passing it a layout resource id, the system uses the correct layout file for the current screen orientation, you just have to make sure that the ids of the UI elements are the same in both files and that the webViewPlaceholder element is present in both the layout configurations. This is what I have also in the internal web browser of my FWebLauncher app and that allows me to have a different position and layout of the buttons bar depending on the screen orientation while keeping the same WebView instance.

I’m sure you noticed that the onSaveInstanceState and onRestoreInstanceState methods are still there, but why since the activity is not destroyed anymore? Well, they are there in case the activity is destroyed for a reason that is not a configuration change (e.g. the system needs to destroy the activity because it is not in foreground and there’s a need to free some memory). In that case we can still restore the original state of the WebView, just without preserving the complete state because we’re going to lose the zoom and the scroll position for example, anyway it’s still better than totally losing the WebView state.

If you want to read more about the configuration change handling in Android, you can check the specific page of the Android documentation. You can also download an example application through the link on top of this post to take a look at the source code that shows what I described in the post.

Recycling objects in Android with an Object Pool to avoid garbage collection

Andrea Bresolin — Sun, 18 Dec 2011 17:28:14 +0000

Source code (LICENSE)

If you need to reduce the work of the garbage collector in Android, like in games development for example, all you can do is reduce the amount of objects you create and recycle those you’ve already created. One of the ways to do this is the implementation of the Object Pool design pattern.

An Object Pool could be implemented in many different ways depending on the needed features. What I’m going to show here is an implementation that respects the following requirements:

during its execution, the Object Pool doesn’t allocate new objects other than those contained in the pool itself (we prefer plain arrays instead of Java collections);
the Object Pool must be efficient in terms of execution speed;
the Object Pool is responsible for initializing and finalizing the objects it contains (the objects must be ready to use when retrieved from the pool and they must free any unneeded resource when they are put back in the pool);
if there’s no more room for new objects in the pool, then new objects must be created anyway if requested, but they’ll not be stored in the pool when freed;
the Object Pool must be able to handle every type of Object (we only ask the objects to implement an interface to make them ready for the pool);
sharing the pool between multiple threads doesn’t have to be a problem.

And now, straight to the source code. We start with the definition of the PoolObject interface:

/**
 * Interface that has to be implemented by an object that can be
 * stored in an object pool through the ObjectPool class.
 */
public interface PoolObject
{
	/**
	 * Initialization method. Called when an object is retrieved
	 * from the object pool or has just been created.
	 */
	public void initializePoolObject();

	/**
	 * Finalization method. Called when an object is stored in
	 * the object pool to mark it as free.
	 */
	public void finalizePoolObject();
}

This is the interface that an object must implement to let the pool perform two operations: the initialization and the finalization. We use an interface so we can easily extend every other class and make the pool able to handle different objects.

The Object Pool creates the needed objects through a factory class that implements the PoolObjectFactory interface:

/**
 * Interface that has to be implemented by every class that allows
 * the creation of objectes for an object pool through the
 * ObjectPool class.
 */
public interface PoolObjectFactory
{
	/**
	 * Creates a new object for the object pool.
	 *
	 * @return new object instance for the object pool
	 */
	public PoolObject createPoolObject();
}

The factory class must decide how to create a new PoolObject instance whenever the pool needs it.

All we need to see now is the ObjectPool class, so let’s take a look at it:

/**
 * Object pool implementation.
 */
public class ObjectPool
{
	protected final int MAX_FREE_OBJECT_INDEX;

	protected PoolObjectFactory factory;
	protected PoolObject[] freeObjects;
	protected int freeObjectIndex = -1;

	/**
	 * Constructor.
	 *
	 * @param factory the object pool factory instance
	 * @param maxSize the maximun number of instances stored in the pool
	 */
	public ObjectPool(PoolObjectFactory factory, int maxSize)
	{
		this.factory = factory;
		this.freeObjects = new PoolObject[maxSize];
		MAX_FREE_OBJECT_INDEX = maxSize - 1;
	}

	/**
	 * Creates a new object or returns a free object from the pool.
	 *
	 * @return a PoolObject instance already initialized
	 */
	public synchronized PoolObject newObject()
	{
		PoolObject obj = null;

		if (freeObjectIndex == -1)
		{
			// There are no free objects so I just
			// create a new object that is not in the pool.
			obj = factory.createPoolObject();
		}
		else
		{
			// Get an object from the pool
			obj = freeObjects[freeObjectIndex];

			freeObjectIndex--;
		}

		// Initialize the object
		obj.initializePoolObject();

		return obj;
	}

	/**
	 * Stores an object instance in the pool to make it available for a subsequent
	 * call to newObject() (the object is considered free).
	 *
	 * @param obj the object to store in the pool and that will be finalized
	 */
	public synchronized void freeObject(PoolObject obj)
	{
		if (obj != null)
		{
			// Finalize the object
			obj.finalizePoolObject();

			// I can put an object in the pool only if there is still room for it
			if (freeObjectIndex < MAX_FREE_OBJECT_INDEX)
			{
				freeObjectIndex++;

				// Put the object in the pool
				freeObjects[freeObjectIndex] = obj;
			}
		}
	}
}

The structure of this class is very simple. There are only three methods, the constructor and two other methods to create and free the object instances.

The constructor accepts two parameters, the factory instance and the maximum number of objects that can be stored in the pool.

The newObject method retrieves an object from the pool and returns it to the caller after initializing it. If there are free objects in the pool, then one of those is returned, otherwise a new one is created through the factory. In this way we put a limit on the maximum number of instances in the pool, but only the needed amount is actually created.

The freeObject method puts an object instance back in the pool making it available for subsequent calls to newObject. Before storing the object in the free objects array, its finalization method is called to let it free any unneeded resource if necessary. If there’s no room in the pool for the object, then only its finalization method is called.

Both the newObject and the freeObject methods are synchronized so the interaction between the pool and different threads is managed correctly.

We have all we need, so let’s take a look at an example to see how our new tool can be used and what is its benefit. Let’s say that we need to work with Point instances for a graphic application. We need to have many points, but we want to avoid to keep on creating them and try to reuse the instances if possible. We need to define a PoolObject first:

import android.graphics.Point;

import com.devahead.util.objectpool.PoolObject;

public class PointPoolObject extends Point implements PoolObject
{
	@Override
	public void initializePoolObject()
	{
		x = 0;
		y = 0;
	}

	@Override
	public void finalizePoolObject()
	{
		// No finalization needed
	}
}

Our PointPoolObject extends the Point class, so it’s a point in fact, but also implements the PoolObject interface. Whenever a point needs to be initialized, it must make sure that its x and y coordinates are both set to zero. There’s no need for a finalization since there are no resources to free.

A PointPoolObject instance is created through the PointPoolObjectFactory class:

import com.devahead.util.objectpool.PoolObject;
import com.devahead.util.objectpool.PoolObjectFactory;

public class PointPoolObjectFactory implements PoolObjectFactory
{
	@Override
	public PoolObject createPoolObject()
	{
		return new PointPoolObject();
	}
}

This simple factory doesn’t need to do anything particular, but just create a new instance of the PointPoolObject class. If additional steps are needed to create a new instance, you can perform them here in the createPoolObject method.

The following code is our example application to test the Object Pool:

import android.app.Activity;
import android.graphics.Point;
import android.os.Bundle;
import android.os.Debug;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.TextView;

import com.devahead.androidobjectpool.poolobjects.PointPoolObject;
import com.devahead.androidobjectpool.poolobjects.PointPoolObjectFactory;
import com.devahead.util.objectpool.ObjectPool;

public class MainActivity extends Activity implements OnClickListener
{
	private Button testNoPoolBtn;
	private TextView testNoPoolText;
	private Button testHalfPoolBtn;
	private TextView testHalfPoolText;
	private Button testFullPoolBtn;
	private TextView testFullPoolText;
	private Button testExceedPoolBtn;
	private TextView testExceedPoolText;

	private ObjectPool pointObjectPool1;
	private ObjectPool pointObjectPool2;
	private ObjectPool pointObjectPool3;

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

		testNoPoolBtn = (Button)findViewById(R.id.testNoPoolBtn);
		testNoPoolText = (TextView)findViewById(R.id.testNoPoolText);
		testHalfPoolBtn = (Button)findViewById(R.id.testHalfPoolBtn);
		testHalfPoolText = (TextView)findViewById(R.id.testHalfPoolText);
		testFullPoolBtn = (Button)findViewById(R.id.testFullPoolBtn);
		testFullPoolText = (TextView)findViewById(R.id.testFullPoolText);
		testExceedPoolBtn = (Button)findViewById(R.id.testExceedPoolBtn);
		testExceedPoolText = (TextView)findViewById(R.id.testExceedPoolText);

		testNoPoolBtn.setOnClickListener(this);
		testHalfPoolBtn.setOnClickListener(this);
		testFullPoolBtn.setOnClickListener(this);
		testExceedPoolBtn.setOnClickListener(this);

		// Create object pools with a maximum of 100 PointPoolObject
		pointObjectPool1 = new ObjectPool(new PointPoolObjectFactory(), 100);
		pointObjectPool2 = new ObjectPool(new PointPoolObjectFactory(), 100);
		pointObjectPool3 = new ObjectPool(new PointPoolObjectFactory(), 100);
	}

	@Override
	public void onClick(View v)
	{
		if (v == testNoPoolBtn)
		{
			testNoPool(100, testNoPoolText);
		}
		else if (v == testHalfPoolBtn)
		{
			testPool(pointObjectPool1, 50, testHalfPoolText);
		}
		else if (v == testFullPoolBtn)
		{
			testPool(pointObjectPool2, 100, testFullPoolText);
		}
		else if (v == testExceedPoolBtn)
		{
			testPool(pointObjectPool3, 120, testExceedPoolText);
		}
	}

	private void testNoPool(final int POINTS_COUNT, TextView textView)
	{
		Point point;

		Point[] points = new Point[POINTS_COUNT];

		Debug.startAllocCounting();

		for (int i = 0; i < POINTS_COUNT; i++)
		{
			point = new Point();

			points[i] = point;
		}

		for (int i = 0; i < POINTS_COUNT; i++)
		{
			point = new Point();

			points[i] = point;
		}

		Debug.stopAllocCounting();

		int ac = Debug.getThreadAllocCount();

		textView.setText(ac + " ac");
	}

	private void testPool(ObjectPool objectPool, final int POINTS_COUNT, TextView textView)
	{
		PointPoolObject point;

		PointPoolObject[] points = new PointPoolObject[POINTS_COUNT];

		Debug.startAllocCounting();

		for (int i = 0; i < POINTS_COUNT; i++)
		{
			point = (PointPoolObject)objectPool.newObject();

			points[i] = point;
		}

		for (int i = 0; i < POINTS_COUNT; i++)
		{
			point = points[i];

			objectPool.freeObject(point);
		}

		for (int i = 0; i < POINTS_COUNT; i++)
		{
			point = (PointPoolObject)objectPool.newObject();

			points[i] = point;
		}

		Debug.stopAllocCounting();

		int ac = Debug.getThreadAllocCount();

		textView.setText(ac + " ac");
	}
}

As you can see, there are four buttons. We test how many instances are created in different situations, but the problem to solve is always the same: we need a certain amount of Point instances that have to be ready to use at the same time and we need to do this twice. We want to see what happens with or without the Object Pool and what happens with the pool if the total amount of needed instances at the same time is 50, 100 or 120 while having set the maximum size of the pool to be 100.

In the image above you can see the test results. What does this mean?

no Object Pool: 200 instances are created because we need 100 instances for two times and we cannot reuse them;
Object Pool and 50 instances needed: only 50 instances are created because the second time we need them we can just reuse those that have previously been created and are still in the pool (the pool maximum limit is never reached);
Object Pool and 100 instances needed: 100 instances are created filling the pool and the second time we need them we can use those inside the pool previously marked as free;
Object Pool and 120 instances needed: in this case 140 instances are created because the pool maximum limit is 100 and the other 20 instances are created anyway by ObjectPool, but there’s no room in the pool to store them when they’re not needed anymore; since we need the 120 instances twice, the second time 20 more instances are created so a total amount of 40 instances is created outside of the pool.

We tested that the Object Pool lets us recycle object instances and creates only the objects that are needed at the same time avoiding to create more useless instances. If you keep on calling the same methods you can understand that without an Object Pool the total amount of instances that the garbage collector needs to collect is potentially endless and this means a lot of CPU time wasted in collecting instances, while the Object Pool keeps the objects creation under control and the garbage collector may not need to be executed at all.

This is just a way to implement the Object Pool design pattern and it’s made to be simple and avoid the creation of any object other than those stored inside the pool while it is used. If you need different features you can modify the proposed architecture to suit your needs.

If you want to take a look at another performance test of this Object Pool implementation and many other tests on the Android platform, you can check my other post titled “Coding for performance and avoiding garbage collection in Android“.

Coding for performance and avoiding garbage collection in Android

Andrea Bresolin — Sun, 11 Dec 2011 22:49:20 +0000

Source code (LICENSE)

Post updates:

[December 18th, 2011] added TEST 10: OBJECT POOL

You know how much important it is to always keep in mind the performance of your application when developing for mobile devices with limited resources. This is important especially for game developers that need to reach two goals:

write high performance code
avoid having the garbage collector work too much because it might have a negative impact on the user experience (you don’t want the users to see small pauses while playing a game)

In this post I’m going to show some tests I made for the Android platform. You can repeat the same tests on your own downloading the test app source code through the link on top of this post.

Here is my test environment:

Samsung Galaxy S II
Android 2.3.3 (Gingerbread)
Airplane mode on (to avoid network connections that could affect the test results)

NOTES:

these tests are not meant to be a 100% exact measure of performance differences between different solutions, they are made to show and verify what could be the best implementation choice depending on the context and they give only a rough measure of the difference in performance (specific to the test cases); the final conclusion is still true for similar implementation cases so a faster implementation is always faster, maybe not as much faster as shown in a test case, but still faster;
these tests are made for the Android platform, so a common good practice for a Java virtual machine might not be valid for the Dalvik virtual machine.

The structure of this post is simple. A series of tests will be described giving information about what is the best choice for a software developer and why. Are you ready? Let’s go!

TEST 1: FOR LOOP OVER ARRAY

When writing a for loop over arrays, the common way of implementing it is use the length property of the array in the termination condition. But instead of asking the array its length on every single iteration of the loop, we could just read it before entering the loop and cache it in a local variable.

What we test: is there a difference between using a local variable to cache the length of an array instead of using the length property in a termination condition of a for loop?

Standard implementation

// arr is an int[] array

for (int i = 0; i < arr.length; i++)
{
	// Do something
}

Optimized implementation

// arr is an int[] array

int arrLength = arr.length;

for (int i = 0; i < arrLength; i++)
{
	// Do something
}

Test results

The results show the average time taken to loop over an array with length = 3000000. The loop is repeated 100 times to check the average time taken for each complete loop.

	Average loop time	Result
Standard	58 ms
Optimized	43 ms	26% faster than standard

Conclusion

Caching the array length in a local variable is faster than reading the value for every single loop iteration. If you know that the length of an array will never change during the loop execution, then caching its value is a good idea to improve the execution speed.

TEST 2: FOR LOOP OVER ARRAYLIST

Like TEST 1, when writing a for loop over ArrayList, the common way of implementing it is use the size method of the ArrayList in the termination condition. But instead of asking the ArrayList its size on every single iteration of the loop, we could just read it before entering the loop and cache it in a local variable.

What we test: is there a difference between using a local variable to cache the size of an ArrayList instead of using the size method in a termination condition of a for loop?

Standard implementation

// arr is an ArrayList

for (int i = 0; i < arr.size(); i++)
{
	// Do something
}

Optimized implementation

// arr is an ArrayList

int arrLength = arr.size();

for (int i = 0; i < arrLength; i++)
{
	// Do something
}

Test results

The results show the average time taken to loop over an ArrayList with size = 3000000. The loop is repeated 100 times to check the average time taken for each complete loop.

	Average loop time	Result
Standard	262 ms
Optimized	233 ms	11% faster than standard

Conclusion

Caching the ArrayList size in a local variable is faster than reading the value for every single loop iteration. If you know that the size of an ArrayList will never change during the loop execution, then caching its value is a good idea to improve the execution speed. An ArrayList is generally slower than a simple array because of the method invocations involved in reading and writing values from and to the collection. Different collections have different performances (think about the access time to the elements of a HashMap), so different tests are necessary to test them.

TEST 3: VARIABLE FIELD ACCESS

If you add a variable field to a class, you can choose to make it public so other classes can read and write its value directly, or you can choose to implement getter and setter accessor methods and make the field private or protected.

What we test: is there a difference between accessing a variable field through getter and setter methods instead of accessing it directly?

Getter and setter methods

private long var;

public long getVar()
{
	return var;
}

public void setVar(long value)
{
	var = value;
}

Direct access

public long var;

Test results

The results show the average time taken to read and write the value of var in a loop executed 3000000 times. The loop is repeated 100 times to check the average time taken for each complete loop.

	Average loop time	Result
Getter and setter	96 ms
Direct access	60 ms	37% faster than getter and setter

Conclusion

Accessing directly a field of a class instance is always faster than getting and setting its value through accessor methods. If the performance is very important and you don’t need to perform any check while reading or writing the value of the field, then making it public and accessing it directly highly increases the speed (methods invocations are slow).

TEST 4: VARIABLE VS CONSTANT

A value can be stored in a variable field or in a constant field. If a value is expected to never change, storing it in a constant field is not only a good practice, but it also improves the speed of the implementation. Here we are going to verify this and we are going to test whether the use of a static field makes a difference in terms of performance.

What we test: is there a difference between reading a value of a variable field compared to the one of a constant field and does declaring it as static make a difference in terms of performance?

Variable field

public int var;

Static variable field

public static int var;

Constant field

public final int CONST;

Static constant field

public static final int CONST;

Test results

The results show the average time taken to read the value of var or CONST in a loop executed 5000000 times. The loop is repeated 500 times to check the average time taken for each complete loop.

	Average loop time	Result
Variable field	63 ms
Static variable field	67 ms	slightly slower than variable
Constant field	55 ms	faster than variable or static variable; no difference between constant and static constant
Static constant field	55 ms	faster than variable or static variable; no difference between constant and static constant

Conclusion

If you know that a value will never change, then you should declare it as constant through the final keyword. Using constants instead of variables is always faster because the compiler can replace their value in the compiled code to avoid the variable field lookup time. In this test we also see that a static variable is slightly slower than an instance variable probably due to the different lookup procedure used by the virtual machine at runtime.

TEST 5: METHOD INVOCATIONS

To have a better structure of a software implementation that helps reuse and maintainability, it’s good to create a modular architecture with multiple classes and methods that solve specific tasks instead of writing very long methods with repeated pieces of code that solve exactly the same problem. This leads anyway to more method invocations instead of having all the necessary code in a single method to complete the task. We want to see what’s the impact of multiple method invocations instead of a single invocation.

What we test: how is the performance affected by multiple method invocations instead of a single invocation to complete the same task?

Multiple method invocations

private void execMethod()
{
	execMethod1();
}

private void execMethod1()
{
	execMethod2();
}

private void execMethod2()
{
	execMethod3();
}

private void execMethod3()
{
	// Do something
}

Single method invocation

private void execMethod()
{
	// Do something
}

Test results

The results show the average time taken to execute execMethod inside a loop repeated 3000000 times. The test is repeated 100 times to check the average time taken for each complete loop.

	Average loop time	Result
Multiple method invocations	656 ms
Single method invocation	175 ms	73% faster than multiple method invocations

Conclusion

Multiple method invocations can really slow down the execution speed, so if you need to write high performance code, you should keep in mind that sometimes it’s more important to put all the necessary code in a single method instead of having the same code spread all over different methods or classes. The code structure will not be optimal, but the performance benefit is notable.

TEST 6: POLYMORPHIC METHODS

Like we already said in TEST 5, to have a better structure of a software implementation that helps reuse and maintainability, it’s good to create a modular architecture with multiple classes so we can have the ability to implement polymorphic methods that execute a task in a different way depending on the specific class implementation. This is obtained through class inheritance and methods overriding. In this test we want to see what’s the impact of methods overriding on performance.

What we test: how is the performance affected by methods overriding?

Classes inheritance and methods overriding

public class PolyClass1
{
	public void execMethod()
	{
		// Do something
	}
}

public class PolyClass2 extends PolyClass1
{
	@Override
	public void execMethod()
	{
		super.execMethod();
	}
}

public class PolyClass3 extends PolyClass2
{
	@Override
	public void execMethod()
	{
		super.execMethod();
	}
}

public class PolyClass4 extends PolyClass3
{
	@Override
	public void execMethod()
	{
		super.execMethod();
	}
}

PolyClass4 polyClass = new PolyClass4();
polyClass.execMethod();

Direct method invocation

public class PolyClass1
{
	public void execMethod()
	{
		// Do something
	}
}

PolyClass1 polyClass = new PolyClass1();
polyClass.execMethod();

Test results

The results show the average time taken to execute execMethod inside a loop repeated 3000000 times. The test is repeated 100 times to check the average time taken for each complete loop.

	Average loop time	Result
Classes inheritance and methods overriding	674 ms
Direct method invocation	195 ms	71% faster than methods overriding

Conclusion

Classes inheritance and polymorphism are good to improve the source code structure, but the cost is the reduced performance compared to direct methods invocations. This is basically the same thing we saw in TEST 5 so we didn’t expect something different because each method in a subclass calls the corresponding one in the superclass (a method invocation). Since overriding a method is done to create a different version (with a different behavior) of the same method in a specific class, if you absolutely need high performance you could implement different methods that do something in a different way and call them directly instead of creating inherited classes with overridden methods to have the same result (of course some code will be repeated in this case).

TEST 7: VIRTUAL VS STATIC METHODS

If you declare a method in Java, it is virtual by default. In case it doesn’t need to access other instance methods or fields, it should be declared as static not only as a good programming practice (you clearly say that the method will not modify anything in a class instance), but also to improve performance.

What we test: is there a difference between virtual and static methods in terms of performance?

Virtual method

public void virtualMethod()
{
	// Do something
}

Static method

public static void staticMethod()
{
	// Do something
}

Test results

The results show the average time taken to execute virtualMethod or staticMethod inside a loop repeated 3000000 times. The test is repeated 100 times to check the average time taken for each complete loop.

	Average loop time	Result
Virtual method	152 ms
Static method	137 ms	10% faster than virtual method

Conclusion

Static methods are faster than virtual methods and since there are no drawbacks in declaring a method as static if it doesn’t use fields or methods specific to a class instance, you should always do that when you can.

TEST 8: ITERATION OVER ARRAY

Starting with Java 1.5, there’s an easy syntax to implement an iteration over arrays or collections instead of hand-writing the usual for loop. This gives performance improvements compared to some hand-written versions of the iteration, while it is indistinguishable from others.

What we test: what’s the difference between using an iterator over an array instead of a hand-written loop in terms of performance and objects allocation?

Iterator

// arr is an Object[] array declared as a class field

for (Object obj : arr)
{
	// Do something
}

Manual iteration

// arr is an Object[] array declared as a class field

int arrLength = arr.length;

for (int i = 0; i < arrLength; i++)
{
	// Do something with arr
}

Manual iteration with local array

// arr is an Object[] array declared as a class field

// We declare a variable localArr that is local to the
// method that implements the iteration (we avoid
// accessing the arr class field inside the loop).
Object[] localArr = arr;

int arrLength = localArr.length;

for (int i = 0; i < arrLength; i++)
{
	// Do something with localArr
}

Test results

The results show the average time taken to loop over an array with length = 5000000. The test is repeated 500 times to check the average time taken for each complete loop. It is also shown the number of objects allocated in the different loop implementations.

	Average loop time	Result
Iterator	90 ms	the same as manual iteration with local array
Manual iteration	102 ms	13% slower than iterator or manual iteration with local array
Manual iteration with local array	90 ms	the same as iterator

Conclusion

To understand this, you should take a look at the “Designing for Performance” document in the Android developers guide (look at “Use Enhanced For Loop Syntax”). The Iterator case is translated by the compiler in a way identical to the Manual iteration with local array case, that’s why the performance is the same. With simple arrays there is no difference between a hand-written optimized loop and the iteration syntax, so you should always prefer the latter to improve the code readability. In every case there are no objects allocations so we have no problems with the garbage collector. In this test we also see a performance improvement if we store a reference to the array locally in the method that executes the loop instead of accessing directly the array as a class instance field. This is another thing to keep in mind to improve performance (the lookup time for the array variable is reduced).

TEST 9: ITERATION OVER ARRAYLIST

We want to try the same test we did in TEST 8, but with an ArrayList instead of a simple array. When using the iteration syntax introduced in Java 1.5 with collections (like ArrayList) instead of simple arrays, there’s a difference in the compiled code. In this case an Iterator object is used to implement the iteration so we must also consider the extra objects allocation compared to a hand-written loop without the iteration syntax.

What we test: what’s the difference between using an iterator over an ArrayList instead of a hand-written loop in terms of performance and objects allocation?

Iterator

// arr is an ArrayList collection declared as a class field

for (Object obj : arr)
{
	// Do something
}

Manual iteration

// arr is an ArrayList collection declared as a class field

int arrLength = arr.size();

for (int i = 0; i < arrLength; i++)
{
	// Do something with arr
}

Manual iteration with local ArrayList

// arr is an ArrayList collection declared as a class field

// We declare a variable localArr that is local to the
// method that implements the iteration (we avoid
// accessing the arr class field inside the loop).
ArrayList localArr = arr;

int arrLength = localArr.size();

for (int i = 0; i < arrLength; i++)
{
	// Do something with localArr
}

Test results

The results show the average time taken to loop over an ArrayList with size = 3000000. The test is repeated 100 times to check the average time taken for each complete loop. It is also shown the number of objects allocated in the different loop implementations.

	Average loop time	Objects allocation count	Result
Iterator	481 ms	100	slower than both manual iterations and 100 objects allocated (an Iterator instance for each test repetition)
Manual iteration	246 ms	0	49% faster than iterator and 5% slower than manual iteration with local ArrayList
Manual iteration with local ArrayList	235 ms	0	51% faster than iterator and 5% faster than manual iteration

Conclusion

You might be surprised to see that the Iterator performance is much slower than a hand-written iteration loop, but the reason is simple: to implement the Iterator syntax, the compiler uses an Iterator object, so the loop is made invoking its hasNext and next methods and you know from our previous tests that method invocations are slow. A hand-written loop just uses a standard for syntax to implement the loop and doesn’t need to invoke any method resulting in a much faster execution. There’s another problem with the Iterator syntax: a new Iterator object is allocated for each complete loop execution and this means more objects to collect for the garbage collector. This can lead to a poor performance in games for example, because there could be many small pauses every time the garbage collector executes while the user is playing, making the overall experience not really great. You should choose the Iterator syntax only for applications that don’t need high performance code or continuous rendering (like games) because it helps to keep the source code cleaner and easier to read, but you should always prefer hand-written iterations when developing games or other similar applications. This test has been made with an ArrayList collection and might give different results with other collections, but it shows that even though the Iterator syntax is the same as the one for a standard array (like we saw in TEST 8), the compiled code is much different and we must consider the drawbacks of this syntax while dealing with collections.

TEST 10: OBJECT POOL

In order to reduce the work of the garbage collector, all you can do is reduce the amount of objects you create and recycle the instances you’ve already created. You can do this with the implementation of the Object Pool design pattern. There are different ways to implement an Object Pool, depending on the features you need, and a possible implementation is the one you can find in my other post titled “Recycling objects in Android with an Object Pool to avoid garbage collection“. That will be the implementation used in this test.

What we test: what’s the impact of an Object Pool in terms of performance and objects allocation compared to the standard object creation without recycling the instances?

Standard object creation

// Example of a standard object creation of an android.graphics.Point instance

Point point = new Point(x, y);

Object Pool

// Example of a creation of an android.graphics.Point instance through an Object Pool

// Object Pool initialization with a maximum capacity or NEEDED_POINTS_COUNT instances.
// The PointPoolObjectFactory is a factory class that creates PointPoolObject
// instances.
ObjectPool pointsPool = new ObjectPool(new PointPoolObjectFactory(), NEEDED_POINTS_COUNT);

// The PointPoolObject class extends android.graphics.Point and implements the
// interface needed to make it work with the Object Pool.
PointPoolObject point = (PointPoolObject)pointsPool.newObject();
point.x = x;
point.y = y;

// When the point instance is not needed anymore, we put it back in the Object Pool
pointsPool.freeObject(point);

Test results

The results show the average time taken to create and initialize 1000 Point instances inside a loop repeated 100 times to simulate a situation where we need 1000 Point instances to be ready to use at the same time and we need all of them 100 times during our application execution (note: with the Object Pool we also need to free the instances and store them back in the pool, while without the pool that’s the job of the garbage collector). The test is repeated 100 times to check the average time taken for each complete loop. It is also shown the number of objects allocated in the different loop implementations.

	Average loop time	Objects allocation count	Result
Standard object creation	180 ms	10000000	slower than the Object Pool implementation and 10000000 objects allocated (the total time varies depending on the speed of the garbage collector execution)
Object Pool	47 ms	1000	faster than the standard object creation (the garbage collector doesn’t need to work) and only 1000 objects allocated

Conclusion

As you can see, the Object Pool allows us to allocate only the total amount of Point instances that are needed at the same time (1000) while with a standard object creation we would allocate the objects multiple times without reusing them (1000 points x 100 times x 100 repetitions of the test = 10000000 instances). Of course we could find a strategy to recycle the points even without the Object Pool, but the reason to have an Object Pool is to make this simple and standardized across the source code of our application. As you surely noticed, the test execution takes even less time with the Object Pool and the reason for this is the garbage collector: with the Object Pool and only 1000 instances created, the garbage collector doesn’t need to work at all, while with the standard object creation it needs to collect many instances and it executes a lot of times making everything slower (you can see this if you try to run the test and check in the LogCat view of the DDMS perspective of Eclipse).

That’s it. This is of course only a subset of what could be tested and more tests could be added, but it covers most of the common scenarios that you have to face every time you need to make a decision about the implementation of an application.

When implementing applications (like games) that need to avoid garbage collection because of the small pauses it introduces every time the garbage collector executes, all you can do is avoid to keep on creating objects and try to reuse as much as possible the objects instances you already have. This can be done in different ways (like through Object Pools as we saw in TEST 10) and depends a lot on the specific implementation and application context, but it’s important to know the cases where you don’t create objects directly and you don’t realize that they are created anyway (like we saw with the Iterator syntax in TEST 9). It can be hard to discover such a hidden source of objects creation when you’ve already completed your source code implementation, so it’s better to know it in advance before any implementation decision.

If you think that something is wrong with these tests or you would like me to implement new ones, feel free to write a comment to this post. Every feedback is appreciated.

Creating a custom Android button with a resizable skin

Andrea Bresolin — Tue, 02 Aug 2011 02:18:40 +0000

Source code

If you are developing your own Android application, maybe you would like to give it a custom skin with a defined set of colors for all the interface elements. Here I’m going to show how to customize Android buttons. This is the same kind of customization I made for my own app which is called FWebLauncher and you can download for free from the Android Market. In this post I’m going to quickly describe the steps that have to be performed to obtain our result, but I recommend you to download the whole example application with all the resource images through the link on top of this post.

First of all, you need to decide how your buttons will look in different states, so you’ve got to define the corresponding skin images for the Normal, Pressed, Focused and Disabled states. Of course, if you don’t need all the states, you can just define some of them. In the following image you can see how our buttons will look like:

We want the skin to be resizable, so the button can adapt its size depending on the content (i.e. the text) without making the skin look weird. To do this, we need to define a 9-patch for each image. There’s a tool installed with the Android SDK that you can find in ${ANDROID_SDK_INSTALL_DIRECTORY}\tools\draw9patch.bat. Execute that batch file and you’ll have the following application running:

As you can see I’ve already loaded the PNG file for the Normal state of our buttons and I’ve defined the 9-patch with the black lines that you can see on every side of the image. As written in the Android developer’s documentation, the top and left lines define the stretchable area used to resize the image, while the bottom and right lines define the area where the content must be placed. With the 9-patch tool, I created a new file for each image of the button skin, so for example, if the skin image for the Normal state of the button is called button_normal.png, then the corresponding 9-patch file will be button_normal.9.png and we need only this inside the resources folders of our application.

The next thing to do is creating a selector that tells Android how it should deal with the skin images depending on the button state. The selector is just an XML file that looks like this:

In the selector you define which skin image should be used to render each button state. So if the selector XML file is called button.xml, you can just write something like this to have your button skin working:

This is just a simple button with some text in it. In case you need a button with an image, like an icon, and you want it to resize proportionally, then you don’t need to define a 9-patch and you need to use something different like an ImageButton:

These are the possible states for iconBtn:

I set the scaleType attribute to make the image resize correctly and I set the background to #00000000 because I want to make it completely transparent (remember that the format for that attribute is ARGB where A is the alpha value). I don’t need the background because I already have an image for each state of the button with its own trasparency correctly set on the borders to have a custom shape for the button if I need it. The src attribute specifies the selector to use for this button:

What if you want a button with both an icon and the text? Well, you can do it with something like this:

The icon is specified in the drawableLeft attribute and you can set also a padding to use between the icon and the text through the drawablePadding attribute. In this case the button.xml selector makes it possible to change only the background image depending on the button state, but not the icon itself. To do that, you need to act programmatically in the source code.

To see the final result of what I explained, take a look at the example application downloadable from the top of this post:

For each kind of button, you can try to make it pressed, focused or disabled to see how it changes. The layout of the main activity is defined as follows:

In the MainActivity class we just define the listeners to make the buttons enabled or disabled depending on the checkboxes. Note that you need to set the value also for the clickable property of the ImageButton to make it actually enabled or disabled.

package com.devahead.customandroidbuttonwithresizableskin;

import android.app.Activity;
import android.os.Bundle;
import android.widget.Button;
import android.widget.CheckBox;
import android.widget.CompoundButton;
import android.widget.CompoundButton.OnCheckedChangeListener;
import android.widget.ImageButton;

public class MainActivity extends Activity implements OnCheckedChangeListener
{
	// Interface elements
	protected Button textBtn;
	protected CheckBox textBtnEnabledCheck;
	protected ImageButton iconBtn;
	protected CheckBox iconBtnEnabledCheck;
	protected Button textAndIconBtn;
	protected CheckBox textAndIconBtnEnabledCheck;

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

		// Retrieve interface elements
		textBtn = (Button)findViewById(R.id.textBtn);
		textBtnEnabledCheck = (CheckBox)findViewById(R.id.textBtnEnabledCheck);
		iconBtn = (ImageButton)findViewById(R.id.iconBtn);
		iconBtnEnabledCheck = (CheckBox)findViewById(R.id.iconBtnEnabledCheck);
		textAndIconBtn = (Button)findViewById(R.id.textAndIconBtn);
		textAndIconBtnEnabledCheck = (CheckBox)findViewById(R.id.textAndIconBtnEnabledCheck);

		// Add listeners
		textBtnEnabledCheck.setOnCheckedChangeListener(this);
		iconBtnEnabledCheck.setOnCheckedChangeListener(this);
		textAndIconBtnEnabledCheck.setOnCheckedChangeListener(this);
	}

	@Override
	public void onCheckedChanged(CompoundButton buttonView, boolean isChecked)
	{
		if (buttonView == textBtnEnabledCheck)
		{
			textBtn.setEnabled(isChecked);
		}
		else if (buttonView == iconBtnEnabledCheck)
		{
			iconBtn.setEnabled(isChecked);
			iconBtn.setClickable(isChecked);
		}
		else if (buttonView == textAndIconBtnEnabledCheck)
		{
			textAndIconBtn.setEnabled(isChecked);
		}
	}
}

That’s it. I hope you can find something useful in this post and if you want to see some custom buttons in action in a real application, you could give a try to FWebLauncher.

Using the standard Android icons in your own application

Andrea Bresolin — Sun, 17 Jul 2011 22:54:35 +0000

Source code

When you make your own Android application, you usually put also your own graphic elements in it like custom icons and images, but it’s still a good idea to keep the standard Android icons for common user interactions. This helps the user to immediately understand the meaning of the options inside your application and it gives a familiar environment that is consistent with the Android platform. So, how do you get the standard Android icons? How do you deal with different Android versions (the style of the icons might change)?

There are two different options to accomplish this task:

reference the icons with android.R.drawable;
copy the standard Android icons from the SDK to your own application’s resources folder.

OPTION 1 – The good points about this option is that you automatically have the correct resource for the platform version where your application is running and the size of the application package doesn’t become higher in case you’re using more standard Android icons. This looks like the perfect solution, so why look for another one? Well, not all the icons are defined in android.R.drawable so you are forced to copy them locally in case you can’t find them in the class. Another bad point is what is explicitly stated in the guidelines documents for the menu icons and the status bar icons:

“Warning: Because these resources can change between platform versions, you should not reference these icons using the Android platform resource IDs (i.e. status bar icons under android.R.drawable). If you want to use any icons or other internal drawable resources, you should store a local copy of those icons or drawables in your application resources, then reference the local copy from your application code. In that way, you can maintain control over the appearance of your icons, even if the system’s copy changes.”

OPTION 2 – You can find all the standard Android icons in your SDK local installation following the path ${ANDROID_SDK_INSTALL_DIRECTORY}\platforms\android-${PLATFORM_VERSION}\data\res, so let’s say that you installed the SDK under C:\AndroidSDK and you want the resources for the version 7 of the Android platform (i.e. Android 2.1), you can find everything under C:\AndroidSDK\platforms\android-7\data\res. You can copy for example the hdpi version of the icons from C:\AndroidSDK\platforms\android-7\data\res\drawable-hdpi. Following this approach, you need to copy the icons for different versions of the Android platform in case their style changed between one version and another. This is what happened for example for the menu and status bar icons, since Android 2.3 (platform version 9) the style changed, so you need a copy of the standard icons for Android 2.3 and higher and for Android 2.2 and lower. To do this, in your own application you need two different folders (this example refers to the hdpi icons):

/res/drawable-hdpi (for Android 2.2 and lower)
/res/drawable-hdpi-v9 (for Android 2.3 and higher)

Now let’s see a simple example application that uses the standard icons getting them in both ways. Here is the layout of the main activity:

And here is the source code for the MainActivity class:

package com.devahead.standardandroidicons;

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

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

		// Set the image source referencing android.R.drawable
		ImageView img1 = (ImageView)findViewById(R.id.img1);
		img1.setImageResource(android.R.drawable.ic_menu_add);

		// Set the image source referencing a local copy of the icon
		ImageView img2 = (ImageView)findViewById(R.id.img2);
		img2.setImageResource(R.drawable.ic_menu_add);
	}
}

In this application I used the ic_menu_add standard Android icon. For this example to work, we need to put a copy of the original icon ic_menu_add.png from C:\AndroidSDK\platforms\android-8\data\res\drawable-hdpi to our local /res/drawable-hdpi and another copy from C:\AndroidSDK\platforms\android-9\data\res\drawable-hdpi to our local /res/drawable-hdpi-v9. In this way, the application will load the correct version of the local icon depending on the platform version, so for Android 2.3 and higher, the copy under /res/drawable-hdpi-v9 will be automatically chosen.

In the following images you can see the final result. If you run the application on Android 2.1, you see that there’s a glow around the icon while on Android 2.3 there is no outer glow. That’s because the style changed starting from Android 2.3 as it is written in the menu icons design guidelines, so our example application loads the correct icon depending on the platform version.

Example application running on Android 2.1:

Example application running on Android 2.3:

The option you choose to load the standard Android icons is up to you. With this post I just wanted to show the different possibilites, but they all have some good and bad points that must be evaluated to choose what’s right for you.

You can find the source code of the example application following the link on top of the post.

Creating an Android dialog and maintaining its state on screen orientation change

Andrea Bresolin — Sun, 10 Jul 2011 22:17:49 +0000

Source code

You want to create a custom dialog in Android, but you also want to maintain its state on screen orientation change when it’s already open and the Android device is rotated. How do you do that? If you use the standard methods that Android provides inside activities, it’s straightforward. Here I’m going to show how to create a completely custom dialog with its own custom layout and interface elements.

Let’s start with the basics. What do you need inside your Android activity?

implement the onCreateDialog method;
implement the onPrepareDialog method;
keep a constant with the custom dialog ID;
call the showDialog method to display the dialog;
call the removeDialog or dismissDialog methods to remove the dialog from the screen.

And now straight to the source code with an example application. The layout of our custom dialog will look like this (custom_dialog.xml resource file):

We simply have two text fields (cdField1Edit and cdField2Edit) and two buttons to confirm our input (cdOKBtn) or to cancel the dialog (cdCancelBtn).

Inside the main activity we can set a default value for cdField2Edit in the dialog (through cdField2DefValEdit) and we have a button to display the dialog (showCDBtn):

The MainActivity class is the place where we’re going to implement the logic to manage the creation and intialization of our custom dialog:

package com.devahead.customandroiddialog;

import android.app.Activity;
import android.app.Dialog;
import android.content.DialogInterface;
import android.content.DialogInterface.OnCancelListener;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.view.ViewGroup.LayoutParams;
import android.widget.Button;
import android.widget.EditText;
import android.widget.Toast;

public class MainActivity extends Activity implements OnClickListener
{
	protected static final int DIALOG_1 = 0; // Dialog 1 ID

	// Dialog 1 default values (static variables to maintain the values on screen orientation change)
	protected static String cdField2DefaultValue;

	// Interface elements
	protected EditText cdField2DefValEdit;
	protected Button showCDBtn;

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

		// Retrieve interface elements
		cdField2DefValEdit = (EditText)findViewById(R.id.cdField2DefValEdit);
		showCDBtn = (Button)findViewById(R.id.showCDBtn);

		// Add listeners
		showCDBtn.setOnClickListener(this);
	}

	public void onClick(View v)
	{
		if (v == showCDBtn)
		{
			showDialog1(cdField2DefValEdit.getText().toString());
		}
	}

	@Override
	protected Dialog onCreateDialog(int id)
	{
		switch (id)
		{
			case DIALOG_1:
			{
				final Dialog dialog = new Dialog(this);

				// Setup the custom dialog interface elements
				dialog.setContentView(R.layout.custom_dialog);
				dialog.getWindow().setLayout(LayoutParams.FILL_PARENT, LayoutParams.WRAP_CONTENT);

				Button cdOKBtn = (Button)dialog.findViewById(R.id.cdOKBtn);
				Button cdCancelBtn = (Button)dialog.findViewById(R.id.cdCancelBtn);

				cdOKBtn.setOnClickListener(new OnClickListener()
				{
					// Called when the OK button is pressed
					@Override
					public void onClick(View v)
					{
						EditText cdField1Edit = (EditText)dialog.findViewById(R.id.cdField1Edit);
						EditText cdField2Edit = (EditText)dialog.findViewById(R.id.cdField2Edit);

						String field1Value = cdField1Edit.getText().toString();
						String field2Value = cdField2Edit.getText().toString();

						// Call a method to process the dialog result
						MainActivity.this.processDialog1Result(field1Value, field2Value);

						// If we call removeDialog, then onCreateDialog will be called every time
						// the dialog needs to be displayed, otherwise if we call dismissDialog,
						// only onPrepareDialog will be called after the first dialog creation
						// (the first showDialog).
						removeDialog(DIALOG_1);
						//dismissDialog(DIALOG_1);
					}
				});

				cdCancelBtn.setOnClickListener(new OnClickListener()
				{
					// Called when the Cancel button is pressed
					@Override
					public void onClick(View v)
					{
						removeDialog(DIALOG_1);
						//dismissDialog(DIALOG_1);
					}
				});

				dialog.setOnCancelListener(new OnCancelListener()
				{
					// Called when the Back button is pressed
					@Override
					public void onCancel(DialogInterface dialog)
					{
						removeDialog(DIALOG_1);
						//dismissDialog(DIALOG_1);
					}
				});

				return dialog;
			}
			default:
				return null;
		}
	}

	@Override
	protected void onPrepareDialog(int id, Dialog dialog)
	{
		switch (id)
		{
			case DIALOG_1:
			{
				dialog.setTitle("Custom dialog 1");

				EditText cdField1Edit = (EditText)dialog.findViewById(R.id.cdField1Edit);
				EditText cdField2Edit = (EditText)dialog.findViewById(R.id.cdField2Edit);

				// Set the default values for Field 1 and 2
				cdField1Edit.setText("");
				cdField2Edit.setText(cdField2DefaultValue != null ? cdField2DefaultValue : "");
			}
			break;
		}
	}

	protected void showDialog1(String field2DefaultValue)
	{
		// Set the default value for Field 2 (used in onPrepareDialog)
		cdField2DefaultValue = field2DefaultValue;

		showDialog(DIALOG_1);
	}

	protected void processDialog1Result(String field1Value, String field2Value)
	{
		Toast.makeText(this, "CD1 - field1Value: " + field1Value + " - field2Value: " + field2Value,
			Toast.LENGTH_LONG).show();
	}
}

All the methods useful to manage dialogs need an ID to keep track of all the operations to perform on a specific dialog, so i created a constant named DIALOG_1 that represents the ID of our custom dialog. I could create as many ids as I want, the important thing is to identify every dialog with a specific ID. When you start the example application, you can set a default value to initialize Field 2 inside the dialog and then you can press the button to display it.

When you call showDialog with the DIALOG_1 ID, Android calls onCreateDialog to let you create the dialog for the same ID, so you can setup the interface elements and add all the listeners you need for managing the dialog events. In the example I added a listener for the click events of the OK button (cdOKBtn) to process the data set by the user, one for the Cancel button (cdCancelBtn) to remove the dialog and another one for the onCancel event. The latter is useful to manage the case when a user presses the back button of the Android device to close the dialog because we can receive the event, but it’s our responsibility to really close the dialog maybe performing some sort of deinitialization if we need it.

After calling onCreateDialog, Android calls onPrepareDialog to let you initialize default values for the interface elements inside the dialog. In the example we set cdField1Edit to blank and we initialize cdField2Edit with the default value specified by the user in the MainActivity.

So why do we need both onCreateDialog and onPrepareDialog? Couldn’t we just do everything inside onCreateDialog? To answer this question, let’s take a look at what happens depending on the way we close the dialog. We have two options to close it: removeDialog and dismissDialog. Here is what happens in different situations depending on our implementation choices:

we close the dialog using removeDialog: every time we display the dialog again using showDialog, both onCreateDialog and onPrepareDialog are called by Android because the dialog is not reused after being closed;
we close the dialog using dismissDialog: the first time we display the dialog using showDialog, both onCreateDialog and onPrepareDialog are called by Android, but all the subsequent times we call showDialog, only onPrepareDialog is called by Android because the dialog has already been previously created and it’s reused after being closed (to save resources and the computation necessary to create the dialog every time we need to display it);
the screen orientations changes while the dialog is still open: both onCreateDialog and onPrepareDialog are called by Android because the MainActivity instance is created again and also the dialog needs to be created again, but using the standard Android methods to manage the dialogs, the system saves its state for us and the field values will be preserved and restored in the new dialog instance after the orientation change (even though onPrepareDialog is called to initialize the fields, Android restores their values after calling that method so we don’t need to care about that).

This is the important thing, Android does the job for us restoring the field values in the dialog when the screen orientation changes, all we need to do is to implement the standard methods available in every activity for dialogs management and choose a specific ID for every dialog created by the activity.

As usual, you can download the full source code for this example using the link on the top of the post so you can take a look at it and experiment on your own.

Extending the Android Application class and dealing with Singleton

Andrea Bresolin — Sun, 19 Jun 2011 21:21:08 +0000

Source code

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:

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.

At this point you may ask: "wait a moment… why is the singleton initialized in MyApplication??? Isn’t it supposed to be just a singleton so the instance can be initialized everywhere in the application like in an Activity?" Here comes the tricky part… I’ve been digging around the web and in books for a long time searching for information on the static variables lifecycle in Android because I found some weird behaviors when I started programming for Android, but unfortunately there seem to be different opinions about this topic, there is a bit of confusion and I still haven’t found a single definitive source of information.

If you know about the activities lifecycle in Android, you also know that they can be destroyed by the system in case they’re no more used and they’re not active or some resources are needed by the system, so it happens that during the life of an application, an activity could be destroyed and created many times, while the application process remains the same. While I was developing an application, I found that sometimes some static variables bound to activities happened to be uninitialized even though they’ve previously been initialized! I thought that when a static variable is initialized it stays so for the entire life of the application, but this doesn’t seem to be the case. Among all the information I found on the web, I tried to find out a safe and reliable way to initialize static variables (and you know that the singleton design pattern requires the use of a static variable). The explanation of the weird behavior I saw that makes more sense to me is that the static variables instances are bound to the class loader of the class that first initialized them. So what does this mean? This means that if a static variable inside any class has been initialized by an activity, when that activity is destroyed also its class might be unloaded and so the variable becomes uninitialized again! While if the variable is initialized by the application class, it’s life is the same as the application process so we’re sure that it will never become uninitialized again. That’s why I chose to initialize all the singletons in the MyApplication class.

I don’t know if the solution I found is correct and makes sense as it seems that this topic is not clear for many people dealing with Android and even the official documentation seems to make the people think that static variables are not problematic and behave exactly like we are used to in other environments with the Java virtual machine, but using the technique I explained actually solved my problems with static variables deinitialization and I never had the weird behaviors I was having when I was initializing them (as well as singletons) directly from my activities.

If someone found a better solution or doesn’t think this approach is correct, I would be happy to hear a different opinion. This is what the web is useful for and it’s interesting to read thoughts of experienced Android developers.

Flex exceptions are suppressed in MXML data binding expressions

Andrea Bresolin — Wed, 15 Sep 2010 00:19:46 +0000

Live demoSource code (LICENSE)

While using data binding expressions inside MXML tags, you may have noticed that sometimes there seem to be strange behaviors during expressions evaluation, for example it could happen that an expression is not updated like you expect it to be when a value of a bindable variable changes. Whenever someone new to Flex starts to work with it, I noticed that sooner or later he asks me always the same question: "Why is the value of that label not being updated? I think that my expression is correct…" I had the same problem too at the beginning, because it’s not something obvious, but it’s important to keep a rule in mind.

This is the thing to know: exceptions are suppressed in MXML data binding expressions! And it’s very important to keep in mind this rule: every data binding expression must be written in a way that avoids exceptions, considering all the possible values that each variable in the expression can get.

The reason why an expression sometimes is not evaluated is usually the fact that there has been an exception during the evaluation. In this case using some if statements in the expression generally solves the problem. Let’s take a look at an example application to show what we’re talking about.

In the application we use some data binding expressions inside curly braces. The value of myVar1 is displayed in three labels, but only in the last one there’s an if statement that actually checks if its value is null. Since in every expression we try to use the function toUpperCase on the variable, there is clearly an exception if the variable is null. If you try to set myVar1 = null clicking on the corresponding button, you’ll see that the only label that is correctly rendered is the one with the if statement, because it’s data binding expression avoids generating an exception. The function testFunc has the purpose of demonstrating that the value of i is never increased whenever there’s an exception in the first line of the function’s body and the exception is never thrown because it is suppressed automatically. If you keep on clicking on both the buttons, you’ll see that the value of i is increased only when there are no exceptions in testFunc, i.e. the value of myVar1 is not null.

So if you notice some strange behaviors in your data binding expressions evaluation, keep in mind what we’ve seen here, because you will never get a message telling you that there has been an exception, even with the debug version of the Flash Player.

Setter is not invoked when a bindable Flex property doesn’t change

Andrea Bresolin — Sat, 15 May 2010 20:35:35 +0000

Live demoSource code (LICENSE)

You’ve probably been using the Bindable metadata tag a lot of times with properties in your Flex applications. When a property is defined through getter and setter functions, you may take for granted that each time you set the value of the property, the corresponding setter is invoked, so you can perform your own operations in it. Well, this is not totally true with bindable properties. What I’m going to show is just something to remember whenever you use the Bindable metadata tag with properties defined through getter and setter. It is much easier to explain everything if we immediately look at the example application.

The property called notBindableProp is just a simple not bindable property. Whenever you set its value, the setter is invoked. bindableProp is a standard bindable property. If you try to set its value, you’ll quickly find out that the setter is invoked only if the new value is different from the value returned by the corresponding getter. So you cannot rely on doing something inside the setter when the new value is exactly the same as the previous one. What if you still want a bindable property, but you need to perform some operations in the setter every time a value is set, even if it’s equal to the previous one? You can simply define a custom event name in the Bindable metadata tag as you can see in the bindableEventProp. Every time a value is set for that property, the setter is invoked and you can perform your operations and then dispatch your own event.