CGet Application
93Using resources
3.4 Exploring the AndroidManifest file
As you learned in chapter 1, Android requires a manifest file for every application— AndroidManifest.xml. This file, which is placed in the root directory of the project source, describes the application context and any supported activities, services, broad- cast receivers, or content providers, as well as the requested permissions for the appli- cation. You’ll learn more about services, Intents, and BroadcastReceivers in chapter 4 and about content providers in chapter 5. For now, the manifest file for our RestaurantFinder sample application, as shown in the following listing, contains only the <application> itself, an <activity> element for each screen, and several <uses- permission> elements. <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android"> <application android:icon="@drawable/restaurant_icon_trans" android:label="@string/app_short_name" android:name="RestaurantFinderApplication" android:allowClearUserData="true" android:theme="@android:style/Theme.Black"> <activity android:name="ReviewCriteria" android:label="@string/app_short_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity android:name="ReviewList" android:label="@string/app_name_reviews"> <intent-filter> <category android:name="android.intent.category.DEFAULT" /> <action android:name="com.msi.manning.restaurant.VIEW_LIST" /> </intent-filter> </activity> <activity android:name="ReviewDetail" android:label="@string/app_name_review"> <intent-filter> <category android:name="android.intent.category.DEFAULT" /> <action android:name="com.msi.manning.restaurant.VIEW_DETAIL" /> Listing 3.12 The RestaurantFinder AndroidManifest.xml file
Define ReviewCriteria Activity
B
C
Define MAIN LAUNCHER Intent filter
99 Summary </intent-filter> </activity> </application> <uses-permission android:name="android.permission.CALL_PHONE" /> <uses-permission android:name="android.permission.INTERNET" /> </manifest>
In the RestaurantFinder descriptor file, you first see the root <manifest> element dec- laration, which includes the application’s package declaration and the Android namespace. Then you see the <application> element with both the name and icon attributes defined. You don’t have to include the name attribute here unless you want to extend the default Android Application object to provide some global state to your application. We took this approach so we could access the Application instance to store the current Review object. The icon is also optional; if you don’t specify one, a sys- tem default is used to represent your application on the main menu. It’s highly recom- mended that you provide an attractive icon for your application to make it stand out.
After the application itself is defined, you see the child <activity> elements within. These elements define each Activity the application supports
B
(note that the manifest file can use Android resources as well, such as with @string/app_name). As we noted when we discussed activities in general, one Activity in every application is defined as the entry point for the application; this Activity has the <intent- filter> action MAIN and category LAUNCHER designationC
. This tells the Android platform how to start an application from the Launcher, meaning this Activity will be placed in the main menu on the device.After the ReviewCriteriaActivity, you see another <activity> designation for ReviewList. This Activity also includes an <intent-filter>, but for our own action, com.msi.manning.restaurant.VIEW_LIST. This tells the platform that this Activity should be invoked for this Intent. Last in our manifest file, we have a <uses- permission> element. This element also relates to Intents and tells the platform that this application needs the CALL_PHONE permission. We touched on permissions briefly in chapter 2 and in other places in this book—mainly when we’re adding a new feature and require a <uses-permission> element to allow the desired behavior.
The RestaurantFinder sample application uses a fairly basic manifest file with three activities and a series of Intents. Wrapping up the description of the manifest file completes our discussion of views, activities, resources, and working with UIs in Android.
3.5
Summary
A big part of the Android platform revolves around the UI and the concepts of activi- ties and views. In this chapter, we explored these concepts in detail and worked on a sample application to demonstrate them. In relation to activities, we addressed the concepts and methods involved, and we covered the all-important lifecycle events the platform uses to manage them. With regard to views, we looked at common and cus- tom types, attributes that define layout and appearance, and focus and events.
In addition, we looked at how Android handles various types of resources, from simple types to more involved layouts, arrays, and animations, and how these relate to, and are used in, views and activities. We also explored the AndroidManifest.xml appli- cation descriptor and how it brings all these pieces together to define an Android application.
This chapter has given you a good foundation for general Android UI develop- ment. Now we need to go deeper into the Intent and BroadcastReceiver classes, which comprise the communication layer that Android activities and other compo- nents rely on. We’ll cover these items, along with longer-running Service processes and the Android interprocess communication (IPC) system involving the Binder, in chapter 4, where you’ll also complete the RestaurantFinder application.
101