What Are Resources? Android

All Android applications are composed of two things: functionality (code instructions) and data (resources).The functionality is the code that determines how your application behaves. This includes any algorithms that make the application run. Resources include text strings, images and icons, audio files, videos, and other data used by the application.

Storing Application Resources

Android resource files are stored separately from the java class files in the Android project. Most common resource types are stored in XML. You can also store raw data files and graphics as resources.

Understanding the Resource Directory Hierarchy

Resources are organized in a strict directory hierarchy within the Android project. All resources must be stored under the /res project directory in specially named subdirectories that must be lowercase.

Different resource types are stored in different directories. The resource sub-directories generated when you create an Android project using the Eclipse plug-in are shown in Table.

Default Android Resource Directories

Default Android Resource Directories

Each resource type corresponds to a specific resource subdirectory name. For example, all graphics are stored under the /res/drawable directory structure. Resources can be further organized in a variety of ways using even more specially named directory qualifiers. For example, the /res/drawable-hdpi directory stores graphics for high-density screens, the /res/drawable-ldpi directory stores graphics for low-density screens, and the /res/drawable-mdpi directory stores graphics for medium-density screens. If you had a graphic resource that was shared by all screens, you would simply store that resource in the /res/drawable directory. We talk more about resource directory qualifiers later in this chapter.

Using the Android Asset Packaging Tool

If you use the Eclipse with the Android Development Tools Plug-In, you will find that adding resources to your project is simple. The plug-in detects new resources when you add them to the appropriate project resource directory under /res automatically. These resources are compiled, resulting in the generation of the R.java file, which enables you to access your resources programmatically.

If you use a different development environment, you need to use the aapt toolcommand-line interface to compile your resources and package your application binaries to deploy to the phone or emulator. You can find the aapt tool in the /tools subdirectory of each specific Android SDK version.

Resource Value Types

Android applications rely on many different types of resources—such as text strings, graphics, and color schemes—for user interface design.

These resources are stored in the /res directory of your Android project in a strict (but reasonably flexible) set of directories and files. All resources filenames must be lowercase and simple (letters, numbers, and underscores only).

The resource types supported by the Android SDK and how they are stored within the project are shown in Table.

How Important Resource Types Are Stored in Android Project Resource Directories

How Important Resource Types Are Stored in Android Project Resource Directories

How Important Resource Types Are Stored in Android Project Resource Directories

Storing Different Resource Value Types

The aapt traverses all properly formatted files in the /res directory hierarchy and generates the class file R.java in your source code directory /src to access all variables.

Later in this chapter, we cover how to store and use each different resource type in detail, but for now, you need to understand that different types of resources are stored in different ways.

Storing Simple Resource Types Such as Strings

Simple resource value types, such as strings, colors, dimensions, and other primitives, are stored under the /res/values project directory in XML files. Each resource file under the /res/values directory should begin with the following XML header:

Next comes the root node <resources> followed by the specific resource element types such as <string> or <color>. Each resource is defined using a different element name.

Although the XML file names are arbitrary, the best practice is to store your resources in separate files to reflect their types, such as strings.xml, colors.xml, and so on. However, there’s nothing stopping the developers from creating multiple resource files for a given type, such as two separate xml files called bright_ colors .xml and muted_colors.xml, if they so choose.

Storing Graphics, Animations, Menus, and Files

In addition to simple resource types stored in the /res/values directory, you can also store numerous other types of resources, such as animation sequences, graphics, arbitrary XML files, and raw files. These types of resources are not stored in the /res/values directory, but instead stored in specially named directories according to their type. For example, you can include animation sequence definitions in the /res/anim directory. Make sure you name resource files appropriately because the resource name is derived from the filename of the specific resource. For example, a file called flag.png in the /res/drawable directory is given the name R.drawable.flag.

Understanding How Resources Are Resolved

Few applications work perfectly, no matter the environment they run in. Most require some tweaking, some special case handling. That’s where alternative resources come in. You can organize Android project resources based upon more than a dozen different types of criteria, including language and region, screen characteristics, device modes (night mode, docked, and so on), input methods, and many other device differentiators.

It can be useful to think of the resources stored at the top of the resource hierarchy asdefault resources and the specialized versions of those resources as alternative resources. Two common reasons that developers use alternative resources are for internationalization and localization purposes and to design an application that runs smoothly on different device screens and orientations.

The Android platform has a very robust mechanism for loading the appropriate resources at runtime. An example might be helpful here. Let’s presume that we have a simple application with its requisite string, graphic, and layout resources. In this application, the resources are stored in the top-level resource directories (for example, /res/values/strings.xml, /res/drawable/myLogo.png, and /res/layout/main.xml). No matter what Android device (huge hi-def screen, postage-stamp-sized screen, English or Chinese language or region, portrait or landscape orientation, and so on), you run this application on, the same resource data is loaded and used.

Back in our simple application example, we could create alternative string resources in Chinese simply by adding a second strings.xml file in a resource subdirectory called /res/values-zh/strings.xml (note the –zh qualifier).We could provide different logos for different screen densities by providing three versions of myLogo.png:

  • /res/drawable-ldpi/myLogo.png (low-density screens)
  • /res/drawable-mdpi/myLogo.png (medium-density screens)
  • /res/drawable-hdpi/myLogo.png (high-density screens)

Finally, let’s say that the application would look much better if the layout was different in portrait versus landscape modes. We could change the layout around, moving controls around, in order to achieve a more pleasant user experience, and provide two layouts:

  • /res/layout-port/main.xml (layout loaded in portrait mode)
  • /res/layout-land/main.xml (layout loaded in landscape mode)

With these alternative resources in place, the Android platform behaves as follows:

  • If the device language setting is Chinese, the strings in /res/values-zh/strings.xml are used. In all other cases, the strings in /res/values/strings.xml are used.
  • If the device screen is a low-density screen, the graphic stored in the /res/drawable-ldpi/myLogo.png resource directory is used. If it’s a medium-density screen, the mdpi drawable is used, and so on.
  • If the device is in landscape mode, the layout in the /res/layout-land/main.xml is loaded. If it’s in portrait mode, the /res/layout-port/main.xml layout is loaded.

There are four important rules to remember when creating alternative resources:

  1. The Android platform always loads the most specific, most appropriate resource available. If an alternative resource does not exist, the default resource is used. Therefore, know your target devices, design for the defaults, and add alternative resources judiciously.
  2. Alternative resources must always be named exactly the same as the default resources. If a string is called strHelpText in the /res/values/strings.xml file, then it must be named the same in the /res/values-fr/strings.xml (French) and /res/values-zh/strings.xml (Chinese) string files. The same goes for all other types of resources, such as graphics or layout files.
  3. Good application design dictates that alternative resources should always have a default counterpart so that regardless of the device, some version of the resource always loads.The only time you can get away without a default resource is when you provide every kind of alternative resource (for example, providing ldpi, mdpi, and hdpi graphics resources cover every eventuality, in theory).
  4. Don’t go overboard creating alternative resources, as they add to the size of your application package and can have performance implications. Instead, try to design your default resources to be flexible and scalable. For example, a good layout design can often support both landscape and portrait modes seamlessly—if you use the right controls.

Enough about alternative resources; let’s spend the rest of this chapter talking about how to create the default resources first. In Chapter “Targeting Different Device Configurations and Languages,” we discuss how to use alternative resources to make your Android applications compatible with many different device configurations.

Accessing Resources Programmatically

Developers access specific application resources using the R.java class file and its subclasses, which are automatically generated when you add resources to your project (if you use Eclipse).You can refer to any resource identifier in your project by name. For example, the following string resource named strHello defined within the resource file called /res /values /strings .xml is accessed in the code as R.string.strHello

This variable is not the actual data associated with the string named hello. Instead, you use this resource identifier to retrieve the resource of that type (which happens to be string).

For example, a simple way to retrieve the string text is to call

First, you retrieve the Resources instance for your application Context (android .content. Context), which is, in this case, this because the Activity class extends Context.Then you use the Resources instance to get the appropriate kind of resource you want. You find that the Resources class (android.content.res.Resources) has helper methods for handling every kind of resource.

Before we go any further, we find it can be helpful to dig in and create some resources, so let’s create a simple example. Don’t worry if you don’t understand every aspect of the exercise. You can find out more about each different resource type later in this chapter.

Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Android Topics