mirror of
https://gitee.com/openharmony/napi_generator
synced 2024-11-23 16:30:17 +00:00
refactor document directory 4
Signed-off-by: gou-jingjing <goujingjing@kaihong.com>
This commit is contained in:
gou-jingjing
parent
de73672a8b
commit
705368315b
110
docs/guide/ADD_SERVICECODE_INSTRUCTION.md
Normal file
110
docs/guide/ADD_SERVICECODE_INSTRUCTION.md
Normal file
@ -0,0 +1,110 @@
|
||||
# 手动配置业务代码说明
|
||||
## 简介
|
||||
|
||||
工具生成框架代码时支持使用cfg.json文件配置业务代码，当用户自动配置业务代码无法达成目的时也可手动进行业务代码配置，本文主要介绍不使用配置文件cfg.json进行业务代码配置并生成框架代码的过程。
|
||||
|
||||
## 生成框架
|
||||
|
||||
### 可执行程序使用方法
|
||||
|
||||
#### Linux
|
||||
|
||||
1.将待转换的.d.ts文件、依赖文件basic.d.ts、napi_generator-linux放在同级目录下。此处新建generatorCode文件夹，用于存放生成框架代码。整体目录文件如下：
|
||||
|
||||
OpenHarmony@Ubuntu-64:~/service$ ls
|
||||
napi_generator-linux @ohos.napitest.d.ts basic.d.ts generatorCode
|
||||
|
||||
2.在终端中进入到之前可执行程序napi_generator-linux所在的目录，并运行napi_generator-linux，命令如下：
|
||||
|
||||
OpenHarmony@Ubuntu-64:~/service$ ./napi_generator-linux -f @ohos.napitest.d.ts -o generatorCode -i false -n int
|
||||
|
||||
其中，参数详情如下：
|
||||
|
||||
-f, 待转换的.d.ts文件，若同时转换多个文件，文件之间用“,”隔开；
|
||||
|
||||
-d, 根据指定路径转换该文件夹中所有.d.ts文件；
|
||||
|
||||
-i, 可选参数，默认false，待转换.d.ts文件中引用非basic.d.ts的ts文件时打开开关；
|
||||
|
||||
-o, 可选参数，默认为当前目录，指定生成框架代码输出路径；
|
||||
|
||||
-n, 可选参数，默认为uint32_t，指定生成框架代码中number类型全部为指定类型；
|
||||
|
||||
-s, 可选参数，默认为不配置业务代码，指定生成框架代码的业务配置文件，用于粘合工具代码和业务代码的配置。
|
||||
|
||||
备注1：-f与-d两个参数只选其中一个参数即可。
|
||||
|
||||
备注2：若.d.ts文件中声明了basic.d.ts文件，将basic.d.ts文件放置在待转换.d.ts文件同一级目录；若除此之外还声明其它.d.ts文件，将此类文件放置在待转换.d.ts文件同级目录。
|
||||
|
||||
3.运行成功后会在generatorCode目录下生成框架代码文件，如下所示：
|
||||
|
||||
OpenHarmony@Ubuntu-64:~/linshi/napi_generator_8/examples/ts/generatorCode$ ls
|
||||
binding.gyp BUILD.gn napi_gen.log napitest.cpp napitest.h napitest_middle.h napitest_middle.cpp test.sh tool_utility.cpp tool_utility.h
|
||||
|
||||
#### Windows
|
||||
|
||||
1.将待转换的.d.ts文件、依赖文件basic.d.ts、napi_generator-win.exe放在同级目录下。此处新建generatorCode文件夹，用于存放生成框架代码。整体目录文件如下：
|
||||
|
||||
E:\demo\napi>dir /B
|
||||
@ohos.napitest.d.ts
|
||||
basic.d.ts
|
||||
napi_generator-win.exe
|
||||
generatorCode
|
||||
|
||||
2.在终端中进入到之前可执行程序napi_generator-win.exe所在的目录，并运行napi_generator-win.exe，命令如下：
|
||||
|
||||
E:\demo\napi>napi_generator-win.exe -f @ohos.napitest.d.ts -o generatorCode -i false -n double
|
||||
|
||||
其中，参数详情如下：
|
||||
|
||||
-f, 待转换的.d.ts文件，若同时转换多个文件，文件之间用“,”隔开；
|
||||
|
||||
-d, 根据指定路径转换该文件夹中所有.d.ts文件；
|
||||
|
||||
-i, 可选参数，默认false，待转换.d.ts文件中引用非basic.d.ts的ts文件时打开开关；
|
||||
|
||||
-o, 可选参数，默认为当前目录，指定生成框架代码输出路径；
|
||||
|
||||
-n, 可选参数，默认为uint32_t，指定生成框架代码中number类型全部为指定类型；
|
||||
|
||||
-s, 可选参数，默认为不配置业务代码，指定生成框架代码的业务配置文件，用于粘合工具代码和业务代码的配置。
|
||||
|
||||
备注1：-f与-d两个参数只选其中一个参数即可。
|
||||
|
||||
备注2：若.d.ts文件中声明了basic.d.ts文件，将basic.d.ts文件放置在待转换.d.ts文件同一级目录；若除此之外还声明其它.d.ts文件，将此类文件放置在待转换.d.ts文件同级目录。
|
||||
|
||||
3.运行成功后会在generatorCode目录下生成框架代码文件，如下所示：
|
||||
|
||||
E:\demo\napi\generatorCode>dir /B
|
||||
binding.gyp
|
||||
BUILD.gn
|
||||
napitest.cpp
|
||||
napitest.h
|
||||
napitest_middle.h
|
||||
napitest_middle.cpp
|
||||
napi_gen.log
|
||||
test.sh
|
||||
tool_utility.cpp
|
||||
tool_utility.h
|
||||
|
||||
#### Mac
|
||||
|
||||
方法步骤参考windows、Linux的使用方法。
|
||||
|
||||
### VS Code插件使用方法
|
||||
|
||||
具体的插件使用步骤，可以左键单击以下链接了解：
|
||||
|
||||
[VS插件使用说明](https://gitee.com/openharmony/napi_generator/blob/master/napi_vs_plugin/docs/napi/INSTRUCTION_ZH.md)
|
||||
|
||||
### DevEco Studio上使用的IntelliJ插件使用方法
|
||||
|
||||
具体的插件使用步骤，可以左键单击以下链接了解：
|
||||
|
||||
[DevEco Studio上使用的IntelliJ插件使用说明](https://gitee.com/openharmony/napi_generator/blob/master/napi_IntelliJ_plugin/docs/napi/INSTRUCTION_ZH.md)
|
||||
|
||||
## 集成测试
|
||||
NAPI框架代码生成后，系统框架开发者进行二次开发后，即可集成到OpenHarmony编译系统，生成对应的库文件，供应用开发者调用接口。工具集成测试的具体操作步骤可以左键单击以下链接了解：
|
||||
|
||||
[工具集成测试](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/INTEGRATION_TESTING_ZH.md)
|
||||
|
||||
120
docs/guide/DEVELOP_ZH.md
Normal file
120
docs/guide/DEVELOP_ZH.md
Normal file
@ -0,0 +1,120 @@
|
||||
# NAPI框架生成工具开发说明
|
||||
|
||||
若当前工具功能不满足开发者需求，开发者需增强工具能力，则可基于已有源码进行工具二次开发，编译打包生成自定义的可执行文件和插件。
|
||||
|
||||
## 工具开发
|
||||
|
||||
### 可执行文件开发说明
|
||||
|
||||
#### 环境说明
|
||||
|
||||
系统：建议Ubuntu 20.04或者Windows 10
|
||||
|
||||
#### 开发步骤
|
||||
|
||||
##### Linux
|
||||
|
||||
1.安装typescript：在napi_generator/src目录下执行命令：
|
||||
|
||||
npm i typescript
|
||||
|
||||
2.安装stdio：在napi_generator目录下执行命令：
|
||||
|
||||
npm i stdio
|
||||
|
||||
3.安装pkg : 在napi_generator目录下执行命令：
|
||||
|
||||
sudo npm i -g pkg
|
||||
|
||||
4.集成clang-format（可选步骤）：
|
||||
|
||||
如果需要工具自动格式化生成的C++代码，可执行此步骤。
|
||||
将windows版的clang-format.exe程序和linux版的clang-format程序拷贝到napi_generator目录下。
|
||||
clang-format程序可从OpenHarmony编译环境获取：
|
||||
windows版：OpenHarmony/prebuilts/clang/ohos/windows-x86_64/llvm/bin/clang-format.exe
|
||||
Linux版：OpenHarmony/prebuilts/mingw-w64/ohos/linux-x86_64/clang-mingw/bin/clang-format
|
||||
|
||||
5.打包三个版本 : 执行命令：
|
||||
|
||||
pkg .
|
||||
|
||||
执行以上步骤后，即可在napi_generator目录下生成Windows、linux、mac系统下的可执行程序:
|
||||
|
||||
napi_generator-win.exe、napi_generator-linux、napi_generator-macos
|
||||
|
||||
6.根据需求打包指定系统下的可执行文件。若想只打包windows系统下可执行文件，可执行命令：
|
||||
|
||||
pkg -t node14-win . -o napi_generator-win.exe
|
||||
|
||||
若想只打包linux系统下可执行文件，可执行命令：
|
||||
|
||||
pkg -t node14-linux . -o napi_generator-linux
|
||||
|
||||
若想只打包macos系统下可执行文件，可执行命令：
|
||||
|
||||
pkg -t node14-macos . -o napi_generator-macos
|
||||
|
||||
备注：参数-t为指定系统，参数-o为指定可执行文件名称。
|
||||
|
||||
|
||||
##### Windows
|
||||
|
||||
1.安装typescript：使用管理员身份在napi_generator/src目录下执行命令：
|
||||
|
||||
npm i typescript
|
||||
|
||||
2.安装stdio：使用管理员身份在napi_generator目录下执行命令：
|
||||
|
||||
npm i stdio
|
||||
|
||||
3.安装pkg : 使用管理员身份在napi_generator目录下执行命令：
|
||||
|
||||
npm i -g pkg
|
||||
|
||||
4.集成clang-format（可选步骤）：
|
||||
|
||||
如果需要工具自动格式化生成的C++代码，可执行此步骤。
|
||||
将windows版的clang-format.exe程序和linux版的clang-format程序拷贝到napi_generator目录下。
|
||||
clang-format程序可从OpenHarmony编译环境获取：
|
||||
windows版：OpenHarmony/prebuilts/clang/ohos/windows-x86_64/llvm/bin/clang-format.exe
|
||||
Linux版：OpenHarmony/prebuilts/mingw-w64/ohos/linux-x86_64/clang-mingw/bin/clang-format
|
||||
|
||||
5.打包三个版本 : 使用管理员身份执行命令：
|
||||
|
||||
pkg .
|
||||
|
||||
执行以上步骤后，即可在napi_generator目录下生成Windows、linux、mac系统下的可执行程序:
|
||||
|
||||
napi_generator-win.exe、napi_generator-linux、napi_generator-macos
|
||||
|
||||
6.根据需求打包指定系统下的可执行文件。若想只打包windows系统下可执行文件，可执行命令：
|
||||
|
||||
pkg -t node14-win . -o napi_generator-win.exe
|
||||
|
||||
若想只打包linux系统下可执行文件，可执行命令：
|
||||
|
||||
pkg -t node14-linux . -o napi_generator-linux
|
||||
|
||||
若想只打包macos系统下可执行文件，可执行命令：
|
||||
|
||||
pkg -t node14-macos . -o napi_generator-macos
|
||||
|
||||
### VS插件开发说明
|
||||
|
||||
具体的插件开发步骤，可以左键单击以下链接了解：
|
||||
|
||||
[VS插件开发说明](https://gitee.com/openharmony/napi_generator/blob/master/napi_vs_plugin/docs/napi/DEVELOP_ZH.md)
|
||||
|
||||
### DevEco Studio上使用的IntelliJ插件开发说明
|
||||
|
||||
具体的插件开发步骤，可以左键单击以下链接了解：
|
||||
|
||||
[DevEco Studio上使用的IntelliJ插件开发说明](https://gitee.com/openharmony/napi_generator/blob/master/napi_IntelliJ_plugin/docs/napi/DEVELOP_ZH.md)
|
||||
|
||||
## 工具测试
|
||||
进行工具二次开发后，本地可进行单元测试、story特性测试确保工具的可用性。左键单击以下链接了解详情：
|
||||
|
||||
[单元测试](https://gitee.com/openharmony/napi_generator/blob/master/test/unittest/README_ZH.md)
|
||||
|
||||
[story测试](https://gitee.com/openharmony/napi_generator/blob/master/test/storytest/README_ZH.md)
|
||||
|
||||
362
docs/guide/ENSEMBLE_METHOD_3.1VERSION.md
Normal file
362
docs/guide/ENSEMBLE_METHOD_3.1VERSION.md
Normal file
@ -0,0 +1,362 @@
|
||||
# 集成到OpenHarmony 3.1 Release的方法
|
||||
|
||||
## 场景说明
|
||||
|
||||
为了实现工具生成的接口被其它子系统或者应用调用，需将生成的代码编译集成到OpenHarmony系统中，使其生成动态库，供OpenHarmony应用层调用。
|
||||
本文介绍如何将工具生成的源码利用OpenHarmony编译系统生成动态库供应用层调用，集成到OpenHarmony 3.1 Release主要是有以下两种方式，分别为增加ohos.build文件方式和增加bundle.json文件方式。
|
||||
|
||||
## 3.1 版本
|
||||
|
||||
### bundle.json方式集成
|
||||
|
||||
#### 建立模块位置
|
||||
|
||||
模块目录理论上可在OpenHarmony工程的任一位置，假设OpenHarmony代码库的目录为OHOS_SRC，在OHOS_SRC/foundation目录下，建测试模块目录：napitest。napitest目录结构如下：
|
||||
|
||||
napitest
|
||||
|-- binding.gyp
|
||||
|-- BUILD.gn
|
||||
|-- bundle.json
|
||||
|-- napitest.cpp
|
||||
|-- napitest.h
|
||||
|-- napitest_middle.h
|
||||
|-- napitest_middle.cpp
|
||||
|-- test.sh
|
||||
|-- tool_utility.cpp
|
||||
|-- tool_utility.h
|
||||
|
||||
其中bundle.json为新增的编译配置文件，其它为工具生成的代码。
|
||||
|
||||
#### 编译修改点
|
||||
|
||||
##### 修改BUILD.gn文件
|
||||
|
||||
将deps中"//foundation/arkui/napi:ace_napi"的修改为"//foundation/ace/napi:ace_napi"，修改后的BUILD.gn文件内容如下所示：
|
||||
|
||||
```
|
||||
import("//build/ohos.gni")
|
||||
|
||||
ohos_shared_library("napitest")
|
||||
{
|
||||
sources = [
|
||||
"napitest_middle.cpp",
|
||||
"../serviceCode/NodeISayHello.cpp", # 将业务代码编译进去
|
||||
"napitest.cpp",
|
||||
"tool_utility.cpp",
|
||||
]
|
||||
include_dirs = [
|
||||
".",
|
||||
"//third_party/node/src",
|
||||
]
|
||||
deps=[
|
||||
"//foundation/ace/napi:ace_napi",
|
||||
"//base/hiviewdfx/hilog/interfaces/native/innerkits:libhilog",
|
||||
]
|
||||
remove_configs = [ "//build/config/compiler:no_rtti" ]
|
||||
cflags=[
|
||||
]
|
||||
cflags_cc=[
|
||||
"-frtti",
|
||||
]
|
||||
ldflags = [
|
||||
]
|
||||
|
||||
relative_install_dir = "module"
|
||||
part_name = "napitest"
|
||||
subsystem_name = "napitest"
|
||||
}
|
||||
```
|
||||
|
||||
若用户需要修改子系统和部件名称，则根据自身需求修改BUILD.gn文件和bundle.json文件中子系统与部件名称即可。
|
||||
|
||||
##### 修改bundle.json文件
|
||||
|
||||
其中destPath选项中的"//foundation/napitest"指的是napitest目录，":napitest"指的是上面BUILD.gn中的目标ohos_shared_library("napitest")。
|
||||
|
||||
```
|
||||
{
|
||||
"name": "@ohos/napitest",
|
||||
"description": "napitest provides atomic capabilities",
|
||||
"version": "3.1",
|
||||
"license": "Apache License 2.0",
|
||||
"publishAs": "code-segment",
|
||||
"segment": {
|
||||
"destPath": "foundation/napitest"
|
||||
},
|
||||
"dirs": {},
|
||||
"scripts": {},
|
||||
"component": {
|
||||
"name": "napitest",
|
||||
"subsystem": "napitest",
|
||||
"features": [],
|
||||
"adapted_system_type": [
|
||||
"standard"
|
||||
],
|
||||
"rom": "10000KB",
|
||||
"ram": "10000KB",
|
||||
"deps": {
|
||||
"components": [
|
||||
"ace_napi",
|
||||
"ipc_core",
|
||||
"libhilog"
|
||||
],
|
||||
"third_party": [
|
||||
"node"
|
||||
]
|
||||
},
|
||||
"build": {
|
||||
"sub_component": [
|
||||
"//foundation/napitest:napitest"
|
||||
],
|
||||
"inner_kits": [
|
||||
{
|
||||
"header": {
|
||||
"header_base": "//foundation/napitest",
|
||||
"header_files": [
|
||||
"tool_utility.h",
|
||||
"napitest.h",
|
||||
"napitest_middle.h"
|
||||
]
|
||||
},
|
||||
"name": "//foundation/napitest:napitest"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
##### 修改napitest.cpp文件
|
||||
|
||||
为方便调试，在napitest.cpp文件中增加业务代码。以修改napitest.cpp文件为例，在以下方法中增加业务代码，
|
||||
|
||||
在sayHello方法中增加注册的object回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
// 业务代码调用 onSayHelloStart callback
|
||||
napitest::napitest_interface::NodeISayHello::listener_.NodeISayHelloListener_onSayHelloStartCallback(info1);
|
||||
// 业务代码调用 onSayHelloEnd callback
|
||||
napitest::napitest_interface::NodeISayHello::listener_.NodeISayHelloListener_onSayHelloEndCallback(info2);
|
||||
...
|
||||
```
|
||||
|
||||
在sayHi方法中增加register注册的回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
napitest::napitest_interface::NodeISayHello *ptr = new napitest::napitest_interface::NodeISayHello();
|
||||
uint32_t callbackNum = 50;
|
||||
ptr->CallbackfuncCallback(callbackNum);
|
||||
delete ptr;
|
||||
...
|
||||
```
|
||||
|
||||
在sayHelloWithResponse方法中增加Promise回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
out.errMsg = "";
|
||||
out.response = "rec hello.";
|
||||
out.result = 0;
|
||||
...
|
||||
```
|
||||
|
||||
在funcTest方法中增加普通函数的业务逻辑：
|
||||
|
||||
```
|
||||
...
|
||||
if (v) {
|
||||
out = "ret is true";
|
||||
} else {
|
||||
out = "ret is false";
|
||||
}
|
||||
...
|
||||
```
|
||||
|
||||
增加业务代码之后的文件如下所示：
|
||||
|
||||
[napitest.cpp](https://gitee.com/openharmony/napi_generator/blob/master/examples/napitest.cpp)
|
||||
|
||||
##### 增加子系统
|
||||
|
||||
在源码/build/subsystem_config.json中增加子系统选项。如下所示：
|
||||
|
||||
```
|
||||
"napitest": {
|
||||
"project": "hmf/napitest",
|
||||
"path": "foundation/napitest",
|
||||
"name": "napitest",
|
||||
"dir": "foundation"
|
||||
}
|
||||
```
|
||||
|
||||
#### 添加功能模块
|
||||
|
||||
在产品配置中添加上述子系统的功能模块，编译到产品产出文件中，例如在源码/productdefine/common/products/rk3566.json中增加part选项，其中第一个napitest就是BUILD.gn文件中的subsystem_name，第二个napitest就是BUILD.gn文件中的part_name。
|
||||
|
||||
"napitest:napitest":{}
|
||||
|
||||
#### 编译验证
|
||||
|
||||
编译成功后，就会在 /out/产品名/packages/phone/system/lib/module/ 生成libnapitest.z.so，如下所示：
|
||||
|
||||
/out/ohos-arm-release/packages/phone/system/lib/module
|
||||
|
||||
### ohos.build方式集成
|
||||
|
||||
#### 建立模块位置
|
||||
|
||||
模块目录理论上可在OpenHarmony工程的任一位置，假设OpenHarmony代码库的目录为OHOS_SRC，在OHOS_SRC/foundation目录下，建测试模块目录：napitest。napitest目录结构如下：
|
||||
|
||||
napitest
|
||||
|-- binding.gyp
|
||||
|-- BUILD.gn
|
||||
|-- ohos.build
|
||||
|-- napitest.cpp
|
||||
|-- napitest.h
|
||||
|-- napitest_middle.h
|
||||
|-- napitest_middle.cpp
|
||||
|-- test.sh
|
||||
|-- tool_utility.cpp
|
||||
|-- tool_utility.h
|
||||
|
||||
其中ohos.build为新增的编译配置文件，其它为工具生成的代码。
|
||||
|
||||
#### 编译修改点
|
||||
|
||||
##### 修改BUILD.gn文件
|
||||
|
||||
将deps中"//foundation/arkui/napi:ace_napi"的修改为"//foundation/ace/napi:ace_napi"，修改后的BUILD.gn文件内容如下所示：
|
||||
|
||||
```
|
||||
import("//build/ohos.gni")
|
||||
|
||||
ohos_shared_library("napitest")
|
||||
{
|
||||
sources = [
|
||||
"napitest_middle.cpp",
|
||||
"../serviceCode/NodeISayHello.cpp", # 将业务代码编译进去
|
||||
"napitest.cpp",
|
||||
"tool_utility.cpp",
|
||||
]
|
||||
include_dirs = [
|
||||
".",
|
||||
"//third_party/node/src",
|
||||
]
|
||||
deps=[
|
||||
"//foundation/ace/napi:ace_napi",
|
||||
"//base/hiviewdfx/hilog/interfaces/native/innerkits:libhilog",
|
||||
]
|
||||
remove_configs = [ "//build/config/compiler:no_rtti" ]
|
||||
cflags=[
|
||||
]
|
||||
cflags_cc=[
|
||||
"-frtti",
|
||||
]
|
||||
ldflags = [
|
||||
]
|
||||
|
||||
relative_install_dir = "module"
|
||||
part_name = "napitest"
|
||||
subsystem_name = "napitest"
|
||||
}
|
||||
```
|
||||
|
||||
若用户需要修改子系统和部件名称，则根据自身需求修改BUILD.gn文件和ohos.build文件中子系统与部件名称即可。
|
||||
|
||||
##### 修改ohos.build文件
|
||||
|
||||
其中module_list选项中的"//foundation/napitest"指的是napitest目录，":napitest"指的是上面BUILD.gn中的目标ohos_shared_library("napitest")。
|
||||
|
||||
```
|
||||
{
|
||||
"subsystem": "napitest",
|
||||
"parts": {
|
||||
"napitest": {
|
||||
"module_list": [
|
||||
"//foundation/napitest:napitest"
|
||||
],
|
||||
"test_list": []
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
##### 修改napitest.cpp文件
|
||||
|
||||
为方便调试，在napitest.cpp文件中增加业务代码。以修改napitest.cpp文件为例，在以下方法中增加业务代码，
|
||||
|
||||
在sayHello方法中增加注册的object回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
// 业务代码调用 onSayHelloStart callback
|
||||
napitest::napitest_interface::NodeISayHello::listener_.NodeISayHelloListener_onSayHelloStartCallback(info1);
|
||||
// 业务代码调用 onSayHelloEnd callback
|
||||
napitest::napitest_interface::NodeISayHello::listener_.NodeISayHelloListener_onSayHelloEndCallback(info2);
|
||||
...
|
||||
```
|
||||
|
||||
在sayHi方法中增加register注册的回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
napitest::napitest_interface::NodeISayHello *ptr = new napitest::napitest_interface::NodeISayHello();
|
||||
uint32_t callbackNum = 50;
|
||||
ptr->CallbackfuncCallback(callbackNum);
|
||||
delete ptr;
|
||||
...
|
||||
```
|
||||
|
||||
在sayHelloWithResponse方法中增加Promise回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
out.errMsg = "";
|
||||
out.response = "rec hello.";
|
||||
out.result = 0;
|
||||
...
|
||||
```
|
||||
|
||||
在funcTest方法中增加普通函数的业务逻辑：
|
||||
|
||||
```
|
||||
...
|
||||
if (v) {
|
||||
out = "ret is true";
|
||||
} else {
|
||||
out = "ret is false";
|
||||
}
|
||||
...
|
||||
```
|
||||
|
||||
增加业务代码之后的文件如下所示：
|
||||
|
||||
[napitest.cpp](https://gitee.com/openharmony/napi_generator/blob/master/examples/napitest.cpp)
|
||||
|
||||
##### 增加子系统
|
||||
|
||||
在源码/build/subsystem_config.json中增加子系统选项。如下所示：
|
||||
|
||||
```
|
||||
"napitest": {
|
||||
"project": "hmf/napitest",
|
||||
"path": "foundation/napitest",
|
||||
"name": "napitest",
|
||||
"dir": "foundation"
|
||||
}
|
||||
```
|
||||
|
||||
#### 添加功能模块
|
||||
|
||||
在产品配置中添加上述子系统的功能模块，编译到产品产出文件中，例如在源码/productdefine/common/products/rk3566.json中增加part选项，其中第一个napitest就是BUILD.gn文件中的subsystem_name，第二个napitest就是BUILD.gn文件中的part_name。
|
||||
|
||||
"napitest:napitest":{}
|
||||
|
||||
#### 编译验证
|
||||
|
||||
编译成功后，就会在 /out/产品名/packages/phone/system/lib/module/ 生成libnapitest.z.so，如下所示：
|
||||
|
||||
/out/ohos-arm-release/packages/phone/system/lib/module
|
||||
|
||||
171
docs/guide/ENSEMBLE_METHOD_4.0CFGCODE.md
Normal file
171
docs/guide/ENSEMBLE_METHOD_4.0CFGCODE.md
Normal file
@ -0,0 +1,171 @@
|
||||
# 手动配置业务代码后集成到OpenHarmony的方法
|
||||
|
||||
## 场景说明
|
||||
|
||||
为了实现工具生成的接口被其它子系统或者应用调用，需将生成的代码编译集成到OpenHarmony系统中，使其生成动态库，供OpenHarmony应用层调用。
|
||||
本文介绍如何手动配置业务代码并将生成的代码集成到OpenHarmony 4.0 Release。
|
||||
|
||||
## 4.0 版本
|
||||
|
||||
### 建立模块位置
|
||||
|
||||
模块目录理论上可在OpenHarmony工程的任一位置，假设OpenHarmony代码库的目录为OHOS_SRC，在OHOS_SRC/foundation目录下，建测试模块目录：napitest。napitest目录结构如下：
|
||||
|
||||
napitest
|
||||
|-- binding.gyp
|
||||
|-- BUILD.gn
|
||||
|-- bundle.json
|
||||
|-- napitest.cpp
|
||||
|-- napitest.h
|
||||
|-- napitest_middle.h
|
||||
|-- napitest_middle.cpp
|
||||
|-- test.sh
|
||||
|-- tool_utility.cpp
|
||||
|-- tool_utility.h
|
||||
|
||||
其中bundle.json为新增的编译配置文件，其它为工具生成的代码。
|
||||
|
||||
### 编译修改点
|
||||
|
||||
#### 修改bundle.json文件
|
||||
|
||||
其中destPath选项中的"//foundation/napitest"指的是napitest目录，":napitest"指的是上面BUILD.gn中的目标ohos_shared_library("napitest")。
|
||||
|
||||
```
|
||||
{
|
||||
"name": "@ohos/napitest",
|
||||
"description": "napitest provides atomic capabilities",
|
||||
"version": "4.0",
|
||||
"license": "Apache License 2.0",
|
||||
"publishAs": "code-segment",
|
||||
"segment": {
|
||||
"destPath": "foundation/napitest"
|
||||
},
|
||||
"dirs": {},
|
||||
"scripts": {},
|
||||
"component": {
|
||||
"name": "napitest",
|
||||
"subsystem": "napitest",
|
||||
"features": [],
|
||||
"adapted_system_type": [
|
||||
"standard"
|
||||
],
|
||||
"rom": "10000KB",
|
||||
"ram": "10000KB",
|
||||
"deps": {
|
||||
"components": [
|
||||
"ace_napi",
|
||||
"ipc_core",
|
||||
"libhilog"
|
||||
],
|
||||
"third_party": [
|
||||
"node"
|
||||
]
|
||||
},
|
||||
"build": {
|
||||
"sub_component": [
|
||||
"//foundation/napitest:napitest"
|
||||
],
|
||||
"inner_kits": [
|
||||
{
|
||||
"header": {
|
||||
"header_base": "//foundation/napitest",
|
||||
"header_files": [
|
||||
"tool_utility.h",
|
||||
"napitest.h",
|
||||
"napitest_middle.h"
|
||||
]
|
||||
},
|
||||
"name": "//foundation/napitest:napitest"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 修改napitest.cpp文件
|
||||
|
||||
为方便调试，在napitest.cpp文件中增加业务代码。以修改napitest.cpp文件为例，在以下方法中增加业务代码，
|
||||
|
||||
在sayHello方法中增加注册的object回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
// 业务代码调用 onSayHelloStart callback
|
||||
napitest::napitest_interface::NodeISayHello::listener_.NodeISayHelloListener_onSayHelloStartCallback(info1);
|
||||
// 业务代码调用 onSayHelloEnd callback
|
||||
napitest::napitest_interface::NodeISayHello::listener_.NodeISayHelloListener_onSayHelloEndCallback(info2);
|
||||
...
|
||||
```
|
||||
|
||||
在sayHi方法中增加register注册的回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
napitest::napitest_interface::NodeISayHello *ptr = new napitest::napitest_interface::NodeISayHello();
|
||||
uint32_t callbackNum = 50;
|
||||
ptr->CallbackfuncCallback(callbackNum);
|
||||
delete ptr;
|
||||
...
|
||||
```
|
||||
|
||||
在sayHelloWithResponse方法中增加Promise回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
out.errMsg = "";
|
||||
out.response = "rec hello.";
|
||||
out.result = 0;
|
||||
...
|
||||
```
|
||||
|
||||
在funcTest方法中增加普通函数的业务逻辑：
|
||||
|
||||
```
|
||||
...
|
||||
if (v) {
|
||||
out = "ret is true";
|
||||
} else {
|
||||
out = "ret is false";
|
||||
}
|
||||
...
|
||||
```
|
||||
|
||||
增加业务代码之后的文件如下所示：
|
||||
|
||||
[napitest.cpp](https://gitee.com/openharmony/napi_generator/blob/master/examples/napitest.cpp)
|
||||
|
||||
#### 增加子系统
|
||||
|
||||
在源码/build/subsystem_config.json中增加子系统选项。如下所示：
|
||||
|
||||
```
|
||||
"napitest": {
|
||||
"path": "foundation/napitest",
|
||||
"name": "napitest"
|
||||
}
|
||||
```
|
||||
|
||||
### 添加功能模块
|
||||
|
||||
在产品配置中添加上述子系统的功能模块，编译到产品产出文件中，例如在源码vendor/hihope/rk3568/config.json中增加part选项，其中第一个napitest就是BUILD.gn文件中的subsystem_name，第二个napitest就是BUILD.gn文件中的part_name。
|
||||
|
||||
```
|
||||
{
|
||||
"subsystem": "napitest",
|
||||
"components": [
|
||||
{
|
||||
"component": "napitest",
|
||||
"features": []
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 编译验证
|
||||
|
||||
编译成功后，就会在 /out/产品名/packages/phone/system/lib/module/ 生成libnapitest.z.so，如下所示：
|
||||
|
||||
/out/rk3568/packages/phone/system/lib/module
|
||||
|
||||
310
docs/guide/ENSEMBLE_METHOD_ZH.md
Normal file
310
docs/guide/ENSEMBLE_METHOD_ZH.md
Normal file
@ -0,0 +1,310 @@
|
||||
# NAPI框架生成代码集成到OpenHarmony的方法
|
||||
|
||||
## 场景说明
|
||||
|
||||
为了实现工具生成的接口被其他子系统或者应用调用，需将生成的代码编译集成到OpenHarmony系统中，使其生成动态库，供OpenHarmony应用层调用。
|
||||
本文介绍如何将工具生成的源码利用OpenHarmony编译系统生成动态库供应用层调用，主要是有以下两种方式，分别为增加ohos.build文件方式和增加bundle.json文件方式。
|
||||
|
||||
## 4.0 版本
|
||||
|
||||
### 建立模块位置
|
||||
|
||||
模块目录理论上可在OpenHarmony工程的任一位置，假设OpenHarmony代码库的目录为OHOS_SRC，在OHOS_SRC/foundation目录下，建测试模块目录：napitest。napitest目录结构如下：
|
||||
|
||||
napitest
|
||||
|-- generatorCode // 工具代码部分
|
||||
|-- |-- binding.gyp
|
||||
|-- |-- BUILD.gn
|
||||
|-- |-- bundle.json
|
||||
|-- |-- napitest.cpp
|
||||
|-- |-- napitest.h
|
||||
|-- |-- napitest_middle.h
|
||||
|-- |-- napitest_middle.cpp
|
||||
|-- |-- test.sh
|
||||
|-- |-- tool_utility.cpp
|
||||
|-- |-- tool_utility.h
|
||||
|-- |-- napi_gen.log
|
||||
|-- serviceCode // 放置业务代码部分
|
||||
|-- |-- NodeISayHello.h
|
||||
|-- |-- NodeISayHello.cpp
|
||||
|
||||
其中generatorCode为工具生成的代码，serviceCode 为用户配置的业务代码， bundle.json 为新增的编译配置文件。
|
||||
|
||||
### 编译修改点
|
||||
|
||||
#### 修改bundle.json文件
|
||||
|
||||
其中destPath选项中的"//foundation/napitest/generatorCode"指的是napitest目录，":napitest"指的是上面BUILD.gn中的目标ohos_shared_library("napitest")。
|
||||
|
||||
```
|
||||
{
|
||||
"name": "@ohos/napitest",
|
||||
"description": "napitest provides atomic capabilities",
|
||||
"version": "4.0",
|
||||
"license": "Apache License 2.0",
|
||||
"publishAs": "code-segment",
|
||||
"segment": {
|
||||
"destPath": "foundation/napitest/generatorCode"
|
||||
},
|
||||
"dirs": {},
|
||||
"scripts": {},
|
||||
"component": {
|
||||
"name": "napitest",
|
||||
"subsystem": "napitest",
|
||||
"features": [],
|
||||
"adapted_system_type": [
|
||||
"standard"
|
||||
],
|
||||
"rom": "10000KB",
|
||||
"ram": "10000KB",
|
||||
"deps": {
|
||||
"components": [
|
||||
"ace_napi",
|
||||
"ipc_core",
|
||||
"libhilog"
|
||||
],
|
||||
"third_party": [
|
||||
"node"
|
||||
]
|
||||
},
|
||||
"build": {
|
||||
"sub_component": [
|
||||
"//foundation/napitest/generatorCode:napitest"
|
||||
],
|
||||
"inner_kits": [
|
||||
{
|
||||
"header": {
|
||||
"header_base": "//foundation/napitest/generatorCode",
|
||||
"header_files": [
|
||||
"tool_utility.h",
|
||||
"napitest.h",
|
||||
"napitest_middle.h"
|
||||
]
|
||||
},
|
||||
"name": "//foundation/napitest/generatorCode:napitest"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 增加子系统
|
||||
|
||||
在源码/build/subsystem_config.json中增加子系统选项。如下所示：
|
||||
|
||||
```
|
||||
"napitest": {
|
||||
"path": "foundation/napitest/generatorCode",
|
||||
"name": "napitest"
|
||||
}
|
||||
```
|
||||
|
||||
### 添加功能模块
|
||||
|
||||
在产品配置中添加上述子系统的功能模块，编译到产品产出文件中，例如在源码vendor/hihope/rk3568/config.json中增加part选项，其中第一个napitest就是BUILD.gn文件中的subsystem_name，第二个napitest就是BUILD.gn文件中的part_name。
|
||||
|
||||
```
|
||||
{
|
||||
"subsystem": "napitest",
|
||||
"components": [
|
||||
{
|
||||
"component": "napitest",
|
||||
"features": []
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 编译验证
|
||||
|
||||
编译成功后，就会在 /out/产品名/packages/phone/system/lib/module/ 生成libnapitest.z.so，如下所示：
|
||||
|
||||
/out/rk3568/packages/phone/system/lib/module
|
||||
|
||||
### 备注
|
||||
|
||||
若自动配置业务代码不能满足业务场景，用户可以手动配置业务代码，以下为用户手动配置业务代码并集成到OpenHarmony上的方法：
|
||||
|
||||
[4.0版本手动配置业务代码集成方法](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/ENSEMBLE_METHOD_4.0CFGCODE.md)
|
||||
|
||||
## 3.2 版本
|
||||
|
||||
### 建立模块位置
|
||||
|
||||
模块目录理论上可在OpenHarmony工程的任一位置，假设OpenHarmony代码库的目录为OHOS_SRC，在OHOS_SRC/foundation目录下，建测试模块目录：napitest。napitest目录结构如下：
|
||||
|
||||
napitest
|
||||
|-- binding.gyp
|
||||
|-- BUILD.gn
|
||||
|-- bundle.json
|
||||
|-- napitest.cpp
|
||||
|-- napitest.h
|
||||
|-- napitest_middle.h
|
||||
|-- napitest_middle.cpp
|
||||
|-- test.sh
|
||||
|-- tool_utility.cpp
|
||||
|-- tool_utility.h
|
||||
|
||||
其中bundle.json为新建的编译配置文件，其它为工具生成的代码。
|
||||
|
||||
### 编译修改点
|
||||
|
||||
#### 修改bundle.json文件
|
||||
|
||||
其中destPath选项中的"//foundation/napitest"指的是napitest目录，":napitest"指的是上面BUILD.gn中的目标ohos_shared_library("napitest")。
|
||||
|
||||
```
|
||||
{
|
||||
"name": "@ohos/napitest",
|
||||
"description": "napitest provides atomic capabilities",
|
||||
"version": "3.2",
|
||||
"license": "Apache License 2.0",
|
||||
"publishAs": "code-segment",
|
||||
"segment": {
|
||||
"destPath": "foundation/napitest"
|
||||
},
|
||||
"dirs": {},
|
||||
"scripts": {},
|
||||
"component": {
|
||||
"name": "napitest",
|
||||
"subsystem": "napitest",
|
||||
"features": [],
|
||||
"adapted_system_type": [
|
||||
"standard"
|
||||
],
|
||||
"rom": "10000KB",
|
||||
"ram": "10000KB",
|
||||
"deps": {
|
||||
"components": [
|
||||
"ace_napi",
|
||||
"ipc_core",
|
||||
"libhilog"
|
||||
],
|
||||
"third_party": [
|
||||
"node"
|
||||
]
|
||||
},
|
||||
"build": {
|
||||
"sub_component": [
|
||||
"//foundation/napitest:napitest"
|
||||
],
|
||||
"inner_kits": [
|
||||
{
|
||||
"header": {
|
||||
"header_base": "//foundation/napitest",
|
||||
"header_files": [
|
||||
"tool_utility.h",
|
||||
"napitest.h",
|
||||
"napitest_middle.h"
|
||||
]
|
||||
},
|
||||
"name": "//foundation/napitest:napitest"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 修改napitest.cpp文件
|
||||
|
||||
为方便调试，在napitest.cpp文件中增加业务代码。以修改napitest.cpp文件为例，在以下方法中增加业务代码，
|
||||
|
||||
在sayHello方法中增加注册的object回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
// 业务代码调用 onSayHelloStart callback
|
||||
napitest::napitest_interface::NodeISayHello::listener_.NodeISayHelloListener_onSayHelloStartCallback(info1);
|
||||
// 业务代码调用 onSayHelloEnd callback
|
||||
napitest::napitest_interface::NodeISayHello::listener_.NodeISayHelloListener_onSayHelloEndCallback(info2);
|
||||
...
|
||||
```
|
||||
|
||||
在sayHi方法中增加register注册的回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
napitest::napitest_interface::NodeISayHello *ptr = new napitest::napitest_interface::NodeISayHello();
|
||||
uint32_t callbackNum = 50;
|
||||
ptr->CallbackfuncCallback(callbackNum);
|
||||
delete ptr;
|
||||
...
|
||||
```
|
||||
|
||||
在sayHelloWithResponse方法中增加Promise回调方法的调用：
|
||||
|
||||
```
|
||||
...
|
||||
out.errMsg = "";
|
||||
out.response = "rec hello.";
|
||||
out.result = 0;
|
||||
...
|
||||
```
|
||||
|
||||
在funcTest方法中增加普通函数的业务逻辑：
|
||||
|
||||
```
|
||||
...
|
||||
if (v) {
|
||||
out = "ret is true";
|
||||
} else {
|
||||
out = "ret is false";
|
||||
}
|
||||
...
|
||||
```
|
||||
|
||||
增加业务代码之后的文件如下所示：
|
||||
|
||||
[napitest.cpp](https://gitee.com/openharmony/napi_generator/blob/master/examples/napitest.cpp)
|
||||
|
||||
#### 增加子系统
|
||||
|
||||
在源码/build/subsystem_config.json中增加子系统选项。如下所示：
|
||||
|
||||
```
|
||||
"napitest": {
|
||||
"path": "foundation/napitest",
|
||||
"name": "napitest"
|
||||
}
|
||||
```
|
||||
|
||||
### 添加功能模块
|
||||
|
||||
在产品配置中添加上述子系统的功能模块，编译到产品产出文件中，例如在源码vendor/hihope/rk3568/config.json中增加part选项，其中第一个napitest就是BUILD.gn文件中的subsystem_name，第二个napitest就是BUILD.gn文件中的part_name。
|
||||
|
||||
```
|
||||
{
|
||||
"subsystem": "napitest",
|
||||
"components": [
|
||||
{
|
||||
"component": "napitest",
|
||||
"features": []
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 编译验证
|
||||
|
||||
编译成功后，就会在 /out/产品名/packages/phone/system/lib/module/ 生成libnapitest.z.so，如下所示：
|
||||
|
||||
/out/rk3568/packages/phone/system/lib/module
|
||||
|
||||
## 3.1 版本
|
||||
|
||||
[3.1版本集成方法](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/ENSEMBLE_METHOD_3.1VERSION.md)
|
||||
|
||||
## 总结
|
||||
|
||||
3.1版本两种集成方式使用场景说明：
|
||||
|
||||
ohos.build方式集成：适合3.0前版本使用。
|
||||
|
||||
bundle.json方式集成：兼容ohos.build方式，但3.1及以后版本建议使用此种方式集成。
|
||||
|
||||
3.2版本适合使用bundle.json方式集成。
|
||||
|
||||
4.0版本适合使用bundle.json方式集成。
|
||||
|
||||
285
docs/guide/INSTRUCTION_ZH.md
Normal file
285
docs/guide/INSTRUCTION_ZH.md
Normal file
@ -0,0 +1,285 @@
|
||||
# NAPI框架生成工具使用说明
|
||||
## 简介
|
||||
|
||||
NAPI框架生成工具支持三种入口，分别是可执行程序、VS Code插件、DevEco Studio上使用的IntelliJ插件，使用者可以根据自己的需要选择合适的工具。
|
||||
|
||||
1.可执行文件下载路径如下(由于网络原因，可能会导致有的下载链接失效，因此提供了以下三个下载链接):
|
||||
|
||||
[可执行文件下载链接1](http://ftpkaihongdigi.i234.me:5000/sharing/yaRiKSjBI)
|
||||
|
||||
[可执行文件下载链接2](http://ftp.kaihong.com:5000/fsdownload/yaRiKSjBI/)
|
||||
|
||||
[可执行文件下载链接3](http://ftp.kaihongdigi.com:5000/fsdownload/yaRiKSjBI/)
|
||||
|
||||
访问密码：kaihong
|
||||
|
||||
压缩包解压密码：kaihong20231121
|
||||
|
||||
DevEco Studio上使用的IntelliJ插件下载路径如下：
|
||||
|
||||
[DevEco Studio上使用的IntelliJ插件下载链接](https://plugins.jetbrains.com/plugin/19593-napi-generator/versions)
|
||||
|
||||
## 工具介绍
|
||||
|
||||
通过NAPI框架生成工具，使用者可输入一个接口定义的ts文件，一键生成NAPI框架代码、业务代码框架、GN脚本等文件，并使用生成的NAPI接口及功能。使用者也可以输入一个定义方法的.h头文件，反向生成ts文件。
|
||||
|
||||
|
||||
|
||||
## 预检查
|
||||
|
||||
napi_generator的可执行程序方式和插件方式都具有预检查的功能，如果.d.ts文件中存在语法错误，那么执行的时候命令行会打印出错误信息，指出代码中存在错误的行号。使用效果如下：
|
||||
|
||||
joey@joey-virtual-machine:~/code/napi_test$ ./napi_generator-linux -f @ohos.napitest.d.ts
|
||||
@ohos.napitest.d.ts (33,12): Identifier expected.
|
||||
@ohos.napitest.d.ts (33,13): ';' expected.
|
||||
@ohos.napitest.d.ts (33,13): An identifier or keyword cannot immediately follow a numeric literal.
|
||||
@ohos.napitest.d.ts (33,13): Cannot find name 'shutdownDevice'.
|
||||
@ohos.napitest.d.ts (33,28): Cannot find name 'reason'.
|
||||
@ohos.napitest.d.ts (33,34): ',' expected.
|
||||
@ohos.napitest.d.ts (33,36): 'string' only refers to a type, but is being used as a value here.
|
||||
@ohos.napitest.d.ts (33,43): ';' expected.
|
||||
@ohos.napitest.d.ts (33,49): Expression expected.
|
||||
|
||||
joey@joey-virtual-machine:~/code/napi_test$
|
||||
|
||||
@ohos.napitest.d.ts (33,49)，其中括号中第一个参数含义为行号，第二个参数含义为列号。
|
||||
|
||||
预检查的触发方式与生成框架的入口一致，使用方法参见生成框架描述。
|
||||
|
||||
## 生成框架
|
||||
|
||||
### 自动配置业务代码用例
|
||||
|
||||
1.ts文件用例
|
||||
|
||||
[@ohos.napitest.d.ts](https://gitee.com/openharmony/napi_generator/blob/master/examples/ts/@ohos.napitest.d.ts)
|
||||
|
||||
注册关键字说明
|
||||
|
||||
(1) registerXXX/unRegisterXXX
|
||||
|
||||
register与unRegister成对使用, registerXXX用于注册回调，其参数即为注册的回调函数，注册之后在其它普通方法中即可在C++层调用registerXXX注册的回调函数；unRegisterXXX用于注销回调，其参数即为需要注销的回调函数，注销之后将无法再在C++层调用注销的回调函数。如：
|
||||
|
||||
```
|
||||
export class NodeISayHello
|
||||
{
|
||||
...
|
||||
// register注册回调
|
||||
registerCallbackfunc(cb : (wid: number) => string);
|
||||
// unRegister注销回调
|
||||
unRegisterCallbackfunc(cb : (wid: number) => string);
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
其中注册/注销的回调方法为箭头函数 (wid: number) => string。注册回调之后，工具会生成回调方法CallbackfuncCallback，业务代码中用户自行定义回调时机进而通过回调接口调用回调，若回调被注销，则业务代码无法触发该回调。
|
||||
|
||||
(2) addXXX/removeXXX onXXX
|
||||
|
||||
addXXX与removeXXX成对使用，addXXX用于注册回调，其参数为class对象, 将需要注册的回调函数放于class中，其写法为onXXX，class中可以有多个onXXX回调函数；removeXXX用于注销回调，其参数为class对象，用于注销addXXX注册的回调。如：
|
||||
|
||||
```
|
||||
export class NodeISayHello
|
||||
{
|
||||
...
|
||||
// 注册object回调
|
||||
addSayHelloListener(listener: NodeISayHelloListener);
|
||||
// 注销object回调
|
||||
removeSayHelloListener(listener: NodeISayHelloListener);
|
||||
...
|
||||
}
|
||||
...
|
||||
export class NodeISayHelloListener
|
||||
{ // 定义回调
|
||||
onSayHelloStart(info: SayInfo);
|
||||
onSayHelloEnd(info: SayInfo);
|
||||
}
|
||||
```
|
||||
|
||||
其中注册/注销的回调方法为onSayHelloStart(info: SayInfo); onSayHelloEnd(info: SayInfo); 注册回调之后，工具会生成两个回调接口供用户调用，业务代码中用户自行定义回调时机进而通过回调接口调用回调，若回调被注销，则业务代码无法触发回调。
|
||||
|
||||
2.自动配置业务代码用例使用的cfg.json
|
||||
|
||||
[配置文件cfg.json用例](https://gitee.com/openharmony/napi_generator/blob/master/examples/cfg.json)
|
||||
|
||||
3.自动配置业务代码使用的业务代码用例
|
||||
|
||||
业务代码用例如下：
|
||||
|
||||
serviceCode/NodeISayHello.h
|
||||
|
||||
[NodeISayHello.h](https://gitee.com/openharmony/napi_generator/blob/master/examples/serviceCode/NodeISayHello.h)
|
||||
|
||||
serviceCode/NodeISayHello.cpp
|
||||
|
||||
[NodeISayHello.cpp](https://gitee.com/openharmony/napi_generator/blob/master/examples/serviceCode/NodeISayHello.cpp)
|
||||
|
||||
### 可执行程序使用方法
|
||||
|
||||
#### Linux
|
||||
|
||||
1.将待转换的.d.ts文件、napi_generator-linux、依赖文件basic.d.ts、 配置文件cfg.json、业务代码文件夹serviceCode（其中serviceCode目录下放置业务代码的.h文件和.cpp文件）放在同级目录下。此处新建generatorCode文件夹，用于存放生成框架代码。整体目录文件如下：
|
||||
|
||||
OpenHarmony@Ubuntu-64:~/service$ ls
|
||||
napi_generator-linux @ohos.napitest.d.ts basic.d.ts generatorCode cfg.json serviceCode
|
||||
|
||||
2.在终端中进入到之前可执行程序napi_generator-linux所在的目录，并运行napi_generator-linux，命令如下：
|
||||
|
||||
OpenHarmony@Ubuntu-64:~/service$ ./napi_generator-linux -f @ohos.napitest.d.ts -o generatorCode -i false -n int -s cfg.json
|
||||
|
||||
其中，参数详情如下：
|
||||
|
||||
-f, 待转换的.d.ts文件，若同时转换多个文件，文件之间用“,”隔开；
|
||||
|
||||
-d, 根据指定路径转换该文件夹中所有.d.ts文件；
|
||||
|
||||
-i, 可选参数，默认false，待转换.d.ts文件中引用非basic.d.ts的ts文件时打开开关；
|
||||
|
||||
-o, 可选参数，默认为当前目录，指定生成框架代码输出路径；
|
||||
|
||||
-n, 可选参数，默认为uint32_t，指定生成框架代码中number类型全部为指定类型；
|
||||
|
||||
-s, 可选参数，默认为不配置业务代码，指定生成框架代码的业务配置文件，用于粘合工具代码和业务代码的配置。
|
||||
|
||||
备注1：-f与-d两个参数只选其中一个参数即可。
|
||||
|
||||
备注2：若.d.ts文件中声明了basic.d.ts文件，将basic.d.ts文件放置在待转换.d.ts文件同一级目录；若除此之外还声明其它.d.ts文件，将此类文件放置在待转换.d.ts文件同级目录。
|
||||
|
||||
其中，cfg.json内容如下：
|
||||
|
||||
```
|
||||
[
|
||||
{
|
||||
"genPath": "/home/kaihong1/napi/myCommitNapiTest/generatorCode",
|
||||
"includeName": "../serviceCode/NodeISayHello.h",
|
||||
"cppName": "../serviceCode/NodeISayHello.cpp",
|
||||
"interfaceName": "funcTest",
|
||||
"serviceCode": "out = napitest::funcTest(v);"
|
||||
"description": "includeName: 引入的业务代码.h文件相对路径, cppName: 引入的业务代码.cpp文件相对路径, interfaceName: ts文件中的使用接口名,业务代码就在该接口中调用;格式为：类名::方法名(如: TestClass::funcTest1)，若无类名，则格式为：方法名(如： funcTest), serviceCode: 在接口中调用业务代码的调用语句。（该属性只做注释使用）"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
cfg.json是一个数组，每一项配置对应一个方法的调用，需要对多少方法进行调用就配置多少项；其中
|
||||
|
||||
"genPath": 生成框架代码路径，用户的业务代码相对于该路径配置，如："/home/kaihong1/napi/myCommitNapiTest/generatorCode"
|
||||
|
||||
"includeName": 引入的业务代码.h文件相对路径, 如："../serviceCode/NodeISayHello.h",
|
||||
|
||||
"cppName": 引入的业务代码.cpp文件相对路径, 如："../serviceCode/NodeISayHello.cpp",
|
||||
|
||||
"interfaceName": ts文件中的使用接口名,业务代码就在该接口中调用;格式为：类名::方法名(如: TestClass::funcTest1)，若无类名，则格式为：方法名(如： funcTest),
|
||||
|
||||
"serviceCode": 在接口中调用业务代码的调用语句。此处调用的是实现该接口的业务代码， 如："out = napitest::funcTest(v);",
|
||||
|
||||
"description": 仅作为cfg.json文件中描述其它字段含义的属性，用户配置时，可以不用填写这个字段
|
||||
|
||||
3.运行成功后会在generatorCode目录下生成框架代码文件，如下所示：
|
||||
|
||||
OpenHarmony@Ubuntu-64:~/linshi/napi_generator_8/examples/ts/generatorCode$ ls
|
||||
binding.gyp BUILD.gn napi_gen.log napitest.cpp napitest.h napitest_middle.h napitest_middle.cpp test.sh tool_utility.cpp tool_utility.h
|
||||
|
||||
#### Windows
|
||||
|
||||
1.将待转换的.d.ts文件、napi_generator-win.exe、 配置文件cfg.json、依赖文件basic.d.ts、业务代码文件夹serviceCode（其中serviceCode目录下放置业务代码的.h文件和.cpp文件）放在同级目录下。此处新建generatorCode文件夹，用于存放生成框架代码。整体目录文件如下：
|
||||
|
||||
E:\demo\napi>dir /B
|
||||
@ohos.napitest.d.ts
|
||||
basic.d.ts
|
||||
napi_generator-win.exe
|
||||
generatorCode
|
||||
cfg.json
|
||||
serviceCode
|
||||
|
||||
2.在终端中进入到之前可执行程序napi_generator-win.exe所在的目录，并运行napi_generator-win.exe，命令如下：
|
||||
|
||||
E:\demo\napi>napi_generator-win.exe -f @ohos.napitest.d.ts -o generatorCode -i false -n double -s cfg.json
|
||||
|
||||
其中，参数详情如下：
|
||||
|
||||
-f, 待转换的.d.ts文件，若同时转换多个文件，文件之间用“,”隔开；
|
||||
|
||||
-d, 根据指定路径转换该文件夹中所有.d.ts文件；
|
||||
|
||||
-i, 可选参数，默认false，待转换.d.ts文件中引用非basic.d.ts的ts文件时打开开关；
|
||||
|
||||
-o, 可选参数，默认为当前目录，指定生成框架代码输出路径；
|
||||
|
||||
-n, 可选参数，默认为uint32_t，指定生成框架代码中number类型全部为指定类型；
|
||||
|
||||
-s, 可选参数，默认为不配置业务代码，指定生成框架代码的业务配置文件，用于粘合工具代码和业务代码的配置。
|
||||
|
||||
备注1：-f与-d两个参数只选其中一个参数即可。
|
||||
|
||||
备注2：若.d.ts文件中声明了basic.d.ts文件，将basic.d.ts文件放置在待转换.d.ts文件同一级目录；若除此之外还声明其它.d.ts文件，将此类文件放置在待转换.d.ts文件同级目录。
|
||||
|
||||
其中，cfg.json内容如下：
|
||||
|
||||
```
|
||||
[
|
||||
{
|
||||
"genPath": "E:\\napi_aboutTest\\testcase_napi_intellijPlugin\\generatorCode",
|
||||
"includeName": "../serviceCode/NodeISayHello.h",
|
||||
"cppName": "../serviceCode/NodeISayHello.cpp",
|
||||
"interfaceName": "funcTest",
|
||||
"serviceCode": "out = napitest::funcTest(v);"
|
||||
"description": "includeName: 引入的业务代码.h文件相对路径, cppName: 引入的业务代码.cpp文件相对路径, interfaceName: ts文件中的使用接口名,业务代码就在该接口中调用;格式为：类名::方法名(如: TestClass::funcTest1)，若无类名，则格式为：方法名(如： funcTest), serviceCode: 在接口中调用业务代码的调用语句。（该属性只做注释使用）"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
cfg.json是一个数组，每一项配置对应一个方法的调用，需要对多少方法进行调用就配置多少项；其中
|
||||
|
||||
"genPath": 生成框架代码路径，用户的业务代码相对于该路径配置，如："E:\\napi_aboutTest\\testcase_napi_intellijPlugin\\generatorCode"
|
||||
|
||||
"includeName": 引入的业务代码.h文件相对路径, 如："../serviceCode/NodeISayHello.h",
|
||||
|
||||
"cppName": 引入的业务代码.cpp文件相对路径, 如："../serviceCode/NodeISayHello.cpp",
|
||||
|
||||
"interfaceName": ts文件中的使用接口名,业务代码就在该接口中调用;格式为：类名::方法名(如: TestClass::funcTest1)，若无类名，则格式为：方法名(如： funcTest),
|
||||
|
||||
"serviceCode": 在接口中调用业务代码的调用语句。此处调用的是实现该接口的业务代码， 如："out = napitest::funcTest(v);",
|
||||
|
||||
"description": 仅作为cfg.json文件中描述其它字段含义的属性，用户配置时，可以不用填写这个字段
|
||||
|
||||
3.运行成功后会在generatorCode目录下生成框架代码文件，如下所示：
|
||||
|
||||
E:\demo\napi\generatorCode>dir /B
|
||||
binding.gyp
|
||||
BUILD.gn
|
||||
napitest.cpp
|
||||
napitest.h
|
||||
napitest_middle.h
|
||||
napitest_middle.cpp
|
||||
napi_gen.log
|
||||
test.sh
|
||||
tool_utility.cpp
|
||||
tool_utility.h
|
||||
|
||||
#### Mac
|
||||
|
||||
方法步骤参考windows、Linux的使用方法。
|
||||
|
||||
### 不配置cfg.json文件生成框架代码
|
||||
|
||||
若用户想手动配置业务代码，可不配置cfg.json文件生成框架代码之后手动增加业务代码，不配置cfg.json文件生成框架代码说明如下：
|
||||
|
||||
[不配置cfg.json生成框架代码说明](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/ADD_SERVICECODE_INSTRUCTION.md)
|
||||
|
||||
### VS Code插件使用方法
|
||||
|
||||
具体的插件使用步骤，可以左键单击以下链接了解：
|
||||
|
||||
[VS插件使用说明](https://gitee.com/openharmony/napi_generator/blob/master/napi_vs_plugin/docs/napi/INSTRUCTION_ZH.md)
|
||||
|
||||
### DevEco Studio上使用的IntelliJ插件使用方法
|
||||
|
||||
具体的插件使用步骤，可以左键单击以下链接了解：
|
||||
|
||||
[DevEco Studio上使用的IntelliJ插件使用说明](https://gitee.com/openharmony/napi_generator/blob/master/napi_IntelliJ_plugin/docs/napi/INSTRUCTION_ZH.md)
|
||||
|
||||
## 集成测试
|
||||
NAPI框架代码生成后，系统框架开发者进行二次开发后，即可集成到OpenHarmony编译系统，生成对应的库文件，供应用开发者调用接口。工具集成测试的具体操作步骤可以左键单击以下链接了解：
|
||||
|
||||
[工具集成测试](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/INTEGRATION_TESTING_ZH.md)
|
||||
|
||||
274
docs/guide/INTEGRATION_TESTING_ZH.md
Normal file
274
docs/guide/INTEGRATION_TESTING_ZH.md
Normal file
@ -0,0 +1,274 @@
|
||||
# NAPI框架生成工具集成测试
|
||||
|
||||
## 简介
|
||||
本文主要介绍如何将NAPI框架生成代码集成到OpenHarmony系统，进而进行集成测试。
|
||||
|
||||
## 准备
|
||||
|
||||
1.硬件：rk3568开发套件。
|
||||
|
||||
2.系统镜像：
|
||||
|
||||
系统镜像的具体生成方法，可以左键单击以下链接了解：
|
||||
|
||||
[生成代码集成到OpenHarmony](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/ENSEMBLE_METHOD_ZH.md)
|
||||
|
||||
3.应用hap包：hap包及源码路径如下：
|
||||
|
||||
```
|
||||
napi_generator/examples/app
|
||||
```
|
||||
|
||||
hap包的具体生成方法，可参考OpenHarmony/docs/zh-cn/application-dev文档中使用ArkTS语言开发（Stage模型）。
|
||||
### 修改点1：扩展SDK接口
|
||||
1. 查看SDK目录：打开DevEco Studio ，点击 Tools -> SDK Manager -> SDK
|
||||
|
||||
|
||||
|
||||
2. 将@ohos.napitest.d.ts文件拷贝到应用所使用的sdk目录下 的ets\api
|
||||
|
||||
|
||||
|
||||
### 修改点2：增加新接口调用
|
||||
其中修改index.ets文件内容如下：
|
||||
|
||||
[Index.ets](https://gitee.com/openharmony/napi_generator/blob/master/examples/Index.ets)
|
||||
|
||||
关键代码说明：
|
||||
|
||||
1.定义回调：
|
||||
|
||||
1.1 定义object回调
|
||||
|
||||
```
|
||||
class NodeISayHelloListenerImpl {
|
||||
onSayHelloStart(info: object) {
|
||||
console.log('napiTestDemo ----onSayHelloStart', info);
|
||||
AppStorage.SetOrCreate("textInfoStart", JSON.stringify(info))
|
||||
}
|
||||
onSayHelloEnd(info: object) {
|
||||
console.log('napiTestDemo ----onSayHelloEnd.', info);
|
||||
AppStorage.SetOrCreate("textInfoEnd", JSON.stringify(info))
|
||||
}
|
||||
}
|
||||
let listener: NodeISayHelloListenerImpl = new NodeISayHelloListenerImpl()
|
||||
```
|
||||
|
||||
1.2 定义register注册的回调
|
||||
|
||||
```
|
||||
function onCallbackfunnm(wid: number) {
|
||||
AppStorage.SetOrCreate("callBackNum", JSON.stringify(wid))
|
||||
console.info("wid = " + wid)
|
||||
return "ocCallbackfuncnm";
|
||||
}
|
||||
```
|
||||
|
||||
2.注册回调：
|
||||
|
||||
2.1 addXXX注册object回调
|
||||
|
||||
```
|
||||
ns.addSayHelloListener(listener);
|
||||
```
|
||||
|
||||
2.2 registerXXX注册回调
|
||||
|
||||
```
|
||||
ns.registerCallbackfunc(onCallbackfunnm);
|
||||
```
|
||||
|
||||
3.调用回调：
|
||||
|
||||
3.1 调用sayHello普通函数，该函数业务实现会调用注册的object回调
|
||||
|
||||
```
|
||||
ns.sayHello("js1", "native1", napitest.SayType.kInitiative);
|
||||
```
|
||||
|
||||
调用成功后，打印传入的参数
|
||||
|
||||
```
|
||||
I C02e00/NAPITESTNAPILayer: [NodeISayHello.cpp:37] NAPITEST_LOGI sayHello from = js1
|
||||
I C02e00/NAPITESTNAPILayer: [NodeISayHello.cpp:38] NAPITEST_LOGI sayHello to = native1
|
||||
I C02e00/NAPITESTNAPILayer: [NodeISayHello.cpp:39] NAPITEST_LOGI sayHello sayType = 0
|
||||
```
|
||||
|
||||
js层打印回调数据
|
||||
|
||||
```
|
||||
A03d00/JSAPP: napiTestDemo ----onSayHelloStart {"from":"js1","fromId":992,"to":"native1","toId":1014,"content":"hello1","saidTime":"123456789","isEnd":false}
|
||||
...
|
||||
A03d00/JSAPP: napiTestDemo ----onSayHelloEnd. {"from":"native","fromId":101,"to":"js","toId":99,"content":"hello","saidTime":"987654321","isEnd":true}
|
||||
```
|
||||
|
||||
3.2 调用sayHi普通函数，该函数业务实现会调用register注册的object回调
|
||||
|
||||
```
|
||||
ns.sayHi("js3", "native3", napitest.SayType.kResponse);
|
||||
```
|
||||
|
||||
调用成功后，打印传入的参数
|
||||
|
||||
```
|
||||
I C02e00/NAPITESTNAPILayer: sayHi:81 NAPITEST_LOGI sayHi from = js3
|
||||
I C02e00/NAPITESTNAPILayer: sayHi:82 NAPITEST_LOGI sayHi to = native3
|
||||
I C02e00/NAPITESTNAPILayer: sayHi:83 NAPITEST_LOGI sayHi sayType = 1
|
||||
```
|
||||
|
||||
js层打印回到数据
|
||||
|
||||
```
|
||||
I A03d00/JSAPP: napiTestDemo ----onCallbackfunnm wid = 50
|
||||
```
|
||||
|
||||
4.注销回调：
|
||||
|
||||
4.1 removeXXX注销object回调
|
||||
|
||||
```
|
||||
ns.removeSayHelloListener(listener);
|
||||
```
|
||||
|
||||
注销回调后再次调用sayHello方法，js层将无法再打印出回调数据
|
||||
|
||||
```
|
||||
ns.sayHello("js2", "native2", napitest.SayType.kInitiative);
|
||||
```
|
||||
|
||||
4.2 unRegisterXXX注销回调
|
||||
|
||||
```
|
||||
ns.unRegisterCallbackfunc(onCallbackfunnm);
|
||||
```
|
||||
|
||||
注销回调后再次调用sayHi方法，js层将无法再打印出回调数据
|
||||
|
||||
```
|
||||
ns.sayHi("js4", "native4", napitest.SayType.kResponse);
|
||||
```
|
||||
|
||||
5.调用Promise回调
|
||||
|
||||
```
|
||||
await ns.sayHelloWithResponse("response from", "response to", napitest.SayType.kResponse).then((ret: object) => {
|
||||
this.promiseRes = JSON.stringify(ret);
|
||||
console.info("napiTestDemo ----sayHelloWithResponse ret = " + JSON.stringify(ret));
|
||||
});
|
||||
```
|
||||
|
||||
调用成功后，打印传入的参数
|
||||
|
||||
```
|
||||
I C02e00/NAPITESTNAPILayer: sayHelloWithResponse:107 NAPITEST_LOGI sayHelloWithResponse from = response from
|
||||
I C02e00/NAPITESTNAPILayer: sayHelloWithResponse:108 NAPITEST_LOGI sayHelloWithResponse to = response to
|
||||
I C02e00/NAPITESTNAPILayer: sayHelloWithResponse:109 NAPITEST_LOGI sayHelloWithResponse sayType = 1
|
||||
```
|
||||
|
||||
js层打印promise回调数据
|
||||
|
||||
```
|
||||
I A03d00/JSAPP: napiTestDemo ----sayHelloWithResponse ret = {"result":0,"errMsg":"","response":""}
|
||||
```
|
||||
|
||||
6.调用普通方法funcTest
|
||||
|
||||
```
|
||||
this.returnVal = napitest.funcTest(false);
|
||||
console.info("napiTestDemo ----funcTest returnVal = " + this.returnVal)
|
||||
```
|
||||
|
||||
调用成功后，在js层打印返回值
|
||||
|
||||
```
|
||||
I A03d00/JSAPP: napiTestDemo ----funcTest returnVal = "ret is false"
|
||||
```
|
||||
|
||||
7.Text打印数据说明
|
||||
|
||||
|
||||
```
|
||||
// 调用sayHelloWithResponse后保存promise回调数据
|
||||
Text('promise回调: promiseResult = ' + this.promiseRes).margin({ top: 10 })
|
||||
// 调用sayHello方法后保留addXXX注册的回调方法数据
|
||||
Text('sayHelloStart回调: info = ' + this.textInfoStart).margin({ top: 10 })
|
||||
Text('sayHelloEnd回调: info = ' + this.textInfoEnd).margin({ top: 10 })
|
||||
// 调用sayHi方法后保留registerXXX注册的回调方法数据
|
||||
Text('register注册的回调： wid = ' + this.callBackNum).margin({ top: 10 })
|
||||
// 调用fucnTest方法后保存返回值
|
||||
Text('普通方法funcTest返回值： returnVal = ' + this.returnVal).margin({ top: 10 })
|
||||
```
|
||||
|
||||
## 使用说明
|
||||
|
||||
步骤一：安装镜像环境：将out/rk3568/packages/phone目录下的images镜像文件下载并烧录到开发板上。
|
||||
|
||||
OpenHarmony@Ubuntu-64:~/OpenHarmony/out/rk3568/packages/phone/images$ ll
|
||||
total 767452
|
||||
drwxrwxrwx 2 root root 4096 Nov 21 05:32 ./
|
||||
drwxrwxrwx 15 root root 4096 Nov 21 05:32 ../
|
||||
-rwxrwxrwx 1 root root 67108864 Nov 21 05:04 boot_linux.img*
|
||||
-rw-r--r-- 1 root root 52428800 Nov 21 05:32 chip_prod.img
|
||||
-rwxrwxrwx 1 root root 8569 Nov 21 05:04 config.cfg*
|
||||
-rw-r--r-- 1 root root 12582912 Nov 21 05:32 eng_system.img
|
||||
-rwxrwxrwx 1 root root 455104 Nov 21 05:04 MiniLoaderAll.bin*
|
||||
-rwxrwxrwx 1 root root 756 Nov 21 05:04 parameter.txt*
|
||||
-rw-rw-r-- 1 root root 2507625 Nov 21 05:32 ramdisk.img
|
||||
-rwxrwxrwx 1 root root 5639680 Nov 21 05:04 resource.img*
|
||||
-rw-r--r-- 1 root root 52428800 Nov 21 05:32 sys_prod.img
|
||||
-rw-r--r-- 1 root root 1610608640 Nov 21 05:32 system.img
|
||||
-rwxrwxrwx 1 root root 4194304 Nov 21 05:04 uboot.img*
|
||||
-rw-rw-r-- 1 root root 15806303 Nov 21 05:32 updater.img
|
||||
-rw-r--r-- 1 root root 1468006400 Nov 21 05:32 userdata.img
|
||||
-rw-r--r-- 1 root root 268431360 Nov 21 05:32 vendor.img
|
||||
|
||||
步骤二：安装hap包。
|
||||
|
||||
Build Haps通过后，通过Run按钮将hap包安装到板子上。
|
||||
|
||||
执行完成后，设备中会出现安装的APP。
|
||||
|
||||
步骤三：打印日志并验证结果。
|
||||
|
||||
hap包安装成功后，进入hdc shell
|
||||
|
||||
首先执行以下命令关闭hilog隐私权限
|
||||
|
||||
```
|
||||
hilog -p off
|
||||
```
|
||||
|
||||
输入命令实时打印日志并输出至windows中。
|
||||
|
||||
.\hdc.exe hilog > log.txt
|
||||
|
||||
然后单击设备中安装的APP，进入APP后单击测试按钮，执行完成后会在hdc安装目录下出现log.txt文件。
|
||||
|
||||
## 查看结果
|
||||
|
||||
log.txt中包含"NAPITEST_LOGI..."相关日志即为接口调用成功，如：
|
||||
|
||||
```
|
||||
I C02e00/NAPITESTNAPILayer: [NodeISayHello.cpp:37] NAPITEST_LOGI sayHello from = js1
|
||||
I C02e00/NAPITESTNAPILayer: [NodeISayHello.cpp:38] NAPITEST_LOGI sayHello to = native1
|
||||
I C02e00/NAPITESTNAPILayer: [NodeISayHello.cpp:39] NAPITEST_LOGI sayHello sayType = 0
|
||||
I C02e00/NAPITESTNAPILayer: [NodeISayHello.cpp:64] NAPITEST_LOGI NodeISayHelloListener_onSayHelloStartCallback begin
|
||||
I C02e00/NAPITESTNAPILayer: [NodeISayHello.cpp:66] NAPITEST_LOGI NodeISayHelloListener_onSayHelloStartCallback end
|
||||
...
|
||||
```
|
||||
|
||||
点击“注册object回调后SayHello调用回调”按钮，sayHelloStart回调info和sayHelloEnd回调info会显示出C++传到js层的回调数据；
|
||||
|
||||
点击“注销object回调后SayHello调用回调”按钮，sayHelloStart回调info和sayHelloEnd回调info会显示出数据为空，即该回调已注销，C++无法调用回调，显示的为应用赋的空值；
|
||||
|
||||
点击“Promise 回调”按钮，Promise回调的errMsg, result, response会出现C++传到js层的回调数据；
|
||||
|
||||
点击“register回调后SayHi调用回调”按钮，register注册的回调会显示出wid = 50, wid值为C++传到js的回调数据；
|
||||
|
||||
点击“unRegister回调后SayHi调用回调”按钮，register注册的回调会显示出wid 为空，即该回调已注销，C++无法调用回调，显示的为应用赋的空值；
|
||||
|
||||
点击”调用funcTest方法“按钮，普通方法funcTest返回值显示出 returnVal = ret is false。
|
||||
|
||||
## 相关仓
|
||||
|
||||
暂无
|
||||
44
docs/guide/ROADMAP_ZH.md
Normal file
44
docs/guide/ROADMAP_ZH.md
Normal file
@ -0,0 +1,44 @@
|
||||
# NAPI框架代码生成工具
|
||||
|
||||
## 版本规划
|
||||
|
||||
2024.03.30提供1.4.1版本 基本完善工具C++支持能力,具体特性见表1。
|
||||
|
||||
**表 1** 2024.03.30待支持特性
|
||||
|
||||
<a name="table143385853320"></a>
|
||||
|
||||
<table><thead align="left"><tr id="row53375863312"><th class="cellrowborder" valign="top" width="25%" id="mcps1.2.3.1.1"><p id="p20331858193317"><a name="p20331858193317"></a><a name="p20331858193317"></a>类别</p>
|
||||
</th>
|
||||
<th class="cellrowborder" valign="top" width="45%" id="mcps1.2.3.1.2"><p id="p1133115820331"><a name="p1133115820331"></a><a name="p1133115820331"></a>待开发特性</p>
|
||||
</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody><tr id="row333115812331"><td class="cellrowborder" valign="top" width="25%" headers="mcps1.2.3.1.1 "><p id="p2142111345714"><a name="p2142111345714"></a><a name="p2142111345714"></a>变量/返回值</p>
|
||||
</td>
|
||||
<td class="cellrowborder" valign="top" width="45%" headers="mcps1.2.3.1.2 "><a name="ul9264132010"></a><a name="ul9264132010"></a><ul id="ul9264132010"><li>支持ts接口文件中namespace域的any类型之复合类型变量转换为对应C++类型变量 </li><li>支持ts接口文件中namespace域的多中类型合并成新类型之复合类型的变量转换为对应C++类型变量</li></ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="row334175803317"><td class="cellrowborder" valign="top" width="25.77%" headers="mcps1.2.3.1.1 "><p id="p382391145710"><a name="p382391145710"></a><a name="p382391145710"></a>函数</p>
|
||||
</td>
|
||||
<td class="cellrowborder" valign="top" width="74.22999999999999%" headers="mcps1.2.3.1.2 "><a name="ul334485413318"></a><a name="ul334485413318"></a><ul id="ul334485413318"><li>支持箭头函数的参数是回调函数</li><li>支持on/off第二个参数为object</li><li>支持class中有参构造中有枚举类型</li><li>箭头回调支持异步调用</li><li>on注册回调的箭头函数支持携带js返回值给C++</li><li>支持js业务代码回调接口中的回调js函数</li><li>class2声明在class1之后时,支持class1中的有参构造的参数有class2</li></ul>
|
||||
</td>
|
||||
<tr id="row119944512385"><td class="cellrowborder" valign="top" width="25.77%" headers="mcps1.2.3.1.1 "><p id="p919862210573"><a name="p919862210573"></a><a name="p919862210573"></a>文件</p>
|
||||
</td>
|
||||
<td class="cellrowborder" valign="top" width="74.22999999999999%" headers="mcps1.2.3.1.2 "><a name="ul12374158862"></a><a name="ul12374158862"></a><ul id="ul12374158862"><li>优化VSCode插件用户界面</li><li>分离生成的工具代码普通方法和回调方法，防止嵌套使用头文件</li></ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tr>
|
||||
<tr id="row119944512385"><td class="cellrowborder" valign="top" width="25.77%" headers="mcps1.2.3.1.1 "><p id="p919862210573"><a name="p919862210573"></a><a name="p919862210573"></a>可维护性</p>
|
||||
</td>
|
||||
<td class="cellrowborder" valign="top" width="74.22999999999999%" headers="mcps1.2.3.1.2 "><a name="ul12374158862"></a><a name="ul12374158862"></a><ul id="ul12374158862"><li>增加debug信息</li></ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
## 相关链接
|
||||
|
||||
无
|
||||
72
docs/guide/SOLUTION.md
Normal file
72
docs/guide/SOLUTION.md
Normal file
@ -0,0 +1,72 @@
|
||||
# 当前已知不支持推荐方案
|
||||
|
||||
1.注册的object回调不支持箭头函数写法, 注册回调格式为addXXX，注销回调格式为removeXXX，且回调方法命名格式为onXXX, 例如:
|
||||
|
||||
```
|
||||
export interface InterfaceB {
|
||||
byClass: (listener: InterfaceA) => void;
|
||||
}
|
||||
export interface InterfaceA {
|
||||
callFunction: (res: number) => void;
|
||||
}
|
||||
```
|
||||
|
||||
修改为:
|
||||
|
||||
```
|
||||
export interface InterfaceB {
|
||||
// object注册回调, 关键字：add
|
||||
addByClass(listener: InterfaceA);
|
||||
// object注销回调, 关键字：remove
|
||||
removeByClass(listener: InterfaceA);
|
||||
}
|
||||
export interface InterfaceA {
|
||||
onCallFunction(res: number): void;
|
||||
}
|
||||
```
|
||||
|
||||
2.注册回调只能支持单个参数, 且注册单个参数的注册回调方法命名格式为registerXXX, 例如:
|
||||
|
||||
```
|
||||
export interface TestA {
|
||||
bGyClass: (a: number, callback: (result: number) => void) => number;
|
||||
}
|
||||
```
|
||||
|
||||
修改为:
|
||||
|
||||
```
|
||||
export interface TestA {
|
||||
// 原bGyClass的参数 callback: (res: number) => void 改为registerXXX/unRegisterXXX形式
|
||||
// register形式注册回调， 关键字：register
|
||||
registerTestACallback(callback: (dd: number) => void);
|
||||
// unRegister形式注销回调, 关键字：unRegister
|
||||
unRegisterTestACallback(callback: (dd: number) => void);
|
||||
// gByClass用于调用回调
|
||||
bGyClass: (a: number) => number;
|
||||
}
|
||||
```
|
||||
|
||||
3.生成报错：The current version does not support generating parameter。
|
||||
|
||||
```
|
||||
genError:at paramGenerate [C:\snapshot\napi_generator\src\gen\generate\param_generate.js(899:17)] The current version does not support generating parameter [elementName] with type [ElementName]
|
||||
```
|
||||
|
||||
ts文件为：
|
||||
|
||||
```
|
||||
import { ElementName } from './bundleManager/ElementName';
|
||||
|
||||
declare namespace cardEmulation {
|
||||
export class HceService {
|
||||
start(elementName: ElementName, aidList: string[]): void;
|
||||
stop(elementName: ElementName): void;
|
||||
}
|
||||
}
|
||||
export default cardEmulation;
|
||||
```
|
||||
|
||||
修改：
|
||||
|
||||
文件中引用了 ElementName 类型， 需要把被引用的文件( import { ElementName } from './bundleManager/ElementName'; ）放到转换路径下工具才可进行转换
|
||||
@ -114,7 +114,7 @@ export default Space;
|
||||
|
||||
[已支持特性](https://gitee.com/openharmony/napi_generator/blob/master/docs/ts/ts_Gen-1.0.md)
|
||||
|
||||
[待支持特性](https://gitee.com/openharmony/napi_generator/blob/master/docs/ts/ROADMAP_ZH.md)
|
||||
[待支持特性](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/ts/ROADMAP_ZH.md)
|
||||
|
||||
## FAQ
|
||||
|
||||
|
||||
@ -109,7 +109,7 @@ TS(type-script)接口生成工具，它可以根据定义在c++头文件中的
|
||||
|
||||
[已支持特性](https://gitee.com/openharmony/napi_generator/blob/master/docs/ts/ts_Gen-1.0.md)
|
||||
|
||||
[待支持特性](https://gitee.com/openharmony/napi_generator/blob/master/docs/ts/ROADMAP_ZH.md)
|
||||
[待支持特性](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/ts/ROADMAP_ZH.md)
|
||||
|
||||
## FAQ
|
||||
|
||||
|
||||
@ -106,7 +106,7 @@ public:
|
||||
|
||||
[已支持特性](https://gitee.com/openharmony/napi_generator/blob/master/release-notes)
|
||||
|
||||
[待支持特性](https://gitee.com/openharmony/napi_generator/blob/master/docs/ROADMAP_ZH.md)
|
||||
[待支持特性](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/ROADMAP_ZH.md)
|
||||
|
||||
## FAQ
|
||||
|
||||
|
||||
@ -71,7 +71,7 @@ bool func1(std::string& v1, std::string& out)
|
||||
|
||||
把工具的生成代码集成到OpenHarmony的具体操作步骤，可以左键单击以下链接了解：
|
||||
|
||||
[生成代码集成到OpenHarmony的方法](https://gitee.com/openharmony/napi_generator/blob/master/docs/ENSEMBLE_METHOD_ZH.md)
|
||||
[生成代码集成到OpenHarmony的方法](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/ENSEMBLE_METHOD_ZH.md)
|
||||
|
||||
## 开发说明
|
||||
|
||||
@ -95,7 +95,7 @@ bool func1(std::string& v1, std::string& out)
|
||||
|
||||
[已支持特性](https://gitee.com/openharmony/napi_generator/blob/master/release-notes)
|
||||
|
||||
[待支持特性](https://gitee.com/openharmony/napi_generator/blob/master/docs/ROADMAP_ZH.md)
|
||||
[待支持特性](https://gitee.com/openharmony/napi_generator/blob/master/docs/guide/ROADMAP_ZH.md)
|
||||
|
||||
## FAQ
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user