The constraint layout was first introduced at Google I/O 2016 to raise auto layout for android, what it is actually, and how it'll impact layout design.
Its effectiveness is indisputable which is why many developers love and use ConstraintLayout to design UI. But using it effectively is also something to keep in mind. Today I will share the most effective and flexible way to use ConstraintLayout. First, we need to learn the pros and cons of ViewGroup.
1. ViewGroups and their pros and cons
FrameLayout: This is a simple ViewGroup that only provides a screen area, often used it to display a single child View. If you put in it many child views, then by default these child views will be stacked on top of each other
Pros
It's lightweight and pretty simple to use
Is the ViewGroup with the highest performance (The reason people often put Fragments on FrameLayout)
Cons
Difficulty in designing complex interfaces
LinearLayout: This is a ViewGroup that will arrange child View elements in two forms, column or row form, with no view overlapping any view.
Pros
Easy to use sequential layout design
Design complex interfaces
Can develop UI for adapt any screen size
Cons
For complex views, many nested views will be used, but google suggests that I should only use a maximum of 10 view groups
Some of Google's recommendations are as follows:
Useless parent - A layout with children that has no siblings, is not a ScrollView or a root layout, and does not have a background, can be removed and have its children moved directly into the parent for a flatter and more efficient layout hierarchy. Deep layouts - Layouts with too much nesting are bad for performance. Consider using flatter layouts such as RelativeLayout or GridLayout to improve performance. The default maximum depth is 10.
RelativeLayout: This is a ViewGroup that allows child views to be aligned with other child views and at the same time contact the parent view through align and margin parameters.
Pros
Able to design complex layout
Overcoming the drawback of LinearLayout's nest view to design views with less view group
Cons
More complex design
Not really strong in adapting to multiple screens
Take more resources for measure with complex view
Note:
In a talk at Google I/O 2013 (Writing Custom Views for Android), The host clarified the misunderstanding that caused everyone to start using RelativeLayouts for everything. A RelativeLayout always has to do two measure passes. Overall it is negligible as long as your view hierarchy is simple. But if your hierarchy is complex, doing an extra measure pass could potentially be fairly costly. Also if you nest RelativeLayouts, you get an exponential measurement algorithm.
2. Why was constraintLayout born?
From the basic assessment of the view groups in part 1 you can see
LinearLayout is easy to design and can develop UI on many screen sizes but has the problem of creating many nested views during development
RelativeLayout solves the problem of nested view of LinearLayout but is not powerful in multi-screen development
Since then, to build a UI that can minimize nested statements and adapt to multi-screen processing, most developers use a combination of both linear and relative in the UI construction process.
And that's also the reason why ConstraintLayout was born inheriting the strengths of both Linear and Relative, I would like to ask permission not to share it thoroughly because it has been mentioned a lot by Google, you can refer to an article below:
I would like to summarize some of the advantages as follows:
We can design the user interface without touching the xml part of the code, to be honest, I feel google is going in the way of UI design in iOS apps, it makes sense if you are used to UI development in iOS, but in its relative layout, it's hard to set constraints without touching the xml design.
ConstraintLayout has the dual power of both RelativeLayout and Linearlayout: Set relative position of views (like Relative layout) and also set weight or percentage for dynamic UI (can only have in Linear Layout).
A very efficient use is to group elements by forming a sequence. This way we can form a group of views that can all be placed the way we want without adding another layer of hierarchy just to form another group of views.
3. Is ConstraintLayout really as powerful as we think?
Correct but it is half the truth. Let's pay attention to the horizontal list of data shown below and evaluate how they are different
Do you feel that the list items on the left when scrolling horizontally seem faster and smoother than the right?
A fact here is that these 2 screens are similar in terms of handling logic but the only difference is that the item on the left screen is built using LinearLayout and the right screen is ConstraintLayout.
So what google above is really true?
To answer the question, you guys and I make a few basic tests below to find the answer
Test case 1
Test case 2
Test case 3
Test case 4
4. Conclusion
My tests show that ConstraintLayout is not necessarily a good solution for simple layouts, especially in list display layouts that need to draw many views in a short time.
So when should we use ConstraintLayout and when to use other layouts?
There is no set standard here, but from my experience, I have some rules when designing layouts as follows:
- Use ConstraintLayout to design main layouts such as Activity and Fragment
- Don't use ConstraintLayout in ConstraintLayout it's a bad practice instead you can use LinearLayout if you must include a layout
- Use LinearLayout when designing items for lists or custom views if the layout is not too complicated (Not more than 3 hierarchies) and does not violate Google's 10 nested view rule.
Note:
The numbers above may vary depending on your environment, but from the above numbers we can sort the performance of ViewGroups as follows: FrameLayout > LinearLayout > RelativeLayout > ConstraintLayout
Comments