Androidmanifest. XML (3) activity -- Translated from beginning Android games

Next part ~

<Activity> element

Now we have an interesting call. Here is an example called 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>

Let's take a look at the attributes of the <activity> tag:

1. Name: it specifies the name of the activity class relative to the package attribute defined in the <manifest> element we discussed earlier. We can also specify the full path of the class here.

2. Label: we have already specified the same attribute in <Application>. Defines the label attribute, and its value is displayed in the title bar of the activity. This label attribute can also be defined in the entry activity, which will display

On application launcher (how to translate this ..). If this parameter is not specified, the label attribute in the <Application> element will be replaced. Note: I used a real string to replace

String provided in the string. xml file

3. screenorientation: This attribute specifies the use direction (horizontal, vertical, etc.) of our activity. In the game mr. Nom, we specify vertical. Select either of them. If you want to run the program in the horizontal state

You can also specify the horizontal mode. If this attribute is configured, it will be forced to maintain this mode during the activity lifecycle. If this attribute is not configured, when the device direction is changed, the device will automatically convert the mode-at the same time

This activity will also be destroyed and restarted. We don't want this to happen in the game. We usually choose either horizontal or vertical mode in the game.

4. configchanges: Adjusting the device or keyboard slide is a change event. In this case, Android will destroy and restart our application to adapt to this change. This is not what we want to see in our games.

Symptom. Configuring the screenorientation attribute in the <activity> element can solve this problem. It allows us to specify to prevent android from destroying and restarting the activity after a change occurs. Multiple configuration attributes are separated by |.

In the previous cases, we blocked the destruction and restart of activities when keyboard, keyboardhidden, and orientation were maintained.

 

 

In the <Application> element, the <activity> element has many other attributes that can be configured, but in game development, the four attributes discussed just now are enough.

 

Now, you may notice that the content in the <activity> element is not empty, and there are other elements. It also contains two child elements. What are they used?

 

In the content I mentioned earlier, they did not point out the main entrance of the application. Relatively, because of the System broadcast feature sent by intents or the introduction of a third application, an application may have many startup points.

In any case, we need to use the intents feature to notify a specific activities or services to start when the application is started. This is the reason why the <intent-filter> element is pure.

In the previous example, we specified two types of intent filters: <action> and <Category>. This <action> tells android which activity is the entry for app startup, <Category>

The element specifies which activity we want to add to the app launcher when the app is busy (how to translate this word ..).

The <action> and <Category> elements are used to indicate the attributes of the intent request. Intent Android. Intent. Action. Main specifies that this activity is the android startup portal. Intent Android. Intent. Category. launcher is used to tell android which activity is specified as the launcher of the application.

Generally, only one activity defines the two intent filters. However, an Android Application usually supports many

<Activity Android: Name = ". mysubactivity"
Android: Label = "sub Activity title"
Android: screenorientation = "portrait">
Android: configchanges = "keyboard | keyboardhidden | orientation"/>

 

No intent filters is specified here. Only the four attributes we just discussed are specified. When we define an activity like this, this activity is unique in the application. We use a special intent to start such an activity. For example, we press a button in an activity to start a new activity. We will see how to start an activity in the following section.

 

Conclusion: one activity specifies two intent filters so that the activity can become the entry activity of the application. For other activities, we do not apply intent filter and use them as internal activities of the application.

Note: As we mentioned earlier, our game once had only one activity. As shown above, this activity has two intent filters of the same specification. The reason why I will discuss how to define multiple activities is that we will

The developed game has many activities. Don't worry, it will be very easy to develop this game.

The next element is <uses-Permission>,

Add the original text:

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.

 

 

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 cocould specify landscape if we wanted to run in Landscape
Mode. Both invocations 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
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
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
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
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?
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
<Category>. The <action> element tells android that our activity is a main entry point
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
Icon in the application launcher for the application is pressed, it shoshould 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
Main activity of an application. The intent Android. Intent. Category. launcher is used
Tell Android whether a specific activity of an application shoshould have an entry in
Application launcher.

Usually we'll only have one activity that specifies these two intent filters. However,
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
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
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 previusly. The reason I discussed how
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.