Android User Interface Development: Beginner's Guide

For our first example, we're going to write a multiple-choice question and answer Activity. We could use it for applications such as "Who wants to be a millionaire?", or "What type of a monkey are you?". This example will pose questions in order to answer a very important question: "What should I have to eat?" As the user answers the questions, this application will filter a database of food ideas. The user can exit the process at any time to view a list of suggested meals, or just wait until the application runs out of questions to ask them.

Since it's a user interface example, we'll skip building filters and recipe databases. We'll just ask our user food preference-related questions. For each question, we have a list of preset answers which the user can select from (that is, multiple-choice questions). Each answer they give will allow us to narrow the list of suitable recipes.

Before we can start writing code, we need a project structure. An Android project is made up of far more than just its Java code—there are also manifest files, resources, icons, and more. In order to keep things easy, we use the default Android toolset and project structure.

You can download the latest version of the Android SDK for your favorite operating system from http://developer.android.com. A single Android SDK may be used to develop against any number of target Android versions. You will need to follow the installation instructions on the website at http://developer.android.com/sdk/installing.html to install the latest SDK "starter package" and one or more platform targets. Most of the examples in this book will work on Android 1.5 and higher. The Android website also maintains a very useful chart where you can see what the most popular versions of Android are.

Once you have downloaded the Android SDK archive for your operating system, you'll need to install it and then download at least one Android Platform package. Open a command-line or console and complete the following steps:

The Android SDK provides a handy command-line tool named android which can be used to generate the skeleton of a new project. You'll find it under the tools directory of your Android SDK. It's capable of creating a basic directory structure and a build.xml file (for Apache Ant) to help get you started with your Android application development. You will need to make sure that the tools directory is in your executable path for this to work. Open a command-line or console.

The android tool has given us a minimal example of an Android project, basically a "Hello World" application.

While Android allows you to create a screen layout in either Java code, or by declaring the layout in an XML file, we will declare the screen layout in an XML file. This is an important decision for several reasons. The first is that, using the Android widgets in Java code requires several lines of code for each widget (a declaration/construction line, several lines invoking setters, and finally adding the widget to its parent), while a widget declared in XML takes up only one XML tag.

The second reason for keeping layouts as XML is that it's compacted into a special Android XML format when it's stored in the APK file. Therefore your application uses less space on the device, takes less time to download, and its in-memory size is also smaller since less byte code needs to be loaded. The XML is also validated by the Android resource packing tool during compilation, and so is subject to the same type safety as Java code.

The third reason XML layouts are a "good idea" is that they are subject to the same resource selection process as all the other external resources. This means that a layout can be varied based on any of the defined properties, such as language, screen orientation and size, and even the time of day. This means that you can add new variations on the same layout in the future, simply by adding new XML files, and without the need to change any of your Java code.

To kick things off we're going to be working with Android's simplest layout called: LinearLayout. Unlike Java AWT or Swing, Android layout managers are defined as specific container types. Thus a LinearLayout is much like a Panel with a built-in LayoutManager. If you've worked with GWT, you'll be quite familiar with this concept. We'll lay out the screen in a simple top-to-bottom structure (which LinearLayout is perfect for).

A widget in Android is called a View, while a container (such as LinearLayout) is a ViewGroup. We have an empty ViewGroup now, but we need to start populating it in order to build up our user interface. While it is possible to nest a ViewGroup inside another ViewGroup object, an Activity has only one root View—so a layout XML file may have only one root View.

In order to ask our user a question, you will need to add a TextView to the top of your layout. A TextView is a bit like a Label or JLabel. It's also the base class for many other Android View widgets that display text. We want it to take up all of the available horizontal space, but only enough vertical space for our question to fit. We populate the TextView with Please wait... as its default text. Later, on we will replace this with a dynamically selected question.

The code for the TextView should end up looking something like this:

<TextView android:id="@+id/question"
          android:text="Please wait..."
          android:layout_width="fill_parent"
          android:layout_height="wrap_content"/>

While posing a question to the user is all very fine and well, we need to give them some way to answer that question. We have several possibilities at our disposal: We could use a RadioGroup with a RadioButton for each possible answer, or a ListView with an item for each answer. However, to minimize the required interaction, and make things as clear as possible, we use one Button for each possible answer. However, this complicates things slightly, since you can't declare a variable number of Button objects in your layout XML file. Instead, we will declare a new LinearLayout and populate it with Button objects in the Java code.

The resulting code should look like this:

<LinearLayout android:id="@+id/answers"
              android:orientation="vertical"
              android:layout_width="fill_parent"
              android:layout_height="wrap_content"/>

What just happened?

You may have noticed that for this example, we have no content in our new LinearLayout. This may seem a little unusual, but in this case, we want to populate it with a variable number of buttons—one for each possible answer to our multiple-choice questions. However, for the next part of the example we need some simple content Button widgets in this LinearLayout so that we can see the entire screen layout in action. Use the following code in your layout resource file to add Yes!, No!, and Maybe? Button widgets to the LinearLayout:

<LinearLayout android:id="@+id/answers"
            android:orientation="vertical"
            android:layout_width="fill_parent"
            android:layout_height="wrap_content">

    <Button android:id="@+id/yes"
            android:text="Yes!"
            android:layout_width="fill_parent"
            android:layout_height="wrap_content" />

    <Button android:id="@+id/no"
            android:text="No!"
            android:layout_width="fill_parent"
            android:layout_height="wrap_content" />

    <Button android:id="@+id/maybe"
            android:text="Maybe?"
            android:layout_width="fill_parent"
            android:layout_height="wrap_content" />
</LinearLayout>

In Android XML layout resources, any View classes extending from the ViewGroup class are considered containers. Adding widgets to them is as simple as nesting those View elements inside the element of your ViewGroup (as opposed to closing it with no child XML elements).

The following is a screenshot of the preceding Yes!, No!, Maybe? options:

We have two additional buttons to add to the screen layout. One will allow the user to skip the current question; the other will allow them to look at the short list of meals that we have filtered through so far (based on the questions they have already answered).

When you've completed these two buttons, your layout XML file should now end with:

    <Button android:id="@+id/skip"
            android:text="Skip Question"
            android:layout_marginTop="12sp"
            android:layout_width="fill_parent"
            android:layout_height="wrap_content"/>

    <Button android:id="@+id/view"
            android:text="Feed Me!"
            android:layout_marginTop="12sp"
            android:layout_width="fill_parent"
            android:layout_height="wrap_content"/>
</LinearLayout>

<Button android:id="@+id/view"
        android:text="Feed Me!"
        android:padding="25sp"
        android:layout_marginTop="12sp"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"/>

<resources>
    <dimen name="half_width">160px</dimen>
</resources>

<TextView layout_width="@dimen/half_width" />

Have a go hero – improve the styling

Now we have the most basic structure for this user interface, but it doesn't really look too great. Other than the margins between the answer buttons, and the Skip Question and Feed Me! buttons, you can't really tell them apart. We need to let the user know that these buttons all do different things. We also need to draw more attention to the question, especially if they don't have a lot of time to squint at their screen. You may need the Android documentation, which can be found online at http://developer.android.com/reference/.

We have a question at the top of our screen, but as you can see in the previous screenshots, it doesn't stand out much. Therefore, it's not really very clear to the user what they need to do (especially the first time they use the application).

Try making the following styling changes to the question TextView at the top of our screen. These will only require you to add some attributes to its XML element:

1. Center the text.

2. Make the text bold.

3. Change the text size to 24sp.

4. Add 12sp spacing between the bottom of the question and the answer buttons

The Feed Me! button is also very important. This is the button that gives the user access to the list of suggested recipes that the application has filtered based on their answers, so it should look good.

The following styling should help the Feed Me! button to stand out nicely (hint: Button extends TextView):

1. Make the text size 18sp.

2. Change the text color to a nice red #9d1111.

3. Style the text as bold.

4. Add a text shadow: x=0, y=-3, radius=1.5, and color=white ("#fff").

When you've finished styling the screen, it should look like the following screenshot:

One of the most obvious limitations of the layout XML format is that you can't dynamically populate part of the Activity based on external variables—there are no loops or methods in the XML file.

In our example, this limitation shows itself in the form of our empty LinearLayout. Because each question has any number of possible answers, we need a varying number of buttons in the group. For our purposes, we will create the Button objects and put them into the LinearLayout as part of the Java code.

The other place the XML layout format falls down is dynamically referencing external resources. This can be seen in our example, where we put placeholder text in the android:text attribute on the TextView element—question. We could have referenced an external string using the following syntax:

<TextView android:id="@+id/question"
          android:text="@string/question"
          android:gravity="center"
          android:textStyle="bold"
          android:layout_width="fill_parent"
          android:layout_height="wrap_content"/>

This will effectively reference a static variable from the strings.xml file. It's not suitable for a dynamically selected question, which will change each time we initialize the Activity.

We have a basic user interface, but right now, it's static. We may want to ask our user many different questions, each of which have different answers. We may also want to vary which questions we ask in some way or another. In short, we need some Java code to populate the layout with a question and some possible answers. Our questions are made up of two parts:

In this example, we will make use of string array resources to store all of the question and answer data. We will use one string array to list the question identifiers, and then one string array for each question and its answers. The advantages of this approach are very similar to the advantages of using a layout XML file instead of hard-coding it. The res/values directory of your project will have an auto-generated strings.xml file. This file contains string and string-array resources that you want your application to use. Here is the start of our strings.xml file, with two questions to ask the user:

<?xml version="1.0" encoding="UTF-8"?>

<resources>
    <string name="app_name">Kitchen Droid</string>

    <string-array name="questions">
        <item>vegetarian</item>
        <item>size</item>
    </string-array>
    
    <string-array name="vegetarian">
        <item>Are you a Vegetarian?</item>
        <item>Yes</item>
        <item>No</item>
        <item>I\'m a vegan</item>
    </string-array>
    
    <string-array name="size">
        <item>How much do you feel like eating?</item>
        <item>A large meal</item>
        <item>Just a nice single serving of food</item>
        <item>Some finger foods</item>
        <item>Just a snack</item>
    </string-array>
</resources>

The first item of each question array (vegetarian and size) is the question itself, while each following item is an answer.

These two methods form the basis for populating our question screen and navigating our way through a defined list of questions. When complete, they should look like this:

private static int getQuestionID(
        final Resources res,
        final int index) {

    final String[] questions = res.getStringArray(R.array.questions);

    return res.getIdentifier(
            questions[index],
            "array",
            "com.packtpub.kitchendroid");
}

private int getQuestionIndex() {
    return getIntent().getIntExtra("KitchenDroid.Question", 0);
}

return res.getIdentifier(
        "com.packtpub.kitchendroid:array/" + questions[index],
        null,
        null);

Up to this point we've only used the layout XML file to populate our screen. In some cases, this is just not enough. In this simple example, we want the user to have a list of buttons that they can touch to answer the questions posed to them. We could pre-create some buttons and name them button1, button2, and so on, but that means limiting the number of possible answers.

In order to create buttons from our <string-array> resources, we need to do it in Java. We created a ViewGroup earlier (in the form of the LinearLayout that we named answers). This is where we will add our dynamically created buttons.

Your application now knows where to find the questions to ask, and knows which question it should be asking. Now it needs to put the question on the screen, and allow the user to select an answer.

What just happened?

The findViewById method traverses the tree of View objects looking for a specific identifying integer value. By default, any resource declared with an android:id attribute in its resource file will have an associated ID. You could also assign an ID by hand using the View.setId method.

Unlike many other user interface APIs, the Android user interface API is geared towards XML development than pure Java development. A perfect example of this fact is that the View subclasses have three different constructors, two of which are designed for use with the XML parsing API. Instead of being able to populate the Button label in a constructor (as with most other UI APIs), we are forced to first construct the object, and then use setText to define its label.

What you do pass into the constructor of every View object is a Context object. In the preceding example you pass the Activity object into the constructor of the answer Button objects as this. The Activity class inherits from the Context class. The Context object is used by the View and ViewGroup objects to load the application resources and services that they require in order to function correctly.

You can now try running the application, in which case you'll be greeted with the following screen. You may have noticed that there is additional styling in this screenshot. If you don't have this, you may want to backtrack a little to the previous Have a go hero section.

Android user interface events work in much the same way as a Swing event-listener or a GWT event-handler. Depending on the type of event you wish to receive, you implement an interface and pass an instance to the widget you wish to receive events from. In our case we have Bu tton widgets that fire click-events when they are touched by the user.

The event-listener interfaces are declared in many of the Android classes, so there isn't a single place you can go look for them. Also, unlike most event-listener systems, many widgets may only have one of any given event-listeners. You can identify an event-listener interface by the fact that their class names are prefixed with On (much like HTML event attributes). In order to listen for click-events on a widget, you would set its OnClickListener using the V iew.setOnClickListener method.

The following code snippet shows how a click-listener might be added to a Button object to show a Toast. A Toast is a small pop-up box which is displayed briefly to give the user some information:

button.setOnClickListener(new View.OnClickListener() {
    public void onClick(View clicked) {
        Toast.makeText(this, "Button Clicked!", Toast.LENGTH_SHORT).
             show();
    }
});

The preceding event-listener is declared as an anonymous inner class, which is okay when you are passing similar event-listeners to many different widgets. However, most of the time you'll want to be listening for events on widgets you've declared in an XML layout resource. In these cases it's better to either have your Activity class implement the required interfaces, or create specialized classes for different event-driven actions. While Android devices are very powerful, they are still limited when compared to a desktop computer or laptop. Therefore, you should avoid creating unnecessary objects in order to conserve memory. By placing as many event-listener methods in objects that will already be created, you lower the overhead required.

Android comes with some great tools to create and test applications, even if you don't have an Android device handy. That said, there's no replacement for actually touching your application. It's part of what makes Android such a compelling platform, the way it feels and responds (and the emulator just doesn't convey that).

One of the most important tools in an Android developer's arsenal is the resource selection system. With it you can build highly dynamic applications that respond to changes in the devices, and thus, the user environment. Changing the screen layout based on the orientation of the device, or when the user slides out the phone's QWERTY keyboard, lets them know that you've taken their preferences into account when building your application.

When building user interfaces in Android, it's strongly recommended to build at least the layout structure in an XML file. The XML layout files are not only considered as application resources, but Android also strongly favors building XML user interfaces over writing Java code. Sometimes, however, a layout XML file isn't enough, and you need to build parts of the user interface in Java. In this case it's a good idea to define at least a skeleton layout as XML (if possible), and then place the dynamically created View objects into the layout by using marker IDs and containers (much like dynamically adding to an HTML document in JavaScript).

When building a user interface, think carefully about the look and feel of the outcome. In our example, we use Button objects for the answers to questions. We could have used RadioButton objects instead, but then the user would have needed to select an option, and then touch a Next Question button, requiring two touches. We could also have used a List (which interacts nicely with the fact that it needs to be dynamically populated), however, a List doesn't indicate an "action" to the user quite the way a Button does.

When coding layouts, be careful with the measurement units that you use. It's strongly recommend that you stick to using sp for most purposes—if you can't use one of the special fill_parent or wrap_content values. Other values are highly dependent on the size of screen, and won't respond to the user preferences. You can make use of the resource selection process to build different screen designs for small, medium, or large screens. You could also define your own measurement unit and base it on the screen size.

Always think about how your user will interact with your application, and how much (or little) time they are likely to have with it. Keeping each screen simple and responsive keeps your users happy.

Now that we've learned how to create a skeleton Android project, and a simple Activiy, we can focus on the more subtle problems and solutions of Android user interface design. In the next chapter, we will focus on working with data-driven widgets. Android has several widgets designed specifically for displaying and selecting from more complex data structures. These widgets form the basis of data-driven applications such as an address book or a calendar application.