ConstraintLayout: One Layout To Rule Them All

If you survey the Internet, you will find that ConstraintLayout is popular but relatively new. You will find references to other ...Layout classes, such as LinearLayout and RelativeLayout. We will explore those briefly later in this chapter. Suffice it to say that LinearLayout and RelativeLayout existed from the beginning (2008’s Android 1.0), while ConstraintLayout debuted in 2016. And, there is nothing that ConstraintLayout can do that cannot also be accomplished by some mix of the classic layout classes (e.g., LinearLayout).

So, why did Google bother with 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.

However, in 2008, we had no drag-and-drop GUI builder. LinearLayout, RelativeLayout, and kin were not designed with drag-and-drop in mind. As it turns out, some of those (e.g., LinearLayout) work well in a drag-and-drop model, while others (e.g., RelativeLayout) do not.

By contrast, ConstraintLayout was designed with drag-and-drop GUI building in mind.

Performance

The classic layout classes were not written with performance in mind. Some of their features work well but are a bit slow to execute. They are not so slow as to be unusable, but they do make the app a bit more sluggish, particularly when scrolling the screen.

The objective of ConstraintLayout was to offer all of the capabilities of the classic containers — and more — while keeping performance in mind.

Library vs. Framework

LinearLayout, RelativeLayout, and the other classic containers are framework classes. As a result, they could have different implementations on different versions of Android. Since that causes a lot of pain for maintaining backwards compatibility, Google does not change these classes that often.

ConstraintLayout, by contrast, comes from a library. This has a cost, as now each app needs its own copy of the ConstraintLayout code. However, it also means that Google can keep improving ConstraintLayout, and developers can adopt newer versions of the library that add new features or fix bugs.