In a previous post called Ten Tips for Android Application Development, which was a compilation of tips by the authors ofAndroid Application Development, I added a bonus tip about navigating in Android applications: Avoid hierarchy. Here, I expand on that advice. Navigation in Android
Android has a wonderful navigation system, with support built deep into the Android architecture. Android applications consist of Activity objects, usually one for each screen, and the Android API supports navigating forward and backward through Activity objects, even across applications. That is, one application can easily “borrow” a screen from another, perform a task, like cropping an image, and get a result back when the activity is complete, or the Android notification system might take you from your current Activity to Gmail to quickly check a mew message.
What the user sees is a seamless blending of functionality. Applications lose their boundaries. Getting back to where you were before you read that new email is as simple as pressing the “Back” button. This simple forward/back navigation, and the way applications can use, and offer up functionality for other applications to use, is why many people find the Android user experience preferable to the more overtly one-app-at-a-time experience on the iPhone. Even Google can get this wrong
But there is a fly in the ointment: Many apps, even those authored by Google, have a menu item called “Home.” Some big applications with lots of hierarchy to traverse, where the user can be many layers deep in this hierarchy, may actually need a Home menu item. But too many applications, especially simple ones like Google Listen and the Android Market, have seemingly gratuitous Home navigation. This is bad. Navigation and modularity
Android applications are modular: It’s easy to refactor well-written applications to include more Activity objects or to put Activity objects in separate applications. You can make a single application look like more than one, and vica versa. Data and user interface are separated, and data is accessible across application boundaries through Intent objects, the content provider mechanism, and through remote methods. Applications should start anywhere in a network of Activity objects. User need not be aware of being “inside” a particular application. Navigation should take you to functionality, not to a place called Home. Unless you really need a place for users to get back from a lengthy excursion, Home is bad for code modularity and bad for the user experience. Home is where you launch apps
Android handsets have a Home hard-key, with an icon that looks like a home. This should be a clue to the application designer that Home means the Android Home application – the launcher, not some place in each application, especially not in applications that have only a handful of Activity objects. Examples: Listen vs. Gmail
Google Listen, for example, has a top level menu with only four items. You can’t actually do anything, or listen to anything, at this top level menu. It’s just a pause on your way to actually getting something you want. In the case of Listen, both the top level menu and the Home navigation that takes you there are gratuitous. Each Activity of the Listen application could have been reached directly from the option menu. The Gmail application is more complex than Listen, but it does entirely without a Home. It may have been tempting to make a Home screen in Gmail. Either the “View labels” screen or the Inbox are candidates for a Home navigation. But lack of a Home is what makes Gmail so fluid: You drop in from a notification, and navigate back out to pick up where you left off in your previous application. Having a Home encourages users to abandon the Back key and navigate through the application switcher dialog, breaking up the forward/back flow and emphasizing boundaries between applications. Don’t be homely
When you design your applications, make them more beautiful by leaving out the Home navigation. Note that none of the examples of navigating among Activity objects in A Tour of Activities and Tasks ever navigates to an application’s home screen. As your application grows, you will find it easier to use other applications’ functionality. You will find it easier for applications to use your application’s functionality. Your users will find the user experience more fluid and a more natural part of the overall Android user experience.
This practical book provides the concepts and code you need to develop software with Android, the open-source platform for cell phones and mobile devices that’s generating enthusiasm across the industry.Android Application Development introduces this programming environment, and offers you a complete working example that demonstrates Android architectural features and APIs. The book is a natural complement to the existing Android documentation provided by Google.