At Google IO 2016 Google announced a new Android layout named ConstraintLayout. Despite the initial release being labelled as an Alpha release, it is actually pretty stable (with a few caveats). In this series of articles we’ll take a look at this new layout-kid on the block and try and get some insights in how best to use it.
In the course of this series we’ve taken quite a long look at various aspects of ConstraintLayout to get a proper feel for how it works, and indeed, why it has been created in the first place. However there is one fundamental question that we need to consider: Should we actually be using it in “real” projects yet? The short answer is “No”, but firmness of that “No” is diminishing with each release.
Let’s first consider why I have said that we shouldn’t actually be using this in production projects: Romain Guy has repeatedly stated that it is not production ready yet, and that it why it is still tagged as an alpha release. ConstraintLayout itself is pretty stable, but it is the visual editor which is a little less stable, so why not use ConstraintLayout as the editor does not run on the users’ devices? There are a couple of main reasons:
Firstly: Performance. Wolfram Rittmeyer has written an excellent post where he explores many aspects of ConstraintLayout including performance and found that it didn’t fare too well in some comparisons with LinearLayout and RelativeLayout. However that was based upon the alpha 3 release of the library and, at the time of writing, we now have alpha 4 which tackles a lot of performance issues. I haven’t seen any comparison data to see how well alpha 4 compares to alpha 3 performance-wise, but Nicholas Roard (one of the ConstraintLayout developers) is saying that it should perform much better.
The second reason that ConstraintLayout is still in alpha is that some of the functionality and APIs are not finalised. One example of this is the abilty to use define an aspect ratio for a view using the app:layout_constraintDimensionRatio attribute. The reason that I haven’t covered this in this series is because it is not yet (at the time of writing) supported by the visual editor (the suggested method of editing ConstraintLayout) . While this will be an extremely useful feature of ConstraintLayout (and I’ll be sure to properly cover it in due course) the fact that it hasn’t yet been surfaced to the visual editor would suggest that either the functionality or API are not yet finalised.
One of the other main reasons not to use ConstraintLayout has just been resolved. Up until Android Studio 2.2 alpha 5 ConstraintLayout was bundled in with Android Studio itself and this made it tricky to use if you were running builds on a CI server. Those with their own Artifactory or Nexus instances could manually upload the ConstraintLayout libraries and make them available to the CI that way. Those without would need to manually install them to the local m2 repo on the CI itself. All of this was a lot of effort, particularly for Alpha releases for which we are receiving regular updates.
The good news is that with Android Studio alpha 5 onwards ConstraintLayout has been moved to its own m2repository – the same mechanism by which the support libraries are distributed. This makes things much easier for CI users as most CIs have mechanisms in place to keep the support libraries up-to-date and so ConstraintLayout can now be kept up-to-date in exactly the same manner.
So that’s where we’ll leave ConstraintLayout. For now, at least. There is already an awful lot to like about ConstraintLayout and I’m really looking forward to being able to use it in production projects. The team working on it are doing an amazing job, and a full release cannot come soon enough for me. And, of course, if there are any interesting additions they’ll be covered here!
© 2016, Mark Allison. All rights reserved.
Copyright © 2016 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at http://blog.stylingandroid.com/license-information.
Very informative series.