摘要:前言当一切就绪后,就要开始进行规划,这一块是整个框架中非常重要的内容,毕竟对于前端页面来说,只会通过来调用功能。基本上,调用起来是否方便简洁影响着整个体验。那么权限认证应该是怎样的呢根据不同需求,可以划分一个等级。
前言
当一切就绪后,就要开始进行API规划,这一块是整个Hybrid框架中非常重要的内容,毕竟对于前端页面来说,只会通过JS API来调用功能。
基本上,API调用起来是否方便简洁影响着整个体验。
这里将内容细分为以下几点:
API约束(包括调用格式,传参格式,回调格式)
功能规划(约定这个框架应该提供什么样的功能)
权限校验(很重要的一块,校验后才能调用,包括权限校验的代码格式,校验一些什么内容,以及哪些API无需校验)
模块化的API(按照模块划分,每一个模块可以作为多带带的组件,便于拓展)
其它优化(如在PC端调试API的页面,部分API支持Promise等)
API约束API调用关乎着整个体验,我们约定所有API统一采用如下调用方式
quick.模块名.方法({ 参数1: "", 参数2: "", success: fucntion(result) { // 成功回调 }, error: fucntion(error) { // 失败回调 } });
约束说明
所有接口都为异步调用
接收一个object类型的参数
成功回调success
通过result获取成功数据
回调函数的触发时机由具体的API决定,有的API是调用时即可回调(短期),有的是某个事件触发后才被回调(长期)
失败回调error,所有的API调用错误都会走失败回调
功能规划混合开发框架最重要的一个功能就是__将原生功能以JS API形式提供给前端页面调用__
本框架的API规划如下:(这个项目中仅规划了部分功能,实际使用中自行拓展即可)
quick |- ui // 系统ui组件 | |- toast | |- alert | |- confirm | |- prompt | |- showWaiting | |- closeWaiting | |- actionSheet | |- pickDate | |- pickTime | |- pickDateTime | |- popWindow |- page // 页面(webview)管理 | |- open | |- openLocal | |- close | |- reload |- navigator // 导航栏控制 | |- setTitle | |- setMultiTitle | |- hookSysBack | |- hookBackBtn | |- setRightBtn | |- setLeftBtn | |- setRightMenu |- auth // 权限认证相关 | |- getToken |- device // 设备相关 | |- setOrientation | |- getDeviceId | |- getNetWorkInfo | |- getVendorInfo | |- closeInputKeyboard | |- vibrate | |- callPhone | |- sendMsg |- runtime // 运行环境 | |- launchApp | |- getAppVersion | |- getQuickVersion | |- getGeolocation | |- clearCache | |- clipboard | |- openUrl |- util // 其它工具 | |- scan | |- selectImage | |- cameraImage | |- selectFile | |- openFile
上述规划的是最常用到的功能,具体每一个API的介绍,传入参数传出参数等会在框架的API文档中提到
权限校验如果整套框架要对外开放(如允许第三方按规范接入),那么权限认证是必不可少的!
如果没有权限认证?可以想象下,随便一个页面就能调用任意API,获取敏感信息。。。
那么权限认证应该是怎样的呢?根据不同需求,可以划分一个等级。
平台级别的(像钉钉、微信这类对外开放的),需要配合后台,有完整的授权,签名,校验机制
项目级别的(N个项目同一个框架,但业务各不相同),简单的应用内部配置,直接校验一些域名白名单信息即可
当然了,这个框架是后面的项目级别的,大批量的项目都采用的,因此直接简单配置即可(示例中是在原生预留了这个入口,但没有实现)
这里暂不谈具体实现(实现可参考源码),只说说权限认证的流程:(如钉钉、微信中的)
quick.error(function(error) { // 处理错误 }); quick.config({ ... }); quick.ready(function() { // TODO: 处理验证成功后的事情,例如调用api });
可以看到,和其它框架一样,前端也是config,ready,error三步,
然后原生接收到config时,内部进行校验(校验内容可以是检测页面地址是否符合域名白名单等等...)
而且,如果config失败或者没有校验,那么敏感API都无法调用
无需校验就可用的API
并不是所有API都需校验后才能用,我们约定以下API默认就可用(这里是一个粗糙的划分,实际上可以精确到每一个API)
ui模块的所有API page模块的所有API navigator模块的所有API
这样做的好处是,如果不涉及到一些敏感数据,可以无需校验,提供效率(校验如果规则毕竟重的话对速度还是有影响的)
模块化的API有一个全局变量quick,但API并不是直接绑定在全局变量下,而是按模块划分,譬如
quick.ui quick.device quick.page ...
这里说明一下,用模块化划分,除了前端调用会更清晰外,原生进行API定义与组件API拓展时也更方便。
组件API的拓展机制
关于组件API的拓展机制,这里也不具体描述如何实现(实现可参考源码),仅说说大概是一个什么样的东西。
默认情况下,框架会注册以下组件(前面已经规划的所有模块)
ui page navigator auth device runtime util
但是假设某项目中突然遇到了一个需求,要新增一个支付功能,并且要以API的形式提供给H5页面调用,该如何实现呢?
注意,这个框架设计的初衷是可以供N个项目使用,所以不可能所有的功能都集成进入框架中的,各个项目可以拓展自己的组件
这时候就需要规划这个拓展机制了,如下
// 1.前端config时,传入需要注册的组件别名 quick.config({ jsApiList: ["pay", "speech"] });
// 2.原生框架中,接收到config后,基于传入的别名,去对应项目配置文件中查询路径,然后将对应路径的API实现类注册 // 对应的组件的API实现类不是放框架中的,而是由各自的项目管理的,到时候框架就是一个固定的库,给各个项目引用 // 代码实现这里省略 ...
// 3.前端中,通过一个固定的方法,调用刚注册的组件API中的功能 quick.callApi({ name: "xxx", mudule: "pay", ... data: {}, success: function(result) {}, error: function(error) {}, });
通过这一套机制,可以保持框架的可拓展性,就算应用不同的项目中,N多的功能,也能通过这种方法拓展,保持一致的使用
其它优化在大体功能都实现后,接下来还需要做一些优化功能,具体效果可以是简化调用,也可以是方便调试
部分API支持Promise
前面定义的API中都是基于普通的回调进行的,在多层回调嵌套时仍然会毕竟麻烦,因此可以拓展支持Promise调用方式
在拓展前,先定一个基调:__所有短期回调都支持Promise调用,长期回调不建议使用Promise__
因为长期回调涉及到多次回调(比如右上角按钮),所以不建议使用Promise,如果强行要使用,这些API调用完毕后马上就会进入then
具体实现参考源码,这里稍微对比下普通调用与Promise调用
quick.ui.alert({ title: "提示", message: "sd#ffffd测试", success: function(result) { console.log("点击alert成功"); }, error: function(error) { console.error("失败:" + JSON.stringify(error)); } });
quick.ui.alert({ title: "提示", message: "sd#ffffd测试", }).then(function(result) { console.log("点击alert成功"); }).catch(function(error) { console.error("失败:" + JSON.stringify(error)); });
上述还只是没有嵌套的对比情况,有嵌套时,区别更大
PC端调试API
类似于钉钉的调试页面,这里也规划了一个在PC端调试API的页面(基于websocket),后续会有更详细的说明。
原理方面的源码可以先参考https://github.com/dailc/node-server-examples/tree/master/node-socketio-hybriddebug
可以先预览下效果
其它
其它优化后续再介绍
返回根目录【quickhybrid】如何实现一个Hybrid框架
源码github上这个框架的实现
quickhybrid/quickhybrid
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/14174.html
摘要:前言当一切就绪后,就要开始进行规划,这一块是整个框架中非常重要的内容,毕竟对于前端页面来说,只会通过来调用功能。基本上,调用起来是否方便简洁影响着整个体验。那么权限认证应该是怎样的呢根据不同需求,可以划分一个等级。 前言 当一切就绪后,就要开始进行API规划,这一块是整个Hybrid框架中非常重要的内容,毕竟对于前端页面来说,只会通过JS API来调用功能。基本上,API调用起来是否方...
摘要:前言虽然说本系列中架构篇是第一章,但实际过程中是在慢慢演化的第二版中才有这个概念,经过不断的迭代,演化才逐步稳定明确目标首先明确需要做成一个什么样的框架大致就是一套规范统一与,所有异步调用防止阻塞提供大部分原生功能的包括很多常用的功能给使用 前言 虽然说本系列中架构篇是第一章,但实际过程中是在慢慢演化的第二版中才有这个概念,经过不断的迭代,演化才逐步稳定 明确目标 首先明确需要做成一个...
摘要:前言虽然说本系列中架构篇是第一章,但实际过程中是在慢慢演化的第二版中才有这个概念,经过不断的迭代,演化才逐步稳定明确目标首先明确需要做成一个什么样的框架大致就是一套规范统一与,所有异步调用防止阻塞提供大部分原生功能的包括很多常用的功能给使用 前言 虽然说本系列中架构篇是第一章,但实际过程中是在慢慢演化的第二版中才有这个概念,经过不断的迭代,演化才逐步稳定 明确目标 首先明确需要做成一个...
摘要:前言一切就绪,开始规划,这里在规划前对进行了一次分类短期长期首先申明下,这个是在实际框架演变过程中自创的一个概念,其它混合框架可能也会有这个概念,但应该是会在原生底层来实现,而不是前端实现。。 前言 一切就绪,开始规划API,这里在规划前对API进行了一次分类:__短期API、长期API__ 首先申明下,这个是在实际框架演变过程中自创的一个概念,其它混合框架可能也会有这个概念,但应该是...
摘要:前言一切就绪,开始规划,这里在规划前对进行了一次分类短期长期首先申明下,这个是在实际框架演变过程中自创的一个概念,其它混合框架可能也会有这个概念,但应该是会在原生底层来实现,而不是前端实现。。 前言 一切就绪,开始规划API,这里在规划前对API进行了一次分类:__短期API、长期API__ 首先申明下,这个是在实际框架演变过程中自创的一个概念,其它混合框架可能也会有这个概念,但应该是...
阅读 1584·2021-11-24 09:39
阅读 2175·2021-10-14 09:43
阅读 3177·2021-10-08 10:10
阅读 1864·2021-09-22 15:54
阅读 3354·2021-09-07 09:58
阅读 2229·2019-08-29 17:20
阅读 1467·2019-08-28 18:14
阅读 2268·2019-08-26 13:28