织梦网站安装视频教程,网站收录批量查询,网站服务器带宽多少合适,津南区网络推广公司文章大纲 引言一、Want概述二、Want的类型1、显式Want2、隐式Want3、隐式Want的匹配 三、隐式启动Want 源码概述1、有且仅有一个Ability匹配2、有多个Ability 匹配需要弹出选择对话框3、ImplicitStartProcessor::ImplicitStartAbility3.1、GenerateAbilityRequestByAction3.1.1… 文章大纲 引言一、Want概述二、Want的类型1、显式Want2、隐式Want3、隐式Want的匹配 三、隐式启动Want 源码概述1、有且仅有一个Ability匹配2、有多个Ability 匹配需要弹出选择对话框3、ImplicitStartProcessor::ImplicitStartAbility3.1、GenerateAbilityRequestByAction3.1.1、GetBundleManagerHelper 获取BMS对象3.1.2、GetBundleManagerHelper()-ImplicitQueryInfos3.1.3、ImplicitStartProcessor::FilterAbilityList 3.2、定义回调3.3、根据dialogAppInfos和deviceType的组合进行不同的分支处理 4、当有多个匹配结果时会先执行FilterAbilityList(有条件执行) 小结 引言
在Android 中Activity及其他四大组件之间是通过Intent来传递信息的在我们的鸿蒙操作系统中同样有自己组件的“Intent”今天我们介绍下鸿蒙中的“Intent”。 暂且对照着Android中的Intent 来理解。 一、Want概述
Want 是对象间信息传递的载体可以用于应用组件间的信息传递。其使用场景之一是作为startAbility()的参数包含了指定的启动目标以及启动时需携带的相关数据如bundleName和abilityName字段分别指明目标Ability所在应用的包名以及对应包内的Ability名称。当UIAbilityA启动UIAbilityB并需要传入一些数据给UIAbilityB时Want可以作为一个载体将数据传给UIAbilityB。
二、Want的类型
1、显式Want
在启动Ability时指定了abilityName和bundleName的Want称为显式Want。 当有明确处理请求的对象时通过提供目标Ability所在应用的包名信息bundleName并在Want内指定abilityName便可启动目标Ability。显式Want通常用于在当前应用开发中启动某个已知的Ability。
let wantInfo {deviceId: , // deviceId为空表示本设备bundleName: com.example.myapplication,abilityName: FuncAbility,
}2、隐式Want
当请求处理的对象不明确时希望在当前应用中使用其他应用提供的某个能力通过skills标签定义而不关心提供该能力的具体应用可以使用隐式Want。例如使用隐式Want描述需要打开一个链接的请求而不关心通过具体哪个应用打开系统将匹配声明支持该请求的所有应用。
3、隐式Want的匹配
根据系统中待匹配Ability的匹配情况不同使用隐式Want启动Ability时会出现以下三种情况。
未匹配到满足条件的Ability启动失败。匹配到一个满足条件的Ability直接启动该Ability。匹配到多个满足条件的AbilityUIAbility弹出选择框让用户选择。
匹配约束
调用方传入的want参数中不带有abilityName和bundleName则不允许通过隐式Want启动所有应用的ServiceExtensionAbility。调用方传入的want参数中带有bundleName则允许使用startServiceExtensionAbility()方法隐式Want启动ServiceExtensionAbility默认返回优先级最高的ServiceExtensionAbility如果优先级相同返回第一个。 let wantInfo: Want {deviceId: ,action: ohos.want.action.viewData,entities: [entity.system.videoPlayer],abilityName: ,uri: ,type: ,parameters: {}}通过上面表格可以除了bundleName和moduleName只有uri、type、action、entities 字段参与匹配换句话说提供相应能力的hap中的moudle.json5 里的skills 的这四个字段的值会影响到匹配结果。
三、隐式启动Want 源码概述 foundation/ability/ability_runtime/services/abilitymgr/src/implicit_start_processor.cpp 处理隐式匹配规则 foundation/ability/ability_runtime/services/abilitymgr/src/system_dialog_scheduler.cpp 弹出模态对话框 1、有且仅有一个Ability匹配 2、有多个Ability 匹配需要弹出选择对话框 3、ImplicitStartProcessor::ImplicitStartAbility
对应的代码由ImplicitStartProcessor::ImplicitStartAbility开始处理首先AbilityRequest的callType 0传入的DeviceType为tablet而社区默认是default。
3.1、GenerateAbilityRequestByAction
传入std::vector dialogAppInfos、deviceType 成功创建AbilityRequest对象
3.1.1、GetBundleManagerHelper 获取BMS对象
3.1.2、GetBundleManagerHelper()-ImplicitQueryInfos
3.1.3、ImplicitStartProcessor::FilterAbilityList
3.2、定义回调
auto startAbilityTask [imp shared_from_this(), request, userId, identity](const std::string bundle, const std::string abilityName) mutable {HILOG_INFO(implicit start ability call back.);IPCSkeleton::SetCallingIdentity(identity);AAFwk::Want targetWant request.want;targetWant.SetElementName(bundle, abilityName);auto callBack [imp, targetWant, request, userId]() - int32_t {return imp-ImplicitStartAbilityInner(targetWant, request, userId);};return imp-CallStartAbilityInner(userId, targetWant, callBack, request.callType);
};3.3、根据dialogAppInfos和deviceType的组合进行不同的分支处理 dialogAppInfos.size() 0 (deviceType STR_PHONE || deviceType STR_DEFAULT dialogAppInfos.size() 0 deviceType ! STR_PHONE deviceType ! STR_DEFAULT dialogAppInfos.size() 0 deviceType ! STR_PHONE deviceType ! STR_DEFAULT deviceType STR_PHONE || deviceType STR_DEFAULT DelayedSingleton::GetInstance()-GetSelectorDialogWant(dialogAppInfos, request.want, request.callerToken)
以上四种情况之外的
4、当有多个匹配结果时会先执行FilterAbilityList(有条件执行)
MatchTypeAndUriAddAbilityInfoToDialogInfos循环从extensionInfos中获取dialogAppInfo信息并存入dialogAppInfos
小结
弹出对话框的SelectorDialog_Service是一个ServiceExtensionAbility进程为com.ohos.amsdialog连接上Selector_Dialog_Service后会触发其onCreate-OnRequest函数执行createWindow时 private async createWindow(name: string, windowType: number, rect) {let deviceTypeInfo deviceInfo.deviceType;console.info(TAG, create window);try {win await window.create(globalThis.selectExtensionContext, name, windowType);if (windowType window.WindowType.TYPE_DIALOG) {await win.bindDialogTarget(globalThis.callerToken.value, () {win.destroyWindow();winNum--;if (winNum 0) {globalThis.selectExtensionContext.terminateSelf();}});}if (deviceTypeInfo ! default) {await win.hideNonSystemFloatingWindows(true);}await win.moveTo(rect.left, rect.top);await win.resetSize(rect.width, rect.height);if (globalThis.params.deviceType phone || globalThis.params.deviceType tablet) {await win.loadContent(pages/selectorPhoneDialog);} else {await win.loadContent(pages/selectorPcDialog);}await win.setBackgroundColor(#00000000);await win.show();} catch (e) {console.error(TAG, window create failed: JSON.stringify(e));}}然后去触发方舟编译器解包ams_system_dialog.hap执行 最终结论 1、win.hideNonSystemFloatingWindows(true); 的父类实现中默认报异常中断所以需要在子类中实现该函数。但是问题来了里面的细节如何实现呢社区中都是直接返回true 2、在不同的设备上弹出的匹配对话框的位置和尺寸大小还需要适配在 this.createWindow(‘SelectorDialog’ startId, windowType, navigationBarRect);
