Blog About Android Development

Android Development

Android Development


{Writing Portable Android Applications}

(Binil Thomas)

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.

Posted by cary in Applications | Code | Development Comments: 2 Add comment


  1. Tweets that mention Writing Portable Android Applications | Android Development | Android Application Development | Android Game Development | Android Software Development | Google Android Development -- wrote on April 24, 2010:

    [...] This post was mentioned on Twitter by Jason Goodrich, Anthony Hand. Anthony Hand said: @ChicagoAndroid – A nice brief article on writing portable apps for Android. Very quick summary, but useful. [...]

  2. wjlroe wrote on May 11, 2010:

    This is why Android has resources for layout etc. selected by the runtime on screen size, dimensions, pixel density, orientation etc. to avoid all this from requiring extensive code changes

Add Comment

You must be logged in to post a comment.