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.

Introducing ConstraintLayout

In 2016, Google released a new container class, ConstraintLayout, that it hopes will become popular among Android developers as an alternative to LinearLayout and RelativeLayout. Certainly, Google is going to “pull out all the stops” to convince developers to use 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 LinearLayout and RelativeLayout are. And, since ConstraintLayout is a library, it adds approximately 100KB to the size of your Android app. Whether it is worth that extra space is for you to decide.

Why Another Container?

LinearLayout, RelativeLayout, and (to a lesser extent) TableLayout have served as the backbone of most Android apps. Previous attempts to provide a new foundation container class — such as GridLayout – have not proven to be particularly popular.

So, why did Google bother creating ConstraintLayout?

Drag-and-Drop GUI Builders

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.

With LinearLayout, adding a widget is fairly easy:

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.


RelativeLayout, LinearLayout with android:layout_weight, and TableLayout with android:stretchColumns/android:shrinkColumns, all 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., android:layout_height), followed by a second pass to allocate the remaining space according to the weight.

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 TextView with android:layout_width="wrap_content". Changing the text changes the horizontal space taken up by that text. So, the 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 re-size/re-position work.

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.

Comparing with the Classics

The preview of this section was accidentally identified as an Android 'tasty treat' by the Cookie Monster.

Getting ConstraintLayout

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

Using Widgets and Containers from Libraries

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

Using a ConstraintLayout

The preview of this section is off trying to sweet-talk the Khaleesi into providing us with a dragon.

Converting Existing Layouts

The preview of this section will not appear here for a while, due to a time machine mishap.

Visit the Trails!

The preview of this section is sleeping in.