ActionBar / Backward Compatibility / DesignLibrary / FloatingActionButton / Ripple / TabLayout

Design Library – Part 5

At Google I/O 2015 the Material Design Support Library was announced, and with it creating material apps targeting API levels below API 19 suddenly got a lot easier. In this series we’ll look at taking the RSS Reader app that we used as a basis for the Material series, and re-write it to make full use of the new Design Support Library. In this article we’ll look at how well the new components introduced in the design support library behave on older versions of Android.

I first started wondering about how the design support library would work on older versions of Android after seeing Vandana Shah, Ian Lake, and Chris Banes presenting the design support library at Goole I/O 2015. I noticed that one of the slides was showing a nice Ripple when a tab was tapped in the TabLayout and thought that it was unlikely that this could be back-ported. I was able to ask Chris about this and he was kind enough to share some insights in to areas which caused them some problems with backwards compatibility, and these insights are the basis for this post.

Let’s start with the very thing that I first noticed – Ripple touch feedback. The reason that I thought this difficult to back-port was because of how they are rendered. One of the underlying changes in Lollipop was the render thread which works in parallel to the standard UI thread. The render thread allows animations (such as Ripples) to be rendered on a separate thread to other UI tasks to ensure a high frame rate for the animation which will consequently appear very smooth to the user. Typically a touch event will trigger a whole bunch of stuff on the UI thread (such as switching Activities, or inflating a new layout) so trying to do on the same thread as all this is going to make the Ripple animation frame-rate suffer quite badly. The lack of a dedicated render thread pre-Lollipop makes a back-port of Ripples extremely unlikely.

So what touch feedback do we get on a pre-Lollipop device? Let’s try things out on Jelly Bean and see how things look:

That’s pretty good! Take a look at the touch feedback on the tabs and there’s no Ripple, but there certainly is normal pre-Lollipop-style touch feedback. It’s a little faint but that is because of the choice of colour we used for colorControlHighlight in our theme (which is shared with the selected state in our navigation drawer) – it would be easy to rectify. That’s the only real difference that the user will (probably not) notice.

Aside from the difference is touch feedback is there anything else? Actually there is another very subtle difference, but it’s too subtle to see even when you’re looking for it, and that is the shadow rendering on the FAB. Lollipop introduced some powerful shadow rendering along with elevation and translationZ which simply aren’t available pre-Lollipop. You wouldn’t know it though – the shadow rendering is pretty good. Even the lift-to-touch behaviour is there and looking good.

So what about if we now try this on an even older version of Android – Gingerbread (API 10):

We have some obvious rendering issues with some of the content in our WebView, but that’s nothing to do with the design support library, so let’s ignore it.

The main thing that we can see is that text colour of the text in the Toolbar and TabLayout is wrong. My guess would be that there is simply no concept of a light theme with a dark ActionBar simply because there was no such concept of an ActionBar before API 11 Honeycomb.

The other thing of note is that we are not getting the FAB moving as the Snackbar appears. Chris explained that this is because there is no translationY before Honeycomb (API 11) so it was not possible to implement the property Animators required for this.

All in all, that’s still pretty good. We still get all of the other nice stuff that we’ve been looking at in this series and where there are some aspects which are not supported, the behaviour degrades as gracefully as possible and the result is still extremely useable.

All in all the design support library is extremely powerful and gives us an extremely useful set of new tools which are both easy to implement and are nicely backwardly compatible. Huge thanks to Chris and the rest of the team behind the design support library.

We’ll end this series for now simply because I’m running out of examples in the RSS reader app – the use of a FAB in the app is tenuous to say the least! But fear not, there will be future articles where we explore more features, behaviours, and general cool stuff. Starting next week – watch this space.

We didn’t actually change any code in this article, but the source for the previous article is available here.

© 2015, Mark Allison. All rights reserved.

Copyright © 2015 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at http://blog.stylingandroid.com/license-information.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.