Hey there, today we’re going to look at Android ConstraintLayout. It was introduced in Android Studio 2.2 and if I got it right, you can use design-only mode (no XML) involved to build beautiful responsive layouts. And that’s what we’re gonna find out today: is it easier, faster to build apps with ConstraintLayout. And what’s by no means less important – does it perform better?
Don’t know about you, but I gave up layout design mode after first few weeks of Android development. Found XML way faster, easier to read, you can just look at few lines of code and tell what it’s gonna look like. With ConstraintLayout it should be easier in Design mode on the other hand. So let’s get started.
Let’s see it from the ease of use point first. Impression after trying it out – this thing is not ready yet, but it’s beta 4 already. I don’t recommend to switch to Design Mode yet, this is so much pain.
Short properties view seems to accept only hardcoded margin values, and lint definitely taught us not to. You’ll have to open all properties view to change to to @dimen/. Loosing point on that already. And you’ll want to go to XML editor back and forth just to double check. Fortunately we can use XML editor with Preview which has all the same functionality as Design mode. You can enjoy the nice animation of constraint strings and still have control over code at the same time. That seems to be the way for me.
What about adding new views? It’s easier to do in XML. Alright, let’s start building something. There’s no purpose to make easy layouts. Let’s build something that can be done with RelativeLayout or nested LinearLayouts. I wander if it’s easier to do with ConstraintLayout or not. And is it easier to read what you get in result.
The end view is going to be this. And I’m not going to use Data Binding, just in case of any performance loses, if there are.
Lets build this layout with only LinearLayouts, just one FrameLayout as a wrap for top header. Space view between red circle and ‘Constraint Layout’ text with 0dp height and weight=1 to fill the whole thing . Took me about 3 minutes or even less, not much thinking needed to be involved. In result – 4 max levels of nesting (counting root) and not much of headache. What about performance? I used AndroidDevMetrics library to measure Activity creation time. Average of 170 ms. Layout time about 100 ms. Now lets make it a ViewPager with 5 pages created at the same time, just to give it more work. Average on 560 ms.
Now lets try to implement the same with ConstraitLayout only. Top seems to be not the problem, but those list items are. Each of them have listPreferredItemHeight and content centered. OK, let’s go nuts and make this row as a ConstraintLayout as well. At this point any Preview/Design mode will fail you, the only solution is to edit XML. Fortunately those attributes seem like from RelativeLayout. But IDE keeps changing my XML after me! I set width to match_parent, it sets it to some hardcoded value. Apparently this layout wasn’t designed for Text editor, this is like pair programming with a child, who messes up your code, nuts.
So my suggestion only to use ConstraintLayout as a root layout. Otherwise it’s a total mess. I decided to implement rows with LinearLayouts. Basically only place where I flattened the layout was headed and as I expected no performance improvements on that. 5 pages simultaneously takes average of 600 ms. Almost same as LinearLayout.
Was it worth it?
I actually managed to implement this layout with ConstratintLayout almost completely. The only nested one was LinearLayout for those ‘text one’, ‘text two’, because I needed them to be centered to a circle to the left. Although need to learn more about chains, they could be a solution
as a wrapper.
Now the most important – performance… The average on 100 ms for Layout which just like with LinearLayout although I flattened a lot. Tested on Nesux 6P, may need to test in on less performant phones. I could probably try to implement it with RelativeLayout, expect it to be something like Linear. The biggest performance drainer of Linear is weight, which cause to calculate each view dimensions twice. And nesting RelativeLayout inside of RelativeLayout. Did some of weight in LinearLayout solution, still performs better and much faster to implement with less paint.
I feel like it’s impossible to make something complex in Design Mode with it, constraint strings everywhere, hard to pick one that you want after you have just a few views in layout. In XML editor it keeps changing your attributes to some hardcoded. Since it’s so hard to build anything complex with it, it’s hard to get performance improvements from it. The question is what’s the purpose of it if not to simplify complex layouts.
I truly want to learn the base use cases to ConstraintLayout, it is has its pros for sure. Like you can flatten some FrameLayout with nested views. And will definitely write more about ConstraintLayout in future, where I feel like going to change my mind towards it
I wouldn’t want want to use this layout. Since everything can be done with Frame/Linear/Relative layouts in a way faster, less pain way. Why switch to ConstraintLayout? Performance improvement comes from eliminating deep nesting, but it’s way too hard to do complex layouts with it. I don’t see it as a big game changer yet. Will try to find the cases where it can improve layout and its key features more. Still they were promoting it so much, in this video, I tried it then, didn’t feel like it. And now almost six months later decided to check it out again, am I missing out on something. Definitely interesting layout and beginner friendly.
Thanks for reading and leave a comment what do you think about ConstraintLayout.