Event transmission method of desktop card, event transmission device, vehicle and storage medium

Abstract

The invention provides an event transmission method of a desktop card, an event transmission device, a vehicle and a storage medium, the method is applied to the field of desktop cards, the method is applied to an application end, and the method comprises the following steps: configuring a plurality of communication instances with a desktop end; a card generation instruction is received, a desktop card is determined according to the card generation instruction, the desktop card and a communication instance corresponding to the desktop card are sent to a desktop end, and the communication instance comprises a communication protocol and a communication channel; and receiving a trigger event of the desktop card based on the communication channel and the communication protocol. Therefore, according to the method, the communication connection between the application end and the desktop end can be directly established by utilizing the updating mechanism of the desktop card, and the event is transmitted directly based on the communication instance corresponding to the desktop card, so that system resources are saved, the event transmission complexity is reduced, and the event transmission cost of the card is reduced.

Description

Technical Field

[0001] This application relates to the field of desktop cards, and more specifically, to an event transmission method, event transmission device, vehicle, and storage medium for desktop cards, according to the invention title "Desktop Card". Background Technology

[0002] With the increasing demand for intelligent vehicles, smart cockpits are being used more and more widely. To meet the growing functional needs of users, desktop cards for smart cockpits are being built through screen projection.

[0003] For desktop cards implemented via screen mirroring, related technologies use Services or custom AIDL to address the issue of passing card events from the Launcher to the corresponding application. However, this method increases the load on the card implementation and requires significant system resources. Summary of the Invention

[0004] This application provides a method, device, vehicle, and storage medium for transmitting events on desktop cards. The method can directly establish a communication connection between the application and the desktop using the desktop card update mechanism, and transmit events directly based on the communication instance corresponding to the desktop card, saving system resources, reducing the complexity of implementing event transmission, and lowering the event transmission cost of the card.

[0005] Firstly, an event transmission method for desktop cards is provided and applied to the application side. The event transmission method for desktop cards includes: configuring multiple communication instances with the desktop; receiving a card generation instruction, determining the desktop card according to the card generation instruction, and sending the desktop card and the corresponding communication instance to the desktop, wherein the communication instance includes a communication protocol and a communication channel; and receiving the triggering event of the desktop card based on the communication channel and the communication protocol.

[0006] The desktop card event transmission method of this application embodiment first configures multiple communication instances with the desktop. When receiving a card generation instruction, the corresponding desktop card and the corresponding communication instance of the desktop card are synchronously sent to the desktop. Event transmission is implemented based on the communication instance of each desktop card, so that the application does not need to implement a Service, thereby saving system resources and reducing implementation complexity. Furthermore, the application directly establishes a connection with the Launcher by utilizing the Widget update mechanism, and directly uses communication instances to transmit events, so that the application does not need an SDK, eliminating the maintenance costs caused by SDK upgrades.

[0007] In conjunction with the first aspect, in some possible implementations, multiple communication instances with the desktop are configured, including: defining a communication class for each preset desktop card on the application based on the inter-process communication class of the target system, wherein both the desktop and the application are located on the target system, and the communication class represents the communication channel with the desktop; determining the request processing function, request sending function, multiple preset events, and parameter identifiers of each preset desktop card to determine the communication protocol of the corresponding preset desktop card; and determining the communication instance of the corresponding preset desktop card according to the communication channel and communication protocol.

[0008] This embodiment defines communication instances based on the communication class (WidgetBinder class) of the preset desktop card and the corresponding communication protocol, thereby improving the accuracy of card event communication with the desktop and enhancing the event transmission effect.

[0009] Combining the first aspect and the above implementation methods, in some possible implementation methods, receiving the trigger event of the desktop card based on the communication channel and communication protocol includes: receiving card event information sent by the desktop through the communication channel based on the request processing function, wherein the card event information is generated based on the communication protocol; and matching the card event information based on the parameter identifier of each preset event to determine the trigger event of the desktop card.

[0010] This embodiment completes the reception and identification of trigger events based on communication channels and communication protocols, ensuring the effectiveness of event transmission while simplifying communication logic.

[0011] Secondly, an event transmission method for desktop cards is provided, which is applied to the desktop. The event transmission method for desktop cards includes: responding to a card generation instruction and forwarding the card generation instruction to the application; receiving the desktop card and the corresponding communication instance of the desktop card from the application based on the card generation instruction, wherein the communication instance includes a communication protocol and a communication channel; and sending the trigger event of the desktop card based on the communication protocol and the communication channel.

[0012] The desktop card event transmission method of this application embodiment first responds to a card generation command and forwards the command to the application. Upon receiving the desktop card and its corresponding communication instance from the application based on the card generation command, the desktop card is displayed. Simultaneously, upon receiving a card-triggered event, the event is transmitted directly based on the communication instance of the desktop card, thereby saving system resources and reducing the complexity of transmitting card events. Furthermore, the communication instance is transmitted to the desktop using the desktop card's own update logic to establish a communication connection between the application and the desktop, greatly simplifying the communication logic and reducing maintenance costs.

[0013] In conjunction with the second aspect, in some possible implementations, sending the desktop card's trigger event based on the communication protocol and communication channel includes: receiving card interaction instructions, determining the desktop card's trigger event based on the card interaction instructions, generating card event information based on the desktop card's trigger event and the communication protocol, and sending the card event information to the application terminal through the communication channel.

[0014] This embodiment identifies the trigger events of desktop cards based on the card interaction commands input by the user, generates card event information that can be recognized by the application according to the communication protocol, and successfully sends the card event information through the communication channel, thereby improving the communication accuracy of card events.

[0015] In combination with the second aspect and the above implementation methods, in some possible implementation methods, the communication protocol includes a desktop card request sending function, multiple preset events, and parameter identifiers for each preset event. The process of generating card event information based on the desktop card's trigger event and the communication protocol includes: matching the desktop card's trigger event with multiple preset events; determining the parameter identifiers of the desktop card's trigger events based on the matching results and the parameter identifiers of the corresponding preset events; and generating card event information based on the request sending function and the parameter identifiers of the desktop card's trigger events.

[0016] When this embodiment receives a trigger event from a user-input desktop card, it generates card event information based on the parameter identifier corresponding to the trigger event by calling a request sending function, and then sends the card event information to the application through the communication channel. This simplifies the communication logic while ensuring the effectiveness of event transmission.

[0017] Thirdly, an event transmission device for desktop cards is provided for application end. The device includes: a configuration module for configuring multiple communication instances with the desktop end; an instruction receiving module for receiving card generation instructions, determining the desktop card according to the card generation instructions, and sending the desktop card and the corresponding communication instance to the desktop end, wherein the communication instance includes a communication protocol and a communication channel; and an event receiving module for receiving trigger events of the desktop card based on the communication channel and the communication protocol.

[0018] Fourthly, an event transmission device for desktop cards is provided, applied to a desktop. The device includes: an instruction forwarding module, used to respond to a card generation instruction and forward the card generation instruction to an application; an instance receiving module, used to receive the desktop card and the corresponding communication instance of the desktop card fed back by the application based on the card generation instruction, wherein the communication instance includes a communication protocol and a communication channel; and an event sending module, used to send the trigger event of the desktop card based on the communication protocol and the communication channel.

[0019] Fifthly, a vehicle is provided, including a memory, a processor, and an event transmission program for a desktop card stored in the memory and executable on the processor, wherein when the processor executes the event transmission program for the desktop card, it implements any of the aforementioned possible event transmission methods for the desktop card.

[0020] In a sixth aspect, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the event transmission method for desktop cards in any of the above possible implementations. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of event transmission for desktop cards in related technologies; Figure 2 This is a flowchart of an event transmission method for a desktop card according to an embodiment of this application; Figure 3 This is a flowchart of an event transmission method for a desktop card according to another embodiment of this application; Figure 4 This is a schematic diagram of the event transmission between the application terminal and the desktop terminal of a specific embodiment of this application; Figure 5 This is a connection diagram of an event transmission device for a desktop card according to an embodiment of this application; Figure 6 This is a connection diagram of an event transmission device for a desktop card according to another embodiment of this application; Figure 7 This is a schematic diagram of the vehicle connection according to one embodiment of this application. Detailed Implementation

[0022] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of 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, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0023] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0024] With the increasing demand for intelligent vehicles, the application of smart cockpits is becoming more and more widespread. In the automotive field, smart cockpits aim to integrate various IT (Information Technology) and artificial intelligence technologies to create a brand-new integrated digital platform within the vehicle, providing drivers with an intelligent experience and promoting driving safety.

[0025] Smart cockpits are now primarily developing towards larger screens and multiple screens to provide immersive entertainment experiences. Information on frequently used functions is often displayed as desktop cards. Since the native cards in smart cockpits cannot achieve rich display effects, screen projection is used to create cards to meet users' functional needs.

[0026] For desktop cards implemented via screen mirroring, related technologies employ either Services or custom AIDL to address the issue of passing card events from the Launcher to the corresponding application. Here, the Launcher refers to the main interface seen after the in-vehicle system (such as Android) boots up; it's the first interactive interface that can be operated after startup. Cards (Widgets) are used to display functions provided by other applications. The Android system represents cards as Widgets. In the native system, Widgets only provide very simple interactions, and the interface display is limited. A Service refers to a service within the application that provides functions without program operation. AIDL, short for Android Interface Definition Language, is used to define communication rules between different processes.

[0027] In the above technical solution for card event transmission based on Service and AIDL communication, each card or application must implement a Service to connect to AIDL, which increases the load on the card implementation.

[0028] Meanwhile, based on the implementation requirements of AIDL, an SDK (Software Development Kit) needs to be provided to the application when AIDL is present. AIDL is a protocol for inter-process communication, and the SDK is a product-level development package that packages this protocol into an easy-to-use, robust, and evolvable solution. It is a combination of tools, documentation, examples, and libraries that are ready to be used for development, with the aim of enabling third-party developers to quickly call the functions provided by the platform or product with minimal code and low learning cost.

[0029] To further explain, Figure 1 Provide a simplified flowchart to demonstrate the card update process. Combined with... Figure 1As shown, when a widget wants to call the capabilities of an application across processes, it must bind to the service exposed by that application through the SDK and then communicate after obtaining the AIDL interface. However, if the AIDL changes, in addition to the corresponding SDK needing to be upgraded, applications in the system that have not upgraded their SDKs are likely to crash. Therefore, all applications need to be upgraded, making SDK management cumbersome and complex.

[0030] To address at least one of the aforementioned technical problems, this application proposes a method for transmitting events on desktop cards. Event transmission is implemented based on a communication instance of each desktop card, eliminating the need for the application to implement a Service, thereby saving system resources and reducing implementation complexity. Furthermore, the method utilizes the Widget update mechanism to directly establish a connection between the application and the Launcher, and directly uses communication instances to transmit events, eliminating the need for an SDK on the application and removing the maintenance costs associated with SDK upgrades.

[0031] Taking the application of this desktop card event transmission method to a vehicle as an example, the following is a detailed description of the desktop card event transmission method of this application with reference to the accompanying drawings.

[0032] Figure 2 This application provides an illustrative flowchart of an event transmission method for desktop cards.

[0033] In some embodiments of this application, the event transmission method of the desktop card is applied to the application side.

[0034] Specifically, a desktop card is a miniature application view that can be embedded on the desktop, displaying key information and core functions of the app without requiring the user to open the full app. The application side, or the app itself, is the provider of card data and the carrier of logic. It is responsible for telling the desktop side "what kind of cards can I provide" and providing the card view and data when needed.

[0035] For example, such as Figure 2 As shown, the event transmission method for desktop cards in this application embodiment may include: S101, configures multiple communication instances with the desktop; Specifically, the desktop, acting as the carrier of desktop cards, serves as the user interface of the operating system. It manages the layout, rendering, and interaction of the home screen, application icons, and desktop cards, providing a "container" and "framework." Taking a vehicle as an example, the desktop is the central control display screen in the smart cockpit. Using an Android system as an example, the desktop is the Launcher, while the application is the App.

[0036] Communication instances can be configured separately for multiple desktop cards of the application or for the application itself, without any specific restrictions. They are used to define the communication channel and protocol between the desktop and the application, so as to establish cross-process communication between the application and the desktop based on the communication instances.

[0037] Taking the in-vehicle system as an example of the Android system, the desktop end is the Launcher end, and the application end is the corresponding App end. Then the communication instance is the Binder instance of the Android system. Binder refers to the underlying mechanism and infrastructure of inter-process communication (IPC) in the Android system. It allows objects in one application (process) to make method calls and interact with objects in another application (process).

[0038] Furthermore, in addition to the operations mentioned above, the application also needs to prepare "card blueprints" and "card controllers" in advance. First, define one or more card metadata entries in the application's resource file. This card metadata includes descriptions of the card's static attributes, essentially acting as the "identity card" and "specification" for the desktop card. This may include: the default number of grid cells occupied by the card, the card's update request cycle, a preview image of the card (displayed to the user when adding a card), the initial layout file for the card, and configurable content. Additionally, the application needs to design the card layout, i.e., create a UI layout file for the desktop card, defining its display effect. Then, the application needs to create a desktop card provider, i.e., write a class that inherits from a specific base class (such as Android's application-side WidgetProvider). This class acts as a broadcast receiver, responsible for responding to various desktop requests, such as desktop card content update requests, desktop card resizing requests, desktop card removal requests, and desktop card creation requests. Furthermore, registration is required in the application's configuration file, declaring this card provider and pointing it to the previously defined metadata file, so that the operating system can listen for the corresponding desktop card service based on this information.

[0039] S102, Receive card generation instruction, determine desktop card according to card generation instruction, and send desktop card and corresponding communication instance to desktop terminal, wherein communication instance includes communication protocol and communication channel; Specifically, card generation commands can be triggered by user-selected desktop card creation commands. For example, when a user receives a desktop card creation command on the desktop, a corresponding card generation command is generated based on the desktop card requirements corresponding to the desktop card creation command, and then forwarded to the corresponding application. For instance, if a user expects a weather forecast card to be displayed on the Launcher, a corresponding card generation command is generated based on the card type of the selected weather forecast card and sent to the weather forecast app.

[0040] The application identifies the required desktop card based on the received card generation command and retrieves the corresponding communication instance. When the application updates and projects the desktop card to the Launcher, it also simultaneously sends the corresponding communication instance to the Launcher. This leverages the card's update logic to pass the communication instance to the Launcher. For example, if a user wants to display a weather forecast card on the Launcher, and the application is a weather forecast app, when the weather forecast app receives the card generation command, it identifies the desktop card as a weather forecast card and calls the corresponding communication instance (Binder object). Thus, while updating the weather forecast card to the Launcher, it simultaneously sends the corresponding communication instance to the Launcher, establishing a communication connection between the weather forecast app and the Launcher based on the communication instance.

[0041] In other words, when a user wants to add a desktop card, the desktop first enters card selection mode. For example, the user can trigger "add mode" by long-pressing an empty area of ​​the desktop or using a specific gesture. A menu will then pop up on the desktop, containing "widgets" or "cards" options. Next, the desktop scans and displays available cards. Specifically, it scans all installed applications that have declared card providers in their manifest file. This is done by reading the metadata defined in the first step for each application, obtaining information such as the desktop card's preview image, name, and size, and then displaying them to the user in a list or gallery format. Then, the user selects a desired card from the list, generating a corresponding card creation command. Upon receiving the user's card creation command, if the selected desktop card does not require configuration, the desktop directly sends a creation request to the system.

[0042] In other words, once the user confirms adding a card, the desktop client assigns a unique ID to this new card instance. Then, it initiates a remote card creation request to the application client. Upon receiving the card creation request, the application client, based on the card ID, sets the display content of various controls in the layout (such as setting text, images, and binding button click events), thereby constructing a card object containing the latest data and UI instructions—the desktop card—and synchronously sends the corresponding communication instance of the desktop card to the desktop client. The desktop client receives the card object returned by the application client. This object does not contain a real View object, but rather a series of UI operation instructions to be executed. At this point, the desktop client parses the instructions on the card object and, in the desktop's process space, creates and renders the actual interface of the card step by step according to the instructions. Therefore, the desktop card actually runs in the desktop's process, not the application client's process. That is to say, the application client is the content provider and logic designer for the desktop card, while the desktop client is the display window for the desktop card. S103, receiving the desktop card's trigger event based on the communication channel and communication protocol.

[0043] In other words, when the application updates and projects the desktop card to the Launcher, and also synchronously sends the corresponding communication instance of the desktop card to the Launcher, the desktop card is displayed through the Launcher. When the user triggers the corresponding event of the desktop card through the Launcher, such as a touch event, a hide event, or an update event, the Launcher converts the trigger event into a communication signal that the application can successfully recognize based on the communication protocol, and sends it to the application through the communication channel. The application receives the communication signal based on the communication channel and parses the communication signal based on the communication protocol to identify the trigger event of the desktop card, thus completing the transmission of the card event from the Launcher to the corresponding application.

[0044] Specifically, after the desktop card is created on the desktop, it is displayed on the desktop. When the user clicks a button on the card, this click event is captured by the desktop. The desktop sends this click event to the application based on the communication channel and protocol, returning control to the application to launch an Activity or Service on the application or send a broadcast, thereby updating the displayed content of the desktop components. For example, after receiving the click event, the application identifies the purpose of the event and determines that it is to launch an interface. At this time, the system will create a new task stack for this interface, or place it on an existing task stack. The target interface will go through the standard creation lifecycle and finally be displayed on the screen, overlaying the desktop. The user will feel as if they have "jumped" from the desktop to the application, thus completing the event triggering. Therefore, this embodiment, based on the App's custom implementation of a Binder and establishing a protocol with the Launcher for communication, can achieve system scalability and eliminate the need for SDK integration. Then, the Binder object is passed to the Launcher using the card's own update logic, establishing a communication connection between the application and the Launcher. This eliminates the need for Service implementation, greatly simplifies the communication logic, and reduces maintenance costs.

[0045] In some embodiments of this application, configuring multiple communication instances with the desktop includes: defining a communication class for each preset desktop card on the application based on the inter-process communication class of the target system, wherein both the desktop and the application are located in the target system, and the communication class represents the communication channel with the desktop; determining the communication protocol of the corresponding preset desktop card by determining the request processing function, request sending function, multiple preset events, and parameter identifiers of each preset event for each preset desktop card; and determining the communication instance of the corresponding preset desktop card according to the communication channel and the communication protocol.

[0046] Specifically, taking the in-vehicle system as an example, with Android as the target system, the application defines a communication class for each preset desktop card based on the inter-process communication (IPC) class of the Android system. By having each preset desktop card inherit from the Android system's IPC class (Binder class), a custom communication class (WidgetBinder class) is created for each preset desktop card, enabling cross-process communication capabilities. In other words, by limiting the communication class of each preset desktop card to the IPC mechanism within the target system, a communication channel between the application and the desktop is established.

[0047] Define a request handling function (onTransact method), a request sending function (Transact method) for each preset desktop card, multiple preset events (such as touch events, card hiding events, etc.), and a parameter identifier code for each preset event. The parameter identifier code is used by both parties to agree that each code represents a different functional meaning. For example, code 100 represents a touch event, and 200 represents a card hiding event. This determines the communication protocol for the corresponding preset desktop card so that the event can be successfully received and sent.

[0048] Then, based on the communication class (WidgetBinder class) and corresponding communication protocol of each preset desktop card, a communication instance (WidgetBinder instance) is constructed for each preset desktop card to establish communication between the application and the desktop.

[0049] This embodiment defines a communication instance based on the WidgetBinder class of the preset desktop card and the corresponding communication protocol, which improves the accuracy of card event communication with the desktop and enhances the event transmission effect.

[0050] In some embodiments of this application, receiving trigger events of desktop cards based on communication channels and communication protocols includes: receiving card event information sent by the desktop terminal through the communication channel based on a request processing function, wherein the card event information is generated based on the communication protocol; and matching the card event information based on the parameter identifier of each preset event to determine the trigger event of the desktop card.

[0051] In other words, when the application updates and projects the desktop cards to the Launcher, and also sends the corresponding communication instance of the desktop cards to the Launcher, the Launcher displays the desktop cards.

[0052] When a user triggers a desktop card's corresponding event via the Launcher, the Launcher converts the event into card event information based on the communication protocol and calls the request sending function (Transact method) to send the card event information to the application through the communication channel. The application receives the card event information through the communication channel using the request handling function (onTransact method), parses it according to the communication protocol, obtains the corresponding parameter identifier, and thus identifies the desktop card's trigger event. This completes the transmission of the card event from the Launcher to the corresponding application, enabling the launch of an Activity or Service on the application or sending a broadcast to update the displayed content of the desktop components.

[0053] This embodiment completes the reception and identification of trigger events based on communication channels and communication protocols, ensuring the effectiveness of event transmission while simplifying communication logic.

[0054] In summary, the event transmission method for desktop cards in this application embodiment first configures multiple communication instances with the desktop. When receiving a card generation instruction, the application synchronously sends the corresponding desktop card and the corresponding communication instance to the desktop. Event transmission is implemented based on the communication instance of each desktop card, eliminating the need for the application to implement a Service, thereby saving system resources and reducing implementation complexity. Furthermore, the application directly establishes a connection with the Launcher using the Widget update mechanism and directly uses communication instances to transmit events, eliminating the need for an SDK and removing the maintenance costs associated with SDK upgrades.

[0055] Figure 3 This is a schematic flowchart of another event transmission method for desktop cards provided in an embodiment of this application.

[0056] The following section continues by applying the event transmission method of this desktop card to a vehicle as an example, combined with the attached... Figure 3 The event transmission method of the desktop card in this application is described in detail.

[0057] In some embodiments of this application, the event transmission method of the desktop card is applied to the desktop.

[0058] For example, such as Figure 3 As shown, the event transmission method for this desktop card may include: S201 responds to the card generation instruction and forwards the card generation instruction to the application. Specifically, the desktop terminal serves as the carrier of desktop cards. Taking a vehicle as an example, the desktop terminal is the central control display screen in the smart cockpit. Taking the in-vehicle system as an Android system as an example, the desktop terminal is the Launcher terminal, while the application terminal is the App terminal.

[0059] Card generation commands can be triggered by users creating new desktop cards on the desktop. For example, when a user selects a new desktop card, the system generates a corresponding card generation command based on that request and forwards it to the relevant application. For instance, if a user expects a weather forecast card to be displayed on the Launcher, the system receives the corresponding card generation command based on the selected weather forecast card type and forwards it to the weather forecast app.

[0060] For example, when a user wants to add a desktop card, the desktop first enters card selection mode. This can be achieved by long-pressing an empty area or using a specific gesture to trigger "Add Mode," which displays a menu with "Widgets" or "Cards" options. Next, the desktop scans and displays available cards. It scans all installed applications that have declared card providers in their manifest files. Specifically, it reads the metadata defined in the first step for each application to obtain information such as the card's preview image, name, and size, and then presents them to the user in a list or gallery format. Then, the user selects a desired card from the list, generating a corresponding card creation command. Upon receiving the user's command, the desktop generates the card and forwards it to the application, initiating a remote card creation request.

[0061] S202, Receive the desktop card and the corresponding communication instance of the desktop card based on the card generation instruction feedback from the application end, wherein the communication instance includes the communication protocol and the communication channel; Specifically, the desktop card generated by the application based on the card is a series of UI operation instructions to be executed, i.e., card objects, corresponding to the desktop card. This allows the desktop to parse the card objects and, in the desktop's process space, create and render the actual interface of the card step by step according to the instructions, thus building desktop components.

[0062] A communication instance defines the communication channel and protocol between the desktop and the application, enabling cross-process communication between them. This can be configured separately for multiple desktop cards within the application or configured on the application itself; there are no specific restrictions. Taking an in-vehicle system as an example (Android system), with the desktop as the Launcher and the application as the corresponding application, the communication instance would be an Android Binder instance. Binder refers to the underlying mechanism and infrastructure of Inter-Process Communication (IPC) in Android, allowing objects in one application (process) to call methods and interact with objects in another application (process).

[0063] In addition to defining the communication instances mentioned above, the application also needs to prepare "card blueprints" and "card controllers" in advance. First, define one or more card metadata entries in the application's resource file. This card metadata includes descriptions of the card's static attributes, essentially acting as the "ID card" and "specification" for the desktop card. This may include: the default number of grid cells occupied by the card, the card's update request cycle, a preview image of the card (displayed to the user when adding a card), the initial layout file for the card, and configurable content. Secondly, the application needs to design the card layout, i.e., create a UI layout file for the desktop card, defining its display effect. Then, the application needs to create a desktop card provider, i.e., write a class that inherits from a specific base class (such as Android's application-side WidgetProvider). This class acts as a broadcast receiver, responsible for responding to various desktop requests, such as desktop card content update requests, desktop card resizing requests, desktop card removal requests, and desktop card creation requests. Furthermore, registration is required in the application's configuration file, declaring this card provider and pointing it to the previously defined metadata file, so that the operating system can listen for the corresponding desktop card service based on this information.

[0064] Upon receiving a card creation request, the application identifies the target card ID based on the card generation instructions. Then, based on the card ID, it sets the display content of various controls in the layout (such as setting text and images, binding button click events, etc.), thus constructing a card object containing the latest data and UI instructions—the desktop card. The application then synchronously sends the corresponding communication instance to the desktop client. The desktop client constructs desktop components based on the card object returned by the application and establishes communication with the application based on the communication instance.

[0065] Based on the above analysis, it can be seen that the desktop client can synchronously receive desktop cards and their corresponding communication instances based on the screen projection of the desktop cards, and the application client can use the update logic of the desktop cards themselves to pass the corresponding communication instances to the desktop client.

[0066] In other words, the application identifies the required desktop card based on the received card generation command and retrieves the corresponding communication instance. When the application updates and projects the desktop card to the Launcher, it also simultaneously sends the corresponding communication instance to the Launcher. This leverages the card's own update logic to pass the communication instance to the Launcher. For example, if a user wants to display a weather forecast card on the Launcher, and the application is a weather forecast app, when the weather forecast app receives the card generation command, it identifies the desktop card as a weather forecast card and calls the corresponding communication instance (Binder object). Thus, while updating the weather forecast card to the Launcher, it simultaneously sends the corresponding communication instance to the Launcher, establishing a communication connection between the weather forecast app and the Launcher based on the communication instance.

[0067] S203, a trigger event for sending desktop cards based on communication protocols and communication channels.

[0068] In other words, when the application updates and projects the desktop cards to the Launcher, and also synchronously sends the corresponding communication instance of the desktop card to the Launcher, the desktop cards are displayed through the Launcher. When the user triggers a corresponding event for the desktop card through the Launcher, such as a touch event, hide event, or update event, the Launcher converts the trigger event into a communication signal that the application can successfully recognize based on the communication protocol, and sends it to the application through the communication channel, thus completing the transmission of the trigger event from the Launcher to the corresponding application.

[0069] For example, after a desktop card is created on the desktop, it is displayed there. When a user clicks a button on the card, this click event is captured by the desktop. The desktop then sends this click event to the application based on the communication channel and protocol, returning control to the application. Upon receiving the click event, the application identifies the event and determines that its purpose is to launch an interface. At this point, the system creates a new task stack for this interface, or places it on an existing task stack. The target interface goes through a standard creation lifecycle and is finally displayed on the screen, overlaying the desktop. The user perceives themselves as having "jumped" from the desktop to the application, thus completing the event triggering.

[0070] Therefore, this embodiment implements a custom Binder on the App side and establishes a protocol with the Launcher side for communication. It uses the card's own update logic to pass the Binder object to the Launcher, establishing a communication connection between the Launcher side and the application side, thereby simplifying the communication logic of card events and reducing maintenance costs.

[0071] In some embodiments of this application, sending the trigger event of a desktop card based on a communication protocol and a communication channel includes: receiving a card interaction instruction, determining the trigger event of the desktop card based on the card interaction instruction, generating card event information based on the trigger event of the desktop card and the communication protocol, and sending the card event information to the application terminal through the communication channel.

[0072] In other words, users can input card interaction commands on the desktop, and the trigger events for the desktop cards are determined by recognizing these commands. For example, the corresponding trigger event can be determined by the trigger trajectory entered by the user in the card interaction command; or by the corresponding trigger event can be determined by the touch position entered by the user in the card interaction command. Then, based on the recognized trigger events of the desktop cards, card event information that can be recognized by the application is generated according to the communication protocol, and the card event information is sent to the application through the communication channel, thereby improving the communication accuracy of card events.

[0073] In some embodiments of this application, the communication protocol includes a desktop card request sending function, multiple preset events, and parameter identifiers for each preset event. Generating card event information based on the desktop card's trigger event and the communication protocol includes: matching the desktop card's trigger event with multiple preset events; determining the parameter identifier of the desktop card's trigger event based on the matching result and the parameter identifier of the corresponding preset event; and generating card event information based on the request sending function and the parameter identifier of the desktop card's trigger event.

[0074] In other words, the communication protocol includes a request and send function for desktop cards (Transact method), multiple preset events (such as touch events, card hiding events, etc.), and a parameter identifier code for each preset event. The parameter identifier code is used by both parties to agree that each code represents a different functional meaning. For example, code 100 represents a touch event, and 200 represents a card hiding event. This determines the communication protocol for the corresponding preset desktop card so that the event can be successfully received and sent.

[0075] When a user triggers a desktop card's corresponding event via the Launcher, the Launcher identifies the parameter identifier (code) of each preset event, calls the request sending function (Transact method), generates card event information based on the parameter identifier, and sends the card event information to the application through the communication channel. The application receives the card event information through the communication channel using the request processing function (onTransact method), parses the card event information according to the communication protocol, obtains the corresponding parameter identifier, and thus identifies the desktop card's trigger event, completing the transmission of the card event from the Launcher to the corresponding application.

[0076] This embodiment completes the information conversion and output of the triggered event based on the communication channel and communication protocol, ensuring the event transmission effect while simplifying the communication logic.

[0077] In summary, the desktop card event transmission method of this application embodiment, applied to the desktop, first responds to the card generation instruction and forwards the card generation instruction to the application. Upon receiving the desktop card and its corresponding communication instance from the application based on the card generation instruction, the desktop card is displayed. On the other hand, upon receiving a triggered event, the event is transmitted directly based on the communication instance of the desktop card, thereby saving system resources and reducing the complexity of transmitting card events. At the same time, the communication instance can be transmitted to the desktop using the desktop card's own update logic to establish a communication connection between the application and the desktop, greatly simplifying the communication logic and reducing maintenance costs.

[0078] Furthermore, as an embodiment of this application, such as Figure 4 As shown, the interaction sequence between the application widget and the launcher is as follows: 1. On the application side (App widget), a custom Binder instance (communication instance) is defined to implement the onTransact method. The parameter code is used by both parties to agree that each code represents a different function. For example, code 100 represents a touch event, and 200 represents a card hiding event.

[0079] In addition to the operations mentioned above, the application also needs to prepare "card blueprints" and "card controllers" in advance. First, define one or more card metadata entries in the application's resource file. This card metadata includes descriptions of the card's static attributes, essentially acting as the "identity card" and "specification" for the desktop card. This may include: the default number of grid cells occupied by the card, the card's update request cycle, a preview image of the card (displayed to the user when adding a card), the initial layout file for the card, and configurable content. Next, the application needs to design the card layout, i.e., create a UI layout file for the desktop card, defining its display effect. Then, the application needs to create a desktop card provider, i.e., write a class that inherits from a specific base class (such as Android's AppWidgetProvider). This class acts as a broadcast receiver, responsible for responding to various desktop requests, such as desktop card content update requests, desktop card resizing requests, desktop card removal requests, and desktop card creation requests. Furthermore, registration is required in the application's configuration file, declaring this card provider and pointing it to the previously defined metadata file, so that the operating system can listen for the corresponding desktop card service based on this information.

[0080] 2. Establishing communication between the application (App widget) and the desktop (Launcher) When the AppWidget updates the interface to the Launcher, it also sends the WidgetBinder instance (the communication instance corresponding to the desktop card) to the Launcher.

[0081] Specifically, when a user wants to add a desktop card, the desktop first enters card selection mode. For example, the user can trigger "Add Mode" by long-pressing an empty area of ​​the desktop or using a specific gesture. A menu will then pop up on the desktop, containing "Widgets" or "Cards" options. Next, the desktop scans and displays available cards. It scans all installed applications that have declared card providers in their manifest files. Specifically, it reads the metadata defined in the first step for each application to obtain information such as the desktop card's preview image, name, and size, and then displays them to the user in a list or gallery format. Then, the user selects a desired card from the list, generating a corresponding card creation command. Upon receiving the user's card creation command, if the selected desktop card does not require configuration, the desktop directly sends a creation request to the system.

[0082] In other words, once the user confirms adding a card, the desktop client assigns a unique ID to this new card instance. Then, it sends a remote card creation request to the application client. Upon receiving the request, the application client, based on the card ID, sets the display content of various controls in the layout (such as setting text and images, binding button click events, etc.), thus constructing a card object containing the latest data and UI instructions—the desktop card. The application client then synchronously sends the corresponding communication instance of the desktop card to the desktop client. The desktop client receives the card object returned by the application client. This object does not contain a real View object, but rather a series of UI operation instructions to be executed. At this point, the desktop client parses the instructions from the card object and, within the desktop's process space, creates and renders the actual interface of the card step by step according to the instructions. Therefore, the desktop card actually runs in the desktop's process, not the application's process.

[0083] 3. The Launcher obtains the WidgetBinder instance and calls its transact method to send an event to the AppWidget.

[0084] Specifically, after a desktop card is created on the desktop, it is displayed there. When a user clicks a button on the card, this click event is captured by the desktop. The desktop then sends this click event to the application based on the communication channel and protocol, returning control to the application to launch an Activity or Service or send a broadcast, thereby updating the displayed content of the desktop components. For example, after receiving a click event, the application identifies the event and determines that its purpose is to launch an interface. At this point, the system creates a new task stack for this interface or places it on an existing task stack. The target interface goes through a standard creation lifecycle and is finally displayed on the screen, overlaying the desktop. The user will perceive a "jump" from the desktop to the application, thus completing the event triggering.

[0085] Therefore, this embodiment implements a custom Binder on the application side and establishes a protocol with the desktop side for communication, achieving system scalability and eliminating the need for SDK integration. Then, the desktop side obtains the Binder object used for communication through the original logic of the card, establishes a communication connection between the application and the Launcher, thus eliminating the need for Service implementation and directly sending events, simplifying the inter-process communication logic.

[0086] Figure 5 This is a schematic diagram of the structure of an event transmission device for a desktop card provided in an embodiment of this application.

[0087] For example, such as Figure 5As shown, the event transmission device for this desktop card is used on the application side, and the device includes: Configuration module 101 is used to configure multiple communication instances with the desktop. The instruction receiving module 102 is used to receive the card generation instruction, determine the desktop card according to the card generation instruction, and send the desktop card and the corresponding communication instance to the desktop terminal. The communication instance includes the communication protocol and the communication channel. The event receiving module 103 is used to receive trigger events from desktop cards based on the communication channel and communication protocol.

[0088] Therefore, this embodiment implements a custom communication instance on the application side and establishes a protocol with the desktop side for communication, achieving system scalability and eliminating the need for SDK integration. Then, the communication instance object is passed to the desktop side using the card's own update logic, establishing a communication connection between the application and the desktop. This eliminates the need for a Service implementation, greatly simplifying the communication logic and reducing maintenance costs.

[0089] In some embodiments of this example, the configuration module 101 configures multiple communication instances with the desktop, specifically for: defining a communication class for each preset desktop card on the application based on the inter-process communication class of the target system, wherein both the desktop and the application are located in the target system, and the communication class represents the communication channel with the desktop; determining the request processing function, request sending function, multiple preset events, and parameter identifiers of each preset desktop card to determine the corresponding communication protocol for the preset desktop card; and determining the communication instance for the corresponding preset desktop card according to the communication channel and communication protocol. Thus, by defining communication instances based on the inter-process communication class and corresponding communication protocol of the preset desktop card, the accuracy of card event communication with the desktop is improved, and the event transmission effect is enhanced.

[0090] In some embodiments of this example, the event receiving module 103 receives trigger events from desktop cards based on a communication channel and a communication protocol. Specifically, it is used to: receive card event information sent by the desktop through the communication channel based on a request processing function, wherein the card event information is generated based on the communication protocol; and match the card event information with the parameter identifier of each preset event to determine the trigger event of the desktop card. Thus, the reception and identification of trigger events are completed based on the communication channel and the communication protocol, ensuring the event transmission effect while simplifying the communication logic.

[0091] In summary, the event transmission device for desktop cards in this application embodiment configures multiple communication instances with the desktop through a configuration module on the application side. When the instruction receiving module receives a card generation instruction, it synchronously sends the corresponding desktop card and the corresponding communication instance to the desktop. This allows the event receiving module to transmit events based on the communication instance of each desktop card, eliminating the need for the application side to implement a Service, thereby saving system resources, reducing implementation complexity, and directly establishing a connection between the application side and the desktop using the desktop card update mechanism. Furthermore, by directly using communication instances to transmit events, the application side does not need an SDK, eliminating the maintenance costs associated with SDK upgrades.

[0092] Figure 6 This is a schematic diagram of the structure of an event transmission device for a desktop card provided in an embodiment of this application.

[0093] For example, such as Figure 6 As shown, the event transmission device for the desktop card, applied to the desktop, may include: The instruction forwarding module 201 is used to respond to the card generation instruction and forward the card generation instruction to the application terminal; The instance receiving module 202 is used to receive the desktop card and the corresponding communication instance of the desktop card from the application based on the card generation instruction. The communication instance includes a communication protocol and a communication channel. The event sending module 203 is used to send trigger events for desktop cards based on communication protocols and communication channels.

[0094] The device uses the card's own update logic to pass the communication instance object to the desktop, establishing a communication connection between the desktop and the application, thereby simplifying the communication logic of card events and reducing communication maintenance costs.

[0095] In some embodiments of this application, the event sending module 203 sends the trigger event of the desktop card based on the communication protocol and communication channel. Specifically, it is used to: receive card interaction instructions; determine the trigger event of the desktop card based on the card interaction instructions; generate card event information based on the trigger event of the desktop card and the communication protocol; and send the card event information to the application terminal through the communication channel. This improves the communication accuracy of card events.

[0096] In some embodiments of this application, the communication protocol includes a desktop card request sending function, multiple preset events, and parameter identifiers for each preset event. The event sending module 203 generates card event information based on the desktop card's trigger event and the communication protocol. Specifically, it is used to: match the desktop card's trigger event with multiple preset events; determine the parameter identifier of the desktop card's trigger event based on the matching result and the parameter identifier of the corresponding preset event; and generate card event information based on the request sending function and the parameter identifier of the desktop card's trigger event. Thus, the information conversion and output of the trigger event are completed based on the communication channel and communication protocol, ensuring the event transmission effect while simplifying the communication logic.

[0097] Therefore, in the event transmission device for desktop cards according to this application embodiment, on the desktop, the instruction forwarding module first responds to the card generation instruction and forwards the card generation instruction to the application. When the instance receiving module receives the desktop card and the corresponding communication instance of the desktop card from the application based on the card generation instruction, the desktop card is displayed on the one hand, and on the other hand, when the event sending module receives the triggered event, the event is directly transmitted based on the communication instance of the desktop card, thereby saving system resources and reducing the complexity of transmitting card events.

[0098] It should be noted that for details not disclosed in the event transmission device of the desktop card in the embodiments of this application, please refer to the details disclosed in the event transmission method of the desktop card in the above embodiments of this application, which will not be repeated here.

[0099] Figure 7 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include: The memory 301, the processor 302, and the computer program stored on the memory 301 and capable of running on the processor 302.

[0100] When the processor 302 executes the program, it implements the event transmission method for desktop cards provided in the above embodiments.

[0101] Furthermore, the vehicle also includes: Communication interface 303 is used for communication between memory 301 and processor 302.

[0102] The memory 301 is used to store computer programs that can run on the processor 302.

[0103] The memory 301 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0104] If the memory 301, processor 302, and communication interface 303 are implemented independently, then the communication interface 303, memory 301, and processor 302 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0105] Optionally, in a specific implementation, if the memory 301, processor 302, and communication interface 303 are integrated on a single chip, then the memory 301, processor 302, and communication interface 303 can communicate with each other through an internal interface.

[0106] Processor 302 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0107] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for transmitting events of a desktop card.

[0108] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0109] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0110] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for transmitting events from a desktop card, characterized in that, When applied to the application side, the method includes: Configure multiple communication instances with the desktop client; Receive a card generation instruction, determine a desktop card according to the card generation instruction, and send the desktop card and the corresponding communication instance to the desktop terminal, wherein the communication instance includes a communication protocol and a communication channel; The desktop card's trigger event is received based on the communication channel and the communication protocol.

2. The event transmission method for desktop cards according to claim 1, characterized in that, Configure multiple communication instances with the desktop, including: Based on the inter-process communication class definition of the target system, a communication class is defined for each preset desktop card of the application terminal, wherein both the desktop terminal and the application terminal are located in the target system, and the communication class represents the communication channel with the desktop terminal; The communication protocol for the corresponding preset desktop card is determined by identifying the request processing function, request sending function, multiple preset events, and parameter identifiers for each preset desktop card. The communication instance of the corresponding preset desktop card is determined according to the communication channel and the communication protocol.

3. The event transmission method for desktop cards according to claim 2, characterized in that, Receiving trigger events from the desktop card based on the communication channel and the communication protocol includes: The request processing function receives card event information sent by the desktop client through the communication channel, wherein the card event information is generated based on the communication protocol; The triggering event of the desktop card is determined by matching the parameter identifier of each preset event with the card event information.

4. A method for transmitting events from a desktop card, characterized in that, Applied to desktop applications, the method includes: In response to a card generation instruction, the card generation instruction is forwarded to the application. The application receives a desktop card and a corresponding communication instance from the card generation instruction. The communication instance includes a communication protocol and a communication channel. The desktop card trigger event is sent based on the communication protocol and the communication channel.

5. The event transmission method for desktop cards according to claim 4, characterized in that, The trigger event for sending the desktop card based on the communication protocol and the communication channel includes: Receive card interaction instructions, and determine the triggering event of the desktop card based on the card interaction instructions; Card event information is generated based on the trigger event of the desktop card and the communication protocol, and the card event information is sent to the application terminal through the communication channel.

6. The event transmission method for desktop cards according to claim 5, characterized in that, The communication protocol includes a request sending function for the desktop card, multiple preset events, and parameter identifiers for each preset event. It generates card event information based on the desktop card's trigger events and the communication protocol, including: Match the trigger events of the desktop cards with the multiple preset events; The parameter identifier of the triggering event of the desktop card is determined based on the matching result and the parameter identifier of the corresponding preset event; The card event information is generated based on the parameter identifiers of the request sending function and the triggering event of the desktop card.

7. An event transmission device for a desktop card, characterized in that, For use in applications, the device includes: The configuration module is used to configure multiple communication instances with the desktop client; The instruction receiving module is used to receive a card generation instruction, determine a desktop card according to the card generation instruction, and send the desktop card and the corresponding communication instance to the desktop terminal, wherein the communication instance includes a communication protocol and a communication channel; An event receiving module is used to receive trigger events from the desktop card based on the communication channel and the communication protocol.

8. An event transmission device for a desktop card, characterized in that, For desktop applications, the device includes: The instruction forwarding module is used to respond to the card generation instruction and forward the card generation instruction to the application terminal; An instance receiving module is used to receive a desktop card and a corresponding communication instance from the application based on the card generation instruction, wherein the communication instance includes a communication protocol and a communication channel; The event sending module is used to send the trigger event of the desktop card based on the communication protocol and the communication channel.

9. A vehicle, characterized in that, The device includes a memory, a processor, and an event transmission program for a desktop card stored in the memory and executable on the processor. When the processor executes the event transmission program for the desktop card, it implements the event transmission method for the desktop card according to any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the event transmission method for desktop cards according to any one of claims 1-6.

Images