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

The preview of this section did not survive Thanos's finger snap.

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

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

Assigning Labels

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

A Commanding Button

The preview of this section was traded for a bag of magic beans.

Fleeting Images

The preview of this section was fed to a gremlin, after midnight.

Fields of Green. Or Other Colors.

The preview of this section is in the process of being translated from its native Klingon.

More Common Concepts

The preview of this section apparently resembled a Pokémon.

Visit the Trails!

The preview of this section did not survive Thanos's finger snap.