Game Development Reference
In-Depth Information
started in response 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 where 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, the only thing that gets specified is the name
attribute, which identifies the intent to which the activity will react. 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 this type of 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 this type
of 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 filters 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 indicated earlier, we'll only ever have a single activity in our game. This activity will have
exactly the same intent filter specification as shown previously. The reason we 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.
The <uses-permission> Element
We are leaving the <application> element now and coming back to elements that we normally
define as children of the <manifest> element. One of these elements is the <uses-permission>
element.
Android has an elaborate security model. Each application is run in its own process and virtual
machine (VM), with its own Linux user and group, and it cannot influence other applications.
 
 
Search WWH ::




Custom Search