10.2 Styles

Understanding Styles in Android

Styles in Android let you define how your views look in a single, reusable place. Instead of repeating the same attributes on many views, you create a style once and apply it wherever you need. This keeps your layouts cleaner and makes it easier to change the design of your app later.

A style is a collection of view attributes such as colors, text sizes, padding, and fonts. You usually store styles in XML under the res/values folder, typically in a file named styles.xml. Styles are applied to views through the style attribute, or they can be used as part of a theme which is applied to an entire activity or app.

Defining Styles in XML

To define a style, you use a <style> element inside a resources file. Every style has a name and contains one or more <item> elements. Each <item> represents a particular attribute and its value.

A simple style definition for text can look like this:

<resources>
    <style name="TitleText">
        <item name="android:textSize">24sp</item>
        <item name="android:textColor">@color/black</item>
        <item name="android:textStyle">bold</item>
    </style>
</resources>

In this example, the style named TitleText defines three attributes for any view that uses it. The android: prefix indicates that these attributes are from the core Android framework. Custom or app specific attributes can be written without that prefix or with your app namespace, for example app:.

You can put multiple styles in the same XML file. It is common to group related styles together, such as text styles in one file and button styles in another, or to keep them all in a single styles.xml for small projects.

Applying Styles to Views

To apply a style to a view, you set the style attribute in your XML layout. The value uses the @style/ prefix followed by the style name.

For example, using the TitleText style on a TextView:

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    style="@style/TitleText"
    android:text="Hello, styled world!" />

The view can still override attributes from the style by specifying them directly. Attributes in the view take precedence over attributes from the style.

For instance, this TextView uses the style but changes the text color:

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    style="@style/TitleText"
    android:text="Custom color"
    android:textColor="@color/primary" />

Here the android:textColor declared on the TextView will override the color defined in the TitleText style.

You can apply styles to most view types including buttons, text views, input fields, and many Material Design components. Some components have their own special style attributes, which can also be defined in style resources.

Style Inheritance and Parent Styles

Styles can inherit from other styles. Inheritance lets you define common attributes in a base style and then create variations that change only a few properties. This avoids duplication and keeps your design consistent.

You specify inheritance using the parent attribute or by using a dotted name where the part before the last dot is treated as the parent.

Here is a base text style and two derived styles:

<resources>
    <style name="BaseText">
        <item name="android:textColor">@color/black</item>
        <item name="android:fontFamily">@font/roboto</item>
    </style>
    <style name="TitleText" parent="BaseText">
        <item name="android:textSize">24sp</item>
        <item name="android:textStyle">bold</item>
    </style>
    <style name="BodyText" parent="BaseText">
        <item name="android:textSize">16sp</item>
    </style>
</resources>

In this example both TitleText and BodyText styles use the color and font from BaseText. They only define size and style specific to their purpose.

You can also inherit from built in Android styles or Material Components styles by using their full names as parents, such as parent="Theme.MaterialComponents.DayNight" or parent="@style/Widget.MaterialComponents.Button" depending on the type.

Style Naming Conventions and Organization

For maintainability, it is helpful to follow consistent naming conventions. Common patterns include names that describe the role of the style, such as Text.Title, Text.Body, Button.Primary, or InputField. These names make your layouts easier to read because you can tell what kind of style is being applied.

You may also choose to separate styles by type. For example, place text related styles in a section of the file, or give them a common prefix such as Text_ or Button_. In larger apps, you can create multiple style files like styles_text.xml or styles_buttons.xml inside the values folder to keep things organized.

Even if you use a simple naming scheme at first, deciding one early helps avoid confusion when your project grows.

Using Style Attributes for Consistency

Styles work best when they help you reuse the same visual rules across the app. You can define typical padding, margin, and size values in dimens.xml and refer to them in your styles, so that multiple components share consistent spacing.

For example, define a dimension in dimens.xml:

<resources>
    <dimen name="button_corner_radius">16dp</dimen>
</resources>

Then reference it in a style:

<resources>
    <style name="PrimaryButton">
        <item name="android:minHeight">48dp</item>
        <item name="android:paddingStart">16dp</item>
        <item name="android:paddingEnd">16dp</item>
        <item name="android:textAllCaps">true</item>
        <item name="cornerRadius">@dimen/button_corner_radius</item>
    </style>
</resources>

Here the cornerRadius attribute might belong to a particular button class, for example a Material Button. Changing the value in dimens.xml will update all buttons that rely on this style, which keeps visual adjustments simple.

Using colors from colors.xml in the same way ensures that if a brand color changes, you update it only in one place.

Widget Specific Styles

Some widget classes look up a style defined as part of the theme or allow you to pass a style reference through their constructor attributes. For example, Material Components often have attributes like style="@style/Widget.MaterialComponents.Button" or they use specific attributes in a theme.

Although the full details of themes are covered elsewhere, it is useful to recognize that you can create widget focused styles that are meant to refine the look of specific components. For example, a style that is used only for EditText fields, or a style for a secondary action button.

You apply these widget styles either directly in the layout using the style attribute, or indirectly through themed attributes that associate a style with a whole class of widgets.

Style Precedence and Overrides

Understanding how styles combine with other attributes helps you predict the final appearance of a view. There are a few important precedence rules.

If a view uses a style and also sets attributes directly, the direct attributes in the view override the ones from the style. If a style inherits from a parent, attributes in the child override attributes with the same name in the parent. If a theme also defines default values through attributes, the style or the view can still override them, depending on how the view resolves its attributes.

From the view's perspective, the final value for each attribute is decided in this general order: default values from theme, then values coming from the applied style, and finally values explicitly set on the view itself. The view's own attributes are the most specific and win if they conflict.

Style Variants for Different Configurations

Sometimes you want a slightly different style depending on device characteristics such as screen size or orientation. You can create alternative values folders with configuration qualifiers and define styles with the same name inside them. Android will choose the appropriate style at runtime based on the current configuration.

For example, you might define larger text sizes for tablets in values-sw600dp/styles.xml and smaller ones in values/styles.xml. As long as the style names are identical, the system will pick the right version automatically.

The code that applies the style does not change. The layout still uses something like style="@style/TitleText". Internally, Android picks the correct resource based on the current device.

This ability to adapt styles helps create a responsive design without cluttering layouts with many conditional checks.

Reusing Styles Across the App

As your app grows, you often find repeating the same visual patterns: titles, subtitles, body text, primary buttons, secondary buttons, cards, or labels. Grouping these into styles lets you make broad design changes quickly.

For example, if every screen uses TitleText for headers, you only need to change that one style definition to adjust all headers across the app. You might update the font, color, or size without touching individual layout files.

To get the most benefit, try to use named styles consistently instead of defining attributes directly on views. Over time you will develop a small design language for your app through these styles, which improves both the user experience and the maintainability of the code.

Styles also make collaboration easier. Designers can specify which style to use for each element, and developers can implement those styles centrally. When requirements change, the shared style resources make adjustments less error prone.

By combining well organized styles with colors and dimensions defined in resources, you create a flexible base for themes and for more advanced customization that you will see elsewhere in this course.