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 in question, 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 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 70: 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. This book covers this newer 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.
Dominating the left side of the graphical layout editor is the Palette tool:
Figure 71: Palette Tool
This lists all sorts of widgets and containers that you can drag and drop.
They are divided into categories (“Widgets”, “Text Views”, “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 72: 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 how some of the sizing and positioning rules that you are using for children of that container:
Figure 73: Blueprint
For a trivial layout resource like this one — what you get from the Android Studio “Empty Activity” template — 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 74: 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 75: Preview Toolbar, Top Level
A couple of those — particularly the theme selector and the notion of “different configurations” — pertain to topics that we will explore later in the book.
On the right side of the lower toolbar level are:
Figure 76: 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 77: 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 78: 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 properties 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 Properties 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 properties:
Figure 79: Properties Pane, Showing Condensed Roster
Clicking the “View all properties” link, or the green-arrows toolbar button, switches to a list of all properties:
Figure 80: Properties Pane, Showing Full Roster
We will see what many of these properties are and how to work with them over the course of the next few chapters.
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 81: 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 82: 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 stepped on by Godzilla.
The preview of this section will not appear here for a while, due to a time machine mishap.
The preview of this section apparently resembled a Pokémon.
The preview of this section was last seen in the Bermuda Triangle.
The preview of this section apparently resembled a Pokémon.
The preview of this section was lost due to a rupture in the space-time continuum.