【鸿蒙开发】第二十九章 Stage模型-信息传递载体Want

目录

1 Want的概述

2 Want的类型

3 显式Want与隐式Want匹配规则

3.1显式Want匹配原理

3.2 隐式Want匹配原理

want参数的action匹配规则

want参数的entities匹配规则

want参数的uri和type匹配规则

uri匹配规则

type匹配规则

linkFeature匹配规则

4 使用显式Want启动应用组件


1 Want的概述

Want是一种对象,用于在应用组件之间传递信息

其中,一种常见的使用场景是作为startAbility()方法的参数。例如,当UIAbilityA需要启动UIAbilityB并向UIAbilityB传递一些数据时,可以使用Want作为一个载体,将数据传递给UIAbilityB。

图1 Want用法示意

2 Want的类型

  • 显式Want:在启动目标应用组件时,调用方传入的want参数中指定了abilityNamebundleName,称为显式Want。

    显式Want通常用于应用内组件启动,通过在Want对象内指定本应用Bundle名称信息(bundleName)和abilityName来启动应用内目标组件。当有明确处理请求的对象时,显式Want是一种简单有效的启动目标应用组件的方式。

import { Want } from '@kit.AbilityKit';

let wantInfo: Want = {
  deviceId: '', // deviceId为空表示本设备
  bundleName: 'com.example.myapplication',
  abilityName: 'FuncAbility',
}
  • 隐式Want:在启动目标应用组件时,调用方传入的want参数中未指定abilityName,称为隐式Want。

当需要处理的对象不明确时,可以使用隐式Want,在当前应用中使用其他应用提供的某个能力,而不关心提供该能力的具体应用。隐式Want使用skills标签来定义需要使用的能力,并由系统匹配声明支持该请求的所有应用来处理请求。例如,需要打开一个链接的请求,系统将匹配所有声明支持该请求的应用,然后让用户选择使用哪个应用打开链接。

import { Want } from '@kit.AbilityKit';

let wantInfo: Want = {
  // uncomment line below if wish to implicitly query only in the specific bundle.
  // bundleName: 'com.example.myapplication',
  action: 'ohos.want.action.search',
  // entities can be omitted
  entities: [ 'entity.system.browsable' ],
  uri: 'https://www.test.com:8080/query/student',
  type: 'text/plain',
};

说明

  • 根据系统中待匹配应用组件的匹配情况不同,使用隐式Want启动应用组件时会出现以下三种情况。

    • 未匹配到满足条件的应用组件:启动失败。
    • 匹配到一个满足条件的应用组件:直接启动该应用组件。
    • 匹配到多个满足条件的应用组件(UIAbility​​​​​​​):弹出选择框让用户选择。
  • 对于启动ServiceExtensionAbility的场景

    • 调用方传入的want参数中带有abilityName,则不允许通过隐式Want启动ServiceExtensionAbility。
    • 调用方传入的want参数中带有bundleName,则允许使用startServiceExtensionAbility()方法隐式Want启动ServiceExtensionAbility,默认返回优先级最高的ServiceExtensionAbility,如果优先级相同,返回第一个。

3 显式Want与隐式Want匹配规则

3.1显式Want匹配原理

显式Want匹配原理如下表所示。

名称类型匹配项必选规则
deviceIdstring留空将仅匹配本设备内的应用组件。
bundleNamestring如果指定abilityName,而不指定bundleName,则匹配失败。
moduleNamestring留空时当同一个应用内存在多个模块且模块间存在重名应用组件,将默认匹配第一个。
abilityNamestring该字段必须设置表示显式匹配。
uristring系统匹配时将忽略该参数,但仍可作为参数传递给目标应用组件。
typestring系统匹配时将忽略该参数,但仍可作为参数传递给目标应用组件。
actionstring系统匹配时将忽略该参数,但仍可作为参数传递给目标应用组件。
entitiesArray<string>系统匹配时将忽略该参数,但仍可作为参数传递给目标应用组件。
flagsnumber不参与匹配,直接传递给系统处理,一般用来设置运行态信息,例如URI数据授权等。
parameters{[key: string]: Object}不参与匹配,应用自定义数据将直接传递给目标应用组件。

3.2 隐式Want匹配原理

隐式Want匹配原理如下表所示。

名称类型匹配项必选规则
deviceIdstring跨设备目前不支持隐式调用。
abilityNamestring该字段必须留空表示隐式匹配。
bundleNamestring匹配对应应用包内的目标应用组件。
moduleNamestring匹配对应Module内的目标应用组件。
uristring参见want参数的uri和type匹配规则
typestring参见want参数的uri和type匹配规则
actionstring参见want参数的action匹配规则
entitiesArray<string>参见want参数的entities匹配规则
flagsnumber不参与匹配,直接传递给系统处理,一般用来设置运行态信息,例如URI数据授权等。
parameters{[key: string]: Object}应用自定义数据将直接传递给目标应用组件。当前支持使用key为linkFeature的参数进行匹配,当linkFeature字段取值不为空时,优先进行linkFeature匹配。

从隐式Want的定义,可得知:

  • 调用方传入的want参数,表明调用方需要执行的操作,并提供相关数据以及其他应用类型限制。
  • 待匹配应用组件的skills配置,声明其具备的能力(module.json5配置文件中的skills标签参数)。

系统将调用方传入的want参数(包含action、entities、uri、type和parameters属性)与已安装待匹配应用组件的skills配置(包含actions、entities、uris和type属性)进行匹配。当want参数五个属性匹配均未配置,隐式匹配失败。

  • 当parameters中的linkFeature字段取值不为空时,系统将优先进行linkFeature匹配。
    • 如果linkFeature匹配成功,并且want中配置了uri或type,则继续匹配uri和type属性,均匹配成功则隐式匹配成功;否则,匹配失败。如果want中未配置uri和type, 则隐式匹配成功。
    • 如果linkFeature匹配失败,则不进行后续属性匹配,匹配失败。
  • 当parameters中的linkFeature未配置或取值为空时,只有当action、entities、uri和type四个属性均匹配通过时,此应用才会被应用选择器展示给用户进行选择。

want参数的action匹配规则

将调用方传入的want参数的action与待匹配应用组件的skills配置中的actions进行匹配。

  • 调用方传入的want参数的action为空,待匹配Ability的skills配置中的actions为空,则action匹配失败。
  • 调用方传入的want参数的action不为空,待匹配应用组件的skills配置中的actions为空,则action匹配失败。
  • 调用方传入的want参数的action为空,待匹配应用组件的skills配置中的actions不为空,则action匹配成功。
  • 调用方传入的want参数的action不为空,待匹配应用组件的skills配置中的actions不为空且包含调用方传入的want参数的action,则action匹配成功。
  • 调用方传入的want参数的action不为空,待匹配应用组件的skills配置中的actions不为空且不包含调用方传入的want参数的action,则action匹配失败。

图1 want参数的action匹配规则

want参数的entities匹配规则

将调用方传入的want参数的entities与待匹配应用组件的skills配置中的entities进行匹配。

  • 调用方传入的want参数的entities为空,待匹配应用组件的skills配置中的entities不为空,则entities匹配成功。
  • 调用方传入的want参数的entities为空,待匹配应用组件的skills配置中的entities为空,则entities匹配成功。
  • 调用方传入的want参数的entities不为空,待匹配应用组件的skills配置中的entities为空,则entities匹配失败。
  • 调用方传入的want参数的entities不为空,待匹配应用组件的skills配置中的entities不为空且包含调用方传入的want参数的entities,则entities匹配成功。
  • 调用方传入的want参数的entities不为空,待匹配应用组件的skills配置中的entities不为空且不完全包含调用方传入的want参数的entities,则entities匹配失败。

图2 want参数的entities匹配规则

want参数的uri和type匹配规则

调用方传入的want参数中设置uri和type参数发起启动应用组件的请求,系统会遍历当前系统已安装的组件列表,并逐个匹配待匹配应用组件的skills配置中的uris数组,如果待匹配应用组件的skills配置中的uris数组中只要有一个可以匹配调用方传入的want参数中设置的uri和type即为匹配成功。

实际应用中,uri和type共存在四种情况,下面将讲解四种情况的具体匹配规则

  • 调用方传入的want参数的uri和type都为空。

    1. 如果待匹配应用组件的skills配置中的uris数组为空,匹配成功。
    2. 如果待匹配应用组件的skills配置中的uris数组中存在uri的scheme和type都为空的元素,匹配成功。
    3. 除以上两种情况,其他情况均为匹配失败。
  • 调用方传入的want参数的uri不为空,type为空。

    1. 如果待匹配应用组件的skills配置中的uris数组为空,匹配失败。
    2. 如果待匹配应用组件的skills配置中的uris数组存在一条数据uri匹配成功且type为空,则匹配成功,否则匹配失败。
    3. 如果前两条均匹配失败,并且传入的uri为文件路径uri,则根据文件后缀获取文件的MIME类型,如果该类型与skills文件中配置的type相匹配,则匹配成功。
  • 调用方传入的want参数的uri为空,type不为空。

    1. 如果待匹配应用组件的skills配置中的uris数组为空,匹配失败。
    2. 如果待匹配应用组件的skills配置中的uris数组存在一条数据uri的scheme为空且type匹配成功,则匹配成功,否则匹配失败。
  • 调用方传入的want参数的uri和type都不为空,如下图所示。

    1. 如果待匹配应用组件的skills配置中的uris数组为空,匹配失败。
    2. 如果待匹配应用组件的skills配置中的uris数组存在一条数据uri匹配type匹配需要均匹配成功,则匹配成功,否则匹配失败。

最左uri匹配:当配置文件待匹配应用组件的skills配置中的uris数组中只配置scheme;或者只配置scheme和host;或者只配置scheme、host和port时。传入want参数的uri的最左边依次需要和scheme,或者scheme和host,或者scheme、host和port都匹配,才满足最左uri匹配。

图3 want参数中uri和type皆不为空时的匹配规则

为了简化描述:

  • 称调用方传入的want参数中的uri参数为w_uri;待匹配应用组件的skills配置中uris为s_uris,其中每个元素为s_uri。
  • 称调用方传入的want参数的type参数为w_type,待匹配应用组件的skills数组中uris的type数据为s_type。

图4 want参数中uri和type的具体匹配规则

uri匹配规则

具体的匹配规则如下:

  • 如果s_uri的scheme为空,当w_uri为空时匹配成功,否则匹配失败。

  • 如果s_uri的host为空,当w_uri和s_uri的scheme相同时匹配成功,否则匹配失败。

  • 如果s_uri的port为空,当w_uri和s_uri中的scheme和host相同时匹配成功,否则匹配失败。

  • 如果s_uri的path、pathStartWith和pathRegex都为空,当w_uri和s_uri中的scheme,host和port相同时匹配成功,否则匹配失败。

  • 如果s_uri的path不为空,当w_uri和s_uri全路径表达式相同时匹配成功,否则继续进行pathStartWith的匹配。

  • 如果s_uri的pathStartWith不为空,当w_uri包含s_uri前缀表达式时匹配成功,否则继续进行pathRegex的匹配。

  • 如果s_uri的pathRegex不为空,当w_uri满足s_uri正则表达式时匹配成功,否则匹配失败。

说明

待匹配应用组件的skills配置的uris中scheme、host、port、path、pathStartWith和pathRegex属性拼接,如果依次声明了path、pathStartWith和pathRegex属性时,uris将分别拼接为如下四种表达式:

  • 前缀uri表达式:当配置文件只配置scheme,或者只配置scheme和host,或者只配置scheme,host和port时,参数传入以配置文件为前缀的Uri
    • scheme://
    • scheme://host
    • scheme://host:port
  • 全路径表达式:scheme://host:port/path
  • 前缀表达式:scheme://host:port/pathStartWith
  • 正则表达式:scheme://host:port/pathRegex

系统应用预留uri的scheme统一以ohos开头,例如ohosclock://。三方应用组件配置的uri不能与系统应用重复,否则会导致无法通过该uri拉起三方应用组件。

图5 want参数中uri的匹配规则示例

type匹配规则

说明

本章节所述的type匹配规则的适用性需建立在want参数内type不为空的基础上。当want参数内type为空时请参见want参数的uri和type匹配规则

具体的匹配规则如下:

  • 如果s_type为空,则匹配失败。

  • 如果s_type或者w_type为通配符*/*,则匹配成功。

  • 如果s_type最后一个字符为通配符*,如prefixType/*,则当w_type包含prefixType/时匹配成功,否则匹配失败。

  • 如果w_type最后一个字符为通配符*,如prefixType/*,则当s_type包含prefixType/时匹配成功,否则匹配失败。

linkFeature匹配规则

说明

本章节所述的linkFeature匹配规则适用于want参数中的parameters包含linkFeature键,且对应取值不为空的场景。

将调用方传入的want参数的parameters与待匹配应用组件的skills配置中的uris进行匹配。为了简化描述, 称调用方传入的want参数中的linkFeature参数为w_linkFeature, 具体的匹配规则如下:

  • want参数的uri和type均为空, 只匹配linkFeature,当w_linkFeature和s_uri的linkFeature相同时匹配成功,否则匹配失败。
  • want参数的uri或type不为空, 依次匹配linkFeature、uri、type (参见want参数的uri和type匹配规则),当三个字段均匹配成功时,则匹配成功,否则匹配失败。

图6 want参数中linkFeature具体匹配规则

4 使用显式Want启动应用组件

在应用使用场景中,当用户在应用内点击某个按钮时,经常需要拉起指定UIAbility组件来完成某些特定任务。在启动UIAbility时,指定了abilityName和bundleName参数,可以使用显式Want方式启动UIAbility。

针对应用的特定任务,用户需要通过点击应用内的按钮来启动指定的UIAbility组件。在启动UIAbility时,需要提供abilityName和bundleName参数,并使用显式Want方式来启动。关于如何使用显式Want方式启动应用内的UIAbility,请参见启动应用内的UIAbility

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值