The material design spec for Android 5.0 is impressive. The updated apps Google provided to show off the reimagined Android UI are gorgeous. The newest Gmail app, the updated Google Play app, and the new Notifications panel are all clean, slick, and one of the sexiest mobile experiences available on any device.
Every client I talk to can't wait to "reskin" their Android app with a materials update; new clients won't even consider anything but a material experience out of the gate. Google has done a fantastic job, creating a unique and beautiful user experience.
Google has also managed to create a buzz — users, stakeholders, artists, and strategists can't stop talking about material design. Developers are talking about material design, though maybe not for the same reasons. Like everyone else, my mouth started watering the moment I saw the material design presentation at Google I/O 2014. I immediately downloaded the L-preview so I could start getting my hands on the material goodness. I ran into some trouble, but I chocked it up to the fact that I was working with pre-release software.
It's some seven months later, the software has already been through an official release and even a dot update, and still I find myself struggling with inconsistencies and APIs that feel unfinished. Last week, I blogged about the elevation property, and a frustrating issue I had getting the drop shadow to work. I continued to bang my head against the dynamic shadows implemented by the framework, and came away with a few more pain points.
- Drop shadows do not render with standard buttons. Period. If you want the framework to render a drop shadow for your buttons, they must be ImageButtons.
- As touched on last week, using an alpha in your background drawable will stop the framework from rendering drop shadows — there seems to be no rhyme or reason for this, and more importantly, no documentation pointing this out.
- The app-compat method ViewCompat.setElevation(View, int) appears to be useless. On an Android device running Lollipop or better, you get the same shadow you'd get when setting the elevation property. On a pre-Lollipop device, the method appears to do nothing besides allowing you to retrieve that elevation later using ViewCompat.setElevation(View).
- There is one interesting exception to rule number three: ViewCompat.setElevation does seem to render shadows when used in conjunction with the app-compat CardView. It's inconsistencies like these that cost developers numerous man-hours in trial and error.
- The only way I found to render drop shadows to pre-Lollipop UI elements was using a layered list, creating a drop shadow stack, and assigning it to the element background; in other words, the same way developers have been doing it all along. Unless your app is only going to run on Android 5.0+ devices, to create the material shadow effects, you are going to have to fake it. And if you are faking it anyhow, why bother with the conditional code that will use the Lollipop-only calls? I guess because pre-Lollipop drop shadows aren't dynamic. This brings us to my final issue.
- There are almost no user devices running Lollipop! Don't believe me? Take a look at the latest set of distribution statistics from the developer console (Figure A). Lollipop doesn't even make the list.
With so many negative things to say about material design and Android 5.0, you might think I'm not a fan, but nothing could be further from the truth. Having the material design specifications is a huge win for Android. The beautiful examples showcasing what can be done using these guidelines are inspiring. I just feel like the cart got a little ahead of the horse. Google set the bar very high for developers, but I think in a number of cases it hasn't provided the full set of tools we need to easily meet user expectations.
Luckily, Android is incredibly flexible and transparent, meaning it's more than possible to get the job done — just don't expect it to be as simple as loading an appcompat library and applying a new theme. Doing material design right, at this juncture, is a significant effort. Make sure you communicate this with your clients and plan appropriately.
William J Francis began programming computers at age eleven. Specializing in embedded and mobile platforms, he has more than 20 years of professional software engineering under his belt, including a four year stint in the US Army's Military Intelligence Corps. Throughout his career William has published numerous technical articles, as well as the occasional short story.