Going a la Carte with Your Menu Going a la Carte with Your Menu

239

Chapter 10: Going a la Carte with Your Menu

➝ 4 This is the ID for the menu_delete button in the list_menu_ item_longpress.xml file. If this menu option is selected, the following code would perform some action based on that deter- mination. Nothing is happening in this code block in this chapter, but in Chapter 12, I delete the task from the SQLite database. You can add many different context menu items to the list_menu_item_ longpress.xml file and switch between them in the onContextMenu- ItemSelected method call — each performing a different action. 240 Part III: Creating a Feature-Rich Application Chapter 11 Handling User Input In This Chapter ▶ Working with EditText widgets ▶ Creating date and time pickers ▶ Setting up alert dialog boxes ▶ Validating user input I t’s rare that you find an application that does not allow you to interact with the user interface via input. Be it text, date pickers, time pickers, or any other input mechanism such as radio buttons or check boxes, users need to interact with your application in one way or another. Although the input mechanism may provide a way for users to interact with your application, unfortunately they won’t be chit-chatting and spurring up small talk with you. The generalization of input also refers to buttons, screen dragging, menus, long pressing, and various other options. In this chapter, I focus solely on user input in the form of free-form text, datetimes, and alerts. Creating the User Input Interface The most common input type is free-form text — known as an EditText widget. In other programming platforms, this is known as a text box. With an EditText widget, you can provide an on-screen keyboard or the user can elect to use the physical keyboard if the device provides one to enter input. Creating an EditText widget In Chapter 9, I create a view layout XML file with the name of reminder_ edit.xml that contains the following code: EditText android:id=”+idtitle” android:layout_width=”fill_parent” android:layout_height=”wrap_content” 242 Part III: Creating a Feature-Rich Application This snippet of code defines the text input for the title of the task. The snippet creates an input on the screen so that the user can type into it. The EditText widget spans the entire width of the screen and only takes up as much room as it needs in regard to height. When selected, Android automatically opens the on-screen keyboard to allow the user to enter some input on the screen. The previous example is a very minimalistic approach as compared to the following EditText example, which is also created in the reminder_edit.xml layout file: EditText android:id=”+idbody” android:layout_width=”fill_parent” android:layout_height=”wrap_content” android:minLines=”5” android:scrollbars=”vertical” android:gravity=”top” Here, I am creating the body description text for the task. The layout width and height are the same as the previous EditText widget — the EditText view spanning the width of the screen. The difference in this EditText definition is outlined in the following three properties: ✓ minLines: This property specifies how tall the EditText view should be. The EditText view is a subclass of the TextView object; therefore, they share the same property. Here I am specifying that the EditText object on the screen be at least five lines tall. This is so that the view resembles a text input that is for long messages. Juxtapose this against the body portion of any e-mail client, and you can see that they’re very much the same — the body is much larger than the subject. In this case, the body is much larger than the title. ✓ scrollbars: This property defines which scroll bars should be present when the text overflows the available input real estate. In this instance, I am specifying vertical to show scroll bars on the side of the EditText view. ✓ gravity: By default, when the user places focus into an EditText field, the text aligns to the middle of the view, as shown in Figure 11-1. However, this is not what users would expect when they work with a multiline input mechanism. The user normally expects the input to have the cursor placed at the top of the EditText view. To do this, you must set the gravity of the EditText view to “top.” This forces the text to gravitate to the top of the EditText input. 243

Chapter 11: Handling User Input

Figure 11-1: An Edit- Text view without the gravity set. Displaying an on-screen keyboard The EditText view is very versatile and can be configured many ways. The EditText view is responsible for how the on-screen keyboard is displayed. Because some devices do not have a physical keyboard, an on-screen key- board must be present to interact with the input mechanisms. One of the properties that the EditText view provides is a way to manipulate the visual aspect of the on-screen keyboard. Why would you need to adjust the on-screen keyboard? It’s simple: Different EditText input types might need different keys. For example, if the EditText is a phone number, the on-screen keyboard should display numbers only. If the EditText value is an e-mail address, the on-screen keyboard should display common e-mail style attributes — such as an at symbol . Remember that you have various ways to configure the on-screen keyboard that, if done properly, can increase the usability of your application.