Card display method and electronic device

Abstract

The present application relates to the technical field of quick application cards, and provides a card display method and an electronic device. In a scenario in which a plurality of cards are displayed on an interface such as a desktop or a minus-one screen, an operation performed by a user on a first card acts to trigger not only a display state change of the first card, but also a simultaneous display state change of a second card, thereby achieving real-time data linkage between cards. The solution of the present application creates an association among a plurality of cards, so that a display effect of the plurality of cards changes in a coordinated manner, thereby offering a richer variety of card display styles, and improving user experience. The solution of the present application provides a real-time linkage capability on the basis of card data exchange, which not only supports real-time data linkage between cards, but also supports data linkage between cards and quick applications.

Description

Card display methods and electronic devices

[0001] This application claims priority to Chinese patent application filed on January 25, 2025, with application number 202510121796.4 and entitled "Card Display Method and Electronic Device", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of quick app card technology, and more particularly to a card display method and electronic device. Background Technology

[0003] 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.

[0004] Currently, when multiple cards are added to the desktop, each card is independent in terms of function and display effect, resulting in a lack of variety in display styles and failing to meet user needs. Summary of the Invention

[0005] This application provides a card display method and electronic device that can link multiple cards together, allowing the display effects of the multiple cards to change in tandem, enriching the card display style and improving the user experience.

[0006] In a first aspect, this application provides a card display method applied to an electronic device. The method includes: displaying a first card and a second card on a desktop; updating the first card to a first display state in response to a first operation by a user on the first card; triggering the second card to update to a second display state when the first card is updated to the first display state; updating the first card to a third display state in response to a second operation by a user on the first card; and triggering the second card to update to a fourth display state when the first card is updated to the third display state.

[0007] The card display method provided in this application, in scenarios where multiple cards are displayed on an interface such as a desktop or negative one screen, responds to user actions on the first card, triggering not only a change in the display state of the first card but also a corresponding change in the display state of the second card, thus achieving real-time data linkage between cards. For example, if the data of the first card changes, the second card can update its display state based on the data change of the first card. This application's solution can establish a connection between multiple cards, enabling the display effects of multiple cards to change in tandem, enriching the card display style and improving the user experience.

[0008] This application provides a real-time linkage capability based on card data exchange, enabling real-time linkage between the data exchange of multiple cards. For example, when a user clicks on the decompression switch card 1, not only does the display state of the decompression switch card 1 change, but the display state of the glowing clock card 2 also changes accordingly, thereby realizing real-time data linkage between cards.

[0009] For example, a decompression switch card 1 (first card) and an luminous clock card 2 (second card) are displayed on the desktop. When the user clicks the decompression switch card 1 on the desktop, the display state of the decompression switch card 1 changes, for example, the decompression switch changes from the closed state to the open state (first display state); at this time, the display state of the luminous clock card 2 changes accordingly, for example, the luminous clock changes from the off state to the lit state (second display state).

[0010] For example, when the user clicks the decompression switch card 1 on the desktop, the display state of the decompression switch card 1 changes, such as the decompression switch changing from the on state to the off state (third display state); at this time, the display state of the glowing clock card 2 changes accordingly, such as the glowing clock changing from the lit state to the off state (fourth display state).

[0011] In some possible implementations, after displaying the first card and the second card on the desktop, the method further includes: calling a registration listener interface to establish a first registration listener relationship between the first card and the second card; the first registration listener relationship includes the second card listening to data changes of the first card.

[0012] The registered listener interface can be represented as the `exchange.registerObserver` interface. By registering a listener, one card can register to listen for data changes in another card. For example, after the second card registers to listen for data changes in the first card, once the first card's data changes, the message about the data change in the first card will be sent back to the second card via the Quick App engine. This achieves real-time interaction between the first and second cards.

[0013] This application solution establishes a registration and monitoring relationship between a first card and a second card, allowing the second card to change in sync with the display status of the first card. This solution can also link multiple cards, enabling their display effects to change in tandem, enriching the card display style and improving the user experience.

[0014] Specifically, in terms of the overall process, this application embodiment adds a listening and notification mechanism to the original data interaction process. When the card writes data and transmits it to the Quick App Engine, if other cards have registered for data change notifications, the Quick App Engine will notify the registered listening cards in real time.

[0015] For example, when the write data of the first card is transmitted to the Quick App Engine, if a second card has registered for notification of data changes of the first card, the Quick App Engine will notify the second card of the write data of the first card in real time, thereby realizing real-time data linkage between cards.

[0016] This application, based on the original interface, provides a register listener interface (e.g., represented by the `exchange.registerObserver` interface) and a cancel listener interface (e.g., represented by the `exchange.unRegisterObserver` interface). After two cards are initialized, one card can call the `exchange.registerObserver` interface to listen for data changes in other cards; when listening is no longer needed or the card is destroyed, calling the `exchange.unRegisterObserver` interface can cancel the card's registration as a listener.

[0017] In some possible implementations, the step of calling the registration listener interface to establish a first registration listener relationship between the first card and the second card includes: calling the registration listener interface to generate first registration listener parameters through the ContentProvider component of the Quick App engine.

[0018] The first registration monitoring parameters include the package name of the monitoring card, the package name of the monitored card, the key parameter, and the value parameter.

[0019] The key parameter represents the object being monitored, and the value parameter represents the state value of the object being monitored.

[0020] For example, the monitored object can be monitored for its on / off state. A state value of 1 indicates the on state, and a state value of 0 indicates the off state.

[0021] Among them, the package name of the monitored card is set to the package name of the second card, and the package name of the monitored card is set to the package name of the first card.

[0022] In some possible implementation manners, when the first card is updated to the first display state, triggering the second card to be updated to the second display state includes: the ContentProvider component receives the first write data of the first card; the ContentProvider component updates the value parameter value in the first registered monitoring parameter based on the first write data; wherein, the value parameter value represents the first display state; the ContentProvider component calls back the key parameter and the value parameter value of the first card to the second card according to the updated first registered monitoring parameter, triggering the second card to be updated to the second display state.

[0023] In some possible implementation manners, the first registered monitoring data is represented in the form of a Uniform Resource Identifier (URI).

[0024] In some possible implementation manners, the ContentProvider component receives the first write data of the first card, including: the first card calls a data interaction interface to pass the first write data to the ContentProvider component.

[0025] Among them, the data interaction interface may refer to the set method of the service.exchange interface. This application is improved based on the service.exchange interface, and can push data changes in real time to meet the purpose of real-time linkage.

[0026] In some possible implementation manners, the first card calls a data interaction interface to pass the first write data to the ContentProvider component, including: the first card interacts with the V8 service process, calls the data interaction interface to request to write the first write data; the V8 service process interacts with the quick application engine through cross-process communication to pass the first write data to the quick application engine; the quick application engine stores the first write data through the ContentProvider component.

[0027] In some possible implementation manners, the registered monitoring interface includes the package name of the monitored card or application, the space type of data publication, the signature of the data publisher, the monitoring parameter, the return parameter when the callback is successful, and the output code when the callback fails.

[0028] In some possible implementations, the method further includes: calling the cancel listening interface to terminate the first registered listening relationship.

[0029] The interface for canceling the listener can be represented as the exchange.unregisterObserver interface.

[0030] In some possible implementations, the cancel listener interface includes the package name of the listener card or application, the listener parameters, the return parameters for a successful callback, and the output code for a failed callback.

[0031] In some possible implementations, after calling the cancel listening interface to release the first registered listening relationship, the method further includes: in response to a third operation by the user on the first card, updating the first card to the first display state; while the first card is updated to the first display state, the display state of the second card remains unchanged; in response to a fourth operation by the user on the first card, updating the first card to a third display state; while the first card is updated to the third display state, the display state of the second card remains unchanged.

[0032] In some possible implementations, the method further includes: calling a registration listening interface to establish a second registration listening relationship between the first card and the first application; the second registration listening relationship includes the first card listening to data changes of the first application.

[0033] This application solution enables the association between cards and quick apps, allowing the card display to change in sync with the quick app, enriching the card display style and improving the user experience.

[0034] In some possible implementations, after calling the registration listener interface to establish a second registration listener relationship between the first card and the first application, the method further includes: when the data of the first application changes from first data to second data, the first card updates its display status based on the second data.

[0035] This application solution not only supports simple data exchange between cards, but also supports real-time data linkage between cards. Building upon card data exchange, this solution provides a real-time linkage capability, enabling real-time linkage between data exchange of multiple JS cards, and also supports data linkage between cards and quick apps.

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

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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

[0044] Figure 1 is a schematic diagram of the desktop display of multiple quick app cards and the user's operation on the cards;

[0045] Figure 2 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0046] Figure 3 is a schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0047] Figure 4 is a schematic diagram of the application interface of the card display method provided in the first embodiment of this application;

[0048] Figure 5 is a schematic diagram of the software architecture of the card display method provided in the first embodiment of this application;

[0049] Figure 6 is a schematic diagram of the timing interaction process of the card display method provided in the first embodiment of this application;

[0050] Figure 7 is a flowchart illustrating the card display method provided in the second embodiment of this application;

[0051] Figure 8A is a schematic diagram of the application interface of the card display method provided in the second embodiment of this application;

[0052] Figure 8B is a schematic diagram of the application interface of the card display method provided in the second embodiment of this application;

[0053] Figure 9 is a schematic diagram of the software architecture of the card display method provided in the second embodiment of this application;

[0054] Figure 10 is a schematic diagram of the timing interaction process of the card display method provided in the second embodiment of this application;

[0055] Figure 11 is a schematic diagram of the timing interaction process of the card display method provided in the second embodiment of this application;

[0056] Figure 12 is a schematic diagram of the application interface of the card display method provided in the third embodiment of this application;

[0057] Figure 13 is a schematic diagram of the software architecture of the card display method provided in the third embodiment of this application;

[0058] Figure 14 is a schematic diagram of the timing interaction process of the card display method provided in the third embodiment of this application. Detailed Implementation

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

[0060] Hereinafter, the terms "first," "second," etc., are used to distinguish different objects, not to describe a specific order of objects. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

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

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

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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).

[0074] 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.

[0075] In practice, users can add multiple cards with various functions to the desktop. As shown in Figure 1(a), the desktop displays a decompression switch card 1 and an illuminated clock card 2.

[0076] The decompression switch card 1 can be in an on or off state. For example, if decompression switch card 1 is in the off state and the user clicks it, as shown in Figure 1(b), decompression switch card 1 switches from the off state to the on state. If the user clicks it again, decompression switch card 1 switches from the on state back to the off state. This clicking operation can trigger decompression switch card 1 to switch on and off states, displaying different patterns, thus providing a stress-relieving and entertaining effect.

[0077] The illuminated clock card 2 can switch between different states to display time information. As shown in Figures 1(c) and (d), if the user clicks on the illuminated clock card 2, it will illuminate to display the time information. If the user clicks on it again, it will turn off. This clicking action triggers the illuminated clock card 2 to switch its display state, providing the user with different display effects.

[0078] It should be noted that when multiple cards are added to the desktop, each card is independent in terms of function and display effect, resulting in a lack of variety in display style and failing to meet user needs.

[0079] To address the aforementioned issues, this application provides a card display method and electronic device. In scenarios where multiple cards are displayed on a desktop or negative one screen, in response to a user's operation on a first card, not only can the display state of the first card be triggered to change, but the display state of the second card can also be triggered to change accordingly, achieving real-time data linkage between cards. This application's solution can establish associations between multiple cards, allowing the display effects of multiple cards to change in tandem, enriching the card display style and improving the user experience.

[0080] Based on card data exchange, this application provides a real-time linkage capability, which not only supports real-time data linkage between cards, but also supports data linkage between cards and quick apps.

[0081] When multiple cards are added to the desktop (e.g., Card 1 and Card 2), a relationship can be established between Card 1 and Card 2, allowing Card 2 to change according to the display state of Card 1. This solution enables the association of multiple cards, allowing their display effects to change in tandem, enriching the card display style and improving the user experience.

[0082] The following description, in conjunction with the accompanying drawings, describes the electronic device to which the card display 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.

[0083] Figure 2 shows a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. For example, taking a mobile phone as an example, as shown in Figure 2, 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 a pressure sensor and a touch sensor.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] In this embodiment of the application, the processor 110 is used to implement the card display method provided in the real-time example of the application.

[0090] 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.

[0091] 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, etc. The data storage area may store data created during the use of the electronic device, 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.

[0092] For example, in an embodiment of this application, the processor 110 can execute instructions stored in the internal memory 121 to implement the card display method provided in the real-time example of this application.

[0093] 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.

[0094] 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.

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

[0096] 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.

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

[0098] 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.

[0099] 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.

[0100] 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.

[0101] Figure 3 is a software structure block diagram of an electronic device 100 according to an embodiment of this application.

[0102] 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.

[0103] 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.

[0104] Applications on the negative one screen can display cards. These cards serve as an intermediate form between icons and full-screen applications, acting as quick operation tools and information overview windows for users, recommending service information. For example, the negative one screen can display quick app cards, native cards, or widget cards. For clarity, this application uses quick app cards as an example.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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.

[0111] 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.

[0112] 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.

[0113] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0114] In this embodiment of the application, the application framework layer may include a card service unit (or JS card module) for managing the addition / deletion, display and update of quick app cards, as well as page redirection after a card is clicked.

[0115] The card service unit may include an event handler, which may be used to handle card exposure events or card click events.

[0116] 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.

[0117] 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.

[0118] 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 card service unit interacts with the AMS unit to determine whether the V8 process is alive.

[0119] If the V8 process is confirmed to be alive, the card service unit can call the V8 process of the quick app engine to jump from the current negative one screen to the card details page.

[0120] Once it's confirmed that the V8 process has been cleared, the card service unit calls the card navigation data configured in the negative one screen application to navigate from the current negative one screen interface to the card details page. This card navigation data includes navigation methods such as third-party application navigation, quick app navigation, or H5 navigation.

[0121] 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.

[0122] 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.

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

[0124] The card interface includes a data interaction interface (service.exchange interface). This interface includes setter and getter methods. Application A can use the setter method to write its updated data to the Quick App Engine. Application B can use the getter method to retrieve Application A's updated data from the Quick App Engine.

[0125] The card interface also includes a listener registration interface (exchange.registerObserver interface). This allows one card to register and listen for data changes in another card. For example, after card 2 registers to listen for data changes in card 1, once card 1 changes its data, the message about the change will be sent back to card 2 via the Quick App engine. This achieves real-time interaction between card 1 and card 2.

[0126] The card interface also includes an unregistered listener interface (exchange.unregisterObserver interface). This allows a card to stop listening to data changes on another card.

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

[0128] 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.

[0129] 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.

[0130] The card display method provided in this application can be implemented by the aforementioned electronic device, or by a functional module and / or entity within the electronic device capable of implementing the card display method. Furthermore, the solution in this application can be implemented through hardware and / or software, the specific implementation depending on actual usage requirements, and this application does not impose any limitations. The following description uses an electronic device as an example, along with the accompanying drawings, to exemplarily illustrate the card display method provided in this application.

[0131] 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 may be as shown in Figure 2, and the software structure block diagram of the electronic device may be as shown in Figure 3, but the embodiments of this application are not limited thereto. The executing entity of the card display method provided in the embodiments of this application can be an electronic device, or it can be a hardware and / or software module in the electronic device. For ease of explanation, the embodiments of this application will be executorized by taking an electronic device as the executing entity.

[0132] Quick Apps and Quick App Cards are lightweight application formats that leverage the dynamic rendering capabilities of a JavaScript engine to update dynamically without requiring deployment. The Quick App engine also provides communication capabilities; the Quick App Alliance defines standard API communication interfaces, allowing Quick Apps and Quick App Cards to communicate with native applications through the Quick App engine, such as network calls, Bluetooth connections, and data exchange.

[0133] For developers of Quick App cards, the "manifest" configuration file in the card installation package declares the API interfaces to be used, thus giving the Quick App card permission to call the API.

[0134] For example, the configuration information in the "manifest" configuration file can be represented in the following code form:

[0135] As shown in the image above, developers need to declare information such as card name, package name, and version number. They can also declare a list of APIs to be called, which are injected into the Quick App Engine as "features" information.

[0136] First Embodiment

[0137] In the first embodiment, data exchange between different cards can be achieved through the service.exchange interface.

[0138] It should be noted that data exchange is a native capability supported by the Quick App Engine, which facilitates data exchange through the service.exchange interface. For example, a scenario where data exchange is implemented by calling the service.exchange interface is as follows: Application A writes data to the Quick App Engine using the set method of the service.exchange interface, and Application B reads the data written by Application A from the Quick App Engine using the get method of the service.exchange interface.

[0139] In the first embodiment, data exchange between a mood calendar card and a perpetual calendar card is used as an example for explanation. Using the card display method provided in the first embodiment, a user can edit their daily mood on the mood calendar card, and correspondingly, the perpetual calendar card can acquire the mood data and display the mood status for the corresponding date on the perpetual calendar card.

[0140] Figure 4 shows a schematic diagram of the application interface of the card display method provided in the first embodiment of this application.

[0141] As shown in Figures 4(a) to (e), a mood calendar card 3 and a perpetual calendar card 4 are displayed on the desktop. Daily moods can be added using mood calendar card 3. All dates can be viewed using perpetual calendar card 4.

[0142] As shown in Figures 4(a) to (c), the initial display of Mood Calendar Card 3 is empty, meaning no mood icons are displayed. When the user clicks on Mood Calendar Card 3, it displays multiple mood options, such as "calm icon," "sad icon," and "happy icon," for the user to choose from. After the user selects a mood option (e.g., "happy icon"), the display of Mood Calendar Card 3 changes to "happy icon." Thus, users can add various mood icons to Mood Calendar Card 3 for different dates.

[0143] As shown in (d) to (e) of Figure 4, the initial display content of the perpetual calendar card 4 is date information. When the user clicks on a certain date of the perpetual calendar card 4, the display content of the perpetual calendar card 4 changes. In addition to displaying date information, the perpetual calendar card 4 also displays a "mood icon" of the date selected by the user.

[0144] For example, in response to user action, today's mood on mood calendar card 3 is displayed as a "happy icon". If the user clicks on today's date on perpetual calendar card 4, then perpetual calendar card 4 changes from displaying today's date information to displaying today's date information and a "happy icon".

[0145] Figure 5 shows a schematic diagram of the software framework corresponding to the card display method provided in the first embodiment of this application. As shown in Figure 5, the host application (e.g., the negative one screen or desktop) can act as a card container to display multiple cards, such as card 3 and card 4. Card 3 and card 4 can respectively interact with the host application. Card 3 is the card corresponding to the first application. Card 4 is the card corresponding to the second application.

[0146] The Quick App Engine includes a ContentProvider component in the storage layer. The ContentProvider component has data storage capabilities.

[0147] V8 services are child processes of the Quick App engine. V8 services consist of a communication layer (JSBridge) and a business layer. V8 services provide data transfer services for writing and reading data.

[0148] In Android development, ContentProvider is a crucial component that allows applications to share data with other applications. ContentProvider manages CRUD (Create, Read, Update, Delete) operations on data through a set of standard interfaces. These standard interfaces include the query() function, the insert() function, the update() function, and the delete() function.

[0149] The following example uses card 3 as the data writer and card 4 as the data reader.

[0150] Referring to the arrows in the diagram, the writing process is as follows: Card 3 can write data A to the ContentProvider component in the storage layer of the Quick App Engine through the communication layer JSBridge and the business layer of the V8 service.

[0151] Referring to the arrow in the diagram, the reading process is as follows: Card 4 can read the data A written by Card 3 from the ContentProvider component of the storage layer in the Quick App Engine through the communication layer JSBridge and business layer of the V8 service.

[0152] For example, users can edit their daily mood in Mood Calendar Card 3. Mood Calendar Card 3 writes the daily mood data to the ContentProvider component in the storage layer of the Quick App Engine via the V8 service. Perpetual Calendar Card 4 can retrieve the daily mood data from the ContentProvider component in the storage layer of the Quick App Engine and display the corresponding mood status or mood icon on the Perpetual Calendar Card 4 based on the daily mood data.

[0153] Figure 6 illustrates the timing interaction flow of the card display method provided in the first embodiment of this application. Figure 6 includes a host application (such as a desktop or negative one screen), a quick app engine, a V8 service (engine subprocess), and a JS card module. The following description uses a desktop application as the host application as an example. Figure 6 describes the possible implementations of the first embodiment from four aspects: the card 3 adding process, the card 4 adding process, the card 3 writing data process, and the card 4 reading data process.

[0154] Card 3 Adding Process

[0155] S201, The host application receives a user's request to add card 3 (such as a mood calendar card).

[0156] S202. The host application creates a card container. This card container is used to hold card 3.

[0157] S203. The host application requests the Quick App Engine to create a CardView component for Card 3. The CardView component is a UI component used to display a card-style layout.

[0158] S204, the Quick App Engine creates a CardView component for Card 3 and returns a message of successful creation to the host application.

[0159] S205, the quick app engine obtains the application resources of card 3 based on the package name of card 3.

[0160] S206. The Quick App Engine creates a V8 service and requests to bind to the V8 service.

[0161] The Quick App Engine is the main process, and the V8 service is the child process.

[0162] The communication method between the Quick App Engine and V8 services is cross-process communication.

[0163] S207 and V8 service initialization requests to establish JSBridge communication with the JS card module.

[0164] The S208 and V8 services received a message from the JS card module indicating that communication had been successfully established.

[0165] The S209 and V8 services return a message indicating successful binding to the Quick App Engine.

[0166] S210 and the Quick App Engine read the application resources of card 3, parse the manifest configuration file, and obtain the declared features (including service.exchange interface information).

[0167] The service.exchange interface supports writing and reading data.

[0168] S211, Quick App Engine calls the V8 service to register the service.exchange interface.

[0169] The S212 and V8 services inject the service.exchange interface into the JS card module.

[0170] S213, the JS card module declares the service.exchange interface for card 3. After the declaration is completed, card 3 has the permission to call the service.exchange interface.

[0171] S214, the JS card module returns a message to the V8 service indicating that the injection interface has been completed.

[0172] The S215 and V8 services return a message indicating that the injection interface is complete to the Quick App Engine.

[0173] S216, the Quick App Engine creates the application for Card 3 and calls the V8 service to initialize the page.

[0174] The S217 and V8 service notification JS card module renders the page content of card 3.

[0175] The S218 and V8 services receive page rendering events sent by the JS card module.

[0176] The S219 and V8 services send a message to the Quick App Engine indicating that rendering is complete.

[0177] S220, Quick App Engine notifies the host application to attach a card view.

[0178] S221, The host application displays card 3 on the desktop.

[0179] Card 4 Adding Process

[0180] S222, The host application receives a user's request to add card 3 (such as a mood calendar card).

[0181] S223, the host application, the quick app engine, the V8 service, and the JS card module interact to complete the process of adding card 4.

[0182] The specific processing steps, such as creating a card container, binding the V8 service, registering the service.exchange interface, and rendering the card, are similar to those for card 1 and will not be described in detail here.

[0183] S224, The host application displays card 4 on the desktop.

[0184] Card 3 data writing process

[0185] S225, the JS card module receives the user's operation on card 3.

[0186] For example, a user can enter their mood for the day on Mood Calendar Card 3. For ease of explanation, let's call today's mood data Data A. Card 3 updates its display status based on Data A.

[0187] S226, the JS card module interacts with the V8 service, calling the set method of the service.exchange interface to write data A.

[0188] The S227 and V8 services transmit data A to the Quick App Engine via cross-process communication.

[0189] S228. The Quick App Engine stores data A through the ContentProvider component in the storage layer.

[0190] Card 4 Data Reading Process

[0191] S229, the JS card module receives user actions on card 4, such as clicking a date on the perpetual calendar card 4. The user can view their mood status by clicking the date.

[0192] The S230 and JS card modules interact with the V8 service by calling the get method of the service.exchange interface to read data A.

[0193] The S231 and V8 services communicate across processes with the Quick App engine to read data A.

[0194] S232. The Quick App Engine calls the get method of the service.exchange interface to retrieve data A from the ContentProvider component in the storage layer.

[0195] S233, the Quick App Engine returns the acquired data A to the V8 service via cross-process communication.

[0196] The S234 and V8 services pass data A to the JS card module.

[0197] S235, the JS card module updates card 4 based on data A.

[0198] S236, The JS card module instructs the host application to update card 4.

[0199] S237. The host application (such as a desktop application) updates card 4 as instructed, for example, displaying the mood status on the perpetual calendar card 4.

[0200] Using the solution provided in the first embodiment, card 3 writes the changed data A into the ContentProvider component, card 4 can obtain the changed data A from the ContentProvider component, and card 4 can change the display status based on the changed data A from card 3.

[0201] Referring back to the interface diagram in Figure 4, in a real business scenario, when a user enters their mood "Happy" (data A) on the Mood Calendar card 3 for the first date, correspondingly, when the user clicks on the first date on the Perpetual Calendar card 4, the Perpetual Calendar card 4 can retrieve the mood status "Happy" for the first date and display it on the Perpetual Calendar card 4. Thus, the two cards exchange data; a change in one card can trigger a change in the other, enriching the display of multiple card scenarios and improving the user experience.

[0202] Second Embodiment

[0203] In the second embodiment, not only is simple data exchange between cards supported, but real-time data linkage between cards is also supported. Based on JS card data exchange, this application provides a real-time linkage capability, allowing data exchange between multiple JS cards to be synchronized in real time.

[0204] For example, in a real-world business scenario, developers create two cards: a decompression switch and an luminous clock. If a user adds both cards to their desktop, the luminous clock's state changes when the user clicks the decompression switch.

[0205] Referring to Figure 7, in response to user operation, the electronic device can add a decompression switch card 1 and an illuminated clock card 2 to the desktop. When the electronic device receives a click operation from the user on the decompression switch card 1, if the display state of the decompression switch card 1 changes to "decompression switch is on", then the display state of the illuminated clock card 2 changes to "illuminated clock is on"; if the display state of the decompression switch card 1 changes to "decompression switch is off", then the display state of the illuminated clock card 2 changes to "illuminated clock is off".

[0206] In other words, when the user clicks the decompression switch card 1, not only does the display state of the decompression switch card 1 change, but the display state of the luminous clock card 2 also changes accordingly, thus realizing real-time data linkage between the cards.

[0207] Figure 8A shows a schematic diagram of the application interface of the card display method provided in the second embodiment of this application.

[0208] As shown in Figure 8A(a), a decompression switch card 1 and an illuminated clock card 2 are displayed on the desktop. Before the improvement, when the user clicks the decompression switch card 1 on the desktop, the display state of the decompression switch card 1 changes, for example, the decompression switch changes from the closed state to the open state; at this time, the display state of the illuminated clock card 2 does not change.

[0209] As shown in Figure 8A(b), a decompression switch card 1 and an luminous clock card 2 are displayed on the desktop. After the improvement, when the user clicks the decompression switch card 1 on the desktop, the display state of the decompression switch card 1 changes, for example, the decompression switch changes from the closed state to the open state; at this time, the display state of the luminous clock card 2 changes accordingly, for example, the luminous clock changes from the off state to the lit state.

[0210] Figure 8B shows a schematic diagram of the application interface of the card display method provided in the second embodiment of this application.

[0211] As shown in Figure 8B(a), a decompression switch card 1 and an luminous clock card 2 are displayed on the desktop. Before the improvement, when the user clicks the decompression switch card 1 on the desktop, the display state of the decompression switch card 1 changes, for example, the decompression switch changes from the on state to the off state; at this time, the display state of the luminous clock card 2 does not change.

[0212] As shown in Figure 8B(b), a decompression switch card 1 and an luminous clock card 2 are displayed on the desktop. After the improvement, when the user clicks the decompression switch card 1 on the desktop, the display state of the decompression switch card 1 changes, for example, the decompression switch changes from the on state to the off state; at this time, the display state of the luminous clock card 2 changes accordingly, for example, the luminous clock changes from the lit state to the off state.

[0213] As shown in Figures 8A and 8B, after the improvement, the display state of card 2 can change in tandem with card 1.

[0214] The above example, using the coordinated changes of decompression switch card 1 and luminous clock card 2, illustrates the possible implementation of the interactive interface of the card display method provided in this application when applied to the above scenario. The following example, using the coordinated changes of decompression switch card 1 and luminous clock card 2, further illustrates the specific improvement strategies and timing interaction flowchart of the card display method provided in this application.

[0215] In the first embodiment described above, this application can call the service.exchange interface to implement data writing and reading of cards, thereby realizing data interaction between cards. In the second embodiment, this application improves upon the service.exchange interface, enabling real-time push of data changes to achieve real-time linkage.

[0216] Specifically, in terms of the overall process, the second embodiment of this application adds a listening and notification mechanism to the original data interaction process. When the card writes data and transmits it to the Quick App Engine, if other cards have registered for data change notifications, the Quick App Engine will notify the registered listening cards in real time.

[0217] For example, when the write data of card 1 is transmitted to the Quick App Engine, if card 2 has registered for notification of data changes of card 1, then the Quick App Engine will notify card 2 of the write data of card 1 in real time, thereby realizing real-time data linkage between cards.

[0218] This application, based on the existing service.exchange interface, provides a register listener interface (e.g., exchange.registerObserver) and a cancel listener interface (e.g., exchange.unRegisterObserver). After two cards are initialized, one card can call the exchange.registerObserver interface to listen for data changes in other cards; when listening is no longer needed or the card is destroyed, calling the exchange.unRegisterObserver interface can cancel the card's registration as a listener.

[0219] For example, in this embodiment of the application, the parameter information of the exchange.registerObserver interface is shown in Table 1 below.

[0220] Table 1

[0221] The code representation of the exchange.registerObserver interface is shown below.

[0222] For example, in this embodiment of the application, the parameter information of the exchange.unregisterObserver interface is shown in Table 2 below.

[0223] Table 2

[0224] Figure 9 illustrates a schematic diagram of the software framework corresponding to the card display method provided in the second embodiment of this application. As shown in Figure 9, the host application (e.g., the negative one screen or desktop) can act as a card container to display multiple cards, such as card 1 and card 2. Card 1 and card 2 can respectively interact with the host application. Card 1 and card 2 each correspond to a quick app.

[0225] The Quick App Engine includes the ContentProvider component in the storage layer. The ContentProvider component has data storage capabilities. The V8 service is a subprocess of the Quick App Engine. The V8 service includes the JSBridge communication layer and the business logic layer. The V8 service provides data writing and reading services.

[0226] It should be noted that, in this embodiment of the application, Android ContentProvider provides the ability to register and cancel listeners.

[0227] The following example uses card 1 as the data writer and card 2 as the data reader.

[0228] Referring to the arrows in the diagram, the registration listener process is as follows: Card 2 calls the registration listener interface to request to register and listen for data changes in Card 1. This registration listener request message is passed to the ContentProvider component of the Quick App engine through the V8 service's communication layer JSBridge and business layer. The ContentProvider component provides the ability to register listeners and records the registration listener information: Card 2 registers to listen for Card 1.

[0229] Referring to the arrows in the diagram, the writing process is as follows: Card 1 can write data B to the ContentProvider component of the Quick App engine through the communication layer JSBridge and business layer of the V8 service. The ContentProvider component stores the data B written by Card 1.

[0230] Referring to the arrow in the diagram, the notification process is as follows: Based on the registration listening information "Card 2 registers to listen to Card 1", the ContentProvider component can notify Card 2 of the data B written by Card 1 through the business layer and communication layer JSBridge of the V8 service.

[0231] For example, a user can click on the decompression switch card 1 to trigger a change in its state. Decompression switch card 1 then writes its state data to the ContentProvider component of the Quick App engine via a V8 service. If the glowing clock card 2 has registered to listen for decompression switch card 1, the ContentProvider component of the Quick App engine sends the decompression switch state data to the glowing clock card 2, allowing the glowing clock card 2 to receive real-time updates on the changes in decompression switch card 1.

[0232] Figure 10 illustrates the timing interaction flow of the card display method provided in the second embodiment of this application. Figure 10 includes a host application (such as a desktop or negative one screen), a quick app engine, a V8 service (engine subprocess), and a JS card module. The following description uses a desktop application as the host application as an example. Figure 10 describes the possible implementations of the second embodiment from four aspects: the card 1 addition process, the card 2 addition process, the card 2 registration and listening process, and the real-time linkage process between card 1 and card 2.

[0233] Card 1 Addition Process

[0234] S301, The host application receives a user-triggered operation to add card 1 (such as decompression switch card).

[0235] S302, the host application, the Quick App engine, the V8 service, and the JS card module interact to complete the process of adding card 1. Specific processing steps such as creating the card container, binding the V8 service, registering the service.exchange interface, and rendering the card are similar to those for card 1 and will not be elaborated here.

[0236] S303, The host application displays card 1 on the desktop.

[0237] Card 2 Addition Process

[0238] S304. The host application receives a user-triggered operation to add card 2 (such as a glowing clock card).

[0239] S305, the host application, the Quick App engine, the V8 service, and the JS card module interact to complete the process of adding card 4. Specific processing steps such as creating the card container, binding the V8 service, registering the service.exchange interface, and rendering the card are similar to those for card 1 and will not be repeated here.

[0240] S306, The host application displays card 2 on the desktop.

[0241] It should be noted that this application does not limit the order in which card 1 and card 2 are added to the desktop. This example illustrates the process by adding card 1 first, then card 2. In actual implementation, card 2 can also be added first, followed by card 1.

[0242] After Card 1 and Card 2 are added to the desktop, the card registration listening process is triggered.

[0243] It should be noted that after card 1 and card 2 are added to the desktop, card 1 can register to listen to card 2; or card 2 can register to listen to card 1; or card 1 and card 2 can register to listen to each other. This embodiment of the application uses card 2 registering to listen to card 1 as an example for illustrative purposes.

[0244] Card 2 Registration Listening Process

[0245] S307, Card 2 initiates registration and monitoring of Card 1.

[0246] S308 and Card 2 call the exchange.registerObserver interface to request the V8 service to register a listener for Card 1.

[0247] The S309 and V8 services transmit registration listening request messages to the Quick App Engine via cross-process communication.

[0248] Among them, the registration listening request message is card 2 requesting to register and listen to card 1.

[0249] S310 and the Quick App Engine register a URI for card 2 through the ContentProvider component and listen for changes in card 1.

[0250] The ContentProvider component can provide a unique URI to represent the registered listener relationship.

[0251] A URI (uniform resource identifier) ​​can be a sequence of strings used to identify and locate a resource.

[0252] For example, a first URI is registered for card 2 using the ContentProvider component. This first URI can include the identifier of card 1 (e.g., the card package name) and the identifier of card 2. This first URI is used to indicate that the object being monitored by card 2 is card 1.

[0253] For example, the URI in the default form of this application may include the package name of the monitored card, the package name of the monitored card, a key parameter, and a value parameter. The key parameter represents the monitored object, and the value parameter represents the status value of the monitored object.

[0254] The ContentProvider component can generate a specific URI by setting the package name of the monitored card, the package name of the monitored card, the key parameter, and the value parameter based on a URI in a preset format.

[0255] For example, taking the registration of the luminous clock card 2 to monitor the decompression switch card 1 as an example, the first URI includes the package name of the luminous clock card 2, the package name of the decompression switch card 1, the on / off state of the decompression switch, and the on / off state value. Among them, the on / off state can be either on or off.

[0256] The registration URI includes: setting the key parameter to the on / off state of the decompression switch, and setting the value parameter to the on / off state value.

[0257] For example, when the value parameter is 1, it can indicate the on state; when the value parameter is 0, it can indicate the off state.

[0258] Real-time linkage process between Card 1 and Card 2

[0259] S311, the JS card module receives user operations on card 1. For example, the user clicks on the decompression switch card 1, triggering the decompression switch to change its state; for ease of explanation, the decompression switch state data is referred to as data B.

[0260] The S312 and JS card modules write data B to card 1, such as switch status data. Card 1 can update its display status based on the switch status data.

[0261] The S313 and JS card modules interact with the V8 service by calling the set method of the service.exchange interface to write data B.

[0262] The S314 and V8 services transmit data B to the Quick App Engine via cross-process communication.

[0263] S315, The Quick App Engine stores data B of card 1 through the ContentProvider component.

[0264] Within the ContentProvider component, there exists a first URI, which indicates that card 2 is listening on card 1. Once card 1 writes data, card 2 is notified of the data written by card 1.

[0265] As described above, the luminous clock card 2 registers to monitor the decompression switch card 1. The corresponding first URI includes the package name of the luminous clock card 2, the package name of the decompression switch card 1, the key parameter (indicating the on / off state of the decompression switch), and the value parameter (indicating the on / off state value).

[0266] S316. The Quick App engine notifies the registered URIs. Thus, based on the URIs, the Quick App engine determines that card 2 is among the cards registered to listen for card 1.

[0267] The ContentProvider component updates the first URI based on data B from card 1.

[0268] For example, data B from card 1 indicates that the decompression switch is on. Accordingly, the ContentProvider component updates the value parameter in the first URI to 1 based on data B from card 1. That is, it indicates that the decompression switch is currently on.

[0269] The ContentProvider component can implement data callback through the first URI. That is, the ContentProvider component returns the key parameter and the specific value (corresponding to parameter B) of card 1 to card 2.

[0270] S317, the Quick App Engine interacts with the V8 service, calls back the onChange event, and sends data B of card 1 to the V8 service.

[0271] The S318 and V8 services pass data B from card 1 to the JS card module.

[0272] S319, the JS card module updates card 2 based on data B from card 1.

[0273] The S320 and JS card modules instruct the host application to update card 2.

[0274] S321. The host application (such as a desktop application) updates card 2 as instructed, for example, changing the display state of the glowing clock card to a clock lit state or a clock off state.

[0275] Using the solution provided in the second embodiment, card 1 writes the changed data B to the ContentProvider component. If card 2 has registered to listen to card 1, card 2 can obtain the changed data B from card 1 in real time from the ContentProvider component. Furthermore, card 2 can change its display status based on the changed data B from card 1.

[0276] Referring back to the interface diagram in Figure 8A, in a real-world business scenario, when the user clicks on the decompression switch card 1, the decompression switch is activated (Data B). Correspondingly, following the change in the decompression switch card 1, the display state of the glowing clock card 2 changes to glowing. Thus, the two cards achieve real-time data exchange; a change in one card can trigger a change in the other, enriching the display effect of multiple card scenarios and enhancing the user experience.

[0277] The above describes the card registration and monitoring process. The following section, with reference to Figure 11, explains the card cancellation and monitoring process.

[0278] S401 to S403 describe the process of adding card 1, S404 to S406 describe the process of adding card 2, and S407 to S410 describe the process of card 2 registering to listen to card 1. For details, please refer to the descriptions of S301 to S310 above.

[0279] In S411 and S412, if card 1 and / or card 2 are destroyed, the JS card module interacts with the V8 service and calls the exchange.unregisterObserver interface to request the V8 service to unregister the listening to card 1.

[0280] The S413 and V8 services transmit cancel listening request messages to the Quick App Engine via cross-process communication.

[0281] Among them, the message to cancel listening is card 2 requesting to cancel listening to card 1.

[0282] S414. The Quick App Engine cancels Card 2's registration listening to Card 1 through the ContentProvider component and deletes the registered URI.

[0283] When a card is destroyed, the `exchange.unRegisterObserver` interface can be called to unregister the card from the listener. Alternatively, the `exchange.unRegisterObserver` interface can be called to unregister the card from the listener when the card is no longer needed. The specific settings can be configured according to actual usage requirements; this embodiment does not impose any limitations on this.

[0284] Third Embodiment

[0285] The solution provided in this application not only enables real-time data linkage between multiple cards, but also between cards and quick apps. Based on card data exchange, this solution provides the capability for real-time linkage between cards, allowing for real-time data exchange between multiple cards, and also supports real-time data linkage between cards and quick apps.

[0286] For example, a card can register to listen for data changes in a Quick App. When the Quick App interface changes, the card can update its display status or content accordingly.

[0287] Figure 12 shows a schematic diagram of the application interface of the card display method provided in the third embodiment of this application. The example described uses a sports and health card as the card and a sports and health application as the quick app.

[0288] As shown in Figures 12(a) and (b), a fitness card 5 is displayed on the desktop, showing information such as today's steps and exercise plan. When the user clicks on fitness card 5, the electronic device responds to the card click event, triggering the launch of the fitness application and displaying its interface. The fitness application interface displays today's steps, exercise plan, and modification options.

[0289] As shown in Figures 12(c) and (d), in response to the user's action on the exercise plan modification option, the electronic device modifies the exercise plan data. Accordingly, the exercise plan information displayed in the desktop's fitness card 5 also changes to match the modified exercise plan information in the fitness application's interface.

[0290] As shown in Figure 12, the display status of the sports and health card 5 can change in conjunction with the sports and health application.

[0291] It should be noted that Figure 12 is an example of a user clicking a card to trigger a jump to the quick app interface. In actual implementation, it is not limited to this method. If the card registers to listen to the quick app, and the quick app changes its data, the card can obtain the changed data of the quick app in real time, and then the card can update the displayed content or display status accordingly.

[0292] Figure 13 illustrates a schematic diagram of the software framework corresponding to the card display method provided in the third embodiment of this application. As shown in Figure 13, the host application (e.g., the negative one screen or desktop) can act as a card container to display multiple cards, such as card 5 and several other cards. Card 5 can interact with the host application.

[0293] Similar to the second embodiment described above, the Quick App engine includes a ContentProvider component in the storage layer. The ContentProvider component has data storage capabilities. The V8 service is a subprocess of the Quick App engine. The V8 service includes a JSBridge communication layer and a business layer. The V8 service provides data writing and reading services. Specifically, the Android ContentProvider provides the ability to register and unregister listeners.

[0294] The following example uses the first application as the data writer and card 5 as the data reader.

[0295] As shown in Figure 13(a), before optimization, referring to the arrows in the figure, the 1-writing process is as follows: The first quick application can write data C to the ContentProvider component of the quick application engine through the communication layer JSBridge and business layer of the V8 service. The ContentProvider component stores the data C written by the first quick application. Then, referring to the arrows in the figure, the 2-reading process is as follows: Card 5 can read the data C written by the first quick application from the ContentProvider component of the storage layer in the quick application engine through the communication layer JSBridge and business layer of the V8 service.

[0296] As shown in Figure 13(b), after optimization, referring to the arrows in the figure, the 1-registration listener process is as follows: Card 5 calls the registration listener interface to request registration and listener for data changes in the first quick application. This registration listener request message is passed to the ContentProvider component of the quick application engine through the communication layer JSBridge and the business layer of the V8 service. The ContentProvider component provides the ability to register and listen, and records the registration and listening information: Card 5 registers and listens for the first quick application.

[0297] Referring to the arrows in the diagram, the writing process (2-) is as follows: The first quick application can write data C to the ContentProvider component of the quick application engine through the communication layer JSBridge and the business layer of the V8 service. The ContentProvider component stores the data C written by the first quick application.

[0298] Referring to the arrow in the diagram, the notification process is as follows: Based on the registration listening information "Card 5 registers to listen to the first application", the ContentProvider component can notify Card 5 of the data C written by the first application through the business layer and communication layer JSBridge of the V8 service.

[0299] For example, a user can interact with the first quick app's interface to modify initial information. The first quick app then writes the modified information to the Quick App engine's ContentProvider component via the V8 service. If card 5 is registered to listen to the first quick app, the Quick App engine's ContentProvider component sends the modified information to card 5, allowing card 5 to receive real-time updates on the first quick app's changes. Then, card 5 updates its display status or content based on the modified information from the first quick app.

[0300] Figure 14 illustrates the timing interaction flow of the card display method provided in the third embodiment of this application. Figure 14 includes a host application (such as a desktop or negative one screen), a quick app engine, a V8 service (engine subprocess), a JS card module, and a first quick app. The following description uses a desktop application as the host application as an example. Figure 14 describes the possible implementations of the third embodiment from three aspects: the card 5 addition process, the card 5 registration and listening process, and the real-time linkage process between the card and the quick app.

[0301] Card 5 Adding Process

[0302] S501, The host application receives a user's request to add card 5 (such as a sports and health card).

[0303] S502, the host application, the Quick App engine, the V8 service, and the JS card module interact to complete the process of adding card 5. Specific processing steps such as creating the card container, binding the V8 service, registering the service.exchange interface, and rendering the card are similar to those for card 1 and will not be repeated here.

[0304] S503, The host application displays card 5 on the desktop.

[0305] After card 5 is added to the desktop, the card registration listening process is triggered.

[0306] It should be noted that after card 5 is added to the desktop, card 5 can register to listen to the first application; or the first application can register to listen to card 5, or card 5 and the first application can register to listen to each other. This embodiment of the application uses card 5 registering to listen to the first application as an example for illustrative purposes.

[0307] Card 5 Registration Listening Process

[0308] S504 and Card 5 initiate registration and monitoring of the first application.

[0309] S505 and Card 5 call the exchange.registerObserver interface to request the V8 service to register the first application to listen for observation.

[0310] The S506 and V8 services transmit registration listening request messages to the Quick App Engine via cross-process communication.

[0311] Among them, the registration listening request message is Card 5 requesting to register and listen to the first fast application.

[0312] S507, the Quick App Engine registers a URI for card 5 through the ContentProvider component and listens for changes in the first Quick App.

[0313] The ContentProvider component can generate URIs to represent registered listener relationships.

[0314] For example, a second URI can be registered for card 5 via the ContentProvider component. This second URI can include the identifier of card 5 and the identifier of the first application. The first URI is used to indicate that the listening object for card 5 is the first application.

[0315] For example, the URI in the default form of this application may include the package name of the monitoring card, the package name of the monitored app, a key parameter, and a value parameter. The key parameter represents the monitored object, and the value parameter represents the status value of the monitored object.

[0316] The ContentProvider component can generate a specific URI by setting the package name of the listening card, the package name of the monitored app, the key parameter, and the value parameter based on a URI in a preset format.

[0317] Card 5 and the First Fast App Real-time Linkage Process

[0318] S508: After the first quick app is launched, the quick app interface is displayed.

[0319] S509 and S510, the first quick application receives the user's operation on the quick application interface and writes data C on the quick application interface, such as data C being exercise plan settings data.

[0320] S511, the first application interacts with the V8 service, calling the set method of the service.exchange interface to write data C.

[0321] S512 and V8 services transmit data C to the Quick App Engine via cross-process communication.

[0322] S513, the Quick App Engine stores data C through the ContentProvider component.

[0323] Within the ContentProvider component, a second URI exists, indicating that card 5 is listening on the first application. Once the first application writes data, card 5 is notified of the data C written by the first application.

[0324] The ContentProvider component updates the second URI based on the data C from the first application.

[0325] The ContentProvider component can implement data callbacks through the updated second URI. That is, the ContentProvider component returns the key parameter and the specific value (corresponding to parameter C) of the first application to card 5.

[0326] S513. The Quick App engine determines the registered URIs based on the identifier of the first Quick App. Thus, the Quick App engine determines, based on the registered URIs, that cards registered to listen to the first Quick App include card 5.

[0327] S514, the Quick App engine interacts with the V8 service, calls back the onChange event, and sends the first Quick App's data C to the V8 service.

[0328] The S318 and V8 services pass the data C of the first application to the JS card module.

[0329] S319, the JS card module updates card 5 based on the data C from the first application.

[0330] The S320 and JS card modules instruct the host application to update card 5.

[0331] S321. The host application (such as a desktop application) updates card 5 as instructed, for example, by updating the exercise plan information in card 5 based on the exercise plan settings data.

[0332] Using the solution provided in the third embodiment, the first application writes the changed data C to the ContentProvider component. If card 5 has registered to listen to the first application, card 5 can obtain the changed data C from the first application in real time from the ContentProvider component. Furthermore, based on the changed data C from the first application, card 5 can update its display status.

[0333] Referring back to the interface diagram in Figure 12, in a real-world business scenario, when a user operates within the sports and health application interface, triggering changes to exercise plan data (data C), the exercise plan information displayed on the sports and health card 5 changes accordingly. This enables real-time data exchange between the card and the quick app. Changes in the quick app can dynamically adjust the card display, resulting in richer card presentation and improved user experience.

[0334] It should be noted that this example illustrates the registration of a listener between a sports and health card and a sports and health application. This application is not limited to registering a listener between the card and the corresponding quick application. In actual implementation, a listener can also be registered between the card and other quick applications.

[0335] In the above embodiments of this application, not only is simple data exchange between cards supported, but real-time data linkage between cards is also supported. Based on card data exchange, this application provides a real-time linkage capability, enabling real-time linkage of data exchange between multiple JS cards, and also supporting data linkage between cards and quick apps.

[0336] 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".

[0337] 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.

[0338] 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.

[0339] 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.

[0340] 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.

[0341] 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.

[0342] 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 card display method in the above embodiment.

[0343] 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 card display method in the above embodiment.

[0344] 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.

[0345] 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 device, 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 devices or units may be electrical, mechanical, or other forms.

[0346] 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.

[0347] 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 card display method, applied to an electronic device, characterized in that, The method includes: Display the first and second cards on the desktop; In response to the user's first operation on the first card, the first card is updated to a first display state; When the first card is updated to the first display state, the second card is triggered to update to the second display state; In response to the user's second operation on the first card, the first card is updated to a third display state; When the first card is updated to the third display state, the second card is triggered to be updated to the fourth display state.

2. The method according to claim 1, characterized in that, After displaying the first card and the second card on the desktop, the method further includes: Call the registration listener interface to establish a first registration listener relationship between the first card and the second card; The first registered listening relationship includes the second card listening to data changes of the first card.

3. The method according to claim 2, characterized in that, The invocation of the registration listener interface to establish a first registration listener relationship between the first card and the second card includes: Call the register listener interface to generate the first register listener parameters through the ContentProvider component of the Quick App engine; The first registration monitoring parameters include the package name of the monitoring card, the package name of the monitored card, the key parameter, and the value parameter. Wherein, the key parameter represents the object being monitored, and the value parameter represents the state value of the object being monitored; In this configuration, the packet name of the monitoring card is set to the packet name of the second card, and the packet name of the monitored card is set to the packet name of the first card.

4. The method according to claim 3, characterized in that, When the first card is updated to the first display state, triggering the second card to update to the second display state includes: The ContentProvider component receives the first write data from the first card; The ContentProvider component updates the value of the value parameter in the first registered listener parameter based on the first written data; wherein the value parameter represents the first display state; The ContentProvider component, based on the updated first registration listening parameters, sends the key and value parameters of the first card back to the second card, triggering the second card to update to the second display state.

5. The method according to claim 3 or 4, characterized in that, The first registration monitoring data is represented in the form of a Uniform Resource Identifier (URI).

6. The method according to claim 4, characterized in that, The ContentProvider component receives the first write data from the first card, including: The first card calls the data interaction interface to pass the first written data to the ContentProvider component.

7. The method according to claim 6, characterized in that, The first card invokes the data interaction interface to pass the first written data to the ContentProvider component, including: The first card interacts with the V8 service process and calls the data interaction interface to request the writing of the first write data; The V8 service process interacts with the Quick App engine through inter-process communication to pass the first written data to the Quick App engine; The Quick App Engine stores the first written data through the ContentProvider component.

8. The method according to any one of claims 2 to 7, characterized in that, The registered listening interface includes the package name of the listening card or application, the space type of the data publication, the signature of the data publisher, the listening parameters, the return parameters when successful, and the output code when failing.

9. The method according to any one of claims 2 to 8, characterized in that, The method further includes: Call the cancel listening interface to remove the first registered listening relationship.

10. The method according to claim 9, characterized in that, The cancel listening interface includes the package name of the listening card or application, the listening parameters, the return parameters when the success callback is successful, and the output code when the failure callback is unsuccessful.

11. The method according to claim 9 or 10, characterized in that, After calling the cancel listening interface and releasing the first registered listening relationship, the method further includes: In response to the user's third operation on the first card, the first card is updated to the first display state; When the first card is updated to the first display state, the display state of the second card remains unchanged; In response to the user's fourth operation on the first card, the first card is updated to the third display state; When the first card is updated to the third display state, the display state of the second card remains unchanged.

12. The method according to any one of claims 1 to 11, characterized in that, The method further includes: Call the registration listener interface to establish a second registration listener relationship between the first card and the first application; The second registration and monitoring relationship includes the first card monitoring data changes of the first application.

13. The method according to claim 12, characterized in that, After invoking the registration listener interface to establish a second registration listener relationship between the first card and the first application, the method further includes: When the data in the first application changes from the first data to the second data, the first card updates its display status based on the second data.

14. 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 13.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 13.

16. 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 13.

Images