During this year Google I/O, a new entry in the support library family was added in the form of support-design.
The goal of this new library is to brige the gap between the theory of the Material Design specification and having actual available code to implement it.
The new library sits on top of the existing support-v7-appcompat package (which provides the base Material theming ability) and offers a bunch of new UI components and interactions from the specification.
Today I want to focus on two of those new elements that we will be using together: the infamous FAB (Floating Action Button) and
The FAB strikes back
If I had to pick one of the most iconic aspect of material design it would be the floating action button (henceforth known as FAB). It’s actually deemed important enough that the specification was expanded recently to have a dedicated section for it.
FAB are circular buttons containing a single icon (usually white or black) with a bright background (the color accent of your app for instance) and generally elevated above content (thus casting a shadow).
These FABs showcase the main actions that your app has to offer. As such, they are ones of the most important part of your UI and you should always pay special attention to get their interactions right.
Because FABs are so proeminent visually, they also offer a good opportunity to add pleasant touches to your app. In the word of the specification: “Take advantage of [FAB’s] visibility to create delightful transitions for a primary UI element.”
The support design library offers a default implementation of that UI widget that’s backward compatible with older versions of Android that don’t have elevation/shadow support or round clipping in the form of the FloatingActionButton widget which is a subclass of the classic
Here I want to focus on one of the documented FAB transition: morphing. This transition is used to alternate between two main actions for a single FAB depending on the context:
To implement this, you can create a simple subclass of the default FAB that let you also specify a secondary set of icon and background and then create a custom animation to alternate between the two:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89
You can then instantiate this new class directly in your XML layout:
1 2 3 4 5 6 7 8 9 10
For that interaction, the icon itself is normally not supposed to scale but since the widget is based on
ImageView it’s impractical right now to separate the two layers to animate a counter-scale for the icon.
I imagine that a default implementation of the documented FAB interactions will likely find its way into the library at some stage but in the meantime it’s very easy to cook them up yourself like above.
You may also have noticed in the video that the second state of my FAB uses an animated selector. This is done by augmenting the
SwitchableFab class to track the checkable state (as I have already demonstrated).
In any case, you can find the full implementation of that selector and checkable changes in Moyeu repository.
CoordinatorLayout, the missing orchestra conductor
Another interesting type that support-design brings is CoordinatorLayout.
On the surface it doesn’t seem to do much, it’s intended as a wrapper around your existing UI that behaves like a
FrameLayout from a layout perspective. The true value of
CoordinatorLayout is found on its child views.
Just like its name imply,
CoordinatorLayout serves as a central conductor for more complex transitions that your app UI may be doing especially when involving several floating views like the aformentioned FAB or snackbars.
The core working of the class relies on so-called Behaviors that can be set on any child views of the
CoordinatorLayout. In a behavior implementation, views can define if they want to be dependent on some other views and get a callback when that other view state (position, size, etc…) changes.
Behaviors can be attached to views in a multitude of ways but here is how you can declare it directly in your layout XML:
1 2 3
Here I made a custom behavior that allows me to automatically track the state of my application bottom pane as it appears/disappears and is dragged by the user so that the FAB automatically stick to it and change its state when the pane is initially expanded (using the transition animation we saw earlier):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Dead simple right?
CoordinatorLayout can also be used to implement other user interactions like swipe-to-dismiss or other scrolling techniques (like collapsing toolbars). Checkout the provided SwipeDismissBehavior and AppBarLayout.Behavior for more information on those scenarios.