Introduction: Designing a Successful Android application

Colin Wilcox

Discussion

This chapter is about design guidelines for writing imaginative and useful Android applications. There are several recipes that describe specific aspects of successful de- sign. This Preface will list some others.

One purpose of this document is to explain the benefits of developing native Java An- droid applications in preference to other methods of delivering rich content on mobile devices.

Mobile Phone Market Growth

The mobile phone market is predicted to growth by up to 27% over the next three years. The original dominating platforms such as Symbian and Windows Mobile will count for a largely reduced percentage of the mobile handset market than in past years with recent newcomers Android and Apple iOS (iPhone and iPad) accounting for al- most two thirds of the market by 2015.

Industry predictions for each of the key mobile handset platforms are shown in the table below.

Example 2-1.

XXX Make this a real table please

Android Apple Symbian Blackberry Microsoft Other 2010 22.7% 15.7% 37.6% 16.0% 4.2% 3.8%

2011 38.5% 19.4% 19.2% 13.4% 5.6% 3.9% 2012 49.2% 18.9% 5.2% 12.6% 10.8% 3.4% 2015 48.8% 17.2% 0.1% 11.1% 19.5% 3.3%

Predictions for the number of mobile handset sales for each of the main handset plat- forms (x thousand units), is shown in the table below.

Example 2-2.

Android Apple Symbian Blackberry Microsoft Other 2010 67,225 46,598 111,577 47,452 12,378 11,417 2011 179,873 90,560 89,930 62,600 26,346 18,392 2012 310,088 118,848 32,666 79,335 68.156 21,383 2015 539,318 189,924 661 122,864 215,998 36,133

Requirements of a Native Handset Application There are a number of key requirements needed for successfully delivering any mobile handset application regardless of the platform it will be deployed onto, namely:

• Ease of installation, removal and update on a device.

• An application should address the user needs in a compelling, unique and elegant way.

• Feature rich whilst remaining usable by both novice and expert users.

• An application should be familiar to users who have accessed the same information through other routes, e.g. website.

• Key areas of functionality should be readily accessible.

• Application should have a common look and feel with other native applications on the handset conforming to the target platform standards and style guidelines. • An application should be stable, scalable, useable and responsive.

• A great application should use the targets capabilities tastefully when it makes the users experience more compelling.

Android Application Design The Android application design will exploit the features and functions unique to the Android OS platform. In general the application will be an Activity based solution allowing independent and controlled access to data on a screen by screen basis. This approach helps to localise potential errors and allows sections of the flow to be readily replaced or enhanced independently of the rest of the application. Navigation will use a similar approach to that of the Apple iPhone solution in that all key areas of functionality will be accessed from a single navigation bar control. The navigation bar will be accessible from anywhere within the application allowing the user to freely move around the application.

The Android solution will exploit features inherent to Android devices, supporting the touch screen features, support for the hardware button to switch the application into the background and provide support for application switching.

Android provides the ability to jump back into an application at the point where it was switched out. This will be supported, when possible within this design.

The application will use only standard Android user interface controls to make it as portable as possible. The use of themes or custom controls is outside the scope of this design document.

The application will be designed such that it interfaces to a thin layer of RESTFUL web services that provide data in a JSON format. This interface will be the same as used by the Apple iPhone, as well as application written for other platforms.

The application will adopt the Android style and design guidelines wherever possible to provide an application that fits in with other Android application on the device. Data that is local to each view will be saved when the view is exited and automatically restored with the corresponding user interface controls repopulated when the view is next loaded.

There are a number of important device characteristics that should be considered:

Screen size and density

In order to categorize devices by their screen type, Android defines two characteristics for each device: screen size (the physical dimensions of the screen) and screen density (the physical density of the pixels on the screen, or dpi (dots per inch). To simplify all the different types of screen configurations, the Android system generalizes them into select groups that make them easier to target.

The design should take into account the most appropriate choices for screen size and screen density when designing the application

By default, your application is compatible with all screen sizes and densities, because the Android system makes the appropriate adjustments to your UI layout and image resources. However, you should create specialized layouts for certain screen sizes and provide specialized images for certain densities, using alternative layout resources, and by declaring in your manifest exactly which screen sizes your application supports.

Input configurations

Many devices provide a different type of user input mechanism, such as a hardware keyboard, a trackball, or a five-way navigation pad. If your application requires a par- ticular kind of input hardware,. However, it is rare that an application should require a certain input configuration.

Device features

There are many hardware and software features that may or may not exist on a given Android-powered device, such as a camera, a light sensor, Bluetooth, a certain version of OpenGL, or the fidelity of the touch screen. You should never assume that a certain feature is available on all Android-powered devices (other than the availability of the standard Android library.