Login     Sign Up
Innocent Cyril (@admin)
4 months ago
78 Views

One of the most powerful reasons to externalize your resources is Android’s dynamic resource selec-tion mechanism.

Using the structure described below, you can create different resource values for specific languages, locations, and hardware configurations that Android will choose between dynamically at run time.

This lets you create language-, location-, and hardware-specific user interfaces without having to change your code.

Specifying alternative resource values is done using a parallel directory structure within the res/ folder, using hyphen (-) separated text qualifiers to specify the conditions you’re supporting.

The example hierarchy below shows a folder structure that features default string values, along with a

French language alternative with an additional Canadian location variation:

Project/

res/

values/

strings.xml

values-fr/

strings.xml

values-fr-rCA/

strings.xml

The following list gives the available qualifiers you can use to customize your resource files:

❑Language Using the lowercase two-letter ISO 639-1 language code (e.g., en)

❑Region A lowercase “r” followed by the uppercase two-letter ISO 3166-1-alpha-2 language code (e.g., rUS, rGB)

❑ Screen Orientation One of port (portrait), land (landscape), or square (square) ❑ Screen Pixel Density Pixel density in dots per inch (dpi) (e.g., 92dpi, 108dpi)

❑Touchscreen Type One of notouch, stylus, or finger

❑Keyboard Availability Either of keysexposed or keyshidden

❑Keyboard Input Type One of nokeys, qwerty, or 12key

❑UI Navigation Type One of notouch, dpad, trackball, or wheel

❑Screen Resolution Screen resolution in pixels with the largest dimension first (e.g., 320x240)

You can specify multiple qualifiers for any resource type, separating each qualifier with a hyphen. Any combination is supported; however, they must be used in the order given in the list above, and no more than one value can be used per qualifier.

The following example shows valid and invalid directory names for alternative drawable resources.

❑Valid:

drawable-en-rUS

drawable-en-keyshidden

drawable-land-notouch-nokeys-320x240

❑Invalid:

drawable-rUS-en (out of order)

drawable-rUS-rUK (multiple values for a single qualifier)

When Android retrieves a resource at run time, it will find the best match from the available alterna-tives. Starting with a list of all the folders in which the required value exists, it then selects the one with the greatest number of matching qualifiers. If two folders are an equal match, the tiebreaker will be based on the order of the matched qualifiers in the above list.

Runtime Confi guration Changes

Android supports runtime changes to the language, location, and hardware by terminating and restart-ing each application and reloading the resource values.

This default behavior isn’t always convenient or desirable, particularly as some configuration changes (like screen orientation and keyboard visibility) can occur as easily as a user rotating the device or slid-ing out the keyboard. You can customize your application’s response to these changes by detecting and reacting to them yourself.

To have an Activity listen for runtime configuration changes, add an android:configChanges attri-bute to its manifest node, specifying the configuration changes you want to handle.

The following list describes the configuration changes you can specify:

❑ orientation The screen has been rotated between portrait and landscape. ❑ keyboardHidden The keyboard has been exposed or hidden.

❑ fontScale The user has changed the preferred font size. ❑ locale The user has chosen a different language setting.

❑keyboard The type of keyboard has changed; for example, the phone may have a 12 keypad that flips out to reveal a full keyboard.

❑touchscreen or navigation The type of keyboard or navigation method has changed. Nei-ther of these events should normally happen.

You can select multiple events to handle by separating the values with a pipe (|).

The following XML snippet shows an activity node declaring that it will handle changes in screen ori-entation and keyboard visibility:


<activity android:name=”.TodoList” android:label=”@string/app_name” android:theme=”@style/TodoTheme” android:configChanges=”orientation|keyboard”/>

Adding this attribute suppresses the restart for the specified configuration changes, instead, triggering the onConfigurationChanged method in the Activity. Override this method to handle the configura-tion changes using the passed-in Configuration object to determine the new configuration values, as shown in the following skeleton code. Be sure to call back to the super class and reload any resource values that the Activity uses in case they’ve changed.

@Override

public void onConfigurationChanged(Configuration _newConfig) {

super.onConfigurationChanged(_newConfig);

[ ... Update any UI based on resource values ... ]

if (_newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE) { [ ... React to different orientation ... ]

}

if (_newConfig.keyboardHidden == Configuration.KEYBOARDHIDDEN_NO) { [ ... React to changed keyboard visibility ... ]

}

}

When onConfigurationChanged is called, the Activity’s Resource variables will have already been updated with the new values so they’ll be safe to use.

Any configuration change that you don’t explicitly flag as being handled by your application will still cause an application restart without a call to onConfigurationChanged.