Android styles are often overlooked yet they're an extremely powerful way to simplify layouts. Styles boost code legibility, reduce technical debt, and provide design consistency and flexibility.

If you're new to styles I recommend checking out Styles and Themes over on Codepath to learn how they work and then use my tips for organizing them. All of this is beginner-level stuff and it will save you time by avoiding common conflicts in how Android works with styles. If you're already using styles, these tips will make them much easier to use.


1. Start with generic base components

The best way to start new styles is by extending a generic base component such as Button, Layout, TextView, and so on:

I try to use generic terms when components are safely interchangeable, such as Image instead of ImageView, or Layout instead of LinearLayout or RelativeLayout. I will stick to system component names when the generic term could cause conflicts and confusion, like between TextView, EditText, and text-only buttons.

It may seem redundant to start with empty tags, but it leads to clear and obvious name hierarchies. Finally, I strongly recommend keeping these generic base component styles in a separate xml file (i.e. styles_base.xml). This way you only need to make it once and can copy the file when starting a new projects.


2. Keep style code in styles and layout code in layouts

Once you begin to use styles, you'll tend to want to put all of your attributes in styles because it's so easy to reuse them. Don't do it! You'll find out over the long haul that most page layouts are not equal and that it's much more clear and instinctive to find layout-specific settings in the layout code.

There are exceptions as you'll see in the next few tips.


3. Add wrap_content in your base components

wrap_content is the default layout setting for most components, but when you change one then you must change the other too. For example, if you need to change width to "match_parent", you still need to specify "wrap_content" for height or else you get a build error.

To avoid this issue, I always add wrap_content to my my base components:

Again it looks redundant, but it's extremely helpful and your layouts are not littered with wrap_content.


4. View component size and spacing

Both page layouts and view components use the same attributes to define size. While styles are bad for page layouts, it's generally fine for defining view component specs like size, padding, and margins. View components would include dividers, buttons, thumbnails, and other custom components.

For example I will define a basic horizontal rule (divider):

Notice I didn't have to specify wrap_content for the width. The base View style already did it!

Next I extend the view component for whatever colors I need:

Finally, I can use this single line in my layouts whenever I need a dark horizontal rule:


5. Use padding and margin edges

If you're going to specify padding or margins in styles, specify all of the edges instead of globally even if all of the edges have the same value:

The reason we do this is because  padding and layout_margin automatically override edge values (though it really should be the other way around). This means, if you use padding or layout_margin in styles, you can no longer override with edge values in the layout. If you try, you'll see edge values in your layout code but they won't actually affect anything in the actual build.

By only defining edges in styles, you're free to override edges in your layouts with a global value.


6. List styles alphabetically

Resources don't have the same organization benefits of class hierarchy. They're generally single-level, so we have to improvise our own solutions.

I strongly recommend keeping styles sorted alphabetically. Not only between styles, but extended styles too. This will group styles together nicely, prevent orphan styles, and make it easy to jump between styles within a single page.


7. Use resource folders for versioning style features

Material design is going through a lot of changes with new Material components getting released every few months. Unfortunately, these components and design features are often not backwards compatible, so we need an easy way to add (and later remove) exceptions.

The best way is to use resource version folders to add features and attributes in styles, like elevation:




8. Keep theme code in themes.xml

We've all seen demo projects released by Google that specify all theme modifications in the styles.xml file and not use themes.xml. This works fine for demos, but when you get into bigger projects you're going to appreciate the separation, particularly when you get into multi-style themes for day & night or theme-coloring.


9. Separate large style lists into component xmls

For large projects you may end up with a long, 500+ line styles.xml file. If the list becomes too long to navigate, split it up into component-based xml files such as:

  • styles_buttons.xml
  • styles_layouts.xml
  • styles_images.xml
  • ...

You may want to keep a catch-all styles.xml file for component types with only a few instances. If you do start splitting up by type, keep the styles_base.xml. It'll be handy for the next project.


Wrap up

I only have nine great tips right now, but I'm confident this list will grow. I'll be updating this page as Android continues to evolve so check back periodically.

If you have any questions or can recommended additions, please feel free to ping me via Twitter: @radley