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.
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.
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.
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
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,
View. Of course, the JavaDocs also list the fields, constants,
constructors, and public/protected methods that you can use on the widget
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.
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
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
Android provides a few special
android:id values, of the form
@android:id/... — we will see some of these in various chapters of this
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
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
All of this will be covered later in this chapter.
Most sample code that you will see for Android will show the results of the
findViewById() call being cast to some other class:
That is because for most of Android’s existence,
findViewById() returned a
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
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
TableLayout in an upcoming chapter. But generally we need to provide
this information ourselves.
To do that, you need to supply
android:layout_height attributes on your widgets in the XML layout file. These
attributes’ values have three flavors:
125dipto indicate the widget should take up exactly a certain size (here, 125 density-independent pixels)
wrap_content, which means the widget should take up as much room as its contents require (e.g., a
TextViewlabel widget’s content is the text to be displayed)
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 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.
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.
If you open a layout resource in Android Studio, by default you will see the 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:
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
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:
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:
Figure 73: Layout Resource with Invisible TextView
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.
From left to right, the upper level of the toolbar contains:
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.
On the right side of the lower toolbar level are:
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
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:
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.
Towards the bottom-left corner is the 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:
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:
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:
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”:
Figure 81: Attributes Pane, Showing One Favorite Attribute
Those favorite attributes show up in the condensed roster, in the section labeled “Favorite Attributes”.
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:
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:
Figure 83: Text Sub-Tab with Preview
Clicking on items in the preview will highlight the corresponding XML element in the text editor.
The preview of this section was lost in the sofa cushions.
The preview of this section may contain nuts.
The preview of this section was whisked away by a shark-infested tornado.
The preview of this section took that left turn at Albuquerque.
The preview of this section was eaten by a grue.
The preview of this section is being chased by zombies.
The preview of this section was eaten by a grue.