Android User Interfaces

Since a user will typically interact visually with an Android application, it is important to understand how Android lays out user interfaces. In this section we give a brief overview. See the Android User Interfaces document for more detail.

A Hierarchy of Views

Visually, an Android window is a hierarchy of views, which are objects derived from the View and ViewGroup classes.

1. View is the base class for "widget" subclasses, which instantiate fully-implemented UI objects. For example, Button is a subclass of View.


2. ViewGroup is the base class for "layout" subclasses, which implement different kinds of UI layout architecture. (A ViewGroup is a special form of View that can contain other Views.) For example,
   
   
   • The class LinearLayout, which implements a layout that arranges its children in a single column or a single row.
   
   
   • The class TableLayout, which arranges its children in rows and columns like a table.
   
   
   • The class RelativeLayout, where the positions of the children can be described relative to each other or to the parent.
   
   
   • The class FrameLayout, which blocks out an area on the screen to display a single item. Multiple children may be added to a FrameLayout and all children will be pegged to the top left of the screen (this, for example, is a way to overlay a set of buttons over an image).
   
   
   • The class GridView, which displays items in two-dimensional scrolling grid.
   
   
   All of these layout classes extend ViewGroup or a subclass of ViewGroup.

Each view in the hierarchy controls a particular rectangular subspace within the window.

• Parent views contain and organize the layout of their children.


• Leaf views are those at the bottom of the hierarchy; they draw in the rectangles they control and respond to user actions within those rectangles.

The following figure illustrates a view hierarchy

Placing the View Hierarchy in an Android Window

The setContentView(View view) method of Activity is used to place a view hierarchy within an activity window, where the content view is the View object at the root of the view hierarchy (the topmost ViewGroup in the preceding figure). Android handles the drawing of the view hierarchy but the Activity must supply the root node as the starting point. The essential procedure is that the root node of the hierarchy requests that its child nodes draw themselves, and in turn each view group node requests that its children draw themselves. Children may request a size and location within the parent, but the parent object has the final say-so on size and position for the child objects. This will be adequate introduction for our initial purposes; a more extensive discussion of rendering the view hierarchy within an Android window may be found in How Android Draws Views.

XML Layouts

The recommended way to lay out the view hierarchy is with an XML layout file. The name of an XML element in this file is in one-to-one correspondence with a Java class that it represents: a <TextView> element creates a TextView in your UI, a <LinearLayout> element creates a LinearLayout view group, and so on. Here is an example of a simple XML layout file:

    <?xml version="1.0" encoding="utf-8"?>
    <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
        android:layout_width="fill_parent" 
        android:layout_height="fill_parent"
        android:orientation="vertical" >
        <TextView android:id="@+id/text"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="Hello, I am a TextView" />
        <Button android:id="@+id/button"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="Hello, I am a Button" />
    </LinearLayout>

This layout would create a TextView and a Button, arrayed vertically in a linear layout in the Android window (we will explain the details of such a listing later). As long as you follow the rules, you do not have to worry about managing the relationship between XML layout of the UI and the Java code that will reference it. Basically you must just place correctly written code in a standardized set of directories and Android will do the rest. When you load a layout resource, Android automatically initializes these run-time objects, corresponding to the elements in your layout.

Menus

Menus are another important part of the UI but, as we describe below, layout and event handling are dealt with somewhat differently for menus than for other UI widgets in Android. There are two types of menus in Android:

1. Options menus: An Activity can be programmed so that if the MENU key on the device is pressed while the Activity is being displayed a menu appears at the bottom of the screen. Such menus are often used for preferences, settings, and other options for an entire activity or application.


2. Context menus: Displayed when the user presses and holds down on (long presses) an item. Such menus are often useful for supplying further information or options for a specific item.

The left figure below illustrates an options menu produced when the MENU key is pressed for an Android phone on its default screen and the right figure below shows a context menu produced on the same phone after a long press on an entry in the Contacts list.

• The View hierarchy corresponding to menus is not handled directly by the user. Instead the user defines the onCreateOptionsMenu() or onCreateContextMenu() callback methods for an Activity and specifies in them the items to be included in the menu (the menu items can also be declared in an XML resource file). When the menu is needed, Android will automatically create the View hierarchy for the menu and draw the user-specified menu items in it.


• Android menus also handle their own events so (unlike for other widgets, as described below) the user does not need to register event listeners on the menu items. The onOptionsItemSelected() or onContextItemSelected() methods will be called automatically by the Android framework when a menu item is selected, so the user puts logic in those methods to deal with the menu events.

Adapters and Data Binding

In dynamical applications you will often want to populate view groups with non-static data from some external data source. For example, a display of the current temperature in several different cities must display temperature data supplied continuously from an external source. This is termed data binding to the View. In Android this is handled by using an AdapterView as the ViewGroup, with each child View populated by an Adapter. An AdapterView object is a ViewGroup that determines its child views based on a given Adapter object. The Adapter acts as a bridge between the data source and the AdapterView, which displays it.

Styles and Themes

Good design is an important component of a user-friendly and aesthetically appealing user interface. One important aspect of good design is achieving a uniform look and feel for applications, which has positive implications for both aesthetics and functionality. One way to achieve this is through styles and themes:

1. Style: a collection of properties that specify the look and format for a View or window. In Android a style is defined in an XML resource separate from the XML layout resource.


2. Theme: a style applied to an entire Activity or application, rather than an individual View.

Styles and themes allow design to be separated from content (thus they function in a way similar to Cascading Style Sheets in webpage design), which facilitates maintenance and extension of projects.

Android provides some default style and theme resources out of the box, and you can also declare your own custom styles and themes. The following figures illustrate the use of one built-in Android theme.

In these two screen shots from an Android phone the "About" button that can be seen in the background of the right image has been clicked to execute an intent to launch a new Activity defined by a Java class About, whose sole function is to display some "About" text. On the left the text appears unformatted on a new screen that replaces the original screen, but on the right the text appears in a rounded rectangular window floating over a dimmed view of the original screen. The only programming difference between the two images is that on the left the activity has been declared in the AndroidManifest.xml file by

  <activity android:name=".About" android:label="@string/about_title"> </activity>

while on the right this declaration has been amended to add an android:theme attribute,

  <activity android:name=".About" android:label="@string/about_title"
      android:theme="@android:style/Theme.Dialog"> 
  </activity>

The @android prefix on the second line indicates that what follows is defined in Android itself, rather than by the user. This added attribute implements automatically a theme Theme.Dialog that gives the look in the right image above, without the programmer having to do anything else. The Theme.Dialog causes the entire activity to be displayed in a floating window that looks like a dialog window. This example illustrates succinctly the use of styles and themes to separate content from design: the left and right figures have exactly the same content, but very different looks, and the programmer does not have to write any code to accomplish this once the theme has been defined.

Another example of a built-in Android theme can be implemented by giving the Activity the attribute android:theme="@android:style/Theme.Translucent. This has the effect of making the background of the Activity window transparent, so that the next window down in the stack is completely visible underneath the content of the new Activity window.

Handling Events

The layout of UI widgets described above will not be very useful unless we define event handlers to respond to events associated with the widgets. We shall give various specific examples later but remark here that this can be implemented in one of two basic ways.

1. The most common way that we will implement event handlers for widgets in our layout is to use Java to define an event handler and then register it with the appropriate view. The View class has a set of interfaces named On<something>Listener, each with a callback method called on<something>(). Examples include
   
   
   • View.OnClickListener, which handles "clicks" on a View.
   
   
   • View.OnTouchListener, which handles touch screen events in a View.
   
   
   • View.OnKeyListener, which handles key presses within a View
   
   
   For example, to cause your View to be notified when it is "clicked", (1) implement OnClickListener, (2) define its onClick(View v) callback method implementing actions to be performed when an event is detected, and (3) register it to the View with setOnClickListener(). (We shall see later how to determine which widget within the View was clicked when there is more than one.)


2. If none of the widgets or layouts already defined in Android are adequate to the task, you may wish to create your own View subclass (see Build a Custom Component). Then you will typically handle events by overriding an existing callback method for the View.