Android Material Design With Backward Compatibility

Earlier mid last year Google released a unified design guideline for web, smartphones, tablets and wearable devices, called Material Design. As per Google’s official design spec, material design is inspired from the concept of paper and ink. Keeping design simple and soothing, material design guidelines suggest to maintain continuity across screens. Being an Android developer, my perception was converting an existing app to material design could lead to huge code rework. But thankfully AppCompat v7 r21 was released recently, supporting Android Material Design Backward Compatibility.

The question is

If we design an Android app with material design will it be backward compatible?

The answer is yes. A single app can be designed maintaining Android material design backward compatibility. This can be done in three ways. But first lets discuss what happens if you start using it directly. Just like Android Holo theme, material design theme is also available in three variants:

• @android:style/Theme.Material
• @android:style/Theme.Material.Light
• @android:style/Theme.Material.Light.DarkActionBar

But if you directly include any of these themes in styles.xml of your project it will give you this error:

java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity

As you may have extended ActionBarActivity in your activity class. This class is a support class and requires an AppCompat theme. Hence we need to include material design in a backward compatible way. As I mentioned above there are three ways we can do this. First lets discuss the most important one, where support library AppCompat v7 r21 is used.

1. Support Library

Whenever a new project is created in Android Studio, by default it comes with an attached AppCompat v7 library. Make sure that this support library is r21. As this new release supports backward compatibility with material design. To include it in you project add the line below in your :app build.gradle file:

compile 'com.android.support:appcompat-v7:21.0.3'

Using the AppCompat v7 r21 supports the maximum compatibility out of the three approaches. You can utilize the AppCompat library for displaying material theme by including code below in your regular styles.xml:

<resources>
    <!-- Base application theme. -->
    <style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
        <!-- Main theme colors -->
        <!--   your app branding color for the app bar -->
        <item name="colorPrimary">#3F51B5</item>
        <!--   darker variant for the status bar and contextual app bars -->
        <item name="colorPrimaryDark">#303F9F</item>
        <!--   theme UI controls like checkboxes and text fields -->
        <item name="colorAccent">#FF4081</item>
    </style>
</resources>

I have defined only three items of the material theme, but for complete Android material design backward compatibility, you can define all of them here. As of now AppCompat v7 r21 does not support all the widgets for backward compatibility, but it can support some of the major widgets:

• EditText
• Spinner
• CheckBox
• RadioButton
• SwitchCompat
• CheckedTextView

I tried to customize them by applying a theme, have a look at the screen shot.

2. Provide v21 layouts

If you are planning to display material design only on new devices then you can take this approach as well. Its fairly simple. Just define the new layouts for v21(Android Lollipop), in res/layout-v21 folder of your project. Your app will show these layout only when an Android 5.0 device is in use.

3. Provide v21 styles

Another way of supporting Android material design backward compatibility is by using material theme styles only for v21(Android Lollipop). This can be done by defining a new style.xml file in res/values-v21/ folder of your project. These styles would also be displayed only in Android 5.0 devices.

With this I would like to conclude by saying, the new material design theme released by Google, can be included in existing projects, in three possible ways. Although each way has its own pros and cons but personally I would go with the first approach. It may be most difficult one to implement, but it supports maximum backward compatibility. Hope this helped you in making an informed decision. Please connect with us through Facebook, Google+ and Twitter for more updates.

Mohit Gupt

Born in New Delhi, India. A software engineer by profession, an android enthusiast and an evangelist. My motive here is to create a group of skilled developers, who can develop something new and good. Reason being programming is my passion, and also it feels good to make a device do something you want. In a very short span of time professionally I have worked with many tech firms. As of now too, I am employed as a senior engineer in a leading tech company. In total I may have worked on more than 20 projects professionally, and whenever I get spare time I share my thoughts here at Truiton.