Target selection and brokering

When a client app queries the invocation framework for a suitable target or when it sends an unbound invocation request, the invocation framework determines the set of suitable targets by comparing the invocation request to all of the installed target filters defined for the apps on the BlackBerry device. This process is called invocation brokering. Brokering uses a set of rules to determine how to match the invocation request to each filter. Specifically, a filter is considered a match only if both the action rules and the data rules are satisfied.

Rules for matching actions

A target filter is considered an action match in either of these two cases:

  • The action specified in the invocation request matches one of the actions that are specified in the target filter.
  • If the invocation request does not specify an action, all filters are considered to be an action match.

If the target filter does not contain declaration of any actions, then it doesn't match any invocation requests.

Rules for matching data

The URI and MIME type are considered when the invocation data is matched. URI matching involves comparing of the uris and exts attributes of the target filter with the uri attribute of the invocation request.

The composition of a URI looks like this: <scheme>://<host>:<port>/<path> = <scheme>://<authority>/<path> , where host and port values are equal to the authority value. The scheme comparison is non case-sensitive while the authority and path sections are case-sensitive. These values are compared in such a way that the uri is considered a match only if any of the values specified in the target filter’s uris attribute is a prefix of the uri specified in the invocation request.

Likewise, if the target filter specifies exts values, then that app is considered a match only if one of the exts values is the suffix of the uri path that is provided in the invocation request.

The invocation framework adds a dot separator between the specified exts value and the rest of the path automatically when it performs the comparison.

A MIME type comparison is performed between the MIME type provided in the invocation request and the MIME type that is provided in the target filter. Both the invocation request and the target filter may use a wildcard character (*) in the subtype of the MIME type. Here are some factors that determine whether a target filter is considered a MIME type match:

  • The URI and MIME type specified in the invocation request match with the target filter's uri and ext.
  • The wildcard character (*) is considered and is used for MIME type matching.
  • If the MIME type is specified then the type is not inferred from the uri.
  • The absence of a declared ext in the target filter implies an ext match.
  • The absence of the uri in either the invocation request or the target filter implies that the data attribute is data://local.
  • If the invocation request does not specify a MIME type and a target filter declaration has matching URIs and file extensions, then the invocation framework considers that target filter for a MIME type match.
  • If the invocation request does not specify a uri while the target filter declared a matching MIME type but either did not declare a uri, which implies that the data attribute is data://local, or explicitly declared the uri as uri=data://local, then the target filter is considered a MIME type match.

Unbound selection

When an unbound invocation has multiple targets that are suitable, the invocation framework chooses a best fit target to invoke by using the brokering rules. Here are the rules that the selection process follows:

  • The filter that has the strongest URI match based on its length is selected.
  • When target filters are compared, only the scheme attribute is used for the URIs that are declared in the bar-descriptor.xml file.
  • If more than one target filter has the longest matching URI, then the target filter with the strongest MIME type match is selected. The type with the wildcard character (*) is considered the weakest match, the subtype with the wildcard character type/* is considered weak, while a match without wildcard characters is considered the strongest match.
  • If more than one target filter has the strongest MIME type match, then the target filter with an exts match is selected if the uri attribute is defined in  file://scheme format.
  • If more than one target filter has a matching ext, then the filter that the system marks as default for that set of target filter criteria is selected.
  • If no target filter is identified as default, then the oldest target filter is selected as the best possible match.

Last modified: 2014-09-30



Got questions about leaving a comment? Get answers from our Disqus FAQ.

comments powered by Disqus