android:fromXScale="0.5" android:toXScale="2.0" android:fromYScale="0.5" android:toYScale="2.0" android:pivotX="50%" android:pivotY="50%" android:startOffset="700" android:duration="400" android:fillBefore="false" />
In code you can reference and use this animation with any View object (TextView, for example) as follows:
view.startAnimation(AnimationUtils.loadAnimation(this, R.anim.scaler));.
This will scale
B
the view element up in size on both the X and Y axes. Though we do not have any animations in the RestaurantFinder sample application by default, to see this work you can simply add the startAnimation method to any view element in the code and reload the application. Animations can come in handy, so you should be aware of them. We will cover animations and other graphics topics in detail in chapter 9.With our journey through Android resources now complete, we next need to address the final aspect of RestaurantFinder we have yet to cover, the AndroidMani- fest.xml manifest file, which is required for every Android application.
3.4
Understanding the AndroidManifest file
As you learned in chapter 1, Android requires a manifest file for every applica- tion—AndroidManifest.xml. This file, which is placed in the root directory of the proj- ect source, describes the application context and any supported activities, services, intent receivers, and/or content providers, as well as permissions. You will learn more about services, intents, and intent receivers in the next chapter and about content providers in chapter 5. For now the manifest for our RestaurantFinder sample applica- tion, as shown in listing 3.11, 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>
Listing 3.12 The RestaurantFinder AndroidManifest.xml file
Include <manifest> declaration
B
Include RestaurantFinder- Application declaration
C
Define Review- Criteria ActivityD
E
<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" /> </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 we first see the root <manifest> element dec- laration, which includes the application’s package declaration and the Android namespace
B
. Then we see the <application> element with both the name and icon attributes definedC
. 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 (which we did to store the Review object each screen is operating on). The icon is also optional; if not specified, a system default is used to represent your application on the main menu.After the application itself is defined, we see the child <activity> elements within. These, obviously, define each Activity the application supports
D
(note that the mani- fest file can use Android resources as well, such as with @string/app_name). As was not- ed when discussing activities in general, one Activity in every application is the starting point; this Activity has the <intent-filter> action MAIN and category LAUNCHER des- ignationE
. This tells the Android platform how to start an application from theLauncher, meaning this Activity will be placed in the main menu on the device. Past the ReviewCriteriaActivity we see another <activity> designation for
ReviewList
F
. This Activity also includes an <intent-filter>, but for our own action, com.msi.manning.chapter3.VIEW_LISTG
. This tells the platform that thisActivity should be invoked for this “intent.” You will learn more about exactly how this works in the next chapter. Last in our manifest we have a <uses-permission>
H
element. This also relates to intents and tells the platform that this application needs the CALL_PHONE permission. (We discussed several aspects of security in chapter 2, and we will touch on this in various contexts throughout the book.)
The RestaurantFinder sample application uses a fairly basic manifest file with three activities and a series of intents. This is not a comprehensive example, of course, but all of the elements an Android manifest supports are shown in table 3.4 for reference.
Define ReviewList Activity
F
Define custom Intent filter
G
95 Summary
Wrapping up the description of the manifest file completes our discussion of views, activities, resources, and in general 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 within, views and activities. We also explored the AndroidMani- fest.xml application descriptor and how it brings all these pieces together to define an Android application.
Table 3.4 Supported AndroidManifest.xml elements and their descriptions
Element Position Description
<manifest> root Defines application package and Android namespace
<uses-permission> root Requests a security permission <permission> root Declares a security permission
<instrumentation> root Declares a test instrumentation component <application> root Defines an application, class name, label, icon, or
theme (one per manifest) <activity> child of <application> Defines an Activity class
<intent-filter> child of <activity> Declares the Intents an Activity supports <action> child of <intent-filter> Intent action
<category> child of <intent-filter> Intent category
<data> child of <intent-filter> Intent MIME type, URI scheme, URI authority, or URI path
<meta-data> child of <activity> General metadata, accessible via Compo- nentInfo.metaData
<receiver> root Defines an IntentReceiver, responds to Intents (also supports <intent-filter> children)
<service> root Defines a background Service (also supports <intent-filter> children)
<provider> root Defines a ContentProvider to manage persis- tent data for access by other applications
This chapter has provided a good foundation for general Android UI develop- ment; next we need to go deeper into the concepts of Intent and IntentReceiver
classes, the communication layer that Android activities and other components use. We will cover these items, along with longer-running Service processes and the Android Inter-Process Communication (IPC) system involving the Binder, in chapter 4, where we will also complete the RestaurantFinder application.
97