Using the View Class

There may be one or more View objects that make up the entire display screen, depending on how you use the View and ViewGroup classes to create the UI structure for your Android application’s screen.

Each View object controls and references its own rectangular view parameters, allowing you to control many attributes. Here are just some examples of the many attributes controlled by the View class parameters that are available to Android application programmers:

• Bounds (measurements)
• Layout on the screen (position)
• Order in which its layers are drawn (compositing)
• Scrolling (directional movement)
• Focus (which screen elements are currently active)
• Keystroke interactions
• Gesture interactions

Finally, Views have the ability to receive events—interaction events between your application’s end user and the View object itself. For this reason, the View class is the logical Java construct to subclass to build more detailed and specific UI elements, such as buttons, check boxes, radio buttons, and text fields.

So many UI classes have been subclassed from the View class that there is a name for them: widgets. All of these widgets are contained in a package (a collection of classes) called android.widget. For example, you can access a Button class via this package using android.widget.Button.

Nesting Views: Using the ViewGroup Class

One of the most useful classes subclassed from the View class is the ViewGroup class. The ViewGroup class is used to subclass layout container classes, which allow groups of View objects to be logically grouped, arranged, and cascaded onto the screen.

ViewGroups are layout containers, usually collections of UI elements. In the diagram in Figure 6-1, View could mean a button, a text field, a check box, and so on. This applies to any other type of UI element.

The remainder of this chapter explores the different types of ViewGroup subclasses. These are the foundation that Android developers use to organize and group their View objects (UI elements) on the Android device display screen, whether that is a smartphone, tablet, e-reader, or iTV set.

Direct subclasses of the ViewGroup class include AbsoluteLayout, RelativeLayout, FrameLayout, GridLayout, LinearLayout, ViewPager, PagerTitleStrip, AdapterView, FragmentBreadCrumbs, and SlidingDrawer. We’ll look at the two most often used ViewGroup subclasses: LinearLayout and RelativeLayout. We’ll also explore one of the coolest ViewGroup subclasses: SlidingDrawer. This layout class can be used to greatly expand your Android screen real estate by 100% by adding another screen that can be pulled in from offscreen.

In the diagram in Figure 6-1, the top level ViewGroup object is the parent of the View objects and ViewGroup objects underneath it, which are called its children. The ViewGroup object in the second row is both a child as well as a parent, and the same goes for the ViewGroup object in the third row. The View objects in the fourth row of the diagram are children only (joke: but not only children because there are two of them).

As you can see, ViewGroup objects can contain other ViewGroup objects (a concept called nesting; it’s all so familial, isn’t it?), but View objects cannot contain other objects. They are the end object, so to speak, and are simply UI components for which you can set properties via a plethora of configuration parameters, as you will soon see.

Setting Up for Your Screen Layout

Back in Chapter 4, three simple lines of Java code inside an onCreate() method set your content view to the activity_hello.xml screen layout XML definition:

public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_hello);
}

As we then learned in Chapter 5, the words before the method name determine who can access its methods and data as well as which type of values it returns. A public method is one that is open (accessible) to any part of your Android application. A void method is one that completes a task without returning any value or data.

The words that follow the method name (always enclosed in parentheses) are the data parameters that an application can pass to the method for its use. Parameters are chunks of data that the method needs to complete its processing tasks.

The savedInstanceState object is a Bundle object, which is a collection of all of the states for your activity screen UI elements. It exists so that the screen UI elements can be restored to their previous positions if the screen is replaced by navigation to other screens during the use of your application. As you learned in Chapter 5, the state of a UI screen consists of its attributes and their values, including the UI element user settings, which UI element has the focus, and similar attributes that define the current user (usage) settings or state of use of your screen user interface elements.

The super keyword calls the superclass (the class containing the onCreate() method that was subclassed from android.app.Activity), so it is basically referencing the onCreate() method of the android.app.Activity class from which our activity class was subclassed. Thus, the keyword “super” is really just a shortcut (shorthand) for android.app.Activity.onCreate(savedInstanceState).

Because it is called locally from this activity class via super, it affects this activity locally, and applies to this activity only, even though it accesses the parent code by using the super keyword to jump up one level to get the original code routine. This local savedInstanceState object is the one Android kindly saves for us when it deals with saving state for the Activity in which it was declared.

The onCreate() method will always be called by the Android operating system when any activity (remember that all activities for your app are defined in the AndroidManifest.xml file) is started. This part of your code is where all of your initializations and UI definitions will be performed, so it must be present—at least if you need your users to interact with the Android device’s screen area.

The way that layouts contain other nested layouts in XML code (as shown previously in Figure 6-1) is by nesting them inside each other’s tags. The closing tags are nested at the bottom of these structures, and they must be nested in the correct order, to show Android which layouts are nested inside of which other layouts. Layouts inside of another layout tag structure conform to, and are controlled by, their parent layout container. The code examples in this chapter indent the nested code structures to more clearly show the nested layout hierarchy.

You are about to see all of this in action in the next few sections, where we’ll start with the most basic layout container in Android: the linear layout, and progress to more complex layout configurations. First we’ll talk about the LinearLayout class, which has been subclassed from the ViewGroup class, which is subclassed from the View class, which is subclassed from the Java language Object class like this: java.lang.Object android.view.View android.view.ViewGroup.

Using Linear Layouts

In a standard screen user interface (UI) layout, buttons are usually placed across the top of the screen, or sometimes down the side of the screen, in a straight line. This is exactly what the LinearLayout class does for you. It is designed to contain and automatically arrange UI elements placed inside of it across the screen (using the horizontal orientation parameter) or up and down the screen (using the vertical orientation parameter).

In Java code, to set the LinearLayout object’s orientation, use the .setOrientation(integer) method, with either the constant HORIZONTAL for horizontal or VERTICAL for vertical:

myLinearLayout.setOrientation(HORIZONTAL);

HORIZONTAL is a Android OS predefined constant that represents the integer value of zero (0) and VERTICAL is an Android OS predefined constant that represents the integer value of one (1) just in case you are wondering what the actual integer values are that are used internal to the class.

We mention this just to let you know that after the LinearLayout has been set up in your XML markup, it’s possible to change its orientation on the fly inside your Java code if you need to. In most cases however a LinearLayout is declared once in XML and then used as-is in the app.

Here’s the attribute for orientation in the LinearLayout tag for XML:

android:orientation="vertical"

Thus, the entire LinearLayout opening tag for a Vertical UI layout looks like this:

<LinearLayout android:orientation="vertical">

However, we should really have a few more key parameters in the LinearLayout tag to make it more useful and standardized, so here’s how a Horizontal UI layout would normally be coded:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android "
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="horizontal">
        <The Items To Be Arranged Horizontally Would Be Inside This Container>
</LinearLayout>

The first parameter of the LinearLayout XML tag is the path to the Android XML naming schema definition (xmlns:android stands for: eXtensible Markup Language Naming Schema for Android, just in case you may be wondering). This parameter sets the variable android used in the rest of the tag to: http://schemas.android.com/apk/res/android, so that you don’t need to write all of the other XML parameters like this:

http://schemas.android.com/apk/res/android:layout_width="match_parent "

The value for the layout width and height parameters, match_parent, simply tells the LinearLayout to expand to match its parent container size. Because this is the top level LinearLayout container, the android:layout_width=“match_parent” would mean to fill the Android device (smartphone, tablet, e-reader, or iTV) display screen width from one side to the other side. We already know what the orientation does, so now we have our LinearLayout defined. Anything we place inside this container will display horizontally across the screen, from left to right.

As discussed earlier in the chapter, the Java onCreate() method is used to load the activity_main.xml layout parameters for an application.

Well, it’s time to fire up Eclipse again, and create a new application to see how all of this cool stuff works together.

Editing the activity_main.xml File

Now it’s time to work on the activity_main.xml file that was generated for us by the New Project Android Application project sequence of dialogs. Right-click activity_main.xml (if it is not open in a tab already, which it should be) and select Open. Click on the activity_main.xml tab at the bottom of the central coding pane, and you will see some default XML code setting up a RelativeLayout with a TextView. Let’s rename the TextView object’s text parameter from hello to textareaone because we need more than one object to align vertically.

Next let’s change the word Relative to Linear in the top (opening) tag and the bottom (closing) tag, and notice how the information in the Outline Pane on the right changes to reflect that you are now using a LinearLayout container instead of a RelativeLayout container.

Next let’s add the android:orientation=“vertical” attribute above the layout default attributes. Notice that after you type in the android and hit the colon, a helper window pops up (shown in Figure 6-5) and gives you all of the LinearLayout parameter options that are possible.

Double-click on the orientation option and Eclipse will insert the code for you, then just type in “vertical” between the quotes and you’re finished adding the parameter that will orient your LinearLayout UI vertically.

Finally, let’s remove the android:layout_centerHorizontal=“true” and the android:layout_centerVertical=“true” parameters because these are parameters that are used with RelativeLayout, and because we don’t want to center our UI. If you forget to remove these, Eclipse will flag these two lines with a yellow triangle on the left side of each line of code, and if you mouse over the tiny yellow triangles on each line, Eclipse will advise you via the ToolTip pop-up that android:layout_center is not a valid parameter for a LinearLayout. Pretty sleek IDE feature!

Here is how the final code should look, which also appears in the activity_main.xml tab shown in Figure 6-6:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android "
    xmlns:tools="http://schemas.android.com/tools "
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/hello"
    tools:context=".MainActivity" />
</LinearLayout>

In this file, add another TextView object, by copy and pasting the <TextView> element like this:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android "
    xmlns:tools="http://schemas.android.com/tools "
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/hello"
    tools:context=".MainActivity" />
<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/hello"
    tools:context=".MainActivity" />
</LinearLayout>

Next we will edit the text strings in the strings.xml file to say: “Text Area One!” and “Text Area Two!”

<resources>
    <string name="app_name">LinearLayout_Example</string>
    <string name="textareaone">Text Area One!</string>
    <string name="textareatwo">Text Area Two!</string>
    <string name="menu_settings">Settings</string>
    <string name="title_activity_main">MainActivity</string>
</resources>

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android "
    xmlns:tools="http://schemas.android.com/tools "
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/textareaone"
    tools:context=".MainActivity" />
<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/textareatwo"
    tools:context=".MainActivity" />
</LinearLayout>

package second.example.linearlayouts;
 
import android.os.Bundle;
import android.app.Activity;
import android.view.Menu;
 
public class MainActivity extends Activity {
     
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }
    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        getMenuInflater().inflate(savedInstanceState);
        setContentView(R.menu.activity_main, menu);
        return true;
    }

Using Relative Layouts

Relative layouts are for the more complicated UI layouts where you need to define the UI elements in not quite a linear fashion. In fact, the RelativeLayout tag is the default tag used in the standard blank activity code bootstrap provided by the New Project Android Application project sequence of dialogs, as we have seen twice already, so it’s clearly a recommended default layout container as far as Google Android is concerned.

The RelativeLayout class allows you to define how the UI elements (the View objects) are to be placed on the screen relative to each other, rather than just laid out linearly. For this reason, the XML definition for a RelativeLayout may contain more screen layout variables and parameters, so this example will be a number of lines of markup code longer (eight additional lines of code, or 50% more code, to be exact) than the LinearLayout example.

If you start to get into the habit of nesting several LinearLayout containers to achieve a more complex UI layout result, you may want to consider using a single RelativeLayout container to achieve the same results with better control, fewer nested levels, and more efficient XML code.

Simpler is always better, so if you can write a UI layout using fewer nested ViewGroup containers, it will always use less memory, and will function more quickly (smoothly). The RelativeLayout container allows you to arrange all sorts of UI elements together in a single ViewGroup to achieve a more complex layout using only a single layout container.

RelativeLayouts are also the optimal type of layout container for using sliding drawers, another direct subclass of the ViewGroup class. Sliding drawers extend the screen real estate of the smartphone, tablet, or iTV by allowing drawers to slide out onto the screen from any of the four sides (top, left, bottom, or right). This is very cool layout container functionality (class) that is built into the Android SDK, as you’ll see in the last part of this chapter.

Because we already have our linear layout application open in Eclipse, let’s change it to a relative layout configuration. That way, we won’t need to type in all the same code, or go through the Project Close and New Project sequence of dialogs yet again. To change a layout, all you need to do is to change the XML code in your activity_main.xml file.

Because our Java code references activity_main.xml, we do not need to change anything in the MainActivity.java tab to make these changes work, a testimony to the power of modularity via XML in Android. We also do not need to change (or even remove) the content in strings.xml, even though the second text area string setting will not be used in the application anymore. If you are meticulous, which is a good thing for a programmer to be, you can always remove it because you know that it is not referenced any more.

We’ll edit activity_main.xml now. And while we are at it, we’ll also add some other UI elements—an editable text field and a couple of buttons—so that you can see how easy it is to create (or in this case, change and refine) a UI layout scheme inside of the Android Development Environment.

In the first tag of activity_main.xml, change LinearLayout and its closing tag back to RelativeLayout and remove the android:orientation="vertical" parameter. We will add some UI elements to the inside of the RelativeLayout tag (before the closing tag </RelativeLayout> line of markup code).

Let’s leave in one <TextView> tag and delete the other. Give the remaining tag an ID and a default, or starting, text value. So, this can be specified not only via a reference to a data declaration in strings.xml (as in our previous example), but also directly, right here in the activity_main.xml file (just to show you two ways to do it) without referencing strings.xml, as follows:

<TextView
        android:id="@+id/label"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Type here:"
        tools:context=".MainActivity"/>

The TextView is the first UI element, so we don’t have any relative layout attributes—there is nothing for this UI element to be relative to yet, other than to be relative to the upper-left corner of the screen, which by the way, is the default alignment, and can be referenced by pixel X,Y coordinates of 0,0, because screen layout coordinates originate from the left and top of the screen, much like a spreadsheet is numbered from it’s upper-left corner.

Next, let’s add an <EditText> element. This can be done either by typing in the code shown in the next section, or by dragging from the visual layout editor in Eclipse, which is accessed via the “Graphical Layout” tab shown on the screenshot in Figure 6-12. Because this is an Absolute Beginners book, we’ll show you how to “Drag-N-Drop” your UI Designs in the Graphical Layout Editor in Eclipse, which will write all the XML markup for you, so that all you have to do is check it and modify it, if needed. Under Palette, click the Text Fields “drawer” to open it, and drag the abc (tooltip will say: Plain Text) UI element onto the screen at the right, under the Type Here: text as shown in Figure 6-12.

Next, click on the activity_main.xml tab next to the Graphical Layout tab to see the XML markup that was just written for us! The resulting XML markup should read as follows (if it does not, edit it directly so that it does):

<EditText
        android:id="@+id/editText1"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_below="@+id/label"
        android:layout_marginTop="10dip" (add this tag to the code the GLE has written for you)
        android:ems="10" >
        <requestFocus />
</EditText>

It will be laid out relative to (below) the TextView as shown because that is where you drag-N-dropped it in the visual layout editor. The key line of XML is the fourth parameter, called layout_below, which references the ID of the TextView, telling Android to position the EditText object below the TextView object that has an ID value of “label.” This is pretty straightforward logic, and is also very powerful.

You’ll soon see that Eclipse (Android ADT more accurately) wants you to use the strings.xml file to hold text constants, as you will see a little triangular yellow “warning” icon next to your android:text parameter. When you mouse-over this, it will say: “Hard-Coded String: Should Use @string Resource” and you will also see another one of these next to the <EditText> tag that reads: “Text Field does not specify an Input Type or a Hint.” Both of these warnings are not important now (that is, they will not prevent your app from compiling and running in the 4.1 emulator), but these warnings are generally helpful to the programmer, and also let us know how Android thinks things should be done (optimally) within their development environment, and within your app code structure.

Because the text label and the text field are a little cramped together, lets add an android:layout_marginTop=”10dip” to space things out a little bit. This adds 10 device independent pixels (DIP; you can also use the abbreviation DP if you like) to the top of the EditText field, which spaces (pushes) it down and away from the text label that we already had in place in the upper-left 0.0 corner location on the screen.

Finally, we observe that Eclipse GLE added a nested <requestFocus /> tag inside (before) the end of the </EditText> closing tag. This is so that this UI element will have “focus” on application launch and will be ready to receive text data. What this does is to get the text entry area ready for use and is the equivalent of the user manually clicking on the text field to tell it to accept text data entry. What having this <requestFocus/> tag inside of the <EditText> tag does for you is that now your user does not have to touch the screen to show Android where they want to start working (i.e., entering text), and your end user can simply begin entering text immediately on launching the app, because the focus has been set for them where it logically should be set—within the first text entry field on the user interface screen.

Note that to set the focus on the button (which we will add next) would be wrong UI design because you can’t click the OK button until you have entered the text in the first place! Figure 6-13 shows what the XML should look like in Eclipse; notice that selecting the EditText tag (shown in light blue highlighting) shows the span (medium blue spanning the left margin) of the code contained within that tag.

Next, let’s click on the Graphical Layout Editor tab again, and add an OK button UI element, by dragging a button UI element out of the Form Widgets section (on the left, under Palette) of the Graphical Layout Editor Tab (in the center code editing area of Eclipse) as shown in Figure 6-14. Note that as you drag and position the UI element (in this case, a button), that the Eclipse Graphical Layout Editor actually shows you in real time what the XML markup parameters it will code for that positioning location are via a light-yellow tool-tip. Super cool stuff, so play around with it for a while!

You can also hand code this OK button via the <Button> XML tag, as in the following example, if you prefer not to use the Drag-N-Drop GUI Editor in Eclipse. Note that the helper tooltip in the screenshot in Figure 6-14 shows what XML parameters will be placed in the following code based on the orange dashed line representation of where your mouse is holding the button for eventual placement via mouse button release (drop).

Here’s the code that Eclipse GLE generates for you:

<Button
        android:id="@+id/button1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentRight="true"
        android:layout_below="@+id/editText1"
        android:text="OK" />

This <Button> tag shows some of the power of relative positioning. The button is below the EditText (using the parent’s ID parameter), aligned right relative to the parent container, which means aligned to the right side of the screen because the parent container is the <RelativeLayout> tag, which has parameters telling it to fill the screen (this is what match_parent means for this tag), thus in this case the RelativeLayout container (tag) IS the screen.

Let’s add a Cancel button to the left of the OK button, over on the left side of the screen, and let’s align it below the EditText UI element, using this code (or you can try using the Graphical Layout Editor in Eclipse, as shown in Figure 6-15, again to get some more practice doing it the easy way).

Here’s the XML markup that should be generated

<Button
        android:id="@+id/button2"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_below="@+id/editText1"
        android:text="Cancel" />

Notice that because the default button alignment is to the left of the screen that the only relative positioning definition tag that we need is one that specifies android:layout_below of the EditText UI widget named editText1. Here is all of the new RelativeLayout code in the activity_main.xml file ( Figure 6-16 shows it in Eclipse):

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android "
    xmlns:tools="http://schemas.android.com/tools "
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
 
<TextView
    android:id="@+id/label"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Type here:"                 (Generates Warning: Hard Coded Text)
    tools:context=".MainActivity" />
 
<EditText                          (Generates Warning: No Hint Parameter Included)
        android:id="@+id/editText1"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_below="@+id/label"
        android:layout_marginTop="10dip"
        android:ems="10" >
        <requestFocus />
</EditText>
 
<Button
        android:id="@+id/button1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentRight="true"
        android:layout_below="@+id/editText1"
        android:text="OK"/>                 (Generates Warning: hard Coded Text)
 
<Button
        android:id="@+id/button2"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_below="@+id/editText1"
        android:text="Cancel"/>             (Generates Warning: Hard Coded Text)
</RelativeLayout>

Now let’s compile the project and run it in the Android 4.1 emulator. Right-click the LinearLayouts project folder at the top of the Package Explorer pane and select Run As Android Application. Figure 6-17 shows our app running in the Android 4.1 device emulator. As you can see, the RelativeLayout code works great and formats our UI perfectly.

Now let’s add some animation to our UI by creating a sliding drawer layout container for our UI elements.

Sliding Drawer: Expanding Your UI

One of the more advanced layout containers in Android is SlidingDrawer, another direct subclass of the ever so useful ViewGroup class. This layout is not used quite as often as the others, but it’s extremely handy and a lot of fun as well.

A sliding drawer is useful because it gives us a way to expand the screen area that can be used by UI components, or even for application content, for that matter.

A SlidingDrawer container should be used inside either the RelativeLayout container or the FrameLayout container, according to the developer documentation, which you should always review on developer.android.com before using any Android Class, just to see what it can do and how it should be coded. Android Developer documents in this case recommend using the RelativeLayout container, if possible, instead of the FrameLayout container. You cannot use SlidingDrawer as its own container because it needs to slide out of (and over) something. Logical enough when you think about it.

How does sliding drawer expand your screen area? By sliding a drawer (vertically or horizontally) onto the display from off the screen, you have another virtual (hidden) screen available for use. This can be useful if you need the entire screen for your content because you can keep your UI controls in a drawer that slides on or off the screen whenever those UI elements are needed.

Now let’s add a sliding drawer to our RelativeLayout of the previous section, and see just how cool an application user interface (UI) we can create using only two dozen lines of XML code. We’ll create an app with an analog clock that slides out inside of its own drawer whenever we need to see what time it is.

Leave our existing project’s RelativeLayout XML tag intact, but delete the text and button elements inside. Then add the SlidingDrawer tag inside of the RelativeLayout container because a drawer always needs to slide out of something (and over the top of the other content in the RelativeLayout container). Let’s practice doing this the easy way, with the Eclipse Graphical Layout Editor, and then we’ll take a look at the XML code once it’s been auto-generated for us and “tweak” it with our own customized parameters to fine-tune our desired end result.

After you delete the TextView, EditText, and Button tags inside of the RelativeLayout container tag using the activity_main.xml tab in Eclipse, switch over to the Graphical Layout Editor by clicking on the Graphical Layout tab at the bottom of the central editing pane in Eclipse. Click on the Composite (stands for Composite Layouts) section (notice that the UI works as a type of sliding drawer that we are implementing here) and drag the SlidingDrawer icon onto the now blank App UI screen on the right, and once the green lines fill the app screen, drop it into place as shown in Figure 6-18.

Now click on the activity_main.xml tab and take a look at the code that Eclipse (more accurately, the ADT plug-in) wrote for us. You’ll see a SlidingDrawer container inside of the RelativeLayout container, and inside of the sliding drawer you will see a Button UI element used for the SlidingDrawer “handle” (a SlidingDrawer UI element must always have a handle defined) and a LinearLayout container ready to hold your content that will be inside of the SlidingDrawer. Figure 6-19 shows the XML code that was auto-generated.

If you like, you can right-click on the project name and do a Run As Android Application and see the handle at the bottom of the screen, click it, watch it animate to the top of the screen (opening the drawer), and then click it again, and watch it animate back down to its original position (i.e., drawer closed). Then close the emulator and go back to the Eclipse Graphical Layout Editor tab, so that we can add an AnalogClock object (widget) inside of the drawer to give our app some useful functionality.

Find the AnalogClock icon under the Time and Date section at the left side of the Graphical Layout Editor and drag the AnalogClock widget icon onto the UI area on the right. Once you drop it, you will have a square resizable area at the upper-left of the container (default position of 0,0 as we learned about previously). Shown below in Figure 6-20 is the drag operation we went through to place the AnalogClock UI widget into our SlidingDrawer; notice that Eclipse ADT gives you guidelines for positioning as you are dragging the UI elements into place; again, be sure to play around a bit with this functionality to get used to it, and then to leverage it completely to your development advantage.

Grab the bottom-right handle of the AnalogClock widget box and drag it down and to the right until it fills the container (screen). This will center the AnalogClock widget on the screen (the AnalogClock widget does not scale as some of the other UI widgets do). You might think that you can click and drag in the middle of this square area to move and position it, but once you try that, you will see that it does not work that way, so position it with the lower-right handle instead. ADT will show you the original size (green square) and the new size (orange square) as you drag the handle, as shown on Figure 6-21.

Now let’s take a look at the XML markup that was generated for us, by simply clicking on the activity_main.xml tab. There should now be an AnalogClock tag inside of the LinearLayout tag, which there is, as shown in Figure 6-22. We now can see a really good example of tags that are nested deeply inside of each other.

Let’s right-click on the project name and Run As Android Application to see our SlidingDrawer open up and give us a nicely centered analog clock. Figure 6-23 shows the before and after of the SlidingDrawer closed and open in the display portion of the Android 4.1 emulator.

Now let’s make a couple of minor modifications to the XML code to make the app a little bit more colorful, user friendly, use fewer lines of code, and work across all screen sizes automatically. Notice that our AnalogClock parameters are different, one uses “match_parent” and the other uses “355dp,” which would work fine on a 320 by 480 smartphone, but not as well on a 800 by 480 tablet or 1,280 by 720 iTV. So, first, to make our app work across different screen sizes, lets change the android:layout_height to have the same match_parent setting as the android:layout_width parameter does.

Next let’s make the app more user friendly and change the Button text parameter to read “Open Drawer” instead of “Handle,” so the user sees what is going on with the app. Now you can Run As Android Application (again) if you wish to see that the app still works the same with the new parameters and settings.

Next you may be wondering: is the LinearLayout container that the Graphical Layout Editor coded for us unused (or redundant) in this example? Couldn’t the AnalogClock be directly inside of the SlidingDrawer container, along with the Button Handle? Let’s remove the LinearLayout tag, its parameters, and closing tag, and find out!

Be sure to rename the AnalogClock ID parameter to “content” so that the SlidingDrawer android:content parameter points to something (the ID of the LinearLayout container that we deleted had been set to “content” and so we need to change the ID AnalogClock1 to “content”). Now Run As Android Application again and see that the new code indeed works the same, saving several lines of code, and more important, memory space that would have been used to define a redundant container that was not really needed. This also puts us into the two dozen lines of code realm that we were shooting for.

Finally, let’s add an android:background=“#D0A0A0” parameter to the SlidingDrawer tag to set a background color to differentiate the open drawer state from the closed drawer state, so you can really see the edges of the SlidingDrawer container itself. Although we are doing this with XML code, shown next, it is also doable by entering #D0A0A0 in the background field under the Properties pane to the lower-right of the Graphical Layout Editor pane when you have the SlidingDrawer container selected in the Graphical Layout Editor (click just above the AnalogClock selection to select the SlidingDrawer container above it).

Here’s the final code:

<RelativeLayout
     xmlns:android="http://schemas.android.com/apk/res/android "
     xmlns:tools="http://schemas.android.com/tools "
     android:layout_width="match_parent"
     android:layout_height="match_parent">
     <SlidingDrawer
           android:id="@+id/slidingDrawer1"
           android:layout_width="match_parent"
           android:layout_height="match_parent"
           android:layout_alignParentLeft ="true"
           android:layout_alignParentTop ="true"
           android:background="#D0A0A0"
           android:content="@+id/content"
           android:handle="@+id/handle" >
 
      <Button
           android:id="@+id/handle"
           android:layout_width="wrap_content"
           android:layout_height="wrap_content"
           android:text="Open Drawer"  />
 
      <AnalogClock            android:id="@+id/content"
           android:layout_width="match_parent"
           android:layout_height="match_parent" />
     </SlidingDrawer>
</RelativeLayout>

As you can see from the code indenting, the SlidingDrawer tag goes inside the RelativeLayout tag. It has two other XML tags that go inside of it: one that defines the button that will be used as the handle for opening and closing the sliding drawer (the Button tag), and another that defines the content inside of the drawer (the AnalogClock tag).

There are two required tags that must be in a SlidingDrawer layout container, the android:handle and the android:content. The android:handle can point to anything that can be used as a handle, the most common would be a button (default) or a drawable asset such as a custom 3D handle that you might create just for this purpose.

The other XML tag that must be inside any SlidingDrawer layout container is android:content. Whatever XML tag you want to use for your content must have an ID specified that matches the name that is specified in the SlidingDrawer android:content parameter. In this case, we are using content as the content container’s ID, but it could be anything you like, for instance we could have specified android:content=“@+id/analogClock1” instead of changing the AnalogClock’s ID to “content.”

We used the Android’s AnalogClock XML tag to give us some impressive working content for this exercise with very little coding effort. Note that we are accomplishing this in only three lines of XML code. In fact, this entire “clock in a drawer” Android application is using primarily XML, and essentially no Java logic, other than to display the UI design on the Android smartphone, tablet, e-reader, or iTV screen.

So that we can see the boundaries of the SlidingDrawer, which we have set in the SlidingDrawer tag layout_width and layout_height parameters, we have placed an android:background parameter in the SlidingDrawer tag. The content is given a teaberry color value background that matches our Android RAZR phone. This android:background parameter will work in virtually any XML tag relating to the screen, and uses a standard hexadecimal color value representation (#D0A0A0) inside of quotes just as it is used in HTML and CSS. If you are entering the value into the Properties Editor pane on the right side of Eclipse, then you don’t need to include the quotes around the hexadecimal color value.

Finally, just to be super precise and exacting, you can click the strings.xml tab and change LinearLayout_Example to SlidingDrawers_Example and delete any unused TextView values.

Figure 6-23 shows the sliding drawer example running in the emulator. Some cool things to change so that you can see what this layout container can do are to change the orientation (to horizontal) and the layout width and height parameters of the SlidingDrawer tag itself. I suggest that you practice compiling and testing Android applications by changing these XML parameters and then choosing Run As Android Application a bunch of times. This will help you to get used to the development work process and more comfortable with Eclipse, and how easy it is to use.

Using Padding and Margins with Views and Layouts

Padding adds spacing to a View (or a widget subclassed therefrom), so that that View’s content is offset by a certain number of pixels on each of the four sides. This way, the content doesn’t touch the edges of the View and look unprofessional. In other words, padding adds space around the outside of a View’s content, and you can choose to do so on any of the four sides of the View object. When using padding, the padding is considered to be part of the View, which may affect the way Android lays out the View.  Remember, we are talking here about a View Class or Object, that is, a user interface widget, not the view on your Android device’s screen!

Padding values are only available to Views, not to ViewGroups (and thus not available in screen layout containers). This is logical because View objects (usually widgets) are contained inside something (ViewGroups) but contain nothing inside of them, that is, they are what they are (Button, Clock, Radio Button, Text Field, etc.).

ViewGroups instead support margins, which allow the same results as padding to be obtained, except that the margins are not considered part of the ViewGroup. For me, this makes UI design more organized and easy to remember: Views use padding values and ViewGroups use margin values and also can use padding values.

Setting Padding in Views

Padding can be set for your View objects (usually widgets) in three ways, two of which we have seen so far in this book. The first and easiest way to set a padding value for a UI element widget is to use the Properties Editor pane in Eclipse, where all of the properties of a selected UI element in the Graphical Layout Editor will be displayed on the right side (or wherever you place that pane) of the Eclipse IDE.

The second way to set properties of a UI widget is in the XML editor pane, where when you type android: a window containing all of the parameter options (including padding settings) will pop-up as soon as you type the colon symbol after you type in android (in lower case). Then you can double-click on the parameter that you want and type in its value or even type in the entire parameter from memory without using the helper that works in the XML editing pane. Most of the time you will use one of these two methods to set padding; using Java for setting padding values is not a “Best Practice,” unless you are doing something really vanguard and need to have real-time control over padding values.

That said, padding can also be set via your Java code, using the .setPadding() method with four values, for left, top, right, and bottom. Think of going around a clock, starting at 9:00, separated by commas. So, to put a four-pixel border inside your view, you would use the following (remember that the order of parameters is left, top, right, bottom):

objectName.setPadding(4,4,4,4);

You can also separate each side in the Java methods, just like you can with the XML tag parameters. So, to get the padding for the left side of the view, use .getPaddingLeft(). To set just the padding on the top to eight pixels, you would write something like this:

ObjectName.setPaddingTop(8);

Setting Margins in ViewGroups

For ViewGroups, including layout containers (the subject of this chapter), the easiest way to set margins during development is via the XML parameters for any ViewGroup object.

Four layout margin values are available in XML:

• android:layout_marginBottom
• android:layout_marginLeft
• android:layout_marginRight
• android:layout_marginTop

We used the android:layout_marginTop in our RelativeLayout example earlier in this chapter to space the text entry UI element down and away from the text label UI element. In fact, we will be using this throughout the book to space out our centered UI objects evenly.

Be sure to experiment with using these four parameters on your UI elements. You’ll see that you can control exactly how your UI elements are spaced around on the screen as you become familiar with what margins can do.