The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

Basic Widgets

Every GUI toolkit has some basic widgets: fields, labels, buttons, etc. Android’s toolkit is no different in scope, and the basic widgets will provide a good introduction as to how widgets work in Android activities. We will examine a number of these in this chapter.

Common Concepts

There are a few core features of widgets that we need to discuss at the outset, before we dive into details on specific types of widgets.

Widgets and Attributes

As mentioned in a previous chapter, widgets have attributes that describe how they should behave. In an XML layout file, these are literally XML attributes on the widget’s element in the file. Usually, there are corresponding getter and setter methods for manipulating this attribute at runtime from your Java code.

If you visit the JavaDocs for a widget, such as the JavaDocs for TextView, you will see an “XML Attributes” table near the top. This lists all of the attributes defined uniquely on this class, and the “Inherited XML Attributes” table that follows lists all those that the widget inherits from superclasses, such as View. Of course, the JavaDocs also list the fields, constants, constructors, and public/protected methods that you can use on the widget itself.

This book does not attempt to explain each and every attribute on each and every widget. We will, however, cover the most popular widgets and the most commonly-used attributes on those widgets.

Referencing Widgets By ID

Many widgets and containers only need to appear in the XML layout file and do not need to be referenced in your Java code. For example, a static label (TextView) frequently only needs to be in the layout file to indicate where it should appear.

Anything you do want to use in your Java source, though, needs an android:id.

The convention is to use @+id/... as the id value (where the ... represents your locally-unique name for the widget) for the first occurrence of a given id value in your layout file. The second and subsequent occurrences in the same layout file should drop the + sign.

Android provides a few special android:id values, of the form @android:id/... — we will see some of these in various chapters of this book.

To access our identified widgets, use findViewById(), passing it the numeric identifier of the widget in question. That numeric identifier was generated by Android in the R class as (where something is the specific widget you are seeking).

This concept will become important as we try to attach listeners to our widgets (e.g., finding out when a checkbox is checked) or when we try referencing widgets from other widgets in a layout XML file (e.g., with RelativeLayout). All of this will be covered later in this chapter.

The Curious Case of the Cast

Most sample code that you will see for Android will show the results of the findViewById() call being cast to some other class:

TextView tv=(TextView)findViewById(;

That is because for most of Android’s existence, findViewById() returned a View, so we would need to down-cast that to a more appropriate class.

However, if you are using Android Studio 3.0+, with an app with a compileSdkVersion of 26 or higher, you will notice that you no longer need those casts. Any existing ones will show up in gray, with a tooltip indicating that the cast is unnecessary.

What happened is that Android 8.0 changed findViewById() to return T, using Java generics to automatically cast it to the data type you request in the assignment. Casts are a compile-time thing in Java — they do not appear in compiled code and have no effects at runtime. As a result, code that skips the casts works perfectly fine on older devices as well.


Most of the time, we need to tell Android how big we want our widgets to be. Occasionally, this will be handled for us — we will see an example of that with TableLayout in an upcoming chapter. But generally we need to provide this information ourselves.

To do that, you need to supply android:layout_width and android:layout_height attributes on your widgets in the XML layout file. These attributes’ values have three flavors:

  1. You can provide a specific dimension, such as 125dip to indicate the widget should take up exactly a certain size (here, 125 density-independent pixels)
  2. You can provide wrap_content, which means the widget should take up as much room as its contents require (e.g., a TextView label widget’s content is the text to be displayed)
  3. You can provide match_parent, which means the widget should fill up all remaining available space in its enclosing container

The latter two flavors are the most common, as they are independent of screen size, allowing Android to adjust your view to fit the available space.

Note that you will also see fill_parent. This is an older synonym for match_parent. match_parent is the recommended value going forward, but fill_parent will certainly work.

This chapter focuses on individual widgets. Size becomes much more important when we start combining multiple widgets on the screen at once, and so we will be spending more time on sizing scenarios in later chapters.

The layout_ prefix on these attributes means that these attributes represent requests by the widget to its enclosing container. Whether those requests will be truly honored will depend a bit on what other widgets there are in the container and what their requests are.

Introducing the Graphical Layout Editor

If you open a layout resource in Android Studio, by default you will see the graphical layout editor:

Android Studio Graphical Layout Editor
Figure 69: Android Studio Graphical Layout Editor

This offers a drag-and-drop means of defining the contents of that layout resource.

Android IDEs have had drag-and-drop GUI building capability for several years, dating back to when Eclipse was the official IDE. However, Android Studio 2.2 made some significant changes in the way the drag-and-drop GUI builder looks and works, and later updates have changed it further. This book covers the current look-and-feel, but older blog posts, Stack Overflow answers, and similar resources may refer to aspects of previous GUI builders.

With all that in mind, let’s look at the different pieces of the graphical layout editor.


The upper-left side of the graphical layout editor is the Palette tool:

Palette Tool
Figure 70: Palette Tool

This lists all sorts of widgets and containers that you can drag and drop. They are divided into categories (“Widgets”, “Text”, “Layouts”, etc.) with many options in each. A few are not strictly widgets or containers but rather other sorts of XML elements that you can have in a layout resource (e.g., <fragment>, <requestFocus>).

As we cover how to use the graphical layout editor, we will see how to create and configure several of these widgets, containers, and other items.


The main central area of the graphical layout editor consists of two perspectives on your layout resource contents. The one on the left is a preview of what your UI should resemble, if this layout were used for the UI of an activity:

UI Preview
Figure 71: UI Preview

This pours your layout resource contents into a preview frame that has aspects of a regular Android device, such as the navigation bar at the bottom and the status bar at the top.

If you drag items out of the Palette and drop them into the preview area, they will be added to your layout resource.


To the right of the preview area is the blueprint view. This also visually depicts your layout resource. However, rather than showing you a preview of what your UI might look like, it visually represents what widget and container classes you are using. And, for some types of containers, it will show some of the sizing and positioning rules that you are using for children of that container:

Figure 72: Blueprint

For a trivial layout resource, the blueprint view does not show you much. It will become more useful with more complex layout resources. In particular, it is very useful when you have designated some widgets or containers as being invisible, as they will show up in the blueprint but not in the preview:

Layout Resource with Invisible TextView
Figure 73: Layout Resource with Invisible TextView

Preview Toolbar

Above the preview and blueprint is a bi-level toolbar that allows you to configure various aspects of the preview and blueprint appearance and behavior.

Upper Toolbar Level

From left to right, the upper level of the toolbar contains:

Preview Toolbar, Top Level
Figure 74: Preview Toolbar, Top Level

A couple of those — particularly the theme selector — pertain to topics that we will explore later in the book.

Lower Toolbar Level

On the right side of the lower toolbar level are:

Preview Toolbar, Bottom Level, Right Side
Figure 75: Preview Toolbar, Bottom Level, Right Side

The left side of the bottom level of the preview toolbar will change, based upon the selected widget or container, offering options for you to be able to make simple changes to whatever is selected. We will see examples of this over the next few chapters

Pan and Zoom Mode

The “Pan and Zoom” mode allows you to navigate a zoomed-in version of your preview and/or blueprint. While the main views will be zoomed in, tapping the “Pan and Zoom” toolbar button opens up a floating window showing the entire preview and/or blueprint, with a red box indicating what portion of that you are seeing in the main views:

Preview and Blueprint, with Pan and Zoom Enabled
Figure 76: Preview and Blueprint, with Pan and Zoom Enabled

You can drag the red frame around the floating window to change what portion of the entire zoomed-in view you can see in the main view.

Component Tree

Towards the bottom-left corner is the component tree:

Component Tree
Figure 77: Component Tree

This gives you a full tree of all of the widgets and containers inside of this layout resource. It corresponds to the tree of XML elements in the layout resource itself.

Clicking on any item in the component tree highlights it in both the preview and blueprint views, plus it switches to that widget or container for the attributes pane.


When a widget or container is selected — whether via the component tree, clicking on it in the preview, or clicking on it in the blueprint – the Attributes pane on the right will allow you to manipulate how that widget or container looks and behaves.

By default, it will bring up a condensed roster of the most important attributes:

Attributes Pane, Showing Condensed Roster
Figure 78: Attributes Pane, Showing Condensed Roster

Clicking the “View all attributes” link, or the opposing-arrows toolbar button, switches to a list of all attributes:

Attributes Pane, Showing Full Roster
Figure 79: Attributes Pane, Showing Full Roster

You can also click the magnifying glass icon in the toolbar of this pane to search for available attributes by name:

Attributes Pane, Showing Search Results
Figure 80: Attributes Pane, Showing Search Results

We will see what many of these attributes are and how to work with them over the course of the next few chapters.

For the attributes in the full roster, you can click the star icon on the left to mark them as “favorites”:

Attributes Pane, Showing One Favorite Attribute
Figure 81: Attributes Pane, Showing One Favorite Attribute

Those favorite attributes show up in the condensed roster, in the section labeled “Favorite Attributes”.

Text Tab

Towards the bottom of the graphical layout tool, you will see that it contains two sub-tabs. One, “Design”, encompasses everything described above. The other, “Text”, allows you to edit the raw XML that is the actual content of the layout resource:

Text Sub-Tab in Layout Editor
Figure 82: Text Sub-Tab in Layout Editor

By default, the entire area is devoted to the text editor. However, when the Text sub-tab is active, a “Preview” tool will appear docked on the right side of the Android Studio window. Clicking that will display the preview from the Design sub-tab:

Text Sub-Tab with Preview
Figure 83: Text Sub-Tab with Preview

Clicking on items in the preview will highlight the corresponding XML element in the text editor.

And Now, Some Notes About the Book’s Sample Projects

The preview of this section was lost in the sofa cushions.

Assigning Labels

The preview of this section may contain nuts.

A Commanding Button

The preview of this section was whisked away by a shark-infested tornado.

Fleeting Images

The preview of this section took that left turn at Albuquerque.

Fields of Green. Or Other Colors.

The preview of this section was eaten by a grue.

More Common Concepts

The preview of this section is being chased by zombies.

Visit the Trails!

The preview of this section was eaten by a grue.