CN113849252B - Mini program multi-screen display method, host system supporting mini program multi-screen display, and client device - Google Patents

Abstract

The application provides an applet multi-screen display method, a host system supporting applet multi-screen display and a client device. The small program multi-screen display method comprises the following steps: monitoring a jump event of a target applet, wherein the target applet is parasitized in a target host application, the target host application is loaded in a target client device, the target client device comprises a plurality of display screens, the host application comprises a plurality of page management units, and one page management unit is configured to manage pages displayed by the applet on one display screen; after the jump event is monitored, determining a target page management unit from the plurality of page management units; and acquiring target page resource data based on the page management unit and displaying the target page resource data on a target display screen through a view unit, wherein the target display screen corresponds to the target page management unit.

Description

Mini program multi-screen display method, host system supporting mini program multi-screen display and client device

Technical Field

The present application relates to the field of mini-program technology, and in particular to a mini-program multi-screen display method, a host system supporting mini-program multi-screen display, and a client device.

Background technique

In the Internet age, people need to install APPs for every need. On the one hand, more and more APPs occupy a large amount of storage space on client devices; on the other hand, every time the client device system is upgraded or updated, the APPs installed in the client device must be reinstalled, which brings great inconvenience to people.

Mini Program is an application developed based on a specific programming language and can be used without downloading and installing. The biggest feature of Mini Program is its convenience. Users do not need to manually install Mini Program in the operating system of the client device. Mini Program relies on large APP as a carrier for use.

In the prior art, most mini program solutions only support single-screen devices, and there is no technical solution that can adapt mini programs to multi-screen devices.

Summary of the invention

In order to solve the technical problem that the mini program solution in the prior art cannot support multi-screen devices, the present application discloses a mini program multi-screen display method, a host system supporting mini program multi-screen display, and a client device.

The mini-program multi-screen display method includes: monitoring the jump event of the target mini-program, wherein the target mini-program is parasitic in the target host application, the target host application is loaded in the target client device, the target client device includes multiple display screens, the host application includes multiple page management units, and a page management unit is configured to manage the page displayed by the mini-program on a display screen; when the jump event is monitored, determining the target page management unit from the multiple page management units; and obtaining target page resource data based on the page management unit and displaying the target page resource data on the target display screen through the view unit, wherein the target display screen corresponds to the target page management unit.

In some embodiments, each of the plurality of page management units manages a page of a display screen corresponding thereto using a stack structure.

In some embodiments, each page management unit includes a routing file, which defines the rules for page jumps on the display screen corresponding to the page management unit, and each routing file includes several routing interfaces. Obtaining the target page resource data through the page management unit includes: calling the target routing interface that matches the jump event to obtain the target page resource data, wherein the target routing interface belongs to the target page management unit.

In some embodiments, wherein the client device includes a first display screen and a second display screen, the multiple page management units include: a first page management unit, configured to manage the pages displayed by the mini-program on the first display screen, including a first page stack, the first page stack including a predetermined number of page instances, and the page instances in the first page stack are preset to correspond to the first display screen; and a second page management unit, configured to manage the pages displayed by the mini-program on the second display screen, including a second page stack, the second page stack including a predetermined number of page instances, and the page instances in the second page stack are preset to correspond to the second display screen.

In some embodiments, when the object of the user behavior that triggers the page jump event is the first display screen, the target page management unit is the first page management unit, and the target display screen is the first display screen; when the object of the user behavior that triggers the page jump event is the second display screen, the target page management unit is the second page management unit, and the target display screen is the second display screen.

In some embodiments, when the object of the user behavior that triggers the page jump event is one of the first display screen and the second display screen, the target page management unit includes the first page management unit and the second page management unit, and the target display screen includes the first display screen and the second display screen.

In some embodiments, calling the target routing interface that matches the jump event to obtain the target page resource data includes: retrieving the target page resource data from a target storage unit, wherein the target storage unit is used to store data about the mini program, and the data includes data of the first page instance and data of the second page instance.

In some embodiments, the first page management unit is executed by a worker module of the applet; and the second page management unit is executed by a native module of the host application.

In some embodiments, the first page management unit is executed by a worker module of the applet; and the second page management unit is executed by a worker module of the applet.

In some embodiments, wherein the jump event includes the URL address of the target page, the mini-program multi-screen display method further includes: parsing the URL address contained in the jump event and obtaining a route matching the URL address, wherein the route matching the URL address is the target route.

The host system supporting dual-screen display of mini-programs includes: a view unit, configured to display the page resource data of the mini-program parasitic in the host system as a page on the display screen of the client device, and to generate an event that triggers a page jump based on the user's behavior on the page; a logic unit, configured to receive event feedback from the view unit, obtain the page data of the mini-program based on the event feedback and send the page data to the view unit to display the page data on the display screen through the view unit, wherein the client device includes multiple display screens, and the logic unit can control the pages displayed by the mini-program on the multiple display screens through the multiple page management units, and one page management unit is configured to manage the pages displayed by the mini-program on one display screen.

In some embodiments, each of the plurality of page management units manages a page of a display screen corresponding thereto using a stack structure.

In some embodiments, each page management unit includes a routing file, which defines the rules for page jumps on the display screen corresponding to the page management unit, and each routing file includes several routing interfaces. Obtaining the target page resource data through the page management unit includes: calling the target routing interface that matches the jump event to obtain the target page resource data, wherein the target routing interface belongs to the target page management unit.

In some embodiments, wherein the client device includes a first display screen and a second display screen, the multiple page management units include: a first page management unit, configured to manage the pages displayed by the mini-program on the first display screen, including a first page stack, the first page stack including a predetermined number of page instances, and the page instances in the first page stack are preset to correspond to the first display screen; and a second page management unit, configured to manage the pages displayed by the mini-program on the second display screen, including a second page stack, the second page stack including a predetermined number of page instances, and the page instances in the second page stack are preset to correspond to the second display screen.

In some embodiments, when the object of the user behavior that triggers the page jump event is the first display screen, the target page management unit is the first page management unit, and the target display screen is the first display screen; when the object of the user behavior that triggers the page jump event is the second display screen, the target page management unit is the second page management unit, and the target display screen is the second display screen.

In some embodiments, when the object of the user behavior that triggers the page jump event is one of the first display screen and the second display screen, the target page management unit includes the first page management unit and the second page management unit, and the target display screen includes the first display screen and the second display screen.

In some embodiments, calling the target routing interface that matches the jump event to obtain the target page resource data includes: retrieving the target page resource data from a target storage unit, wherein the target storage unit is used to store data about the mini program, and the data includes data of the first page instance and data of the second page instance.

In some embodiments, the first page management unit is managed by the framework of the applet; and the second page management unit is managed by the native module of the host system.

In some embodiments, the first page management unit is managed by the framework management of the applet; and the second page management unit is managed by the framework management of the applet.

The client device includes: a memory storing at least one instruction set; and a processor communicatively connected to the memory and the display. When the client is running, the processor reads and runs the at least one instruction set and executes the mini-program dual-screen display method described in the present application according to the instructions of the at least one instruction set, thereby controlling the pages displayed on different display screens of the client device.

The mini-program multi-screen display method, host system supporting mini-program multi-screen display, and client device provided in the present application support multi-screen display of mini-program pages by creating multiple page stacks within the mini-program framework. Developers only need to develop one mini-program, which reduces the difficulty for developers. When updating the mini-program, only one mini-program needs to be updated, which makes it easier to update synchronously. Each page stack includes its own page routing interface, so each screen can support multiple pages and jumps between pages. The design of multiple page stacks can enable the mini-program to support the same page starting on different screens. Different screens correspond to different page stacks. There is no need for communication between the routing interfaces of different page stacks, which avoids various problems caused by communication between interfaces.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of this specification, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

FIG1 is a schematic diagram showing a hardware structure of a client device provided according to an embodiment of the present application;

FIG2 shows the architecture of a small program provided according to an embodiment of the present application;

FIG3 shows a page management structure of a small program that only supports single-screen display according to an embodiment of the present application;

FIG4 shows a page management structure of a mini-program provided according to an embodiment of the present application;

FIG5 is a schematic diagram showing a page management unit managing pages of a display screen according to an embodiment of the present application;

FIG6 is a schematic diagram showing a page management unit managing pages of a display screen according to an embodiment of the present application; and

FIG. 7 shows a flowchart of a method for displaying a mini-program on multiple screens according to some embodiments of the present application.

Detailed ways

The following description provides specific application scenarios and requirements of the present application, with the purpose of enabling those skilled in the art to make and use the content in the present application. It will be apparent to those skilled in the art that various local modifications to the disclosed embodiments are apparent, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present application. Therefore, the present application is not limited to the embodiments shown, but to the widest scope consistent with the claims.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting.

In view of the following description, these and other features of the present application, as well as the operation and function of the related elements of the structure, and the economy of the combination and manufacture of the parts can be significantly improved. With reference to the accompanying drawings, all of which form a part of this application. However, it should be clearly understood that the drawings are only for the purpose of illustration and description and are not intended to limit the scope of this application.

The following description may significantly improve these and other features of the present application, as well as the operation and function of the relevant elements of the structure, and the combination of components and the economic efficiency of manufacturing. All of these refer to the accompanying drawings to form a part of this application. However, it should be clearly understood that the drawings are for illustration and description purposes only and are not intended to limit the scope of the present application. It should also be understood that the drawings are not drawn to scale.

The present application provides a method for displaying a mini-program on multiple screens, a host system supporting displaying a mini-program on multiple screens, and a client device.

As an example, Fig. 1 shows a schematic diagram of a hardware structure of a client device 100 provided according to an embodiment of the present application. Referring to Fig. 1 , the client device 100 may include a memory 230 and a processor 220 .

The memory 230 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 232, a read-only memory (ROM) 234, or a random access memory (RAM) 236. The memory 230 also includes at least one instruction set stored in the data storage device. The instruction set is a computer program code, and the computer program code may include a program, a routine, an object, a component, a data structure, a process, a module, etc. for executing the method shown in the present application.

The processor 220 communicates with the memory 230 via the internal communication bus 210. At least one processor 220 is used to execute the at least one instruction set mentioned above. When at least one processor 220 executes the at least one instruction set mentioned above, the client device 100 implements the mini-program multi-screen display method shown in this application. The processor 220 can execute some or all of the steps included in the method shown in this application. The processor 220 can be in the form of one or more processors. In some embodiments, the processor 220 can include one or more hardware processors, such as a microcontroller, a microprocessor, a reduced instruction set computer (RISC), an application-specific integrated circuit (ASIC), an application-specific instruction set processor (ASIP), a central processing unit (CPU), a graphics processing unit (GPU), a physical processing unit (PPU), a microcontroller unit, a digital signal processor (DSP), a field programmable gate array (FPGA), an advanced RISC machine (ARM), a programmable logic device (PLD), any circuit or processor capable of performing one or more functions, etc., or any combination thereof. For illustration purposes only, only one processor 220 is described in the client device 100 in this application. However, it should be noted that the client device 100 in the present application may also include multiple processors, and therefore, the operations and/or method steps disclosed in the present application may be performed by one processor as described in the present application, or may be performed jointly by multiple processors. For example, if the processor 220 of the client device 100 in the present application performs step A and step B, it should be understood that step A and step B may also be performed jointly or separately by two different processors 220 (for example, the first processor performs step A, the second processor performs step B, or the first and second processors perform steps A and B together).

In some embodiments, the client device 100 may further include a communication port 250 and an internal communication bus 210. The communication port 250 is used for data communication between the client device 100 and the outside world. The internal communication bus 210 may connect different system components, including a memory 230 and a processor 220.

In some embodiments, the client device 100 may also include an I/O component 260. The I/O component 260 supports input/output between the client device 100 and other components.

In some embodiments, the I/O component 260 may include a display. The display may receive instructions from the processor 220 and display data as a human-computer interaction interface on the display.

As an example, FIG2 shows an architecture of a small program provided according to an embodiment of the present application. The architecture of the small program can be integrated in the host system 200 in the form of a framework document. The host system 200 is installed in the client device 100.

The host system 200 may be an application (APP). The application may include computer program code. The computer program code may include, but is not limited to, programs, routines, objects, components, data structures, processes, modules, etc. The operating system loaded in the client device 200 may provide the host system 100 with the environment required for its operation.

As an example, the host system 200 may be an open platform. The open platform enables external programs to increase the functionality of the open platform or use the resources of the open platform by disclosing its application programming interface (API) or function, without changing the source code of the open platform. Through the API or function disclosed by the open platform, external programs can access the open platform. The open platform can provide a runtime environment (runtime) for running external programs. That is, when an external program is connected to the open platform, the runtime of the open platform can run the code of the external program. As an example, the open platform may include, but is not limited to, a digital life open platform, a social open platform, a shopping open platform, a game open platform, a content platform, and the like. The external program refers to a program outside the open platform. As an example, the external program may include, but is not limited to, mobile applications, website applications, public accounts, third-party platforms, and the like outside the open platform. In some embodiments, the external program is a mini-program.

For ease of description, in the following description of this application, "mini program" refers to an external program that is connected to the open platform through the open API or function. The mini program may be developed based on the host APP. For example, the host APP may be XX social software, and the mini program may be a mini program or H5 developed based on the environment of the XX social software and connected to the XX social software. For another example, the host APP may be XX payment software, and the mini program may be a merchant or service mini program developed based on the XX payment software and connected to the XX payment software.

In some embodiments, the host system 200 may include a native application (Native Application, referred to as Native APP). The Native APP may run based on a local operating system. In some embodiments, the applet may include a web application (Web Application, referred to as Web APP) developed based on the Native APP. The Web APP may run based on a browser.

Specifically, the applet architecture shown in FIG. 2 may include a view unit 001 and a logic unit 002 .

The view unit 001 is configured to display the page resource data of the applet parasitic in the host system 200 as a page on the display screen of the client device 100, and to generate an event triggering a page jump based on the user's behavior on the page.

The logic unit 002 is configured to receive event feedback from the view unit 001 , obtain page data of the applet based on the event feedback and send the page data to the view unit 001 so as to display the page data on the display screen through the view unit 001 .

As an example, FIG3 shows a page management structure of a small program that only supports single-screen display according to an embodiment of the present application. The page routing of the small program is managed by the framework of the small program. The framework maintains all pages in the form of a stack. As a data structure, a stack is a special linear table that can only perform insertion and deletion operations at one end. It stores data according to the principle of last-in-first-out. The first data entered is pushed to the bottom of the stack, and the last data entered is at the top of the stack. When data needs to be read, data is popped from the top of the stack (the last data is read out first). The page interaction of the small program is also completed through the stack. When the small program is initialized, a new page is pushed into the stack; when a new page is opened, a new page is pushed into the stack; when the page is redirected, the current page is popped out of the stack and the new page is pushed into the stack; when the page returns, the page is continuously popped out of the stack until the new page is pushed into the stack; when the tab is switched, all pages are popped out of the stack, leaving only the new tab page; when reloading, all pages are popped out of the stack, leaving only the new page. Using the architecture shown in FIG3 to maintain the pages displayed by the small program, it is possible to support the switching of multiple pages of the small program, but only one page (the page at the top of the stack) can be displayed on the display screen at the same time.

According to the foregoing description, the client device 100 may include a display. The display may receive instructions from the processor 220 and display data as a human-computer interaction interface on the display. In some embodiments, the client device 100 includes multiple display screens. In some embodiments, the multiple display screens may be two screens displayed on one display through a split screen technology. In some embodiments, the multiple display screens may be screens displayed on different displays respectively. For example, as shown in FIG. 2 , the client device may include a first display screen 110 and a second display screen 120. The first display screen 110 and the second display screen 120 may belong to different displays.

When the client device 100 has multiple display screens, it is not possible to display different page contents on different display screens of the client device 100 using the applet architecture shown in FIG. 3 .

As an example, FIG4 shows a page management structure of a mini-program provided according to an embodiment of the present application. FIG4 shows a plurality of page management units 400. A page management unit 400 is configured to manage pages displayed by the mini-program on a display screen. The logic unit may control the pages displayed by the mini-program on the plurality of display screens through the plurality of page management units. As an example, in the page management structure shown in FIG4, each of the plurality of page management units 400 uses a stack structure to manage the pages of the display screen corresponding thereto.

Taking the client device 100 including the first display screen 110 and the second display screen 120 as an example, the plurality of page management units may include a first page management unit 400 - 1 and a second page management unit 400 - 2 .

The first page management unit 400-1 may be configured to manage the pages displayed by the applet on the first display screen 110. The first page management unit 400-1 may include a first page stack. The first page stack includes a predetermined number of page instances. The page instances in the first page stack are preset to correspond to the first display screen 110. For example, the first display screen 110 may be the home screen of the applet, and the page instances in the first page stack may be page instances of the home screen, such as home screen page a, home screen page b, home screen page c, and so on. The first page stack is used to maintain the page display of the home screen and jump between pages.

The second page management unit 400-2 is configured to manage the pages displayed by the applet on the second display screen 120. The second page management unit 400-2 may include a second page stack. The second page stack includes a predetermined number of page instances. The page instances in the second page stack are preset to correspond to the second display screen 120. For example, the second display screen 110 may be an extended sub-screen of the applet, and the page instances in the second page stack may be page instances of the sub-screen, such as sub-screen page a, sub-screen page b, sub-screen page c, and so on. The second page stack is used to maintain the page display of the sub-screen and jump between pages.

In some embodiments, when the object of the user behavior that triggers the page jump event is one of the first display screen 110 and the second display screen 120, the target page management unit includes the first page management unit 400-1 and the second page management unit 400-2, and the target display screen includes the first display screen 110 and the second display screen 120. As an example, FIG5 shows a schematic diagram of managing the pages of a display screen by a page management unit provided in an embodiment of the present application. When the user operates the first display screen 110, for example, the user clicks on an icon button on the first display screen or adds some text content on the first display screen, according to the jump event triggered by the user behavior, the logic unit can control the page jump on the first display screen through the first page management unit, and control the page jump on the second display screen through the second page management unit. That is, when the user operates a display screen, the page displayed on the first display screen and the page displayed on the second display screen will both jump.

In some embodiments, when the object of the user behavior that triggers the page jump event is the first display screen 110, the target page management unit is the first page management unit 400-1, and the target display screen is the first display screen 110; when the object of the user behavior that triggers the page jump event is the second display screen 120, the target page management unit is the second page management unit 400-2, and the target display screen is the second display screen 120. As an example, FIG. 6 shows a schematic diagram of a page management unit provided according to an embodiment of the present application managing the page of the display screen. When the user only operates the first display screen 110, for example, the user clicks on an icon button on the first display screen or adds some text content on the first display screen, according to the jump event triggered by the user behavior, the logic unit can control the page jump on the first display screen through the first page management unit, and the second page management unit controls the page on the second display screen not to jump. That is, the first page management unit can only maintain the page on the first display screen according to the trigger event from the first display screen. The first page management unit does not respond to events related to the second display screen. Correspondingly, the second page management unit also only responds to events from the second display screen. In this way, a page management unit establishes a one-to-one correspondence between the events and pages of a display screen, and errors are less likely to occur during program execution.

According to the above introduction, each page management unit uses a stack structure to manage and maintain the page of the display screen corresponding to it. In some embodiments, each page management unit includes a routing file, and the routing file defines the rules for page jumps on the display screen corresponding to the page management unit. Each routing file includes several routing interfaces, and the acquisition of target page resource data through the page management unit includes: calling the target routing interface matching the jump event to obtain the target page resource data, wherein the target routing interface belongs to the target page management unit. As an example, the routing interface may include, but is not limited to, a switchTab interface, a reLauncn interface, a redirectTo interface, a navigateTo interface, a navigateBack interface, and the like. The switchTab interface may be an API (Application ProgrammingInterface) that jumps to a specified tab page and closes all other non-tab pages. The reLauncn interface may be an API that closes all current pages and jumps to a specified page in a mini-program. The redirectTo interface may be an API that closes the current page and jumps to a specified page in a mini-program. The navigateTo interface may be an API that jumps from the current page to a specified page in a mini-program. The navigateTo interface can be used to open a new page on the display screen. The navigateBack interface can be an API for closing the current page and returning to the previous page or multiple pages. Before calling the navigateBack interface, the current page stack information can be obtained first to determine how many layers need to be returned. In some embodiments, the current page list can also be obtained through the Pagelist interface. For each new page opened using the navigateTo interface, the page stack size can be increased by 1 until the page stack size reaches the maximum allowed number of layers of the page stack (for example, 5 layers). Correspondingly, for each layer of the page returned using the navigateBack interface, the page stack size can be reduced by 1 until the page stack size is 1.

Continue to refer to the applet framework shown in Figure 2. In some embodiments, the framework also includes a storage unit 003 for storing data. In some embodiments, the calling of the target routing interface matching the jump event to obtain the target page resource data includes: retrieving the target page resource data from the target storage unit, wherein the target storage unit is used to store data about the applet, and the data includes data of the first page instance and data of the second page instance. Storage unit 003 can be a storage space for the applet. The storage space can include a first data block, a second data block, and a third data block. The first data block is configured to store data related only to the first display screen page. The second data block is configured to store data related only to the second display screen page. The third data block can be a shared data block, that is, the third data block can store data shared by the first display screen and the second display screen. For example, there is an order list, and a data is added to the order list in the main screen page, then the secondary screen page can directly know that the data has changed, that is, the main screen page and the secondary screen page can jointly change the same data. In this way, on the one hand, the utilization rate of the storage space is improved, and on the other hand, the data between the main screen and the sub-screen can be communicated without the need to transmit data between the main screen and the sub-screen, thus saving memory and improving performance.

In some embodiments, the first page management unit is managed by the worker module of the mini program, and the second page management unit is managed by the native module of the host application. For example, the first page management unit may be the page stack of the main screen, and the second page management unit may be the page stack of the secondary screen. The main screen page stack may be managed by the mini program front-end framework (e.g., the front-end worker layer), and the secondary screen page stack may be managed by the native container.

In some embodiments, the first page management unit is managed by the worker module of the mini program; the second page management unit is executed by the worker module of the mini program. For example, the first page management unit may be a page stack of the main screen, and the second page management unit may be a page stack of the secondary screen, and both the main screen page stack and the secondary screen page stack may be managed by the mini program front-end framework.

A mini program may correspond to a worker module. The worker module may be the virtual space or running space of the mini program. As an example, the worker module may be a virtual process of the mini program, which may be a process dedicated to serving the mini program to protect the consistency and integrity of the mini program data so that the data is not perceived by other places. The native module may be a native module.

As an example, FIG7 shows a flowchart of a mini-program multi-screen display method S100 provided according to some embodiments of the present application. Some steps and/or all steps in process S100 can be stored as at least one instruction set in a non-temporary storage medium (such as memory 230) in the client device 100, which is used to control the pages displayed on different display screens of the client device. At least one processor 220 is communicatively connected to the at least one non-temporary storage medium, wherein when the client device 100 is running, the at least one processor 220 reads the at least one instruction set and executes the steps in process S100 according to the instructions of the at least one instruction set.

The operations of the illustrated process S100 presented below are intended to be illustrative and not restrictive. In some embodiments, process S100 may add one or more additional operations not described, and/or delete one or more operations described herein when implemented. In addition, the order of the operations illustrated in FIG. 7 and described below is not intended to be limiting.

S110, monitoring the jump event of the target applet.

S120: After the jump event is monitored, a target page management unit is determined from the multiple page management units.

The target applet is parasitic in a target host application, the target host application is loaded in a target client device, the target client device includes multiple display screens, the host application includes multiple page management units, and a page management unit is configured to manage a page displayed by the applet on a display screen.

The jump event may be triggered by a user's interaction with a display screen. For example, the interaction may be clicking an icon button on a display screen. For another example, the interaction may be that the user adds content to a specific text box on a display screen.

S130, parsing the URL address contained in the jump event, and acquiring a route matching the URL address.

In some embodiments, the jump event includes the URL address of the target page. After monitoring the jump event, the processor can parse the URL address included in the jump event and obtain a route matching the URL address.

S140: Call a target routing interface that matches the jump event to obtain the target page resource data.

S150: Display the target page resource data on a target display screen via a view unit.

The target routing interface is a routing interface that matches the URL address and belongs to the target page management unit.

After acquiring the target page resource data based on the page management unit, the processor may display the target page resource data on a target display screen through a view unit, wherein the target display screen corresponds to the target page management unit.

In summary, the mini-program multi-screen display method, host system supporting mini-program multi-screen display, and client device provided by the present application: by creating multiple page stacks within the mini-program framework to support multi-screen display of mini-program pages, developers only need to develop one mini-program, which reduces the difficulty for developers. When updating the mini-program, only one mini-program needs to be updated, which makes it easier to update synchronously; each page stack includes its own page routing interface, so each screen can support multiple pages and jumps between pages. The design of multiple page stacks can enable the mini-program to support the same page starting on different screens. Different screens correspond to different page stacks. There is no need to communicate between the routing interfaces of different page stacks, thus avoiding various problems caused by communication between interfaces.

On the other hand, this specification provides a computer-readable storage medium. At least one set of computer instructions is stored in the storage medium. When the instructions are executed by the processor, the instructions guide the processor to implement the steps of the small program multi-screen display method described in this specification. In some possible implementations, various aspects of this specification can also be implemented in the form of a program product, which includes a program code. When the program product is run on a signal processing device, the program code is used to enable the signal processing device to execute the steps of the small program multi-screen display method described in this specification. The program product for implementing the above method can use a portable compact disk read-only memory (CD-ROM) to include program code and can be run on a signal processing device. However, the program product of this specification is not limited to this. In this specification, the readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system (such as processor 202) or used in combination with it. The program product can use any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of readable storage media include: an electrical connection with one or more conductors, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. The computer-readable storage medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein the readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The readable storage medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, device, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the above. Program code for performing the operations of the present specification may be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, etc., and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the signal processing device, partially on the data processing apparatus 200, as a separate software package, partially on the signal processing device and partially on a remote computing device, or entirely on a remote computing device.

In summary, after reading this detailed disclosure, it will be apparent to those skilled in the art that the aforementioned detailed disclosure may be presented only by way of example and may not be restrictive. Although not explicitly stated herein, it will be appreciated by those skilled in the art that this application is intended to encompass various reasonable changes, improvements and modifications to the embodiments. These changes, improvements and modifications are intended to be proposed by this application and are within the spirit and scope of the exemplary embodiments of this application.

In addition, certain terms in this application have been used to describe embodiments of the present application. For example, "one embodiment", "embodiment" and/or "some embodiments" mean that a particular feature, structure or characteristic described in conjunction with the embodiment may be included in at least one embodiment of the present application. Therefore, it can be emphasized and should be understood that two or more references to "embodiment" or "one embodiment" or "alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. In addition, specific features, structures or characteristics can be appropriately combined in one or more embodiments of the present application.

It should be understood that in the foregoing description of the embodiments of the present application, in order to help understand a feature and for the purpose of simplifying the present application, the present application sometimes combines various features in a single embodiment, drawings or description thereof. Alternatively, the present application disperses various features in multiple embodiments of the present application. However, this does not mean that the combination of these features is necessary. It is entirely possible for those skilled in the art to extract some of the features and understand them as separate embodiments when reading the present application. In other words, the embodiments in the present application can also be understood as the integration of multiple secondary embodiments. This is also true when the content of each secondary embodiment is less than all the features of a single aforementioned disclosed embodiment.

In some embodiments, the numbers expressing the quantity or properties used to describe and claim certain embodiments of the present application should be understood to be modified in some cases by the terms "about", "approximately" or "substantially". For example, unless otherwise stated, "about", "approximately" or "substantially" may represent a ±20% variation of the value described. Therefore, in some embodiments, the numerical parameters listed in the written description and the attached claims are approximate values, which may vary depending on the desired properties that a particular embodiment attempts to obtain. In some embodiments, the numerical parameters should be interpreted according to the number of reported significant figures and by applying ordinary rounding techniques. Although some embodiments of the present application are described, the numerical ranges and parameters listed in a wide range are approximate, but the numerical values that are as accurate as possible are listed in the specific examples.

Each patent, patent application, patent application publication, and other materials, such as articles, books, specifications, publications, documents, articles, etc., cited herein may be incorporated herein by reference in its entirety for all purposes, except for any prosecution document history related thereto, any equivalent that may be inconsistent or conflicting with this document, or any equivalent prosecution document history that may have a limiting effect on the broadest scope of the claims now or later associated with this document. For example, if there is any inconsistency or conflict between the description, definition, and/or use of a term associated with any of the incorporated materials and the term, description, definition, and/or use associated with this document, the term in this document shall control.

Finally, it should be understood that the embodiments of the application disclosed herein are explanations of the principles of the embodiments of the present application. Other modified embodiments are also within the scope of the present application. Therefore, the embodiments disclosed in the present application are merely examples and not limitations. Those skilled in the art can adopt alternative configurations according to the embodiments in the present application to realize the application in the present application. Therefore, the embodiments of the present application are not limited to those embodiments that have been accurately described in the application.

Claims (20)

1. An applet multi-screen display method comprising:

Monitoring a jump event of a target applet, wherein the target applet is parasitized in a target host application, the target host application is loaded in target client equipment, the target client equipment comprises a plurality of display screens, the target host application comprises a plurality of page management units, and one page management unit is configured to manage pages displayed by the target applet on one display screen;

After the jump event is monitored, determining a target page management unit from the plurality of page management units; and

And acquiring target page resource data based on the target page management unit and displaying the target page resource data on a target display screen through a view unit, wherein the target display screen corresponds to the target page management unit.

2. The applet multi-screen display method according to claim 1, wherein each of the plurality of page management units manages pages of its corresponding display screen in a stack structure.

3. The applet multi-screen display method according to claim 1, wherein each page management unit comprises a routing file defining rules for page jumps on a display screen corresponding to the page management unit, each routing file comprising a number of routing interfaces,

The obtaining the target page resource data based on the target page management unit comprises the following steps:

And calling a target routing interface matched with the jump event so as to acquire the target page resource data, wherein the target routing interface belongs to the target page management unit.

4. The applet multi-screen display method according to claim 3, wherein the client device comprises a first display screen and a second display screen, the plurality of page management units comprising:

A first page management unit configured to manage pages displayed on a first display screen by the applet, including a first page stack, wherein a predetermined number of page instances are included in the first page stack, and the page instances in the first page station are preset to correspond to the first display screen; and

The second page management unit is configured to manage pages displayed on a second display screen by the applet, and comprises a second page stack, wherein a preset number of page instances are included in the second page stack, and the page instances in the second page stack are preset to correspond to the second display screen.

5. The applet multi-screen display method according to claim 4, wherein,

When the object triggering the user behavior of the page jump event is a first display screen, the target page management unit is the first page management unit, and the target display screen is the first display screen;

When the object triggering the user behavior of the page jump event is a second display screen, the target page management unit is the second page management unit, and the target display screen is the second display screen.

6. The applet multi-screen display method according to claim 4, wherein,

When the object triggering the user behavior of the page jump event is one of a first display screen and a second display screen, the target page management unit comprises the first page management unit and the second page management unit, and the target display screen comprises the first display screen and the second display screen.

7. The applet multi-screen display method according to claim 4, wherein the invoking a destination routing interface that matches the jump event to obtain the destination page resource data comprises:

And retrieving the target page resource data from a target storage unit, wherein the target storage unit is used for storing data related to the applet, and the data comprise the data of the first page instance and the data of the second page instance.

8. The applet multi-screen display method according to claim 4, wherein,

The first page management unit is executed by a worker module of the applet; and

The second page management unit is executed by the native module of the host application.

9. The applet multi-screen display method according to claim 4, wherein,

The first page management unit is executed by a worker module of the applet; and

The second page management unit is executed by a worker module of the applet.

10. The applet multi-screen display method according to claim 3, wherein the jump event includes a url address of the target page, the applet multi-screen display method further comprising:

analyzing the url address contained in the jump event, and obtaining a route matched with the url address, wherein the route matched with the url address is the target route.

11. A host system supporting an applet dual screen display, comprising:

A view unit configured to display page resource data of an applet hosted in the hosting system as a page on a client device display screen, and to generate an event triggering a page jump based on user behavior of the page;

And a logic unit configured to receive event feedback from the view unit, acquire page data of the applet based on the event feedback and send the page data to the view unit to display the page data on the display screen through the view unit, wherein the client device comprises a plurality of display screens, the logic unit can control pages displayed on the plurality of display screens by the applet through the plurality of page management units, and one page management unit is configured to manage pages displayed on one display screen by the applet.

12. The hosting system supporting dual-screen display of the applet as recited in claim 11, wherein each of the plurality of page management units manages pages of its corresponding display screen in a stack structure.

13. The hosting system supporting dual-screen display of applets as recited in claim 11 wherein each page management unit includes a routing file defining rules for page jumps on a display screen corresponding to the page management unit, each routing file including a plurality of routing interfaces,

The obtaining, by the page management unit, the target page resource data includes:

And calling a target routing interface matched with the jump event so as to acquire the target page resource data, wherein the target routing interface belongs to the target page management unit.

14. The hosting system supporting dual-screen display of an applet as recited in claim 13, wherein the client device comprises a first display screen and a second display screen, the plurality of page management units comprising:

A first page management unit configured to manage pages displayed on a first display screen by the applet, including a first page stack, wherein a predetermined number of page instances are included in the first page stack, and the page instances in the first page station are preset to correspond to the first display screen; and

The second page management unit is configured to manage pages displayed on a second display screen by the applet, and comprises a second page stack, wherein a preset number of page instances are included in the second page stack, and the page instances in the second page stack are preset to correspond to the second display screen.

15. The host system supporting dual-screen display of an applet as recited in claim 14, wherein,

When the object triggering the user behavior of the page jump event is a first display screen, the target page management unit is the first page management unit, and the target display screen is the first display screen;

When the object triggering the user behavior of the page jump event is a second display screen, the target page management unit is the second page management unit, and the target display screen is the second display screen.

16. The host system supporting dual-screen display of an applet as recited in claim 14, wherein,

When the object triggering the user behavior of the page jump event is one of a first display screen and a second display screen, the target page management unit comprises the first page management unit and the second page management unit, and the target display screen comprises the first display screen and the second display screen.

17. The host system supporting dual-screen display of claim 14, wherein said invoking a destination routing interface that matches said jump event to obtain said destination page resource data comprises:

And retrieving the target page resource data from a target storage unit, wherein the target storage unit is used for storing data related to the applet, and the data comprise the data of the first page instance and the data of the second page instance.

18. The host system supporting dual-screen display of an applet as recited in claim 14, wherein,

The first page management unit is managed by the framework of the applet; and

The second page management unit is managed by the native module of the host system.

19. The host system supporting dual-screen display of an applet as recited in claim 14, wherein,

The first page management unit is managed by the framework management of the applet; and

The second page management unit is managed by the framework management of the applet.

20. A client device, comprising:

A memory storing at least one instruction set; and

A processor in communication with the memory and the display, the processor, when the client is running, reading and running the at least one instruction set and executing the applet dual screen display method according to any one of claims 1-10 according to an indication of the at least one instruction set to control pages displayed by different display screens of the client device.