CN113591006A

CN113591006A - Web extension method and device based on WebSocket

Info

Publication number: CN113591006A
Application number: CN202110912291.1A
Authority: CN
Inventors: 王晔; 李游
Original assignee: Seerof Information Technology Shanghai Co ltd
Current assignee: Seerof Information Technology Shanghai Co ltd
Priority date: 2021-08-10
Filing date: 2021-08-10
Publication date: 2021-11-02

Abstract

The invention relates to a Web extension method and a device based on WebSocket, wherein the method is executed at a WebSocket server side: the JS extension interface description file is written according to the format, and an adaptation layer code corresponding to the JS extension interface description file is generated; setting local service event monitoring; registering a message processing function of an extension interface; establishing bidirectional communication with a Web end; registering a general message processing function; establishing an event monitoring callback channel; and circularly waiting for the request message of the Web end. Through the application, the problems that Web expansion in the related technology needs to depend on a JS engine or a host with the JS engine are solved, when the JS engine or the host thereof is changed, Webapp cannot directly and normally run, and the expansion of the Webapp needs to be realized again are solved, no JS engine or the host thereof is depended on, and only one expansion needs to be realized.

Description

Web extension method and device based on WebSocket

Technical Field

The invention relates to the technical field of computers, in particular to a Web extension method and device based on WebSocket, computer equipment and a computer readable storage medium.

Background

The existing Web common extension scheme principle is based on a JS engine or a JS engine-based framework in a browser. The basic principle is that a Native interface is bound and registered in a JS engine through a character string, so that a Web context can identify the field, when the field is called, the field is equal to the Native interface, then the Native interface can process a specific request, and then the result is returned to the Web. Existing extensions rely on a JS engine or a host (browser) with a JS engine. When the JS engine or the host thereof is changed, the Webapp cannot directly and normally run, and the extension of the Webapp needs to be realized again.

At present, aiming at the problems that Web expansion in the related technology needs to depend on a JS engine or a host with the JS engine, when the JS engine or the host thereof is changed, Webapp cannot directly and normally run, and the expansion needs to be realized again, an effective solution is not provided.

Disclosure of Invention

The application aims to provide a Web extension method, a Web extension device, computer equipment and a computer readable storage medium based on WebSocket, so as to solve the problem that Web extension in the related technology at least depends on a JS engine or a host with the JS engine, and when the JS engine or the host thereof is changed, Webapp cannot directly and normally run and needs to be extended again.

In order to achieve the purpose, the technical scheme adopted by the application is as follows:

in a first aspect, an embodiment of the present application provides a Web extension method based on WebSocket, where an execution flow of the method at a WebSocket server includes:

the JS extension interface description file is written according to the format lyric, and an adaptation layer code corresponding to the JS extension interface description file is generated;

setting local service event monitoring;

registering a message processing function of an extension interface;

establishing bidirectional communication with a Web end;

registering a general message processing function;

establishing an event monitoring callback channel;

and circularly waiting for the request message of the Web end.

In some embodiments, the execution flow of the method on the Web side includes:

adding a packaged JS extension library, and automatically establishing communication connection with a WebSocket server when a webpage runs;

adding a JS extension interface description file, and initializing a JS extension interface;

monitoring events required by registering applications;

and developing an application by using the JS extension interface.

In some embodiments, adding the JS extension interface description file and initializing the JS extension interface includes:

mounting the function of the JS extension interface to a JS context;

setting a sending function for the function of the JS extension interface;

constructing message parameters;

each request-canceling message is assigned a unique identification.

In some of these embodiments, the event listening required to register the application includes:

and after determining that the communication connection is successfully established with the WebSocket server, registering event monitoring required by the application.

In a second aspect, an embodiment of the present application provides a Web extension apparatus based on WebSocket, where the apparatus includes a first execution unit, configured to execute a flow at a WebSocket server, where the first execution unit includes:

the definition module is used for expressing the JS extension interface description file according to the format and generating an adaptation layer code corresponding to the JS extension interface description file;

the setting module is used for setting local service event monitoring;

the first register module is used for registering a message processing function of the expansion interface;

the first establishing module is used for establishing bidirectional communication with the Web end;

the second registration module is used for registering the general message processing function;

the second establishing module is used for establishing an event monitoring callback channel;

and the waiting module is used for circularly waiting the request message of the Web end.

In some embodiments, the apparatus further includes a second execution unit, configured to execute the flow at the Web end, where the second execution unit includes:

the first adding module is used for adding the packaged JS extension library and automatically establishing communication connection with the WebSocket server when the webpage runs;

the second adding module is used for adding the JS extension interface description file and initializing the JS extension interface;

the third registration module is used for registering event monitoring required by the application;

and the development module is used for developing application by using the JS extension interface.

In some embodiments, the second adding module comprises:

the mounting submodule is used for mounting the function of the JS extension interface to the JS context;

the setting submodule is used for setting a sending function for the function of the JS extension interface;

the construction submodule is used for constructing message parameters;

and the distribution submodule is used for distributing a unique identifier for each request eliminating message.

In some embodiments, the third registration module comprises:

and the registration submodule is used for monitoring the event required by the registration application after the communication connection with the WebSocket server is determined to be successfully established.

In a third aspect, an embodiment of the present application provides a computer device, which includes a memory, a processor, and a computer program that is stored on the memory and is executable on the processor, and when the processor executes the computer program, the Web extension method based on WebSocket as described in the first aspect is implemented.

In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the WebSocket-based Web extension method according to the first aspect.

Compared with the prior art, the Web expansion based on the Websocket provided by the embodiment of the application is executed at the Websocket server side by adopting the technical scheme that: the JS extension interface description file is written according to the format, and an adaptation layer code corresponding to the JS extension interface description file is generated; setting local service event monitoring; registering a message processing function of an extension interface; establishing bidirectional communication with a Web end; registering a general message processing function; establishing an event monitoring callback channel; the method and the device have the advantages that the request message of the Web end is circularly waited, the problems that Web expansion needs to depend on a JS engine or a host with the JS engine in the related technology, when the JS engine or the host changes, Webapp cannot directly and normally operate, and the expansion needs to be realized again are solved, the effect that the expansion only needs to be realized once without depending on the JS engine or the host thereof is realized.

The details of one or more embodiments of the application are set forth in the accompanying drawings and the description below to provide a more thorough understanding of the application.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

fig. 1 is a block diagram of a mobile terminal according to an embodiment of the present application;

fig. 2 is a frame structure diagram of a Web extension method based on WebSocket according to an embodiment of the present application;

fig. 3 is a flowchart of an execution flow of a Web socket server based Web extension method according to an embodiment of the present application;

fig. 4 is a flowchart of an execution flow of a Web extension method based on WebSocket on a Web end according to an embodiment of the present application;

fig. 5 is a block diagram of a Web extension apparatus based on WebSocket according to an embodiment of the present application;

fig. 6 is a block diagram of a Web extension apparatus based on WebSocket according to another embodiment of the present application;

fig. 7 is a hardware structure diagram of a computer device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments provided in the present application without any inventive step are within the scope of protection of the present application.

It is obvious that the drawings in the following description are only examples or embodiments of the present application, and that it is also possible for a person skilled in the art to apply the present application to other similar contexts on the basis of these drawings without inventive effort. Moreover, it should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another.

Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the specification. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of ordinary skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments without conflict.

Unless defined otherwise, technical or scientific terms referred to herein shall have the ordinary meaning as understood by those of ordinary skill in the art to which this application belongs. Reference to "a," "an," "the," and similar words throughout this application are not to be construed as limiting in number, and may refer to the singular or the plural. The present application is directed to the use of the terms "including," "comprising," "having," and any variations thereof, which are intended to cover non-exclusive inclusions; for example, a process, method, system, article, or apparatus that comprises a list of steps or modules (elements) is not limited to the listed steps or elements, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. Reference to "connected," "coupled," and the like in this application is not intended to be limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The term "plurality" as referred to herein means two or more. "and/or" describes an association relationship of associated objects, meaning that three relationships may exist, for example, "A and/or B" may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. Reference herein to the terms "first," "second," "third," and the like, are merely to distinguish similar objects and do not denote a particular ordering for the objects.

The embodiment provides a mobile terminal. Fig. 1 is a block diagram of a mobile terminal according to an embodiment of the present application. As shown in fig. 1, the mobile terminal includes: a Radio Frequency (RF) circuit 110, a memory 120, an input unit 130, a display unit 140, a sensor 150, an audio circuit 160, a wireless fidelity (WiFi) module 170, a processor 180, and a power supply 190. Those skilled in the art will appreciate that the mobile terminal architecture shown in fig. 1 is not intended to be limiting of mobile terminals and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.

The following describes each constituent element of the mobile terminal in detail with reference to fig. 1:

the RF circuit 110 may be used for receiving and transmitting signals during information transmission and reception or during a call, and in particular, receives downlink information of a base station and then processes the received downlink information to the processor 180; in addition, the data for designing uplink is transmitted to the base station. In general, RF circuits include, but are not limited to, an antenna, at least one Amplifier, a transceiver, a coupler, a Low Noise Amplifier (LNA), a duplexer, and the like. In addition, the RF circuitry 110 may also communicate with networks and other devices via wireless communications. The wireless communication may use any communication standard or protocol, including but not limited to Global System for Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Message Service (SMS), and the like.

The memory 120 may be used to store software programs and modules, and the processor 180 executes various functional applications and data processing of the mobile terminal by operating the software programs and modules stored in the memory 120. The memory 120 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the mobile terminal, and the like. Further, the memory 120 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

The input unit 130 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the mobile terminal. Specifically, the input unit 130 may include a touch panel 131 and other input devices 132. The touch panel 131, also referred to as a touch screen, may collect touch operations of a user on or near the touch panel 131 (e.g., operations of the user on or near the touch panel 131 using any suitable object or accessory such as a finger or a stylus pen), and drive the corresponding connection device according to a preset program. Alternatively, the touch panel 131 may include two parts, i.e., a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 180, and can receive and execute commands sent by the processor 180. In addition, the touch panel 131 may be implemented by various types such as a resistive type, a capacitive type, an infrared ray, and a surface acoustic wave. The input unit 130 may include other input devices 132 in addition to the touch panel 131. In particular, other input devices 132 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.

The display unit 140 may be used to display information input by a user or information provided to the user and various menus of the mobile terminal. The Display unit 140 may include a Display panel 141, and optionally, the Display panel 141 may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like. Further, the touch panel 131 can cover the display panel 141, and when the touch panel 131 detects a touch operation on or near the touch panel 131, the touch operation is transmitted to the processor 180 to determine the type of the touch event, and then the processor 180 provides a corresponding visual output on the display panel 141 according to the type of the touch event. Although the touch panel 131 and the display panel 141 are shown in fig. 1 as two separate components to implement the input and output functions of the mobile terminal, in some embodiments, the touch panel 131 and the display panel 141 may be integrated to implement the input and output functions of the mobile terminal.

The mobile terminal may also include at least one sensor 150, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor that may adjust the brightness of the display panel 141 according to the brightness of ambient light, and a proximity sensor that may turn off the display panel 141 and/or the backlight when the mobile terminal is moved to the ear. As one of the motion sensors, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally, three axes), detect the magnitude and direction of gravity when stationary, and can be used for applications (such as horizontal and vertical screen switching, related games, magnetometer attitude calibration) for recognizing the attitude of the mobile terminal, and related functions (such as pedometer and tapping) for vibration recognition; as for other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which can be configured on the mobile terminal, further description is omitted here.

A speaker 161 and a microphone 162 in the audio circuit 160 may provide an audio interface between the user and the mobile terminal. The audio circuit 160 may transmit the electrical signal converted from the received audio data to the speaker 161, and convert the electrical signal into a sound signal for output by the speaker 161; on the other hand, the microphone 162 converts the collected sound signal into an electric signal, converts the electric signal into audio data after being received by the audio circuit 160, and then outputs the audio data to the processor 180 for processing, and then transmits the audio data to, for example, another mobile terminal via the RF circuit 110, or outputs the audio data to the memory 120 for further processing.

WiFi belongs to a short-distance wireless transmission technology, and the mobile terminal can help a user to send and receive e-mails, browse webpages, access streaming media and the like through the WiFi module 170, and provides wireless broadband internet access for the user. Although fig. 1 shows the WiFi module 170, it is understood that it does not belong to the essential components of the mobile terminal, and it can be omitted or replaced with other short-range wireless transmission modules, such as Zigbee module or WAPI module, etc., as required within the scope not changing the essence of the invention.

The processor 180 is a control center of the mobile terminal, connects various parts of the entire mobile terminal using various interfaces and lines, and performs various functions of the mobile terminal and processes data by operating or executing software programs and/or modules stored in the memory 120 and calling data stored in the memory 120, thereby performing overall monitoring of the mobile terminal. Alternatively, processor 180 may include one or more processing units; preferably, the processor 180 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 180.

The mobile terminal also includes a power supply 190 (e.g., a battery) for powering the various components, which may preferably be logically coupled to the processor 180 via a power management system that may be configured to manage charging, discharging, and power consumption.

Although not shown, the mobile terminal may further include a camera, a bluetooth module, and the like, which will not be described herein.

In this embodiment, the processor 180 is configured to: at a WebSocket service end, a JS extension interface description file is written according to a format, and an adaptation layer code corresponding to the JS extension interface description file is generated; setting local service event monitoring; registering a message processing function of an extension interface; establishing bidirectional communication with a Web end; registering a general message processing function; establishing an event monitoring callback channel; and circularly waiting for the request message of the Web end.

In some of these embodiments, the processor 180 is further configured to: adding a packaged JS extension library at a Web end, and automatically establishing communication connection with a WebSocket server when a webpage runs; adding a JS extension interface description file, and initializing a JS extension interface; monitoring events required by registering applications; and developing an application by using the JS extension interface.

In some of these embodiments, the processor 180 is further configured to: mounting the function of the JS extension interface to a JS context; setting a sending function for the function of the JS extension interface; constructing message parameters; each request-canceling message is assigned a unique identification.

In some of these embodiments, the processor 180 is further configured to: and after determining that the communication connection is successfully established with the WebSocket server, monitoring a registration event.

The embodiment provides a Web extension method based on WebSocket.

First, technical terms appearing in the embodiments of the present application are explained as follows:

1) WebSocket: a network technology capable of bi-directional communication with a WebSocket Server. The embodiment of the application acquires the service capability through the WebSocket technology.

2) WebSocket Server: and the WebSocket-based server is used for responding to the Web request.

3) JS interface List: JsJson technology is used for describing interface information to be expanded according to a certain format.

4) JS extension interface module: the method is used for packaging the WebSocket, providing a JS interface list initialization interface, adding and removing an event monitoring interface and the like.

5) Adaptor: and the adaptation layer is used for actually processing the JS interface request and carrying out butt joint service.

6) Web app: apps developed using Web technology. Web technologies include, but are not limited to, H5+ JS, variants thereof, subsets thereof.

The method and the device can be applied to all applications which want to develop the local service capability by using the Web technology.

Fig. 2 is a frame structure diagram of a Web extension method based on WebSocket according to an embodiment of the present application, and as shown in fig. 2, the frame structure of the Web extension method based on WebSocket includes a Web end, a WebSocket server, a browser, and a local service, where the Web end and the WebSocket server are in communication connection, and the WebSocket server is provided with an adaptation layer, and the local service can be invoked by using the adaptation layer.

The Web expansion method based on the Websocket is divided into an execution flow of a Websocket server and an execution flow of a Web end.

Fig. 3 is a flowchart of an execution flow at a WebSocket server of a WebSocket-based Web extension method according to an embodiment of the present application, where as shown in fig. 3, the execution flow at the WebSocket server includes the following steps:

s301, expressing a JS extension interface description file according to a format, and generating an adaptation layer code corresponding to the JS extension interface description file;

step S302, setting local service event monitoring;

step S303, registering a message processing function of the expansion interface;

step S304, establishing bidirectional communication with a Web end;

step S305, registering a general message processing function;

step S306, establishing an event monitoring callback channel;

step S307, a loop waits for a request message of the Web side.

Fig. 4 is a flowchart of an execution flow at a Web end of a Web extension method based on WebSocket according to an embodiment of the present application, where as shown in fig. 4, the execution flow at the Web end includes the following steps:

step S401, adding a packaged JS extension library, and automatically establishing communication connection with a WebSocket server when a webpage runs;

step S402, adding a JS extension interface description file, and initializing a JS extension interface;

step S403, monitoring events required by the registered application;

and step S404, developing the application by using the JS extension interface.

In some embodiments, the step S402 of adding the JS extension interface description file and initializing the JS extension interface includes:

mounting the function of the JS extension interface to a JS context;

setting a sending function for the function of the JS extension interface;

constructing message parameters;

each request-canceling message is assigned a unique identification.

In some embodiments, the event listening required for registering the application in step S403 includes:

Through the steps, the problems that Web expansion needs to depend on a JS engine or a host with the JS engine in the related technology are solved, when the JS engine or the host changes, the Web app cannot directly and normally run, and the expansion needs to be realized again, the JS engine or the host is not depended on, and only one-time expansion needs to be realized.

The invention bypasses the original expansion mode based on the JS engine or the host thereof by using the WebSocket mode.

The process at the Web end is as follows:

a) adding a packaged JS extension library at the head of a webpage, and automatically connecting a Websocket server end when the webpage runs;

b) adding a JS extension interface description file at the head of the webpage;

c) initializing a JS extension interface;

d) registering event monitoring of each module;

e) an application is developed using the extended interface.

The process at the WebSocket Server end is as follows:

a) writing JS extension interface description;

b) automatic adapter layer codes are realized;

c) setting monitoring of system service;

d) registering a message processing function (adapter) of an extension interface, and finally distributing a request by a WebSocket Server end through the monitoring container;

e) establishing a WebSocket Server;

f) registering a general message processing function, wherein the general message processing function comprises an active request interface, an event monitoring adding interface and an event monitoring removing interface; all the descriptions in the a) are active request interfaces, and the messages are distributed according to the participation in the message processing;

g) establishing an event monitoring callback channel;

h) and circularly waiting for Web requests or notifications.

Specifically, the method comprises the following steps:

the process at the Web end comprises the following steps:

a) and adding an encapsulated JS extension library at the head of the webpage. When the webpage runs, the webpage firstly runs, WebSocket is initialized, and onpen, onerror, onmessage, onclose and send packaging work needs to be done.

b) And adding a JS extension interface description file at the head of the webpage. The interface description file is provided by the extension developer where the addition is in preparation for initialization.

c) And initializing the JS extension interface. And registering the expansion interface into the JS context according to the module, and then normally calling the expansion interface.

d) Registering each module event monitoring. In the step, registration is needed after the connection with the Websocket Server is confirmed to be successful, otherwise, the callback is saved by the Web end, but the related key is not synchronized with the Websocket Server.

e) An application is developed using the extended interface. The preparation is completed and the development of the application can begin.

The process at the WebSocket Server end comprises the following steps:

a) write JS extension interface description. Describes what module the extended interface is, what APIs are under the module, and what parameters each API has.

b) And automatically generating and implementing the Adaptor layer code. And the writing script automatically analyzes the JS extension interface description, provides an API for registering the extension interface and generates null implementation of the Adaptor.

c) And setting the monitoring of system services. The Web needs to register the states of some services, and the WebSocket Server does not own and needs to register with a local service.

d) And registering a message processing function (adapter) of the extension interface, and finally distributing the request by the WebSocket Server terminal through the monitoring container. Interception is set with an API that automatically generates a registration extension interface in the Adaptor code.

e) And establishing the WebSocket Server. And the Web end is communicated with the Web end in a bidirectional mode.

f) The generic message handling function is registered. The system comprises an active request interface, an event monitoring adding interface and an event monitoring removing interface. All descriptions in a) are active request interfaces, and the messages are distributed according to participation in the processing process.

g) And establishing an event monitoring callback channel. The method mainly comprises the step of notifying the Web end when the Web end registers a local service event but the local service event occurs.

h) And circularly waiting for Web requests or notifications. Keeping the WebSocket active.

A specific example of the present application, such as the time zone of a television system, now requires an interface to obtain the time zone.

Firstly, the execution flow of the WebSocket Server end is as follows:

1) the JS interface description needs to be written first.

2) And generating or writing an adapter code by self through script analysis of the JS interface description.

void apihnd_sraftv_timer_get_time_zone(intid,

const Json::Value&params,Json::Value&result){

TvTimerServicetvTimerService; // System services

result["value"]＝tvTimerService.getTimeZone()；

result["status"]＝"ok"；

}

3) And setting the monitoring of system services.

This interface does not listen for the scenario of an event. If other interfaces need, the monitoring can be carried out according to the local service monitoring specification, and a callback function is set.

4) The message handling functions of the extension interface are registered.

When the WebSocket Server is started, the adapter corresponding to the JS interface description is stored in a map. In this example, the key may be sraftv _ timer _ get _ time _ zone, when the front end requests, the modules, sub-modules, and functions of the interface are joined by underlining, and are passed as parameters, and finally, the corresponding Adaptor is found through the key value.

5) And establishing the WebSocket Server.

Any open-source and well-used library, such as Libwebsockets, can be obtained and built according to the specifications of the library. Setting a port and a bidirectional communication processing function. The main work is as follows:

a) WebSocket context information preparation and service initiation.

A port is provided, which may be 8989; setting a processing function of a protocol state; and starts a thread to start service and wait for a message to come.

b) And processing the protocol state. Only the processing of a received message is described here.

The status of the received message in this example is LWS _ CALLBACK _ RECEIVE. When the front end sends a message, the front end message is injected into a queue.

6) And processing the message in the Web end message queue.

Starting a new thread, checking whether the message queue has messages, and if so, taking out the messages one by one for processing; if not, wait.

7) Generic message handling function registration

Before message parsing, the generic message handling function is explained. In actual operation, only registration is needed before request. The only common message processing is controlPlatform, addplatform Listener, removeplatform Listener. Active requests of all APIs are passed through the former, and the latter two are event snoops used to add or remove native system services or operating system services.

8) And (5) front-end message analysis processing.

When a message comes from the front end and is taken out for processing, what is needed to be distributed to which general function is the first to be done. In this case, it is distributed to the control platform.

9) General message processing function (controlPlatform)

And analyzing the parameters of the front-end message, finding the KEY of the expansion interface, finding the corresponding adapter and executing.

The execution flow at the Web end is as follows:

1) and adding a JS extension library.

a) And starting the WebSocket connection, and writing the callback of each state.

There are onpen, onerror, onmessage, onclose for each state callback. The main one is the onmessage, and the function trigger represents that the WebSocketServer has a message coming.

b) Initialization of the extended interface list.

The first step of initialization is mainly to mount each module function to the JS context. In this example, sraftv can be used as a global variable, then the timer is hung under sraftv, and finally get _ time _ zone is hung under the timer; this can be developed later to initiate requests in the form of sraftv.

The second step of initialization is to set a uniform send function for each extension function. When the Web develops the call extension function is equal to the call to the send function. This form can be exploited asynchronously, which is well developed.

The third step of initialization is to construct message parameters. Firstly, a parameter for constructing general message processing, in this example, control platform, and then constructing a Key parameter of an Adaptor, in this example, sraftv _ timer _ get _ timer _ zone, if the extended interface has a parameter, the parameter can be described in a Json format, in this example, the parameter is not described.

The fourth step of initialization is to identify a unique Id for each request. And saving the callback function according to the Id, so that the callback can be found when the WebSocket Server responds.

Specific code examples are as follows:

in the application embodiment, when the Web calls the extended API, the extended API is converted into a character string message with a certain format according to a self-defined message protocol, and the character string message is sent to a local WebSocket server through a WebSocket technology; the WebSocket server analyzes the message and then distributes the message to the relevant adaptors for processing, the relevant adaptors call the local system service capability to realize the request, and if a result exists, the result is returned to the Web end through the WebSocket technology.

The key technical points are as follows:

1) the communication between Web and Native is realized through a WebSocket technology, and the problem that the existing extension mode depends on a JS engine or a host thereof is solved.

2) The description of the expansion interface is a bridge for communication between a Web capability expansion developer and a WebApp developer, and is also a guarantee that the Web expansion interface and the Adaptor can be in one-to-one correspondence.

3) And the JS extension module library encapsulates repeated and multiple details of the WebSocket, provides a JS interface list initialization interface, adds and removes an event monitoring interface and the like, so that the Web can use the extension API in a traditional API calling mode.

4) The Adaptor automatically generates a script and quickly generates an Adaptor code, and only needs to pay attention to specific request realization.

The embodiment of the application can realize the following technical effects:

1) and the dependence of the Web extension on the JS engine or a host (browser) with the JS engine is broken. So that if running at a different browser vendor (for example) no further extensions to the new browser are required.

2) And the JS interface is used for description, so that the front-end initialization corresponds to the back-end adapter one by one, and after the whole framework is established, a developer does not need to care about the process, so that the supplementary expansion becomes very simple and the start is very quick.

3) And initializing the extension interface, so that a Web end developer can use the extension interface in a traditional calling mode without learning cost. And by using the Promise characteristic, asynchronous data acquisition and business logic are separated, so that a developer can concentrate on one transaction without considering the transaction at the same time.

It should be noted that the steps illustrated in the above-described flow diagrams or in the flow diagrams of the figures may be performed in a computer system, such as a set of computer-executable instructions, and that, although a logical order is illustrated in the flow diagrams, in some cases, the steps illustrated or described may be performed in an order different than here.

The present embodiment provides a Web extension apparatus based on WebSocket, where the apparatus is used to implement the foregoing embodiments and preferred embodiments, and details are not repeated for what has been described. As used hereinafter, the terms "module," "unit," "subunit," and the like may implement a combination of software and/or hardware for a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.

Fig. 5 is a block diagram of a structure of a Web extension apparatus based on WebSocket according to an embodiment of the present application, and as shown in fig. 5, the apparatus includes a first execution unit 51, configured to execute a flow at a WebSocket server, where the first execution unit 51 includes:

the definition module 511 is used for expressing the JS extension interface description file according to the format and generating an adaptation layer code corresponding to the JS extension interface description file;

a setting module 512, configured to set local service event monitoring;

a first registration module 513, configured to register a message processing function of the extension interface;

a first establishing module 514, configured to establish bidirectional communication with the Web end;

a second registration module 515, configured to register a general message processing function;

a second establishing module 516, configured to establish an event listening callback channel;

and a waiting module 517, configured to circularly wait for the request message of the Web end.

In some embodiments, as shown in fig. 6, the apparatus further includes a second execution unit 52, configured to execute the flow at the Web end, where the second execution unit 52 includes:

the first adding module 521 is used for adding the packaged JS extension library and automatically establishing communication connection with the WebSocket server when the webpage runs;

the second adding module 522 is used for adding a JS extension interface description file and initializing a JS extension interface;

a third registration module 523, configured to register event monitoring required by the application;

and a development module 524, configured to develop an application using the JS extension interface.

In some embodiments, the second adding module 522 comprises:

the construction submodule is used for constructing message parameters;

In some embodiments, the third registration module 523 includes:

The above modules may be functional modules or program modules, and may be implemented by software or hardware. For a module implemented by hardware, the modules may be located in the same processor; or the modules can be respectively positioned in different processors in any combination.

An embodiment provides a computer device. The Web extension method based on the WebSocket in combination with the embodiment of the application can be realized by computer equipment. Fig. 7 is a hardware structure diagram of a computer device according to an embodiment of the present application.

The computer device may comprise a processor 71 and a memory 72 in which computer program instructions are stored.

Specifically, the processor 71 may include a Central Processing Unit (CPU), or A Specific Integrated Circuit (ASIC), or may be configured to implement one or more Integrated circuits of the embodiments of the present Application.

Memory 72 may include, among other things, mass storage for data or instructions. By way of example, and not limitation, memory 72 may include a Hard Disk Drive (Hard Disk Drive, abbreviated to HDD), a floppy Disk Drive, a Solid State Drive (SSD), flash memory, an optical Disk, a magneto-optical Disk, tape, or a Universal Serial Bus (USB) Drive or a combination of two or more of these. Memory 72 may include removable or non-removable (or fixed) media, where appropriate. The memory 72 may be internal or external to the data processing apparatus, where appropriate. In a particular embodiment, the memory 72 is a Non-Volatile (Non-Volatile) memory. In particular embodiments, Memory 72 includes Read-Only Memory (ROM) and Random Access Memory (RAM). The ROM may be mask-programmed ROM, Programmable ROM (PROM), Erasable PROM (EPROM), Electrically Erasable PROM (EEPROM), Electrically rewritable ROM (EAROM), or FLASH Memory (FLASH), or a combination of two or more of these, where appropriate. The RAM may be a Static Random-Access Memory (SRAM) or a Dynamic Random-Access Memory (DRAM), where the DRAM may be a Fast Page Mode Dynamic Random-Access Memory (FPMDRAM), an Extended data output Dynamic Random-Access Memory (EDODRAM), a Synchronous Dynamic Random-Access Memory (SDRAM), and the like.

The memory 72 may be used to store or cache various data files that need to be processed and/or used for communication, as well as possible computer program instructions executed by the processor 71.

The processor 71 reads and executes the computer program instructions stored in the memory 72 to implement any one of the Web socket-based Web extension methods in the above embodiments.

In some of these embodiments, the computer device may also include a communication interface 73 and a bus 70. As shown in fig. 7, the processor 71, the memory 72, and the communication interface 73 are connected via the bus 70 to complete mutual communication.

The communication interface 73 is used for realizing communication among modules, devices, units and/or equipment in the embodiment of the present application. The communication interface 73 may also enable communication with other components such as: the data communication is carried out among external equipment, image/data acquisition equipment, a database, external storage, an image/data processing workstation and the like.

The bus 70 comprises hardware, software, or both that couple the components of the computer device to one another. Bus 70 includes, but is not limited to, at least one of the following: data Bus (Data Bus), Address Bus (Address Bus), Control Bus (Control Bus), Expansion Bus (Expansion Bus), and Local Bus (Local Bus). By way of example, and not limitation, Bus 70 may include an Accelerated Graphics Port (AGP) or other Graphics Bus, an Enhanced Industry Standard Architecture (EISA) Bus, a Front-Side Bus (FSB), a Hyper Transport (HT) Interconnect, an ISA (ISA) Bus, an InfiniBand (InfiniBand) Interconnect, a Low Pin Count (LPC) Bus, a memory Bus, a microchannel Architecture (MCA) Bus, a PCI (Peripheral Component Interconnect) Bus, a PCI-Express (PCI-X) Bus, a Serial Advanced Technology Attachment (SATA) Bus, a Video Electronics Bus (audio Electronics Association), abbreviated VLB) bus or other suitable bus or a combination of two or more of these. Bus 70 may include one or more buses, where appropriate. Although specific buses are described and shown in the embodiments of the application, any suitable buses or interconnects are contemplated by the application.

In addition, in combination with the Web socket-based Web extension method in the foregoing embodiment, embodiments of the present application may provide a computer-readable storage medium to implement. The computer readable storage medium having stored thereon computer program instructions; when executed by a processor, the computer program instructions implement any one of the Web socket-based Web extension methods in the above embodiments.

The technical features of the embodiments described above may be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the embodiments described above are not described, but should be considered as being within the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A Web extension method based on WebSocket is characterized in that the execution flow of the method at a WebSocket server side comprises the following steps:

the JS extension interface description file is written according to the format, and an adaptation layer code corresponding to the JS extension interface description file is generated;

setting local service event monitoring;

registering a message processing function of an extension interface;

establishing bidirectional communication with a Web end;

registering a general message processing function;

establishing an event monitoring callback channel;

and circularly waiting for the request message of the Web end.

2. The Web extension method based on WebSocket of claim 1, wherein the execution flow of the method at the Web end comprises:

monitoring events required by registering applications;

and developing an application by using the JS extension interface.

3. The Web socket-based Web extension method of claim 2, wherein adding a JS extension interface description file and initializing a JS extension interface comprises:

mounting the function of the JS extension interface to a JS context;

setting a sending function for the function of the JS extension interface;

constructing message parameters;

each request-canceling message is assigned a unique identification.

4. The Web socket-based Web extension method of claim 2, wherein the event monitoring required for registering the application comprises:

5. The Web expansion device based on WebSocket is characterized by comprising a first execution unit, wherein the first execution unit is used for executing a process at a WebSocket server side, and the first execution unit comprises:

the setting module is used for setting local service event monitoring;

6. The Web socket-based Web extension apparatus according to claim 5, further comprising a second execution unit configured to execute the process at the Web end, wherein the second execution unit includes:

7. The WebSocket-based Web extension device of claim 6, wherein the second adding module comprises:

the construction submodule is used for constructing message parameters;

8. The WebSocket-based Web extension device of claim 6, wherein the third registration module comprises:

9. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the WebSocket-based Web extension method according to any one of claims 1 to 4 when executing the computer program.

10. A computer-readable storage medium on which a computer program is stored, the program, when executed by a processor, implementing the WebSocket-based Web extension method according to any one of claims 1 to 4.