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:
Important Alternative Resource Qualifiers
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/res/values-en-rUS-port-finger
Bad examples of alternative resource directories with qualifiers are/res/values-en-rUS-rGB
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
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 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
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.