关于openharmony:OpenHarmony-31-Beta版本关键特性解析探秘隐式查询

13次阅读

共计 4435 个字符,预计需要花费 12 分钟才能阅读完成。

本文作者:徐浩

隐式查问是 OpenAtom OpenHarmony(以下简称“OpenHarmony”)的一个根底能力,被广泛应用于各种利用中(如视频播放、阅读器播放等)。利用通过隐式查问能够借助其余利用提供的能力,从而缩小开发者工作量,同时给用户带来更好的体验。那么隐式查问是什么?隐式查问是如何实现的?等等一连串疑难想必是开发者们最关怀的问题,本期将对这些问题进行具体的解答。

什么是隐式查问?

当一个利用执行某操作时,如果利用本人不具备此操作须要的能力,则会触发零碎的隐式查问性能。零碎去查找其余具备此项能力的利用,并通过利用选择器展现给用户,让用户抉择应用哪个利用来实现操作。

为了帮忙大家了解,咱们来举个例子:

在微信中关上 pdf 文件时,如果没有设置默认的 pdf 文件阅读器,那么零碎会通过隐式查问查找所有具备 pdf 浏览能力的利用,并通过利用选择器将其展现给用户进行抉择。

隐式查问代码解析

从下面隐式查问的定义,咱们理解到:

  1. 查问方利用须要执行要执行的操作。
  2. 其余利用须要申明本人具备的能力。

上面咱们联合示例,看看具体的代码实现吧。

第一步:在查问方利用的 Ability 中通过 want 信息指定要执行的操作。

want 信息示例代码如下:

"want"{  
     "action":"action.system.play",  
     "entities":["entity.system.video", "entity.system.camera"],  
     "uri" :"https://www.test.com:8080/query/student/name",  
     "type":"text/plain"  
 }

当利用调用 startAbility 接口启动 Ability 时,通过 want 信息中的 action、entities、uri 和 type 属性指定要执行的操作。

第二步:在其余利用的配置文件 config.json 中通过 skills 参数申明具备的能力。

skills 信息示例代码如下:

"skills": [  
   {"actions": ["action.system.play"],  
     "entities": ["entity.system.video", "entity.system.camera"],  
     "uris": [  
       {  
         "scheme": "https",  
         "host": "www.test.com",  
         "port": "8080",  
         "path": "query/student/name",  
          "pathStartWith":"query/student",  
         "pathRegex":"query/.*/name", 
         "type": "text/plain"  
       }  
     ]  
   }  
 ]

实现下面两步,零碎就能够进行隐式查问了。零碎依照隐式查问规定,将其余利用的 skills 信息与查问方利用的 want 信息进行匹配,而后将匹配胜利的利用通过利用选择器展现给用户进行抉择。

上面咱们为大家具体解说隐式查问的匹配规定。

隐式查问匹配规定详解

零碎将其余利用的 skills 信息(蕴含 actions、entities 和 uris 属性)与查问方利用的 want 信息(蕴含 action、entities、uri 和 type 属性)进行匹配,具体匹配规定如下:

  1. action 匹配规定

将其余利用 skills 信息中的 actions 与查问方利用 want 信息中的 action 进行匹配。

• 如果 skills 信息中的 actions 为空,匹配不通过。

• 如果 skills 信息中的 actions 不为空,且其蕴含 want 信息中的 action(能够为空),匹配通过。否则匹配不通过。

  1. entities 匹配规定

将其余利用 skills 信息中的 entities 与查问方利用 want 信息中的 entities 进行匹配。

• 如果 skills 信息中的 entities 为空,则只有当 want 信息中的 entities 为空时才匹配通过。否则匹配不通过。

• 如果 skills 信息中的 entities 不为空,且其蕴含 want 信息中的 entities(能够为空),匹配通过。否则匹配不通过。

  1. uri 匹配规定

将其余利用 skills 信息的 uris 中的 scheme、host、port、path、pathStartWith 和 pathRegex 属性拼接成 uri(scheme://host:port/(path;pathStartWith;pathRegex)),将此 uri 与查问方利用 want 信息中的 uri 进行匹配。其中,path 为残缺门路匹配,pathStartWith 为前缀匹配,pathRegx 为正则匹配。

skills 信息的 uris 中的 type 与 want 信息中的 type 进行匹配,反对 * 通配符匹配。

• 如果 skills 信息拼接的 uri 为空,则只有当 want 信息中的 uri 为空时才匹配通过。否则匹配不通过。

• 如果 skills 信息拼接的 uri 不为空,且其蕴含 want 信息中的 uri(不能够为空),uri 匹配通过。否则匹配不通过。

  1. type 匹配规定

将其余利用 skills 信息的 uris 中的 type 与查问方利用 want 信息中的 type 进行匹配,反对 * 通配符匹配。

• 如果 skills 信息中的 type 为空,则只有当 want 信息中的 type 为空时才匹配通过。否则匹配不通过。

• 如果 skills 信息中的 type 不为空,且其蕴含 want 信息中的 type(不能够为空),匹配通过。否则匹配不通过。

当利用的以上四个属性都匹配通过,此利用才会被利用选择器展现给用户进行抉择。

典型隐式查问匹配示例

为了让大家更好地了解,上面咱们看看几个典型的匹配示例:

示例 1:
查问方利用的 want 信息示例代码:

featureAbility.startAbility({  
   "want": {"action": "action.system.play"}, }).then((data) => {})

其余利用的 skills 信息示例代码:


  "skills": [    
    {"actions": ["action.system.play"]    
    }    
  ] 

• skills 信息中的 actions 不为空,且其蕴含 want 信息中的 action,action 匹配通过。
• skills 信息中的 entities 为空,want 信息中的 entities 也为空,entities 匹配通过。同理,uri 和 type 也匹配通过。
此示例,四个属性均匹配胜利,则此利用匹配胜利,会被利用选择器展现给用户进行抉择。

示例二:
查问方利用的 want 信息示例代码:

featureAbility.startAbility({  
   "want": {"type": "prefixType/suffixType",}, }).then((data) => {}) 

其余利用的 skills 信息示例代码:


  "skills": [  
    {"actions": ["action.system.play"],
      "uris": [  
        {"type": "prefixType/suffixType"}  
      ]  
    }  
  ]

• skills 信息中的 actions 不为空,want 信息中的 action 为空,action 匹配通过。
• skills 信息中的 entities 为空,want 信息中的 entities 也为空,entities 匹配通过。同理,uri 也匹配通过。
• skills 信息中的 type 不为空,且其蕴含 want 信息中的 type,type 匹配通过。
此示例,四个属性均匹配胜利,则此利用匹配胜利,会被利用选择器展现给用户进行抉择。

示例三:
查问方利用的 want 信息示例代码:

featureAbility.startAbility({  
  "want": {  
    "type": "text/plain",  
    "uri": "https://www.test.com:8080/query/student"  
  }, }).then((data) => {})  

其余利用的 skills 信息示例代码:

"skills": [  
   {"actions": ["action.system.play"],
     "uris": [  
       {  
         "scheme": "https",  
         "host": "www.test.com",  
         "port": "8080",  
         "path": "query/student",  
         "type": "text/*"  
       }  
     ]  
   }  

• skills 信息中的 actions 不为空,want 信息中的 action 为空,action 匹配通过。
• skills 信息中的 entities 为空,want 信息中的 entities 也为空,entities 匹配通过。
• skills 信息的 uris 中 scheme、host、port 和 path 属性拼接出 uri 为 https://www.test.com:8080/que…,与 want 信息中的 uri 统一,uri 匹配通过。
• skills 信息中的 type 为 text/ 示意通配),want 信息中的 type 为 text/plain,type 匹配通过。
此示例,四个属性均匹配胜利,则此利用匹配胜利,会被利用选择器展现给用户进行抉择。

示例四:
查问方利用的 want 信息示例代码:

featureAbility.startAbility({  
  "want": {  
    "action": "action.system.play",  
    "entities":["entity.system.video"],  
    "type": "text/plain",  
    "uri": "https://www.test.com/query/student"  
  }, }).then((data) => {}) 

其余利用的 skills 信息示例代码:

"skills": [  
   {"actions": ["action.system.play"],  
     "entities": ["entity.system.video"],  
     "uris": [  
       {  
         "scheme": "https",  
         "host": "www.test.com",  
         "pathStartWith": "query",  
         "type": "text/plain"  
       }  
     ]  
   }  
 ]

• skills 信息中的 actions 不为空,want 信息中的 action 为空,action 匹配通过。
• skills 信息中的 entities 为空,want 信息中的 entities 也为空,entities 匹配通过。
• skills 信息的 uris 中 scheme、host、port 和 path 属性拼接出 uri 为 https://www.test.com:8080/que…,与 want 信息中的 uri 统一,uri 匹配通过。
• skills 信息中的 type 为 text/ 示意通配),want 信息中的 type 为 text/plain,type 匹配通过。
此示例,四个属性均匹配胜利,则此利用匹配胜利,会被利用选择器展现给用户进行抉择。
通过以上示例,置信大家曾经分明隐式查问匹配规定了。
全文介绍了隐式查问是什么,并对隐式查问的相干代码和匹配规定进行了深刻分析。隐式查问,你都 get 到了吗?心愿开发者们能够将隐式查问利用于更多的场景和畛域中。

正文完
 0