Composition over Inheritance: Adding a Material Speed Dial to a Floating Action Button
Material Design is an excellent design and visual language on Android, it is also very ambitious, which makes the actual implementation of its guidelines without dropping any of the visual flair a daunting exercise. To this end, the Android community relies on multiple 3rd party libraries and codes samples that provide implementations of these Material patterns, however most of them require inheritance on a customView class that makes it difficult to add more attributes to.
Take for instance, your UI/UX designer initially requests that the FloatingActionButton in your application have a speed dial behavior on a particular screen. To do this, you have a couple of fantastic libraries to choose from:
You pick either of those 2, and you get exactly what is promised; excellent feature rich libraries with well designed APIs. Things are going great till your UI / UX designer decides that under some arcane condition, the FloatingActionButton should first be expanded when the user first enters the screen, then collapse after 2 seconds and resume its speed dial behavior. Furthermore, if the FAB is extended when the user clicks it, it should collapse first, then show the speed dial.
This poses a challenge because these libraries require you to use their own custom Views that are more or less black boxes as far as their standard APIs are concerned. You’d need to peer into their internals to see what’s actually going on and see if you can work around whatever limitations you may have.
This is the classic argument against inheritance for adding extra functionality to a class. None of the elements in a speed dial actually require you to extend from the View whose click should trigger the speed dial. The speed dial rather should either be a function, or independent class which you can call on to get the desired behavior, completely independent of the View clicked.
That being said, let’s go about creating a FAB speed dial that is completely independent of the anchor View for the speed dial action. The requirements are:
- The speed dial should work independent of the
Viewsubclass of it’s anchor - The anchor
Viewneeds to meet the requirement that it initially appears expanded, then collapses itself along with collapsing itself when clicked, and subsequently showing the speed dial.
Fortunately, the Material Components for Android provide an excellent base to build upon for sort of thing. In this case, the anchor View to provide the behavior shall be the MaterialButton. It may be tempting to go with the ExtendedFloatingActionButton as it gives expanding behavior out of the box, unfortunately it suffers the same inheritance problems outlined earlier. Expanding and collapsing behavior can be composed independent of the MaterialButton. The implementation of ExtendedFloatingActionButton actually subclasses MaterialButton internally to build upon, which makes the original FloatingActionButton class rather duplicitous and redundant. We hope to achieve something close to the below:
The crux for the speed dial behavior will be Android’s PopupWindow class which is amazing for displaying an arbitrary View in a window and having full control over its positioning. A Dialog is a bit clunky in this regard as it does a lot and wraps your custom View in other Views that inadvertently mess up the positioning you’d prefer. First, we define a method that lets you pop any View over any other View:
This method creates a wrapper FrameLayout that fits the whole screen, and adds the View to be popped over the anchor relative to the anchor only after it has been measured. This is necessary because the speed dial can have an arbitrary height and width, and these values are needed for pixel perfect placement after layout.
With the above, we can define the pop up layout and show it relative to the anchor. Since the speed dial should not have more than 5 items, a LinearLayout with dynamically added views will suffice.
Notice that the parent LinearLayout mirrors itself around both the x and y axes. This is because the LinearLayout stacks children from top to bottom and left to right. For a speed dial however, the inverse is required, children items stack from bottom to top, and are right aligned. Rather than deal with LayoutParams and gravity for child views, it’s easier to just mirror the parent, and the children displayed within it.
On the animation front, there are two things going on:
- The pop up window fade in animation: defaults to the system provided
android.R.style.Animation_Dialog. This can be overriden if desired. - The speed lateral translation of each item in the speed dial which is set using the
layoutAnnimationproperty of the parentLinearLayout, which is also user customizable. TheLinearLayoutwill run this animation on each child that is added to it.
At this point all that is left is to animate the rotation of the MaterialButton and to give a halo as it opens up the speed dial. This is the most involved part, and also the part that may need the most customization, and as such, is outside the core behavior to show a speed dial.
In the following implementation, the entry point is a View.OnClickListener that can be attached to any View. The moment the View is clicked, the instance verifies the View clicked is a MaterialButton and is in a state to run, then goes ahead to animate the, stroke, rotation and transparency to give the desired effect. It knows nothing of the expanding or collapsing behabior of the FAB. Externally, if the MaterialButton is an ExtendedFloatingActionButton, a callback can be attached to it to call performClick on itself after it the collapse has finished animating. In my case, I do the same with a custom class I wrote called a FabExtensionAnimator.
With the above, the output looks like this:
With the above, the speed dial is completely independent of whatever View is attached to. If a new Material Design spec came out, the behavior can be easily moved to any View with no overhead. In the case where both the extension of the FAB and the speed dial are both independent of the FAB, things are even better as there’s a much higher separation of concerns.
The implementation in the host fragment follows:
The adage rings true, whenever you can, favor composition over inheritance.
You can find the sample code for this post in it’s entirety here:
