MotionLayout – Collapsing Toolbar – Part 1 – Styling Android

MotionLayout – Collapsing Toolbar – Part 1 – Styling Android

- in Android
Comments Off on MotionLayout – Collapsing Toolbar – Part 1 – Styling Android

At Google IO 2018 ConstraintLayout was introduced and the most important new addition was MotionLayout which provides us a tremendous new software for structure animations. Nicolas Roard has already printed a wonderful introduction to MotionLayout and I might extremely suggest giving learn to know the fundamentals and parts of MotionLayout. On this quick collection we’ll take a look at how we will use MotionLayout to create a behaviour that we must always all be conversant in: a Collapsing Toolbar.

Earlier than we start it’s price mentioning that there’s nothing by any means flawed with utilizing CollapsingToolbarLayout inside a CoordinatorLayout to attain this behaviour. Furthermore, if you have already got that working in an app then there’s little to be gained by altering. That mentioned, which CoordinatorLayout offers some actually helpful behaviours, attempting to tweak them and even create your individual customized behaviours is sort of troublesome. It’s these conditions the place MotionLayout might present far higher flexibility and, my early experiments would recommend, a far simpler path to reaching what you need. Moreover, MotionLayout opens up new behaviours that may be actually troublesome with CoordinatorLayout.

One of many key variations between MotionLayout and most of the different animation frameworks on Android is that view animations and property animations run for a given length. Whereas it’s potential to specify the length and cancel a operating animation, it’s not potential to regulate a operating animation based mostly upon consumer enter. For instance, a Collapsing Toolbar ought to increase and collapse based mostly upon the consumer scrolling, and the precise animation ought to comply with the consumer’s drag. That is merely not potential with these frameworks.

Let’s start by looking on the behaviour that we’re attempting to emulate. Right here’s a Collapsing Toolbar which is applied utilizing CollapsingToolbarLayout from the Materials Parts Library and CoordinatorLayout:

The behaviour that we get from that’s this:

Getting an in depth approximation to that utilizing MotionLayout is reqlly fairly straightforward. We first begin with our structure file:

That is basically a typical structure that we’d create utilizing ConstraintLayout, the one distinction being the mum or dad is definitely MotionLayout (which extends ConstraintLayout, so we will use MotionLayout similar to a standard ConstraintLayout). The MotionLayout has an attribute named app:layoutDescription which is the place the magic occurs. I’ve intentionally used primary View sorts right here to make it clear that there’s no behaviour coming from the Views themselves. In an actual app I might be utilizing AppBarLayout and Toolbar.

If we view this within the design software, we will see that this represents the structure when the toolbar is in its expanded state:

I simply talked about that the magic occurs within the file which is referenced within the app:layoutDescription attribute, so let’s check out this:

So that is all new to MotionLayout and doubtless appears just a little scary, so let’s break it down in to smaller, extra manageable chunks. The mum or dad structure is a MotionScene, and this holds the entire parts which outline the transition. It comprises two ConstraintSets with every ConstraintSet defining a set of constraints which symbolize a hard and fast state of the structure. We’ll take an in depth take a look at these in a second, however for now it is sufficient to perceive that one ConstraintSet represents the toolbar in its absolutely expanded state, and the opposite represents the toolbar in its absolutely collapsed state.

The Transition component defines what these begin and finish states are and the way the transition between the 2 is managed by consumer interplay:

The app:constraintSetStart and app:constraintSetEnd attributes are references to the 2 ConstrainSets defining the expanded and collapsed states. The OnSwipe component binds this transition to the consumer dragging on the RecyclerView in the principle structure file that we checked out earlier. Within the expanded and collapsed states, the highest fringe of the RecyclerView is at a special location as a result of it’s constrained to the underside fringe of the ImageView with the ID toolbar_image, and this transition is all about controlling that variable location, and that management comes from the consumer dragging on the RecyclerView. There’s an enormous quantity of labor being carried out for us in these 10 strains of XML. The internals are fairly complicated as a result of it’s being pushed off the scrolling behaviour of the RecyclerView.

To know the 2 ConstrainSet definitions, let’s first contemplate that there are solely two issues that we have to management. The primary is the ImageView which represents the background (with ID toolbar_image) adjustments top, and the picture opacity adjustments. By altering the peak, it should additionally trigger the highest of the RecyclerView to maneuver as a result of the latter is constrained to the underside of this ImageView. The second view is the TextView which comprises the title (with ID title) which must each transfer and alter dimension.

Let’s first take a look at the delta between the 2 states of the ImageView. Within the expanded state it’s this:

For the collapsed state is thus:

There are solely two small variations right here. The primary is the layout_height, and the second is a CustomAttribute named imageAlpha. The title CustomAttribute might indicate that we’re utilizing a customized View, however that’s not the case. Though we’re utilizing a typical ImageView, the principle attributes on the Constraint component in a ConstraintSet could be any of the attributes of ConstraintLayout.LayoutParams or any of the attributes of View, however for subclasses of View similar to ImageView we have to use a CustomAttribute which is definitely very related in precept to ObjectAnimator. On this case, we’re adjusting the imageAlpha property of ImageView. After all you can too use this method for customized attributes on customized Views, similar to ObjectAnimator.

The TextView is definitely actually related. The expanded state is:

And the collapsed state is:

Right here we’re utilizing view scaling to change the dimensions of the TextView. If you happen to’re questioning why I opted for view scaling fairly than altering textSize through a CustomAttribute, the reason being that altering the textual content dimension and re-rendering it’s computationally far more costly than merely making use of a change, so we’re a lot much less more likely to get jank in out transition utilizing this method.

The opposite factor we’re doing is altering margins, and the way the TextView is positioned relative to the ImageView. Within the collapsed state it’s centred vertically, and in expanded state it’s aligned to the underside, so the TextView will extra relative to the dimensions of the ImageView.

If we use that structure rather than the CoordinatorLayout implementation that we began with we get this behaviour:

That’s really fairly shut, however the eagle eyed might spot that there’s a slight distinction between that and the CoordinatorLayout method that we checked out at first: Within the CoordinatorLayout transition the picture fade doesn’t occur uniformly in the course of the transition because it does with the MotionLayout model. Within the concluding article on this collection we’ll take a look at a few of the finer-grained management we will get with MotionLayout.

The supply code for this text is out there right here.

© 2018, Mark Allison. All rights reserved.

CC BY-NC-SA 4.0 MotionLayout – Collapsing Toolbar – Half 1 by Styling Android is licensed underneath a Inventive Commons Attribution-NonCommercial-ShareAlike Worldwide License.
Permissions past the scope of this license could also be out there at