EXHIBIT 57

133 Patent 1. In a computer system having a central processing unit (CPU), a graphical user interface including a display and a user interface selection device communicatively coupled to the CPU, a method for providing, and selecting from, a menu for a selected computer resource, said method comprising the steps of:

Exemplary Motorola Devices To the extent the preamble is construed to be limiting, the Droid 2 includes a computer system having a central processing unit (CPU), a graphical user interface including a display and a user interface selection device communicatively coupled to the CPU, and provides for a method for providing, and selecting from, a menu for a selected computer resource. Figure 1-1 shows the Motorola Droid 2 (hereinafter, "Droid 2").

Touchscreen

Keyboard

Figure 1-1 See also Ex. A, "Droid 2 by Motorola," http://www.motorola.com/Consumers/US-EN/Consumer-Productand-Services/Mobile-Phones/Motorola-DROID-2-US-EN (visited Sept. 9, 2010). This device is a handheld computer and accordingly includes a CPU. As shown, it includes a graphical user interface including a display. The device also includes user interface selection devices, including a touch screen and a keyboard. These elements are labeled in Figure 1-1. Figure 1-2 shows an exemplary Inbox email folder in the accused device's Email application.

133 Patent

Exemplary Motorola Devices

Figure 1-2 generating a set of menu selections for the selected computer resource in response to receiving, by the CPU, a context menu generation signal from the user interface selection device, the generating step comprising the steps of: The Droid 2 generates a set of menu selections for the selected computer resource in response to receiving, by the CPU, a context menu generation signal from the user interface selection device. The accused devices generate menu selections in response to receiving a click that lasts longer than a prescribed period of timei.e., a "long-click."or in response to the user selecting the message by navigating to it using the arrow keys and pressing and holding the Enter key on the keyboard for more than a prescribed threshold of time. For instance, "[t]he Android system provides two types of menus you can use to provide functionality or navigation." (Menu Design Guidelines.) One of the menus that the accused devices generate is a context menu: "This is a floating list of menu items that may appear when you perform a long-press on a View (such as a list item)." Ex. B, "Creating Menus Documentation," http://developer.android.com/guide/topics/ui/menus.html (visited Sept. 9, 2010). "The Android context menu is similar, in concept, to the menu revealed with a 'right-click' on a PC. When a view is registered to a context menu, performing a 'long-press' (press and hold for about two seconds) on the object will reveal a floating menu that provides functions relating to that item." Id. Figure 1-3 shows an exemplary context menu. The Droid 2 generates this menu when the user performs a long click on an

133 Patent

Exemplary Motorola Devices email message that has been read or presses and holds the enter key on the keyboard after selecting such a message using the arrow keys.

Figure 1-3

retrieving a menu selection relating to a class of objects to which the selected computer resource belongs; and

The Droid 2 retrieves a menu selection relating to a class of objects to which the selected computer resource belongs. For instance, the Menu Design Guidelines describe retrieving menu selections relating to classes of objects to which computer resources belong: "Text links and text fields in the content both have systemprovided operations that are common across all applications: operations such as 'Select all', 'Select text', 'Copy all', and 'Add to dictionary'. If the text field is editable, it also has other operations, such as 'Cut all' and 'Input Method', and if text is also on the clipboard, it has 'Paste'. The system automatically inserts the appropriate menu items into the Context menu of text links and text fields, as shown in the following screenshot." Ex. C, "Menu Design Guidelines," http://developer.android.com/guide/practices/ui_guidelines/menu_ design.html (visited Sept. 9, 2010); see also Fig. 1-3, supra. The Droid 2 retrieves a menu selection associated with a container in which the selected computer resource resides. For instance, the Menu Design Guideline provides examples of retrieving menu selections for context menus associated with a

retrieving a menu selection associated with a container in which the selected computer resource resides; and

133 Patent

Exemplary Motorola Devices container in which selected computer resources reside. See Ex. C. For example, the email messages shown in the Figures above are stored in a container; namely, the Inbox. The context menus shown in Figure 1-3 includes menu selections that are common to all email messages in the Inbox: Archive, Delete, etc.. The Droid 2 displays upon the display the set of menu selections in a menu positioned in the proximity of a graphical representation of the selected computer resource. For example, Figure 1-3 shows such a display:

displaying upon the display the set of menu selections in a menu positioned in the proximity of a graphical representation of the selected computer resource.

Figure 1-3

18. A graphical user interface providing context sensitive menu options to a user for a selected computer resource in a computer system having a central processing unit (CPU), a display, and a user interface selection device communicatively coupled to the CPU, the graphical user interface comprising:

To the extent the preamble is construed to be limiting, the Droid 2 includes a graphical user interface that provides context sensitive menu options to a user for a selected computer resource in a computer system having a central processing unit (CPU), a display, and a user interface selection device communicatively coupled to the CPU. Figure 18-1 shows the Motorola Droid 2 (hereinafter, "Droid 2").

133 Patent

Exemplary Motorola Devices

Touchscreen

Keyboard

Figure 1-1 See also Ex. A. This device is a handheld computer and accordingly includes a CPU. As shown, it includes a graphical user interface including a display. The device also includes user interface selection devices, including a touch screen and a keyboard. These elements are labeled in Figure 18-1. Figure 18-2 shows an exemplary Inbox email folder in the Droid 2's Email application.

Figu7re 18-2 means for generating a set of menu selections for the The Droid 2 includes a means for generating a set of menu selections for the selected computer resource in response to 5

133 Patent selected computer resource in response to receiving, by the CPU, a context menu generation signal from the user interface selection device, the means for generating comprising:

Exemplary Motorola Devices receiving, by the CPU, a context menu generation signal from the user interface selection device. For instance, the Droid 2 generates menu selections in response to receiving a click that lasts longer than a prescribed period of timei.e., a "long-click"or in response to the user selecting the message by navigating to it using the arrow keys and pressing and holding the Enter key on the keyboard for more than a prescribed threshold of time. For instance, "[t]he Android system provides two types of menus you can use to provide functionality or navigation." Ex. C. One of the menus that the accused devices generate is a context menu: "This is a floating list of menu items that may appear when you perform a long-press on a View (such as a list item)." Ex. B. "The Android context menu is similar, in concept, to the menu revealed with a 'right-click' on a PC. When a view is registered to a context menu, performing a 'long-press' (press and hold for about two seconds) on the object will reveal a floating menu that provides functions relating to that item." Id. Figure 18-3 shows an exemplary context menu. The Droid 2 generates this menu when the user performs a long click on an email message that has been read or presses and holds the enter key on the keyboard after selecting such a message using the arrow keys.

Figure 18-3

133 Patent means for retrieving a menu selection relating to a class of computer objects to which the computer resource belongs, and

Exemplary Motorola Devices The Droid 2 includes a means for retrieving a menu selection relating to a class of computer objects to which the computer resource belongs. For instance, the Menu Design Guidelines describe retrieving menu selections relating to classes of objects to which computer resources belong: "Text links and text fields in the content both have systemprovided operations that are common across all applications: operations such as 'Select all', 'Select text', 'Copy all', and 'Add to dictionary'. If the text field is editable, it also has other operations, such as 'Cut all' and 'Input Method', and if text is also on the clipboard, it has 'Paste'. The system automatically inserts the appropriate menu items into the Context menu of text links and text fields, as shown in the following screenshot." Ex. C; see also Fig. 18-3, supra. For example, to create the context menu shown in Figure 18-3, the device retrieved a menu selection relating to the class of objects: "Unread messages." The corresponding menu selection is "Mark unread." The Droid 2 includes a means for retrieving a menu selection associated with a container in which the computer resource resides. For instance, the Menu Design Guideline provides examples of retrieving menu selections for context menus associated with a container in which selected computer resources reside. See Ex. C. For example, the email messages shown in the Figures above are stored in a container; namely, the Inbox. The context menushown in Figure 1-3 includes menu selections that are common to all email messages in the Inbox: Archive, Delete, etc. The Droid 2 includes a means for displaying upon the display the set of menu selections in a menu positioned in the proximity of a graphical representation of the selected computer resource. Figure 1-3, supra, shows this display:

means for retrieving a menu selection associated with a container in which the computer resource resides; and

means for displaying upon the display the set of menu selections in a menu positioned in the proximity of a graphical representation of the selected computer resource. 35. A computer-readable To the extent the preamble is construed to be limiting, the Droid 2 storage medium for use in a includes a computer-readable storage medium for use in a 7

133 Patent computer system having a display device, a selected object having a visual representation stored in storage, and a container object in which the selected object is contained, said medium holding instructions for:

Exemplary Motorola Devices computer system having a display device, a selected object having a visual representation stored in storage, and a container object in which the selected object is contained. Figure 35-1 shows the Motorola Droid 2.

Touchscreen

Keyboard

Figure 35-1. See also Ex. A. This device is a handheld computer and accordingly includes a CPU, a computer-readable storage medium, and a display. Figure 35-2 shows an exemplary Inbox email folder in the Droid 2's email application.

Figure 35-2

133 Patent adding a menu selection, related to the class of objects to which the selected object belongs, to a menu;

Exemplary Motorola Devices The Droid 2 adds a menu selection, related to the class of objects to which the selected object belongs, to a menu. For instance, the Droid 2 adds menu selections in response to receiving a click that lasts longer than a prescribed period of timei.e., a "long-click"or in response to the user selecting the message by navigating to it using the arrow keys and pressing and holding the Enter key on the keyboard for more than a prescribed period of time. These menu selection items are related to classes of objects to which the selected objects belong. For instance, "[t]he Android system provides two types of menus you can use to provide functionality or navigation." Ex. C. One of the menus that the accused devices generate is a context menu: "This is a floating list of menu items that may appear when you perform a long-press on a View (such as a list item)." Ex. B. "The Android context menu is similar, in concept, to the menu revealed with a 'right-click' on a PC. When a view is registered to a context menu, performing a 'long-press' (press and hold for about two seconds) on the object will reveal a floating menu that provides functions relating to that item." Id. The Menu Design Guidelines describe one example of adding menu selections relating to classes of objects to which computer resources belong: "Text links and text fields in the content both have systemprovided operations that are common across all applications: operations such as 'Select all', 'Select text', 'Copy all', and 'Add to dictionary'. If the text field is editable, it also has other operations, such as 'Cut all' and 'Input Method', and if text is also on the clipboard, it has 'Paste'. The system automatically inserts the appropriate menu items into the Context menu of text links and text fields, as shown in the following screenshot." Ex. C. Figure 35-3 shows an exemplary context menu. The accused Motorola devices generate this menu when the user performs a long click on an email message that has been read or in response to the user selecting such a message by navigating to it using the arrow keys and pressing and holding the Enter key on the

133 Patent

Exemplary Motorola Devices keyboard for more than a prescribed threshold period of time.

Figure 35-3 For the context menu shown in Figure 35-3, the device retrieved a menu selection related to the class of objects: "Read messages." The corresponding menu selection is "Mark unread." The Droid 2 adds a menu selection that is associated with the container in which the selected object is stored to the menu. For instance, the Menu Design Guideline provides examples of adding menu selections for context menus associated with a container in which selected computer resources reside. For example, computer resources located in a telephone's "Contacts" container have context menu options that include "View Contact" or "Call Mobile." See Ex. C. These options are associated with the Contacts container. By way of example, the email messages shown in the Figures above are stored in a container; namely, the Inbox. The context menu shown in Figures 35-3 includes menu selections that are common to all email messages in the Inbox: Archive, Delete, etc. The Droid 2 displays the menu with the menu selections on the display device in proximity to the visual representation of the selected object. For instance, the Creating Menus Documentation describes the process of displaying context menus on the display: "Performing a 'long-press' (press and hold for about two seconds) on [an] object will reveal a floating menu that provides functions relating to that item." Ex. B. Moreover, "[t]he system automatically lays the menus out and 10

adding a menu selection that is associated with the container in which the selected object is stored to the menu; and

displaying the menu with the menu selections on the display device in proximity to the visual representation of the selected object.

133 Patent

Exemplary Motorola Devices provides standard ways for users to access them. In this sense, they are familiar and dependable ways for users to access functionality across all applications. All menus are panels that 'float' on top of the activity screen and are smaller than full screen, so that the application is still visible around its edges. This is a visual reminder that a menu is an intermediary operation that disappears once it's used." Ex. C. By way of example, as shown in Figure 35-2, the accused Motorola devices display a graphical representation of each email message in the Inbox. As shown in Figures35-3 the accused Motorola devices display the set of menu options in proximity to the graphical representation of the email messages.

11

ATTACHMENT A

MOTOROLA FOR BUSINESS

SIGN UP FOR EMAIL UPDATES

USA (Change Location)

Search

Overview

Features

Tech Specs

Owner Support

|
Like

Share
2,323 people like this.

Multimedia Station for DROID 2 by Motorola

For music, movies and more, this is the accessory you'll want to get. CHECK IT OUT

Car Mount for DROID 2 by Motorola

This dock triggers an app that allows access to music, Google Maps Navigation and more. CHECK IT OUT

Owner Support
Learn how to get help for your Motorola product. FIND IT

Motorola Home > Consumer Product & Services > Mobile Phones > DROID 2 by Motorola

The Office, property of NBC Studios used under license. PrimeTime2Go is a trademark of Quickplay Inc. Google, Google Search, Google Maps, Gmail, Google Latitude, Google Talk, YouTube, Google Quick Search Box, Android, and Android Market are trademarks of Google, Inc. DROID is a trademark of Lucasfilm Ltd. and its related companies. Used under license. Airtime, data charges, and/or additional charges may apply to applications. Certain applications or features may not be available in all areas. Some listed applications may be trial versions. See your service provider for details.

ABOUT MOTOROLA CAREERS DEVELOPERS INVESTORS MEDIA CENTER PRIVACY POLICY TERMS OF USE CONTACT US

SITE FEEDBACK
2010 MOTOROLA,INC.ALL RIGHTS RESERVED

SITE MAP

ATTACHMENT B

User Interface >

Creating Menus
In this document

Menus are an important part of an application that provide a familiar interface for the user to access application functions and settings. Android offers an easy programming interface for you to provide application menus in your application. Android provides three types of application menus: Options Menu The primary menu for an Activity, which appears when the user presses the device MENU key. Within the Options Menu are two groups: Icon Menu The menu items visible at the bottom of the screen at the press of the MENU key. It supports a maximum of six menu items. These are the only menu items that support icons and the only menu items that do not support checkboxes or radio buttons.

Defining Menus Inflating a Menu Resource Creating an Options Menu Changing the menu when it opens Creating a Context Menu Creating a Submenu Other Menu Features Menu groups Checkable menu items Shortcut keys Intents for menu items

Key classes
Menu MenuItem ContextMenu SubMenu

See also
Menu Resource

Expanded Menu The vertical list of menu items exposed by the "More" menu item in the Icon Menu. When the Icon Menu is full, the expanded menu is comprised of the sixth menu item and the rest. Context Menu A floating list of menu items that appears when the user performs a long-press on a View. Submenu A floating list of menu items that the user opens by pressing a menu item in the Options Menu or a context menu. A submenu item cannot support a nested submenu.

Defining Menus
Instead of instantiating Menu objects in your application code, you should define a menu and all its items in an XML menu resource, then inflate the menu resource (load it as a programmable object) in your application code. Defining your menus in XML is a good practice because it separates your interface design from your application code (the same as when you define your Activity layout). To define a menu, create an XML file inside your project's res/menu/ directory and build the menu with the following elements: <menu> Creates a Menu, which is a container for menu items. It must be the root node and holds one or more of the following elements. You can also nest this element in an <item> to create a submenu. <item>

Creates a MenuItem, which represents a single item in a menu. <group> An optional, invisible container for <item> elements. It allows you to categorize menu items so they share properties such as active state and visibility. See Menu groups. For example, here is a file in res/menu/ named game_menu.xml: <?xml version="1.0" encoding="utf-8"?> <menu xmlns:android="http://schemas.android.com/apk/res/android"> <item android:id="@+id/new_game" android:icon="@drawable/ic_new_game" android:title="@string/new_game" /> <item android:id="@+id/quit" android:icon="@drawable/ic_quit" android:title="@string/quit" /> </menu> This example defines a menu with two menu items. Each item includes the attributes: android:id A resource ID that's unique to the item so that the application can recognize the item when the user selects it. android:icon A drawable resource that is the icon visible to the user. android:title A string resource that is the title visible to the user. For more about the XML syntax and attributes for a menu resource, see the Menu Resource reference.

Inflating a Menu Resource

You can inflate your menu resource (convert the XML resource into a programmable object) using MenuInflater.inflate(). For example, the following code inflates the game_menu.xml file defined above during the onCreateOptionsMenu() callback method, to be used for the Options Menu: @Override public boolean onCreateOptionsMenu(Menu menu) { MenuInflater inflater = getMenuInflater(); inflater.inflate(R.menu.game_menu, menu); return true; } The getMenuInflater() method returns a MenuInflater for the Activity. With this object, you can call inflate(), which inflates a menu resource into a Menu object. In this example, the menu resource defined by game_menu.xml is inflated into the Menu that was passed into onCreateOptionsMenu(). (This callback method for creating an option menu is discussed more in the next section.)

Creating an Options Menu

The Options Menu is where you should include basic application functions and necessary navigation items (for example, a button to open application settings). The user can open the Options Menu with the device MENU key. Figure 1 shows a screenshot of an Options Menu.

When opened, the first visible portion of the Options Menu is called the Icon Menu. It holds the first six menu items. If you add more than six items to the Options Menu, Android places the sixth item and those after it into the Expanded Menu, which the user can open with the "More" menu item. When the user opens the Options Menu for the first time, Android calls your Activity's onCreateOptionsMenu() method. Override this method in your Activity and populate the Menu that is passed into the method. Populate the Menu by inflating a menu resource as described in Inflating a Menu Resource. (You can also populate the menu in code, using add() to add menu items.) When the user selects a menu item from the Options Menu, the system calls your Activity's onOptionsItemSelected() method. This method passes the MenuItem that the user selected. You can identify the menu item by calling getItemId(), which returns the unique ID for the menu item (defined by the android:id attribute in the menu resource or with an integer passed to the add() method). You can match this ID against known menu items and perform the appropriate action. For example: @Override public boolean onOptionsItemSelected(MenuItem item) { // Handle item selection switch (item.getItemId()) { case R.id.new_game: newGame(); return true; case R.id.quit: quit(); return true; default: return super.onOptionsItemSelected(item); } } Figure 1. Screenshot of an Options Menu.

In this example, getItemId() queries the ID for the selected menu item and the switch statement compares the ID against the resource IDs that were assigned to menu items in the XML resource. When a switch case successfully handles the item, it returns "true" to indicate that the item selection was handled. Otherwise, the default statement passes the menu item to the super class in case it can handle the item selected. (If you've directly extended the Activity class, then the super class returns "false", but it's a good practice to pass unhandled menu items to the super class instead of directly returning "false".) Tip: If your application contains multiple activities and some of them provide the same Options Menu, consider creating an Activity that implements nothing except the onCreateOptionsMenu() and onOptionsItemSelected() methods. Then extend this class for each Activity that should share the same Options Menu. This way, you have to manage only one set of code for handling menu actions and each decendent class inherits the menu behaviors. If you want to add menu items to one of your decendent activities, override onCreateOptionsMenu() in that Activity. Call super.onCreateOptionsMenu(menu) so the original menu items are created, then add new menu items with menu.add(). You can also override the super class's behavior for individual menu items.

Changing the menu when it opens

The onCreateOptionsMenu() method is called only the first time the Options Menu is opened. The system keeps and re-uses the Menu you define in this method until your Activity is destroyed. If you want to change the Options Menu each time it opens, you must override the onPrepareOptionsMenu() method. This passes you the Menu object as it currently exists. This is useful if you'd like to remove, add, disable, or enable menu items depending on the current state of

your application. Note: You should never change items in the Options Menu based on the View currently in focus. When in touch mode (when the user is not using a trackball or d-pad), Views cannot take focus, so you should never use focus as the basis for modifying items in the Options Menu. If you want to provide menu items that are context-sensitive to a View, use a Context Menu.

Creating a Context Menu

A context menu is conceptually similar to the menu displayed when the user performs a "right-click" on a PC. You should use a context menu to provide the user access to actions that pertain to a specific item in the user interface. On Android, a context menu is displayed when the user performs a "long press" (press and hold) on an item. You can create a context menu for any View, though context menus are most often used for items in a ListView. When the user performs a long-press on an item in a ListView and the list is registered to provide a context menu, the list item signals to the user that a context menu is available by animating its background colorit transitions from orange to white before opening the context menu. (The Contacts application demonstrates this feature.) In order for a View to provide a context menu, you must "register" the view for a context menu. Call registerForContextMenu() and pass it the View you want to give a context menu. When this View then receives a long-press, it displays a context menu. To define the context menu's appearance and behavior, override your Activity's context menu callback methods, onCreateContextMenu() and onContextItemSelected ().
Register a ListView If your Activity uses a ListView and you want all list items to provide a context menu, register all items for a context menu by passing the ListView to registerForContextMenu(). For example, if you're using a ListActivity, register all list items like this: registerForContextMenu(getListView());

For example, here's an onCreateContextMenu() that uses the context_menu.xml menu resource: @Override public void onCreateContextMenu(ContextMenu menu, View v, ContextMenuInfo menuInfo) { super.onCreateContextMenu(menu, v, menuInfo); MenuInflater inflater = getMenuInflater(); inflater.inflate(R.menu.context_menu, menu); } MenuInflater is used to inflate the context menu from a menu resource. (You can also use add() to add menu items.) The callback method parameters include the View that the user selected and a ContextMenu.ContextMenuInfo object that provides additional information about the item selected. You might use these parameters to determine which context menu should be created, but in this example, all context menus for the Activity are the same. Then when the user selects an item from the context menu, the system calls onContextItemSelected(). Here is an example of how you can handle selected items: @Override public boolean onContextItemSelected(MenuItem item) { AdapterContextMenuInfo info = (AdapterContextMenuInfo) item.getMenuInfo(); switch (item.getItemId()) { case R.id.edit: editNote(info.id); return true; case R.id.delete: deleteNote(info.id); return true; default:

return super.onContextItemSelected(item); } } The structure of this code is similar to the example for Creating an Options Menu, in which getItemId() queries the ID for the selected menu item and a switch statement matches the item to the IDs that are defined in the menu resource. And like the options menu example, the default statement calls the super class in case it can handle menu items not handled here, if necessary. In this example, the selected item is an item from a ListView. To perform an action on the selected item, the application needs to know the list ID for the selected item (it's position in the ListView). To get the ID, the application calls getMenuInfo(), which returns a AdapterView.AdapterContextMenuInfo object that includes the list ID for the selected item in the id field. The local methods editNote() and deleteNote() methods accept this list ID to perform an action on the data specified by the list ID. Note: Items in a context menu do not support icons or shortcut keys.

Creating Submenus
A submenu is a menu that the user can open by selecting an item in another menu. You can add a submenu to any menu (except a submenu). Submenus are useful when your application has a lot of functions that can be organized into topics, like items in a PC application's menu bar (File, Edit, View, etc.). When creating your menu resource, you can create a submenu by adding a <menu> element as the child of an <item>. For example: <?xml version="1.0" encoding="utf-8"?> <menu xmlns:android="http://schemas.android.com/apk/res/android"> <item android:id="@+id/file" android:icon="@drawable/file" android:title="@string/file" > <!-- "file" submenu --> <menu"> <item android:id="@+id/new" android:title="@string/new" /> <item android:id="@+id/open" android:title="@string/open" /> </menu> </item> </menu> When the user selects an item from a submenu, the parent menu's respective on-item-selected callback method receives the event. For instance, if the above menu is applied as an Options Menu, then the onOptionsItemSelected() method is called when a submenu item is selected. You can also use addSubMenu() to dynamically add a SubMenu to an existing Menu. This returns the new SubMenu object, to which you can add submenu items, using add()

Other Menu Features

Here are some other features that you can apply to most menu items.

Menu groups
A menu group is a collection of menu items that share certain traits. With a group, you can:

Show or hide all items with setGroupVisible() Enable or disable all items with setGroupEnabled() Specify whether all items are checkable with setGroupCheckable()

You can create a group by nesting <item> elements inside a <group> element in your menu resource or by specifying a group ID with the the add() method. Here's an example menu resource that includes a group: <?xml version="1.0" encoding="utf-8"?> <menu xmlns:android="http://schemas.android.com/apk/res/android"> <item android:id="@+id/item1" android:icon="@drawable/item1" android:title="@string/item1" /> <!-- menu group --> <group android:id="@+id/group1"> <item android:id="@+id/groupItem1" android:title="@string/groupItem1" /> <item android:id="@+id/groupItem2" android:title="@string/groupItem2" /> </group> </menu> The items that are in the group appear the same as the first item that is not in a groupall three items in the menu are siblings. However, you can modify the traits of the two items in the group by referencing the group ID and using the methods listed above.

Checkable menu items

A menu can be useful as an interface for turning options on and off, using a checkbox for stand-alone options, or radio buttons for groups of mutually exclusive options. Figure 2 shows a submenu with items that are checkable with radio buttons. Note: Menu items in the Icon Menu (from the Options Menu) cannot display a checkbox or radio button. If you choose to make items in the Icon Menu checkable, you must manually indicate the checked state by swapping the icon and/or text each time the state changes. You can define the checkable behavior for individual menu items using the android:checkable attribute in the <item> element, or for an entire group with the android:checkableBehavior attribute in the <group> element. For example, all items in this menu group are checkable with a radio button: <?xml version="1.0" encoding="utf-8"?> <menu xmlns:android="http://schemas.android.com/apk/res/androi d"> <group android:checkableBehavior="single"> <item android:id="@+id/red" android:title="@string/red" /> <item android:id="@+id/blue" android:title="@string/blue" /> </group> </menu> The android:checkableBehavior attribute accepts either: single Only one item from the group can be checked (radio buttons)

Figure 2. Screenshot of checkable menu items

all All items can be checked (checkboxes) none No items are checkable You can apply a default checked state to an item using the android:checked attribute in the <item> element and change it in code with the setChecked() method. When a checkable item is selected, the system calls your respective item-selected callback method (such as onOptionsItemSelected()). It is here that you must set the state of the checkbox, because a checkbox or radio button does not change its state automatically. You can query the current state of the item (as it was before the user selected it) with isChecked() and then set the checked state with setChecked(). For example: @Override public boolean onOptionsItemSelected(MenuItem item) { switch (item.getItemId()) { case R.id.vibrate: case R.id.dont_vibrate: if (item.isChecked()) item.setChecked(false); else item.setChecked(true); return true; default: return super.onOptionsItemSelected(item); } } If you don't set the checked state this way, then the visible state of the item (the checkbox or radio button) will not change when the user selects it. When you do set the state, the Activity preserves the checked state of the item so that when the user opens the menu later, the checked state that you set is visible. Note: Checkable menu items are intended to be used only on a per-session basis and not saved after the application is destroyed. If you have application settings that you would like to save for the user, you should store the data using Shared Preferences.

Shortcut keys
You can add quick-access shortcut keys using letters and/or numbers to menu items with the android:alphabeticShortcut and android:numericShortcut attributes in the <item> element. You can also use the methods setAlphabeticShortcut(char) and setNumericShortcut(char). Shortcut keys are not case sensitive. For example, if you apply the "s" character as an alphabetic shortcut to a "save" menu item, then when the menu is open (or while the user holds the MENU key) and the user presses the "s" key, the "save" menu item is selected. This shortcut key is displayed as a tip in the menu item, below the menu item name (except for items in the Icon Menu, which are displayed only if the user holds the MENU key). Note: Shortcut keys for menu items only work on devices with a hardware keyboard. Shortcuts cannot be added to items in a Context Menu.

Intents for menu items

Sometimes you'll want a menu item to launch an Activity using an Intent (whether it's an Actvitity in your application or another application). When you know the Intent you want to use and have a specific menu item that should initiate the Intent, you can execute the Intent with startActivity() during the appropriate on-item-selected callback method (such as the onOptionsItemSelected() callback). However, if you are not certain that the user's device contains an application that handles the Intent, then adding a menu

item that executes the Intent can result in a non-functioning menu item, because the Intent might not resolve to an Activity that accepts it. To solve this, Android lets you dynamically add menu items to your menu when Android finds activities on the device that handle your Intent. If you're not familiar with creating Intents, read the Intents and Intent Filters.

Dynamically adding Intents

When you don't know if the user's device has an application that handles a specific Intent, you can define the Intent and let Android search the device for activities that accept the Intent. When it finds activies that handle the Intent, it adds a menu item for each one to your menu and attaches the appropriate Intent to open the Activity when the user selects it. To add menu items based on available activities that accept an Intent: 1. Define an Intent with the category CATEGORY_ALTERNATIVE and/or CATEGORY_SELECTED_ALTERNATIVE, plus any other requirements. 2. Call Menu.addIntentOptions(). Android then searches for any applications that can perform the Intent and adds them to your menu. If there are no applications installed that satisfy the Intent, then no menu items are added. Note: CATEGORY_SELECTED_ALTERNATIVE is used to handle the currently selected element on the screen. So, it should only be used when creating a Menu in onCreateContextMenu(). For example: @Override public boolean onCreateOptionsMenu(Menu menu){ super.onCreateOptionsMenu(menu); // Create an Intent that describes the requirements to fulfill, to be included // in our menu. The offering app must include a category value of Intent.CATEGORY_ALTERNATIVE. Intent intent = new Intent(null, dataUri); intent.addCategory(Intent.CATEGORY_ALTERNATIVE); // Search and populate the menu with acceptable offering applications. menu.addIntentOptions( R.id.intent_group, // Menu group to which new items will be added 0, // Unique item ID (none) 0, // Order for the items (none) this.getComponentName(), // The current Activity name null, // Specific items to place first (none) intent, // Intent created above that describes our requirements // Additional flags to control items (none) 0, null); // Array of MenuItems that correlate to specific items (none) return true; } For each Activity found that provides an Intent filter matching the Intent defined, a menu item is added, using the value in the Intent filter's android:label as the menu item title and the application icon as the menu item icon. The addIntentOptions() method returns the number of menu items added. Note: When you call addIntentOptions(), it overrides any and all menu items by the menu group specified in the first argument.

Allowing your Activity to be added to menus

You can also offer the services of your Activity to other applications, so your application can be included in the menu of others (reverse the roles described above). To be included in other application menus, you need to define an Intent filter as usual, but be sure to include the CATEGORY_ALTERNATIVE and/or CATEGORY_SELECTED_ALTERNATIVE values for the Intent filter category. For example:

<intent-filter label="Resize Image"> ... <category android:name="android.intent.category.ALTERNATIVE" /> <category android:name="android.intent.category.SELECTED_ALTERNATIVE" /> ... </intent-filter> Read more about writing Intent filters in the Intents and Intent Filters document. For a sample application using this technique, see the Note Pad sample code. Back to User Interface
Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License. Android 2.2 r1 - 08 Sep 2010 18:21 Site Terms of Service - Privacy Policy - Brand Guidelines

Go to top

ATTACHMENT C

Menu Design Guidelines

Menu design quickview

A menu holds a set of commands (user actions) that are normally hidden, and are accessible by a button, key, or gesture. Menu commands provide a means for performing

An Options menu is for any commands that are global to the current activity. A Context menu is for any commands that apply to the current selection. Place the most frequently used operations first. Put only the most important commands fixed on the screen. 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.

In this document
Tour of the Menus Options Menu Context Menu Comparison of Options & Context Menus Commands Fixed in an Activity Screen Guidelines Separate specific from global commands Place most frequently used first Don't put commands only in a Context menu First command in Context menu should be most intuitive Selecting an item should perform most intuitive operation A Context menu should identify the selected item Put only most important commands fixed on the screen Use short names in Options icon menu A dialog should not have Options menu If no Options menu, don't display message Dim or hide menu items not available

See also
Touch mode Activity and Task Design

operations and for navigating to other parts of your application or other applications. Menus are useful for freeing screen space, as an alternative to placing functionality and navigation, in buttons or other user controls in the content area of your application. The Android system provides two types of menus you can use to provide functionality or navigation. Between them, you should be able to organize the functionality and navigation for your application. Briefly:

The Options menu contains 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 labeled MENU. The Context menu contains 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. All but the simplest applications have menus. The system automatically lays the menus out and provides standard ways for users to access them. In this sense, they are familiar and dependable ways for users to access functionality across all applications. All menus are panels that "float" on top of the activity screen and are smaller than full screen, so that the application is still visible around its edges. This is a visual reminder that a menu is an intermediary operation that disappears once it's used. Let's start out with a quick tour of the menus.

Tour of the Menus

Note: Your menus and screens might not look like those shown in this document; they may vary from one version of Android or device to another.

Options Menu
The Options menu contains commands that apply globally across the current activity, or can start another activity. They do not apply to a selected item in the content (a Context menu does that). On most devices, a user presses the MENU button to access the Options menu, as shown in the screenshot below. To close the menu, the user presses MENU again, or presses the BACK button. In fact, to cancel out of any menu, press the BACK button. (Pressing the MENU button or touching outside the menu also works.) Note that how to invoke this menu may be different on different devices. Each activity activity has its own set of operations and therefore its own Options menu. An application with multiple activities would have a different Options menu for each activity. For example, in the message list view of an email program, the Options menu might let you search the messages, compose a new message, refresh the list, or change the email settings. The compose view of an email program would have a different Options menu, such as adding a CC field, attaching a file, or discarding the message. In order to handle a large number of menu items, the Options menu progressively discloses them in two steps:

Options icon menu - The first press of the MENU button displays a non-scrollable grid of icons at the bottom of the screen. (On the G1 phone, up to 6 buttons typically appear.) Options expanded menu - If the activity has more menu items than will fit on the icon menu, then the last icon is labeled "More" selecting it displays a list that can contain any number of menu items and will scroll as necessary.

On some versions of Android, the user can display keyboard shortcuts in the icon menu by long pressing the MENU button the text in the icon menu alternates between the command names and their keyboard shortcuts (if any).

Context Menu
A Context menu is similar to a right-click context menu in a desktop operating system. It is normally a shortcut that duplicates commands found elsewhere. A user can touch & hold on content on the screen to access a Context menu (if one exists), as shown in the screenshot below. A Context menu is a list of menu items (commands) that can operate on the selected content. The command can either be part of the current activity, or the system can pass the selected content along to an operation in another activity (by way of an intent). For example, in an email message list, a user can touch & hold on an email message to open a Context menu containing commands to read, archive, or delete the message. A user can also touch & hold a location on the screen to access a Context menu. An example is when the user does touch & hold on a blank spot on the Home screen, a Context menu appears; selecting an item from that menu inserts an icon at that location.

Context Menu is a Shortcut

In the above example, if the user performs touch & hold on the contact "Obi Wan Kenobi", a Context menu opens. The commands provided in this Context menu are the complete set of actions that can be performed on this contact. A normal touch on an item in the content activates the most intuitive command for that selection in this case, "View contact". We recommend that the most intuitive command also be listed as the first item in the Context menu. In this example, selecting the contact "Obi Wan Kenobi" runs the same command "View contact" that is listed at the top of the Context menu. Also note, as shown in the following screenshot, the Context menu and the next screen both hold the same complete set of commands that can be performed on this contact. The Context menu displays the commands in a list, while the "View contact" activity splits them into various items in the Options menu, icon buttons and list items. Because of this duplication, using the Context menu is considered a shortcut for going to the next screen and performing the operation there. Context menus are less discoverable than either buttons fixed on-screen or the Options menu. Many users never discover or use Context menus. It is for this reason that, for the most part, any command on a Context menu should also appear on the most intuitive operation's screen. As the next section explains, text operations, such as "Select text" might appear only on a Context menu. Also, rich applications, such as browsers, which themselves can contain web applications, may have commands on Context menus that are not available elsewhere.

Text Commands in Context Menu

Text links and text fields in the content both have system-provided operations that are common across all applications: operations such as "Select all", "Select text", "Copy all", and "Add to dictionary". If the text field is editable, it also has other operations, such as "Cut all" and "Input Method", and if text is also on the clipboard, it has "Paste". The system automatically inserts the appropriate menu items into the Context menu of text links and text fields, as shown in the following screenshot.

Comparison of Options and Context Menus

An Options menu holds commands that are global to the activity while a Context menu holds commands that apply only to an item in the content. As shown in these diagrams, the user navigates to the menu, then touches a menu item to perform an action or open a dialog.

For more technical information on menus, see Creating Menus.

Commands Fixed in an Activity Screen

Commands can also be fixed directly on screen, typically in text buttons, graphic buttons, or list items. This placement is by far the most discoverable location for commands a user can immediately see the command without having to first press a button. This increased visibility needs to be weighed against the space such user controls take up, or the sense that they might clutter the visual design.

Guidelines
Selecting the right kind of menu to present, and using menus consistently, are critical factors in good application design. The following guidelines should assist user experience designers and application developers toward this end.

Separate selection-specific commands from global commands

Put any commands that are global to the current activity in the Options menu or place them fixed in an activity screen; put commands that apply to the current selection in the Context menu. (In any case, the command could either run as part of this activity or start another activity.) You can determine in which menu to place a command by what it operates on: If the command acts on selected content (or a particular location) on the screen, put the command in the Context menu for that content. If the command acts on no specific content or location, put it in the Options menu. This separation of commands is enforced by the system in the following way. When you press the MENU button to display the Options menu, the selected content becomes unselected, and so cannot be operated on. For an explanation of why the content becomes unselected, see the article on Touch mode. An example of a selection-specific Context menu is when a user performs a touch & hold on a person's name in a list view of a contacts application. The Context menu would typically contain commands "View contact", "Call contact", and "Edit contact".

Place the most frequently used operations first

Because of limited screen height, some menus may be scrollable, so it's important to place the most important commands so they can be viewed without scrolling. In the case of the Options menu, place the most frequently used operation on its icon menu; the user will have to select "More" to see the rest. It's also useful to place similar commands in the same location for example, the Search icon might always be the first icon in the Options menu across several activities that offer search.

In a Context menu, the most intuitive command should be first, followed by commands in order of decreasing use, with the least used command at the bottom.

Don't put commands only in a Context menu

If a user can fully access your application without using Context menus, then it's designed properly! In general, if part of your application is inaccessible without using Context menus, then you need to duplicate those commands elsewhere. Before opening a Context menu, it has no visual representation that identifies its presence (whereas the Options menu has the MENU button), and so is not particularly discoverable. Therefore, in general, a Context menu should duplicate commands found in the corresponding activity screen. For example, while it's useful to let the user call a phone number from a Context menu invoked by touch & hold on a name in a list of contacts, that operation should also be available by the user touching the phone number itself when viewing contact details. See shortcut for an illustration of this example.

The first command in a Context menu should be the selection's most intuitive command
As described under shortcut, touching on an item in the content should activate the same command as touching the first item in the Context menu. Both cases should be the most intuitive operation for that item.

Selecting an item in the content should perform the most intuitive operation
In your application, when the user touches any actionable text (such as a link or list item) or image (such as a photo icon), execute the operation most likely to be desired by the user. Some examples of primary operations:

Selecting an image executes "View image" Selecting a media icon or filename executes "Play" Selecting a URL link executes "Open link" Selecting an address executes "Go to address" (in a maps application)

Note that selecting the same item in different contexts might invoke different operations:

In a contact application, selecting a contact executes "View details" In an IM application, selecting a contact executes "Start chat" In an Email application, when adding a recipient to the "To" field through the contact book, selecting a contact executes "Add to recipient list"

A Context menu should identify the selected item

When a user does touch & hold on an item, the Context menu should contain the name of the selected item. Therefore, when creating a Context menu, be sure to include a title and the name of the selected item so that it's clear to the user what the context is. For example, if a user selects a contact "Joan of Arc", put that name in the title of the Context menu (using setHeaderTitle). Likewise, a command to edit the contact should be called "Edit contact", not just "Edit".

Put only the most important commands fixed on the screen

By putting commands in menus, you free up the screen to hold more content. On the other hand, fixing commands in the content area of an activity makes them more prominent and easy to use. Here are a number of important reasons to place commands fixed on the activity screen:

To give a command the highest prominence, ensuring the command is obvious and won't be overlooked. Example: A "Buy" button in a store application.

When quick access to the command is important and going to the menu would be tedious or slow. Example: Next/Previous buttons or Zoom In/Out buttons in an image viewing application. When in the middle of an operation that needs to be completed. Example: Save/Discard buttons in an image crop activity. Dialogs and wizards. Example: OK/Cancel buttons For direct manipulation. Example: Dragging an icon in the Home screen to the trash

Use short names in the Options icon menu

If a text label in the Options icon menu is too long, the system truncates it in the middle. Thus, "Create Notification" is truncated to something like "Createication". You have no control over this truncation, so the best bet is to keep the text short. In some versions of Android, when the icon is highlighted by a navigation key (such as a trackball), the entire descriptive text may be shown as a marquee, where the words are readable as they scroll by.

A dialog should not have an Options menu

When a dialog is displayed, pressing the MENU button should do nothing. This also holds true for activities that look like dialogs. A dialog box is recognizable by being smaller than full-screen, having zero to three buttons, is non-scrollable, and possibly a list of selectable items that can include checkboxes or radio buttons. The rationale behind not having a menu is that when a dialog is displayed, the user is in the middle of a procedure and should not be allowed to start a new global task (which is what the Option menu provides).

If an activity has no Options menu, do not display a message

When the user presses the MENU button, if there is no Options menu, the system currently does nothing. We recommend you do not perform any action (such as displaying a message). It's a better user experience for this behavior to be consistent across applications.

Dim or hide menu items that are not available in the current context
Sometimes a menu item's action cannot be performed for example, the "Forward" button in a browser cannot work until after the "Back" button has been pressed. We recommend:

In Options menu - disable the menu item, which dims the text and icon, turning it gray. This applies to menu items in both the icon menu and the "More" menu. It would be disorienting for the icon menu to change from 6 items to 5 items, and we treat the "More" menu the same way. In Context menu - hide the menu item. This makes the menu shorter so the user sees only available choices (which also reduces any scrolling). Go to top

Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License. Android 2.2 r1 - 08 Sep 2010 18:21 Site Terms of Service - Privacy Policy - Brand Guidelines