WAS IT LOGICAL GROUPING OR JUST A POSITIONING CONTAINER? (THINK ABOUT CHANGES IN DESIGN REQUIREMENTS) ‣ ARE WE REALLY IN LOVE WITH CREATING LAYOUTS IN XML? (PROBABLY, BECAUSE WE TRIED EDITOR AND PAINFULLY FAILED) WHY SHOULD I CARE OR WHAT WE HAVE NOW
app:layout_constraintHorizontal_bias="0.75" app:layout_constraintVertical_bias="0.75" /> </android.support.constraint.ConstraintLayout> CENTERING IN PARENT AND BIAS
size becomes zero (a dot, essentially). All “out-going” margins become zero as well. Not necessarily desirable result (do we really need all these margins?) layout_goneMargin* attributes let us control margins to the target view which visibility is View.GONE w/o GONE margin attribute w/ GONE margin attribute
edges aligned to top edge of the button at the center Middle chain Spread inside style, left and right buttons top edges aligned to guideline (see in the next slide) Bottom chain Packed with bias style, left and right buttons top edges aren’t aligned (will jump to layout’s top at runtime) Vertical chain Composed from buttons at the center of each horizontal chain
(i.e. lightweight GridLayout) No need to use Percent*Layouts, e.g. on the blueprint to the right, screen is divided into four equal sections (50% guidelines) Allows you easily implement fancy animations (later)
… /> <TextView android:id="@+id/topTextView" android:text="A little bit longer text” … /> <TextView android:id=“@+id/bottomTextView" android:text="Now this text is the longest” … /> <android.support.constraint.Barrier android:id="@+id/barrier" app:barrierDirection="end" app:constraint_referenced_ids=“topTextView,bottomTextView” … /> </android.support.constraint.ConstraintLayout>
ConstraintSet() cs2.clone(this, R.layout.activity_main_top) var alternative = false playBtn.setOnClickListener { TransitionManager.beginDelayedTransition(constraintLayout) val constraint = if (alternative) cs1 else cs2 constraint.applyTo(constraintLayout) alternative = !alternative }
it to animate text color, elevation etc Animation will be performed only on direct children. Additional motivation to avoid nested view hierarchies If you have changed ConstraintLayout params dynamically and then trying to run animation, the attributes will revert back to the original values
MATCH_CONSTRAINT, the default behavior is to have the resulting size take all the available space. Several additional modifiers are available: - layout_constraintWidth_min and layout_constraintHeight_min : will set the minimum size for this dimension - layout_constraintWidth_max and layout_constraintHeight_max : will set the maximum size for this dimension - layout_constraintWidth_percent and layout_constraintHeight_percent : will set the size of this dimension as a percentage of the parent FROM CONSTRAINT LAYOUT DOCUMENTATION 1.1.X
android:text="ConstraintLayout allows you to create large …” app:layout_constrainedWidth=“false" /> </android.support.constraint.ConstraintLayout> ENFORCING CONSTRAINTS IN WRAP_CONTENT 1.1.X
android:text="ConstraintLayout allows you to create large …” app:layout_constrainedWidth=“true” /> </android.support.constraint.ConstraintLayout> ENFORCING CONSTRAINTS IN WRAP_CONTENT 1.1.X
is turn on/off feature. Creates constraints to parent layout (when appropriate) Constraints inference scans the layout and tries to infer best possible set of constraints to parent and sibling views (sometimes it needs help)