Android intents and intent filters (2)

Intent Object Parsing

Intent can be divided into two groups:

1. Use the component name to clearly point the intent object to the target component (specify the target component name in the component name segment of the intent object ). Generally, developers of other applications do not know the name of the target component. Therefore, an intent object with a clear name is usually used for internal messages of the application, for example, an activity starts a subordinate service or a sister activity.

2. There is no implicit intent object for naming the target (the component name segment of the intent object is empty. Implicit intent objects are often used to activate components in other applications.

Android sends a clearly-named intent object to an instance of the target class. Except for the component name, no other information in the intent object is used to determine which component should obtain the intent object.

For implicit intent objects, different types are required. When the target component is missing, the android system must find the most suitable component (an activity or service capable of executing the request action, or a group of broadcast referers capable of responding to broadcast notifications) to process this intent object. By comparing the content of the intent object with the intent filter, the system can potentially receive the intent object by associating the content with the component structure. The filter exposes the capabilities of the component and the intent object restrictions that it can process. They open the component to receive potential Open Type implicit intent objects. If the component does not have any filters, it can only receive explicitly named intent objects. A component with a filter can receive named and anonymous intent objects.

The intent Filter checks whether the intent object is received by referring to the following three aspects of the intent object:

1. Action)

2. Data (Uri and data type)

3. Category)

Extras and flags are not used to determine which component receives the intent object.

Intent Filter

Intent filters are used to notify the system that they can process the type of implicit intent objects. Activity, service, and broadcast referers can have one or more intent filters. Each filter describes a set of intent objects that the component will accept. It filters out valid intent objects of the expected type, and filters out unwanted intent objects-but only implicit intent objects that are not desired (intent objects without naming the target class ). An intent object with a clear name is always an instance of the target class sent to it, no matter what it contains; the filter does not work. However, an implicit intent object can only be sent to a component that can be passed through a filter of the component.

Each task that a component can perform has an independent filter that can be presented to users. For example, there are two filters for the noteeditor activity of the Instance app note pad-one is used to start the filter with the specific comment information that the user can view or edit; the other is used to start a new blank comment filter that can be filled and saved by the user. (All note pad filters are described in the "note pad example" section)

An intent filter is an instance of the intentfilter class. However, the android system must understand the capabilities of related components before starting the components. Therefore, intent filters are generally not created using Java code, but in the androidmanifest file of the application. the <intent-filter> element is used for declaration. (If you call the context. registerreceiver () method to dynamically register broadcast referers, you can directly create intentfilter objects as filters .)

Filters have fields similar to the action, data, and classification of intent objects. Filters use these three fields to detect an implicit intent object. All the three fields to be checked must be passed to the intent object of the component with the filter to be passed. If one of them fails, the android system will not send it to the corresponding component-at least not based on that filter. However, because a component can have multiple intent filters, you can use other filters even if you cannot pass intent objects through a filter of the component.

The following details the detection of three domains:

1. Action Domain Detection

List the <action> child elements of the corresponding action in the <intent-filter> element of the configuration file. For example:

<Intent-filter...>
<Action Android: Name = "com. example. Project. show_current"/>
<Action Android: Name = "com. example. Project. show_recent"/>
<Action Android: Name = "com. example. Project. show_pending"/>
...
</Intent-filter>

As shown in the preceding example, an intent object is a naming action, and a filter can list multiple actions. The list cannot be empty. A filter must contain at least one <action> element. Otherwise, it will block all intent objects.

To perform this check, the action specified in the intent object must match the action in the action list of the filter. If no action is specified for the intent object or filter, the following results are generated:

A. If all actions in the list fail to be filtered, the intent object to be matched will not do anything, and all other intent detection will fail. No intent object can pass this filter;

B. On the other hand, intent objects without a specified action will automatically pass the detection-as long as the filter contains at least one action.

2. Classification Domain Detection

The <intent-filter> element also lists categories as sub-elements. For example:

<Intent-filter...>
<Category Android: Name = "android. Intent. Category. Default"/>
<Category Android: Name = "android. Intent. Category. browsable"/>
...
</Intent-filter>

Note that the action and category in the listing file are not replaced by the constants described earlier, but are replaced by the complete string value. For example, in the preceding example, the "android. Intent. Category. browsable" string corresponds to the categor_browsable constant mentioned earlier in this document. Similar to the "android. Intent. Action. Edit" string, it corresponds to the action_edit constant.

For an intent object to pass classification detection, each category in the intent object must match a category in the filter. The filter can list additional categories, but it cannot ignore any category in the intent object.

Therefore, in principle, an unclassified intent object should always pass this check regardless of the classification declared in the filter. This is the case in most cases, but with one exception, Android processes all the implicit intent objects passed to the startactivity () method, just as they contain at least one "android. intent. category. default (corresponding to the category_default constant) "category is the same. Therefore, the activity that receives implicit intent objects must include the "android. Intent. Category. Default" category in their intent filter. (The filter with "android. Intent, action. Main" and "android. Intent. Category. launcher" is an exception. Because they mark the activity as the start of a new task and represent the startup screen. They can include "android. Intent. Category. Default" in the category list, but are not required .)

3. Data Domain Detection

Like action classification detection, data rules for intent filters must also be contained in a sub-element. In the same way as actions and categories, this sub-element can appear multiple times, or do not appear. For example:

<Intent-filter...>
<Data Android: mimetype = "Video/MPEG" Android: Scheme = "HTTP".../>
<Data Android: mimetype = "audio/MPEG" Android: Scheme = "HTTP".../>
...
</Intent-filter>

Each <DATA> element can specify a URI and a data type (MIME media type). Each URI part has an independent attribute --- scheme, host, port, path: Scheme: // host: Port/path

For example, the following URI:

Content: // com. example. Project: 200/folder/subfolder/etc

Scheme is content, host is "com. example. Project", port is "200", and path is "folder/subfolder/etc ". The host and port constitute URI authorization. If no host is specified, the port is ignored.

These attributes are optional, but they are not independent from each other. For example, an authorization means that a scheme must be specified, and a path means that scheme and authorization must be specified.

When the URI in the intent object is compared with a URI rule of the filter, it is only compared to the URI section actually mentioned by the filter. For example, if a filter only specifies one scheme, all URIs with this scheme will match this filter. If a filter specifies a scheme and authorization, but there is no path, the intent objects with the same scheme and all the URLs authorized will match, regardless of their path. If a filter specifies a scheme, authorization, and path, only the same scheme, authorization, and path intent object will match. However, the path rules in the filter can contain wildcards that only require Partially Matching paths.

<DATA> the type attribute of the element specifies the MIME type of the data. It is more common than URI in the filter. For child-type fields, both intent objects and filters can use the "*" wildcard, for example, "text/*" or "audio/*", to indicate that they can match any child type.

Data Detection compares the URI and data type in the intent object and filter. The rules are as follows:

A. Only when the filter does not specify any URI or data type can an intent object with no URI or data type pass detection;

B. an intent object that contains a URI but does not have a data type (and cannot be extracted from the URI) only matches a URI in the filter and the filter does not specify a data type, to pass the detection. This is only applicable to URLs that do not point to actual data, such as mailto: And Tel :.

C. An intent object that contains a data type but does not have a URI can pass detection only when the filter also lists the same data type and does not specify a URI.

D. an intent object that contains the URI and data types (or the data type can be inferred from the URI) only matches the type listed in the filter, in order to pass the detection of the Data Type part, if its URI part matches a URI in the filter or the intent object has a content: or file: URI, and the filter does not specify a URI, in this way, the URI part can be detected. In other words, if the filter only lists data types, a component is assumed to support content: and file: data.

If an intent object can be passed to an activity or service through multiple filters, you can ask which component the user wants to activate. If no target is found, an exception occurs.

Common Cases

The last entry (Rule D) in the preceding data detection rule reflects the expectation that a component can obtain local data from a file or content provider. Therefore, their filters can only list data types, and do not need to explicitly name content: and file: solutions. This is a typical situation. For example, the following <DATA> element tells android that a component can get an image from a content provider and display it: <data Android: mimetype = "image/*"/>

Because most valid data is distributed through the content provider, it is most common to specify a filter with a data type but no Uri.

Another common configuration is a filter with a solution and data type. For example, the <DATA> element like the following tells the android component to get a video from the network and display it.

<Data Android: Scheme = "HTTP" Android: TYPE = "Video/*"/>

For example, let's look at what the browser application will do when a user clicks a link on a webpage. First, it will try to display the data (if the link is an HTML page, it will be displayed ). If the data cannot be displayed, the scheme and data type will be put together in an implicit intent object, and an activity that can do the work will be started. If there is no recipient, it will require the Download Manager to download data. Put the data under the control of a content provider so that a potentially larger activity pool (those with only named data types) can respond.

Most applications start to refresh without referencing any special data. All the activities that can start the application initially contain "android. Intent. Action. Main" as the filter of the specified action. If they represent the starters in the application, they also need to specify the "android. Intent. Category. launcher" category:

<Intent-filter...>
<Action Android: Name = "code Android. Intent. Action. Main"/>
<Category Android: Name = "code Android. Intent. Category. launcher"/>
</Intent-filter>

Match with intent object

Intent object matching with the filter is not only to find the target component to be activated, but also to find some things about the component set on the device. For example, the android System Searches for all. intent. action. main and Android. intent. category. launcher "categories of filter activity, fill them into the app launcher, and display the effective app launched by the user on the top of the screen, then, the icons and labels of the activity in the initiator are displayed. Similarly, the system finds the main screen through the activity with "android. Intent. Category. Home" in its filter.

Applications can be used for intent objects to match similar methods in groups. In the packagemanager class, there is a set of queries... () Method, they return all the components that can accept a special intent object, and there is a set of similar resolve... () Method, used to determine the best component to respond to an intent object. For example, the queryintentactivities () method returns an activity that can execute the action required by the intent object. The queryintentservices () method returns the service list similarly. These methods do not activate components. They only list all components that can respond to this intent object. For Broadcast
Receiver has a similar method: querybroadcastreceivers ().