Introduction: Designing a Successful Android Application
Author: Colin Wilcox --
Published? true --
This chapter is about design guidelines for writing imaginative and useful Android applications. There are several recipes that describe specific aspects of successful design. This Preface will list some others.
One purpose of this document is to explain the benefits of developing native Java Android applications in preference to other methods of delivering rich content on mobile devices.
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.
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 particular kind of input hardware,. However, it is rare that an application should require a certain input configuration.
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.
The Android application will provide instances of the two types of menus provided by the Android framework depending on the circumstances.
- Options menus contain primary functionality that applies globally to the current activity or starts a related activity. It is typically invoked by a user pressing a hard button, often labelled MENU. An Options menu is for any commands that are global to the current activity.
- Context menus contain secondary functionality for the currently selected item. It is typically invoked by a user's touch & hold on an item. Like on the Options menu, the operation can run either in the current or another activity.
A Context menu is for any commands that apply to the current selection.
The commands on the Context menu that appears when you touch & hold on an item should be duplicated on the activity you get to by a normal press on that item.
- Place the most frequently used operations first.
- Put only the most important commands fixed on the screen.
The system will automatically lay the menus out and provides standard ways for users to access them ensuring that the application will conform to the Android user interface guidelines. In this sense, they are familiar and dependable ways for users to access functionality across all applications.
The Android application will make extensive use of Googles Intent mechanism for passing data between Activity objects. Intents are used not only to pass data between views within a single application but also allow data, or requests, to be passed to external modules. As such much functionality can be adopted by the Android application by embedded functionality from other applications invoked by Intent calls. This reduces the development process and maintains the common look and feel and functionality behaviour across all application.
Data Feeds and Feed Formats
It is not intended to interface directly to any third party data source. The normal approach would be to mitigate the data, from several sources in potentially multiple data formats, through a middleware which then passes data to an application through a series of RESTFUL web service APIs in the form of JSON data streams.
Typically data is provided in such formats as XML, SOAP or some other XML-derived representation. Such representations such as SOAP are heavyweight and as such transferring data from the backend servers in this format increases development time significantly as the responsibility of converting this data into something more manageable falls on either the handset application or an object on the middleware server.
Mitigating the source data through a middleware server also helps to break the dependency between the application and the data. Such a dependency has the disadvantage that if, for some reason, the nature of the data changes or cannot be retrieved the application may be broken and become unusable and such changes may require the application to be republished. By mitigating the data on a middleware server, the application will continue to work, albeit possibly in a limited fashion, regardless of whether the source data exists or not. The link between the application and the mitigated data will remain. This can be seen from the abstracted diagram below: