This blog is about design guidelines for writing imaginative and useful Android applications. Several recipes describe specific aspects of successful design. This article will list some others.
One purpose of this article is to explain the benefits of developing native Java Android applications over other methods of delivering rich content on mobile devices.
Requirements of a native handset application
There are a number of key requirements for successfully delivering any mobile handset application, regardless of the platform onto which it will be deployed:
- The application should be easy to install, remove, and update on a device.
- It should address the user’s needs in a compelling, unique, and elegant way.
- It should be feature-rich while remaining usable by both novice and expert users.
- It should be familiar to users who have accessed the same information through other routes, such as a website.
- Key areas of functionality should be readily accessible.
- It should have a common look and feel with other native applications on the handset, conforming to the target platform’s standards and style guidelines.
- It should be stable, scalable, usable, and responsive.
- It should use the platform’s capabilities tastefully, when it makes the user’s experience more compelling.
Android application design
The Android application we will design in my late blog's articles 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 localize 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 devices’ touch-screen features, the hardware button that allows users to switch the application to the background, and application switching capability.
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 article.
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 the one used by the Apple iPhone, as well as applications written for other platforms.
The application will adopt the Android style and design guidelines wherever possible so that it fits in with other Android applications 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.
A number of important device characteristics should be considered, as discussed in the following subsections.
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 designer should take into account the most appropriate choices for screen size and screen density when designing the application.
By default, an application is compatible with all screen sizes and densities, because the Android system makes the appropriate adjustments to the UI layout and image resources. However, you should create specialized layouts for certain screen sizes and provide specialized images for certain densities, by 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 particular kind of input hardware, you must declare it in the AndroidManifest.xml file, and be aware that the Google Play Store will not display your app on devices that lack this feature. However, it is rare for an application to 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 capability, 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).
A sophisticated Android application will use both 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. An options menu is typically invoked by a user pressing a hard button, often labeled Menu, or a soft menu button on an Action Bar (a vertical stack of three dots).
- Context menus contain secondary functionality for the currently selected item. A context menu is typically invoked by a user performing a long-press (press and hold) on an item. Like on the options menu, the selected operation can run in either 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 appear when you long-press on an item should be duplicated in the Activity you get to by a normal press on that item.
As very general guidance:
- Place the most frequently used operations first in the menu.
- Only the most important commands should appear as buttons on the screen; delegate the rest to the menu.
- Consider moving menu items to the action bar if your application uses one.
The system will automatically lay out the menus and provide standard ways for users to access them, ensuring that the application will conform to the Android user interface guidelines. In this sense, menus are familiar and dependable ways for users to access functionality across all applications.
Our Android application will make extensive use of Google’s Intent mechanism for passing data between Activity objects. Intents not only are used 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 behavior across all applications.
Data feeds and feed formats
It is not a good idea to interface directly to any third-party data source; for example, it would be a bad idea to use a Type 3 JDBC driver in your mobile application to talk directly to a database on your server. The normal approach would be to mediate the data, from several sources in potentially multiple data formats, through 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. 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 the data cannot be retrieved, the application may be broken and become unusable, and such changes may require the application to be republished. Mitigating the data on a middleware server ensures that the application will continue to work, albeit possibly in a limited fashion, regardless of whether the source data exists. The link between the application and the mitigated data will remain.
