Introduction

In Android, you define a large share of the user interface through views. A view is a resource that combines together multiple widgets, including custom widgets you create from existing ones or completely from scratch. A view, however, represents the static part of a user interface, which is the part that is displayed by default as the user navigates to that particular section of the application. As the user interacts with the presented user interface the need for additional input elements may arise. Which kind of additional input elements? I mean portions of the user interface not originally displayed and mostly displayed on demand such as dialog boxes and menus.

Android devices feature a Menu button that, when touched by users, automatically pops up any application registered menu that applies to that context. Dialog boxes, instead, are programmatically displayed under the total control of the developer. The developer, in fact, may decide when to display a given dialog whether after a click on a button or the selection of a menu item. In this article, I'll be delving deep into menus and dialog boxes in Android for .NET, and discuss a few very common (and frequently used) types of menus and dialogs.

Types of Menus in Android

Android defines three distinct types of menus: options, context and submenu. The options menu refers to a feature has similarities with both the main menu and the context menu of desktop applications. In fact, the options menu is always hidden and shows up only when the user touches the Menu button. The options menu is dismissed right after a selection is made. At the same time, the options menu displays always in the same position, that is at the bottom of the screen.

The idea is that, as a user, you touch the Menu button when you're looking for a list of possible actions to take at a given stage of the application. Just for this reason, the list of options presented by the menu may be significantly different at different times. You can handle these differences in either of two ways. You can, for example, create a single menu and add or remove items and disable and enable items on a per-display basis. In alternative, you can reset and repopulate the menu before each display. You typically choose the latter option if the two menus to display are significantly different.

Another type of menu you find in Android is the context menu. It is nearly the same as the context menu of a desktop application. In Android, you associate the context menu with a view or a widget and all you get is a floating list of menu items to choose from. Finally, the submenu is a floating menu used to nest child menus to both options and context menus.

Creating an Options Menu

The menu is an application resource and should be defined as an XML file located in the res/menu folder. The name of the XML file is unimportant but it determines the name of the menu that you'll be using to reference the menu later. Figure 1 shows a project with two sample menu resources.

Figure 1: An example of menu resources.

Here's a concrete example of the content that a menu resource may have:

All items are grouped under the <menu> not and each item is characterized by a <item> node. Each item contains at least an ID and a title and an icon. You can reference titles and icons from the resources of the application using resource IDs. The previous example defines two menu items - to save and share the current state of the application.

Creating a menu from a resource is the most common approach, but it is not the only one. You can also do that programmatically by first creating a Menu object and then filling it up with MenuItem objects. To create submenus you simply create nested <menu> sub-trees. Speaking of menus, another really interesting concept is the menu group. A menu group is a logical way to group menu items so that you can then enable and disable them in a single shot. To create a group menu, you use the <group> element to group multiple menu items. Each group is given a unique ID.

Note that group menus have no impact on the user interface. In other words, the end user has no visible clue that two or more items are in the same group. Here's how you define menu groups:

An interesting scenario where menu groups are helpful is checkable menu items. Checkable menu items are a variation of menu items that permit the action of "checking" instead of "selecting" an option. You indicate a menu item as checkable by using the checkableBehavior attribute in the <item> element. More interestingly, you can make an entire group of items checkable. The checkableBehavior attribute gets two values: single and all. The former indicates that only one selection is possible; in a group, this indicates a radio button list. The latter indicates that all elements are individually checkable and corresponds to a check box list.

Displaying the Menu

To deal with menus in an Android activity, you must know about a couple of overridable methods of the Activity class. They are onCreateOptionsMenu and onPrepareOptionsMenu. Both take a Menu object and return a Boolean value.

The onCreateOptionsMenu is invoked only once, the first time the Menu button is touched in the application's instance. (Note that this behavior is slightly different in Android 3.0.) If your menu is relatively static and never changes, or limits its changes to enabling/disabling items, then it may be a good idea to initialize it only once and move adjustments to the implementation of onPrepareOptionsMenu. If your application's menu may require a significant restructuring depending on the context, then you'd better creating it from scratch every time the Menu button is touched. In this case, you save yourself overriding onCreateOptionsMenu and concentrate on onPrepareOptionsMenu. In the example below, you see an implementation of onPrepareOptionsMenu that chooses between two different menus. The method onPrepareOptionsMenu is invoked every time the menu is about to display. Both methods receive the menu object as an argument - the menu object is created by system as soon as the user taps the Menu button.

The method first clears the current menu and then repopulates it based on the context. Note that this code runs every time the user touches the Menu button, regardless of the application's context. Checking the context, in other words, is entirely up to you. In this case, if the menu has been requested when the sample application (a water polo scoring applet) is not playing a match, you get the "main" menu with options like start new match and settings. Otherwise, you get only options to save the current state and email/text it to a friend. (Figure 2 shows the two menus in action.

Figure 2: Different menus at different times.

Note that the menu object adjusts itself in terms of size and composition based on title length, icons and number of items.

Handling Menu Item Selection

The final aspect of menus we need to consider is how you handle the user's clicking. As you'll see in a moment, this particular aspect of Android programming is old vintage and calls back to memory the Windows SDK programming style of the 1990s.

All you need to do is overriding the onOptionsItemSelected method, grab the unique ID of the selected item and arrange a switch statement to decide the next step.

Generic Dialog Boxes

An old acquaintance of nearly every Windows programmer is the MessageBox function (and the peer static method in the .NET Framework). Android makes it easy to display a quick message that disappears after a specified number of seconds, but that's all it has to offer with nearly no programming effort. If you intend to create even the world's simplest alert box, be ready to write quite a bit of code. Worse yet, it's not especially clean code. On the other hand, that's the way to go and any effort to modify things to force a different programming style can easily be a remedy worse than the disease. Here's what you need to display a Yes/No message box in Android in response to the user's clicking on a button:

First off, the resetClickListener object you see at the top of the listing has been previously bound to the click event of a particular button - the Reset button you can see in Figure 2.

When the user touches the Reset button the preceding code runs and sets up an alert dialog box. To set up the dialog box, you use a builder object. The builder receives your input and understands how to shape up the dialog - title, message, buttons. In particular, the negative button refers to the action that represents a No answer to the question being asked by the dialog. (You wouldn't bring up a dialog if you weren't looking for some sort of an answer.) The positive button instead represents the Yes answer.

As I see things, the problem with code design comes when you call either setPositiveButton or setNegativeButton. You have no other way than passing the code for button clicks inline. As a .NET developer, unless you're a big fan of delegates you likely feel a bit uncomfortable. Anyway, that's just the way it works for dialogs in Android. Figure 3 shows the output of the previous listing.

Figure 3: An Android message box.

What about custom dialog boxes? Android offers a bunch of predefined dialog boxes for you to pick up dates, times, items from a list and other common scenarios. However, base classes exist for you to customize nearly everything.

Summary

This article approached a couple of relatively common elements of a mobile user interface: menus and dialog boxes. Both aspects are nothing new in development but in mobile they play a fundamental role in providing a native experience to users of our applications. For this reason, it is important not just to understand how, say, menus work, but the scenarios in which the user expects to find them available and with which options enabled. Overall, I believe that this second aspect is even more crucial than mere syntax.

About Dino Esposito

Dino Esposito is one of the world's authorities on Web technology and software architecture. Dino published an array of books, most of which are considered state-of-the-art in their respective areas. His most recent books are “Microsoft ® .NET: Architecting Applications for the Enterprise” and “... This author has published 53 articles on DotNetSlackers. View other articles or the complete profile here.