ConstraintLayout vs "Traditional" Layouts

Question

I am just wondering when to choose the CoordinatorLayout over "Traditional" Layouts or are they (or at least some of them) going to be deprecated?

The question ConstraintLayout vs CoordinatorLayout already showed me that the CoordinatorLayout still has its right of existence. I'd imagine that the FrameLayout is still a better choice than the ConstraintLayout when there is only one child View.

But what's about the other Layouts?

I am personally so accustomed to writing layouts by hand in xml so transitioning to the ConstraintLayout is very hard for me. Furthermore answers to this questions would really interest me:

Does the ConstraintLayout have better performance then a nested Layout? If it is the case, at which point does this occur (which level of nesting)?

Answer 1

I will try to answer for your questions. And I assume you are talking about the layouts in Android development.

First of all, you can still use all layouts Relative, Linear, Frame and etc. They are not depreciated yet by Android platform. I know from my experience that ConstrainLayout is a bit hard to code manually in xml but if you use the constraint layout, Android Studio provides pretty cool tools for "drag and drop". The tools can nearly do what you usually do in XML manually. Besides, they are very productive and save lots of your time.

In terms of performance, one of the deadly and expensive operation in Android is rendering the views, specially when the complex tree views are used inside listview or recycler views. Complex tree views, which are usually designed with linear or relative layouts are expensive to compute and render. Constraint Layout saves and helps solving these problems.

I would highly recommend looking thru the Android official documentations for more reference in the following link.

https://developer.android.com/training/constraint-layout/

Answer 2

I'd imagine that the FrameLayout is still a better choice than the ConstraintLayout when there is only one child View.

I think the power of ConstraintLayout really takes place when you go beyond simple layouts. I think the objective (at least for me) is to flatten your complex layout as much as possible. By using the ConstraintLayout's full suite of help such as invisible constraint views like Guideline and Barrier, to specifying vertical/horizontal layout_constraintVertical_bias and view distributions using layout_constraintVertical_chainStyle.

If you have a complex view that has nested ViewGroups, start using ConstraintLayout.

I am personally so accustomed to writing layouts by hand in xml so transitioning to the ConstraintLayout is very hard for me.

This is also true for me. I used to write layout xml files by hand, and i still do with ConstraintLayout. The editor is much improved, and i use it mostly to make sure the constraints look right. There was a bit of lead time to get used to writing the xml by hand, but once you get going, i am a lot more confident with it then the editor adding stuff that you might not be aware of.

Another reason to use ConstraintLayout: A great way to implement animations without too much hand coding by using ConstraintSet. Some great example: https://robinhood.engineering/beautiful-animations-using-android-constraintlayout-eee5b72ecae3

Answer 3

I am just wondering when to choose the CoordinatorLayout over "Traditional" Layouts or are they (or at least some of them) going to be deprecated?

So ConstraintLayout is useful, but (for now) it is not required for Android app development, any more than LinearLayout and RelativeLayout are. And, because ConstraintLayout is a library, you will need to take some additional steps to add it to your project (com.android.support.constraint:constraint-layout artifact in your dependencies closure of your module’s build.gradle file), and it adds ~100KB to the size of your Android app.

I am personally so accustomed to writing layouts by hand in xml so transitioning to the ConstraintLayout is very hard for me.

Drag and drop GUI builder

Google is trying to make life easier to developers and make they work faster and more productive so they continue improving drag-drop GUI builder. However drag-and-drop gestures, the developer is only providing you with X/Y coordinates of a widget, based on where the developer releases the mouse button and completes the drop. With LinearLayout adding widgets is easy. With RelativeLayout is difficult for GUI bulder to handle drag-drop and probably you will have to dig inside the XML code to get things done. ConstraintLayout was created with GUI building in mind, to make it a bit easier to infer the right rules based upon where the developer happens to drop a widget.

Recomputing size and position

Changing the details of a widget often cause the sizes to have to be recomputed. For example nne change in TextView might cause that whole hierarchy to go through re-size/re-position work. If you have container inside container which is inside another container etc., means that parents re-size/re-position their children and that can be very expensive for deep hierarchies. So

Does the ConstraintLayout have better performance then a nested Layout?

Yes, ConstraintLayout is being designed with performance in mind, trying to eliminate as many pass scenarios as possible and by trying to eliminate the need for deeply-nested view hierarchies.

Huh,

for more you can take a look in a book about android development from CommonsWare. There using ConstraintLayout is explained in more details with comparation examples with another containers like LinearLayout, RelativeLayout etc. Really anatomy of android development.

Answer 4

You can continue to use other layouts for simple things (if they are not deprecated), but ConstraintLayout is faster, smarter and yes, have better performance than RelativeLayout.

You can check this answer that talk about differences between ConstraintLayout and RelativeLayout