AndroidManifest.xml 详解 (三) 之Activity—— 译自《Beginning Android Games》

接上篇~

<activity>元素

现在我们来电有趣的。这里有一个叫Mr. Nom的例子：

<activity android:name=".MrNomActivity"
android:label="Mr. Nom"
android:screenOrientation="portrait">
android:configChanges="keyboard|keyboardHidden|orientation">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

我们先来看看<activity>标签的属性：

1、name: 它指定了 activity类相对于我们之前讨论的<manifest>元素中定义的package属性的名字，我们也可以在这里指定成类的全路径。

2、label : 我们已经在<application>指定了相同的属性。定义Label属性，它的值就会显示在activity 的 title 栏里面。这个label属性同样可以定义在入口activity，它将显示

在application launcher上（话说这个怎么翻译。。）。如果我们不指定它，<application>元素中的label属性将会被替代。Note:我在这里使用了一个真实的字符串来替代一个

String.xml文件中提供的字符串

3、screenOrientation：这属性指定了我们Activity的使用方向（横向，纵向等），在游戏Mr. Nom中我们指定为纵向。两者选一，如果我们希望在横向状态中运行程序

我们也可以指定横向模式，配置这个属性，它就会在Activity生存周期中强制保持这个模式，如果不配置这个属性，当我们设备方向发生转化是，设备会自动转化模式——同时

这个Activity也会被摧毁然后重新启动。我们不希望在游戏里发生这种情况。通常我们在游戏中选择横向或纵向模式。

4、configChanges：调整设备或者键盘滑出都是一种变化事件，在这种情况下Android会销毁和重新启动我们的应用去适应这种变化。这在我们游戏中不是我们所想看到的

现象。配置<activity>元素中的screenOrientation属性可以解决这种现象。它允许我们指定在某种变化发生后阻止Android去销毁和重新启动Activity。多个配置属性用 | 分隔。

在之前的情况下，我们阻止保持了keyboard 和 keyboardHidden 还有 orientation发生时去触发销毁和重新启动Activity。

在<application>元素中，<activity>元素还有许多其他的属性可以配置，但是在游戏开发中，刚才讨论的4个属性已经够用了。

现在你可能注意到<activity> 元素中的内容不是空的，存在着其他的元素，同时它包含了2个子元素，他们是干什么用的？

在我之前说明的内容中，它们是没有指出应用的主要入口的。相对的，由于intents 发出的系统广播的特性或者一个第三放应用的引入，一个应用或许会有许多个启动点。

不论如何我们需要在应用启动的时候利用intents 的特性去通知一个特定的activities或者services启动，这个就是<intent-filter>元素纯在的理由。

在之前的例子中，我们指定了2个类型的intent filters，一个是<action> ，另外一个是<category>。这个<action>告诉Android哪一个Activity是应用启动的入口，<category>

元素指定了在应用繁忙的时候我们希望哪个Activity添加到应用launcher（这个单词怎么翻译。。）。

对于<action>和<category>元素都有用来标示应答intent请求的属性。intent android.intent.action.MAIN 指定了这个Activity是Android启动的入口。intent android.intent.category.LAUNCHER 用来告诉Android哪一个Activity被指定作为应用的launcher。

通常我们只有一个Activity定义了这2个intent filters，然而，一个Android应用通常支持许多个像这样的Activity

<activity android:name=".MySubActivity"
android:label=“Sub Activity Title"
android:screenOrientation="portrait">
android:configChanges="keyboard|keyboardHidden|orientation"/>

这里没有intent filters被指定。其中只指定了我们刚才讨论的四个属性。当我们定义了一个象这样的Activity，这个Activity在应用中就是唯一的。我们用一个特殊的intent启动这样一个activity。比如说我们在一个Activity中按下一个按钮就会启动一个新的Activity。我们将在接下来的小节中看到如何启动一个Activity。

总结：我们有一个Activity指定了2个intent filter，这样这个Activity才能成为应用的入口Activity。对于其他的Activity，我们不适用intent filter,将它们作为应用内部的的Activity

NOTE：就像早先讲的，我们的游戏曾经只有一个Activity。就像上面将的一样，这个activity拥有2个相同规格的intent filter。我讨论怎么样去定义多个Activity的原因是我们将要

开发的游戏会有许多个Activity。别担心，开发这个游戏会很简单。

接下来一个元素是<uses-permission>，

同时附上原文：

The <activity> Element
Now it’s getting interesting. Here’s a hypothetical example for our Mr. Nom game:

<activity android:name=".MrNomActivity"
android:label="Mr. Nom"
android:screenOrientation="portrait">
android:configChanges="keyboard|keyboardHidden|orientation">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

Let’s have a look at the attributes of the <activity> tag first.

name: This specifies the name of the activity’s class relative to the package attribute
we specified in the <manifest> element. You can also specify a fully qualified class
name here.

label: We already specified the same attribute in the <application>. This label is
displayed in the title bar of the activity (if it has one).The label will also be used as
the text displayed in the application launcher if the activity we define is an entry
point to our application. If we don’t specify it, the label from the <application>
element will be used instead. Note that I used a raw string here instead of a
reference to a string in the string.xml file.

screenOrientation: This attribute specifies what orientation the activity will use.
Here I specified portrait for our Mr. Nom game, which will only work in portrait
mode. Alternative, we could specify landscape if we wanted to run in landscape
mode. Both configurations will force the orientation of the activity to stay the same
over the activity’s life cycle, no matter how the device is actually oriented. If we
leave out this attribute, then the activity will use whatever the current orientation of
the device is, usually based on accelerometer data. This also means that whenever
the device orientation changes, the activity will be destroyed and restarted—
something that’s undesirable in the case of a game. Usually we fix the orientation of
our game’s activity to either landscape or portrait mode.

configChanges: Reorienting the device or sliding out the keyboard is
considered a configuration change. In the case of such a change,
Android will destroy and restart our application to accommodate the
change. That’s not so good in the case of a game. The configChanges
attribute of the <activity> element comes to the rescue. It allows us
to specify which configuration changes we want to handle ourselves
without destroying and recreating our activity. Multiple configuration
changes can be specified by using the | character to concatenate
them. In the preceding case, we handle the changes keyboard,
keyboardHidden, and orientation ourselves.

As with the <application> element, there are of course more attributes that you can
specify for an <activity> element. For game development, though, we get away with
the four attributes just discussed.

Now, you might have noticed that the <activity> element isn’t empty, but houses
another element, which itself contains two more elements. What are those for?
As I pointed out earlier, there’s no notion of a single main entry point to your applicatio
on Android. Instead, we can have multiple entry points in the form of activities and
services that are started due to specific intents being sent out by the system or a third
party application. Somehow we need to communicate to Android which activities and
services of our application will react (and in what ways) to specific intents. That’s wher
the <intent-filter> element comes into play.

In the preceding example, we specify two types of intent filters: an <action> and a
<category>. The <action> element tells Android that our activity is a main entry point to
our application. The <category> element specifies that we want that activity to be added
to the application launcher. Both elements together allow Android to infer that when the
icon in the application launcher for the application is pressed, it should start that specific
activity.

For both the <action> and <category> elements, all that gets specified is the name
attribute, which identifies the intent the activity will react to. The intent
android.intent.action.MAIN is a special intent that the Android system uses to start the
main activity of an application. The intent android.intent.category.LAUNCHER is used to
tell Android whether a specific activity of an application should have an entry in the
application launcher.

Usually we’ll only have one activity that specifies these two intent filters. However, a
standard Android application will almost always have multiple activities, and these need
to be defined in the manifest.xml file as well. Here’s an example definition of such a
subactivity:

<activity android:name=".MySubActivity"
android:label=“Sub Activity Title"
android:screenOrientation="portrait">
android:configChanges="keyboard|keyboardHidden|orientation"/>

Here, no intent filters are specified—only the four attributes of the activity we discussed
earlier. When we define an activity like this, it is only available to our own application. We

start such an activity programmatically with a special kind of intent, say, when a button
is pressed in one activity to cause a new activity to open. We’ll see in a later section how
we can start an activity programmatically.

To summarize, we have one activity for which we specify two intent filter so that it
becomes the main entry point of our application. For all other activities, we leave out the
intent filter specification so that they are internal to our application. We’ll start these
programmatically.

NOTE: As said earlier, we’ll only ever have a single activity in our games. This activity will have
exactly the same intent filter specification as shown previously. The reason I discussed how to
specify multiple activities is that we are going to create a special sample application in a minute
that will have multiple activities. Don’t worry, it’s going to be easy.