Whenever a user launches an Android application, a thread called “main” is automatically created. This main thread, also called the UI thread, is crucial since it’s responsible for dispatching events to various widgets, including the drawing events. For careless Android developers, this single thread can be the overarching reason for poor app performance. With so much riding on a single thread performing long operations like network access or database queries, any interference on this thread will block up the entire user interface. No events can be dispatched – including drawing events – while long operations are underway, and from the user’s perspective, the application appears hung. Even worse, if the UI thread is blocked for more than a few seconds (about 5 seconds currently) the user will encounter the dreaded “application not responding” (ANR) dialog.

BaseAdapter is an Adapter object that acts as a bridge between an AdapterView and the underlying data for that view. The Adapter provides access to specific data points and is also responsible for making a View for each point in the data set. So, taking the example of downloading an image over HTTP, there may be some slowdown in our application with the Main UI thread getting blocked for more than a few seconds, and users might be presented with the ANR dialog. To avoid this situation I have some suggestions:

1. Use ExecuterService (Thread pool)
2. Use AsynTask
3. Use SoftReference Drawable Object
4. Create the ListView first, then download images
5. Make use of OnScrollListener Interface

I’ve written a sample application to help Android developers visualize this implementation.

Here we have AbastractListAdapter, an extension of BaseAdapterClass:

public abstract class AbstactListAdapter extends BaseAdapter {
	public AbstactListAdapter(Context context) {
		this.context = context;
	}
	public abstract void setScrollStatus(boolean scroll);
	public abstract void scrollIdle(AbsListView view);
}

There are two methods of implementation for Class ListAdapterScrollListener and Onscrollistner.

public void onScroll(AbsListView view, int firstVisibleItem,int visibleItemCount, int totalItemCount) {
		adapter.setScrollStatus(true);
	}
public void onScrollStateChanged(AbsListView view,intSrollState) {
		switch (scrollState) {
		case OnScrollListener.SCROLL_STATE_IDLE:
			adapter.scrollIdle(view);
			break;
		case OnScrollListener.SCROLL_STATE_TOUCH_SCROLL:
			adapter.setScrollStatus(true);
			break;
		case OnScrollListener.SCROLL_STATE_FLING:
			adapter.setScrollStatus(true);
			break;
		}
}

In my onCreate method I set up and configure the list view to load the views and set the listner for Scroll.

public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Adapter mAdapter=new Adapter(this);
        setListAdapter(mAdapter);
        getListView().setOnScrollListener(new 		ListAdapterScrollListener(mAdapter));
      }

I use an Adapter class to extend AbstractAdapterClass and implement BaseAdapter, both of which help to load images when scrolling is idle.

The image is loaded in a separate threadpool. I have used Executerservice and assign a threadpool to download images. This method employs a runnable which will extend Assigntask. This ImageLoader class has a subclass, workerthread, which extends Assyntask and implements runnables. This class uses ExecutorService, and assigns 5 threads to do the work. Other implementations of this kind launch a separate thread per image, meaning that the network connection will become clogged with any image load. Assigning the task to the workerthread subclass and using onprogressupdate to notify the adapter to display the image reduces the burden.

You’ll notice the use of SoftReference here. While this appears to work well, I haven’t done any significant load or performance testing, so it may not be necessary. Since bitmap/drawable objects require memory, and Android supports 16mb of heap, it’s better to classify those objects as SoftReference objects. SoftReferences pointing to softly reachable objects are guaranteed to be cleared before the VM triggers an OutOfMemoryError. This can be written as follows:

 public class ImageLoader {

private class WorkerThread extends AsyncTask implements Runnable{
		public WorkerThread(String url,int pos) {
			this.url=url;
			intex=pos;
			}
		@Override
		protected void onProgressUpdate(Void... values) {
			mAdapter.notifyDataSetChanged();
			super.onProgressUpdate(values);
		}
		@Override
		public void run() {
			Cache.put(intex,new SoftReference(readDrawableFromNetwork(this.url)));
			publishProgress();
		}
	}

	public Drawable getDrawble(int pos)
	{
		SoftReference mReference=Cache.get(pos);;
		if(mReference!=null)
			return mReference.get();
		else
			return null;
	}

/*method to get Image if already or to start new task to download*/
	public void loadImage(int First,int Last) {
			try{
					_exec = Executors.newFixedThreadPool(5);
				for(int pos=First;pos<=Last;pos++){
					if(Cache.containsKey(pos)){
						if(Cache.get(pos).get()==null)
							_exec.execute(new  WorkerThread(Dataset.mStrings[pos],pos));
					}else{
						_exec.execute(new  WorkerThread(Dataset.mStrings[pos],pos));
					}
				}
			}catch (Exception e) {
				_exec.shutdown();
			}

	}//end of method

	private static Drawable readDrawableFromNetwork(String url ) {
	   Write code here to downlaod image from network.
	}//end of method
}

And that’s it!

For your reference, the code has been packaged for you to download and inspect here.

Anyone with significant time in mobile application development understands the challenges of writing portable applications. There are tons of reasons for this, but probably the biggest hurdles we face are:

• Varying screen sizes
• Varying screen resolutions
• Varying hardware configurations
• Varying media formats; such as for images, audio, video
• Varying input methods; e.g. touch screen, T9 key pad, qwerty keypad
• Non-standard, device-specific hardware keys

And so on and so forth >_<

Android engineers, anticipating the witches brew of OEM handsets they would encounter, took steps to try and alleviate the situation by standardizing some key features:

• A very rich widget set that can scale according to needs
• Standardized way of implementing custom widgets
• Standardized user interface conventions for touch screen devices
• Standardized image capture formats {still buggy from time to time}
• Standardized mechanism for sharing code across different components; such as user interface elements, fixed content or a specific activity
• Standardized on a base set of hardware keys; e.g. Home, Back, End, and Trackball

Above notwithstanding, with screen sizes and resolutions still very much device dependent {see: T-Mobile G1, Motorola Droid, Google Nexus One, HTC Hero and so on}, creating a consistent UI that both looks good and works well on all platforms has been a slog. For Android developers or those just interested in Android application development, here we present a method and a design pattern that can be utilized to achieve precisely that. The focus points are as follows:

• Understand the functionality that needs to be replicated per device. This can be represented by a Java interface to achieve, for example, scaled UI elements across varying screen sizes and resolutions.
• Separate device-specific features into device-specific implementations. For example, each phone {including from the same manufacturer} might have different hardware keys, or even different keypads (such as T9, QWERTY, or SureType). If an application is to work on different phones with different input mechanisms, it must take into account these differences when implementing.
• A Class Factory that can intelligently instantiate the device-specific components of multiple handset designs.

Let’s take for example the case of displaying a splash screen at application launch. Here we address the issue of supporting for multiple devices. The first act of separating the functionality begins with this interface:

public interface SplashableScreen {
public void showSplashImage(ImageView mView);
public void startSpalshing() throws Exception;
public void SetSplashDuration(int time);

}

Any screen that can be shown as a splash has the functionality as described by the methods indicated.

A device-specific implementation / screen-specific implementation can be written as follows:

public class SplashScrren_320_480 implements SplashableScreen{
public void showSplashImage(ImageView mView){
// Write code speficic to this resolution.
}

}

And a proper implementation can be instantiated and used as follows:

public class SplashFactory{
public static SplashableScreen getSplashScreen(){
// Given a device metrics, instantiate appropriate class and return.
}
}

We’re pleased to offer the full code for this useful application for download here.

If you wish to publish your application to other users, you are required to sign your application with your own personal certificate. You can generate your own certificate by using the keytool.exe that comes with the JDK/bin folder. In most cases, you can tell the SDK build tools how to find keytool by making sure that your JAVA_HOME environment variable is set and that it references a suitable JDK. Alternatively, you can add the JDK version of Keytool to your PATH variable.

To generate your own certificate, issue the following command:

keytool –genkey –v –keystore sourcebits.keystore –alias CoolApp –keyalg RSA –validity 10000

The above command generates a certificate named sourcebits.keystore with the key alias sourcebits, generated using the RSA algorithm, and with a validity of 10,000 days (this is the minimum recommended).

You will be prompted for some information:

What is your first and last name?

[unknown]: <enter your first and last name>

What is the name of your organizational unit?

[unknown]: <enter your organizational unit>

What is the name of your organization?

[unknown]: <enter the name of your company>

What is the name of your City or Locality?

[unknown]: <enter the name of your city>

What is the name of your State or Province?

[unknown]: <enter the name of your state>

What is the two-letter country code for this unit?

[unknown]: <enter the two digit country code> e.g for USA it is US.

If you are publishing your application for the Android Market, your keystore must have a validity period that ends after 22 October 2033 (which is the reason greater than 10000 days validity is recommended).

Keytool prompts you to provide passwords for the keystore and key. It then generates the keystore as a file called sourcebits.keystore. The keystore and key are protected by the passwords you entered. The keystore contains a single key, valid for 10000 days. The alias is a name that you — will use later, to refer to this keystore when signing your application. Secure and protect these two passwords so that only people who are authorized to sign your applications know about them.

Signing your Android application:

All Android applications must be signed before they are allowed to be deployed onto a device. Android Market Place has made it mandatory to at-least Self-Sign your app before it is accepted. Unlike other mobile platforms, you need not purchase digital certificates from a certificate authority (CA). Instead, you can self-sign (generate your own personal certificate and use it to sign your Android applications).

To sign your application manually:

Have a project that generates your executable with the name you desire for your application.

(PAIN POINT: Your signing may fail otherwise).

Go to Eclipse, right-click on the project ->Android Tools->Export Unsigned Application Package and Select the apk file. You will then be asked to select a directory for exporting the application. For convenience you can export the Android package (with the .apk extension) to JDK/bin.

jarsigner -verbose -keystore sourcebits.keystore CoolApp.apk CoolApp

When prompted for the password for the keystore, use the password that was supplied during the key generation.

To verify that the application is signed correctly, you can use the –verify option with jarsigner.exe.

To verify that your .apk is signed, you can use a command like this:

$ jarsigner -verify CoolApp.apk

If the .apk is signed properly, Jarsigner prints “jar verified”. If you want more details, you can try one of these commands:

$ jarsigner -verify -verbose CoolApp.apk

or

$ jarsigner -verify -verbose -certs CoolApp.apk

The command above, with the –certs option added, the details of the certificate used to sign the application can be seen.

NOTE:

Select strong passwords for the keystore and key.

When you use keytool and jarsigner, do not supply the -storepass and -keypass options at the command line