CN113591006B

CN113591006B - A Web extension method and device based on WebSocket

Info

Publication number: CN113591006B
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: 2025-03-04
Anticipated expiration: 2041-08-10
Also published as: CN113591006A

Abstract

The application relates to a Web extension method and a Web extension device based on WebSocket, wherein the method is executed at a WebSocket server side, a JS extension interface description file is formed according to a format describe, an adaptation layer code corresponding to the JS extension interface description file is generated, local service event monitoring is set, a message processing function of an extension interface is registered, two-way communication with the Web side is established, a general message processing function is registered, an event monitoring callback channel is established, and request messages of the Web side are circularly waited. The application solves the problems that the Web expansion in the related technology needs to rely on the JS engine or the host with the JS engine, and when the JS engine or the host changes, the Webapp cannot directly and normally run and needs to realize the expansion again, and realizes that the Web expansion does not depend on the JS engine or the host thereof and only needs to realize one-time expansion.

Description

Web expansion method and device based on WebSocket

Technical Field

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

Background

The existing Web common extension principle is based on a JS engine or a JS engine-based framework in a browser. The basic principle is that the Native interface is registered into the JS engine through a character string binding, so that the Web context can identify the field, when the field is called, the field is called to the Native interface, then the Native interface processes 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 changes, the Webapp cannot directly and normally operate, and the expansion of the JS engine needs to be realized again.

At present, aiming at the problems that the Web expansion in the related technology needs to rely on a JS engine or a host with the JS engine, and when the JS engine or the host changes, the Webapp cannot directly and normally operate and needs to realize the expansion again, no effective solution is proposed.

Disclosure of Invention

The application aims to provide a Web expansion method, a Web expansion device, a Web expansion computer device and a Web expansion computer readable storage medium based on WebSocket, which at least solve the problems that the Web expansion in the related technology needs to depend on a JS engine or a host with the JS engine, and when the JS engine or the host changes, the Webapp cannot directly and normally run and needs to realize the expansion again.

In order to achieve the above 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:

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

Setting local service event monitoring;

registering a message processing function of the expansion interface;

establishing two-way 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 terminal.

In some embodiments, the execution flow of the method at the Web end includes:

Adding the 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;

Event monitoring required by registration application;

And developing an application by using the JS extension interface.

In some of these embodiments, adding the JS expansion interface description file and initializing the JS expansion interface includes:

The functions of the JS extension interface are mounted to a JS context;

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

Constructing message parameters;

each cancellation request message is assigned a unique identification.

In some of these embodiments, event interception required to register an application includes:

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 device based on WebSocket, where the device 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 expanding the interface description file according to a format describe JS, and generating an adaptation layer code corresponding to the JS expansion interface description file;

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

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

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

A second registration module for registering the universal message processing function;

The second building module is used for building an event monitoring callback channel;

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

In some embodiments, the apparatus further includes a second execution unit, configured to execute a 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 a WebSocket server side when a 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 the application by using the JS extension interface.

In some of these embodiments, the second adding module includes:

the mounting sub-module is used for mounting the functions 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;

a construction submodule for constructing message parameters;

and the allocation submodule is used for allocating unique identification to each cancellation request message.

In some of these embodiments, the third registration module includes:

And the booklet injection module is used for registering event monitoring required by the application after the communication connection with the WebSocket server is successfully established.

In a third aspect, an embodiment of the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor, where the processor implements the WebSocket-based Web extension method according to the first aspect when executing the computer program.

In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, on which a computer program is stored, which when executed by a processor implements the WebSocket-based Web extension method described in the first aspect above.

Compared with the prior art, the Web extension based on the WebSocket provided by the embodiment of the application is implemented at a WebSocket server side, the interface description file is extended according to the format describe JS, an adaptation layer code corresponding to the JS extension interface description file is generated, local service event monitoring is set, a message processing function of an extension interface is registered, two-way communication with the Web side is established, a general message processing function is registered, an event monitoring callback channel is established, request messages of the Web side are circularly waited, the problem that the Web extension in the related art needs to depend on a JS engine or a host with the JS engine, and the extension needs to be realized again when the JS engine or the host thereof changes is solved, and the problem that the extension does not depend on the JS engine or the host thereof and only needs to be realized once.

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 other features, objects, and advantages 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 specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on 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 WebSocket-based Web extension method according to an embodiment of the present application;

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

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

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

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

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

Detailed Description

The present application will be described and illustrated with reference to the accompanying drawings and examples in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application. All other embodiments, which can be made by a person of ordinary skill in the art based on the embodiments provided by the present application without making any inventive effort, are intended to fall within the scope of the present application.

It is apparent that the drawings in the following description are only some examples or embodiments of the present application, and it is possible for those of ordinary skill in the art to apply the present application to other similar situations according to these drawings without inventive effort. Moreover, it should be appreciated that while such a development effort might be complex and lengthy, it would nevertheless be a routine undertaking of design, fabrication, or manufacture for those of ordinary skill having the benefit of this disclosure, and thus should not be construed as having the benefit of this disclosure.

Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearances of such phrases 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. It is to be expressly and implicitly understood by those of ordinary skill in the art that the described embodiments of the application can be combined with other embodiments without conflict.

Unless defined otherwise, technical or scientific terms used herein should be given the ordinary meaning as understood by one of ordinary skill in the art to which this application belongs. The terms "a," "an," "the," and similar referents in the context of the application are not to be construed as limiting the quantity, but rather as singular or plural. The terms "comprises," "comprising," "includes," "including," or any other variation 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 modules (elements) is not limited to only those steps or elements but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. The terms "connected," "coupled," and the like in connection with the present application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The term "plurality" as used herein means two or more. "and/or" describes the association relationship of the association object, and indicates that three relationships may exist, for example, "a and/or B" may indicate that a exists alone, a and B exist simultaneously, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship. The terms "first," "second," "third," and the like, as used herein, are merely distinguishing between similar objects and not representing a particular ordering of 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 (WIRELESS FIDELITY, wiFi) module 170, a processor 180, and a power supply 190. Those skilled in the art will appreciate that the mobile terminal structure shown in fig. 1 is not limiting of the mobile terminal and may include more or fewer components than shown, or may combine certain components, or a different arrangement of components.

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

The RF circuit 110 may be used for receiving and transmitting signals during the process of receiving and transmitting information or communication, specifically, receiving downlink information of a base station, processing the downlink information by the processor 180, and transmitting uplink data to the base station. Typically, RF circuitry includes, but is not limited to, antennas, at least one amplifier, transceivers, couplers, low noise amplifiers (Low Noise Amplifier, abbreviated as LNAs), diplexers, and the like. In addition, RF circuit 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 communications (Global System of Mobile communication, abbreviated as GSM), general packet Radio Service (GENERAL PACKET Radio Service, abbreviated as GPRS), code division multiple access (Code Division Multiple Access, abbreviated as CDMA), wideband code division multiple access (Wideband Code Division Multiple Access, abbreviated as WCDMA), long term evolution (Long Term Evolution, abbreviated as LTE), email, short message Service (Short MESSAGING SERVICE, abbreviated as SMS), etc.

The memory 120 may be used to store software programs and modules, and the processor 180 performs various functional applications and data processing of the mobile terminal by executing the software programs and modules stored in the memory 120. The memory 120 may mainly include a storage program area which may store an operating system, an application program required for at least one function (such as a sound playing function, an image playing function, etc.), etc., and a storage data area which may store data (such as audio data, a phonebook, etc.) created according to the use of the mobile terminal, etc. In addition, 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 to generate key signal inputs related to user settings and function control of the mobile terminal. In particular, 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 thereon or thereabout by a user (e.g., operations of the user on the touch panel 131 or thereabout by using any suitable object or accessory such as a finger, a stylus, etc.), and drive the corresponding connection device according to a predetermined program. Alternatively, the touch panel 131 may include two parts of a touch detection device and a touch controller. The touch controller receives touch information from the touch detection 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 in various types such as resistive, capacitive, infrared, and 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 (e.g., volume control keys, switch keys, etc.), a trackball, mouse, joystick, etc.

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 alternatively, the display panel 141 may be configured in the form of a Liquid Crystal Display (LCD) CRYSTAL DISPLAY, an Organic Light-Emitting Diode (OLED), or the like. Further, the touch panel 131 may cover the display panel 141, and when the touch panel 131 detects a touch operation thereon or thereabout, the touch panel is transferred 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 in fig. 1, the touch panel 131 and the display panel 141 implement the input and output functions of the mobile terminal as two independent components, 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 moves to the ear. The accelerometer sensor can detect the acceleration in all directions (generally three axes), can detect the gravity and the direction when the accelerometer sensor is static, can be used for identifying the gesture of the mobile terminal (such as transverse and vertical screen switching, related games, magnetometer gesture calibration), vibration identification related functions (such as pedometer and knocking), and the like, and other sensors such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors and the like which are also configured by the mobile terminal are not repeated herein.

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

WiFi belongs to a short-distance wireless transmission technology, and a mobile terminal can help a user to send and receive emails, browse webpages, access streaming media and the like through the WiFi module 170, so that wireless broadband Internet access is provided for the user. Although fig. 1 shows a WiFi module 170, it will be understood that it does not belong to the necessary configuration of the mobile terminal, and may be omitted entirely or replaced with other short-range wireless transmission modules, such as Zigbee modules, WAPI modules, or the like, as desired within the scope of 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 running 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, the processor 180 may include one or more processing units, and preferably the processor 180 may integrate an application processor that primarily processes operating systems, user interfaces, applications, etc., with a modem processor that primarily processes 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 be logically connected to the processor 180 via a power management system so as to provide for the management of charge, discharge, and power consumption by the power management system.

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

In this embodiment, the processor 180 is configured to, at the WebSocket server, expand the interface description file according to the format describe JS and generate an adaptation layer code corresponding to the JS expansion interface description file, set local service event monitoring, register the message processing function of the expansion interface, establish bidirectional communication with the Web terminal, register the general message processing function, establish an event monitoring callback channel, and cycle to wait for the request message of the Web terminal.

In some embodiments, the processor 180 is further configured to add the encapsulated JS expansion library on the Web side, automatically establish a communication connection with the WebSocket server when the Web page is running, add the JS expansion interface description file, initialize the JS expansion interface, register event interception required by the application, and develop the application using the JS expansion interface.

In some of these embodiments, the processor 180 is further configured to mount the function of the JS extension interface to a JS context, set a send function for the function of the JS extension interface, construct message parameters, and assign a unique identification to each cancellation request message.

In some of these embodiments, the processor 180 is further configured to register for event listening after determining that a communication connection was successfully established with the WebSocket server.

The embodiment provides a Web expansion 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 two-way communication with WebSocket Server. The embodiment of the application acquires the service capability through the WebSocket technology.

2) WebSocket Server, a Server based on WebSocket, which is used for responding Web request.

3) JS interface list-interface information to be expanded is described in a certain format by JsJson technology.

4) The JS expansion interface module is used for packaging the WebSocket, providing a JS interface list initializing interface, adding and removing an event monitoring interface and the like.

5) And the adapter is used for actually processing JS interface requests and interfacing services.

6) Web app-apps developed using Web technology. Web technologies include, but are not limited to, h5+js, variants thereof, subsets thereof.

The application is applicable to all applications where it is desirable to develop local service capabilities using Web technology.

Fig. 2 is a frame structure diagram of a WebSocket-based Web extension method according to an embodiment of the present application, and as shown in fig. 2, the frame structure of the WebSocket-based Web extension method 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 can use the adaptation layer to call the local service.

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

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

Step S301, a JS extension interface description file is expanded according to a format describe, and an adaptation layer code corresponding to the JS extension interface description file is generated;

Step S302, setting local service event monitoring;

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

Step S304, establishing two-way communication with the Web terminal;

step S305, registering a general message processing function;

step S306, an event monitoring callback channel is established;

Step S307, loops waiting for the request message of the Web terminal.

Fig. 4 is a flowchart of an execution flow of the WebSocket-based Web extension method at the Web end according to an embodiment of the present application, 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 side when a webpage runs;

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

Step S403, registering event monitoring required by the application;

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

In some embodiments, step S402 adds a JS expansion interface description file, and initializing the JS expansion interface includes:

The functions of the JS extension interface are mounted to a JS context;

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

Constructing message parameters;

each cancellation request message is assigned a unique identification.

In some of these embodiments, the event listening required for the registration application of step S403 includes:

Through the steps, the problem that the Web extension in the related technology needs to rely on the JS engine or the host with the JS engine, and when the JS engine or the host changes, the Web app cannot directly and normally run and needs to realize the extension again is solved, and the Web extension is realized without relying on the JS engine or the host thereof and only needs to be realized once.

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

The flow at the Web end is as follows:

a) Adding a packaged JS extension library in the head of a webpage, and automatically connecting a Websocket server when the webpage runs;

b) Adding a JS extension interface description file in the head of the webpage;

c) Initializing a JS extension interface;

d) Registering event monitoring of each module;

e) The application is developed using an extension interface.

The flow at the WebSocket Server end is as follows:

a) Writing a JS extension interface description;

b) Automatic adapter layer codes are realized;

c) Monitoring system service is set;

d) Registering a message processing function (adapter) of the expansion interface, and finally distributing a request by a WebSocket Server terminal through the monitoring container;

e) Establishing a WebSocket Server;

f) Registering a general message processing function, wherein the general message processing function is provided with an active request interface, an event monitoring adding interface and an event monitoring removing interface, and the description in a) is the active request interface and is distributed according to the participation in the message processing;

g) Establishing an event monitoring callback channel;

h) Loops waiting for Web requests or notifications.

Specifically:

The flow at the Web end comprises the following steps:

a) And adding the encapsulated JS extension library into the head of the webpage. When the webpage runs, the webpage runs first, initializes WebSocket and needs to do onpen, onerror, onmessage, onclose, send packaging work.

B) And adding a JS extension interface description file in the head part 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. The expansion interface is registered into the JS context according to the module, and then the expansion interface can be normally called.

D) Registering event monitoring of each module. In this step, registration is required after the connection between the Web terminal and the Websocket Server is confirmed to be successful, otherwise, the Web terminal stores a callback, but the related keys are not synchronized with the Websocket Server terminal.

E) The application is developed using an extension interface. The preparation work is completed and the development of the application can be started.

The flow at the WebSocket Server end comprises:

a) A JS expansion interface description is written. What module the extension interface is, what APIs under the module, and what parameters the various APIs have.

B) And automatically generating and realizing the adapter layer code. The writing script automatically analyzes the JS extension interface description, provides an API for registering the extension interface, and generates the null implementation of the adapter.

C) Monitoring of system services is set. The Web needs to register the state of some services, and WebSocket Server itself does not have, and needs to register with the 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 up with an API that automatically generates a registration extension interface in the adapter code.

E) And establishing a WebSocket Server. And the network terminal is in bidirectional communication with the Web terminal.

F) Registering the generic message handling function. The system comprises an active request interface, an event monitoring addition interface and an event monitoring removal interface. All that is described in relation to a) is an active request interface, which in its message processing will be distributed according to the participants.

G) And establishing an event monitoring callback channel. Mainly when the Web end registers a local service event, but when it happens, it needs to be notified to the Web end.

H) Loops waiting for Web requests or notifications. WebSocket activity is maintained.

In one embodiment of the present application, an interface is now required to obtain the time zone of a television system, for example.

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

1) First, a JS interface description needs to be written.

2) And analyzing the JS interface description through the script to generate or write the adapter code.

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) Monitoring of system services is set.

This interface does not have a scenario of snoop events. If other interfaces are needed, 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, and when the front end requests, the module, the sub-module, and the function are spliced by underlining, and the corresponding adapter is found by the key value under the condition that the function is transmitted as a parameter.

5) And establishing a WebSocket Server.

Any library, such as Libwebsockets, which is well-used for open sources can be obtained and built according to the specifications. And setting ports and bidirectional communication processing functions. The main work is as follows:

a) WebSocket context information preparation and service initiation.

The port is set, which may be 8989, the processing function of the protocol state is set, and a thread is started to service and wait for a message to come.

B) Processing of protocol states. Only the processing of a received message will be 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 put into a queue.

6) Message processing flow of the message queue of the Web end.

And starting a new thread, checking whether the message queue has the message, if so, taking out the messages one by one, and if not, waiting.

7) Generic message handling function registration

Before the message parsing, the general message processing function is explained. In actual operation, only registration is needed before the request. The general message processing is only controlPlatform, addPlatformListener, removePlatformListener. All API active requests are passed through the former, which is event listening to add or remove local system services or operating system services.

8) And analyzing and processing the front-end message.

When the message is sent from the front end and fetched for processing, what is first to be done is which generic function to dispatch to. In this example, it is distributed controlPlatform.

9) General message processing function (controlPlatform)

Analyzing the front-end message parameters, finding an expansion interface KEY, finding a corresponding adapter and executing.

The execution flow at the Web end:

1) And adding a JS extension library.

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

Each state callback has onpen, onerror, onmessage, onclose. Of which onmessage is the most important, this function triggers, representing that WebSocketServer is messaging.

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 global variable, then the timer is hung under sraftv, and finally the get_time_zone is hung under the timer, so that after development this can initiate the request by means of sraftv.

The second step of initialization is to set a unified send function for each extended function. When Web development this call extension function is equal to the call of this send function. This form can be used Promise and can be well developed asynchronously.

The third step of initialization is to construct message parameters. Firstly, parameters of general message processing are constructed, in this example controlPlatform, then Key parameters of an adapter are constructed, in this example sraftv _timer_get_timer_zone, if parameters exist in an expansion interface, the parameters can be described in a Json format, and in this example, the parameters are not described.

The fourth step of initialization is to identify a unique Id to each request. And stores its callback function according to this Id so that its callback can be found when WebSocket Server responds.

Specific code examples are as follows:

In the embodiment of the application, when the Web calls an extension API, converts the extension API into a character string message with a certain format according to a self-defined message protocol, sends the character string message to a local WebSocket server through a WebSocket technology, analyzes the message, then sends the message to a relevant adapter for processing, and then calls a local system service capability to realize a request, and if a result exists, returns the result to the Web end through the WebSocket technology.

Key technical points are as follows:

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

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

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

4) The Adaptor automatically generates the script and rapidly generates the Adaptor code, and only needs to pay attention to specific request realization.

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

1) The dependence of the Web extension on the JS engine or the host (browser) with the JS engine is broken. So that if running at a different browser vendor (for example), no extensions need to be made to the new browser.

2) The JS interface is used for description, so that front-end initialization and back-end adapter are in one-to-one correspondence, 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 very quick to start.

3) And initializing the expansion interface, so that a Web end developer can use the expansion interface in a traditional calling mode without learning cost. And by using Promise characteristics, asynchronous data acquisition and business logic are separated, so that a developer is focused on one of the transactions, and simultaneous consideration is not needed.

It should be noted that the steps illustrated in the above-described flow or 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 other than that illustrated herein.

The embodiment provides a Web extension device based on WebSocket, which is used for implementing the foregoing embodiments and preferred embodiments, and is not described in detail. As used below, the terms "module," "unit," "sub-unit," and the like may be a combination of software and/or hardware that implements a predetermined function. While the means described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.

Fig. 5 is a block diagram of a Web extension device based on WebSocket according to an embodiment of the present application, and as shown in fig. 5, the device 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 configured to expand the interface description file according to format describe JS, and generate an adaptation layer code corresponding to the JS expansion interface description file;

A setting module 512, configured to set local service event interception;

a first registration module 513 for registering a message processing function of the extension interface;

A first establishing module 514, configured to establish bidirectional communication with the Web terminal;

a second registration module 515 for registering the universal message processing function;

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

A waiting module 517, configured to wait for a request message of the Web end in a loop.

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

The first adding module 521 is configured to add the packaged JS extension library, and automatically establish a communication connection with the WebSocket server when the web page runs;

a second adding module 522, configured to add a JS extension interface description file, and initialize a JS extension interface;

A third registration module 523, configured to register event interception required by an application;

and a development module 524 for developing an application using the JS extension interface.

In some of these embodiments, the second adding module 522 includes:

a construction submodule for constructing message parameters;

In some of these embodiments, the third registration module 523 includes:

The above-described respective modules may be functional modules or program modules, and may be implemented by software or hardware. For modules implemented in hardware, the modules may be located in the same processor, or may be located in different processors in any combination.

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

The computer device may include a processor 71 and a memory 72 storing computer program instructions.

In particular, the processor 71 may include a Central Processing Unit (CPU), or an Application SPECIFIC INTEGRATED Circuit (ASIC), or may be configured as one or more integrated circuits that implement 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 comprise a hard disk drive (HARD DISK DRIVE, abbreviated HDD), floppy disk drive, solid state drive (Solid STATE DRIVE, abbreviated SSD), flash memory, optical disk, magneto-optical disk, magnetic tape, or universal serial bus (Universal Serial Bus, abbreviated USB) drive, or a combination of two or more of these. The 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 memory. In particular embodiments, memory 72 includes Read-Only Memory (ROM) and random access Memory (Random Access Memory RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (Programmable Read-Only Memory, abbreviated PROM), an erasable PROM (Erasable Programmable Read-Only Memory, abbreviated EPROM), an electrically erasable PROM (ELECTRICALLY ERASABLE PROGRAMMABLE READ-Only Memory, abbreviated EEPROM), an electrically rewritable ROM (ELECTRICALLY ALTERABLE READ-Only Memory, abbreviated EAROM), or a FLASH Memory (FLASH), or a combination of two or more of these. The RAM may be a Static Random-Access Memory (SRAM) or a dynamic Random-Access Memory (Dynamic Random Access Memory DRAM), where the DRAM may be a fast page mode dynamic Random-Access Memory (Fast Page Mode Dynamic Random Access Memory, FPMDRAM), an extended data output dynamic Random-Access Memory (Extended Date Out Dynamic Random Access Memory, EDODRAM), a synchronous dynamic Random-Access Memory (Synchronous Dynamic Random-Access Memory, SDRAM), or the like, as appropriate.

Memory 72 may be used to store or cache various data files that need to be processed and/or communicated, as well as possible computer program instructions for execution by processor 71.

The processor 71 implements any WebSocket-based Web extension method of the above-described embodiments by reading and executing the computer program instructions stored in the memory 72.

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 to each other through the bus 70 and perform communication with each other.

The communication interface 73 is used to enable communication between modules, devices, units, and/or units in embodiments of the application. The communication interface 73 may also enable data communication with other components such as external devices, image/data acquisition devices, databases, external storage, and image/data processing workstations, etc.

Bus 70 includes hardware, software, or both, coupling components of the computer device to each other. The Bus 70 includes, but is not limited to, at least one of a Data Bus (Data Bus), an Address Bus (Address Bus), a Control Bus (Control Bus), an Expansion Bus (Expansion Bus), and a Local Bus (Local Bus). By way of example, and not limitation, bus 70 may include a graphics acceleration interface (ACCELERATED GRAPHICS Port, abbreviated as AGP) or other graphics Bus, an enhanced industry standard architecture (Extended Industry Standard Architecture, abbreviated as EISA) Bus, a Front Side Bus (Front Side Bus, abbreviated as FSB), a HyperTransport (abbreviated as HT) interconnect, an industry standard architecture (Industry Standard Architecture, abbreviated as ISA) Bus, a wireless bandwidth (InfiniBand) interconnect, a Low Pin Count (LPC) Bus, a memory Bus, a micro channel architecture (Micro Channel Architecture, abbreviated as MCA) Bus, a peripheral component interconnect (PERIPHERAL COMPONENT INTERCONNECT, abbreviated as PCI) Bus, a PCI-Express (PCI-X) Bus, a serial advanced technology attachment (SERIAL ADVANCED Technology Attachment, abbreviated as SATA) Bus, a video electronics standards Association local (Video Electronics Standards Association Local Bus, abbreviated as 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 embodiments of the application have been described and illustrated with respect to a particular bus, the application contemplates any suitable bus or interconnect.

In addition, in combination with the WebSocket-based Web extension method in the above embodiment, the embodiment of the present application may be implemented by providing a computer-readable storage medium. The computer readable storage medium has stored thereon computer program instructions which when executed by a processor implement any of the WebSocket-based Web extension methods of the above embodiments.

The technical features of the above-described embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above-described embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The above examples illustrate only a few embodiments of the application, which are described in detail and are not to be construed as limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of protection of the present application is to be determined by the appended claims.

Claims

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

the method comprises the steps of expanding an interface description file according to a format describe JS, and generating an adaptation layer code corresponding to the JS expanded interface description file;

Setting local service event monitoring;

registering a message processing function of the expansion interface;

establishing two-way communication with a Web end;

registering a general message processing function;

Establishing an event monitoring callback channel;

circularly waiting for a request message of the Web terminal;

the execution flow of the method at the Web end comprises the following steps:

Event monitoring required by registration application;

Developing an application by using the JS extension interface;

The adding the JS extension interface description file and initializing the JS extension interface comprise:

The functions of the JS extension interface are mounted to a JS context;

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

Constructing message parameters;

Assigning a unique identifier to each cancellation request message;

wherein, event interception required for registering an application includes:

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

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

the waiting module is used for circularly waiting for the request message of the Web terminal;

The device further comprises a second execution unit, which is used for executing the flow at the Web end, wherein the second execution unit comprises:

the development module is used for developing an application by using the JS extension interface;

wherein the second adding module includes:

a construction submodule for constructing message parameters;

The allocation submodule is used for allocating unique identifiers for each cancellation request message;

wherein the third registration module includes:

3. 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 of claim 1 when the computer program is executed by the processor.

4. A computer-readable storage medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the WebSocket-based Web extension method according to claim 1.