Using the Menu vs onscreen buttons

We have chosen to use the Menu here, in addition to the on-screen buttons. Though either (or both) can work in many scenarios, you need to consider whether the menu, which is invoked by pressing the Menu button on the device and tapping a selection (button and a tap) is appropriate for what you are doing, or whether an on-screen button (single tap) is more appropriate. Generally on-screen buttons should be tied to UI elements (a search button for a search form input, for example), and menu items should be used for screen-wide actions (submitting a form, performing an action like create, save, edit, or delete). Because all rules need an exception, if you have the screen real estate, it may be more convenient for users to have on-screen buttons for actions as well (as we have done here). The most important thing to keep in mind with these types of UI decisions is to be consistent. If you do it one way on one screen, use that same approach on other screens.

In addition to creating the menu item, we add support to react and perform an action when the item is selected. This is done in the onMenuItemSelected() event method Q, where we parse the ID of the multiple possible menu items with a case/switch statement. When the MENU_GET_REVIEWS item is determined to have been selected, we then call the handleGetReviews method G. This method puts the user's selection state in the Application object Q and sets up to call the next screen. We have moved this logic into its own method because we are using it from multiple places, from our on-screen Button and again from our MenuItem.

The Application object is used internally by Android for many purposes, and it can be extended, as we have done with RestaurantFinderApplication (which includes a few member variables in JavaBean style), to store global state information. We will reference this object again in other activities to retrieve the information we are storing here. There are several ways to pass objects back and forth between activities; using Application is one of them. You can also use public static members and Intent extras with Bundle objects. In addition, you can use the provided SQLite database, or you can implement your own ContentProvider and store data there. We will cover more about state, and data persistence in general, including all these concepts, in chapter 5. The important thing to take away here is that at this point we are using the Application object to pass state between activities.

After we store the criteria state we fire off an action in the form of an Android Intent Q. We touched on intents in chapter 1, and we will delve into them further in the next chapter, but basically we are asking another Activity to respond to the user's selection of a menu item by calling startActivity(Intent intent) G.

0 0

Post a comment