First Impressions of Android’s new ConstraintLayout

This article was originally published to Medium on May 31, 2016 · 4 min read

After Google IO, the Android GDE team got together to gather our thoughts about the most significant announcements from the conference. This is a summary of our thoughts about the new ConstraintLayout.

Some of the Andoid GDEs at post-IO gathering

At IO 2016, one of the more exciting announcements (especially for UI focused developers) was a new layout container and tool named ConstraintLayout (CL).

It’s early days for this tool. It is currently only available from the Canary channel of Android Studio. We expect it to mature quickly (they have already pushed their first update within the first week of release). We expect that eventually this layout type will be the default used for all top-level interfaces.

ConstraintLayout View Type

High-level Constraint Layout basic concepts

On a basic level, the new CL is just another simple XML layout type. It is not much different then other layouts you are probably already using (like RelativeLayout or LinearLayout). In fact, the CL can be used just like any other layout — it can be nested into other layouts, and even be used back to API 9. It is possible to view and edit the XML, but when we asked Googlers about this, they all answered: “You can, but why would you want to?”. This is primarily designed as a visually oriented tool.

The new layout is based on Constraints. These describe relationships between your views (or the screen), in a responsive nature. These attributes are very similar to the ones used with RelativeLayout (such as: android:layout_alignParentBottom=”true”).

If CL was just another layout container, there wouldn’t be too much to be excited about. But, CL is much more then just another layout type. It is an all new layout container designed to help developers create complex layouts that are optimized to render quickly. This is because it generates flat view hierarchies (read this article to review why this is important). This will really help developers create apps with complex interfaces, that get displayed quickly and without visual jank or pauses, that consume minimal memory resources. #perfmatters ;-)

This should get rid of the newbie question of “What layout should I use here” which the answer comes from experience (and failure). There is now a top level container that is designed to be the main one everyone should use always

ConstraintLayout Editor

In addition to the new layout type, there is also an all new visual editor to make creating these new layouts easy. The visual editor is intended to be the main way developers interact with their layouts. We aren’t going to cover usage of this tool in detail, because Rebecca already did a great job in this article, and there is documentation.

This is primarily designed as a visual tool, that was re-written from scratch, and is not an evolution of the existing visual editor

The new visual editor is interesting and fun to use. It consists of 3 main tools:

• Visual Editor — shows how your UI will look on specific screens and with specific themes applied

• Blueprint Editor — this is where people will spend most of their time, and is where a developer defines the relationship between their views

• Properties editor — apply specific attributes to a view you have selected.

Most of the developer interaction will be done using the Blueprint view. If you have the “Autoconnect“ button enabled and drag a view (like a Button or a TextView) onto the screen, the editor will automatically create Constraints (connections to other objects or the edge of the screen). There is a nice animation displayed while the constraint is created.

It is easy to delete and re-create constraints, and there is even an “Infer Constraints” button that will guess the constraints for your entire layout. When we tried this, it worked as well as can be expected. We think developers will use this to get started then adjust the constraints to fine-tune the details.

Overall all the editor is very straightforward to use. If you are used to building UIs with RelativeLayouts, this will seem very familiar. If however, you have been nesting a lot of LinearLayouts to build complex layouts, well, shame on you, this will be a great time to learn how to build responsive layouts the right way.

Where is this all going?

It is very early days for this tool. As with all things Google we are approaching this with cautious optimism.

We welcome the day when designers can understand basic concepts of Android view layouts, and even use the tools. The possibility to export layouts from prototyping tools (like Sketch, or Adobe Illustrator) are likely to be coming (either directly from Google or from the community).

It is currently possible to import existing layouts directly into the tool. This is likely something worth doing at some point, as this should improve the overall performance of every app. At this time, we think it is wise to let this mature a bit before using this widely in production.

We were concerned about how the switch to visual oriented development will effect development workflows. For instance, how are changes to layouts tracked for code review?

The Blueprint editor shows animations when creating Constraints. They are slow, and you have until the end of the animation to stop the constraint generation. It seems like this will be tedious to watch (hopefully there is an option to turn animations off).

Conclusion

We are excited for this new UI concept, and think using ConstraintLayout will be very useful in the near future.