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.
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.