Android Lollipop:

Why no one has it licked

Google IO 2014 was an exciting time in the world of Android. Google had just announced Android L (later to receive its full name of Lollipop) and, with it, the announcement of a new design language — Material Design. This was universally acclaimed by both designers and developers.

We loved the meaningful transitions, the delightful details, the ripples, the elevations and the new colour palettes. We loved the fact that cards were now an integral part of the design pattern. We even loved the animating hamburger icon until we were told, “actually the navigation drawer has to go over the top of it”. You can still see the legacy of that about-turn now in multiple apps (Google included) that still begin to animate the hamburger as you slide the drawer instead of adding this simple line of code to suppress it:

drawerToggle = new ActionBarDrawerToggle(this, drawerLayout, getToolbar(), R.string.open_navigation_drawer, R.string.close_navigation_drawer) {
    @Override
    public void onDrawerSlide(View drawerView, float slideOffset) {
        super.onDrawerSlide(drawerView, 0); // this disables the animation
    }
};

After the excitement of Google IO 2014, we went back to our day jobs and, although some of us may have played with the developer preview, a lot of us didn’t do anything new in our apps until at least the end of October 2014 with the release of the new support library; ahead of the 12th November launch date. Then as January 2015 came and went and Lollipop adoption was still too low to even feature in the monthly distribution stats we began to wonder if we’d ever get to play with the new APIs in any meaningful way.

Fortunately the support library included some of the Lollipop features in it from the get-go but not as many as most of us hoped for. In fact it was only really after this year’s IO and the launch of the design support library that we had a more comprehensive base from which to build our apps from without having to resort to third party libraries or rolling our own code to back port Material design elements.

What have you been doing?

So I’m going to take a guess here as to what you’ve been doing in your app over the past year or so (apart from actually delivering the direct business requirements):

1. Dropped Gingerbread and Honeycomb Support (possibly even Ice Cream Sandwich). This also depends on how global your app is and whether you depend on developing countries that may not have such a high-level adoption of the latest Android versions.
2. Replaced your ActionBar with an App bar (Toolbar) and dropped the application icon from the layout.
3. Replaced most of your ListViews with RecyclerViews. You’ve probably added SwipeRefreshLayouts too.
4. Started using the official CardView.
5. Made your navigation drawer appear over the top of the app bar. You’ve also possibly made it fit the system windows and scroll under the status bar for Lollipop.
6. Finally started to understand themes and styles properly and have been making good use of primaryColor, accentColor, colorControlNormal etc. You also understand TextAppearance better and you’ve probably got your app in such a state that you can change a few colour values in XML and completely change the look of the app.
7. Replaced your single-coloured icons with white ones and used the android:tint on ImageView and ImageButton to get the correct colour for your app.
8. Added the occasional Floating Action Button (FAB) into your app.

Am I right so far?

If you’ve had time since the launch of the design support library you’ve probably started to implement or look into some of the following too:

1. Replaced your drawer adapter with a menu and a NavigationView
2. Added Snackbars (you were probably creating your own or using a third party library before this).
3. Replaced your FloatingActionButtons with the official one. (Plus put in a few hacks to get around the bugs).
4. Wrapped your edit texts in TextInputLayout to get floating text labels (but you’re mildly annoyed that they don’t yet follow all the Google guidelines when in error state).
5. Added CoordinatorLayouts, AppBarLayouts, CollapsingToolbarLayouts, NestedScrollingViews and replaced existing tabs with a TabLayout but you still can’t get it to look as good and responsive as Play Newsstand.

All this is (Im)Material

So you’ve done all that, as well as delivering all the business as usual requirements that the company has asked of you, and you think you’re there. But, unless the applications that I use daily are unrepresentative, you probably have a lot of work to do.

Perhaps it’s just me but I get mildly annoyed with the countless posts from Android developers saying check out my new Material blah-blah-blah app. Ofttimes the only Material aspect of this app is that they’re using a primary and accent colour. Which brings me to another bug bear — even on the Google apps where I can see the accent colour being used correctly — if I drop into settings for that app I’m back to the default colour theme. Also a lot of the time the accent colour is identical to the primary colour — what happens when you want to anchor a Floating Action Button (FAB) to the toolbar and they have the same colour?

And where are all the delightful details animations? Some of you may have looked at vector graphics and stateListAnimators — particularly for your FABs — but can any of you truly say that you’ve put them everywhere you should? Now that there are more than 12% users actually running Lollipop worldwide at least you can start justifying including v21 drawables — even if it is just eye candy. The Google apps are just as bad: Play Movies and Play Music don’t even bother to animate the play/pause button despite that being one of their very first examples.

And where-oh-where are the meaningful transitions? I can see some lovely shared element transitions in Play Movies when browsing My Library but it’s rare that I see them in any other apps. Also these transitions were in the very first versions after IO 2014 and nothing has really changed since. Are there really no other meaningful transitions to implement in these apps?

Conformity vs Creativity

So why has it taken so long to get here and why is no one really doing things right? And what does this mean with Android M coming to a small screen near you soon?

Well the first and most obvious reason is that we didn’t have a common toolset for the first year or so. As I stated earlier, it’s only really with both the AppCompat and design support library that we can push forward from a common base; it is clear that Google is working hard to ensure that this library will continue to be developed further as time goes on. But if Google really wants adoption of the latest standards as quickly as possible they need to either release all the new features in the support library (without bugs!) at the same time as a new OS release or ensure that it doesn’t take six months for the latest OS to reach a mere 10% of users.

I’m quite confident that the support library will soon contain all the features that we need to build our Material design apps with backwards compatibility. Historically, we had to wait much, much longer for Google to implement the AppCompat library when we needed to incorporate action bars and the Holo theme on Gingerbread for example. Hence the almost universal adoption of the legendary Jake Wharton’s ActionBarSherlock and Nine Old Androids libraries.

Android M (whatever name it acquires before the autumn) is not a paradigm shift. In fact, apart from having to implement the new permissions system, it shouldn’t keep us too busy having to reimplement or reimagine old features. In the meantime, having built the foundations with a common base, Android developers and designers can actually start putting the icing on the cake with some great transitions and meaningful animations.

The problem is, once that’s done and everyone conforms more closely to the same patterns, every app is going to look very similar but then we should start seeing some breakout apps that embody all the principles of the Material Design guidelines but then take them further with some really creative transitions and ideas.

It’s been a long time coming and — in the fast-moving world of mobile app development — much longer than it should have been but I’m truly quite excited about what the future holds for Android apps everywhere.

We’re hiring!

Do you want to join the Depop family? We’re looking for Android engineers who can help change the way people buy and sell from their mobile using the latest android UI, coding and testing practices.

Find our vacancies here and get in touch with a copy of your CV.