In Chapter 2, you got an overview of an Android application and a quick look at some of its underlying concepts. Among these, resources, content providers, and intents form the three primary pillars of Android UI programming. Android depends on resources for look-and-feel flexibility, content providers for abstracting data into services, and intents for interoperability
and UI reuse. You must fully understand these three concepts in order to build successful Android applications, so we’ll discuss them in depth here.

Understanding Resources

Resources are critical to the Android architecture. In this section, you’ll learn what resources are and how to create them using resource files. You’ll find out that resources are declarative, and that Android creates resource IDs for convenient use in your Java programs. You’ll also see how the R.java source file mediates the generation and usage of these resource IDs. Then
you’ll learn how to define resources in XML files, reuse resources in other resource XML definitions, and reuse resources in Java programs. In addition to these XML-based resources, this chapter also covers two other types of resources: raw resources and assets.

String Resources

A resource in Android is a file (like a music file) or a value (like the title of a dialog box) that is bound to an executable application. These files and values are bound to the executable in such a way that you can change them without recompiling and redeploying the application.

Resources play a part in many, if not all, familiar UI frameworks. Familiar examples of resources include strings, colors, and bitmaps. Instead of hard-coding strings in an application, for example, you can use their IDs instead. This indirection lets you change the text of the string resource without changing the source code.

Let’s start with strings and see how they are used as resources. Android allows you to define multiple strings in one or more XML resource files. These XML files containing string-resource definitions reside in the /res/values subdirectory. The names of the XML files are arbitrary, although you will commonly see the file name as strings.xml. Listing 3-1 shows an example of
a string-resource file.

Listing 3-1. Example strings.xml File


hello
hello appname


When this file is created or updated, the Eclipse ADT plug-in will automatically update a Java class in your application’s root package called R.java with unique IDs for the two string resources specified.

For the string-resource file in Listing 3-1, the updated R.java file would have these entries:
public final class R {
...other entries depending on your project and application
public static final class string
{
...other entries depending on your project and application
public static final int hello=0x7f040000;
public static final int app_name=0x7f040001;
...other entries depending on your project and application
}
...other entries depending on your project and application
}

Let’s focus on the static definition for static final class string. R.java creates this inner static class as a namespace to hold string-resource IDs. The two static final ints defined with variable names hello and app_name are the resource IDs that represent the corresponding string resources. You could use these resource IDs anywhere in the source code through the following code structure:

R.string.hello
Note that these generated IDs point to ints rather than strings. Most methods that take strings also take these resource identifiers as inputs. Android will resolve those ints to strings where needed.

It is merely a convention that most sample applications define all strings in one strings. xml file. Android takes any number of arbitrary files as long as the structure of the XML file looks like Listing 3-1 and the file resides in the /res/values subdirectory.

The structure of this file is easy to follow. You have the root node of followed by one or more of its child elements of . Each element or node has a property called name that will end up as the id attribute in R.java and the actual text for that string ID.

To see that multiple string-resource files are allowed in this subdirectory, you can place another file with the following content in the same subdirectory and call it strings1.xml:



hello 1
hello appname 1


The Eclipse ADT plug-in will validate the uniqueness of these IDs at compile time and place them in R.java as two additional constants: R.string.hello1 and R.string.app_name1.

Layout Resources

A layout resource is another key resource commonly used in Android programming. In Android, the view for a screen is often loaded from an XML file as a resource. These XML files are called layout resources. Consider this code segment for a sample Android activity:

public class HelloWorldActivity extends Activity
{
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView tv = (TextView)this.findViewById(R.id.text1);
tv.setText("Try this text instead");
}
………
}

The line setContentView(R.layout.main) points out that there is a static class called R.layout, and within that class there is a constant called main (an integer) pointing to a View defined by an XML layout-resource file. The name of the XML file would be main.xml, which needs to be placed in the resources’ layout subdirectory. In other words, this statement would expect the programmer to create the file /res/layout/main.xml and place the necessary layout definition in that file. The contents of the main.xml layout file could look like Listing 3-2.

Listing 3-2. Example main.xml Layout File


android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
>

android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="@string/hello"
/>

android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="@+string/hello"
/>


The layout file in Listing 3-2 defines a root node called LinearLayout, which contains a TextView followed by a Button. A LinearLayout lays out its children vertically or horizontally— vertically, in this example.

You will need to define a separate layout file for each screen. More accurately, each layout needs a dedicated file. If you are painting two screens, you will likely need two layout files such as /res/layout/screen1_layout.xml and /res/layout/screen2_layout.xml.

For example, if you have two files under /res/layout/ called file1.xml and file2.xml, you’ll have the following entries in R.java:

public static final class layout {
.... any other files
public static final int file1=0x7f030000;
public static final int file2=0x7f030001;
}

The views defined in these layout files are accessible in code if you reference their IDs from R.java:

TextView tv = (TextView)this.findViewById(R.id.text1);
tv.setText("Try this text instead");

In this example, you locate the TextView by using the findViewById method of the Activity class. The constant R.id.text1 corresponds to the ID defined for the TextView. The id for the TextView in the layout file is as follows:


..


The attribute value for the id attribute indicates that a constant called text1 will be used to uniquely identify this view among other views hosted by that activity. The plus sign (+) in @+id/text1 means that text1 will be created if it doesn’t exist already. There is more to this syntax, in which ids are assigned to resources. We’ll talk about that next.

Resource-Reference Syntax

Irrespective of the type of resource, all Android resources are identified (or referenced) by their id in Java source code. The syntax you use to allocate an id to a resource in the XML file is called resource-reference syntax. The id attribute syntax in the previous example @+id/text1 has the following formal structure:

@[package:]type/name
The type corresponds to one of the resource-type namespaces available in R.java, such as
the following:
• R.drawable
• R.id
• R.layout
• R.string
• R.attr
The corresponding types in XML resource-reference syntax are as follows:
• drawable
• id
• layout
• string
• attr
The name part in the resource reference @[package:]type/name is the name given to the resource; it also gets represented as an int constant in R.java. Now we have come to the important part of this syntax: the package. If you don’t specify any package, then the pair type/ name will be resolved based on local resources and the application’s local R.java package.

If you specify android:type/name, on the other hand, the reference will look in the package identified by android: the android.R.java file, to be precise. So you can use any Java package name in place of the package placeholder to locate the right R.java file to resolve the reference. Based on this information, let’s analyze a few examples:


// Compile error, as id will not take raw text strings

// wrong syntax. It is missing a type name
// you will get an error "No Resource type specified


//Error: No Resource found that matches id "text"
//Unless you have taken care to define "text" before

// Error: Resource is not public
// indicating that there is no such id in android.R.id
// Of course this would be valid if Android R.java were to define
// an id with this name

//Success: Creates an id called "text" in the local package

Defining Your Own Resource IDs for Later Use

The general pattern for allocating an id is either to create a new one or to use the one created by the Android package. However, it is possible to create ids beforehand and use them later in your own packages.

The line in the preceding code segment indicates that an id named text is going to be used if one already exists. If the id doesn’t exist, then a new one is going to be created. So when might an id such as text already exist in R.java for it to be reused?

You might be inclined to put a constant like R.id.text in R.java, but R.java is not editable. Even if it were, it gets regenerated every time something gets changed, added, or deleted in the /res/* subdirectory. However, you can use a resource tag called item to define an id without attaching to any particular resource. Here is an example:




The type refers to the type of resource—an id in this case. Once this id is in place, the following
View definition would work:

..

The lifecycle of Android applications differs greatly from the lifecycle of web-based J2EE applications. J2EE apps are loosely managed by the container they run in. For example, a J2EE container can remove an application from memory if it sits idle for a predetermined time period. But the container generally won’t move applications in and out of memory based on load and/or available resources. In other words, it’s up to the application owners to ensure that resources are available.

The lifecycle of an Android application, on the other hand, is strictly managed by the system, based on the user’s needs, available resources, and so on. A user might want to launch a web browser, for example, but the system ultimately decides whether to start the application.Although the system is the ultimate manager, it adheres to some defined and logical guidelines
to determine whether an application can be loaded, paused, or stopped. If the user is currently working with an activity, the system will give high priority to that application. Conversely, if an activity is not visible and the system determines that an application must be shut down to free up resources, it will shut down the lower-priority application.

The concept of application lifecycle is logical, but a fundamental aspect of Android applications complicates matters. Specifically, the Android application architecture is component-and integration-oriented. This allows a rich user experience, seamless reuse, and easy application integration, but creates a complex task for the application-lifecycle manager.

Let’s consider a typical scenario. A user is talking to someone on the phone and needs to open an e-mail message to answer a question. She goes to the home screen, opens the mail application, opens the e-mail message, clicks a link in the e-mail, and answers her friend’s question by reading a stock quote from a web page. This scenario would require four applications: the home application, a talk application, an e-mail application, and a browser application. As the user navigates from one application to the next, her experience is seamless. In the background, however, the system is saving and restoring application state. For instance,when the user clicks the link in the e-mail message, the system saves metadata on the running
e-mail–message activity before starting the browser-application activity to launch a URL. In fact, the system saves metadata on any activity before starting another, so that it can come back to the activity (when the user backtracks, for example). If memory becomes an issue, the system will have to shut down a process running an activity and resume it as necessary.

Android is sensitive to the lifecycle of an application and its components. Therefore, you’ll need to understand and handle lifecycle events in order to build a stable application. The processes running your Android application and its components go through various lifecycle events, and Android provides callbacks that you can implement to handle state changes. For
starters, you’ll want to become familiar with the various lifecycle callbacks for an activity (see Listing 2-7).

Listing 2-7. Lifecycle Methods of an Activity
protected void onCreate(Bundle savedInstanceState);
protected void onStart();
protected void onRestart();
protected void onResume();
protected void onPause();
protected void onStop();
protected void onDestroy();

Listing 2-7 shows the list of lifecycle methods that Android calls during the life of an activity. It’s important to understand when each of the methods is called by the system to ensure that you implement a stable application. Note that you do not need to react to all of these methods. If you do, however, be sure to call the superclass versions as well. Figure 2-9 shows
the transitions between states.

The system can start and stop your activities based on what else is happening. Android calls the onCreate() method when the activity is freshly created. onCreate() is always followed by a call to onStart(), but onStart() is not always preceded by a call to onCreate() because onStart() can be called if your application was stopped (from onStop()). When onStart() is called, your activity is not visible to the user, but it’s about to be. onResume() is called after onStart(), just when the activity is in the foreground and accessible to the user. At this point, the user is interacting with your activity.

When the user decides to move to another activity, the system will call your activity’s onPause() method. From onPause(), you can expect either onResume() or onStop() to be called. onResume() is called, for example, if the user brings your activity back to the foreground.onStop() is called if your activity becomes invisible to the user. If your activity is brought back
to the foreground, after a call to onStop(), then onRestart() will be called. If your activity sits on the activity stack but is not visible to the user, and the system decides to kill your activity, onDestroy() will be called.

The state model described for an activity appears complex, but you are not required to deal with every possible scenario. In fact, you will mostly handle onCreate() and onPause().You will handle onCreate() to create the user interface for your activity. In this method, you will bind data to your widgets and wire up any event handlers for your UI components. In
onPause(), you will want to persist critical data to your application’s data store. It’s the last safe method that will get called before the system kills your application. onStop() and onDestroy() are not guaranteed to be called, so don’t rely on these methods for critical logic.

The takeaway from this discussion? The system manages your application, and it can start, stop, or resume an application component at any time. Although the system controls your components, they don’t run in complete isolation with respect to your application. In other words, if the system starts an activity in your application, you can count on an application context in your activity. For example, it’s not uncommon to have global variables shared among the activities in your application. You can share a global variable by writing an extension of the android.app.Application class and then initializing the global
variable in the onCreate() method (see Listing 2-8). Activities and other components in your application can then access these references with confidence when they are executing.

Listing 2-8. An Extension of the Application Class
public class MyApplication extends Application
{
// global variable
private static final String myGlobalVariable;
@Override
public void onCreate()
{
super.onCreate();
//... initialize global variables here
myGlobalVariable = loadCacheData();
}
public static String getMyGlobalVariable() {
return myGlobalVariable;
}
}

In the next section, we’ll give you some armor to help you develop Android applications—we will discuss debugging.

Debugging Your App

After you write a few lines of code for your first application, you’ll start wondering if it’s possible to have a debug session while you interact with your application in the emulator. Shortly after that, you’ll instinctively run to System.out.println(), which will fail because the code is running on the emulator and the sys-out statement is not fed back to the IDE. But don’t worry; the Android SDK includes a host of applications that you can use for debugging purposes.

To log messages from your application, you’ll want to use the android.util.Log class. This class defines the familiar informational, warning, and error methods. You can also get detailed tracing information by using the android.os.Debug class, which provides a start-tracing method (Debug.startMethodTracing()) and a stop-tracing method (Debug.stopMethodTracing()). You can then view the tracer output using the trace-viewer tool included in the Android SDK. The SDK also includes a file-explorer tool that you can use to view files on the device. These tools are integrated with the Eclipse IDE (see Figure 2-10).

You can view the tools by selecting the Debug perspective in Eclipse. You can also launch each tool by going to Window ➤ Show View ➤ Other ➤ Android.One of the tools that you’ll use throughout your Android development is LogCat. This tool
displays the log messages that you emit using android.util.Log, exceptions, and so on. We will introduce the other tools throughout the book.