The UI design determines the usability of your application, which will ultimately determine its success and even its profitability if you are selling it. We’ll build on what we learned in Chapter 6 as UI elements in Android are View classes (widgets) and are grouped together using ViewGroup classes (layout containers).

A standard UI is composed of a number of familiar components that can be used by your application’s users to control their user experience (often called the UX). These UI elements include items such as buttons, check boxes, radio buttons, menus, text fields, dialog boxes, progress bars, system alerts, and similar screen-based elements that are available to us under Android as widgets as we learned in Chapter 6.

This chapter covers how to use several of the most important Android widgets for UI design. First, we’ll cover adding image buttons, text, and images to your UI. Then you’ll learn about the different types of menus available. Finally, we’ll cover displaying dialogs, including alerts, which carry messages to your application user. There’s a lot of cool stuff to cover, so let’s get started.

Using Android UI Elements (Widgets)

One of the foundational areas of user interface (UI) design is creating and placing the functional elements of the design that allow your user to seamlessly interface with your application. These elements include buttons, text fields, check boxes, radio buttons, scrollable lists, and the like. We can’t cover all of these in one chapter, but we can cover some of the more useful and visually impressive UI elements, just in case you need to make your apps stand apart from the crowd!

One of the most impressive types of user interface elements is the image button, which is an image that is a button itself or an icon on a button that visually represents what that button will do. In this next section we will learn how to combine an Android ImageButton widget along with a TextView widget and an ImageView widget to show how these Android View Classes can be implemented to add some graphics-intensive UI elements to your layout containers that we learned about in Chapter 6. This will provide a good foundation for then learning more about using graphics in Android in Chapter 8 which covers graphics design in Android.

Android has all of the standard UI elements already coded and ready to use in a single package called android.widget. Here, we’ll explore how to add an image button, text area, and image to your app’s UI.

<selector xmlns:android="http://schemas.android.com/apk/res/android ">
        <item android:state_pressed="true"
                android:drawable="@drawable/button1_pressed" />
        <item android:state_focused="true"
                android:drawable="@drawable/button1_focused" />
        <item android:drawable="@drawable/button1_normal" />
</selector>

<selector xmlns:android="http://schemas.android.com/apk/res/android ">
        <item android:state_pressed="true"
                android:drawable="@drawable/button1_pressed" />
        <item android:state_focused="true"
                android:drawable="@drawable/button1_focused" />
        <item android:drawable="@drawable/button1_normal" />
</selector>

<ImageButton android:id="@+id/button_one"
             android:layout_width="wrap_content"
             android:layout_height="wrap_content"
             android:src="@drawable/button1"
             android:contentDescription="@string/app_name">
</ImageButton>

Using Menus in Android

Menus in Android are quite different from the top-mounted text menus found directly beneath the title bar in PC applications. The menu function on a smartphone or tablet is a bit different for ease of use, and is sometimes an actual physical button called Menu on some Android smartphones and tablets. Other Android devices may have a soft button or touchscreen button area for menu access, or even a Menu button on a remote control for GoogleTV. Nevertheless, the menu function is an important one in Android, as well as in application development in general, so we’re covering it in detail in our UI Design chapter.

Pressing the Menu button calls up a menu, which is—you guessed it—at the bottom of the screen, instead of at the top. To make it even more user-friendly, it is composed of five large rectangular icons stacked on top of each other that can be easily touched to control your application features.

For our application, we will have our menus do things with our ImageView object, background color, and alert dialog (which we’ll add later on in this chapter), so that everything we cover in this chapter ties together nicely in one single UI_Design application.

 
<menu xmlns:android="http://schemas.android.com/apk/res/android ">
 
    <item android:id="@+id/buttonone"
          android:title="@string/showimage1"
          android:orderInCategory="100"
          android:showAsAction="never" />
 
    <item android:id="@+id/buttontwo"
          android:title="@string/showimage2"
          android:orderInCategory="200"
          android:showAsAction="never" />
 
    <item android:id="@+id/buttonthree"
          android:title="@string/showwhite"
          android:orderInCategory="300"
          android:showAsAction="never" />
 
    <item android:id="@+id/buttonfour"
          android:title="@string/showblack"
          android:orderInCategory="400"
          android:showAsAction="never" />
 
    <item android:id="@+id/buttonfive"
          android:title="@string/showalert"
          android:orderInCategory="500"
          android:showAsAction="never" />
</menu>

If you want some practice using the Remove Button, and want to be meticulous in your programming and make sure that there are no unused string variables in your strings.xml file, you can select (and Remove) the menu_settings variable that ADT created for us in the New Project sequence, as we have replaced that needed variable with five of our own, and it will thus be unreferenced in any code, and can therefore be deleted (but does not absolutely have to be). Figure 7-27 shows the strings.xml Resource Editor Pane after we have added our five menu title and two background color string variables.

Inflating the Menu Structure via Java

Now it is time to add in our Java code, which inflates our menu from the XML file into our application’s memory. The term inflating a resource describes the process of the Android operating system taking the data definition described in an XML file and populating a Java object that can be accessed and used in Java with that data. In this case, it is our activity_main.xml object from the /res/menu/ folder, which contains five menu selection buttons, their settings, and their text captions.

Here are the three lines of Java code that Eclipse so generously added to our MainActivity.java file for us during the File New Project Android Application Project creation operation:

public boolean onCreateOptionsMenu(Menu menu) {
        getMenuInflater().inflate(R.menu.activity_main, menu);
        return true;
 }

Android has a dedicated Java object for inflating XML code constructs into a Java object-based format for use with Java. This is precisely what you are seeing here inside of the onCreateOptionsMenu() method, which uses the .inflate() method and the R.menu.activity_main path to our activity_main.xml file. This method creates a MenuInflater object, which contains our inflated menu objects. The OS then “gets” the MenuInflater object and puts into memory via the getMenuInflater() method. Later on in the book we’ll learn about the Java construct that allows us to “chain” Java commands together into a single line of code, as we see here as the method() attaches itself to the .method call.

As you learned previously, the R equates to the /res/ folder of our project, so R.menu.activity_main in this case is equivalent to (inflates to, if you will) the following complete file path reference: C:/Users/Walls/workspace/UI_Design/res/menu/activity_main.xml.

ADT also added a menu-related import statement at the top of our code to tell Android which UI code we would be using. We should specify android.view.Menu that forms the Menu Class foundation for our menu and android.app.Activity for the inflation methods that access the data structures defined in the /res/menu/activity_main.xml file containing our menu UI design coded in the XML format. In this case Eclipse added the import statement for us.

import android.view.Menu;

Figure 7-28 shows the code our New Project Android Application helper added to MainActivity.java.

Note that we have implemented our application’s UI and options menu using only a half-dozen lines of Java code. We have offloaded about 80% of the menu implementation coding to XML (30 lines of XML markup relative to 6 lines of Java code, or one-fifth Java, which is 20%), and we can continue to add features and fine-tune menu options inside the XML markup as well.

Running the Application in the Android Emulator

Let’s run our code and see our menu in action. Right-click on the UI_Design folder in the Package Explorer pane, and select: Run As Android Application. After the emulator loads, and you start up your application, the emulator should look like Figure 7-29.

As you can see, the Android phone has a prominent Menu button, second from the left (bottom row) in the emulator, which we can press to display our menu at the bottom of the screen. If you click the various buttons, they will highlight in blue and close the menu, which you can re-open again with the Menu button.

So, the default way an empty menu (no code yet completing its function) works is harmless to the application. This allows us to develop and test the way our menu looks via XML before we add in the Java logic to implement the actions that will be called when each button is pressed. This allows our UI designers to work separately from our programmers without breaking the application! Next we’ll code some basic programming logic to make our menu items functional.

Making the Menu Work

Let’s add our menu item implementations now. First, we need to give our RelativeLayout an ID, so that we can find it in our Java code.

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android "
    android:id="@+id/uilayout"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >

Now, we need to implement the onOptionsItemSelected() method, where we code the choices between our different menu item selections, and write the code that defines what they do in our application, if and when they are selected. Here is the Java code for the method we will write:

public boolean onOptionsItemSelected(MenuItem item) {
    RelativeLayout bkgr = (RelativeLayout)findViewById(R.id.uilayout);
    ImageView image = (ImageView)findViewById(R.id.imageView1);
 
        switch (item.getItemId()) {
 
        case R.id.buttonone:
                        image.setImageResource(R.drawable.image1);
                        return true;
        case R.id.buttontwo:
                        image.setImageResource(R.drawable.image2);
                        return true;
        case R.id.buttonthree:
                        bkgr.setBackgroundResource(R.color.background2);
                        return true;
        case R.id.buttonfour:
                        bkgr.setBackgroundResource(R.color.background);
                        return true;
        case R.id.buttonfive:
                        // The Alert Code For Next Section Goes Here!
                        return true;
        default:
                return super.onOptionsItemSelected(item);
        }
 
    }

This code is a bit more complex than our MenuInflater() code. At its core, it implements a switch structure. The switch is a Java iteration construct that says, “In the case of this, do that, and in the case of this, do that; otherwise, as a default, do this.” This type of code construct is perfect for the main Android menu, as it usually has only five or six items. Let’s type this code block into our MainActivity.java editing pane after the routine that inflates our new menu.

Once you are finished typing the new method into your MainActivity.java class, you will notice that there are three little red X icons in the left of the Java editing pane that signify that our code has a problem. Click on the first one as shown in Figure 7-30 to get Eclipse and ADT to tell you what is wrong and to give you some solutions to the problem.

As you can see, Eclipse is telling us that we do not have the import statement that is required to run the method referenced in that line of code. Pretty Nifty! Double-click on the Import MenuItem (android.view) selection listed at the top of the pop-up, and Eclipse and ADT will write the import statement code for you. Do this for the next two warning flags as well to import the other packages (libraries) that are needed for RelativeLayouts and ImageView widget usage.

Figure 7-31 shows the MainActivity.java code in the Eclipse editor in context with our previous two code blocks once our Import statements are added and the editing area is “clean” with no errors or warnings showing. In the figure, the new code is boxed. We will cover the top import statements, then the outer onOptionsItemSelected() method, and then its inner switch statement and programming logic for each button inside of the  case statement, and what it needs to do regarding the UI (switch images, set background colors, and so on).

First are the import statements for the Android classes that we are going to use in our onOptionsItemSelected() method (see the top box in Figure 7-31):

• Because we reference MenuItem in our onOptionsItemSelected() method, we need to import android.view.MenuItem.
• Because we are going to switch image resources in our ImageView UI object, we also need to import android.widget.ImageView.
• Because we are going to change our RelativeLayout background color from black to white, we need to import android.widget.RelativeLayout as well.

Remember that importing the class libraries that we are going to use in our Java code makes sure that these classes are in memory when Eclipse needs to use them during the compilation of our Java code.

Next, let’s examine our onOptionsItemSelected() code. First, we need to create references to our RelativeLayout and ImageView objects, so that we can operate on these objects. This way, we can adjust their resource values to change the image used in the UI and the background color used when the user selects our menu buttons’ image and background color change menu options.

The first line creates a RelativeLayout object called bkgr and sets it to the RelativeLayout that is assigned the ID uilayout via the findViewById() method. The second line creates an ImageView object called image and sets it to the ImageView that is assigned the ID imageView1 in the same way. These IDs can be seen in the /res/layout/ folder’s activity_main.xml file and corresponding tab, so you can check that everything matches.

Finally, we have the Java switch statement. It starts with switch(item.getItemId, which means “Decide between the following options (each case statement) based on the ID of the MenuObject that we named item. If nothing matches, just use the default action at the bottom of the statement decision tree list.” The case statements work as follows:

• The first case statement says, “In the case of the item MenuItem with an ID of buttonone being passed into this case statement, set the image ImageView object’s image resource to the 32-bit PNG image called image1 in the /res/drawable folder, using the setImageResource() method.”
• The second case statement says, “In the case of the item MenuItem with an ID of buttontwo being passed over, set the image ImageView object’s image resource to the 32-bit PNG image called image2 in the /res/drawable folder, using the setImageResource() method.”
• The third case statement says, “In the case of the item MenuItem with an ID of buttonthree being passed over, set the bkgr RelativeLayout object’s background resource to the color resource called background in the /res/values/strings.xml resource, using the setBackgroundResource() method.”
• The fourth case statement says, “In the case of the item MenuItem with an ID of buttonfour being passed over, set the bkgr RelativeLayout object’s background resource to the color resource called background2 in the /values/strings.xml resource using the setBackgroundResource() method.”
• The fifth case is left open for our next section, and thus the button does nothing at this point.

If none of the case statements match IDs passed over to them to operate on, then the default action is called (executed), which is to pass over to the onOptionsItemSelected() method of the superclass (in this case, to do nothing).

Now let’s Run As Android Application, and make sure that our code works! Shown below is a screen shot of the Android 4.1 emulator after the menu is brought up (twice) via the Menu Button (see right side of emulator), and the Image Two option and then the black background option were selected.

Using Custom Dialog Subclasses

Five custom subclasses of the android.app.Dialog class are provided as part of the Android API:

• AlertDialog
• CharacterPickerDialog
• ProgressDialog
• DatePickerDialog
• TimePickerDialog

You can also subclass your own custom Dialog class (say, CustomDialog), so that it does exactly what you need it to do.

The general way to create a basic dialog within any given activity is via the onCreateDialog(int) method. Android uses this method to track the dialog created, which activity it belongs to, and its current state.

To display a dialog once it is created, you use the showDialog(int) method, specifying the number of the dialog you wish to display. To hide or dismiss a Dialog object, use the dismissDialog(int) method, and the Dialog object will be removed from memory and the application.

Here, we’ll take a closer look at the most often used (and the recommended) Dialog class: AlertDialog . Android provides an easy and powerful way to construct alert dialogs with many features.

Displaying an Alert Dialog

The AlertDialog class provides a lot of built-in dialog features, such as a title, user message, up to three buttons, and a list of selectable items. You can even use check boxes and radio buttons in your dialog.

The AlertDialog works its magic via a dialog builder that provides a ready-made dialog code structure for you to easily create complicated dialogs via the android.app.AlertDialog class.

As shown in the boxed areas of Figure 7-33, there are four main parts to adding our AlertDialog to our existing Android application.

First, we add the import statements for the Android utilities we are going to leverage to provide our AlertDialog object:

import android.app.AlertDialog;
import android.content.DialogInterface;

Next, we create our AlertDialog.Builder object, which we name builder. This is a new (empty and initialized) AlertDialog.Builder object.

public boolean onOptionsItemSelected(MenuItem item) {
    RelativeLayout bkgr = (RelativeLayout)findViewById(R.id.uilayout);
    final ImageView image = (ImageView)findViewById(R.id.imageView1);
    AlertDialog.Builder builder = new AlertDialog.Builder(this);

To work with the image object inside the builder dialog object that we are constructing, we need to add the keyword final to our declaration of this object variable (you’ll see why in the next step). The final keyword is used for variables, methods, and classes. A final variable cannot be given a new value after it has been assigned one (although we can alter the variable object like any other object). A final method cannot be overridden. Also, a final class cannot be extended, and is thus, in a sense, protected from further programming modifications.

The preceding code basically says, “I want to declare an object named builder that is of the type AlertDialog.Builder, and I wish to set it equal to this new AlertDialog.Builder object that I am creating here. Therefore, please instantiate an empty AlertDialog.Builder object for me to define and fill with my own custom parameters.”

After this has been declared, builder exists as an empty AlertDialog ready to fill with our own custom parameters. OK, on to the fun part, and to the third and major part of our AlertDialog definition.

Here is the code to customize our dialog:

builder.setTitle("Pick an Image!")
       .setMessage("Please Select Image One or Image Two:")
       .setCancelable(false)
       .setPositiveButton("IMAGE 1", new DialogInterface.OnClickListener()
       {
             public void onClick(DialogInterface dialog, int id) {
                   image.setImageResource(R.drawable.image1);
             }
       })
 
       .setNegativeButton("IMAGE 2", new DialogInterface.OnClickListener() {
             public void onClick(DialogInterface dialog, int id) {
                   image.setImageResource(R.drawable.image2);
             }
        });

We work with the image object, which we know can’t be reassigned a value because it is final. This is to deal with situations where the event listener is used after the onOptionsItemSelected() method has terminated. In this case, a non final image variable would not be around to take a new assignment, whereas a final variable is frozen in memory for access at all times (of course, this may never happen, but Java was built this way just to be sure).

Notice in this block of code that sets our AlertDialog parameters (I am amazed that they did not offload AlertDialog parameters to an alert_dialog.xml file) that a new concept called method chaining is used. This allows a large number of parameters to be set without the builder object being explicitly typed before each dot-notation construct.

In method chaining, the first method is attached to its object with dot notation. In our example, it looks like this:

builder.setTitle("Pick an Image!")

The follow-up methods that set the other parameters are simply .setMessage(), .setCancelable(false), and so on.

I’ve formatted the preceding code for ease of reading. But to give you a little more grip on method chaining, the first three method calls could be rewritten as follows, illustrating the method chain:

builder.setTitle("Pick an Image!").setMessage("Please Select...").setCancelable(false)

Also note that between contiguous methods, there is no semicolon at the end of these parameter setting lines of code. Semicolons are required on only the last and final method call—in this case, after .setNegativeButton() to end the builder definition. This chaining allows programmers to write denser code, or to use fewer lines of code to accomplish more tasks. Pretty cool stuff.

The code for setting the title, the message, and whether the Back button on the phone is able to cancel the dialog (in this case, it is not cancelable) is pretty straightforward here, so let’s go over what is happening inside each button.

You can have up to three buttons in an AlertDialog object. These buttons are hard coded into the Android operating system as follows:

• PositiveButton
• NeutralButton
• NegativeButton

This explains the setPositiveButton() and setNegativeButton() methods shown in the preceding code.

The convention in Android AlertDialogs is to use PositiveButton for one-button dialogs, PositiveButton and NegativeButton for two-button dialogs, and all three for three-button dialogs. The code inside the two buttons in our dialog is nearly identical, so let’s go over what is happening inside the first button, IMAGE 1.

      .setPositiveButton("IMAGE 1", new DialogInterface.OnClickListener()
      {
            public void onClick(DialogInterface dialog, int id) {
                  image.setImageResource(R.drawable.image1);
            }
      })

The setPositiveButton() method allows us to name the button IMAGE 1 and creates a new OnClickListener() implementation for the DialogInterface. Note that we declared android.content.DialogInterface in an import statement initially, and it is being used here to create a PositiveButton.

Inside the OnClickListener, we have a public method onClick(), which defines what will be done when the button is clicked. We pass onClick a dialog object of type DialogInterface and an integer ID value that represents which of the buttons was clicked or the numerical order of the button that was clicked—both of which are what OnClickListener wants to evaluate in the event the user clicks that button. Note that we will be getting into event listeners in much greater detail in Chapter 9.

Inside this onClick container is where our code goes to change our ImageView object to the appropriate image resource. Because we have already done that in the menu code, we can simply copy the image.setImageResource(R.drawable.image1) code from down in our switch construct for ButtonOne.

Finally, down inside of our switch statement, where before we had a placeholder comment, we can now display the dialog by calling the show() method of the builder object that we created earlier. This line of code could not be much simpler:

builder.show();

Whenever the fifth menu button is clicked, our dialog will be shown. We can select between the two images, which will then be set on our screen appropriately.

Now, right-click on your UI_Design folder, and select Run As Android Application to see your work. Figure 7-34 shows the dialog as it appears in the emulator after you click the SHOW ALERT button in the menu.