File Conventions

Some conventions and rules apply generally to all elements and attributes in the manifest: Elements

Only the <mani fest> and <application> elements are required, they each must be present and can occur only once. Most of the others can occur many times or not at all — although at least some of them must be present for the manifest to accomplish anything meaningful.

If an element contains anything at all, it contains other elements. All values are set through attributes, not as character data within an element.

Elements at the same level are generally not ordered. For example, <activity>, <provider>, and <service> elements can be intermixed in any sequence. (An <activity-alias>element is the exception to this rule: It must follow the <activity> it is an alias for.)

Attributes

In a formal sense, all attributes are optional. However, there are some that must be specified for an element to accomplish its purpose. Use the documentation as a guide. For truly optional attributes, it mentions a default value or states what happens in the absence of a specification.

Except for some attributes of the root <manifest> element, all attribute names begin with an android: prefix — for example, android:alwaysRetainTaskState. Because the prefix is universal, the documentation generally omits it when referring to attributes by name.

Declaring class names

Many elements correspond to Java objects, including elements for the application itself (the <application> element) and its principal components — activities (<activity>), services (<service>), broadcast receivers (<receiver>), and content providers

If you define a subclass, as you almost always would for the component classes (Activity, Service, BroadcastReceiver, and ContentProvider), the subclass is declared through a name attribute. The name must include the full package designation. For example, an Service subclass might be declared as follows:

<service android:name="com.example.project.SecretService" . . . >

</application> </manifest>

However, as a shorthand, if the first character of the string is a period, the string is appended to the application's package name (as specified by the <manifest> element's package attribute). The following assignment is the same as the one above:

<manifest package="com.example

.project" . . . >

<application . . . >

<service android:name=

".SecretService" . .

. >

</service>

</application>

</manifest>

When starting a component, Android creates an instance of the named subclass. If a subclass isn't specified, it creates an instance of the base class.

Multiple values

If more than one value can be specified, the element is almost always repeated, rather than listing multiple values within a single element. For example, an intent filter can list several actions:

<intent-filter . .

>

<action android

name=

"android

intent

action

EDIT" />

<action android

name=

"android

intent

action

INSERT" />

<action android

name=

"android

intent

action

DELETE" />

</intent-filter>

Some attributes have values that can be displayed to users — for example, a label and an icon for an activity. The values of these attributes should be localized and therefore set from a resource or theme. Resource values are expressed in the following format,

@[package:]type:name where the package name can be omitted if the resource is in the same package as the application, type is a type of resource — such as "string" or "drawable" — and name is the name that identifies the specific resource. For example:

<activity android:icon="@drawable/smallPic" . . . >

Values from a theme are expressed in a similar manner, but with an initial '?' rather than ?[package:]type:name String values

Where an attribute value is a string, double backslashes ('\\') must be used to escape characters — for example, '\\n' for a newline or '\\uxxxx' for a Unicode character.

0 0

Post a comment