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.