Dynamic Theme Management for Android

The quest for a scalable and extensible solution

Chaitanya Varier
University of Waterloo

May 27, 2018

Outline

1. Context

2. Approach 1: The UiModeManager

3. Approach 2: Programmatic Theming

4. Approach 3: Styles and Custom Attributes

5. Conclusion

1
Context
Motivation

Imagine you are working as an Android developer in the team of your

dream. You love your job.

One day, your manager walks over to you and says,

”I’m afraid I have some bad news. Our users want a new UI.”

2
Motivation (contd.)

Your skin starts turning paler and paler, and your blood starts
curdling as you cringe at the thought of having to refactor the entire
app from the ground-up.

But little did you realize that your boss actually said,

”We’re implementing a theme manager.”

3
Motivation

If you too thought about countless hours of tedious work, you

weren’t wrong.

But there’s definitely a simpler solution.

4
Approach 1: The UiModeManager
The UiModeManager

The Android SDK provides an interface for manipulating the OS’s UI

modes called UiModeManager.

Figure 1: Qualified resource folders for separate UI modes

5
The UiModeManager (contd.)

Advantages:

• Allows specification of distinct color palettes

• Can specify unique assets for each theme

Disadvantages:

• Limited selection of UI modes and qualifiers

• Behavior not consistent across all Android versions

Not a scalable and extensible approach. We can definitely do better.

6
Approach 2: Programmatic
Theming
Programmatic Theming

An alternative would be to write a programmatic theming engine

either in Kotlin or Java.

Our engine would do the following:

1. Define a set of XML tags to be applied on each View (UI

component)
2. Map each tag to an id that defines a characteristic of a View (eg.
background color, text color)
3. Traverse through all the Views and apply the chosen theme’s
properties on each one

7
Programmatic Theming (contd.)

To get this working, we first need to define an interface which we can

apply to every Activity and Fragment (Sections of the UI).

Figure 2: The Themeable interface

8
Programmatic Theming (contd.)

We’d then use our interface to notify a ThemeEngine class when each
Activity and Fragment is ready to be themed (during its lifecycle).

Upon being given a ready signal, we would apply our View hierarchy
traversal algorithm.

9
Programmatic Theming (contd.)

Advantages:

• Allows developer to choose which resources to load at runtime

• Theming engine can be subclassed to handle any type of UI
component

Disadvantages:

• Tag API feature not available on all Android versions

• Traversing View hierarchies at runtime will be slow

This is an extensible, but not scalable approach. We can still do

better.

10
Approach 3: Styles and Custom
Attributes
Styles and Custom Attributes

Most elegant solution involves using two of Android’s core UI

building blocks: the <style> and <attr> XML tags.

Styles provide encapsulation and let the developer abstract away the
UI’s appearance from its function.

Attributes can be referenced within <style> elements using the <attr>

tag. They can point to any type of asset resource within the app.

11
Styles and Custom Attributes (contd.)

Advantages:

• Can be referenced anywhere in the app, both programatically

and through XML
• Can implement as many themes as you want

Disadvantages:

• Small Android version-specific quirks that can be mitigated with

resource qualifiers and conditional checks

Thus, our thirst for scalability is quenched.

12
Styles and Custom Attributes (contd.)

Figure 3: An implementation of a light and dark mode using Styles and

Attributes

13
Conclusion
Conclusion

Ultimately, we’ve arrived at a solution that is not only scalable to any

project size, but also extensible enough to support any number of
themes.

Few things to keep in mind:

• There is still a non-trivial amount of refactoring and grunt work

involved
• Even with the most elegant solution we’ve discussed, we must
tread carefully

14
Questions?

14