Getting started with ConstraintLayout in Kotlin - Part 1: introduction to ConstraintLayout
This is the first part of a five-part series. In this series, we will be looking at one of the recently released layouts in Android - the ConstraintLayout. We will cover various building blocks of the layout, how they work collectively, and we will round off the series by creating a complex layout in the final part.
For this first part, however, we will look at the features and the problems the layout attempts to solve. Plus we will set up an Android project, which we will be playing around with through the series.
For you to follow along in the entire series, you need to have the following requirements:
- Android Studio (v3.0 or higher) installed on your machine. .
- Ability to navigate the Android Studio IDE.
- A basic understanding of Android development, especially layouts.
If you have these prerequisites, let’s start.
The advent of the ConstraintLayout
The ConstraintLayout is a new layout available in the Android Support repository for building flexible and efficient layouts. Unlike preceding layouts, it is not bundled into the support library dependency. This is to enable frequent releases to be shipped easily and so the Android framework releases do not affect them directly.
This layout was introduced in May 2016 during the . The layout comes with higher advantages, better performance, and more flexibility as compared to other layouts. This layout is backward compatible with API 9 (Android 2.3).
The ConstraintLayout system has three parts: constraints, equations, and solver. Constraints are relationships between your views and are determined when you set up your UI. Once you create these relationships, the system will translate them into a linear system of equations. In subsequent parts of this series, we will take a deeper look at constraints.
Based on the constraints you’ve set, the unknowns as to where the views are supposed to be, are resolved. It uses the popular algorithm to know how to solve the equations (position its constraints). This algorithm is used in other popular platforms too like the AutoLayout in iOS development. The equations go in the solver and it returns the positions, and view sizes to be used in the layout.
The ConstraintLayout becomes very necessary most especially when building complex layouts. Android actually has other layouts, which have their own unique features. Some of which could be used to build complex layouts also. However, they have their own bottlenecks, hence the need to introduce a new layout.
These older layouts have rules that tend to be too rigid. As a result of this, the tendency to nest layouts become higher. For instance, the LinearLayout only permits placing views linearly, either horizontally or vertically. The FrameLayout places views in a stacked manner, the topmost view hides the rest. The RelativeLayout places views relative to each other.
The release of a much more diverse and flexible layout was long overdue.
Bottlenecks of other layouts
One of the major bottlenecks endured in using previous layouts is having a deep view hierarchy. A deep view hierarchy arises when your layout is deeply nested. Deeply nested in the sense that layouts are embedded in other layouts.
A deeply nested layout looks like this:
<?xml version="1.0" encoding="utf-8"?>
In the above sample, we have a parent linear layout that contains a LinearLayout, a TextView, and another LinearLayout.