Handling Multiple Resource Sets, Part One

Welcome to the new “Building ‘Droids” section of AndroidGuys! This column looks at Android from the developer’s perspective, poking around dusty corners of the Android SDK, and showing how you can create interesting and effective Android applications.

Today, we’ll talk about how to have your Android application support multiple sets of resources for different scenarios, such as internationalization (i18n) and localization (l10n). This material is adapted from a portion of The Busy Coder’s Guide to Android Development.

We're giving stuff away to help celebrate our tenth anniversary. Are you in?

Today’s material is for intermediate Android developers — some experience with the Android SDK is expected. And today’s material is targeted for the M5 SDK, so if you’re reading this in the archives, bear in mind that the SDK may have shifted since this post was written.

The most commonly encountered scenario for needing multiple sets of resources is i18n and l10n, as noted above — if you want to support English and Spanish in one application, you will need strings for each. However, that is not the only scenario:

  • Screen orientation: is the screen in a portrait orientation? Landscape? Is the screen square and, therefore, does not really have an orientation?
  • Screen size: how many pixels does the screen have, so you can size your resources accordingly (e.g., large versus small icons)?
  • Touchscreen: does the device have a touchscreen? If so, is the touchscreen set up to be used with a stylus or a finger?
  • Keyboard: what keyboard does the user have (QWERTY, numeric, neither), either now or as an option?
  • Other input: does the device have some other form of input, like a directional pad or click-wheel?

The way Android presently handles this is by having multiple resource directories, with the criteria for each embedded in their names.

Suppose, for example, you want to support strings in both English and Spanish. Normally, for a single-language setup, you would put your strings in a file named res/values/strings.xml. To support both English and Spanish, you would create two folders, res/values-en and res/values-es, where the value after the hyphen is the ISO 639-1 two-letter code for the language you want. Your English-language strings would go in res/values-en/strings.xml and the Spanish ones in res/values-es/strings.xml. Android will choose the proper file based on the user’s device settings.

Seems easy, right?

For just one criteria, such as language, having multiple resource sets is easy. Things get a lot more tricky when you need to handle several different axes of change, such as different languages and different screen sizes. In the next installment, we’ll see how to handle these more complex scenarios.

  • MJ

    What happened to the comments that were here?

  • AndroidGuys

    We lost all the stuff we did on the 18th and 19th, including comments. We reposted these last night and backdated them. Sorry for confusion.


  • vish

    hello.. actually i am too working on the same, googled a lot and still didn’t get anything relavent. Can any1 here send me a tutorial that consists a small app on this topic.
    Thanks in advance..

  • Pingback: appetible aperch azote()

  • Pingback: autopoisonous beltian beslime()