Creating Applications and Activities

previous Android Development Tools

Before you start writing Android applications, it’s important to understand how they’re constructed and have an understanding of the Android application life cycle. In this chapter, you’ll be introduced to the loosely coupled components that make up Android applications (and how they’re bound together using the Android manifest). Next you’ll see how and why you should use external resources, before getting an introduction to the Activity component.

In recent years, there’s been a move toward development frameworks featuring managed code, such as the Java virtual machine and the .NET Common Language Runtime.

Mobile devices now come in many shapes and sizes and are used internationally. In this chapter, you’ll learn how to give your applications the flexibility to run seamlessly on different hardware, in different countries, and using multiple languages by externalizing resources.

Next you’ll examine the Activity component. Arguably the most important of the Android building blocks, the Activity class forms the basis for all your user interface screens. You’ll learn how to create new Activities and gain an understanding of their life cycles and how they affect the application lifetime.

Finally, you’ll be introduced to some of the Activity subclasses that wrap up resource management for some common user interface components such as maps and lists.

What Makes an Android Application?

Android applications consist of loosely coupled components, bound using a project manifest that describes each component and how they interact.

There are six components that provide the building blocks for your applications:

• Activities Your application’s presentation layer. Every screen in your application will be an extension of the Activity class. Activities use Views to form graphical user interfaces that display information and respond to user actions. In terms of desktop development, an Activity is equivalent to a Form.

• Services The invisible workers of your application. Service components run invisibly, updating your data sources and visible Activities and triggering Notifications. They’re used to perform regular processing that needs to continue even when your application’s Activities aren’t active or visible.

• Content Providers A shareable data store. Content Providers are used to manage and share application databases. Content Providers are the preferred way of sharing data across application boundaries. This means that you can configure your own Content Providers to permit access from other applications and use Content Providers exposed by others to access their stored data. Android devices include several native Content Providers that expose useful databases like contact information.

• Intents A simple message-passing framework. Using Intents, you can broadcast messages system- wide or to a target Activity or Service, stating your intention to have an action performed. The system will then determine the target(s) that will perform any actions as appropriate.

• Broadcast Receivers Intent broadcast consumers. By creating and registering a Broadcast Receiver, your application can listen for broadcast Intents that match specific filter criteria. Broadcast Receivers will automatically start your application to respond to an incoming Intent, making them ideal for event-driven applications.

• Notifications A user notification framework. Notifications let you signal users without stealing focus or interrupting their current Activities. They’re the preferred technique for getting a user’s attention from within a Service or Broadcast Receiver. For example, when a device receives a text message or an incoming call, it alerts you by flashing lights, making sounds, displaying icons, or showing dialog messages. You can trigger these same events from your own applications using Notifications.

By decoupling the dependencies between application components, you can share and interchange individual pieces, such as Content Providers or Services, with other applications — both your own and those of third parties.

Introducing the Application Manifest

Each Android project includes a manifest fi le, AndroidManifest.xml, stored in the root of the project hierarchy. The manifest lets you define the structure and metadata of your application and its components.

It includes nodes for each of the components (Activities, Services, Content Providers, and Broadcast Receivers) that make up your application and, using Intent Filters and Permissions, determines how they interact with each other and other applications.

It also offers attributes to specify application metadata (like its icon or theme), and additional top-level nodes can be used for security settings and unit tests as described below.

The manifest is made up of a root manifest tag with a package attribute set to the project’s package. It usually includes an xmlns:android attribute that supplies several system attributes used within the file. A typical manifest node is shown in the XML snippet below:

<manifest xmlns:android=http://schemas.android.com/apk/res/android
package=”com.my_domain.my_app”>
[ ... manifest nodes ... ]
</manifest>

The manifest tag includes nodes that define the application components, security settings, and test classes that make up your application. The following list gives a summary of the available manifest node tags, and an XML snippet demonstrating how each one is used:

• application A manifest can contain only one application node. It uses attributes to specify the metadata for your application (including its title, icon, and theme). It also acts as a container that includes the Activity, Service, Content Provider, and Broadcast Receiver tags used to specify the application components.
  <application android:icon=”@drawable/icon”
  android:theme=”@style/my_theme”>
  [ ... application nodes ... ]
  </application>

• activity An activity tag is required for every Activity displayed by your application, using the android:name attribute to specify the class name. This must include the main launch Activity and any other screen or dialogs that can be displayed. Trying to start an Activity that’s not defi ned in the manifest will throw a runtime exception. Each Activity node supports intent-filter child tags that specify which Intents launch the Activity.
  <activity android:name=”.MyActivity” android:label=”@string/app_name”>
  <intent-filter>
  <action android:name=”android.intent.action.MAIN” />
  <category android:name=”android.intent.category.LAUNCHER” />
  </intent-filter>
  </activity>

• service As with the activity tag, create a new service tag for each Service class used in your application. Service tags also support intent-filter child tags to allow late runtime binding.
  <service android:enabled=”true” android:name=”.MyService”></service>

• provider Provider tags are used for each of your application’s Content Providers. Content Providers are used to manage database access and sharing within and between applications.
  <provider android:permission=”com.paad.MY_PERMISSION”
  android:name=”.MyContentProvider”
  android:enabled=”true”
  android:authorities=”com.paad.myapp.MyContentProvider”>
  </provider>

• receiver By adding a receiver tag, you can register a Broadcast Receiver without having to launch your application first. As you’ll see in Chapter 5, Broadcast Receivers are like global event listeners that, once registered, will execute whenever a matching Intent is broadcast by an application. By registering a Broadcast Receiver in the manifest, you can make this process entirely autonomous. If a matching Intent is broadcast, your application will be started automatically and the registered Broadcast Receiver will be run.
  <receiver android:enabled=”true”
  android:label=”My Broadcast Receiver”
  android:name=”.MyBroadcastReceiver”>
  </receiver>

• uses-permission As part of the security model, uses-permission tags declare the permissions you’ve determined that your application needs for it to operate properly. The permissions you include will be presented to the user, to grant or deny, during installation. Permissions are required for many of the native Android services, particularly those with a cost or security implication (such as dialing, receiving SMS, or using the location-based services). As shown in the item below, third-party applications, including your own, can also specify permissions before providing access to shared application components.
  <uses-permission android:name=”android.permission.ACCESS_LOCATION”>
  </uses-permission>

• permission Before you can restrict access to an application component, you need to define a permission in the manifest. Use the permission tag to create these permission definitions. Application components can then require them by adding the android:permission attribute. Other applications will then need to include a uses-permission tag in their manifests (and have it granted) before they can use these protected components.

  Within the permission tag, you can specify the level of access the permission will permit (normal, dangerous, signature, signature Or System), a label, and an external resource containing the description that explain the risks of granting this permission.

  <permission android:name=”com.paad.DETONATE_DEVICE”
  android:protectionLevel=”dangerous”
  android:label=”Self Destruct”
  android:description=”@string/detonate_description”>
  </permission>
• instrumentation Instrumentation classes provide a framework for running tests on your Activities and Services at run time. They provide hooks to monitor your application and its interaction with the system resources. Create a new node for each of the test classes you’ve created for your application.
  <instrumentation android:label=”My Test”
  android:name=”.MyTestClass”
  android:targetPackage=”com.paad.aPackage”>
  </instrumentation>

A more detailed description of the manifest and each of these nodes can be found at
http://code.google.com/android/devel/bblocks-manifest.html
The ADT New Project Wizard automatically creates a new manifest fi le when it creates a new project.
You’ll return to the manifest as each of the application components is introduced.

Using the Manifest Editor

The ADT plug-in includes a visual Manifest Editor to manage your manifest, rather than your having to manipulate the underlying XML directly.

To use the Manifest Editor in Eclipse, right-click the AndroidManifest.xml fi le in your project folder, and select Open With ➪ Android Manifest Editor. This presents the Android Manifest Overview screen, as shown in Figure 3-1. This gives you a high-level view of your application structure and provides shortcut links to the Application, Permissions, Instrumentation, and raw XML screens.

Each of the next three tabs contains a visual interface for managing the application, security, and instrumentation (testing) settings, while the last tag (using the manifest’s fi lename) gives access to the raw XML.

Of particular interest is the Application tab, shown in Figure 3-2. Use it to manage the application node and the application component hierarchy, where you specify the application components.

You can specify an application’s attributes — including its Icon, Label, and Theme — in the Application Attributes panel. The Application Nodes tree beneath it lets you manage the application components, including their attributes and any associated Intent Filter subnodes.

next The Android Application Life Cycle