Resources Overview

« Prev Next »

Every non-code asset an Android app uses — its text, colors, sizes, layouts, images, and icons — lives in one place: the res/ folder. This lesson opens the "Resources & Styling" part of the track by mapping out what belongs where, and why Android is so insistent about keeping these values out of your Java code in the first place.

The res/ Folder at a Glance

Folder / File	Holds
values/strings.xml	All user-facing text — labels, button captions, error messages.
values/colors.xml	Every color used across the app, named once.
values/dimens.xml	Reusable sizes — margins, padding, text sizes.
layout/	XML layout files describing each screen or reusable view.
drawable/	Images, vector icons, and XML-defined shapes/selectors.
mipmap/	The app's launcher icon, at multiple densities.

Why Externalize These at All?

It would be entirely possible to write tv.setText("Recipe Box") directly in Java and skip strings.xml altogether — so why doesn't RecipeBox do that? Two reasons, and only one of them is about convenience:

A single place to change a value. RecipeBox's brand green, referenced from a dozen layouts, only needs updating in colors.xml once — every screen picks up the new shade automatically.
It's required, not optional, for proper localization and screen support. Android can swap in a Hindi strings.xml or a higher-density drawable automatically — but only if the value was externalized as a resource to begin with. A hardcoded string in Java can never be translated this way.

Looking ahead: That second point is exactly what Localization & RTL and Dimensions & Density cover in depth later in this section.

Referencing a Resource from XML

Inside any layout file, a resource is referenced with an @ prefix followed by its type and name:

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/app_name"
    android:textColor="@color/recipe_green" />

Referencing a Resource from Java

The same values are reachable from Java code through helper methods, using the auto-generated R class to identify which resource:

// RecipeListActivity.java
String appName = getString(R.string.app_name);
int greenColor = ContextCompat.getColor(this, R.color.recipe_green);

Explanation: getString() is an Activity/Context method that resolves a string resource to plain text; ContextCompat.getColor() does the equivalent for a color resource, resolving it to an actual int color value.

The Auto-Generated R Class

Android Studio scans res/ on every build and generates the R class automatically — it's never written by hand. Every resource gets a corresponding constant (R.string.app_name, R.color.recipe_green, R.layout.activity_recipe_list, and so on). This is a genuine safety net: typing R.string.app_naem fails to compile immediately, whereas a typo'd string ID passed as raw text would only surface as a confusing runtime crash — if it's ever noticed at all.

Resource Qualifiers: One Name, Several Variants

A resource folder name can carry a qualifier — extra text after a dash — telling Android to use that folder's version of a resource only under matching conditions:

Qualified Folder	Used When
values-night/	The system is in dark mode.
values-hi/	The device's language is set to Hindi.
drawable-hdpi/	The screen density is in the "high-density" range.

Android checks the device's current configuration and automatically picks the best-matching folder at runtime — the Java code calling getString(R.string.app_name) never changes; it simply resolves to a different actual value depending on where that call happens to run.

Foreshadowing: This exact mechanism resurfaces repeatedly later in this section — Light/Dark Theme for values-night, and Localization & RTL for language qualifiers like values-hi.

Up next: Styles & Themes covers how to bundle several resource values together into a single, reusable style.

« Prev Next »