What is RES folder in Android Studio?

ByJael Lawler

What is the RES folder?

The RES folder is where all the resources for an Android app project are stored, such as images, layout XML files, strings, etc. RES stands for “resources”.

The purpose of the RES folder is to separate an app’s resources from the source code. This provides a cleaner project structure and makes resources easier to locate and manage. It’s considered a best practice in Android development to store all reusable assets like images and strings in the RES folder, rather than embedding them directly into code.

Some key contents of the RES folder include:

  • Drawable files – Bitmap and vector images
  • Layout XML files – User interface layouts
  • Values files – Strings, dimensions, styles, colors, etc.

By default, Android Studio will generate a RES folder when creating a new project. The IDE handles packaging resources into the final APK. So developers rarely need to directly modify the contents of RES, beyond adding/editing resources.

Overall, the RES folder is integral to Android apps, housing all the supporting assets that the app code relies on. Keeping resources separate optimizes app architecture.

Layout Files in RES Folder

The RES folder in an Android Studio project contains the XML layout files that define the user interface for each screen in the app. These XML files allow developers to visually design the UI layouts using a drag-and-drop interface in Android Studio.

Typically, there will be multiple layout files in the RES/layout folder, with each one representing a different screen or activity in the app. For example, there may be separate layout files named activity_main.xml, activity_settings.xml, fragment_profile.xml etc. The name of the layout file usually corresponds to the name of the Activity or Fragment class that will use that layout.

Having separate XML layout files for each screen allows you to customize the UI for different screen sizes and orientations. For example, you may want a single column layout for phones in portrait, and a two column layout for tablets in landscape. This can be achieved by creating different versions of the layout file – for example activity_main.xml and activity_main_land.xml. The system will automatically choose the appropriate layout based on the device configuration.

The layout files only define the visual structure and components of the UI. The actual logic to populate the UI and handle interactions is written in Kotlin or Java code, usually within the Activity or Fragment class.

Some key things that can be defined in Android layout XML include (see Layout Lessons! Better Android Layouts):

  • ViewGroup containers like LinearLayout, RelativeLayout, ConstraintLayout etc.
  • UI widgets like TextView, ImageView, Button etc.
  • Layout properties like width, height, padding, margin etc.
  • UI component ID to reference in code

By separating the layout code into XML files, it makes the UI layer more modular and manageable. Developers can visually design and tweak the UI without having to modify the main app code.

Drawable Files in RES Folder

The drawable folders contain image files like PNG, JPG, GIF etc. that are used in the app’s UI. Android supports multiple screen densities, so the drawable folders contain resolution-specific image assets for mdpi, hdpi, xhdpi, xxhdpi screens and more. For example, an icon image would be stored as:

  • drawable-mdpi/icon.png – for medium density screens
  • drawable-hdpi/icon.png – higher resolution version for high density
  • drawable-xhdpi/icon.png – higher resolution for extra-high density
  • drawable-xxhdpi/icon.png – highest resolution for extra-extra-high density screens

The specific size and resolution varies based on the screen density bucket. As a reference, xxhdpi screens have pixel density of 480 dpi, so a 48 x 48 px icon would be 24 x 24 dp. Developers need to provide images for each density bucket to ensure crisp rendering across devices.

Learn more about supporting various pixel densities here: Support different pixel densities

Reference image resolution sizes here: Image resolution for mdpi, hdpi, xhdpi and xxhdpi

Values files in RES folder

The values files in the res folder define various simple values used in the app such as colors, strings, styles, dimensions etc. Values files are stored in the res/values/ directory and have a .xml extension.

There can be multiple values files to separate values based on functionality or configuration. For example, strings can be stored in strings.xml while colors are stored in colors.xml. There can also be different values files for different configurations like values-night/ for night mode colors.

Some common value types stored in values files are:

  • colors – defines color values used in the app
  • dimens – defines dimension values like font sizes, margins etc.
  • strings – defines all text/string constants used in the app
  • styles – defines reusable styles for views
  • themes – defines styles/colors for different themese

Values defined in these files can be referenced in layout XMLs or code via the @ syntax e.g. @string/app_name. The build system processes values files and bakes them into the app binary at build time.

By externalizing values like colors, strings and dimensions into values files, it becomes easy to update them without touching any code. Values can also be overridden for different configurations to support localization or themes.

Navigation between XML layouts

Android allows navigation between different screens or layouts in several ways. The most common approaches are using Activities with Intents, and Fragment navigation.

To navigate between Activities, you can start a new Activity using an Intent. For example:


Intent intent = new Intent(CurrentActivity.this, NextActivity.class);
startActivity(intent);

This will launch the NextActivity. You can pass data between Activities using extras on the Intent. To return back to the previous Activity, call finish() in the NextActivity.

Fragments provide another approach for navigation. They allow you to modularize your UI into reusable components. To navigate between Fragments, you use a FragmentTransaction:


Fragment newFragment = NewFragment.newInstance();
FragmentTransaction transaction = getFragmentManager().beginTransaction();

transaction.replace(R.id.fragment_container, newFragment);
transaction.addToBackStack(null);
transaction.commit();

This will replace the current Fragment with the new one. The back stack allows going back to the previous Fragment on back press. Fragments are useful for navigation within an Activity.

Overall, Intents and Activities provide coarse-grained navigation between standalone screens. Fragments offer more modular and fine-grained navigation within an Activity.

Accessing resources in code

In Android, resources like strings, drawables, and layouts are externalized into XML files in the res folder. To access these resources in Java or Kotlin code, the generated R class provides constants for all the resources. The Resources object obtained via Context.getResources() provides methods to retrieve resources based on their resource IDs.

For example, to get a string resource:


String hello = getResources().getString(R.string.hello);

To get a drawable resource:


Drawable icon = getResources().getDrawable(R.drawable.icon);

The R class contains an inner class for each resource type (drawable, layout, string etc.) that holds the ID constants. Using the generated R class instead of hardcoding resource IDs provides referential integrity, allowing renaming resources without breaking references in code.

Here are some examples of accessing different resource types in code:


// Strings  
String message = getResources().getString(R.string.message);

// Drawables
Drawable image = getResources().getDrawable(R.drawable.image); 

// Layouts
setContentView(R.layout.activity_main);

// Dimensions 
int margin = getResources().getDimensionPixelSize(R.dimen.margin);

The Resources object also provides typed get methods like getString(), getDimension(), getColor() etc. to retrieve resource values directly with correct types.

Source: https://stackoverflow.com/questions/6999866/access-a-resource-name-programmatically

Organization and naming conventions

Proper organization and naming conventions for files and folders is crucial for maintainable Android apps. The recommended folder structure is:

  • res/layout/ – Contains XML layout files
  • res/values/ – Contains values files like strings and colors
  • res/drawable-mdpi/ – Drawable resources for medium density
  • java/com../ – Java source code files

Some key naming conventions for Android resources include:

  • Layout files should match the name of the Activities that use them e.g. activity_main.xml
  • Drawable files should be named based on what they represent e.g. icon_settings.png
  • ID names should be prefixed with the name of the layout e.g. activity_main_title
  • String names should be lowercase with underscores e.g. hello_world

Following standard naming conventions makes it easy to find resources and understand what they represent at a glance. Overall, neat project organization is vital for Android apps to be maintainable and scalable.

Localization Support

The RES folder in Android Studio provides built-in support for localizing your app into multiple languages. This is done by organizing locale-specific resource folders such as values-es for Spanish and values-fr for French. Each folder can contain strings.xml and other resource files translated into the appropriate language.

To localize your Android app, you create alternate versions of resources like string files for each language you want to support. At runtime, Android loads the appropriate resources based on the device’s current locale setting. This allows your app to dynamically adapt its text, images, and layouts based on the user’s language preferences. For more details, see the Android developer guide on localizing your app.

The localization system allows you to easily support multiple languages without having to hardcode strings and other resources. By separating your resources into localized folders, you avoid cluttering your default values files. Overall, the RES folder structure streamlines translating Android apps to reach international users.

Build process for resources

Android’s build system uses the Android Asset Packaging Tool (AAPT) to compile app resources during the build process. AAPT takes the application’s raw assets such as XML layouts and drawable files and compiles them into binary resource files that can be loaded efficiently at runtime.

One of the key functions of AAPT is to generate unique integer IDs for each resource. These integer IDs allow the app to reference resources dynamically by ID instead of name. For example, a layout specified in XML can be loaded using the syntax setContentView(R.layout.main) where R.layout.main refers to the generated ID for that layout resource.

During resource compilation, AAPT parses the raw XML resources and generates the R class which contains all the resource IDs. The generated R class allows the app to easily reference any resource by ID. Properly defining resources in XML and using the generated R class is important for performance and localization support.

For more details, see the Android documentation on the Build process.

Tips for efficient use of resources

Here are some tips for using resources efficiently in your Android app:

  • Reuse layouts, drawables, and other resources whenever possible instead of duplicating them. This helps reduce the overall app size.
  • Use density-specific image assets like hdpi, xhdpi, xxhdpi instead of scaling a single image. This ensures images look crisp on all device screen densities. See App resources overview.
  • Store reusable strings, dimensions, colors etc in values/dimens.xml, values/strings.xml instead of hardcoding them.
  • Use vector drawables instead of bitmap images where possible to reduce apk size. Vectors scale smoothly across resolutions.
  • Follow naming conventions and organizational structure within res/ folders to make resources easy to locate.
  • Enable resource shrinking to remove unused resources in release builds. This reduces app size.

Properly organizing resources and reusing them can greatly improve app performance and reduce apk size. Refer to Android’s app resource docs for more best practices.

Leave a Reply

Your email address will not be published. Required fields are marked *