ConstraintLayout vs "Traditional" Layouts
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 ViewGroup
s, 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
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.
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