Providing Alternative Application Resources - Android

Each time a screen is drawn within an Android application, the Android operating system attempts to match the best possible resource for the job. In many cases, applications provide only one set of resources—the default resources. Developers can include alternative versions of those same resources as part of their application packages. The Android operating system always attempts to load the most specific resources available—the developer does not have to worry about determining which resources to load because the operating system handles this task.

Working with Alternative Resource Qualifiers

Alternative resources can be created for many different criteria, including, but not limited to, screen characteristics, device input methods, and language or regional differences. These alternative resources are organized hierarchically within the /res resource project directory. You use directory qualifiers (in the form of directory name suffixes) to specify a resource as an alternative resource to load in specific situations.

A simple example might help to drive this concept home. The most common example of when alternative resources are used has to do with the default application icon resources created as part of a new Android project in Eclipse. An application could simply provide a single application icon graphic resource, stored in the /res /drawable directory. However, different Android devices have different screen resolutions. Therefore, alternative resources are used instead: /res /drawable -hdpi/icon .png is an application icon suitable for high-density screens, the /res/drawable-ldpi/icon.png is the application icon suitable for low-density screens, and the /res /drawable-mdpi/icon.png is the application icon suitable for medium-density screens. Note that in each case, the alternative resource is named the same. This is important .Alternative resources must use the same names as the default resources. This is how the Android system can match the appropriate resource to load—by its name.

Ironically, this example is also one of the only times you do not also see a default resource (that is, an icon.png resource file stored in the /res/drawable directory), which the system could fall back on if the device environment did not match an hdpi, mdpi, or ldpi qualifier for resolution screen. The reason you can get away with this is because, by definition, all Android devices fall into one of these three categories, so a fallback is unnecessary.

Here are some additional important facts about alternative resources:

  • Alternative resource directory qualifiers are always applied to the default resource directory name. For example, /res/drawable-qualifier, /res/values-qualifier, /res /layout- qualifier.
  • Alternative resource directory qualifiers (and resource filenames) must always be lowercase, with one exception: region qualifiers.
  • Only one directory qualifier of a given type may be included in a resource directory name. Sometimes this has unfortunate consequences—you might be forced to include the same resource in multiple directories. For example, you cannot create an alternative resource directory called /res/drawable-ldpi-mdpi to share the same icon graphic. Instead, you must create two directories: /res/drawable-ldpi and /res/drawable/mpdi. Frankly, when you want different qualifiers to share resources instead of providing two copies of the same resource, you’re often better off making those your default resources, and then providing alternative resources for those that do not match ldpi and mdpi—that is, hdpi. As we said, it’s up to you how you go about organizing your resources; these are just our suggestions for keeping things under control.
  • Alternative resource directory qualifiers can be combined or chained with each qualifier being separated by a dash. This enables developers to create very specific directory names and therefore very specialized alternative resources. These qualifiers must be applied in a very specific order and the Android operating system always attempts to load the most specific resource (that is, the resource with the longest matching path). For example, you can create an alternative resource directory for French language (qualifier fr), Canadian region (qualifier rCA—this is a region qualifier and is therefore capitalized) string resources (stored in the values directory) as follows: /res/values-fr-rCA/strings.xml.
  • You only need to create alternative resources for the specific resources you require—not every resource in a given file. If you only need to translate half the strings in the default strings.xml file, then only provide alternative strings for those specific string resources. In other words, the default strings.xml resource file might contain a superset of string resources with the alternative string resource files containing a subset—only the strings requiring translation. Common examples of strings that do not get localized are company or brand names.
  • No custom directory names or qualifiers are allowed. You may only use the qualifiers defined as part of the Android SDK. Most of these qualifiers are listed inTable.
  • Important Alternative Resource Qualifiers

    Important Alternative Resource Qualifiers

    Important Alternative Resource Qualifiers

    Important Alternative Resource Qualifiers

    Important Alternative Resource Qualifiers

  • Always try to include default resources—that is, those resources saved in directories without any qualifiers. These are the resources that the Android operating system will fall back upon when no specific alternative resource matches the criteria. If you don’t, the system falls back on the closest matching resource based upon the directory qualifiers—one that might not make sense.

Now that you understand how alternative resources work, let’s look at some of the directory qualifiers you can use to store alternative resources for different purposes. Qualifiers are tacked on to the existing resource directory name in a strict order, shown in descending order in Table.

Good examples of alternative resource directories with qualifiers are


Bad examples of alternative resource directories with qualifiers are


The first bad example does not work because you can have only one qualifier of a given type, and this one violates that rule by including both rUS and rGB. The second bad example violates the rule that qualifiers (with the exception of the Region) are always lowercase. The third bad example includes a custom attribute defined by the developer, but these are not currently supported. The last bad example violates the order in which the qualifiers must be placed: Language first, then Region, and so on. Providing Resources for Different Orientations Let’s look at a very simple application that uses alternative resources to customize screen content for different orientations.

This application has no real code to speak of—check the Activity class if you don’t believe us. Instead, all interesting functionality depends upon the resource folder qualifiers. These resources are

  • The default resources for this application include the application icon and a picture graphic stored in the /res/drawable directory, the layout file stored in the /res/layout directory, and the color and string resources stored in the /res/values directory. These resources are loaded whenever a more specific resource is not available to load. They are the fallbacks.
  • There is a portrait-mode alternative picture graphic stored in the /res/drawableport directory. There are also portrait-mode–specific string and color resources stored in the /res/values-port directory. If the device is in portrait orientation, these resources—the portrait picture graphic, the strings, and colors—are loaded and used by the default layout.
  • There is a landscape-mode alternative picture graphic stored in the /res/drawable-land directory. There are landscape-mode–specific string and color (basically reversed background and foreground colors) resources stored in the /res/values-land directory as well. If the device is in landscape orientation, these resources—the landscape picture graphic, the strings, and the colors—are loaded and used by the default layout.

In this way, the application loads different resources based upon the orientation of the device at runtime, as shown in Figure.This figure shows the project layout, in terms of resources, as well as what the screen might look like when the device is in different orientations.

Using alternative resources for portrait and landscape orientations

Using alternative resources for portrait and landscape orientations

Using Alternative Resources Programmatically

There is currently no way to request resources of a specific configuration programmatically. For example, the developer cannot programmatically request the French or English version of the string resource. Instead, the Android system determines the resource at runtime, and developers refer only to the general resource variable name.

Organizing Application Resources Efficiently

It’s easy to go too far with alternative resources. You could provide custom graphics for every different permutation of device screen, language, or input method. However, each time you include an application resource in your project, the size of your application package grows.

There are also performance issues with swapping out resources too frequently—generally when runtime configuration transitions occur. Each time a runtime event such as an orientation or keyboard state change occurs, the Android operating system restarts the underlying Activity and reloads the resources. If your application is loading a lot of resources and content, these changes come at a cost to application performance and responsiveness.

Choose your resource organization scheme carefully. Generally, you should put the most commonly used resources as your defaults and then carefully overlay alternative resources only when necessary. For example, if you are writing an application that routinely shows videos or displays a game screen, you might want to make landscape mode resources your defaults and provide alternative portrait mode resources because they are not as likely to be used.

Retaining Data Across Configuration Changes

An Activity can keep data around through these transitions by using the on Retain Non Configuration Instance() method to save data and the getLast Non Configuration Instance() method to restore this data after the transition. This functionality can be especially helpful when your Activity has a lot of setup or preloading to do.

Handling Configuration Changes

In cases where your Activity does not need to reload alternative resources on a specific transition, you might want to consider having the Activity class handle the transition to avoid having your Activity restart. The camera application mentioned earlier uses this technique to handle orientation changes without having to reinitialize the camera hardware internals, redisplay the viewfinder window, or redisplay the camera controls (the Button controls simply rotate in place to the new orientation—very slick).

For an Activity class to handle its own configuration changes, your application must

  • Update the <activity> tag in the Android manifest file for that specific Activity class to include the android:configChanges attribute. This attribute must specify the types of changes the Activity class handles itself.
  • Implement the onConfigurationChanged() method of the Activity class to handle the specific changes (by type).

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Android Topics