Game Development Reference
In-Depth Information
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>
element.
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 we
used a raw string here instead of a reference to a string in the
string.xml
file.
ï?®
screenOrientation
: This attribute specifies the orientation that the activity
will use. Here we specified
portrait
for our Mr. Nom game, which will
only work in portrait mode. Alternatively, 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 the current orientation of the device, 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. We usually fix the orientation of our
game's activity either to landscape mode 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 desirable 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
re-creating 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, we get away with the four attributes
just discussed.
Now, you might have noticed that the
<activity>
element isn't empty, but it houses another
element, which itself contains two more elements. What are those for?
As we pointed out earlier, there's no notion of a single main entry point to your application on
Android. Instead, we can have multiple entry points in the form of activities and services that are
