concept resource in category android
This is an excerpt from Manning's book Android in Action, Third Edition.
In this example application, the setContentView method creates the primary UI, which is a layout defined in main.xml in the /res/layout directory. The EditText view collects information, which in this case is an address. The EditText view is a text box or edit box in generic programming parlance. The findViewById method connects the resource identified by R.id.address to an instance of the EditText class.
Views use strings, colors, styles, and graphic resources, which Android compiles into a binary form and makes available to applications as resources. The automatically generated R.java class, which we introduced in chapter 1, provides a reference to individual resources and is the bridge between binary references and the source code of an Android application. You use the R class, for example, to grab a string of text or a color and add it to a view. The relationship between activities, views, and resources is depicted in figure 3.1.
Figure 3.1. High-level diagram of Activity, view, resource, and manifest relationships, showing that activities are made up of views, and views use resources
Along with the components you use to build an application—views, resources, and activities—Android includes the manifest file we introduced in chapter 1: AndroidManifest.xml. This XML file provides entrance points into your app, as well as describes what permissions it has and what components it includes. Because every Android application requires this file, we’ll address it in more detail in this chapter, and we’ll come back to it frequently in later parts of the book. The manifest file is the one-stop shop for the platform to start and manage your application.
If you’ve done any development involving UIs on any platform, the concepts of activities, views, and resources should seem familiar. Android approaches UI in a slightly different way, and this chapter will help address common points of confusion.
You’ve already seen several examples of resources throughout the book. We’ll now explore them in detail and implement the third and final Activity in RestaurantFinder—the ReviewDetail screen.
When you begin working with Android, you’ll quickly notice many references to a class named R. This class was introduced in chapter 1, and we’ve used it in our previous Activity examples in this chapter. Android automatically generates this class for each of your projects to provide access to resources. Resources are noncode items that the platform automatically includes in your project.
To begin looking at resources, we’ll first explore the various available types, and then we’ll demonstrate examples of each type of resource.
In the ReviewDetail class, we first define View components that we’ll later reference from resources
. Next, you see a handler that’s used to perform a network call to populate an ImageView based on a URL. (Don’t worry too much about the details of the network calls here; these will be addressed in the networking sections in chapter 5.) After the handler, we set the layout and view tree using setContentView (R.layout.review_detail)
. This maps to an XML layout file at src/res/layout/review_detail.xml. Next, we reference some of the View objects in the layout file directly through resources and corresponding IDs.
This is an excerpt from Manning's book Android in Practice.
As we’ve seen, the @ sign in a layout file (which itself is a type of resource) is a reference to another resource. In the case of @string/hello we’re referring to a strings.xml file. It’s always a good idea to keep different types of entities in your project separate from the code. This goes for layouts, strings, images, XML files, and anything that Android refers to as a resource.
With strings and images, this is obvious. If you want to have different resources based on different settings, such as language or location, you can. The @ sign tells Android to parse these values as resources. Android has many resource types, which we’ll learn more about in the next few chapters, but for now let’s take a look at what’s in our strings.xml file.
This externalized string file is in an XML format, and it holds key/value paired data. In the layout we referred to the hello resource, which will ultimately display the “Hello Android!” string. Strings, as well as more complex data types such as colors and drawables (an Android type for shapes), can all be represented in XML and used as resources.
Resource is a broad term. It can mean images used in your application, internationalized text, or any type of static value that you want to externalize from your application code, as we discussed in chapter 1. Resources are defined by placing files in the /res directory of your project. Resources can then be accessed either in code or through references in XML.
Android goes to a lot of trouble to define resource types and make support of resources available through the API. You might wonder why this is necessary. There are several reasons. First, they separate code from external entities such as images and strings. Such separation is a good thing because it keeps the code focused and uncluttered. Second, resources are efficient and fast. XML resources are compiled into a binary format. This makes them friendly at development time, without being slow at runtime. Third, resources enable the support of dynamic loading at runtime based on various environment properties such as language, screen configuration, and hardware capability. This enables internationalization and localization, which we’ll learn more about later, and other environment specific changes.
The resources that we’ll deal with for DealDroid are simple: they’re strings, plurals, and layouts. Plurals are a special type of resource that allow the system to automatically deal with plurality for strings; we’ll come to those in a moment. First, let’s look at the strings DealDroid uses in the following listing.
As promised, the strings we use in the DealDroid application are externalized and defined in an XML file. This XML file is strings.xml and it’s placed in /res/values. The file starts off with the typical XML stanza and then has a root element named resources
. Each string is then defined in its own element with an attribute for the name
. The name will be the ID for the resource, as well as the constant identifier in the generated R class.
All of the strings we defined in strings.xml will be present as constants in the R class with hexadecimal values. The values are pointers to where the initial values have been compiled and stored in the internal resource table. You shouldn’t ever need to dig into the resource table unless you’re doing serious Android hacking, but it helps to understand that this is how compiled resources work.
