Disclosure of Invention
In order to solve the defects in the prior art, embodiments of the present invention provide a method for mounting a function module, a mounting system, and a method for updating a mounting system, which achieve the purpose that any function module is mounted on a container at will, and provide a basis for flexibly updating (adding, deleting, and modifying) functions of an application program in units of function modules.
In a first aspect, an embodiment of the present invention provides a function module mounting system, which includes a container, a message framework, a function module, and a registration module, where,
the functional module is preset with registration information, the registration information comprises mounting data or a mounting interface of the functional module, and the mounting interface is used for acquiring the mounting data;
the registration module is used for registering the registration information to the message framework;
the container is used for acquiring the mounting data through the message frame and mounting the functional module according to the mounting data.
In an implementation manner of the embodiment of the present invention, the registration information further includes: a command number for identifying each of the functional modules. Further, the functional module includes: the plug-in function module and the non-plug-in function module; the plug-in type functional module has the same command number as the non-plug-in type functional module, or the plug-in type functional module has a different command number from the non-plug-in type functional module, or the mounting data of the plug-in type functional module is empty, or the mounting data of the plug-in type functional module is not empty. Or, further, the registration module is specifically configured to: registering the registration information of each of the functional modules to the message framework in a preset priority order, wherein if the registration information registered later and the registration information registered earlier have the same command number, the registration information registered earlier is replaced with the registration information registered later.
In another implementation manner of this embodiment, the mount data includes any one or more of the following data: an icon of the functional module, a text description of the functional module, and a skip logic of the functional module.
In yet another implementation manner of this embodiment, the container is specifically configured to send a mount message for requesting the mount data to the message framework; the message frame is specifically configured to send the mount data registered in the message frame to the container, or the message frame is specifically configured to acquire the mount data through the mount interface registered in the message frame and send the mount data to the container.
In another implementation manner of this embodiment, the container is specifically configured to send a mount message for requesting the mount data to the message framework; the message framework is specifically configured to send the mount interface registered in the message framework to the container; the container is further specifically configured to acquire the mount data through the mount interface.
In a second aspect, an embodiment of the present invention provides a method for mounting a functional module, including:
registering preset registration information in a functional module to a message framework, wherein the registration information comprises mounting data or a mounting interface of the functional module, and the mounting interface is used for acquiring the mounting data;
the container obtains the mounting data through the message frame, and mounts the functional module according to the mounting data.
In an implementation manner of this embodiment, the registration information further includes: a command number for identifying each of the functional modules. Further, the functional module includes: the plug-in function module and the non-plug-in function module; the plug-in type functional module has the same command number as the non-plug-in type functional module, or the plug-in type functional module has a different command number from the non-plug-in type functional module, or the mounting data of the plug-in type functional module is empty, or the mounting data of the plug-in type functional module is not empty. Or, further, the registering the preset registration information in the functional module to the message framework includes: registering the registration information of each of the functional modules to the message framework in a preset priority order, wherein if the registration information registered later and the registration information registered earlier have the same command number, the registration information registered earlier is replaced with the registration information registered later.
In another implementation manner of this embodiment, the mount data includes any one or more of the following data: an icon of the functional module, a text description of the functional module, and a skip logic of the functional module.
In another implementation manner of this embodiment, the acquiring, by the container, the mount data through the message framework includes: the container sends a message for requesting the mounting data to the message framework; the message framework sends the mounting data registered to the message framework to the container, or the message framework obtains the mounting data through the mounting interface registered to the message framework and sends the mounting data to the container.
In another implementation manner of this embodiment, the acquiring, by the container, the mount data through the message framework includes: the container sends mounting information for requesting the mounting data to the message framework; the message framework sends the mounting interface registered to the message framework to the container; the container obtains the mounting data through the mounting interface.
In a third aspect, an embodiment of the present invention provides a method for updating a functional module mount system based on the first aspect or the implementation manner thereof, where the method includes:
registering preset registration information in a functional module to be added to the message frame, wherein the registration information of the functional module to be added comprises mounting data or a mounting interface of the functional module to be added, and the mounting interface is used for acquiring the mounting data of the functional module to be added;
and the container mounts the functional module according to the mounting data of the functional module registered with the registration information in the message frame.
In an implementation manner of this embodiment, the function module to be added is a plug-in function module.
In another implementation manner of this embodiment, the registration information of the function module to be added further includes a command number for identifying the function module to be added; registering preset registration information in the functional module to be added to the message framework comprises the following steps: and if the command number of the functional module to be added is the same as the command number of the previously registered registration information, replacing the previously registered registration information with the registration information of the functional module to be added.
In another implementation manner of this embodiment, the mounting, by the container, the function module according to the mounting data of the function module in which the registration information is registered in the message framework includes: the container acquires mounting data of the functional module registered with the registration information in the message frame through the message frame, and then mounts the functional module according to the acquired mounting data; or the container acquires the mounting data of the functional module to be added through the message frame, and mounts the functional module according to the stored mounting data and the mounting data of the functional module to be added.
The adoption of the various embodiments of the invention has the following beneficial effects:
on one hand, the message framework 12 realizes the decoupling between the container 11 and the functional module 13, and achieves the purpose that the container 11 can mount any functional module at will. On the other hand, an architecture basis is provided for flexibly updating functions (including function addition, modification and deletion) by taking the function modules as units, so that when an application program is updated, for example, a complete installation package does not need to be developed, released, downloaded or installed, the flow and the development cost are saved, and the user experience is improved.
Detailed Description
Various aspects of the invention are described in detail below with reference to the figures and the detailed description. Well-known modules, units and their interconnections, links, communications or operations with each other are not shown or described in detail. Furthermore, the described features, architectures, or functions can be combined in any manner in one or more implementations. It will be understood by those skilled in the art that the various embodiments described below are illustrative only and are not intended to limit the scope of the present invention. It will also be readily understood that the modules or units, or steps, of the embodiments described herein and illustrated in the figures can be combined and designed in a wide variety of different configurations.
Fig. 1 is a block diagram of a function module mounting system according to an embodiment of the present invention, and referring to fig. 1, the mounting system 1 includes a container 11, a message framework 12, a function module 13, and a registration module 14, which are described below respectively.
In the present invention, a "functional module" (for example, the functional module 13) refers to a functional unit that performs a specific process or task in an application program. By way of example, a "functional module" may be a service, a rule, a global configuration, long connection management, short connection management, local service, and the like. In a more specific example, the functional modules may be pages, background logic (e.g., play music), and so forth.
In this embodiment, the functional module 13 is preset with registration information, where the registration information includes mounting data or a mounting interface of the functional module 13, and the mounting interface is used to obtain the mounting data. The mount data may include any one or more of the following data: icon of the function module, text description of the function module, skip logic of the function module, etc.
Optionally, in an implementation manner of this embodiment, the "mount data or mount interface of the functional module 13" is represented in the following manner: a command number for identifying the functional module 13 is set in the registration information of the functional module 13 (for example, the command number may be an integer value, and int type may be adopted in java implementation). That is, the correspondence relationship between the mount data/mount interface registered on the message frame 12 and the function module 13 can be determined by the correspondence relationship between the command number and the mount data/mount interface.
It should be noted that the functional module 13 in the present embodiment is not intended to represent a specific single functional module, and the description of the functional module 13 is applicable to any functional module in the mounting system 1. In other words, the mounting system 1 may include one or more functional modules, and for the description of each functional module and the related processing, please refer to the description and the related processing for the functional module 13.
In the present embodiment, the registration module 14 is configured to register the registration information of the function module 13 to the message framework 12.
Optionally, in an implementation manner of this embodiment, a static code segment may be added to the functional module 13, and corresponding registration information is preset in the static code segment. The registration module 14 registers the registration information of the function module 13 to the message framework 12 by executing (e.g., executing at application start-up) the static code section.
Optionally, in an implementation manner of the present embodiment, for a detailed description of the processing executed by the registration module 14, please refer to the following description in the method embodiment, which is not described in detail here.
In the present embodiment, the container 11 is used to acquire the mount data of the function module 13 through the message framework 12, and is used to mount the function module 13 according to the acquired mount data. .
Optionally, in an implementation manner of this embodiment, the container 11 is specifically configured to send a mount message for requesting mount data to the message framework 12. After receiving the mount message, the message framework 12 sends the mount data registered in the message framework 12 to the container 11 so that the container 11 can perform mount processing; alternatively, the message framework 12 acquires mount data through a mount interface registered in the message framework 12, and transmits the acquired mount data to the container 11 so that the container 11 performs mount processing.
Optionally, in an implementation manner of this embodiment, the container 11 is specifically configured to send a mount message for requesting mount data to the message framework 12; the message framework 12 is specifically configured to send, after receiving the mount message, the mount interface registered in the message framework 12 to the container 11; the container 11 acquires the mount data through the acquired mount interface.
It should be noted that, in a specific application of the present embodiment, the message framework 12 may exist in the form of a core library, and is a basis for mounting the function module 13 to the container 11. The container 11 may be an empty page or a blank area in a page (e.g., an empty page or a blank area in an android app project) that is used to provide a mounting point for the functional module to mount. The mount interface can be understood as an abstract interface, the definition of which is provided by the container 11, and the instantiation of which is realized by the functional module 13.
The embodiment of the invention provides a mounting system 1 for mounting a functional module 13 based on a container 11, a message frame 12 and a registration module 14, on one hand, the decoupling between the container 11 and the functional module 13 is realized through the message frame 12, and the purpose that any functional module can be mounted on the container 11 at will is achieved; on the other hand, an architecture basis is provided for flexibly updating functions (including function addition, modification and deletion) by taking the function modules as units, so that when an application program is updated, for example, a complete installation package does not need to be developed, released, downloaded or installed, the flow and the development cost are saved, and the user experience is improved.
Fig. 2 is a schematic view of a mounting process of a functional module mounting system according to an embodiment of the present invention, and fig. 3 is a schematic view of a flow of a functional module mounting method according to an embodiment of the present invention. The mounting method will be described below with reference to fig. 2 and 3.
Referring to fig. 3, the functional module mounting method includes:
30: and registering preset registration information in the functional module to the message framework. The registration information includes mounting data or a mounting interface of the functional module, the mounting interface is used for acquiring the mounting data, and the mounting data may include any one or more than one of the following data: icons of the functional modules, text descriptions of the functional modules, skip logic of the functional modules, and the like.
32: the container obtains the mounting data through the message frame and mounts the functional module according to the mounting data.
Optionally, in an implementation manner of this embodiment, as shown in fig. 2, the processing 30 includes: registration information preset in service a (a kind of functional module) and registration information preset in service B (a kind of functional module) are registered to the message framework 12. In order to distinguish which functional module the registration information registered to the message framework 12 belongs to, a command number for identifying the service a and a command number for identifying the service B may be included in the registration information of the service a and the service B, respectively.
Alternatively, in one implementation of the present embodiment, as shown in fig. 2, the container 11 and the message framework 12 may implement the process 32 in the following manner.
The first method is as follows: the container 11 sends a mount data request message to the message framework 12; then, the message framework 12 transmits the mount data registered to the message framework 12 to the container 11.
The second method comprises the following steps: the container 11 sends a mount data request message to the message framework 12; then, the message framework 12 acquires mount data through a mount interface registered to the message framework 12, and transmits the acquired mount data to the container 11.
The third method comprises the following steps: the container 11 sends a mount message for requesting mount data to the message framework 12; then, the message framework 12 sends the mount interface registered to the message framework 12 to the container 11; after that, the container 11 acquires mount data through the mount interface.
Of course, in the above three manners, the container 11 and the message framework 12 may also obtain the mounting data of a certain function module or a certain type of function module according to a predetermined rule. For example, if the message framework 12 actively notifies the container 11 of the command number of the newly registered function module when the function module is newly registered in the case where the container 11 has already mounted the function module, so that the container 11 indicates by the command number which function module's mounting data is acquired.
In a more specific implementation, the mount message may contain an empty list of functions. Taking the second method as an example, after receiving the mount message, the message framework 12 sends the function list to the mount interface of the service a according to the preset priority order (assuming that the priority of the service a is higher than that of the service B), and adds the mount data of the service a to the function list by operating the mount interface processing function of the service a. Then, the service a returns the function list to the message frame 12, the message frame 12 sends the function list containing the mount data of the service a to the service B, and the mount data of the service B is added to the function list by operating a mount interface processing function of the service B. Service B then returns the list of functions to the message framework 12 (if there are more functional modules, and so on). Finally, the message framework 12 returns the function list containing the mount data of the service a and the service B to the container 11, so that the container 11 mounts the service a and the service B.
In addition, in the implementation manner described above, a command number for identifying a container that sends the mount message may also be carried in the mount message, so as to determine to which container the function list is returned according to a correspondence between the command number and the function list. The mounting data of each function module is preferably stored in the function list according to the correspondence between the command number and the mounting data of each function module.
By adopting the method provided by the embodiment of the method, the decoupling between the container and the functional module is realized through the message framework, the aim that the container can mount any functional module at will is achieved, and an architecture basis is provided for flexibly updating (including function addition, modification and deletion) functions by taking the functional module as a unit.
Fig. 4A is a schematic diagram of a mounting process of a functional module mounting system according to an embodiment of the present invention. The functional module mounting system is different from the mounting system shown in fig. 2 in that the mounting system in fig. 4A includes a plug-in service C and a plug-in service D in addition to the two functional modules, i.e., service a and service B. The plug-in service C and the plug-in service D are plug-in type functional modules (i.e. functional modules implemented by installing plug-ins), and correspondingly, the service a and the service B are non-plug-in type functional modules ("non-plug-in type functional modules" may also be understood as built-in functional modules, i.e. functional modules in the application installation package).
The mount process shown in fig. 4A corresponds to two scenarios, the first scenario being: in the initialization stage of the application program, the application program is internally provided with a service A and a service B and is provided with plug-ins corresponding to a plug-in service C and a plug-in service D; the second scenario is: the application program is already hung on the service A and the service B, and the plug-ins corresponding to the plug-in service C and the plug-in service D are downloaded but not installed.
For the first scenario, fig. 4B is a flowchart illustrating a method for mounting a functional module according to an embodiment of the present invention, and meanwhile, may also be understood as a flowchart illustrating a method for updating the mounting system shown in fig. 2. Referring to fig. 4A and 4B, the method includes:
40: the registration information of service a, service B, plug-in service C and plug-in service D is registered to the message framework 12, for example by means of the aforementioned registration module 14.
Optionally, in an implementation manner of this embodiment, the registration information of the service a, the service B, the plug-in service C, and the plug-in service D is registered in the message frame 12 according to a preset priority order. Preferably, the non-plug-in function module has a higher priority, and the plug-in function module has a lower priority.
Optionally, in an implementation manner of this embodiment, the "registration information of the service a, the service B, the plug-in service C, and the plug-in service D" is expressed in the following manner: and setting command numbers for identifying each functional module in the registration information of the service A, the service B, the plug-in service C and the plug-in service D respectively. That is, which function module the registration information corresponds to is determined by the command number in the registration information.
In process 40, if the subsequently registered registration information has the same command number as the previously registered registration information, the previously registered registration information is replaced with the subsequently registered registration information.
For example, assume that the following first condition is satisfied: the plug-in service C has the same command number as the service A, and the plug-in service D has a different command number from the service A and the service B. At this time, in the process 40, since the plug-in service C has the same command number as the service a, the registration information of the service a is replaced (or, overwritten) with the registration information of the plug-in service C.
42: the container 11 mounts the function module based on the mounting data of the function module in which the registration information is registered in the message frame 12.
More specifically, process 42 includes: the container 11 acquires, through the message framework 12, the mount data of the functional module in which the registration information is registered in the message framework 12 (please refer to the process 32 for the acquisition method, which is not described herein); the container 11 mounts the function module according to the acquired mounting data.
Likewise, assuming that the aforementioned first condition is satisfied, the "functional module in which registration information is registered in the message framework 12" mentioned in the processing 42 includes the service B, the plug-in service C, and the plug-in service D, but does not include the service a, that is, the container 11 does not acquire the mount data of the service a, and finally, the container 11 only mounts the service B, the plug-in service C, and the plug-in service D, but does not mount the service a.
Obviously, as far as the plug-in service C is concerned, the plug-in service C enables the replacement of the service a. If the mounting data of the plug-in service C is not empty, the container 11 mounts the plug-in service C according to the mounting data of the plug-in service C, thereby realizing function updating; if the mount data of the plug-in service C is empty, the container 11 will neither mount the service C nor the service a, thereby realizing function deletion.
In addition, regarding the plug-in service D, if the mounting data of the plug-in service D is not empty, the container 11 mounts the plug-in service D according to the mounting data of the plug-in service D, and compared with the mounting system shown in fig. 2, the function increase is realized.
That is, in the embodiment of the present invention, by the way the plug-in is mounted, and by controlling the following factors: the command number of the plug-in is the same as or different from the command of the built-in function module, and the mounting data of the plug-in is null or non-null, so that the addition, deletion and modification of functions can be flexibly realized.
For the second scenario, fig. 4C is a schematic flowchart of a method for mounting a functional module according to an embodiment of the present invention, and meanwhile, may also be understood as a schematic flowchart of a method for updating the mounting system shown in fig. 2. Referring to fig. 4A and 4C, the method includes:
44: registration information (including mount data or a mount interface) preset in the plug-in service C and the plug-in service D is registered to the message framework 12, and the registration process is performed, for example, by the registration module 14. Before processing 44, the plug-ins corresponding to plug-in service C and plug-in service D are installed.
Optionally, in an implementation manner of this embodiment, similar to the process 40, a command number may also be included in the registration information of the plug-in service C and the plug-in service D, respectively. And, assuming that the aforementioned first condition is satisfied, the registration information of the plug-in service C replaces the registration information of the service a in the message framework 12.
46: the container 11 mounts the function module based on the mounting data of the function module in which the registration information is registered in the message frame 12.
Optionally, in one implementation of the present embodiment, after the processing 44, a request message is sent by the message framework 12 to the container 11 to trigger the container 11 to perform the processing 46.
Optionally, in an implementation manner of this embodiment, the processing 46 may include: the container 11 acquires, through the message framework 12, the mount data of the function module in which the registration information is registered in the message framework 12 (see the above description of the processing 32 for a specific acquisition manner), and then mounts the function module according to the acquired mount data. Wherein, assuming that the aforementioned first condition is satisfied, the functional module that has registered the registration information in the message framework 12 does not include the service a.
Optionally, in an implementation manner of this embodiment, the processing 46 may include: first, the container 11 acquires mount data of the plug-in service C and the plug-in service D through the message framework 12. The specific obtaining manner is similar to the obtaining manner in the foregoing process 32, except that the mounting data of the plug-in service C and the plug-in service D are obtained specifically here. For example, the message framework 12 adds the mount data of the plug-in service C and the plug-in service D to the function list containing the mount data of the service a and the plug-in service B, and then returns to the container 11. Then, the container 11 mounts the function module according to the stored mounting data and the mounting data of the plug-in service C and the plug-in service D. If the first condition is satisfied, the container 11 replaces the mount data of the service a with the mount data of the plug-in service C, and as a result, the container 11 does not mount the service a.
Those skilled in the art will appreciate that the embodiment shown in fig. 4C can achieve the same benefits as the embodiment shown in fig. 4B and will not be described in detail herein.
Comparing the mounting system shown in fig. 4A with the mounting system shown in fig. 2, it can be seen that the function addition, update and deletion of the mounting system can be realized by installing the plug-in service C and the plug-in service D. Since the plug-in service C and the plug-in service D can be independent of the application installation package, the plug-in service C and the plug-in service D can be collectively referred to as "function modules to be added". In addition, since the plug-in can be flexibly unloaded, the "function module to be added" can also be flexibly unloaded. For example, when the plug-in corresponding to the plug-in service D is uninstalled, the message framework 12 triggers the container 11 to retrieve the mounting data again, and then the functional module is re-mounted.
In various embodiments of the present invention, the number of plug-in type functional modules and non-plug-in functional modules is not limited.
By integrating various embodiments of the present invention, in a specific application scenario, only core functions can be implemented in an application installation package, that is, only a few core function modules are configured in the installation package (whether the core function modules are determined flexibly according to user requirements, development requirements, and the like, which is not limited by the present invention), so as to reduce the size of the installation package. Meanwhile, a function list can be provided for a user, the user selects to install or uninstall any function through the function list, and the customization of the function is realized by adopting various embodiments of the invention.
Through the above description of the embodiments, those skilled in the art will clearly understand that the present invention can be implemented by combining software and a hardware platform. With this understanding in mind, all or part of the technical solutions of the present invention that contribute to the background art may be embodied in the form of a software product, which can be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, a smart phone, or a network device, etc.) to execute the methods according to the embodiments or some parts of the embodiments.
The terms and expressions used in the specification of the present invention have been set forth for illustrative purposes only and are not meant to be limiting. It will be appreciated by those skilled in the art that changes could be made to the details of the above-described embodiments without departing from the underlying principles thereof. The scope of the invention is, therefore, indicated by the appended claims, in which all terms are intended to be interpreted in their broadest reasonable sense unless otherwise indicated.