【quickhybrid】组件（自定义）API的实现

前言

前文在API规划时就已经有提到过组件API这个概念，本文将会介绍它的原理以及实现

理解组件API这个概念

quick.ui.xxx
quick.page.xxx

在quick hybrid中，API是按模块划分的，如ui，page等都是不一样模块，而模块的另外一个名称则是组件

为何叫组件？能够这样理解，模块更多的是H5前端的叫法（由于在前端看来不一样API分别属于不一样的模块下），
而组件则是原生那边增强的理解概念（由于，每个组件都是能够在项目中单独存在的，譬如项目A中有组件pay，但项目B却不必定集成有）

框架API和组件API

回到最初，quick hybrid的使命就是服务于N个项目，那么会遇到一个问题-N个项目中可能会有很是多的须要以API方式提供的需求，可是考虑到体积以及通用性，并非全部的都适合直接集成到框架中

此时，就须要对框架内容和项目内容进行区分，因而就有了框架API和组件API的概念（此时能够认为原生中框架文件是单独打成一个静态包给项目引用的，项目没法直接修改）

框架API

• 直接打包到框架文件中（前端的quick.native.js，原生框架包中的API都会包含）

• 使用的时候直接quick.xx模块.xx功能便可调用（由于前端会将框架API都默认封装）

• config配置时无需单独注册（由于默认状况会注册好）

• 部分框架API会有H5下的实现（如部分系统级API都是有H5下的实现的）

组件API

• 框架中不会包含，由各自的项目自行开发或集成（如某项目单独集成一个个性化语音组件）

• 使用的时候必须用quick.callAPi(...)并传入合适参数（由于框架不会集成，须要经过这个万金油方法调用）

• config配置时必须注册（须要传入组件别名注册，由于框架内部不知道这些新组件的）

• 全部组件API都只是quick环境下的实现（通常都是一些原生中集成的拓展功能）

项目中如何拓展组件API

项目中默认只会打包框架API，可是框架的功能是有限的（只会集成一些最经常使用的功能），若是遇到一些个性化的需求（如支付，语音等等），则须要项目拓展组件API，整体步骤以下：

• 1.原生引入框架，并实现对应的API接口，编写API的功能代码

• 2.原生在项目配置文件中（不是框架配置文件）声明对应的别名和路径关系

• 3.H5页面初始化时，config，并传入对应须要注册的组件的别名

• 4.容器接收到config方法后，去配置文件中根据别名找路径，而后注册对应路径下的API类

• 5.注册成功后，H5页面中经过callAPi来调用新注册的组件API

原生实现API接口

原生中API的定义以下（以pay组件为示例）

Android中

public class PayApi implements IBridgeImpl {

     public static void payCustom(..., JSONObject param, final Callback callback) {
        // 作对应的支付工做，作完后回调
        ...
        callback.apply(...);
    }
}

iOS中

@implementation PayApi
- (void)registerHandlers {
    [self registerHandlerName:@"payCustom" handler:^(id data, WVJBResponseCallback responseCallback) {
        // 作对应的支付工做，作完后回调
        ...
        responseCallback(...);
    }];
}

声明别名与路径的关系

须要注意的是，Android和iOS中别名请保持一致，通常状况下键值对也可

譬如以示例项目为例，

Android在app模块下的assets/modules.properties中

pay = com.quick.quickhybrid.api.PayApi
...

同理iOS中也相似，只不过右侧的路径值能够换为iOS中的，如

pay = PayApi

能够看到，Android和iOS中的别名名称相同，可是路径不一致（由于各类的包机制不同）

H5中config注册

H5中须要在config注册拓展的组件，须要传入别名（别名有对应的文档说明-通常状况下同类型组件的别名是固定的）

quick.config({
   jsApiList: ['pay']
});

// error表明发生错误
quick.error(...);

// ready中是注册成功
quick.ready(...);

原生容器注册组件API

原生容器接收到config请求后就开始注册组件，以下

// RegisterName: ui,page,pay之类的组件（模块）名
// RegisterNclass: 对应的路径，Android中和iOS中不一致

// RegisterNclass: 如com.quick.quickhybrid.api.PayApi
JSBridge.register(RegisterName, RegisterNclass);

// RegisterNclass: 如PayApi
[self registerHandlersWithClassName:@"RegisterNclass" moduleName:@"RegisterName"];

H5中调用组件API

注册成功后，H5中经过特定方法调用

quick.callApi({
    name: 'testPay',
    mudule: 'pay',
    // 额外参数常常都须要
    data: {...},
    success: function(result) {
        quick.ui.toast(JSON.stringify(result));
    },
    error: function(error) {},
});

结束语

实际状况下，当项目足够多时，拓展组件API是一种很是常见的场景，所以制定规范是颇有必要的。

另外，通常状况下，不少相同功能的组件都是能够一块儿积累，多个项目复用的（好比支付，特定业务组件等等）

返回根目录

• 【quickhybrid】如何实现一个Hybrid框架

源码

github上这个框架的实现

quickhybrid/quickhybrid