CGet Application
91Using resources
this.name.setText(currentReview.name); this.rating.setText(currentReview.rating); this.location.setText(currentReview.location); this.review.setText(currentReview.content);
if ((currentReview.phone != null) && !currentReview.phone.equals("")) { this.phone.setText(currentReview.phone); } else { this.phone.setText("NA"); } } @Override
public boolean onCreateOptionsMenu(Menu menu) { super.onCreateOptionsMenu(menu); menu.add(0, ReviewDetail.MENU_WEB_REVIEW, 0, R.string.menu_web_review).setIcon( android.R.drawable.ic_menu_info_details); menu.add(0, ReviewDetail.MENU_MAP_REVIEW, 1, R.string.menu_map_review).setIcon( android.R.drawable.ic_menu_mapmode); menu.add(0, ReviewDetail.MENU_CALL_REVIEW, 2, R.string.menu_call_review).setIcon( android.R.drawable.ic_menu_call); return true; } ...
In the ReviewDetail class, we first define View components that we’ll later reference from resources
B
. Next, you see a Handler that’s used to perform a network call to populate an ImageView based on a URL. (This doesn’t relate specifically to our cur- rent discussion of resources, but is included here for completeness. Don’t worry too much about the details of this idea here; we’ll talk about it more when we specifically discuss networking in chapter 5.) After the Handler, we set the layout and View tree using setContentView(R.layout.review_detail)C
. 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.Views defined in XML are inflated by parsing the layout XML and injecting the cor- responding code to create the objects for you. This process is handled automatically by the platform. All the View and LayoutParams methods we’ve discussed have coun- terpart attributes in the XML format. This inflation approach is one of the most important aspects of View-related resources, and it makes them convenient to use and reuse. We’ll examine the layout file we’re referring to here and the specific views it contains more closely in the next section.
You reference resources in code, as we’ve been doing here, through the automati- cally generated R class. The R class is made up of static inner classes (one for each resource type) that hold references to all of your resources in the form of an int value. This value is a constant pointer to an object file through a resource table that’s contained in a special file the aapt tool creates and the R.java file uses.
The last reference to resources in listing 3.6 is for the creation of our menu items
D
. For each of these, we’re referencing a String for text from our own local resources, andUse String and Drawable resources
we’re also assigning an icon from the android.R.drawable resources namespace. You can qualify resources in this way and reuse the platform drawables: icons, images, bor- ders, backgrounds, and so on. You’ll likely want to customize much of your own appli- cations and provide your own drawable resources, which you can do. Note that the platform provides resources if you need them, and they’re arguably the better choice in terms of consistency for the user, particularly if you’re calling out to well-defined actions as we are here: map, phone call, and web page.
We’ll cover how all the different resource types are handled and where they’re placed in source in the next several sections. The first types of resources we’ll look at more closely are layouts and views.
3.3.3 Defining views and layouts through XML resources
As we’ve noted in several earlier sections, views and layouts are often defined in XML1 rather than in Java code. Defining views and layout as resources in this way makes them easier to work with, decoupled from the code, and in some cases reusable in dif- ferent contexts.
View resource files are placed in the res/layout source directory. The root of these XML files is usually one of the ViewGroup layout subclasses we’ve already discussed: RelativeLayout, LinearLayout, FrameLayout, and so on. Within these root elements are child XML elements that comprise the view/layout tree.
A subtle but important thing to understand here is that resources in the res/layout directory don’t have to be complete layouts. For example, you can define a single TextView in a layout file the same way you might define an entire tree starting from an AbsoluteLayout. Yes, this might make the layout name and path potentially confus- ing, but that’s how it’s set up. It might make more sense to have separate res/layout and res/view directories, but that might be confusing too, so keep in mind that res/ layout is useful for more than layout. You might use this approach when a particularly configured View is used in multiple areas of your application. By defining it as a stand- alone resource, it can be maintained more readily over the lifetime of your project.
You can have as many XML layout/view files as you need, all defined in the res/lay- out directory. Each View is then referenced in code, based on the type and ID. Our lay- out file for the ReviewDetail screen, review_detail.xml shown in the following listing, is referenced in the Activity code as R.layout.review_detail—which is a pointer to the RelativeLayout parent View object in the file.
<?xml version="1.0" encoding="utf-8"?> <RelativeLayout
xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent"
android:layout_height="fill_parent"
1 See http://www.xml.com for more information about XML.
93