Method, device and equipment for generating front-end function and readable storage medium

Abstract

The present disclosure relates to the technical field of computer, and discloses a method and device for generating front-end function of an application program, an equipment and a readable storage medium. The method comprises: reading bridge object information corresponding to the application program; when there is a newly added bridge object in the bridge object information, obtaining configuration information of the newly added bridge object; generating a calling instruction corresponding to the newly added bridge object based on the configuration information, and verifying whether the calling instruction successfully calls native information of the application program; when the calling instruction successfully calls the native information, generating a front-end function corresponding to the newly added bridge object based on the calling instruction, so as to call the native information of the application program through the front-end function. By implementing the present disclosure, it is not necessary to manually add the native code information of the newly added bridge object, the possibility of introducing human errors is reduced, the manual collaboration cost in the development process is reduced, the front-end function can be deployed at any time and is no longer limited to the release of the client, the hot update of the front-end function is realized, and the update efficiency is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and specifically to a method, apparatus, device, and readable storage medium for generating front-end functions. Background Technology

[0002] The current application (APP) development process includes client-side development and front-end development. Client-side development usually adopts native development methods, while front-end development usually adopts non-native development methods, such as developing as web pages and then embedding them into the APP for display.

[0003] However, when front-end developers implement APP functions using non-native development methods (such as H5), they need to register a new JS Bridge on the platform used to manage JS Bridges and communicate with client developers to manually add the native code of the new JS Bridge to the client. Moreover, the effectiveness of the new functions corresponding to the new JS Bridge depends on the release of the client. As a result, the development collaboration cost of adding new functions to the application front end is relatively high and the function update efficiency is slow. Summary of the Invention

[0004] In view of this, the present disclosure provides a method, apparatus, device and readable storage medium for generating front-end functions, so as to solve the problems of high development cost and slow function update efficiency of the prior art for adding new front-end functions.

[0005] According to a first aspect, this disclosure provides a method for generating a front-end function, comprising: reading bridge object information corresponding to an application; when a new bridge object exists in the bridge object information, obtaining configuration information of the new bridge object; generating a call instruction corresponding to the new bridge object based on the configuration information, and verifying whether the call instruction successfully calls back the native information of the application; when the call instruction successfully calls back the native information, generating a front-end function corresponding to the new bridge object, so as to call the native information of the application through the front-end function.

[0006] The front-end function generation method provided in this disclosure reads the bridge object information corresponding to the application. When a new bridge object is detected in the bridge object information, the configuration information of the new bridge object is automatically read, and a calling instruction is automatically generated based on the configuration information of the new bridge object. The calling instruction is used to invoke the native function of the application. This achieves automatic reading of the configuration information of the new bridge object, eliminating the need to manually add the native code information of the new bridge object, reducing the possibility of human error, and lowering the cost of manual collaboration during development. Simultaneously, the method verifies whether the calling instruction successfully calls back the native information of the application. When the verification is successful, a front-end function corresponding to the new bridge object is generated on the front-end page of the application, so that the native information of the application can be invoked through the front-end function. Therefore, the front-end function can be deployed at any time, no longer limited by client releases, achieving hot updates of the front-end function and improving update efficiency.

[0007] In conjunction with the first aspect, in the first embodiment of the first aspect, the configuration information includes parameter information and invocation information, the invocation instruction includes parameter definition instruction and information invocation instruction, and the step of generating an invocation instruction corresponding to the newly added bridge object based on the configuration information includes: generating a parameter definition instruction corresponding to the parameter information using dynamic bytecode; and generating an information invocation instruction corresponding to the invocation information using dynamic bytecode.

[0008] The front-end function generation method provided in this disclosure generates parameter definition instructions for new bridge objects through dynamic bytecode, thereby realizing the automatic generation of parameter definitions for new bridge objects and reducing the possibility of human-introduced parameter errors; it also generates information calling instructions through dynamic bytecode, so as to enable new bridge objects to call native information without the need to develop corresponding native code on the client side of the application.

[0009] In conjunction with the first embodiment of the first aspect, in the second embodiment of the first aspect, verifying whether the calling instruction successfully calls back the native information of the application includes: verifying whether the application has native parameters corresponding to the calling information, wherein the native parameters include package name, class name, and method name; when the application has native parameters corresponding to the calling information, it is determined that the verification of the calling instruction calling back the native information of the application is successful.

[0010] In conjunction with the second implementation of the first aspect, in the third implementation of the first aspect, the step of verifying whether the calling instruction successfully calls back the native information of the application further includes: when the application does not have native parameters corresponding to the calling information, determining that the verification of the calling instruction calling back the native information of the application has failed, and generating calling exception information.

[0011] The front-end function generation method provided in this disclosure verifies whether the application has corresponding native parameters to determine whether the calling instruction of the newly added bridge object can successfully call back the native information, thereby avoiding calling errors and ensuring the effective execution of subsequent calling instructions.

[0012] In conjunction with the second implementation of the first aspect, in the fourth implementation of the first aspect, after determining that the call instruction has successfully verified the application's native information, the method further includes: based on the package name, class name, and method name of the native function, calling the application's native information via reflection to obtain the successfully verified native information of the application.

[0013] The front-end function generation method provided in this disclosure calls the native information of the application through reflection, thereby realizing flexible calling of the native information. As a result, the launch of the front-end function no longer depends on the release of the application, improving the update efficiency of the front-end function.

[0014] In conjunction with the first aspect, in the fifth embodiment of the first aspect, the application includes a local configuration file for storing configuration information of the bridge object; after obtaining the configuration information of the newly added bridge object, the application further includes writing the configuration information of the newly added bridge object into the local configuration file.

[0015] The front-end function generation method provided in this embodiment writes the configuration information of the newly added bridge object into the local configuration file of the application, so as to realize the automatic reading and automatic writing of the configuration information of the newly added bridge object. Thus, the deployment of the front-end function is no longer limited by the version of the application and can flexibly support various historical versions.

[0016] In conjunction with the first aspect, in the sixth embodiment of the first aspect, generating the front-end function corresponding to the newly added bridge object includes: registering the function for the invocation instruction, generating the front-end function corresponding to the invocation instruction, and displaying the front-end function on the front-end page of the application.

[0017] The front-end function generation method provided in this embodiment registers the function after the calling instruction is successfully verified, thereby realizing the front-end function corresponding to the newly added bridge object, which makes it easier for users to perform function operations through the front-end page and improves the user experience.

[0018] According to a second aspect, embodiments of this disclosure provide a front-end function generation apparatus, comprising: a reading module for reading bridge object information corresponding to an application; an acquisition module for acquiring configuration information of a newly added bridge object when such an object exists in the bridge object information; a first generation module for generating a call instruction corresponding to the newly added bridge object based on the configuration information, and verifying whether the call instruction successfully calls back the native information of the application; and a second generation module for generating a front-end function corresponding to the newly added bridge object when the call instruction successfully calls back the native information, so as to call the native information of the application through the front-end function.

[0019] According to a third aspect, this disclosure provides an electronic device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the front-end function generation method described in the first aspect or any embodiment of the first aspect.

[0020] According to a fourth aspect, embodiments of this disclosure provide a computer-readable storage medium storing computer instructions for causing a computer to perform the front-end function generation method described in the first aspect or any embodiment of the first aspect.

[0021] It should be noted that the beneficial effects of the front-end function generation apparatus, electronic device, and computer-readable storage medium provided in the embodiments of this disclosure can be found in the description of the corresponding content in the front-end function generation method, and will not be repeated here. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a flowchart of a method for generating front-end functions according to some embodiments of the present disclosure;

[0024] Figure 2 This is another flowchart of a method for generating front-end functions according to some embodiments of the present disclosure;

[0025] Figure 3 This is another flowchart of a method for generating front-end functions according to some embodiments of the present disclosure;

[0026] Figure 4 This is a structural block diagram of a front-end function generation apparatus according to some embodiments of the present disclosure;

[0027] Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided according to some embodiments of the present disclosure. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0029] Currently, when front-end developers develop app front-end features using non-native development methods (such as H5), they need to register a new JS Bridge on the bridge object management platform and define the functionality and parameters of that JS Bridge. Simultaneously, front-end developers need to communicate and collaborate with client-side developers so that the client-side developers can manually add the native code for the new JS Bridge in the client-side. However, manual development is prone to errors; for example, inconsistencies in the definitions of the JSBridge between the front-end and client-side can lead to unusable front-end features, highlighting the unavoidable possibility of human-introduced errors.

[0030] Moreover, even though the front-end developers can deploy and go live at any time after completing the development of the new JS Bridge corresponding front-end functions, it still depends on the client to complete the definition and implementation of the JS Bridge. The new JS Bridge corresponding front-end functions will only take effect after the client is further released. For historical versions of the application, they still cannot use the new JS Bridge corresponding front-end functions.

[0031] Based on this, the disclosed technical solution automatically reads the configuration information for the JS Bridge on the bridge object management platform and automatically generates code for the JS Bridge, thus eliminating the need for manual development and reducing the possibility of human error. Simultaneously, it generates invocation instructions to call native information based on the JS Bridge configuration information, thereby reducing the cost of manual collaboration during development. Once the invocation instruction successfully calls back the application's native information, the instruction can be registered to generate a front-end function corresponding to the newly added bridge object on the application's front-end page. This front-end function can then call the application's native information, allowing for flexible deployment of the front-end function, no longer limited by client releases. Furthermore, all versions of the application can utilize the front-end function by automatically reading the configuration information for the JS Bridge on the bridge object management platform.

[0032] According to an embodiment of this disclosure, an embodiment of a method for generating front-end functions is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] This embodiment provides a method for generating front-end functions, which can be used in electronic devices such as mobile phones, tablets, and computers. Figure 1 This is a flowchart of a method for generating front-end functions according to some embodiments of this disclosure, such as... Figure 1 As shown, the process includes the following steps:

[0034] S11, Read the bridge object information corresponding to the application.

[0035] An application (APP) is software installed on an electronic device. A bridge object is an intermediary object that connects non-native and native information within an APP; it's essentially a JS Bridge. When implementing business pages on the APP front-end using non-native development methods, it's necessary to call native information. In this case, the implementation of each function on the page requires a JS Bridge as an "intermediary bridge" to connect the non-native and native information.

[0036] Bridge object information is used to characterize relevant information about the JS Bridge. This information may include the JS Bridge's identifier and configuration information. The identifier is used to ensure the uniqueness of the JS Bridge; different JS Bridges have different identifiers. The configuration information is used to characterize the native information that the JS Bridge needs to invoke and its own definitions.

[0037] Each bridge object corresponding to the app needs to be registered by the front-end developers in advance on the platform used to manage the JS Bridge, and the calling functions and parameter passing information of the JS Bridge need to be configured. For the configured JS Bridge, the platform managing the JS Bridge can store it in the form of an index or in the form of key-value pairs, without specific restrictions here.

[0038] The APP communicates with the platform that manages the JS Bridge. Each time it starts, it reads the JS Bridge information defined on the management platform and compares the read JS Bridge information with the JS Bridge information that exists locally to determine whether a new JS Bridge has been added.

[0039] S12, when a new bridge object is added to the bridge object information, obtain the configuration information of the new bridge object.

[0040] A newly added bridge object is a new JSBridge defined by front-end developers when creating new features. When a newly added bridge object is detected in the bridge object information, the app can further locate the new JSBridge based on its identifier to obtain its configuration information. This configuration information includes: the JS Bridge name, input parameters, return value, and native capability call definition. Specifically, the native capability call definition can include the package name, class name, and method name of the native function to ensure that the new JS Bridge can correctly call the native information.

[0041] In one specific implementation, upon startup, the app reads the identifiers of existing JSBridges on the platform managing the JS Bridge and compares them with the identifiers of existing JS Bridges locally to determine if a new JSBridge identifier exists. If the comparison confirms the existence of a new JS Bridge identifier on the platform, the app can then locate the new JS Bridge on the platform and read its configuration information. For example, if a new JS Bridge for obtaining MAC addresses is added, the app can read the configuration information of that JS Bridge.

[0042] S13, generate a call instruction corresponding to the newly added bridge object based on the configuration information, and verify whether the call instruction is successful by calling back the application's native information.

[0043] Invocation commands are programs or code used to retrieve native information from the app. The app automatically generates corresponding invocation commands based on the configuration information it reads for the newly added JS Bridge, using pre-defined code templates. These pre-defined code templates can be custom program generation templates or code generation templates, such as those based on index.js, package.json, or custom base file templates based on plop. By using these pre-defined command generation templates, the app can dynamically generate corresponding invocation commands based on the newly added JS Bridge configuration information.

[0044] Native information is used to represent the native code information of the APP client. Only when the calling instruction successfully calls back the APP's native information can its functionality be guaranteed. When generating the calling instruction corresponding to the newly added JS Bridge, the APP executes the calling instruction to invoke its native information. The success of the calling instruction in calling back the application's native information is verified by checking whether native information is returned. If the calling instruction successfully calls back the native information, step S14 is executed; otherwise, an exception warning is issued.

[0045] S14. When the call instruction successfully calls back the native information, a front-end function corresponding to the newly added bridge object is generated to call the application's native information through the front-end function.

[0046] If the executed command receives native information returned by the APP client, it indicates that the call command callback native information verification was successful. At this point, the APP can register the corresponding front-end function for the newly added JS Bridge. Subsequently, the APP's native information can be called through this front-end function. Thus, the corresponding function can be enabled without adding native code for the newly added JS Bridge in the APP client, thereby achieving hot updates of the front-end function.

[0047] The front-end function generation method provided in this embodiment reads the bridge object information corresponding to the application. When a new bridge object is detected in the bridge object information, the configuration information of the new bridge object is automatically read, and a calling instruction is automatically generated based on the configuration information of the new bridge object. This calling instruction invokes the native function of the application, thereby realizing the automatic reading of the configuration information of the new bridge object. There is no need to manually add the native code information of the new bridge object, reducing the possibility of human error and lowering the manual collaboration cost in the development process. At the same time, the method verifies whether the calling instruction successfully calls back the native information of the application. When the verification is successful, the front-end function corresponding to the new bridge object is generated on the front-end page of the application, so that the native information of the application can be invoked through the front-end function. Thus, the front-end function can be deployed at any time, no longer limited by the client release, realizing hot update of the front-end function and improving update efficiency.

[0048] This embodiment provides a method for generating front-end functions, which can be used in electronic devices such as mobile phones, tablets, and computers. Figure 2 This is a flowchart of a method for generating front-end functions according to some embodiments of this disclosure, such as... Figure 2 As shown, the process includes the following steps:

[0049] S21, Read the bridge object information corresponding to the application.

[0050] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.

[0051] S22, when a new bridge object is added to the bridge object information, obtain the configuration information of the new bridge object.

[0052] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.

[0053] S23, generate a call instruction corresponding to the newly added bridge object based on the configuration information, and verify whether the call instruction is successful by calling back the application's native information.

[0054] Specifically, the configuration information includes parameter information and call information, and the call instructions include parameter definition instructions and information call instructions. Accordingly, the above step S23 may include:

[0055] S231 uses dynamic bytecode to generate parameter definition instructions corresponding to the parameter information.

[0056] Parameter definition directives define the code for a new JS Bridge. The parameters for a new JS Bridge can include its name, input parameters, and return value. When the app calls the defined method of the JS Bridge, the corresponding parameter definition directives are generated dynamically based on the parameter information of the new JS Bridge using dynamic bytecode. For example, based on the name of the new JS Bridge, the corresponding definition code can be dynamically generated using dynamic bytecode.

[0057] S232 uses dynamic bytecode to generate information call instructions corresponding to the call information.

[0058] The information retrieval instruction indicates the addition of code from the JS Bridge to call native information from the app. The JS Bridge's retrieval information includes the package name, class name, and method name of the native information it needs to call. When the app calls the JS Bridge's defined methods, the corresponding code is automatically generated using dynamic bytecode based on the package name, class name, and method name of the native capabilities that the newly added JS Bridge needs to call.

[0059] S233, verify that the application has native parameters corresponding to the call information.

[0060] The native parameters include: package name, class name, and method name.

[0061] The native parameters differ for different native information; that is, the package name, class name, and method name are different. Therefore, the native information that the newly added JS Bridge needs to call can be determined by the native parameters. After generating the call instruction, the app attempts to call the app's native information through this instruction. If the app has native parameters corresponding to the native information, the newly added JS Bridge can successfully call back the native information.

[0062] The app verifies whether the native parameters corresponding to the call information exist in the app's native information. Specifically, it checks whether the package name, class name, and method name required for the new JS Bridge to be called exist in the app's native information. This determines whether the new JSBridge can successfully call back the app's native information. If the application has the native parameters corresponding to the call information, step S234 is executed; otherwise, step S235 is executed.

[0063] S234, It is determined that the native information verification of the calling instruction callback application was successful.

[0064] When the application has native parameters corresponding to the call information, it means that the call instruction successfully verifies the native information of the APP, that is, the native information of the APP can be successfully called back through the call instruction.

[0065] S235, determines that the verification of the native information of the application calling the instruction callback failed, and generates call exception information.

[0066] When the application lacks native parameters corresponding to the call information, it indicates that the verification of the native information of the APP failed, meaning that the native information of the APP cannot be retrieved through this call instruction. In this case, the APP can generate call exception information to remind the front-end developers to handle the exception.

[0067] As an optional implementation, after step S234, the above method may further include: based on the package name, class name, and method name, invoking the native information of the application through reflection to obtain the native information of the application that has successfully received a callback.

[0068] When calling back the app's native information, the corresponding native information is determined through reflection based on the package name, class name, and method name contained in the information call instruction. The app client can then return the corresponding native information, thus further confirming that the call instruction can successfully call back the app's native information.

[0069] By using reflection to call the application's native information, flexible access to native information is achieved. As a result, the launch of front-end functions no longer depends on the release of the application, thus improving the efficiency of front-end function updates.

[0070] S24. When the call instruction callback native information verification is successful, generate the front-end function corresponding to the newly added bridge object, so as to call the application's native information through the front-end function.

[0071] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.

[0072] The front-end function generation method provided in this embodiment generates parameter definition instructions for new bridge objects through dynamic bytecode, realizing the automatic generation of parameter definitions for new bridge objects and reducing the possibility of human-introduced parameter errors. It also generates information retrieval instructions through dynamic bytecode to enable new bridge objects to call native information, eliminating the need to develop corresponding native code on the application's client side. By verifying whether the application has the corresponding native parameters, it determines whether the call instructions for new bridge objects can successfully call back native information, avoiding call errors and ensuring the effective execution of subsequent call instructions.

[0073] This embodiment provides a method for generating front-end functions, which can be used in electronic devices such as mobile phones, tablets, and computers. Figure 3 This is a flowchart of a method for generating front-end functions according to some embodiments of this disclosure, such as... Figure 3As shown, the process includes the following steps:

[0074] S31, Read the bridge object information corresponding to the application.

[0075] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.

[0076] S32, when a new bridge object exists in the bridge object information, obtain the configuration information of the new bridge object.

[0077] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.

[0078] S33, writes the configuration information of the newly added bridge object to the local configuration file.

[0079] The application includes a local configuration file used to store configuration information for bridge objects. Specifically, the local configuration file is a file pre-configured by technical personnel within the application project. The app can write the configuration file it reads for a new JS Bridge into the local configuration file, and subsequently extract the configuration information of the new JS Bridge from the local configuration file to achieve automated development of the new JS Bridge. For example, if the new JS Bridge's function is to obtain the MAC address, the app can obtain the name of the new JS Bridge, such as "name":"app.getMacInfo"; the input parameters, such as "param":"Void"; the return value, such as "return":"Int"; and the native capability call definition, such as the package name "native_package":"com.xxx.common.utility", the class name "native_class":"NetworkUtils", and the method name "native_method":"getMacAddress", and write the JS Bridge's name, input parameters, return value, and native capability call definition into the local configuration file.

[0080] S34 generates a call instruction corresponding to the newly added bridge object based on the configuration information, and verifies whether the call instruction is successful by calling back the application's native information.

[0081] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.

[0082] S35, when the call instruction callback native information verification is successful, generate the front-end function corresponding to the newly added bridge object, so as to call the application's native information through the front-end function.

[0083] Specifically, step S35 above may include:

[0084] S351, Register the newly added bridge object and obtain the registration information corresponding to the newly added bridge object.

[0085] Registration information is used to declare the functions registered by the JS Bridge, such as obtaining the MAC address. Specifically, the app can register the corresponding functions for the newly added JS Bridge in the app's corresponding JS library by calling the registration method of the JS Bridge Manager, and obtain the registration information for the newly added bridge object.

[0086] S352, Deploy front-end functions corresponding to the registration information on the application's front-end page.

[0087] The newly added JS Bridge is deployed on the front-end page of the APP to generate front-end functions. Users can then obtain relevant information through these front-end functions, making it easier for them to perform functions through the front-end page. This achieves hot updates of front-end functions, and the release of front-end functions does not have to wait for the release of the APP client, thus improving the user experience.

[0088] The front-end functionality generation method provided in this embodiment writes the configuration information of the newly added bridge object into the application's local configuration file, enabling automatic reading and writing of the configuration information. This removes the limitations of the application version on the deployment of front-end functionality, allowing flexible support for various historical versions. After successful verification of the call command, the functionality is registered, thus realizing the front-end functionality corresponding to the newly added bridge object. This facilitates user operation through the front-end page, improving the user experience.

[0089] This embodiment also provides a front-end function generation apparatus, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0090] This embodiment provides a front-end function generation device, such as... Figure 4 As shown, it includes:

[0091] The reading module 41 is used to read the bridge object information corresponding to the application.

[0092] The acquisition module 42 is used to acquire the configuration information of the newly added bridge object when there is a newly added bridge object in the bridge object information.

[0093] The first generation module 43 is used to generate a call instruction corresponding to the newly added bridge object based on the configuration information, and to verify whether the call instruction successfully calls back the native information of the application.

[0094] The second generation module 44 is used to generate front-end functions corresponding to the newly added bridge object when the call instruction successfully calls back the native information, so as to call the native information of the application through the front-end functions.

[0095] As an optional implementation, the configuration information includes parameter information and calling information, and the calling instructions include parameter definition instructions and information calling instructions. Accordingly, the aforementioned first generation module 43 may include:

[0096] The first generation submodule is used to generate parameter definition instructions corresponding to the parameter information using dynamic bytecode.

[0097] The second generation submodule is used to generate information call instructions corresponding to the call information using dynamic bytecode.

[0098] The verification submodule is used to verify whether the application has native parameters corresponding to the call information. These native parameters include package name, class name, and method name.

[0099] The first determination submodule is used to determine whether the native information verification of the calling instruction callback application is successful when the application has native parameters corresponding to the calling information.

[0100] The second determination submodule is used to determine that the verification of the native information of the application failed when the application does not have native parameters corresponding to the call information, and to generate call exception information.

[0101] As an optional implementation, the first generation module 43 may further include:

[0102] The submodule is invoked to retrieve the application's native information via reflection, based on the package name, class name, and method name of the native functionality, and to obtain the application's native information upon successful callback.

[0103] As an optional implementation, the aforementioned front-end function generation apparatus may further include:

[0104] The write module is used to write the configuration information of newly added bridge objects to the local configuration file.

[0105] As an optional implementation, the second generation module 44 described above may include:

[0106] The registration submodule is used to register the functions of the call command, generate the front-end functions corresponding to the call command, and display the front-end functions on the front-end page of the application.

[0107] In this embodiment, the front-end function generation device is presented in the form of a functional unit. Here, a unit refers to an ASIC circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0108] Further functional descriptions of the above modules are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0109] The front-end function generation device provided in this embodiment automatically reads the configuration information of newly added bridge objects, eliminating the need to manually add the native code information of the newly added bridge objects. This reduces the possibility of human error and lowers the cost of manual collaboration during development. Simultaneously, when the call command successfully verifies the application's native information, a front-end function corresponding to the newly added bridge object is generated on the application's front-end page. This allows the application's native information to be called through the front-end function, enabling the front-end function to be deployed at any time, no longer limited by client releases. This achieves hot updates of the front-end function and improves update efficiency.

[0110] This disclosure also provides an electronic device having Figure 4 The device for generating the front-end functions shown.

[0111] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in an optional embodiment of this disclosure, such as... Figure 5 As shown, the electronic device may include: at least one processor 501, such as a central processing unit (CPU), at least one communication interface 503, memory 504, and at least one communication bus 502. The communication bus 502 is used to enable communication between these components. The communication interface 503 may include a display screen or a keyboard; optionally, the communication interface 503 may also include a standard wired interface or a wireless interface. The memory 504 may be high-speed volatile random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory 504 may also be at least one storage device located remotely from the aforementioned processor 501. The processor 501 may be combined with... Figure 4 The described apparatus has an application program stored in memory 504, and a processor 501 calls the program code stored in memory 504 to perform any of the above method steps.

[0112] The communication bus 502 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication bus 502 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0113] The memory 504 may include volatile memory, such as random-access memory (RAM); the memory may also include non-volatile memory, such as flash memory, hard disk drive (HDD) or solid-state drive (SSD); the memory 504 may also include a combination of the above types of memory.

[0114] The processor 501 can be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP.

[0115] The processor 501 may further include a hardware chip. This hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0116] Optionally, memory 504 is also used to store program instructions. Processor 501 can call the program instructions to implement the functions described in this application. Figures 1 to 3 The method for generating front-end functions shown in the embodiment.

[0117] This disclosure also provides a non-transitory computer storage medium storing computer-executable instructions that can execute the front-end function generation method in any of the above method embodiments. The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium may also include combinations of the above types of memory.

[0118] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for generating front-end functionality, characterized in that, include: Read the bridge object information corresponding to the application; When a new bridge object is added to the bridge object information, the configuration information of the new bridge object is obtained, and the configuration information includes parameter information and calling information. Based on the configuration information, a call instruction corresponding to the newly added bridge object is generated, and the call instruction is verified to successfully call back the native information of the application. When the invocation instruction successfully calls back the native information, a front-end function corresponding to the newly added bridge object is generated to call the native information of the application through the front-end function; The invocation instruction includes a parameter definition instruction and an information invocation instruction. The step of generating an invocation instruction corresponding to the newly added bridge object based on the configuration information includes: generating a parameter definition instruction corresponding to the parameter information using dynamic bytecode; and generating an information invocation instruction corresponding to the invocation information using dynamic bytecode.

2. The method according to claim 1, characterized in that, The verification of whether the invocation instruction successfully calls back the application's native information includes: Verify whether the application has native parameters corresponding to the call information, wherein the native parameters include package name, class name, and method name; When the application has native parameters corresponding to the call information, it is determined that the call instruction successfully verifies the native information of the application.

3. The method according to claim 2, characterized in that, The verification of whether the invocation instruction successfully calls back the application's native information also includes: When the application does not have native parameters corresponding to the call information, it is determined that the call instruction failed to verify the native information of the application and a call exception message is generated.

4. The method according to claim 2, characterized in that, After determining that the native information verification of the application is successful when the invocation instruction calls back, the process further includes: Based on the package name, class name, and method name, the native information of the application is invoked through reflection to obtain the native information of the application after a successful callback.

5. The method according to claim 1, characterized in that, The application includes a local configuration file, which is used to store the configuration information of the bridge object; After obtaining the configuration information of the newly added bridge object, the process further includes: Write the configuration information of the newly added bridge object into the local configuration file.

6. The method according to claim 1, characterized in that, The generation of front-end functions corresponding to the newly added bridge object includes: Register the newly added bridge object to obtain the registration information corresponding to the newly added bridge object; Deploy front-end functions corresponding to the registration information on the front-end page of the application.

7. A front-end function generation device, characterized in that, include: The reading module is used to read the bridge object information corresponding to the application. The acquisition module is used to acquire the configuration information of the newly added bridge object when there is a new bridge object in the bridge object information. The configuration information includes parameter information and calling information. The first generation module is used to generate a call instruction corresponding to the newly added bridge object based on the configuration information, and to verify whether the call instruction successfully calls back the native information of the application. The second generation module is used to generate a front-end function corresponding to the newly added bridge object when the call instruction callback to the native information verification is successful, so as to call the native information of the application through the front-end function; The calling instruction includes a parameter definition instruction and an information calling instruction. The first generation module includes: a first generation submodule, used to generate a parameter definition instruction corresponding to the parameter information using dynamic bytecode; and a second generation submodule, used to generate an information calling instruction corresponding to the calling information using dynamic bytecode.

8. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the front-end function generation method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the front-end function generation method according to any one of claims 1-6.

Images