Refactoring Android Themes with Style
Building a Gallery App (Part 4)
This is part four of a series on refactoring themes and styles — it’ll make sense without reading the other parts, but if you want the full picture, start reading here:
At Monzo, we often create short-lived apps which only depend on the specific modules we need to test our feature during development. This helps mitigate the cost of having to wait for long builds because we don’t have to compile the entire app.
One of these short-lived apps evolved into the Gallery, a showcase of styles and components that can be reused in different features.
While the initial goal of the short-lived app was to test components on different versions of Android, it grew into more:
- We can develop new components in this app quickly (10 second builds) or test changes to existing components
- We could test the behavior and appearance of different components with different themes
- It’s installed with every debug build of the main app, so it can be used as a companion reference
This post briefly describes the approach we took and how it helped us refactor Android themes.
Creating a Gallery module
Our Gallery is defined in a module called gallery (🤯). This contains the launcher activity pictured above, as well as the activities for each of the listed components.
The gallery module is a dependency of both app and gallery-app, each of which are Android application modules.
This means that we can build and run the gallery-app module when we’re working on something in common-design, benefiting from quick builds since gallery-app doesn’t depend on anything else.
Since we define gallery as a debug-only dependency of app, it also means that the Gallery is accessible to anyone who installs the debug app, making it simpler for other disciplines such as designers or product managers to take a peek:
debugImplementation project(':gallery')Comparing across Android versions
The Monzo app has a minSdkVersion value of 21, meaning that we support Android 5.0 devices. Here’s what one of the screens from the Gallery looks like on Android 5.1 vs. Android 10:
As you can see, the color of the amount hint is red on Lollipop! The Gallery app makes it easy for us to see what our most commonly-used components look like on various Android versions. (By the way, this particular issue can be fixed in AppCompat, please star! 🌟)
It’s been incredibly valuable as we were refactoring our themes, using the following process:
- Add components to the Gallery and observe the existing behavior
- Refactor themes
- Verify that nothing unexpected changes
Testing themes in Gallery
The Gallery needed a way to view components with different themes so that we could verify that each one was actually reusable. We added a selector to the launcher activity:
This would pass the selected theme resource as an intent extra when starting the specified activity. Then the receiving activity could set the theme in onCreate():
override fun onCreate(savedInstanceState: Bundle?) {
setTheme(intent.getIntExtra(EXTRA_THEME, 0))
super.onCreate(savedInstanceState)
// ...Now we can see the Gallery with whichever theme was selected!
What’s next?
A Gallery app can help with testing and they’re valuable as references for components in your app. They don’t have to look pretty (though I’ve seen some incredible ones 👀) and you can get started with a simple version in less than an afternoon.
In the next and final post of this series, we’ll look at tools to help prevent regressions as you make improvements with refactoring your Android themes.
In the meantime, if you have any comments, corrections or questions, leave a note below or let me know on Twitter!
