[quickhybrid] 구성 요소 (사용자 정의) API의 실현

전언
앞에서 API를 기획할 때 이미 구성 요소 API라는 개념을 언급한 적이 있으므로 본고는 그 원리와 실현을 소개할 것이다
어셈블리 API 개념 이해

quick.ui.xxx
quick.page.xxx

quick hybrid에서 API는 모듈에 따라 구분된다. 예를 들어 ui10page 등은 모두 다른 모듈이고 모듈의 또 다른 명칭은 이다.
왜 구성 요소라고 합니까?이렇게 이해할 수 있다. 모듈은 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 어셈블리의 예).
안드로이드

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(...);
    }];
}

별명과 경로의 관계 선언
주의해야 할 것은 안드로이드와 iOS의 별명은 일치해야 하며 일반적으로 키 값이 맞아도 된다는 것이다
예를 들어 예시 항목을 예로 들면app 모듈의 assets/modules.properties

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

같은 이치의 iOS에서도 유사하지만 오른쪽의 경로 값은 iOS의 것으로 바꿀 수 있다. 예를 들어

pay = PayApi

보시다시피 안드로이드와 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