Fast application card processing method and electronic equipment

Abstract

The invention provides a fast application card processing method and electronic equipment, and relates to the technical field of image processing. When the negative one-screen interface is displayed, responding to a click event of the card, calling a V8 process of the fast application engine, and skipping to a card detail interface from the negative one-screen interface. And when switching back to the negative one-screen interface after quitting the negative one-screen interface, calling card jump data configured by the negative one-screen application in response to a click event of the card, and jumping to the card detail interface from the negative one-screen interface. Through the scheme, the problem that the card click event occurring in the card recovery and reconstruction process cannot be responded after the quick application engine V8 process is cleared and returns to the negative screen can be solved.

Description

Technical Field

[0001] This application relates to the field of Quick App card technology, and in particular to a Quick App card processing method and electronic device. Background Technology

[0002] To facilitate information access for users, electronic devices utilize a card recommendation function, presenting potentially relevant information as cards on the device's negative one screen or desktop. For example, the negative one screen can display various cards with different functions for users to choose from. Users can click on a card to navigate to its details page, allowing them to quickly view the details of the service they need.

[0003] However, after users click on the card, the electronic device often becomes unresponsive. This is especially true when exiting and then returning to the negative one screen; the card remains unresponsive after being clicked, requiring multiple clicks before the electronic device responds and redirects to the card details page, severely impacting the user experience. Summary of the Invention

[0004] This application provides a method for processing quick app cards and an electronic device, which can improve the response rate after the card is clicked and enhance the user experience.

[0005] In a first aspect, this application provides a method for processing quick app cards. The method includes: an electronic device displaying a negative one screen interface, wherein a first card is displayed in a first area of ​​the negative one screen interface, and the first card corresponds to a first V8 process; detecting a first click event in the first area; in response to the first click event, calling the first V8 process, exiting the negative one screen interface, and jumping to the details page corresponding to the first card; after exiting the negative one screen interface, in response to a first operation by the user, jumping back to the negative one screen interface; and, in the event of detecting a second click event in the first area, in response to the second click event, calling the first card jump data configured in the negative one screen application, and jumping from the negative one screen interface to the details page corresponding to the first card.

[0006] The Quick App card processing method provided in this application embodiment detects a first click event on a card when displaying the negative one screen interface. In response to the first click event, the V8 process of the Quick App engine is invoked, and the user jumps from the negative one screen interface to the card details interface. Upon exiting the negative one screen interface and then switching back, a second click event on the card is detected. In response to the second click event, the card jump data configured in the negative one screen application is invoked, and the user jumps from the negative one screen interface to the card details interface. This solution resolves the problem that card click events cannot be responded to during the card recovery and reconstruction process when returning to the negative one screen after the Quick App engine V8 process has been cleared.

[0007] It should be noted that the method provided in this application embodiment can be applied to the scenario where card recovery and reconstruction (i.e., card update) is triggered after returning to the negative one screen, and can also be applied to the scenario where the user swipes up and down on the negative one screen to trigger card recovery and reconstruction (i.e., card update).

[0008] In some embodiments, the first card and the second card can be two cards for the same quick app. In other embodiments, the first card and the second card can be two cards for different quick apps.

[0009] In some possible implementations, the method further includes: detecting that the first V8 process has been cleared upon detecting the second click event.

[0010] The above solution ensures that when returning to the negative one screen after exiting it, if the first V8 process has been cleared, the application's first card navigation data is invoked to navigate from the negative one screen to the details page corresponding to that card. If the first V8 process has not been cleared, it can be invoked to navigate from the negative one screen to the details page of the first card. This guarantees that card click events are successfully responded to.

[0011] In some possible implementations, the first card redirection data includes multiple redirection methods after the first card is clicked. These multiple redirection methods are configured with different usage priorities, and the first redirection method has a higher priority than the second redirection method. In this case, the aforementioned invocation of the first card redirection data configured in the negative one screen application to redirect from the negative one screen interface to the details page corresponding to the first card includes: performing a redirection using the first redirection method; and performing a redirection using the second redirection method if the electronic device does not support the first redirection method or if redirection based on the first redirection method fails.

[0012] In some possible implementations, the multiple redirection methods after the first card is clicked include third-party application redirection, quick app redirection, and H5 redirection.

[0013] In some possible implementations, the first card redirection data further includes a sequence number and a resource identifier, with each redirection method corresponding to one sequence number and one resource identifier. In this case, performing the redirection via the first redirection method includes: if the electronic device supports the first redirection method, obtaining the first details page according to the first resource identifier corresponding to the first redirection method, and redirecting from the negative one screen interface to the first details page.

[0014] Specifically, when the first redirection method is a third-party application redirection method, the first details page is the third-party application page corresponding to the first card; when the first redirection method is a quick app redirection method, the first details page is the quick app page corresponding to the first card; when the first redirection method is an H5 redirection method, the first details page is the H5 page corresponding to the first card.

[0015] In some possible implementations, before the first card is displayed in the first area of ​​the negative one screen interface, the method further includes: in response to a second operation of user confirmation to add the first card, loading and displaying the first card in the negative one screen interface; the negative one screen application calling the quick app engine to create the first V8 process; after the first V8 process is created, the quick app engine calling a preset jump component, through the first V8 process, configuring the jump data of the first card to the negative one screen application.

[0016] In some possible implementations, the quick app engine is configured with the preset jump component, which includes an out-link-view component that supports the linkType parameter field, the uris parameter field, and the linkresult callback field.

[0017] The linkType parameter field carries information about multiple redirection methods corresponding to the first card, the uris parameter field carries the resource identifier corresponding to each redirection method, and the linkresult callback field carries the redirection result after the first card is clicked.

[0018] The jump component includes a jump type parameter, which can be in numeric form.

[0019] For example, the linktype parameter can be set to 1 to indicate a third-party application redirection method; the linktype parameter can be set to 2 to indicate a quick app redirection method; and the linktype parameter can be set to 3 to indicate an H5 redirection method.

[0020] In some possible implementations, the method further includes updating the card content of the first area whenever the user navigates to the negative one screen. In this case, updating the card content of the first area includes updating the card content in the first area from the first card to the second card.

[0021] In some possible implementations, updating the card content in the first area from the first card to the second card includes: starting to load the second card in the first area; if the first card and the second card are displayed overlapping in the first area, displaying the first card in a first layer with a first transparency and displaying the second card in a second layer with a second transparency, wherein the first layer is higher than the second layer; the first transparency is higher than the second transparency; after the second card has finished loading, displaying the second card in the first area with the first transparency and clearing the first card and the first layer.

[0022] The above solution allows new cards to be placed below old cards during card updates, resolving the issue of click events not responding when the new card is displayed on top of the old card and the old card cannot be clicked.

[0023] In some possible implementations, the method further includes: detecting a third click event on the first card in the first area when the first card and the second card are displayed overlapping in the first area; and, in response to the third click event, jumping from the negative one screen interface to the details page corresponding to the first card.

[0024] The above solution triggers a card exposure event upon returning to the negative one screen, causing a card update. When the old card has not been removed, the new card is loading, and the old and new cards overlap, the new card is displayed below the old card, and the user can only click on the old card. This avoids clicking on the loading new card.

[0025] In some possible implementations, loading the second card in the first area includes: the negative one screen application calling the Quick App Engine to create a second V8 process; after creating the second V8 process, the negative one screen application calling the second V8 process to load the second card in the first area; wherein, jumping from the negative one screen interface to the details page corresponding to the first card includes: calling the second V8 process to jump from the negative one screen interface to the details page corresponding to the first card.

[0026] In some possible implementations, the first transparency is 0%, and the second transparency is 100%.

[0027] With the above solution, when the first and second cards overlap and the first card is displayed on top of the second card, the user can click on the first card. In other words, when the user clicks on the first area of ​​the negative one screen, the first card is clicked. Upon detecting a click event on the first card, the negative one screen application can launch the application and navigate to the card details page based on pre-configured card navigation data, thus responding to the card click event. This avoids situations where a newly loaded card is clicked, causing the card click event to go unresponsive.

[0028] In some possible implementations, the method further includes: during the loading of the second card, obtaining service data corresponding to the second card from the server side and the local cache of the electronic device respectively; after the second card is loaded, if the first service data is obtained from the server side, displaying the first service data in the second card; if no service data is obtained from the server side but the second service data is obtained from the local cache, displaying the second service data in the second card.

[0029] By using the above solution, when updating a card, cached data is used to render the card first, which can solve the problem of not being able to respond to user clicks because the new card business data has not been fully obtained.

[0030] In some possible implementations, after displaying the first business data or the second business data in the second card, the method further includes: detecting a fourth click event on the second card; and in response to the fourth click event, invoking a second V8 process to jump from the negative one screen interface to the details page corresponding to the second card.

[0031] In some possible implementations, the method further includes: when the second service data is obtained from the server side, caching the second service data in the local cache of the electronic device; and when the first service data is obtained from the server side, replacing the second service data already stored in the local cache of the electronic device with the first service data. Wherein, the update time of the first service data is later than the update time of the second service data.

[0032] With the above scheme, a card exposure event occurs after returning to the negative one screen, triggering a card update. When loading new card service data, in order to ensure that click events occurring on the new card at this time can be successfully responded to, the improvement of this embodiment is: the card service data obtained from the server side is cached on the electronic device side and updated in real time. Therefore, in the card update process, card service data can be obtained from both the server side and the electronic device side at the same time. Even if it fails to obtain service data from the server side, it can still ensure that card service data is obtained from the electronic device side. Therefore, it can ensure that the new card completes the loading of service data in a timely manner, which can avoid the situation where clicks are not responded to due to the incomplete loading of new card service data.

[0033] Secondly, this application provides a quick app card processing apparatus, which includes units for performing the method described in the first aspect above. This apparatus can correspond to performing the method described in the first aspect above; for a detailed description of the units within the apparatus, please refer to the description in the first aspect above, and for the sake of brevity, will not be repeated here.

[0034] The method described in the first aspect above can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above functions. For example, a processing module or unit, a display module or unit, etc.

[0035] Thirdly, this application provides an electronic device, which includes a processor, a computer program or instructions stored in a memory, wherein the processor is used to execute the computer program or instructions to cause the method in the first aspect to be performed.

[0036] Fourthly, this application provides a computer-readable storage medium having a computer program (also referred to as instructions or code) stored thereon for implementing the method of the first aspect. For example, when the computer program is executed by a computer, it enables the computer to perform the method of the first aspect.

[0037] Fifthly, this application provides a chip including a processor. The processor is used to read and execute a computer program stored in a memory to perform the methods in the first aspect and any possible implementation thereof. Optionally, the chip further includes a memory connected to the processor via a circuit or wire.

[0038] Sixthly, this application provides a chip system including a processor. The processor is used to read and execute a computer program stored in a memory to perform the methods in the first aspect and any possible implementation thereof. Optionally, the chip system further includes a memory connected to the processor via a circuit or wire.

[0039] In a seventh aspect, this application provides a computer program product comprising a computer program (also referred to as instructions or code), which, when executed by an electronic device, causes the electronic device to implement the method in the first aspect.

[0040] It is understood that the beneficial effects of the second to seventh aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of the user interface where card click events are not responded to when exiting and then switching back to the negative one screen.

[0042] Figure 2 A flowchart illustrating the process of a card click event being responded to and a flowchart illustrating the process of a card click event not being responded to;

[0043] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0044] Figure 4 A schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0045] Figure 5 This is a timing flowchart of a quick app card processing method;

[0046] Figure 6 This is a schematic diagram of the node flow of a quick app card processing method;

[0047] Figure 7 A schematic diagram of the timing improvement of a quick app card processing method provided in this application embodiment. Figure 1 ;

[0048] Figure 8 A schematic diagram of the timing improvement of a quick app card processing method provided in this application embodiment. Figure 2 ;

[0049] Figure 9 A schematic diagram illustrating an improved node flow of a quick app card processing method provided in this application embodiment;

[0050] Figure 10 An improved timing flow diagram of another quick app card processing method provided in an embodiment of this application;

[0051] Figure 11 A schematic diagram illustrating an improved node flow of another quick app card processing method provided in an embodiment of this application;

[0052] Figure 12 A schematic diagram illustrating the improved timing flow of another quick app card processing method provided in this application embodiment;

[0053] Figure 13 A schematic diagram illustrating an improved process for processing quick app cards provided in an embodiment of this application;

[0054] Figure 14 This is a schematic diagram illustrating an improved node flow of another quick app card processing method provided in an embodiment of this application. Detailed Implementation

[0055] The embodiments of this application will be further described in detail below with reference to specific examples and the accompanying drawings.

[0056] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "more than" means two or more.

[0057] The term "user interface (UI)" used in the following embodiments of this application refers to the medium interface through which an application or operating system interacts and exchanges information with the user. It realizes the conversion between the internal form of information and the form that the user can accept. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0058] To facilitate understanding of the embodiments of this application, some terms used in the embodiments of this application are explained below, so that those skilled in the art can understand them.

[0059] 1) Quick Apps: Quick Apps are a new type of installation-free application that provides a fast, convenient, and ready-to-use application experience without installation. Quick Apps are a JavaScript-based mobile application development framework.

[0060] 2) Quick App Engine: Adopting a technical architecture similar to mini-programs, it allows developers to create quick apps using front-end technologies and submit them to the quick app platform. Quick apps do not require users to download or install them; they can be directly opened and run on mobile devices that support the quick app engine.

[0061] 3) V8 Threads: Used for parsing and executing JavaScript (JS) code, memory management, and garbage collection. The Quick App engine can create V8 threads and implement Quick App functionality by calling these threads.

[0062] The Quick App engine's rendering and logic layers are managed by two types of threads: the rendering layer uses WebView threads for UI rendering; the logic layer uses V8 threads to run JavaScript. A Quick App contains multiple pages, so the rendering layer uses multiple WebView threads. The Quick App engine creates a V8 thread during card rendering. When the V8 thread finishes execution or terminates abnormally, it is cleaned up to release the memory it occupies.

[0063] 4) Quick App Cards (or simply Cards): Quick App cards are a form of Quick App presentation that directly displays the application services or content that users care about most in an interactive card format. A Quick App may contain multiple Quick App cards. Quick App cards and the Quick App main program can be packaged in the same RPK (resource package) file.

[0064] Quick App Cards are card-based UI components created using JavaScript; they are also known as JS Cards.

[0065] Quick App cards can be displayed on host pages such as the -1 screen, Quick Service Center, and / or the desktop.

[0066] In this embodiment of the application, the scenario of displaying a quick app card on the negative one screen is used as an example for illustrative explanation.

[0067] 5) Negative One Screen: This is a special page that appears after swiping right from the phone's home screen (main desktop). The Negative One Screen displays shortcuts, notifications, and frequently used applications in card format.

[0068] 6) Card Exposure Event: The card exposure (onshow) event is triggered when switching from the desktop or application interface to the negative one screen. The card exposure event will trigger the display and update of the card.

[0069] 7) Card click event: When a user clicks on a card displayed on the negative one screen, the electronic device can launch (launch) the quick app (or third-party app) corresponding to the card and jump to the quick app interface (called the card details page).

[0070] Currently, to facilitate information access for users, electronic devices utilize card recommendation functions. Information that users might need is presented as cards on the device's negative one screen or desktop, making it convenient for users to view information. For example, the negative one screen can display various cards with different functions for users to choose from. Users can click on a card according to their needs, triggering the electronic device to jump to the card's details page, allowing users to quickly view details of the services they need.

[0071] However, after users click on the card, the electronic device often becomes unresponsive. This is especially true when exiting and then returning to the negative one screen; the card remains unresponsive after being clicked, requiring multiple clicks before the device responds and redirects to the card details page. This severely impacts the user experience.

[0072] To address the aforementioned issues, this application provides a method and electronic device for processing Quick App cards. This solution, when displaying the negative one screen interface, invokes the V8 process of the Quick App engine in response to a card click event, navigating from the negative one screen interface to the card details interface. Upon exiting and returning to the negative one screen interface, the solution invokes the card navigation data configured in the negative one screen application in response to a card click event, navigating back to the card details interface. This solution resolves the problem that when the Quick App engine V8 process is cleared and the user returns to the negative one screen, the old card's V8 channel becomes unavailable during the card recovery and reconstruction process, preventing card click events from being responded to.

[0073] The following is combined with Figure 2 Through the interaction process between the negative one screen application, the quick app engine, and the card module, this paper explains the situations in which card click events are responded to and the possible situations in which card click events are not responded to.

[0074] Figure 2 Figure (a) illustrates the flowchart of the card click event response. When the electronic device displays the negative one screen, a card exposure event is triggered. The negative one screen application responds to this event by calling the V8 process created by the Quick App engine to render the card on the negative one screen. When the negative one screen application detects a card click event, it dispatches the event to the Quick App engine. The Quick App engine then calls the V8 process to dispatch the card click event to the card module. In response to the card click event, the card module calls the V8 process of the Quick App engine, launches the Quick App, and navigates to the card details page of the Quick App.

[0075] Figure 2 (b) shows a flowchart illustrating the process where a card click event is not responded to. When the electronic device displays the negative one screen, a card exposure event is triggered. The negative one screen application responds to the card exposure event by calling the V8 process created by the Quick App engine to render the card on the negative one screen. It should be noted that, in conjunction with... Figure 1 as well as Figure 2 As seen in (b), in actual implementation, in response to user actions, the electronic device switches from the negative one screen to the desktop or other application interface. After exiting the negative one screen, the V8 process of the Quick App Engine is cleared. Upon returning to the negative one screen, when the negative one screen application detects a card click event, it dispatches the card click event to the Quick App Engine. Because the V8 process is cleared and cannot be invoked, the Quick App Engine cannot dispatch the card click event to the card module, resulting in the card click event not being responded to. In other words, after the user clicks the card, no page redirection is triggered.

[0076] It should be noted that the expected response for the card click event is that every time a user clicks a card (e.g., clicks an ad slot on the card), the Quick App will be launched and the user will be redirected to the Quick App interface. In other words, the goal is a 100% success rate from clicking the card to launching the Quick App. However, in actual implementation, due to technical limitations, the success rate is only about 75%, which impacts both user experience and monetization.

[0077] Possible technical reasons include: when the Quick App engine's V8 process is cleared, the Quick App engine cannot dispatch card click events to the card module, causing the card click event transmission to fail and remain unresponsive. Additionally, the prerequisites for a card click event to be transmitted and respond to, triggering a page redirect, include: the card being clickable, the existence of a V8 channel, and the card data being acquired. If at least one of these three prerequisites is not met, the click event will not be responded to.

[0078] The method provided in this application aims to solve the following problem: when returning to the negative one screen after the Quick App Engine V8 process is cleared, the user cannot respond to clicks in the three scenarios of the card recovery and reconstruction process: the old card V8 channel is not open, the old card is not clickable, and the new card data acquisition is completed.

[0079] The following description, in conjunction with the accompanying drawings, describes the electronic device to which the Quick App Card Processing Method provided in this application is applied. Exemplary examples show that the electronic device in this application may be a mobile phone, tablet computer, ultra-mobile personal computer (UMPC), netbook, cellular phone, personal digital assistant (PDA), wearable device (such as a smartwatch, smart bracelet), or other device with image display capabilities. This application does not impose any special limitations on the specific form of the electronic device.

[0080] Figure 3 This illustration shows a hardware structure diagram of an electronic device according to an embodiment of this application. For example, a mobile phone is used as an example. Figure 3As shown, the electronic device may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver (i.e., earpiece) 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The aforementioned sensor module may include pressure sensors and touch sensors.

[0081] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0082] A controller can be the nerve center and command center of an electronic device. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0083] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0084] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0085] It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a structural limitation on the electronic device. In other embodiments, the electronic device may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0086] In this embodiment, the processor 110 is configured to: detect a first click event on a card when displaying the negative one screen interface; and in response to the first click event, invoke the V8 process of the Quick App engine to jump from the negative one screen interface to the card details interface. When exiting the negative one screen interface and then switching back to it, detect a second click event on a card; and in response to the second click event, invoke the card jump data configured in the negative one screen application to jump from the negative one screen interface to the card details interface, which can be a Quick App interface, a third-party application interface, or an H5 interface.

[0087] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0088] Internal memory 121 can be used to store executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as controlling the switching of the electronic device's operating state), etc. The data storage area may store data created during the use of the electronic device (such as operating status information, switching time information), etc. Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of the electronic device by running instructions stored in internal memory 121 and / or instructions stored in memory located within the processor.

[0089] For example, in this embodiment, the processor 110 can execute instructions stored in the internal memory 121 to detect a first click event on a card when displaying the negative one screen interface. In response to the first click event, it can invoke the V8 process of the Quick App engine to jump from the negative one screen interface to the card details interface. When exiting the negative one screen interface and then switching back to it, a second click event on a card is detected. In response to the second click event, it can invoke the card jump data configured in the negative one screen application to jump from the negative one screen interface to the card details interface. The card details interface can be a Quick App interface, a third-party application interface, or an H5 interface.

[0090] The charging management module 140 receives charging input from a charger (such as a wireless charger or a wired charger) to charge the battery 142. The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power various components of the electronic device.

[0091] The wireless communication function of electronic devices can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.

[0092] Electronic devices can achieve shooting functions through image signal processors, cameras 193, video codecs, GPUs, displays 194, and application processors.

[0093] Electronic devices can implement display functions through GPUs, displays 194, and application processors. A GPU is a microprocessor for image processing, connecting the display 194 and the application processor. The GPU performs mathematical and geometric calculations and is used for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0094] Display screen 194 is used to display images, videos, etc. Display screen 194 can display a negative one screen and display quick app cards on the negative one screen.

[0095] The above is a detailed description of the embodiments of this application using electronic device 100 as an example. It should be understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on electronic device 100. Electronic device 100 may have more or fewer components than shown in the figures, may combine two or more components, or may have different component configurations. The various components shown in the figures can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0096] In addition, an operating system runs on top of the aforementioned hardware. This operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. Applications can be installed and run on this operating system.

[0097] The operating system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses the layered architecture Android system as an example to exemplify the software structure of electronic device 100.

[0098] Figure 4 This is a software structure block diagram of the electronic device 100 according to an embodiment of this application.

[0099] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: applications, application framework, system libraries and Android Runtime, and kernel.

[0100] The application layer may include a series of application packages. For example, the application layer may include desktop applications, sports and health applications, negative one screen applications, and quick app engines, etc., and this application embodiment does not impose any limitations on this.

[0101] The negative one screen application is used to display cards on the negative one screen interface. These cards are an intermediate form between icons and full-screen applications, serving as quick operation tools and information overview windows for users, recommending service information. For example, the negative one screen interface can display quick app cards, native cards, or widget cards. For ease of explanation, this application uses quick app cards as an example.

[0102] In some embodiments, electronic devices automatically add certain quick app cards to the negative one screen interface based on card promotion needs, user behavior data, and / or card big data.

[0103] In other embodiments, in an interface displaying multiple quick app cards, in response to the user confirming the addition of a quick app card to the negative one screen interface, the negative one screen application adds the quick app card selected by the user to the negative one screen interface.

[0104] For example, in response to a user's confirmation of adding the sports and health app's quick app card to the negative one screen, the negative one screen app displays the sports and health app's quick app card on the negative one screen.

[0105] It should be noted that when switching from the first screen (such as the desktop or application screen) to the negative one screen, the card exposure (onshow) event is triggered. The negative one screen application detects the card exposure event and dispatches it to the Quick App Engine.

[0106] The Quick App Engine can respond to card exposure events, enabling the rendering, content display, and content updates of Quick App cards. Specifically, the Quick App Engine can create and invoke V8 processes to perform these tasks.

[0107] It should also be noted that when a user clicks on a Quick App card, a card click event is triggered. The app on the -1 screen detects the card click event and dispatches it to the Quick App engine.

[0108] The Quick App Engine can respond to card click events, enabling navigation from the current negative one screen to the card details page. Specifically, the Quick App Engine can invoke the V8 process to complete this navigation.

[0109] It should also be noted that the V8 process is a child process of the Quick App engine, and the V8 process has a specific lifecycle. For example, after exiting the negative one screen, if the user does not return to the negative one screen after a preset time, the V8 process will be cleared to release the memory it occupies.

[0110] The application framework layer provides APIs and a programming framework for applications within the application layer. The application framework layer includes some predefined functions.

[0111] In this embodiment of the application, the application framework layer may include a Quick App Card Service Unit (hereinafter referred to as the Card Module), which is used to manage the addition / deletion, display and update of Quick App Cards, as well as page redirection after a card is clicked.

[0112] The Quick App Card Service Unit may include an event handler, which may be used to handle card exposure events or card click events.

[0113] In this embodiment of the application, the application framework layer may further include a Quick App SDK (software development kit), which interacts with the card service unit to realize the display and updating of Quick App cards.

[0114] In addition, the application framework layer may also include an AMS (Activity Manager Service) unit, which is responsible for monitoring and managing all Activities in the system, and managing the application's lifecycle, task stack, process and activity switching, etc.

[0115] In this embodiment, the AMS unit can monitor the lifecycle, survival / cleanup, and other statuses of the V8 process. Upon the occurrence of a card click event, the Quick App Card Service unit interacts with the AMS unit to determine whether the V8 process is alive.

[0116] If the V8 process is confirmed to be alive, the Quick App Card Service Unit calls the V8 process of the Quick App Engine to jump from the current negative one screen to the card details page.

[0117] Once it's confirmed that the V8 process has been cleared, the Quick App Card Service unit invokes the card redirection data configured in the application on the -1 screen to navigate from the current -1 screen interface to the card details page. This card redirection data includes redirection methods such as third-party application redirection, Quick App redirection, or H5 redirection. The specific redirection method to choose will be explained in detail below.

[0118] The Android Runtime comprises the core libraries and the virtual machine. The Android Runtime is responsible for the scheduling and management of the Android system. The core libraries consist of two parts: one part contains the functionalities that Java calls, and the other part is the core Android library itself. The application layer and application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0119] The system library can include multiple functional modules. Examples include: a surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), and 2D graphics engines (e.g., SGL). The surface manager manages the display subsystem and provides the fusion of 2D and 3D layers for multiple applications.

[0120] Specifically, in this application, the system library includes a quick app card display interface, which is used to call the display driver and display (including rendering and updating) quick app cards on the negative one screen interface through the display screen.

[0121] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver.

[0122] For clarity, the diagram also illustrates the hardware layer that interacts with the aforementioned software structure. For example, the hardware layer may include a display screen. The display screen can be used to show interfaces such as the negative one screen or the desktop, and can also be used to display cards on the negative one screen or the desktop.

[0123] It should be noted that, although the embodiments of this application are based on... The system is used as an example for explanation, but its basic principles also apply to systems based on... or Electronic devices with operating systems, etc.

[0124] The execution subject of the quick app card processing method provided in this application embodiment can be the aforementioned electronic device, or it can be a functional module and / or functional entity within the electronic device capable of implementing the quick app card processing method. Furthermore, the solution of this application can be implemented through hardware and / or software, and the specific implementation can be determined according to actual usage requirements; this application embodiment does not impose any limitations. The following description uses an electronic device as an example, in conjunction with the accompanying drawings, to exemplarily illustrate the quick app card processing method provided in this application embodiment.

[0125] The embodiments of this application will be described below with reference to the accompanying drawings and through several exemplary embodiments. The methods in the following embodiments can all be implemented in an electronic device having the above-described hardware structure and software architecture. The hardware structure diagram of the electronic device can be as follows: Figure 3 As shown, the software structure block diagram of an electronic device can be as follows: Figure 4 As shown, the embodiments of this application are not limited thereto. The execution subject of the quick app card processing method provided in the embodiments of this application can be an electronic device, or a hardware and / or software module in an electronic device. For ease of explanation, the embodiments of this application all use an electronic device as an example for illustrative purposes.

[0126] First, it's important to note that when exiting and then returning to the negative one screen, the Quick App card undergoes processes such as card exposure, card loading, and card rendering. Click events are only responded to after card rendering is complete. During the card exposure, loading, and rendering processes, due to technical limitations, click events are not responded to, preventing the Quick App from launching or navigating to the card details page.

[0127] This application improves upon this problem scenario, ensuring that click events can be responded to after exiting and returning to the negative one screen. In other words, after a user clicks on a card, the electronic device can successfully launch the quick app and jump to the card details page.

[0128] Let's combine the following... Figure 5 and Figure 6 This document details the card exposure, loading, and rendering process of Quick App cards when exiting and returning to the negative one screen. It also explains the scenarios where click events are not responded to during card exposure, loading, and rendering.

[0129] Figure 5 This diagram illustrates the card update process when returning to the negative one screen after exiting it. The card update process includes the card exposure stage, the card update stage, and the post-update click support stage.

[0130] For ease of explanation, the card before the update will be referred to as the old card, and the card after the update will be referred to as the new card. For example, the first card is the old card, and the second card is the new card. The V8 process used to render the old card (such as the first card) will be referred to as the first V8 process, and the V8 process used to render the new card (such as the second card) will be referred to as the second V8 process.

[0131] Electronic devices can complete the card update process through the negative one screen application, quick app engine, V8 process and card module.

[0132] Card Exposure Stage

[0133] S1. The electronic device displays the negative one screen interface (hereinafter referred to as the negative one screen) through the negative one screen application. The negative one screen displays the first card, which is rendered by the V8 process. In response to user operation, the electronic device exits the negative one screen. After a certain period of time, the V8 process of the first card will be cleared.

[0134] Multiple Quick App cards can be displayed on the -1 screen, and the first card can be any one of these Quick App cards. The Quick App engine creates a V8 process for the first card and uses this V8 process to load and render the first card.

[0135] For example, Quick App cards can include various types of cards such as quick access cards, instant messaging and alert cards, and follow-up activity cards. For instance, quick access cards can provide payment codes, Quick access points provide users with convenient access to frequently used functions. Real-time information and reminder cards can display package tracking, expense information, and commute traffic conditions, keeping users informed. Dynamic cards can display information such as football stands and stock market updates, with content dynamically updated to provide users with real-time updates.

[0136] It should be noted that the first card includes 1*4 cards, 2*2 cards, 2*4 cards, or cards of other possible sizes.

[0137] In some embodiments, the first card may include one or more application icons.

[0138] For example, the first card is The app's quick app card includes a scan icon, a travel icon, and a down payment icon.

[0139] In some embodiments, the first card includes an application icon, service information, and interactive controls.

[0140] For example, the first card is The app's quick app card, which includes information such as step count.

[0141] S2, the application on the negative one screen responds to user actions, returns to the negative one screen, and triggers the card exposure event.

[0142] Among them, the card exposure event will trigger an update of the cards displayed on the negative one screen, such as updating the first card displayed on the negative one screen to the second card.

[0143] In some embodiments, the first card and the second card can be two cards of the same quick app.

[0144] In other embodiments, the first card and the second card can be two cards from different quick apps.

[0145] S3 and the negative one screen application respond to the card exposure event and request the Quick App Engine to bind the V8 service.

[0146] S4-S5: If the first V8 process has been cleared, the Quick App Engine starts the main process and creates a second V8 process for loading and rendering the new card. The Quick App Engine returns a message indicating successful binding to the application on the negative one screen.

[0147] Card update phase

[0148] After receiving the successful binding message, the S6-S8 and negative one screen applications initiate the card update process, instructing the card module to destroy the old card (first card) data, triggering the card module to release the old card data.

[0149] In S9-S10, the application on the negative one screen calls the V8 process to mount the new card view, which is displayed on top of the old card. For example, the transparency of the new card can be set to 1, and the transparency of the old card can be set to 0. After the first screen rendering is complete, the application on the negative one screen removes the old card and displays the new card frame. At this time, the transparency of the new card is updated to 0.

[0150] Here, 0 represents complete opacity, and 1 represents complete transparency.

[0151] S11-S12, the application indicator card module on the negative one screen displays the new card service data. The card module obtains the new card service data and displays it. At this point, the card update is complete.

[0152] It should be noted that an animation can be executed when the card is updated to notify the user that the card has been updated, thus improving the user experience.

[0153] The updated version supports click-based stages.

[0154] In S13-S17, the application on the negative one screen detects a card click event and dispatches it to the Quick App Engine. The Quick App Engine then calls the V8 process to send the card click event back to the card module. The card module sends a pull-up command to the V8 process. In response to the pull-up command, the V8 process provides card feature interfaces to the application on the negative one screen.

[0155] S18-S19: The application on the negative one screen calls the card feature interface to trigger the launch of the quick app. After the quick app is launched, it displays the card details page.

[0156] After the card update phase ends, if the card is clicked, the electronic device can respond normally to the card click event, launch the quick app, and jump from the negative one screen to the card details page.

[0157] For example, when a user clicks a Quick App card on the -1 screen, the -1 screen app detects the card click event. The -1 screen app needs to send the card click event back to the card module via the V8 process. After the Quick App card is clickable and the card's business data is ready, the card module responds to the card click event and triggers a push action to the V8 process, such as launching... Apps and other similar devices initiate business processes.

[0158] It should be noted that there is a scenario where click events do not respond during the card update process:

[0159] Problem Scenario 1

[0160] like Figure 5 As shown, during the card exposure phase, immediately after returning to the negative one screen, the card is clicked, but the click event has no response.

[0161] Reason: After exiting the negative one screen, the old card's V8 process has been cleared. After returning to the negative one screen, the old card has not been destroyed, and the new card has not been loaded and rendered. If the user clicks on a card, the old card will be clicked. The electronic device needs to call the V8 process to complete the response to the card click event. However, since the old card's V8 process has been cleared, it cannot be called, so the card click event cannot be responded to.

[0162] Problem Scenario 2

[0163] like Figure 5 As shown, during the card update phase, when the new card and the old card overlap, the card is clicked, but the click event does not respond.

[0164] Cause: The old card was not removed, and the new card has not been fully loaded and rendered. The new card is displayed on top of the old card. If the user clicks on a card, the new card will also be clicked. However, the new card is in a loading state and cannot support the response to card click events.

[0165] Problem Scenario 3

[0166] like Figure 5 As shown, during the card update phase, after the old card is removed and the new card frame is displayed, the new card frame is clicked, but the click event does not respond.

[0167] Reason: Because the new card business data was not obtained, the new card was not fully displayed. Even if the new card is clicked, the system cannot respond to the card click event.

[0168] Figure 6 The diagram illustrates the nodes and time consumption of the card update process, as well as the card display, clickable objects for the user, and application launch status.

[0169] like Figure 6 As shown, the card update process can include nodes such as card exposure, binding to the V8 process, destroying old card data, starting to load the new card, mounting the new card view, completing the first screen rendering, completing the animation execution, removing the old card and displaying the new card after the animation execution is completed, and displaying the new card's business data.

[0170] Figure 6 The diagram illustrates the time consumption between various nodes in the card update process. Throughout the entire process, from the moment a card is clicked to the application launching, at least 1891 milliseconds (ms) are required; all click events within this 1875ms fail to generate a real response.

[0171] refer to Figure 6 As shown and referring to scenario 1 above, in the card update process, after the card is exposed but before the new card view is mounted, the old card is displayed on the negative one screen. Accordingly, the user can click on the old card. It should be noted that since the old card's V8 process is cleared after exiting the negative one screen, when the old card is clicked, its V8 process cannot be invoked, therefore the card click event is not responded to.

[0172] refer to Figure 6 As shown and referring to scenario 2 above, when swiping the negative one screen, the process of creating a new card and replacing the old card takes 1339ms. During this time, the two cards overlap, with the new card floating transparently on top of the old card. This causes the user to see the old card but actually click on the new card. Because the V8 channel is not established and / or the business data is not ready during the new card creation process, clicking on the new card will not trigger a response.

[0173] In other words, during the card update process, after the new card view is mounted and before the old card is removed and the new card is displayed, both the new and old cards will be displayed simultaneously on the -1 screen, meaning they overlap. By default, the new card is displayed on top of the old card. Correspondingly, the user can click on the new card. It should be noted that because the new and old cards overlap and the new card is displayed on top of the old card, when the user clicks on a card, they will click on the new card, which has not yet finished loading, so the card click event will not be responded to.

[0174] refer to Figure 6 As shown and referring to the above problem scenario 3, after removing the old card and displaying the new card, the time taken before displaying the new card's service data is unknown. This is because requesting the new card's service data from the server side may result in the new card's service data being obtained quickly, or it may fail to be obtained due to network reasons or request failure. Therefore, the time taken is uncertain, which will cause card update delays, and consequently cause click events to not be responded to.

[0175] In the card update process, after removing the old card and displaying the new card, the new card is shown on the -1 screen. Correspondingly, the new card is the only clickable object for the user. It should be noted that when a user clicks on the new card, if the new card's business data has been successfully acquired, the card click event will be responded to, launching the application and redirecting the user to the card details page; if the new card's business data has not been successfully acquired, the card click event will not be responded to.

[0176] The method provided in this application aims to solve the following problem: when returning to the negative one screen after the Quick App Engine V8 process is cleared, the user cannot respond to clicks in the three scenarios of the card recovery and reconstruction process: the old card V8 channel is not open, the old card is not clickable, and the new card data acquisition is completed.

[0177] The above details the card update process and the scenario where click events become unresponsive during the process. It also analyzes the causes of these problems using flowcharts and node diagrams. The following section describes the Quick App card processing method provided in this application, using specific embodiments.

[0178] It should be noted that this application provides solutions for the three problem scenarios mentioned above, which will be described in detail below through examples.

[0179] First Embodiment

[0180] The quick app card processing method provided in the first embodiment can solve the problem in scenario 1 above where click events are not responded to due to the disconnection of the old card's V8 channel.

[0181] In the first embodiment, the application on the negative one screen pre-configures card navigation data. When a card click event occurs after returning to the negative one screen, the application can launch itself and navigate to the card details page based on the pre-configured data, thus responding to the card click event. This avoids situations where card click events are not responded to because the card's V8 process has been cleaned up and cannot be invoked.

[0182] Figure 7 This is a flowchart illustrating the quick app card processing method provided in this application embodiment. The flowchart includes a card navigation data configuration process and a click response process when the card is exposed.

[0183] Card jump data configuration process

[0184] S200, in response to user interaction, the negative one screen application adds the first card to the negative one screen.

[0185] For example, the electronic device displays a Quick Service Center interface, which shows multiple Quick App cards. The user can select the first card among the multiple Quick App cards and click the "Add to -1 Screen" button. In response to the user's action, the electronic device adds the first card to the first area of ​​the -1 screen via the -1 screen application.

[0186] S201-S203, the application on the negative one screen requests to bind to the V8 service from the Quick App Engine. The Quick App Engine starts its main process and creates the V8 process for the first card (i.e., the first V8 process), and then sends a binding success message to the application on the negative one screen.

[0187] S204-S206: The negative one screen application requests configuration card navigation data from the V8 process, and the V8 process configures the first card navigation data to the negative one screen application. The negative one screen application can receive a configuration success message.

[0188] For example, in the embodiments of this application, the first card jump data may include third-party application jump methods, quick app jump methods, and H5 jump methods.

[0189] Among them, the third-party application redirection method is based on the third-party application. The third-party application is triggered to start, and then the card details page is displayed through the third-party application to complete the page redirection.

[0190] Among them, the quick app jump method is based on the quick app to realize the jump. The quick app is triggered to start, and then the card details page is displayed through the quick app to complete the page jump.

[0191] The H5 redirection method is a page redirection method implemented based on H5 redirection to a mini-program. The H5 page is triggered and displayed, and then the card details page is displayed through the H5 page, completing the page redirection.

[0192] In this context, H5-to-mini-program redirection involves setting up links within an H5 page. Clicking these links allows users to directly jump to the corresponding mini-program, enabling quick switching and seamless integration. H5 is short for Hypertext Markup Language (HTML) 5.

[0193] Click response process when card is exposed

[0194] S207. When the electronic device displays the negative one screen, the negative one screen application calls the V8 process to load and render the first card on the negative one screen. The negative one screen application responds to user operation and exits the negative one screen. After a certain period of time, the V8 process is cleaned up.

[0195] For example, an electronic device responds to a user's swipe-left action on the negative one screen, exits the negative one screen, and displays the desktop.

[0196] For example, an electronic device displays a message notification bar in response to a user pulling down from the top of the screen; in response to a user clicking on a message in the message notification bar, it navigates to the message details page and exits the negative one screen.

[0197] For example, an electronic device responds to a user swiping up from the bottom of the screen to display the interface of recently run applications; responds to a user clicking on an application in the interface of recently run applications to jump to the application page and exit the negative one screen.

[0198] After exiting the negative one screen, electronic devices typically clean up the V8 process to free up memory space.

[0199] S208. In response to user interaction, when returning to the negative one screen from the desktop or application interface, a card exposure event is triggered, which in turn updates the cards on the negative one screen. Specifically, the first card will be updated.

[0200] S209. After returning to the negative one screen, the negative one screen application detects a card click event.

[0201] It should be noted that when the card is exposed but before the new card starts loading, the old card is displayed on the negative one screen.

[0202] For example, the first card is displayed in the first area of ​​the negative one screen, and the first card is the clickable object for the user. When the user clicks on the first area of ​​the negative one screen, the first card is clicked.

[0203] S210-S211: The application on the negative one screen calls the pre-configured first card jump data, launches the application, and jumps to the card details page.

[0204] In some embodiments, after returning to the negative one screen, if the negative one screen application detects a card click event, the negative one screen application can directly call the first card jump data, launch the application, and jump to the card details page.

[0205] For example, the application on the -1 screen might call pre-configured first card redirection data to launch a third-party application and redirect to the card details page. Alternatively, the application on the -1 screen might call pre-configured first card redirection data to launch a quick app and redirect to the card details page. Or, the application on the -1 screen might call pre-configured first card redirection data to launch an H5 page and display the card details page through the H5 page.

[0206] refer to Figure 7As shown in the circular dashed box, for scenario 1, after returning to the negative one screen, a card click event occurs (the old card is clicked). In order to ensure that the card click event is responded to, the improvement of this application embodiment is: instead of calling the V8 process, the pre-configured card jump data is called to launch the application and jump the page, so the click is successfully responded to.

[0207] In other embodiments, when the application on the negative one screen detects a card click event, it determines whether a V8 process for the first card exists. If the negative one screen determines that a V8 process for the first card exists, it calls the V8 process for the first card, launches the application, and navigates to the card details page. If the negative one screen determines that a V8 process for the first card does not exist, it calls pre-configured first card navigation data, launches the application, and navigates to the card details page.

[0208] Jump components and card jump data

[0209] The above describes possible implementations of launching the application and page navigation using pre-configured navigation data in scenarios where a card click event occurs after returning to the negative one screen. The following describes the navigation component and card navigation data provided in the embodiments of this application.

[0210] In this embodiment, the Quick App engine adds a jump component to resolve the issue of unresponsive clicks caused by the inaccessibility of the V8 channel on older cards. During card rendering, the card module can pre-pass card jump data to the jump component, which then enables page navigation. During the card update process, by calling the card jump data in this jump component, it can support jump methods such as commonly used apps, Quick Apps, and / or H5 pages, without relying on the V8 process.

[0211] Among them, the jump component is a component that enables page jump capabilities. For example, by binding the jump component to a business component of the Quick App Engine, page jumps can be achieved.

[0212] It should be noted that this application does not limit the naming of the jump component. For example, the jump component can also be called a click component or a launch application component.

[0213] In some embodiments, the redirection component includes a redirection type parameter, which can be in numeric form. The linkType parameter field carries information about various redirection methods corresponding to the first card.

[0214] For example, the linktype parameter can be set to 1 to indicate a third-party application redirection method; the linktype parameter can be set to 2 to indicate a quick app redirection method; and the linktype parameter can be set to 3 to indicate an H5 redirection method.

[0215] It should be noted that the above describes commonly used jump methods, but other jump methods can also be used in actual implementation.

[0216] It should also be noted that by setting a common redirection method, the business side can eventually redirect successfully even if the redirection fails.

[0217] In some embodiments, the redirection component further includes a URI parameter, which can be an array. The URI parameter field carries a resource identifier corresponding to each redirection method.

[0218] For example, Table 1 below schematically illustrates the jump components and card jump data provided in this application.

[0219] Table 1

[0220] Jump component Card jump data type Number(1:App; 2:QuickApp; 3:H5; xxx...) Resource identifier (URI) String Parameters Number(1: timestamp, ...) Replace Type For example 1 Replace macro string replaceStr The engine interprets it only as replacing the current timestamp; the macro string is in uppercase form: __TIME__ Object Each element in the jump behavior set is an Object, with priority in array order.

[0221] In this context, Number represents a number, App represents a third-party application, QuickApp represents a quick app, and String represents a string. The jump component and the card jump data constitute the jump behavior set.

[0222] This application illustrates possible representations of jump behavior sets in its embodiments.

[0223]

[0224]

[0225] In this embodiment, the Quick App engine is configured with a preset jump component, which includes an out-link-view component. The out-link-view component supports a linkType parameter field, a uris parameter field, and a linkresult callback field. The linkresult callback field carries the jump result after the first card is clicked.

[0226] In this embodiment, the JS card can be clicked using the out-link-view component, which supports parameter fields such as linkType and uris, as well as the linkresult callback field.

[0227] Once the jump component is bound to a business component, if a card click event occurs on the negative one screen, the application can be launched based on the jump data of the jump component to complete the page jump, without relying on the V8 process, thus solving the problem of V8 channel disconnection and inability to respond to clicks.

[0228] In this embodiment, during card rendering, card navigation data can be bound to the negative one screen application via the V8 process. When the card is restored and rebuilt (i.e., card update), if the negative one screen application detects a card click event, it can directly call the navigation data to launch the application. The process of launching the application by calling the card navigation data in this navigation component does not rely on the V8 process; even if the V8 process does not exist, the application can still be successfully launched, ensuring that the card click event is successfully responded to.

[0229] Application of jump data

[0230] In this embodiment of the application, the first card jump data may include multiple jump methods, and different execution priorities can be set for each jump method, and page jumps can be attempted according to the execution priority.

[0231] For example, assuming the first card is associated with a Quick App, a third-party app, and an H5 page, the Quick App engine can set the first card's redirection data and the execution priority of the redirection methods. For instance, the first card's redirection data may include Quick App redirection methods, third-party app redirection methods, and H5 redirection methods. The execution priority of the third-party app redirection method is higher than that of the Quick App redirection method, and the execution priority of the Quick App redirection method is higher than that of the H5 redirection method.

[0232] Figure 8 The diagram illustrates the process in the first embodiment described above: the application on the negative one screen calls the first card jump data, launches the application, and jumps to the card details page.

[0233] S300-S301, when the application on the negative one screen detects a click event on the first card, the application on the negative one screen obtains the redirection data for the first card. This redirection data includes multiple redirection methods, ordered from highest to lowest execution priority: third-party application redirection method, quick application redirection method, and H5 redirection method.

[0234] S302-S304, the application on the negative one screen triggers the launch (launch) of the third-party application corresponding to the first card. The third-party application launches and displays the card details page, and sends the redirection result 1 to the application on the negative one screen.

[0235] Among them, jump result 1 indicates whether the jump was successful or failed.

[0236] S305-S308, If the redirection result 1 is a redirection failure, the application on the negative one screen triggers the launch (launch) of the quick app corresponding to the first card. The quick app launches and displays the card details page, and sends the redirection result 2 to the application on the negative one screen.

[0237] Among them, jump result 2 indicates whether the jump was successful or failed.

[0238] S309-S311, If ​​the jump result 2 is a jump failure, the application on the negative one screen triggers the launch (pull up) of the H5 page corresponding to the first card, and displays the card details page through the H5 page. This card details page is the details page of the first card.

[0239] Figure 9 An improved schematic diagram of the first embodiment of this application is shown.

[0240] Before the improvement, in the card update process, after the card was exposed but before the new card view was mounted, the user could click on the old card. Because the old card's V8 process was cleared after exiting the negative one screen, the old card's V8 process could not be invoked when the old card was clicked, so the card click event was not responded to.

[0241] In the improved card update process, after the card is exposed but before the new card view is attached, the user can click on the old card. (Reference) Figure 9 As shown in the shaded area, when the old card is clicked, the application on the negative one screen does not call the old card's V8 process. Instead, it launches the application based on the pre-configured card jump data to achieve page jump, so that the card click event can be responded to.

[0242] The Quick App card processing method provided in this application, when displaying the negative one screen interface, responds to card click events by invoking the V8 process of the Quick App engine to jump from the negative one screen interface to the card details interface. When exiting and returning to the negative one screen interface, responding to card click events again, it invokes the card jump data configured in the negative one screen application to jump from the negative one screen interface to the card details interface. This solution resolves the problem that when the Quick App engine V8 process is cleared and the user returns to the negative one screen, the old card V8 channel becomes unavailable during the card recovery and reconstruction process, causing card click events to be unresponsive.

[0243] Second Embodiment

[0244] The quick app card processing method provided in the second embodiment can solve the problem in scenario 2 above, where the new card being loaded is displayed on top of the old card, and the old card cannot be clicked, resulting in the click event not being responded to. For example, when updating cards, the new card can be placed below the old card, solving the problem of unresponsive clicks caused by the old card being unclickable.

[0245] In the second embodiment, a card exposure event occurs after returning to the negative one screen, triggering a card update. When the old card has not been removed, the new card is loading, and the old and new cards are displayed overlapping, the new card is displayed below the old card, and the user can click on the old card. This can prevent the loading new card from being clicked.

[0246] For example, when the first card and the second card are displayed overlapping, with the first card appearing on top of the second card, the user can click on the first card. That is, when the user clicks on the first area of ​​the negative one screen, the first card is clicked.

[0247] Upon detecting a click event on the first card, the application on the negative one screen can launch the application and navigate to the card details page based on pre-configured card navigation data, thus completing the response to the card click event. This avoids situations where a click on a newly loaded card causes the card click event to go unresponsive.

[0248] Figure 10 This is a flowchart illustrating the quick app card processing method provided in this application embodiment. The flowchart includes a card jump data configuration process, a card exposure process, and a click response process when cards overlap.

[0249] Card jump data configuration process

[0250] From S400 to S406, in response to user interaction, the application on the negative one screen adds the first card to the negative one screen. The quick app engine starts its main process and creates a V8 process for the first card. The application on the negative one screen calls the V8 process to configure the navigation data for the first card.

[0251] It should be noted that the card jump data configuration process in the second embodiment is the same as that in the first embodiment, and will not be repeated here.

[0252] Card Exposure Process

[0253] S407 to S411: In response to user interaction, exit the negative one screen. After a certain period of time, the V8 process of the first card will be cleaned up. In response to user interaction, return to the negative one screen, triggering a card exposure event (which will trigger a card update). The negative one screen application requests to bind the V8 service to the Quick App Engine. The Quick App Engine starts its main process and creates the V8 process for the second card, which can be called by the negative one screen application.

[0254] It should be noted that the card exposure process in the second embodiment is the same as... Figure 5 The processing flow for the card exposure stage is the same as shown, so it will not be repeated here.

[0255] Click response process when cards overlap

[0256] S412, the application on the negative one screen starts updating the card, that is, it begins to destroy the old card (such as the first card) and load the new card (such as the second card).

[0257] S413-S414, the negative one screen application instructs the card module to destroy old card data; the card module destroys old card data according to this instruction information.

[0258] It should be noted that while the card module releases the old card data, the old card data is still retained in the application on the negative one screen.

[0259] S415, the negative one screen application calls the V8 process to mount the new card view, displaying the new card under the old card.

[0260] refer to Figure 10 As shown in the elliptical dashed box, for scenario 2, the old card has not been removed, the new card has not finished loading, and the new card and the old card are displayed overlapping. In order to ensure that the card click event that occurs at this time can be successfully responded to, the improvement of this application embodiment is to place the new card under the old card. At this time, the object that the user can click is the old card. This can prevent the new card that is being loaded from being clicked, and thus can prevent the card click event from not being responded to.

[0261] In some embodiments, when the old card is not removed, the new card is loading, and the old and new cards are displayed overlapping, the transparency of the new card is set to 100%, i.e., completely transparent. For example, when the first card and the second card are displayed overlapping in the first area of ​​the negative one screen, the new card is displayed under the old card and is completely transparent, and the first card is presented in the first area of ​​the negative one screen.

[0262] Once the new card has finished loading, set its transparency to 0%, meaning it will be completely opaque. For example, after the first card is removed and the second card has finished loading, the second card will be displayed in the first area of ​​the negative one screen.

[0263] S416. When the new card is displayed below the old card, the application on the negative one screen detects a card click event, at which point the old card is clicked.

[0264] S417-S419, In ​​the absence of a V8 process for the old card, the application on the negative one screen launches a third-party application, quick app, or H5 page based on the old card's redirection data (first card redirection data). Accordingly, the third-party application launches and displays the card details page, which is the details page for the first card.

[0265] After the old card is clicked, the application can be launched and the page can be redirected using the old card's preset redirection component without relying on the V8 process.

[0266] Figure 11 An improved schematic diagram of the second embodiment of this application is shown.

[0267] Before the improvement, in the card update process, after the new card view was mounted but before the old card was removed and the new card was displayed, the new card was displayed on top of the old card, and the user could only click on the new card. Because the new card was in a loading state, the card click event was not responded to when the new card was clicked.

[0268] In the improved card update process, after mounting the new card view and before removing the old card and displaying the new card, the old card is placed on top of the new card, and the user can click on the old card. (Reference) Figure 11 As shown in the shaded area, the old card is placed on top of the new card. When a card click event occurs, the old card is clicked. In this case, the application on the negative one screen can launch the application according to the pre-configured card jump data to achieve page jump, so that the card click event can be responded to.

[0269] Third Embodiment

[0270] The quick app card processing method provided in the third embodiment can solve the problem in scenario 3 above where click events are not responded to due to the lack of card business data. For example, when updating a card, cached data is used first to render the card, thus solving the problem of not being able to respond to user clicks because the new card business data has not been fully acquired.

[0271] In the third embodiment, a card exposure event occurs after returning to the negative one screen, triggering a card update. When loading new card service data, in order to ensure that click events occurring on the new card at this time can be successfully responded to, the improvement of this embodiment is: the card service data obtained from the server side is cached on the electronic device side and updated in real time. Therefore, in the card update process, card service data can be obtained from both the server side and the electronic device side at the same time. Even if it fails to obtain service data from the server side, it can still ensure that card service data is obtained from the electronic device side. Therefore, it can ensure that the new card completes the loading of service data in a timely manner, which can avoid the situation where clicks are not responded to due to the incomplete loading of new card service data.

[0272] Figure 12 This is a flowchart illustrating the quick app card processing method provided in this application embodiment. The flowchart includes a card jump data configuration process, a card exposure process, and a click response process when the card is loaded.

[0273] Card jump data configuration process

[0274] From S500 to S506, in response to user interaction, the application on the negative one screen adds the first card to the negative one screen. The quick app engine starts its main process and creates a V8 process for the first card. The application on the negative one screen calls the V8 process to configure the navigation data for the first card.

[0275] It should be noted that the card jump data configuration process in the third embodiment is the same as that in the first embodiment, and will not be repeated here.

[0276] Card Exposure Process

[0277] In steps S507 to S511, in response to user interaction, the user exits the negative one screen. After a certain period, the V8 process of the first card is cleared. In response to user interaction, the user returns to the negative one screen, triggering a card exposure event (which will trigger a card update). The negative one screen application requests to bind to the V8 service from the Quick App engine. The Quick App engine starts its main process and creates a V8 process for the second card, which can be called by the negative one screen application.

[0278] It should be noted that the card exposure process in the third embodiment is the same as that in the second embodiment, and will not be described again here.

[0279] Click response process when loading a card

[0280] S512-S515, the negative one screen application initiates a card update, which means starting to destroy old cards (such as the first card) and load new cards (such as the second card). The negative one screen application instructs the card module to destroy the old card data; the card module destroys the old card data according to this instruction. The negative one screen application calls the V8 process to mount the new card view, displaying the new card below the old card.

[0281] S516. After the initial screen rendering and animation are complete, remove the old card and display the new card frame.

[0282] S517-S519, the negative one screen application instructs the card module to display new card service data. The card module retrieves new card service data from both the server side and the electronic device side, and displays the retrieved card service data in the new card frame. The negative one screen application receives a message indicating that the loading and display of the new card service data is complete.

[0283] refer to Figure 12 As shown in the elliptical dashed box, for scenario 3, when the new card is clicked before the new card service data loading is complete, in order to ensure that the card click event can be successfully responded to at this time, the improvement of this application embodiment is: the card service data obtained from the server side is cached on the electronic device side. In this way, during the card update process, the card service data can be obtained from both the server side and the electronic device side, thereby speeding up the extraction speed of service data, displaying the card service data in the new card frame in a timely manner, completing the loading of the card service data, and avoiding the situation where the card click event is not responded to due to the incomplete loading of the card service data.

[0284] S520, the application on the negative one screen detects a card click event, and at this time the new card is clicked.

[0285] S521-S523, the negative one screen application launches a third-party application, quick app, or H5 page based on the new card's V8 process. Accordingly, the third-party application launches and displays the card details page, which is the details page of the second card.

[0286] In some embodiments, the negative one screen application can first determine whether there is a V8 process for the new card. If it is determined that there is a V8 process for the new card, the negative one screen application calls the V8 process to launch the application.

[0287] If the V8 process bound to the new card has been cleared, the application on the negative one screen can launch the application and jump to the card details page instead of calling the V8 process, thus completing the response to the card click event.

[0288] Figure 13 This illustration shows an improved method for acquiring card service data in the third embodiment of this application. Figure 1 .

[0289] like Figure 13 As shown, before the improvement, in the scenario of adding a card (e.g., adding the first card), the card frame is loaded and the card business data is requested from the server side; if the card business data is obtained from the server side, the card view is rendered in the card frame according to the obtained card business data.

[0290] In a card update scenario (e.g., updating the first card to the second card), the card frame is loaded, and card business data is requested from the server. If the card business data is obtained from the server, the card view is updated in the card frame according to the card business data. If the request from the server fails or the card business data cannot be obtained due to no network, card rendering or updating fails.

[0291] like Figure 13 As shown, in the improved version, in a card-adding scenario (e.g., adding the first card), the card frame is loaded, and card business data is requested from the server. If the card business data is obtained from the server, the card view is rendered within the card frame based on the obtained data. Also, the card business data obtained from the server is cached locally on the electronic device.

[0292] In a card update scenario (e.g., updating the first card to the second card), the card framework is loaded, and card business data is requested from the server side. If the card business data has already been cached on the electronic device side, the cached card business data is retrieved from the electronic device side.

[0293] In some embodiments, if obtaining data from the server fails, card business data is obtained from the electronic device. In this case, the card view is updated in the card frame based on the card business data obtained from the electronic device.

[0294] In some embodiments, card service data is obtained from both the electronic device side and the server side. In this case, the card view is updated in the card frame according to the latest version of the card service data.

[0295] In some embodiments, when card service data is obtained from the server side, the card service data obtained from the server side is used to update the card service data already cached locally on the electronic device.

[0296] Figure 14 This illustration shows an improved method for acquiring card service data in the third embodiment of this application. Figure 2 .

[0297] Before the improvement, in the card update process, after removing the old card and displaying the new card (actually the new card frame), the user could click on the new card. After displaying the new card, it needed to show business data, but whether the business data could be successfully retrieved from the server was uncertain. Therefore, the time taken from displaying the new card to displaying its business data was unpredictable. (Reference) Figure 14 As shown in the bold box, if the new card is clicked before its service data is displayed, the card click event will not be responded to, and the application cannot be launched.

[0298] In the improved version, the card update process requests card service data from the server, and if the card service data is already cached on the electronic device, it retrieves the cached card service data from the electronic device. This allows the card service data to be quickly displayed in the new card frame after the old card is removed and the new card is shown. (Reference) Figure 14 As shown in the shaded area, when a new card is clicked, the application on the negative one screen can launch the application based on the pre-configured card jump data, or based on the V8 process bound to the new card, so that the card click event can be responded to.

[0299] When rebuilding a card, cached data is retrieved locally first, which reduces the time from "animation completion" to "displaying new card business data" from seconds to milliseconds. This reduction in time increases the click response rate.

[0300] The method provided in this application embodiment can improve the conversion rate of JS cards responding to clicks and performing subsequent business actions when a user clicks on a mobile quick app card display area (such as the negative one screen, quick service center, desktop, etc.).

[0301] It should be noted that in the embodiments of this application, "greater than" can be replaced with "greater than or equal to", "less than or equal to" can be replaced with "less than", or "greater than or equal to" can be replaced with "greater than", and "less than" can be replaced with "less than or equal to".

[0302] The various embodiments described herein can be independent solutions or combinations thereof based on their inherent logic, and all such solutions fall within the protection scope of this application.

[0303] The foregoing mainly describes the solutions provided by the embodiments of this application from the perspective of method steps. It is understood that, in order to achieve the above functions, the electronic device implementing this method includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of protection of this application.

[0304] This application embodiment can divide an electronic device into functional modules based on the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, other feasible division methods may exist. The following description uses the division of functional modules according to each function as an example.

[0305] This application also provides a chip coupled to a memory, which is used to read and execute computer programs or instructions stored in the memory to perform the methods in the above embodiments.

[0306] This application also provides an electronic device including a chip for reading and executing computer programs or instructions stored in a memory, causing the methods in the various embodiments to be performed.

[0307] This embodiment also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the quick app card processing method in the above embodiment.

[0308] This embodiment also provides a computer program product. The computer-readable storage medium stores program code. When the computer program product is run on a computer, it causes the computer to perform the above-mentioned related steps to implement the quick app card processing method in the above embodiment.

[0309] In this embodiment, the electronic device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0310] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0311] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0312] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects. In the description of embodiments in this application, unless otherwise stated, "multiple" means two or more; for example, multiple processing units refer to two or more processing units, etc.; multiple elements refer to two or more elements, etc.

[0313] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for processing quick application cards, characterized in that, include: The electronic device displays a negative one screen interface, and a first card is displayed in the first area of ​​the negative one screen interface. The first card corresponds to a first V8 process. A first click event was detected in the first area; In response to the first click event, the first V8 process is invoked, the negative one screen interface is exited, and the user is redirected to the details page corresponding to the first card. After exiting the negative one screen interface, in response to the user's first operation, the user is redirected back to the negative one screen interface. Upon detecting a second click event in the first area, in response to the second click event, the first card jump data configured in the negative one screen application is invoked, and the user jumps from the negative one screen interface to the details page corresponding to the first card.

2. The method according to claim 1, characterized in that, The method further includes: Upon detecting the second click event, it was detected that the first V8 process had been cleared.

3. The method according to claim 1 or 2, characterized in that, The first card jump data includes multiple jump methods after the first card is clicked. The multiple jump methods are configured with different usage priorities. Among the multiple jump methods, the priority of the first jump method is higher than the priority of the second jump method. The step of calling the first card jump data configured in the negative one screen application and jumping from the negative one screen interface to the details page corresponding to the first card includes: The jump is executed using the first jump method; If the electronic device does not support the first redirection method or if redirection based on the first redirection method fails, the redirection is performed using the second redirection method.

4. The method according to claim 3, characterized in that, The first card can be clicked and then redirected in various ways, including via third-party applications, quick apps, and H5.

5. The method according to claim 3 or 4, characterized in that, The first card redirection data also includes a sequence number and a resource identifier, with each redirection method corresponding to a sequence number and a resource identifier; The jump performed via the first jump method includes: If the electronic device supports the first jump method, the first details page is obtained according to the first resource identifier corresponding to the first jump method, and the user jumps from the negative one screen to the first details page. Specifically, when the first redirection method is a third-party application redirection method, the first details page is the third-party application page corresponding to the first card; when the first redirection method is a quick app redirection method, the first details page is the quick app page corresponding to the first card; when the first redirection method is an H5 redirection method, the first details page is the H5 page corresponding to the first card.

6. The method according to any one of claims 1 to 5, characterized in that, Before the first card is displayed in the first area of ​​the negative one screen interface, the method further includes: In response to the user's confirmation of the second operation of adding the first card, the first card is loaded and displayed on the negative one screen interface; The negative one screen application calls the quick app engine to create the first V8 process; After creating the first V8 process, the Quick App Engine calls a preset jump component and configures the first card jump data to the negative one screen application through the first V8 process.

7. The method according to claim 6, characterized in that, The quick app engine is configured with the preset jump component, which includes the out-link-view component. The out-link-view component supports the linkType parameter field, the uris parameter field, and the linkresult callback field. The linkType parameter field carries information about multiple redirection methods corresponding to the first card, the uris parameter field carries the resource identifier corresponding to each redirection method, and the linkresult callback field carries the redirection result after the first card is clicked.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Whenever the user navigates to the negative one screen, the card content in the first area is updated. Updating the card content in the first area includes: updating the card content in the first area from the first card to the second card.

9. The method according to claim 8, characterized in that, The step of updating the card content in the first area from the first card to the second card includes: The second card is loaded starting in the first area; When the first card and the second card are displayed overlapping in the first area, the first card is displayed in a first layer with a first transparency, and the second card is displayed in a second layer with a second transparency, wherein the first layer is higher than the second layer; the first transparency is higher than the second transparency; After the second card is loaded, the second card is displayed in the first area with the first transparency, and the first card and the first layer are cleared.

10. The method according to claim 9, characterized in that, The method further includes: When the first card and the second card are displayed overlapping in the first area, a third click event on the first card in the first area is detected; In response to the third click event, the user is redirected from the negative one screen to the details page corresponding to the first card.

11. The method according to claim 10, characterized in that, The step of loading the second card in the first area includes: The negative one screen application calls the quick app engine to create a second V8 process; After creating the second V8 process, the negative one screen application calls the second V8 process to load the second card in the first area; The step of jumping from the negative one screen to the details page corresponding to the first card includes: calling the second V8 process to jump from the negative one screen to the details page corresponding to the first card.

12. The method according to any one of claims 9 to 11, characterized in that, The first transparency is 0%, and the second transparency is 100%.

13. The method according to any one of claims 9 to 12, characterized in that, The method further includes: During the loading of the second card, the business data corresponding to the second card is obtained from the server side and the local cache of the electronic device, respectively. After the second card is loaded, if the first business data is obtained from the server side, the first business data is displayed in the second card; if no business data is obtained from the server side but the second business data is obtained from the local cache, the second business data is displayed in the second card.

14. The method according to claim 13, characterized in that, After displaying the first service data or the second service data in the second card, the method further includes: A fourth click event on the second card was detected; In response to the fourth click event, the second V8 process is invoked to jump from the negative one screen to the details page corresponding to the second card.

15. The method according to claim 13 or 14, characterized in that, The method further includes: If the second service data is obtained from the server side, the second service data is cached in the local cache area of ​​the electronic device; If the first service data is obtained from the server side, the second service data already stored in the local cache of the electronic device is replaced with the first service data; The update time of the first business data is later than the update time of the second business data.

16. An electronic device, characterized in that, The electronic device includes: one or more processors, and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 15.

17. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 15.

18. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 15.

Images