My experience with Material Design Components on Android
Users like fancy and functional interfaces and experiences. From the user perspective, it doesn’t matter how the business logic or communication with server are implemented — as far as it’s functional. However, it matters how a UI is designed and how much of it is functional and intuitive. The Material Design Components (MDC) as a tool, comes to help to be consistent in the implementation and thus in the app UI.
Let’s see an overview and some details of it.
Artifact
It’s really simple to integrate MDC, since it’s wrapped in one single library: com.google.android.material:material. All you need to do is to introduce the dependency into app’s gradle file (i.e. implementation ‘com.google.android.material:material:1.0.0’).
For alternative versions, the Maven repository page provides additional info.
Core
The Material design system applied to themes, widgets, text appearances are identified by the MaterialComponents keyword, and it's extended to all the style subjects, including the most important:
Theme.MaterialComponentsThemeOverlay.MaterialComponentsWidget.MaterialComponentsTextAppearance.MaterialComponentsShapeAppearance.MaterialComponents
Whether setting a theme for the app, or simply overriding the default style of a widget or of text appearance, one of the above style types should be used or extended.
The AppCompat and MaterialComponents design systems (referenced also as theme families) - unlike the Holo system - uses a specific view inflater class (defined by the viewInflaterClass attribute at theme-level). This comes with specific implementations of standard components. For example the AppCompat system defines and inflates AppCompatButton instead of Button, extended further by MaterialButton within MaterialComponents. Worth mentioning that even if a "base version" of a widget (Button) is defined in the XML, it's subclass is inflated if using the AppCompat or MaterialComponents design system (thankfully to viewInflaterClass). These classes in subject are AppCompatViewInflater and MaterialComponentsViewInflater.
Priority in attributes application
Setting attributes to views, can be accomplished on multiple levels, like from Java/Kotlin code, from XML at view definition-level and so on. Deciding which level is actually applied on a view is defined by the following rule — starting with the highest priority of application (using android:textColor of a TextView as an example):
- applied programmatically
textView.setTextColor(ContextCompat.getColor(context, R.color.pink))2. applied in XML at view definition
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:textColor="@color/pink"/>3. applied based on the style of the view
<TextView
android:lyout_width="wrap_content"
android:layout_height="wrap_content"
style="@style/Theme.MyApp.TextView"/>
<style name="Theme.MyApp.TextView" parent="Widget.AppCompat.TextView">
<item name="android:textColor">@color/pink</item>
</style>
4. applied based on the global style of the view (from current theme)
<style name="Theme.MyApp" parent="Theme.MaterialComponents.Light.NoActionBar">
<item name="android:textViewStyle">@style/Theme.MyApp.TextView</item>
</style>Helpfully, the style of most components is associated with a theme attribute, like the above for TextView, and it’s applied globally.
5. applied based on the global attribute (from current theme)
<style name="Theme.MyApp" parent="Theme.MaterialComponents.Light.NoActionBar">
<item name="android:textColor">@color/pink</item>
</style>Subsystems
1. Color
1.1 Defined colors
The material design defines a new set of colors, partially based on AppCompat: colorPrimary, colorPrimaryDark, colorAccent etc.
One part of the set consist of colorPrimary, colorPrimaryVariant, colorSecondary, colorSecondaryVariant which represents the brand of the app. Another part is not necessarily related to the brand, but are used for different UI elements: android:colorBackground, colorSurface, colorError.
Furthermore, each aforementioned color comes with a color which is used on top of these: the “on” colors, mostly used for coloring text and iconography: colorOnPrimary, colorOnSecondary, colorOnBackground, colorOnSurface, colorOnError.
Of course, there are other color attributes in the Android SDK which could be overridden in app’s theme, however, if they are not, the system either uses a color from the aforementioned set of colors (mapping), or a default one from the SDK.
Related to the application of these theme attributes to the style of views, there is a mapping (referenced as Theme Attribute Mapping) which is executed on some of the style of views. However when there is no mapping created between component and theme attributes, customizing component attributes should be implemented manually (at style attribute or theme attribute level).
1.2 Application
A possible application of basic colors could be:
In order to brand additional entities, like text, icon tint and special purpose colors (for which the Theme Attribute Mapping is not extended, or different colors wanted) other attributes could be overridden:
1.3 Ref
Color generator, palette:
Docs:
- material colours general overview
- material colours for Android
- colour attributes introduced by Material library(com.google.android.material:material): /res/values/values.xml
- colour attributes introduced by AppCompat library
2. Typography
Material design comes with a set of predefined textAppearance styles, described in the docs. These styles can be grouped by their type: Headline, Subtitle, Body and so on.
Each textAppearance style defines a set of attributes (wrapping different values according to the textAppearance type): android:fontFamily, android:textStyle, android:textAllCaps, android:textSize, android:letterSpacing.
Worth noting that some styles also define other attributes (like textColor), however they rather belong to Widget styles and not to TextAppearance ones. Setting android:textColor to a TextAppearance will most likely not have any effect, but it will however take effect if it's set as an attribute of a Widget style. Continuing this thought, I also tried to set other text-based attributes, like android:ellipsize, android:maxLines etc. on a TextAppearance style, but of course they didn't work since they are consumed by the TextView widget. The scope of style attributes are important!
Discovered that, in order to load font into the project, besides manually adding a .ttf file, there is another interesting way: downloadable fonts. It's worth at least a try, because it saves bandwidth, storage, since these fonts are served on device-level by Google Play services.
Applying a textAppearance style to a TextView based view in XML can be accomplished in two ways - but both use almost the same flow:
- applying an attribute value: the
android:textAppearanceattribute needs to be set to atextAppearance(i.e.android:textAppearance="?attr/textAppearanceBody2"). This way the value of thetextAppearanceBody2from the theme is applied, which can be the default one (defined in theme at SDK-level), or overridden at app-level:<item name="textAppearanceBody2">@style/TextAppearance.MyApp.Body2</item>. - applying a style:
android:textAppearance="@style/TextAppearance.MaterialComponents.Body1". Custom, overridden styles can be referenced here as well instead of the default ones.
3. Shape
Styling different properties of a view’s surface is achieved by using shapeAppearance styles. According to the docs, it focuses only to corners and edges of a shape.
Similarly to textAppearance, it defines different attributes for types:
shapeAppearanceSmallComponent, applied toMaterialButton,Chipetc.shapeAppearanceMediumComponent, applied toMaterialCardView,AlertDialogusing withMaterialAlertDialogBuilderetc.shapeAppearanceLargeComponentfor bottom sheet, navigation drawer...
For a complete list of widgets grouped by shapeAppearance type check the docs.
Defined attributes of a shapeAppearance style are: cornerFamily, cornerSize, and can be overridden when creating any of:
ShapeAppearance.MaterialComponents.SmallComponentShapeAppearance.MaterialComponents.MediumComponentShapeAppearance.MaterialComponents.LargeComponent
Furthermore, there are additional corner related attributes, which can be overridden: cornerSizeTopLeft, cornerSizeTopRight, cornerSizeBottomRight, cornerSizeBottomLeft, cornerFamilyTopLeft, cornerFamilyTopRight, cornerFamilyBottomRight, cornerFamilyBottomLeft.
However, seems that in the ‘1.1.0-alpha06’ version of the library, attributes representing edge related values are not defined, but they can be set programmatically by using MaterialShapeDrawable and ShapeAppearanceModel. Many components have a MaterialShapeDrawable background, and can be returned from them (i.e. MaterialShapeDrawable drawable = (MaterialShapeDrawable) cardView.getBackground();). A ShapeAppearanceModel can be set to a MaterialShapeDrawable (or modified) which takes CornerTreatment and EdgeTreatment objects to represent specific corner and edge behaviours. A very good example is implemented in the material-components-android demo project: BottomAppBarMainDemoFragment.java.
4. Dark theme
It’s still in the future, since it comes with Android Q, but it’s already documented.
Conclusion
It’s clear that Material Design Components is the best design system besides Holo and AppCompat to create beautiful interfaces. Even if it’s a great tool, in order to achieve a consistent UI/UX, the design — i.e. mockups from a graphic designer — certainly matters, since MDC is rather a tool or a guideline for implementation.
