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.
In 2016, Google released a new container class,
that it hopes will become popular among Android developers as an
Google is going to “pull out all the stops” to convince developers
ConstraintLayout, such as having it be used in many of the
activity templates employed by Android Studio’s new-activity wizard.
ConstraintLayout is useful, but it is not required for Android
app development, any more than
are. And, since
ConstraintLayout is a library, it adds ~100KB
to the size of your Android app. Whether it is worth that extra space
is for you to decide.
RelativeLayout, and (to a lesser extent)
have served as the backbone of most Android apps. Previous attempts to
provide a new foundation container class — such as
have not proven to be particularly popular.
So, why did Google bother creating
Google would like everyone to use Android Studio, and in particular for everyone to use Android Studio’s drag-and-drop GUI builder.
How well a drag-and-drop GUI builder works depends a lot on how the rules for laying out a UI get defined. With drag-and-drop gestures, the developer is only providing you with X/Y coordinates of a widget, based on where the developer releases the mouse button and completes the drop. It is up to the GUI builder to determine what that really means in terms of layout rules.
LinearLayout, adding a widget is fairly easy:
LinearLayout, put the new widget in between the existing ones
LinearLayoutwhere the developer dropped it
TableLayout is a bit more involved but still not that bad, as we have
decades of experience of working with spreadsheets to know about inserting
rows and columns into a grid-like structure.
RelativeLayout, though, was difficult for a GUI builder to handle.
Often, the Android Studio GUI builder (and its predecessor in Eclipse)
would misinterpret the developers wishes. Sometimes, the rules the
developer wanted to express were simply unavailable through pure
drag-and-drop operations. As a result, developers had to dive into the
XML to get anything done. Being able to read layout XML is important –
otherwise, books like this would be unusable. However, forcing developers
to write the XML defeated the purpose of the GUI builder.
ConstraintLayout was created with GUI building in mind, to make it a
bit easier to infer the right rules based upon where the developer happens
to drop a widget.
require two passes over their children to determine final sizes and positions.
For example, with a weighted
LinearLayout, you need to make one pass
to calculate the directly-expressed sizes (e.g.,
followed by a second pass to allocate the remaining space according to
This gets exacerbated by the fact that changing the details of a widget
often causes the sizes to have to be recomputed. Suppose that you change
the text in a
Changing the text changes the horizontal space taken up by that text.
TextView winds up telling its container “hey, please recompute
the sizes and positions”, as the larger
TextView might now cause
shifts in other children of the container. Depending on how the container
itself is sized, it might need to tell its container to recompute
the sizes and positions.
Cascading upward to have parents re-size/re-position their children
gets very expensive for deep hierarchies, where we have containers holding
containers holding containers holding containers and so on. One change
in text of a
TextView might cause that whole hierarchy to go through
All else being equal:
ConstraintLayout is being designed with performance in mind, trying
to eliminate as many two-pass scenarios as possible and by trying
to eliminate the need for deeply-nested view hierarchies. Right now,
ConstraintLayout performance is not that
great. However, it is a focus area and should improve over time.
ConstraintLayout most closely resembles
RelativeLayout, you can anchor widgets to other widgets inside
ConstraintLayout or to the boundaries of the
Many structures that can be implemented using
LinearLayout but not
RelativeLayout — such as allocating widget sizes based on weights –
can be handled by
designed to handle such conditional sizing without requiring two passes
through its children to determine those sizes.
TableLayout remains distinct.
ConstraintLayout does not
have the notion of columns, let alone sizing those columns based upon
their contents and layout rules.
The preview of this section is [REDACTED].
The preview of this section is off trying to sweet-talk the Khaleesi into providing us with a dragon.
The preview of this section is in the process of being translated from its native Klingon.
The preview of this section was accidentally identified as an Android 'tasty treat' by the Cookie Monster.
The preview of this section was traded for a bag of magic beans.