Detailed Description
Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the disclosure are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
The term "include" and variations thereof as used herein is meant to be inclusive in an open-ended manner, i.e., "including but not limited to". Unless specifically stated otherwise, the term "or" means "and/or". The term "based on" means "based at least in part on". The terms "one example embodiment" and "one embodiment" mean "at least one example embodiment". The term "another embodiment" means "at least one additional embodiment". The terms "first," "second," and the like may refer to different or the same object. Other explicit and implicit definitions are also possible below.
As described above, since the H5 page is limited by the capability of the application-side web view component, the H5 can do a limited job without modification, and cannot implement a complex service scenario. How to abstract these complicated functional requirements into a uniform and simple set of interfaces, and simultaneously ensure the migratability, compatibility and extensibility, so that the developer of H5 can quickly iterate complex services is an urgent technical problem to be solved.
To address, at least in part, one or more of the above problems and other potential problems, example embodiments of the present disclosure propose a solution for a web page to invoke native functionality. In the scheme, in response to the first webpage view component starting to be instantiated, injecting a first programming language script into the running environment of the first webpage view component to obtain a first bridging object; responding to a first call from a first webpage and comprising a function module identifier, a module parameter and a first callback, and distributing a callback identifier for the first callback by a first bridging object; the first bridging object triggers second calling according to a preset format based on the callback identifier, the function module identifier and the module parameter; in response to the second call being triggered, the local module management component calls the local function module associated with the function module identifier for processing based on the module parameter to obtain a processing result; the local module management component triggers a third call based on the processing result and the callback identifier; and in response to the third call being triggered, the first bridging object triggers a first callback associated with the callback identification based on the processing result. In this way, the mobility and compatibility of the webpage calling the local function can be improved.
Hereinafter, specific examples of the present scheme will be described in more detail with reference to the accompanying drawings.
FIG. 1 shows a schematic diagram of an example of an information processing environment 100, according to an embodiment of the present disclosure. The information processing environment 100 may include a computing device 110.
Computing devices 110 include, for example, but are not limited to, personal computers, desktop computers, laptop computers, smart phones, personal digital assistants, and the like. The computing device 110 may run a hybrid application that may include one or more processing units, including, for example and without limitation, a first web page 111, a first web page view component 112, a local module management component 113, and a local function module 114. The native module management component 113 and the native function module 114 are located at the native or native (native) end, which are modules implemented, for example, by a native or native programming language (e.g., Java/Objective-C).
Regarding the first web page 111, which is, for example, an H5 web page, a script such as javascript may be included in the first web page 111.
Regarding the first web page view component 112, it is, for example, webview (android system) or UIWebview or wkwwebview (IOS system), etc. The local or native side may inject a first programming language script 115, such as a js script, into the runtime environment of the first web view component 112 after the first web view component 112 begins to instantiate to obtain the first bridge object 116.
After obtaining the first bridging object 116, the web site and the local or native site can communicate or call through the first bridging object. For example, the first web page 111 may be used to trigger a first call comprising a function module identification, a module parameter and a first callback in order to invoke a local function to obtain relevant data.
The first bridging object 116 is operable to assign a callback identification to a first callback in response to a first call from the first web page 111 comprising a function module identification, a module parameter and the first callback being triggered; and triggering a second call according to a predetermined format based on the callback identifier, the function module identifier and the module parameter. The predetermined format includes, for example, but is not limited to, a predetermined URL format.
With respect to the local module management component 113, it may be configured to, in response to the second call being triggered, call a local function module associated with the function module identification for processing based on the module parameter to obtain a processing result; and triggering a third call based on the processing result and the callback identifier.
With respect to the local function module 114, it may be used to execute relevant logic based on module parameters.
The first bridging object 116 may also be configured to trigger a first callback associated with the callback identification based on the processing result in response to the third call being triggered.
Therefore, the mobility and the compatibility of the webpage calling the local function can be improved.
FIG. 2 shows a flow diagram of a method 200 for a web page to invoke a native function, according to an embodiment of the present disclosure. For example, the method 200 may be performed by the computing device 110 as shown in FIG. 1. It should be understood that method 200 may also include additional blocks not shown and/or may omit blocks shown, as the scope of the present disclosure is not limited in this respect.
At block 202, the computing device 110 injects the first programming language script 115 in the runtime environment of the first web view component 112 to obtain the first bridge object 116 in response to the first web view component 112 beginning to instantiate. The first programming language script 115 includes, for example, but not limited to, a js script. For example, a first programming language script may be injected into the runtime environment of the first web view component 112 by a method such as webview. After injecting the first programming language script 115, the first web page view component 112 may execute the first programming language script 115 to obtain the first bridge object 116. The first bridge object 116 may be used to implement bridging between the web page side (e.g., js in the web page) and the local side, such as communication, calls, callbacks, and the like.
At block 204, in response to a first call from the first web page 111 including the function module identification, the module parameter, and the first callback being triggered, the first bridging object 116 assigns a callback identification to the first callback.
The first call is provided and implemented by, for example, the first bridge object 116, e.g., a method associated with the first bridge object 116, and the web site may implement the local function call by triggering the first call. The form of the first call includes, for example, but is not limited to, WosaiJServer. call ([ moduleServer ], [ parameters ], [ callback function ]), where WosaiJServer represents the first bridge object 116, call represents the identity of the first call, moduleServer represents the function module identity, parameter identity module parameter, and callback function represents the first callback.
In the first call, the first bridging object 116 may hold the first callback, e.g., add the first callback to a local callback pool, and assign a callback identification, e.g., denoted callbackId, to the first callback, and associate the first callback with the assigned callback identification. The manner of allocation may be in any suitable manner.
At block 206, the first bridging object 116 triggers a second call in a predetermined format based on the callback identification, the function module identification, and the module parameter.
In the first call, the first bridging object 116 may generate a second call from the function module identifier, the module parameter, and the callback identifier in a predetermined format. The predetermined format includes, for example, but is not limited to, a predetermined URL format, such as WusaJSJSM:// [ moduleName ]: CallbidBackId/[ jsonObj ], where WusalJSM can be used to indicate that the source of the message is the first bridge object 116, the moduleName includes the functional module identification, and the jsonObj includes the module parameter. Subsequently, the first bridging object 116 triggers the second call. With the URL standard format, the data structure is more standard.
At block 208, in response to the second call being triggered, the local module management component 113 invokes the local function module 114 associated with the function module identification for processing based on the module parameter to obtain a processing result. The second call may be implemented, for example, by local module management component 113.
The method by which the local module management component 113 invokes the local function module 114 associated with the function module identification for processing based on the module parameter will be described in detail below in connection with FIG. 3.
At block 210, the local module management component 113 triggers a third call based on the processing result and the callback identification.
In some embodiments, local module management component 110 may normalize the processing results, such as { data: xxx, code:1000, message: "some message" }, when an error occurs { data: nil, code: 403, message: "replay description of error" }, and then trigger a third call based on the normalized processing results and the callback identification.
The third call is provided and implemented by, for example, the first bridging object 116, such as a method associated with the first bridging object 116. The third call includes, for example, but is not limited to, wosaijsbridge. Wherein, WosaiJSBridge represents the first bridging object 116, handleprocessessagefrommative represents the identifier of the third call, callbackId represents the callback identifier, and responseInfo represents the processing result.
In some embodiments, there may be a low version of the web page view component for some systems, and when the data is returned by the third call in the above form, if the local side finds that the data is returned by trying to return, it will use a predetermined call mode such as webview.
At block 212, in response to the third call being triggered, the first bridge object 116 triggers a first callback associated with a callback identification based on the processing result.
For example, the first bridging object 116 may first determine whether a callback identifier in the third call's entry exists in the local callback pool, and if so, determine a first callback associated with the callback identifier, and trigger the first callback based on a processing result in the third call's entry, so that the web-side can receive the processing result.
Therefore, through a script injection mechanism without participation of webpage developers, the interaction specification is directly injected from the local or native terminal, so that the webpage developers do not need to pay attention to platform difference problems of communication mechanisms, callback management and the like between the webpage and the local, and the developed webpage can have better mobility and compatibility for different platforms.
FIG. 3 illustrates a flow diagram of a method 300 for a local module management component to invoke a local function module associated with a function module identification for processing based on a module parameter in accordance with an embodiment of the present disclosure. For example, the method 300 may be performed by the computing device 110 as shown in FIG. 1. It should be understood that method 300 may also include additional blocks not shown and/or may omit blocks shown, as the scope of the disclosure is not limited in this respect.
At block 302, the local module management component 113 determines a local function module identification associated with the function module identification based on the association between the function module identification and the local function module identification. The function module identification may be, for example, an identification common or standardized by the different platforms for the local function, and the local function module identification may be, for example, a unique identification of the current platform for the local function, such as, but not limited to, a class name of the local function module. The association between the functional module identification and the local functional module identification may be, for example, pre-generated in the local module management component 113.
At block 304, the local module management component 113 instantiates the local function module associated with the determined local function module identification to obtain the first instance.
At block 306, local module management component 113 passes the module parameters to the first instance for processing by the first instance based on the module parameters.
At block 308, local module management component 113 obtains the processing result from the first instance.
Therefore, the local function module can be determined and called in the local module management assembly based on the association between the function module identification and the local function module identification, so that the function module identification used when the webpage end calls the local function can be standardized for a plurality of platforms, the specific identification and calling process of the local function module are not required to be known, and the mobility and compatibility of the webpage to different platforms are improved.
Alternatively or additionally, in some embodiments, the first web page view component 112 may send a jump intent to a jump plug-in management component (not shown) in response to detecting a jump intent of a web page to a local function. The jumplist management component is located at a local or native level.
For example, the first web page view component 112 may determine whether a web page intent to jump to a local function is detected by determining whether the loaded link satisfies a predetermined jump intercept rule. The predetermined jump interception rule includes, for example, but is not limited to, "terminating-activated-self [ \ \ S ]. iwosai.com/home". The predetermined jumplitting link rule may be one or more items.
Subsequently, the jumping plug-in management component determines a jumping plug-in matching the jumping intention from the registered plurality of jumping plug-ins (not shown). The jump plug-in is located at the local or native layer.
In some embodiments, the jump plug-in management component may determine a jump rule matching the jump intention from among the plurality of registered jump rules. The jumplist rules are provided, for example, when the jumplist registers with the jumplist management component. Subsequently, the jumping plug-in management component may determine, based on the associations between the registered plurality of jumping rules and the registered plurality of jumping plug-ins, a jumping plug-in associated with the determined jumping rule as a jumping plug-in matching the jumping intention.
Furthermore, in some embodiments, the hopping rules can also be prioritized. The skip plug-in management component can sort the plurality of registered skip rules according to priority to obtain a sorting result, and determine the skip rule firstly matched with the skip intention as the skip rule matched with the skip intention based on the sorting result.
After determining the jump plug-in that matches the jump intent, the jump plug-in management component may retrieve the context associated with the first web page view component 112.
Next, the jumping plug-in management component instantiates the determined jumping plug-in based on the context. For example, the jumping plug-in management component may instantiate the jumping plug-in first and then pass the context to the instantiated jumping plug-in.
Therefore, by distinguishing the jump intents of the web pages to the local functions from the jump between the web pages and transferring the scheduling and implementation of the jump intents to the jump plug-in management component and the matched jump plug-in, the implementation logic of understanding non-H5 jump (for example, jump from H5 page to native page) and special H5 jump pre-or post-processing (for example, pre-login mechanism which must be completed in advance due to inconsistency of account systems before jumping, or supplement of local unique parameters on URL, and influence on local data possibly generated after jumping) by the web page view component is simplified, and the addition and deletion of the jump logic plays a good normative role, and the constraint of freely adjusting the series connection of business scenes is realized. In addition, the logic module capable of interactive communication with a web site such as H5 is designed as a plug-in, so that the container capability can be freely adjusted without changing the subject design and logic. The development of the plug-in is decoupled with the container main body, so that the stability of the container body can be effectively ensured.
Alternatively or additionally, in some embodiments, the first bridging object 116 may generate an association between the channel identification and the second callback in response to a notify register call from the first web page 111 including the channel identification and the second callback being triggered.
The notification registration call is implemented by the first bridge object 116, for example, including but not limited to, WosaiJSBridge.
In response to the second web view component beginning to instantiate, injecting a first programming language script in the runtime environment of the second web view component to obtain a second bridge object. Specific procedures are as described above.
In response to a notification send call from a second web page (not shown) including a channel identification and a message being triggered, the second bridging object triggers a local messaging call based on the channel identification and the message. The notification send call is implemented, for example, by a second bridge object, including, but not limited to, WosaiJSBridge1.sendNotification ([ channelName ], [ data ]), where WosaiJSBridge1 represents the second bridge object, sendNotification represents the identification of the notification send call, channelName represents the channel identification, and data represents the data or message. The local messaging call includes, for example, but not limited to, a sendnotification, whose entry includes a channel identification and a message.
In response to the local message send call being triggered, the local message processing module sends a channel identification and a message to the first bridging object 116.
The local message processing module may send the channel identification and message to all currently active web page view components, for example, by broadcast, and thus the first bridge object 116 in the first web page view component 112 may receive the channel identification and message.
Upon receiving the channel identification and the message, the first bridging object 116 may determine a second callback associated with the channel identification.
The first bridge object 116 may determine the second callback associated with the channel identification, for example, based on the association between the generated channel identification and the second callback described above.
Subsequently, the first bridge object 116 may trigger a second callback based on the message. The message may be passed to the first web page via the second callback, such that the first web page in the first web page view component receives the message from the second web page in the second web page view component.
Therefore, real-time message communication between different webpages rendered by different webpage view components can be realized, and the condition that data is written into a buffer area through one webpage and the same-name buffer area is read from another webpage for processing as in the prior art is not needed.
Alternatively or additionally, in some embodiments, the first web page view component 112 may cache a navigation bar style associated with the first web page.
Subsequently, in response to rolling back to the first web page from other web pages, the first web page view component 112 may render the navigation bar of the first web page based on the cached navigation bar style.
Therefore, when backspacing can be loaded back and forth among the webpages with different styles, the style of the navigation bar can be smoothly transited.
In addition, the first web page view component 112 can also automatically switch the action of the return button of the navigation bar to return the web page and exit the web page presentation according to the rollback degree of the web page, and add a direct closing function.
In addition, the first bridging object can realize the long callback method related to the page life cycle in advance, and the webpage side does not need to pay attention to specific realization and only needs to realize logic in the related life cycle callback function. The effect of the callback function is that business logic will be triggered each time the user sees the page (the first time the load is complete and the APP is re-invoked after the page state cuts it into the background), as in wosaijsbridge.
The interaction timing between the native side, the first bridge object and the H5 page is described below in conjunction with fig. 4.
The native side 401 injects (411) a first programming language script in the runtime environment of the first web view component in response to the first web view component starting to instantiate. The first web page view component executes (412) the first programming language script to obtain the first bridge object 402. The first bridge object 402 sends 413 a message to the H5 page 403 that the first bridge object 402 is ready.
Thereafter, the H5 page 403 triggers (414) a first call associated with the first bridge object 402, the first call's arguments including the function module identification, the module parameters, and the first callback. In response to the first call being triggered, the first bridging object 402 assigns (415) a callback identification to the first callback. The first bridging object 402 triggers (416) a second call associated with the native peer 401, the second call's arguments including a callback identification, a function module identification and module parameters, the second call may be in a predetermined URL format. In response to the second call being triggered, the native peer 401 (and in particular the local module management component therein) calls (417), based on the module parameters, the local function module associated with the function module identification to obtain a processing result.
Subsequently, the originating terminal 401 triggers (418) a third call associated with the first bridge object 402, the entry of the third call comprising the processing result and the callback identification.
In response to the third call being triggered, the first bridge object 402 triggers 419 a first callback associated with a callback identification, the argument of the first callback including the processing result, such that the H5 page 403 gets the processing result.
Fig. 5 illustrates a schematic block diagram of an example device 500 that may be used to implement embodiments of the present disclosure. For example, computing device 110 as shown in fig. 1 may be implemented by device 500. As shown, device 500 includes a Central Processing Unit (CPU) 501 that may perform various appropriate actions and processes according to computer program instructions stored in a Read Only Memory (ROM) 502 or computer program instructions loaded from a storage unit 508 into a Random Access Memory (RAM) 503. In the RAM 503, various programs and data required for the operation of the device 500 can also be stored. The CPU 501, ROM 502, and RAM 503 are connected to each other via a bus 504. An input/output (I/O) interface 505 is also connected to bus 504.
A number of components in the device 500 are connected to the I/O interface 505, including: an input unit 506 such as a keyboard, a mouse, a microphone, and the like; an output unit 507 such as various types of displays, speakers, and the like; a storage unit 508, such as a magnetic disk, optical disk, or the like; and a communication unit 509 such as a network card, modem, wireless communication transceiver, etc. The communication unit 509 allows the device 500 to exchange information/data with other devices through a computer network such as the internet and/or various telecommunication networks.
The various processes and processes described above, such as the method 200 and 400, may be performed by the central processing unit 501. For example, in some embodiments, the method 200-400 may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 508. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device 500 via the ROM 502 and/or the communication unit 509. When the computer program is loaded into RAM 503 and executed by CPU 501, one or more of the acts of method 200 and 400 described above may be performed.
The present disclosure relates to methods, apparatuses, systems, electronic devices, computer-readable storage media and/or computer program products. The computer program product may include computer-readable program instructions for performing various aspects of the present disclosure.
The computer readable storage medium may be a tangible device that can hold and store the instructions for use by the instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device, such as punch cards or in-groove projection structures having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein is not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses through a fiber optic cable), or electrical signals transmitted through electrical wires.
The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a respective computing/processing device, or to an external computer or external storage device via a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. The network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing/processing device.
The computer program instructions for carrying out operations of the present disclosure may be assembler instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, the electronic circuitry that can execute the computer-readable program instructions implements aspects of the present disclosure by utilizing the state information of the computer-readable program instructions to personalize the electronic circuitry, such as a programmable logic circuit, a Field Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA).
Various aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.
These computer-readable program instructions may be provided to a processing unit of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable medium storing the instructions comprises an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
Having described embodiments of the present disclosure, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein were chosen in order to best explain the principles of the embodiments, the practical application, or technical improvements to the techniques in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.