CN112947897A

CN112947897A - Cross-platform API (application program interface) sharing method, device and system and storage medium

Info

Publication number: CN112947897A
Application number: CN201911171393.1A
Authority: CN
Inventors: 熊文源
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2019-11-26
Filing date: 2019-11-26
Publication date: 2021-06-11

Abstract

The application provides a cross-platform API sharing method, a device, a system and a storage medium, wherein the method comprises the following steps: determining a calling mode of an Application Programming Interface (API) according to the type of the application development platform; running a monitor corresponding to the target API according to the calling mode; the listener comprises a listener program compiled after abstracting the API into a function set of interface operation. The application can realize API compatibility of different application development platforms, guarantee the consistency of interface calling and reduce development cost.

Description

Cross-platform API (application program interface) sharing method, device and system and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a cross-platform API sharing method, apparatus, system, and storage medium.

Background

More and more solutions are developed across platforms, such as read Native/Weex, Flutter, etc. The framework is dependent on the basic API of the Android/IOS platform, so that when the application is developed on the platform, a plurality of native related APIs are often required to be developed to complete certain specific functions.

The calling mode and the encapsulation of the Native API by the existing Flutter and React Native are two sets of different logics. The fact Native registers all APIs to JS end by marking the fact Method. And Flutter directly tells the native terminal the name of the interface to be called through the method channel, and then the native terminal decides to call the logic according to the required name. Since the calling modes and the encapsulation logics of the flute and the read Native are different, the APIs need to be developed respectively, and the development cost is high.

Disclosure of Invention

The application provides a cross-platform API sharing method, device, system and storage medium, API compatibility of different application development platforms can be achieved, consistency of interface calling is guaranteed, and development cost is reduced.

In a first aspect, an embodiment of the present application provides a cross-platform API sharing method, including:

determining a calling mode of an Application Programming Interface (API) according to the type of the application development platform;

running a monitor corresponding to the target API according to the calling mode; the listener comprises a listener program compiled after abstracting the API into a function set of interface operation.

In one possible design, determining a calling mode of an application programming interface API according to a type of an application development platform includes:

if the application development platform is reach Native, calling the target API by adopting a reach marking method;

and if the application development platform is the Flutter, calling the target API through a Flutter unified calling interface, wherein the Flutter unified calling interface is used for establishing a mapping relation between the target API and the corresponding monitor.

In one possible design, the calling the target API using the React flag method includes:

registering a module method in an React interface management object, wherein the module method is used for declaring an API as a React marking method and registering a listener corresponding to the React marking method;

establishing mutual calling between the module method and the JS through the JS communication bridge;

and calling the listener corresponding to the target API through a React marking method in the module method.

In one possible design, the calling the target API through the Flutter unified call interface includes:

defining a Flutter unified calling interface in a Flutter framework;

and calling the listener corresponding to the target API through a Flutterer unified calling interface.

In a possible design, before the calling the listener corresponding to the target API through the Flutter unified call interface, the method further includes:

storing the mapping interface into a cached table in a way of using a flute method key word;

registering a Flutter interface call-back registration center by using a Flutter method keyword;

when a method for calling a key word to an object is called, a corresponding Flutter unified calling interface is found from a cache according to the value of the key word, and data is converted into a table and a method and then transmitted to the Flutter unified calling interface.

In one possible design, further comprising:

and feeding back the running result of the monitor to a Flutter result callback interface through a Flutter unified calling interface so that the Flutter result callback interface feeds back the running result to a calling end.

In a second aspect, an embodiment of the present application provides a cross-platform API sharing apparatus, including:

the determining module is used for determining a calling mode of an Application Programming Interface (API) according to the type of the application development platform;

the calling module is used for operating the listener corresponding to the target API according to the calling mode; the listener comprises a listener program compiled after abstracting the API into a function set of interface operation.

In one possible design, the determining module is specifically configured to:

defining a Flutter unified calling interface in a Flutter framework;

In one possible design, further comprising:

the cache module is used for storing the mapping interface into a cached table in a way of a Flutter method keyword before the listener corresponding to the target API is called through a Flutter unified call interface;

the registration module is used for registering a Flutter interface callback registration center by using a Flutter method keyword;

and the transmission module is used for finding the corresponding Flutter unified calling interface from the cache according to the value of the key word when the method for calling the key word to the object is called, converting the data into the table and the method, and then transmitting the table and the method to the Flutter unified calling interface.

In one possible design, further comprising:

and the feedback module is used for feeding back the running result of the monitor to the Flutter result callback interface through the Flutter unified calling interface so that the Flutter result callback interface feeds the running result back to the calling end.

In a third aspect, an embodiment of the present application provides a cross-platform API sharing system, including: the device comprises a memory and a processor, wherein the memory stores executable instructions of the processor; wherein the processor is configured to perform the cross-platform API sharing method of any of the first aspects via execution of the executable instructions.

In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, which when executed by a processor implements the cross-platform API sharing method described in any one of the first aspects.

In a fifth aspect, an embodiment of the present application provides a program product, where the program product includes: a computer program stored in a readable storage medium from which at least one processor of a server can read the computer program, execution of the computer program by the at least one processor causing the server to perform the cross-platform API sharing method of any one of the first aspects.

The application provides a cross-platform API sharing method, a device, a system and a storage medium, wherein a calling mode of an Application Programming Interface (API) is determined according to the type of an application development platform; running a monitor corresponding to the target API according to the calling mode; the listener comprises a listener program compiled after abstracting the API into a function set of interface operation. Therefore, API compatibility of different application development platforms can be realized, the consistency of interface calling is ensured, and the development cost is reduced.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to these drawings without inventive exercise.

FIG. 1 is a schematic diagram of an application scenario of the present application;

FIG. 2 is a flowchart of a cross-platform API sharing method according to an embodiment of the present disclosure;

fig. 3 is a schematic structural diagram of a cross-platform API sharing apparatus according to a second embodiment of the present application;

fig. 4 is a schematic structural diagram of a cross-platform API sharing system according to a third embodiment of the present application.

With the foregoing drawings in mind, certain embodiments of the disclosure have been shown and described in more detail below. These drawings and written description are not intended to limit the scope of the disclosed concepts in any way, but rather to illustrate the concepts of the disclosure to those skilled in the art by reference to specific embodiments.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The technical solution of the present application will be described in detail below with specific examples. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments.

In the following, some terms in the present application are explained to facilitate understanding by those skilled in the art:

1) flutter is a set of brand-new cross-platform, open-source UI framework developed by Google, supports iOS and Android system development, and is a default development suite of a new future operating system Fuchsia. The goal of Flutter is to have the same set of code running on both the Android and iOS systems and to have performance comparable to native applications, Flutter even provides two sets of controls to adapt the Android and iOS (scroll effects, fonts and control icons, etc.) in order for App to look more like native applications at the details.

2) The fact Native (RN) is a cross-platform mobile application development framework sourced from Facebook in 2015 4, and is a derivative product of JS framework React sourced from Facebook in the Native mobile application platform, and currently supports iOS and android platforms. The RN develops mobile applications using the Java script language, JSX similar to HTML, and CSS, so those familiar with Web front-end development need little learning to enter the field of mobile application development.

In order to solve the above problems, the present application provides a cross-platform API sharing method, apparatus, system, and storage medium, which can implement API compatibility of different application development platforms, ensure consistency of interface calling, and reduce development cost. Fig. 1 is a schematic diagram of an application scenario of the present application, and as shown in fig. 1, a set of new interfaces is defined in the present solution to separate and abstract the Flutter and the read Native interfaces into several layers, so as to achieve unification of the interfaces. From bottom to top are Core API layer, Jd exact frame layer, SDK layer, service API layer.

The concrete functions of the Core API layer (Core API) are completed, so that a developer only needs to care about the functions of the API and does not need to worry about the problem of interface inconsistency and redevelopment caused by cross-framework. When a developer writes a Native API, the APIs need to be abstracted into interfaces (interfaces) and implemented into listeners (listeners), and the set of APIs which are completely independent of the Flutter and the read Native realize the abstract interfaces and are provided for two ends for use later.

Above the core API, a jd exact frame layer can be defined, i.e. an abstraction layer for smoothing the interface inconsistency on both sides. And for the application development platform being React Native, a module method (Moudel API) needs to be added, all APIs are declared to be React marking methods, and a function set (interface) of interface operation mentioned in core API is registered, so that all React marking methods uniformly call a method corresponding to the function set of interface operation. Because the module method is effective and must be registered in the React interface management object for registration, a listener (listener) corresponding to the module method needs to be registered together during registration, and the module method can be directly called to the listener for specific implementation after corresponding API is called. If the application development platform is the Flutter, a new unified Call interface (JD Flutter Call) can be defined and abstracted in the JD interact frame layer. A Method Call Handler (Method Call Handler) for defining and implementing Flutter becomes a standard interface (JD Flutter Method Call Handler, also called Flutter interface callback registry). This setting is mainly to unify all Flutter interfaces, so that developers are not concerned about the implementation of the Flutter interfaces.

Optionally, above the jd exact frame layer, there may be an SDK layer as a bridge between the service API layer and the defined jd exact frame layer. And for the application development platform being reach Native, establishing mutual calling between the module method and the JS through the JS communication bridge, and calling the listener corresponding to the target API through the reach marking method in the module method. If the application development platform is the Flutter, the interaction between the service API layer and the jd exact frame work layer is realized by adopting a method channel. And when the service is called, maintaining the cache of all the realized Flutter unified calling interfaces. For example, it may be stored in a table (map) and then saved according to a Flutter method key (method channel key). And (5) injecting keywords of the Flutter method into the surface and the inner surface. In specific implementation, the interface is registered in the Flutter View, after the call is received, the corresponding Flutter unified call interface is found in the cache according to the corresponding key words, and the method and the parameters in the Flutter unified call interface are transmitted to the Flutter unified call interface.

Optionally, the top layer is set as a service API layer, and is consistent with the original architecture implementation. And then determining the calling mode of the application programming interface API according to the type of the application development platform. And finally, running a listener corresponding to the target API according to the calling mode, thereby realizing the cross-platform API sharing.

The following describes the technical solutions of the present application and how to solve the above technical problems with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.

Fig. 2 is a flowchart of a cross-platform API sharing method provided in an embodiment of the present application, and as shown in fig. 2, the method in this embodiment may include:

s101, determining a calling mode of an Application Programming Interface (API) according to the type of the application development platform.

In this embodiment, when a service needs to call an API, a calling mode of an application programming interface API is determined according to the type of the application development platform. If the application development platform is reach Native, calling a target API by adopting a reach marking method; and if the application development platform is the Flutter, calling the target API through a Flutter unified calling interface, wherein the Flutter unified calling interface is used for establishing a mapping relation between the target API and the corresponding monitor.

Specifically, the scheme defines a set of new interfaces for separating and abstracting the Flutter and the read Native interfaces into a plurality of layers, so as to realize the unification of the interfaces. From bottom to top, a core API layer, a Jd exact frame layer, an SDK layer and a service API layer are respectively arranged. Finally, the function of the API is completed in the core API, so that a developer only needs to care about the function of the API and does not need to worry about the problem of interface inconsistency and redevelopment caused by cross-framework. When a developer writes native APIs, these APIs need to be abstracted into interfaces (interfaces) and implemented into listeners (listeners). The core API is a concrete function to be realized, an abstract interface is defined to contain a group of functional APIs to be realized, and the group of independent API functions are realized in the listener.

Since all APIs of the read Native are implemented by implementing the Java class read Context Base Java Module, and all APIs exposed to JS are marked with @ read Method, in order to maintain the consistency of the APIs on both sides, it is necessary to register a previously declared listener in the Module and call back this listener in all marked methods. Therefore, when the business needs to call the API, if the application development platform is reach Native, the @ reach Method is adopted to call the target API.

The interface of Flutter is realized by implementing an on Method Call in a Method Call Handler, and the on Method Call tells the native terminal to Call the API name, which is mapped by the native terminal. Therefore, the Flutter end can abstract a new unified calling interface for realizing the mapping of all the APIs without depending on any Flutter and realizing the interface in the listener. Therefore, when the service needs to call the API, if the application development platform is Flutter, the target API is called through the new unified call interface.

Optionally, calling the target API by using a read marking method includes: registering a module method in the React interface management object, wherein the module method is used for declaring the API as a React marking method and registering a listener corresponding to the React marking method; through the mutual calling between the JS communication bridge building module method and the JS; and calling the listener corresponding to the target API through a React marking method in the module method.

Specifically, above the core API, a jd exact frame layer may be defined, that is, an abstraction layer for floating the interface inconsistency between the two sides. And (3) for an application development platform which is real Native, a newly added module (move) is needed, all APIs are declared to be the real marking methods, interfaces mentioned in core APIs are registered, and all the real marking methods call methods corresponding to the interfaces uniformly. Because the newly added module is effective and must be registered in the read interface management object, the corresponding listeners of the module need to be registered together during registration, and the corresponding API in the module can be directly called to the specific implementation in the listener after calling. Above the jd exact frame layer, there may be an SDK layer, which is a bridge between the service API layer and the defined jd exact frame layer. And for the application development platform being reach Native, establishing mutual calling between the module method and the JS through the JS communication bridge, and calling the listener corresponding to the target API through the reach marking method in the module method.

Optionally, the invoking the target API through the Flutter unified call interface includes: defining a Flutter unified calling interface in a Flutter framework; and calling the listener corresponding to the target API through the Flutter unified calling interface.

Specifically, if the application development platform is Flutter, a new unified call interface can be defined and abstracted in the jd interact frame layer. The method call handler of Flutter is defined and implemented as a standard interface. And in the SDK layer, a method channel is adopted to realize the interaction between the service API layer and the jd exact frame layer. When the service is called, the cache of all the implemented Flutter unified calling interfaces is maintained, and the cache can be stored in a table and is stored according to the key words of the Flutter method. In specific implementation, the interface is registered in the Flutter View, after the call is received, the corresponding Flutter unified call interface is found in the cache according to the corresponding key words, and the method and the parameters in the Flutter unified call interface are transmitted to the Flutter unified call interface.

Optionally, before calling the listener corresponding to the target API through the Flutter unified call interface, the method further includes: storing the mapping interface into a cached table in a way of using a flute method key word; registering a Flutter interface call-back registration center by using a Flutter method keyword; when a method for calling a key word to an object is called, the corresponding Flutter unified calling interface is found from the cache according to the value of the key word, and the data is converted into a table and a method and then is transmitted to the Flutter unified calling interface.

Specifically, all Flutter unified calling interfaces may be stored in the cached hash table in a way of a Flutter method key. When the system calls back a method from a keyword to an object, the corresponding Flutter unified calling interface is taken out according to the keyword, data is converted into a hash map and transmitted to the Flutter unified calling interface in a just-sending mode, finally the Flutter unified calling interface calls back the corresponding monitor to complete a corresponding function, and the data is transmitted to dart through the Flutter unified calling interface.

And S102, operating the listener corresponding to the target API according to the calling mode.

In this embodiment, the listener includes a listener program compiled after abstracting the API to a function set of interface operations. And running a monitor corresponding to the target API according to the calling mode to realize the final function in the core API.

Specifically, the top layer is a service API layer, which is consistent with the original implementation. The method can be characterized in that the application development platform is flute or React Native, interaction is realized in the SDK layer through a method channel or a JS bridge and a flute unified call interface or a mobile API in a jd exact frame layer, and a listener corresponding to a target API in a core API layer is operated at most. The embodiment can smooth the inconsistency of the interfaces at two ends by abstracting a layer of Flutter unified call interface and a listener. Then all Flutter unified Call interfaces are cached and customized to unify the standard Method Call Handler interfaces. And the Method Call Handler is repeatedly packaged by the developer not needing to package the API through the unified calling interface corresponding to the Flutter Method keyword. In this mode, the developer only needs to implement the relationship listener/Flutter unified call interface, and does not need to care about the inconsistency of the two-side frames.

Optionally, the running result of the listener is fed back to the Flutter result callback interface through the Flutter unified call interface, so that the Flutter result callback interface feeds back the running result to the call end.

Specifically, the abstracted Flutter's data returns to the Flutter result callback interface, including successful and failed callbacks. After the JD Flutter Call returns data, the data is finally returned to the caller through the result of the JD Flutter Method Call Handler.

In the embodiment, the calling mode of the application programming interface API is determined according to the type of the application development platform; running a listener corresponding to the target API according to the calling mode; the listener includes a listener program compiled by abstracting the API to a function set of interface operations. Therefore, API compatibility of different application development platforms can be realized, the consistency of interface calling is ensured, and the development cost is reduced.

Fig. 3 is a schematic structural diagram of a cross-platform API sharing apparatus according to a second embodiment of the present disclosure, and as shown in fig. 3, the apparatus in this embodiment may include:

the determining module 31 is configured to determine a calling mode of an application programming interface API according to the type of the application development platform;

the calling module 32 is used for operating a listener corresponding to the target API according to a calling mode; the listener includes a listener program compiled by abstracting the API to a function set of interface operations.

In one possible design, the determining module 31 is specifically configured to:

if the application development platform is reach Native, calling a target API by adopting a reach marking method;

In one possible design, the target API is called using the React flag method, which includes:

registering a module method in the React interface management object, wherein the module method is used for declaring the API as a React marking method and registering a listener corresponding to the React marking method;

through the mutual calling between the JS communication bridge building module method and the JS;

In one possible design, the target API is called through the Flutter unified call interface, including:

defining a Flutter unified calling interface in a Flutter framework;

and calling the listener corresponding to the target API through the Flutter unified calling interface.

In one possible design, further comprising:

the cache module 33 is configured to store the mapping interface in a cached table in a manner of a Flutter method keyword before calling the listener corresponding to the target API through the Flutter unified call interface;

the registration module 34 is configured to register a Flutter interface callback registration center with a Flutter method keyword;

and the transmission module 35 is configured to, when a method for calling a keyword to an object is called, find a corresponding Flutter unified calling interface from the cache according to a value of the keyword, convert the data into a table and a method, and then transfer the table and the method to the Flutter unified calling interface.

In one possible design, further comprising:

and the feedback module 36 is configured to feed back the running result of the listener to the Flutter result callback interface through the Flutter unified call interface, so that the Flutter result callback interface feeds back the running result to the call end.

The cross-platform API sharing apparatus of this embodiment may execute the technical solution in the method shown in fig. 2, and for specific implementation processes and technical principles, reference is made to relevant descriptions in the method shown in fig. 2, which is not described herein again.

Fig. 4 is a schematic structural diagram of a cross-platform API sharing system provided in a third embodiment of the present application, and as shown in fig. 4, the cross-platform API sharing system 40 of the present embodiment may include: a processor 41 and a memory 42.

A memory 42 for storing programs; the Memory 42 may include a volatile Memory (RAM), such as a Static Random Access Memory (SRAM), a Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM), and the like; the memory may also comprise a non-volatile memory, such as a flash memory. The memory 42 is used to store computer programs (e.g., applications, functional modules, etc. that implement the above-described methods), computer instructions, etc., which may be stored in one or more of the memories 42 in a partitioned manner. And the above-mentioned computer program, computer instructions, data, etc. can be called by the processor 41.

The computer programs, computer instructions, etc. described above may be stored in one or more memories 42 in partitions. And the above-mentioned computer program, computer instructions, data, etc. can be called by the processor 41.

A processor 41 for executing the computer program stored in the memory 42 to implement the steps of the method according to the above embodiments.

Reference may be made in particular to the description relating to the preceding method embodiment.

The processor 41 and the memory 42 may be separate structures or may be integrated structures integrated together. When the processor 41 and the memory 42 are separate structures, the memory 42 and the processor 41 may be coupled by a bus 43.

The cross-platform API sharing system of this embodiment may execute the technical solution in the method shown in fig. 2, and for the specific implementation process and technical principle, reference is made to the relevant description in the method shown in fig. 2, which is not described herein again.

In addition, embodiments of the present application further provide a computer-readable storage medium, in which computer-executable instructions are stored, and when at least one processor of the user equipment executes the computer-executable instructions, the user equipment performs the above-mentioned various possible methods.

Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. Of course, the storage medium may also be integral to the processor. The processor and the storage medium may reside in an ASIC. Additionally, the ASIC may reside in user equipment. Of course, the processor and the storage medium may reside as discrete components in a communication device.

The present application further provides a program product comprising a computer program stored in a readable storage medium, from which the computer program can be read by at least one processor of a server, the computer program being executable by the at least one processor to cause the server to carry out the method of any of the embodiments of the present application described above.

Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A cross-platform API sharing method is characterized by comprising the following steps:

2. The method of claim 1, wherein determining the calling mode of the Application Programming Interface (API) according to the type of the application development platform comprises:

3. The method of claim 2, wherein the calling the target API with the React flag method comprises:

4. The method according to claim 2, wherein the calling the target API through the Flutter unified call interface comprises:

defining a Flutter unified calling interface in a Flutter framework;

5. The method according to claim 4, wherein before the calling the listener corresponding to the target API through the Flutter unified call interface, the method further includes:

6. The method of claim 4, further comprising:

7. A cross-platform API sharing apparatus, comprising:

8. The apparatus of claim 7, wherein the determining module is specifically configured to:

9. A cross-platform API sharing system, comprising: the memory is used for storing executable instructions of the processor; wherein the processor is configured to perform the cross-platform API sharing method of claims 1-6 via execution of the executable instructions.

10. A computer-readable storage medium on which a computer program is stored, the program, when executed by a processor, implementing the cross-platform API sharing method of claims 1-6.