Mostly, this is helpful for consistency within the app and future-proofing design changes.
We don’t have to explicitly apply a button style in the layout because the Button class supports default styles, and the default style for button is already set in our theme (in the framework layer, unless you’ve overridden it). Default stylesĭefault styles are what allow us to write in an XML layout and have it look like a button, rather than a textview. In this post, we’ll briefly cover what default styles are, how to use them, and why they belong (for the most part) in your base theme. This lets us reduce duplication, making our themes leaner and more robust. We had a single tree (a single base), meaning we were in a position to move resources from the app themes (the bottom layer) to the base theme (the middle layer). We started by renaming themes and adopting a naming convention to make it easier to understand the state of the app, and followed up by collapsing similar themes into one, ending up with something like this: There were multiple hierarchies, with distinct framework bases, and the sheer number of nodes was pretty overwhelming.
In the last post, we recounted what the theme structure looked like for the Monzo Android app. This is part two of a series on refactoring themes and styles - it’ll make sense without reading part one, but if you want the full picture, check it out here.
0 kommentar(er)
