Skip to content
tezvyn:

Styles vs. Themes and Attribute Resolution in Android

Source: developer.android.comMediumHow cards are made

Styles vs. Themes and Attribute Resolution in Android

This tests your grasp of Android's resource indirection. A Style is a set of attributes for one View type. A Theme is a collection of named attributes for an app or Activity. ?attr is resolved at runtime against the Theme, while @color is a direct.

What's really being asked

This tests your understanding of the fundamental difference between applying a fixed set of properties (a Style) and using a level of indirection for those properties (a Theme). It's a proxy for whether you can build a scalable, maintainable UI that supports features like dark mode or dynamic colors. The interviewer wants to see you understand that Themes are a runtime concept, not just a compile-time resource grouping.

The full answer

A strong answer explains four points in order. First, a Style is a collection of view attributes for a single View type, like making all Buttons have the same padding. It's applied with style="@style/MyButtonStyle". Second, a Theme is a collection of named, semantic attributes applied to an entire Application or Activity. It's a map of abstract names (like colorPrimary) to concrete resources (like @color/blue_500). Third, ?attr/colorPrimary is a pointer. At runtime, when a View is inflated, the system looks at the Context's current Theme, finds the attribute named colorPrimary, and then resolves that to a concrete value. This is late-binding. Fourth, @color/purple_500 is a direct reference. The Android Asset Packaging Tool (AAPT) resolves this at compile time to a specific integer resource ID. The value is static and does not change based on the current theme.

The mistakes people make

The most common mistake is saying a Theme is just a "global style". This misses the core concept of indirection; a Style applies values, while a Theme applies attributes which then resolve to values. Another major red flag is stating that ?attr is resolved at compile time, which shows a fundamental misunderstanding of how theming works. Finally, candidates often fail to connect the ?attr mechanism to practical features like Day/Night themes, which is the entire purpose of the system.

What usually comes next

Expect questions like: "How would you implement a Day/Night theme switch?" (Answer: Use Theme.AppCompat.DayNight, define colors in values and values-night, and use ?attr for all colors). Or, "What is a theme overlay?" (Answer: A parentless theme applied to a specific View hierarchy with android:theme to override a few attributes, like a dark toolbar in a light activity). Or, "How does Material You fit into this?" (Answer: It's the ultimate extension, generating a theme at runtime from the user's wallpaper and populating ?attr values).

A concrete example

In your themes.xml, a light theme maps ?attr/myCustomBackgroundColor to @color/white. A dark theme maps the same ?attr/myCustomBackgroundColor to @color/black. Your layout XML has <LinearLayout android:background="?attr/myCustomBackgroundColor">. When the user switches to dark mode, the Activity is recreated with the dark theme. The LinearLayout inflates, sees the ?attr reference, and the Resources.Theme object provides the value for @color/black without you changing the layout file. If you had used android:background="@color/white", it would stay white regardless of the theme.

Interview question

What is the key benefit of using "?attr/myCustomColor" in an Android layout XML instead of "@color/myFixedColor"?

  • a.It provides a fallback mechanism, preventing crashes if the color resource is undefined.
  • b.It ensures the color is applied consistently across all instances of a specific View type.
  • c.It allows the resource to be resolved at compile time, improving app startup performance.
  • d.It enables the referenced color to change dynamically based on the active Theme at runtime.Correct
Why?

The primary benefit of using "?attr" is that it provides a layer of indirection, allowing the concrete color value to be resolved at runtime based on the currently applied Theme. This is crucial for features like dark mode. In contrast, "@color" is a direct reference resolved at compile time, making its value static.

Just read this? Test yourself on what you have been reading.

Read the original → developer.android.com

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.

See open roles