The simplest of Constraint Layout helpers. Just controls visibility of multiple (or one) referenced views. Tends to be useful if you want to set multiple views to VISIBLE or GONE state, but don't want to wrap them in some ViewGroup wrapper so your XML structure can stay flat.
For referencing views inside Group constraint_referenced_ids attribute can be used.
app:constraint_referenced_ids="text,button"
In the following example, text's and button's visibility can be controlled by setting visibility to Group helper. E.g.
In case where one view is referenced from multiple groups, the declaration order in XML will define the final visibility (last group in XML has last word).
Practically the same as Group helper, but changes of translation, scale and rotation are supported.
E.g. rotating multiple views can look like this
Invisible helper object for Constraint Layout (it's never displayed on device). Main purpose of guideline is to place the child of Constraint Layout at some specific location (e.g. 100dp from screen start or 25% from screen bottom...)
Guideline can be either Vertical (zero width, height of parent Constraint Layout) or Horizontal(width of parent Constraint Layout, zero height). You can use orientation attribute for defining orientation of Guideline.
The most important property of Guideline is it's position. Guideline can be positioned in 3 different ways using layout_constraintGuide_begin, layout_constraintGuide_end and layout_constraintGuide_percent attributes. These are affected by orientation also.
Any direct child of Constraint Layout can be constrained to Guideline, but Guideline on it's own cannot have any constraints. Position of guidelines is only determined by mentioned attributes. Here is the example of Button positioned to 25% from top of the screen.
Barrier helper is similar to Guideline. Main difference between them is that the Barrier is flexible. It takes multiple views in constraint_referenced_ids attribute and creates virtual guideline based on the most extreme view from referenced views (most extreme view is the widest or the highest view). If width (or height) of most extreme view changes during runtime, barrier will automatically move according to it. Every Barrier needs to have barrierDirection attribute.
Barrier tends to be useful when you want to constraint view below (or above, at the end, at the start) of another views. E.g. usecase, when button needs to be under textViews, no matter how long they are.You should notice that, you can constraint views to Barrier (unlike to Guideline).
Did you like this article? Read more in the second part! Follow me on LinkedIn and stay in track.
