Method, electronic device and readable storage medium for displaying a card

Abstract

The application discloses a method for displaying a card, an electronic device and a readable storage medium, and belongs to the technical field of terminals. The method comprises the following steps: in response to order generation of a first application program, acquiring a first card view of a first card of the first application program and a background view of the first card view, the first card being used for displaying information related to the order; generating a second card view according to card setting parameters of a second application program, the first card view and the background view, the second application program being an application program used for displaying cards in the electronic device; and displaying the second card view through the second application program to display the first card. According to the application, different styles of cards can be displayed through the second application program without the need of the first application program to adapt itself, and the display effect of the cards is enriched.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a method for display cards, electronic devices, and readable storage media. Background Technology

[0002] With the rapid development of terminal technology, electronic devices such as mobile phones and tablets are becoming increasingly feature-rich. For example, electronic devices can display application notifications to users in the form of cards. These notifications can include text messages, trip information, ride-hailing information, food delivery information, and so on. Summary of the Invention

[0003] This application provides a method for displaying cards, an electronic device, and a readable storage medium, enabling the electronic device to display application cards with different display effects when displayed through different host applications, without requiring the application to adapt itself. The technical solution is as follows:

[0004] In a first aspect, a method for displaying a card is provided, applied to an electronic device, the method comprising:

[0005] In response to an order generated by a first application, the electronic device obtains a first card view and a background view of the first card view for a first card within the first application. The first application is an application in the electronic device that needs to display cards related to the order; the first application can be a third-party application or a system application. The first card is used to display information related to the order. Then, the electronic device generates a second card view based on card setting parameters of a second application, the first card view, and the background view, wherein the second application is an application in the electronic device used to display the card. Subsequently, the second card view is displayed through the second application to display the first card.

[0006] Thus, by obtaining a separate first card view and a background view of the first card view, and then processing the first card view and the second background view according to the display requirements of the second application, a second card view that meets the display requirements of the second application is obtained. Different styles of cards can be displayed through the second application without the first application needing to adapt itself, enriching the card display effects and improving card management efficiency.

[0007] As an example and not a limitation, the second application can be the desktop, notification center, lock screen, always-on display, or negative one screen. In implementation, the electronic device can display the first card in each second application using the method described above. Thus, when a second application is running in the foreground, the user can see the displayed first card within the foreground application, increasing the display space for the first card.

[0008] As an example of this application, before obtaining the first card view and the background view of the first card view of the first application, the electronic device obtains a first target layer in a first embedded window corresponding to the first application. The first embedded window is used for the first application to embed a second card view, and the first target layer is the actual layer in the first embedded window used to render the second card view; that is, the first target layer is used to render the second card view. Then, the electronic device creates a second embedded window for the second application; that is, the second embedded window is an embedded window used by the second application. Thus, the first target layer is embedded in the second embedded window to place a placeholder in the second embedded window, preventing the second application from displaying card views of other applications in the second embedded window. Additionally, a placeholder can be added to the second embedded window containing the first target layer to place a placeholder. The second embedded window with the added placeholder is added to the parent view of the second application, which is used to accommodate the second embedded window. In this way, the first target layer can be mounted to the second embedded window of the second application so that when the second card view is rendered with the first target layer, the rendered second card view can be displayed through the second embedded window of the second application, thereby achieving the display of the first card.

[0009] As an example of this application, the specific implementation of displaying the second card view through the second application to display the first card may include: rendering the second card view onto the first target layer of the second embedded window, and deleting the placeholder in the second embedded window. When displaying the interface of the second application, the second embedded window is displayed within the interface of the second application to display the first card within the interface of the second application.

[0010] Thus, by rendering the second card view onto the first target layer and removing the placeholders, the first card is displayed, which means that the first card with a custom style is displayed through the second application.

[0011] As an example of this application, the specific implementation of obtaining the first target layer in the first embedded window corresponding to the first application may include: querying whether the first embedded window exists in the electronic device. If the first embedded window exists in the electronic device, it indicates that the electronic device has previously created the first embedded window. In this case, the previously created first embedded window can be used directly, i.e., the first target layer in the first embedded window can be obtained. If the first embedded window does not exist in the electronic device, it indicates that the electronic device has not previously created the first embedded window. In this case, the electronic device creates the first embedded window and obtains the first target layer from the created first embedded window.

[0012] Thus, if a valid first embedded window exists, it can be used directly, avoiding the need to recreate it and improving processing speed. Of course, if a valid first embedded window does not exist, a first embedded window is created to render the second card view, thereby enabling the cards to be displayed synchronously in the host application through the embedded window.

[0013] As an example of this application, the card setting parameters include card rounded corner information, transparency indication information, and dynamic blur indication information. The transparency indication information indicates whether the second card view needs to be transparent, and the dynamic blur indication information indicates whether the first card needs to be displayed with a dynamic blur effect. The dynamic blur effect refers to the area where the first card is displayed on the interface of the second application, where the interface color of the second application is blurred through. In this case, the specific implementation of the electronic device generating the second card view based on the card setting parameters of the second application, the first card view, and the background view can include the following two possible scenarios:

[0014] In the first scenario, if the motion blur indicator indicates that the first card needs to be displayed with a motion blur effect, a second card view is generated based on the card's rounded corner information and the first card view, and the first target layer is blurred. Specifically, if the motion blur indicator indicates that the first card needs to be displayed with a motion blur effect, the rounded corners of the first card view are cropped based on the card's rounded corner information, and the cropped first card view is determined as the second card view.

[0015] Thus, if the dynamic blur indicator message indicates that the first card needs to be displayed with a dynamic blur effect, it means that a transparent card view is required, and a dynamic blur effect is also required. Therefore, the rounded corners of the first card view can be directly cropped to obtain a second card view that meets the display requirements of the second application, and the first target layer can be blurred so that a dynamic blur effect can be achieved when it is displayed.

[0016] In the second scenario, if the motion blur indicator indicates that the first card does not need to be displayed with a motion blur effect, a second card view is generated based on the card's rounded corner information, the transparency indicator information, the first card view, and the background view. Specifically, if the motion blur indicator indicates that the first card does not need to be displayed with a motion blur effect, and the transparency indicator indicates that the second card view needs to be transparent, then the rounded corners of the first card view are cropped according to the card's rounded corner information to obtain the second card view. If the transparency indicator indicates that the second card view does not need to be transparent, then the background view is merged with the first card view, and the rounded corners of the merged first card view are cropped according to the card's rounded corner information to obtain the second card view.

[0017] Thus, if the second application requests a transparent second card view, it means that the second host application needs to customize the background color. Therefore, a custom background layer is set on the parent view so that after the second card view is rendered to the first target layer and the placeholders are removed, the second application can display the first card, and the first card has the background effect customized by the second application.

[0018] As an example of this application, the card setting parameters also include card size information. In this case, the specific implementation of the electronic device obtaining a first card view and a background view of the first card from the first application in response to an order generated by the first application may include: in response to the order being generated, transmitting the card size information to the first application, so that the first application generates the first card view and the background view respectively based on the card size information. That is, when obtaining the first card view and the background view, transmitting the card size information to the first application so that the first application can generate a first card view and a background view that meet the size display requirements of the second host application based on the card size information.

[0019] As an example of this application, when the second application requests to display the first card with a dynamic blur effect, after the electronic device adds the second embedded window with the placeholder to the parent view of the second application, it can also set the second target layer in the second embedded window to transparent. The second target layer is a layer used to embed the first target layer into the second embedded window.

[0020] As mentioned above, the dynamic blur effect refers to the fact that when the first card is displayed on the interface of the second application, the area where the first card is located can blur the interface color of the second application.

[0021] Thus, if the second application requests that the first card be displayed with a motion blur effect, the color of the second target layer is prevented from showing through when the first card is displayed, thus avoiding affecting the display effect of the first card, by setting the second target layer to transparent.

[0022] As an example of this application, when the second application requests a transparent second card view, after the electronic device adds the second embedded window with the placeholder to the parent view of the second application, it can also set a custom background layer of the second application on the parent view.

[0023] Thus, if the second application requests a transparent second card view, it means that the second host application needs to customize the background color. Therefore, a custom background layer is set on the parent view so that after the second card view is rendered to the first target layer and the placeholders are removed, the second application can display the first card, and the first card has the background effect customized by the second application.

[0024] In a second aspect, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method of displaying a card as described in the first aspect above.

[0025] Thirdly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the display card method described in the first aspect.

[0026] Fourthly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to execute the display card method described in the first aspect.

[0027] The technical effects achieved by the second, third, and fourth aspects mentioned above are similar to those achieved by the corresponding technical means in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0028] Figure 1 This is a schematic diagram illustrating an application scenario according to an exemplary embodiment;

[0029] Figure 2 This is a schematic diagram illustrating an application scenario according to another exemplary embodiment;

[0030] Figure 3 This is a schematic diagram illustrating an application scenario according to another exemplary embodiment;

[0031] Figure 4 This is a schematic diagram illustrating an application scenario according to another exemplary embodiment;

[0032] Figure 5 This is a schematic diagram illustrating an application scenario according to another exemplary embodiment;

[0033] Figure 6 This is a schematic diagram of the framework of a software system for an electronic device according to an exemplary embodiment;

[0034] Figure 7 This is a schematic diagram of the framework of a software system for an electronic device according to another exemplary embodiment;

[0035] Figure 8 This is a flowchart illustrating a method for displaying a card according to an exemplary embodiment;

[0036] Figure 9 This is a flowchart illustrating a method for displaying a card according to another exemplary embodiment;

[0037] Figure 10 This is a schematic diagram illustrating the display effect of a layer according to an exemplary embodiment;

[0038] Figure 11 This is a schematic diagram illustrating the preloaded display effect of a card according to an exemplary embodiment;

[0039] Figure 12 This is a flowchart illustrating a method for displaying a card according to another exemplary embodiment;

[0040] Figure 13 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0042] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document 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, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0043] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0044] To more intuitively display notifications from a specific application (hereinafter referred to as the primary application) to users, electronic devices can use cards (or widgets, micro-devices, components, etc.) to display these notifications. The primary application is the application within the electronic device that needs to publish the notification information. It can be a built-in application or a third-party application. For example, a primary application might be a travel application or a delivery application. A travel application provides services such as hailing a ride, booking tickets, and travel reminders; examples include ride-hailing apps and map applications. A delivery application provides services such as delivering packages and meals; examples include food delivery apps and courier apps.

[0045] In some embodiments, when an electronic device displays notification information of a first application in the form of a card, it can create and display the card according to predefined native card elements. These native card elements are typically predefined UI elements based on Android's native card framework (i.e., AppWidget). That is, when the electronic device displays a card corresponding to the first application, the card can only include native card elements and cannot support custom card elements of the first application. For example, taking the notification information as order-related information from a ride-hailing application, when the electronic device displays the card corresponding to the ride-hailing application, the ride-hailing application running on the electronic device creates the corresponding card according to native card elements and serializes the card according to preset rules to obtain the card data for the ride-hailing application's card. The ride-hailing application can send this card data to the host application of the electronic device. Then, the host application creates and displays the card corresponding to the ride-hailing application based on the card data, where the card only includes native card elements supported by Android's native card framework. Additionally, the ride-hailing application can call predefined functions, such as the `set text` function and the `settranslation` function. Correspondingly, the host application can also call predefined functions, such as the `settext` function and the `settranslation` function. Specifically, the electronic device can pre-establish a correspondence between the `settext` functions that the ride-hailing application can call and those that the host application can call, as well as a pre-established correspondence between the `settranslation` functions that the ride-hailing application can call and those that the host application can call. In this way, the ride-hailing application can call its own `settext` function to update the text elements in the card. When the ride-hailing application calls its own `settext` function to update the text elements in the card, based on the pre-established correspondence, the corresponding `settext` function that the host application can call can first determine. Therefore, the host application can call its corresponding `settext` function to update the text elements in the card.

[0046] Of course, ride-hailing apps can also call their own `settranslation` function to update the card's display position. When a ride-hailing app calls its `settranslation` function to update the card's display position, based on a pre-established correspondence, the host application's corresponding callable `settranslation` function can be determined first. Therefore, the host application can call its corresponding `settranslation` function to update the card's display position.

[0047] However, Android's native card framework supports a limited number of native card elements, such as only text and image elements. Therefore, when an electronic device creates a card corresponding to the first application based on the native card elements, it creates cards with different text and image elements according to the notification information of the first application, and then displays the notification information of the first application to the user through the text and image elements displayed on the cards. However, electronic devices cannot create cards with custom card elements based on the notification information of the first application; that is, the first application cannot create different cards as needed. The cards displayed in this way have a relatively simple style and are difficult to effectively and intuitively display the information of the first application to the user.

[0048] Furthermore, when an electronic device displays notification information from a first application in the form of a card, the card can be displayed through at least one host application within the electronic device, wherein the host application is the application used to display the card. By way of example and not limitation, the host application can be, but is not limited to, the electronic device's desktop, negative one screen, notification center, banner notification, always-on display, or lock screen.

[0049] Different host applications typically display cards with different effects. In some embodiments, special effects such as card blurring are often not achievable, or require the first application to adapt to specific scenarios like card blurring. Therefore, this application provides a method for displaying cards that allows the host application to display cards with custom blurring effects without requiring separate adaptation from the first application. Furthermore, this method supports the first application in creating and displaying card views that include custom card elements, enabling a more effective and intuitive presentation of notification information from the first application to the user.

[0050] In one example, display effects include custom rounded corners, motion blur, static blur, and custom backgrounds. The following section uses a mobile phone as the electronic device and a ride-hailing application as the primary application to introduce several display effects for cards in exemplary application scenarios.

[0051] In an exemplary application scenario, when a user needs to hail a ride, they can use a ride-hailing app on their phone to place an order. Once an order is placed (e.g., a driver accepts the order), the phone can display the corresponding card for the ride-hailing app in multiple host applications (such as the home screen, notification center, and lock screen).

[0052] In one example, when the phone is displaying its home screen, the user can see the following on the phone's home screen: Figure 1 The card 111 shown can be displayed at the top of the phone's home screen 110. Card 111 may include a ride-hailing application icon 112, text "License plate number XXX, arrives in approximately 2 minutes" 113, and text "Mr. Zhang, white" 114. Card 111 may also include a call control 115, which can be used to contact the driver. The display height of card 111 is h1, the display width is d1, the corner radius is c1, and card 111 has a dynamic blur effect when displayed. Figure 1 (Not shown in the image), meaning that the user can see the background color of the phone's desktop from the area where card 111 is located, but the background color of the desktop that can be seen is not completely clear.

[0053] In one example, see Figure 2 In Figure (a), after the card 111 is displayed on the desktop 110 of the electronic device, when the mobile phone receives a pull-down operation from the user in the top status bar of the display, in response to the pull-down operation, as shown in Figure (a), the mobile phone responds to the pull-down operation as follows: Figure 2 As shown in Figure (b), the phone displays Notification Center 120, and within Notification Center 120, card 121 is displayed. Combined with... Figure 2 As shown in Figure (b), card 121 may include a ride-hailing app icon 122, text "License plate number XXX, approximately 2 minutes arrival" 123, and text "Mr. Zhang, white" 124. (and) Figure 1Compared to card 111, card 121 may also include a progress bar 125. The progress bar 125 can more intuitively indicate the processing progress of a ride-hailing order to the user. Card 121 has a display height of h2, a display width of d2, and a corner radius of c2. Card 121 has a static blur effect. For example, the display height h2 of card 121 is less than the display height h1 of card 111, the display width d2 of card 121 can be equal to the display width d1 of card 111, and the corner radius c2 of card 121 can be less than the corner radius c1 of card 111. It can be seen that the display size of the card displayed in the notification center is smaller than the display size of the card displayed on the desktop. This reduces the space occupied by the card corresponding to the ride-hailing order, allowing the phone to display more cards corresponding to other notification information. Therefore, users can view more notification cards without having to scroll through them, improving human-computer interaction efficiency.

[0054] See another example. Figure 3 In Figure (a), after the electronic device displays card 111 on desktop 110, it enters a locked screen state when it receives a user's lock screen operation (such as pressing the lock screen button). While in the locked screen state, in response to the user's touch operation on the electronic device's display screen, such as... Figure 3 As shown in Figure (b), the electronic device displays a lock screen interface 130, which contains a display card 131. Combined with... Figure 3 As shown in Figure (b), card 131 may include a ride-hailing app icon 132, text "License plate number XXX, approximately 2 minutes arrival" 133, and text "Mr. Zhang, white" 134. (and) Figure 1 Compared to card 111, card 131 may also include a progress bar 135. The progress bar 135 can more intuitively indicate the processing progress of a ride-hailing order to the user. The display height of card 131 is h3, the display width of card 131 is d3, and the corner radius of card 131 is c3. For example, the display height h3 of card 131 is less than the display height h2 of card 111, the display width d3 of card 131 is less than the display width d1 of card 111, and the corner radius c3 of card 131 is less than the corner radius c1 of card 111. Furthermore, card 131 is located at the bottom of the lock screen interface 130, while card 111 is located at the top of the desktop 110; that is, the display positions of card 131 and card 111 are different.

[0055] See another example. Figure 4 In Figure (a), after the electronic device's desktop 110 displays card 111, when the electronic device receives a user's screen-off operation (such as pressing the lock screen button), as shown in Figure (a), Figure 4As shown in Figure (b), the electronic device displays an always-on display (AOD) interface 140, and displays a card 141 on the AOD interface 140. Card 141 is a card capsule. Upon receiving a user's touch operation (such as a swipe) on card 141 (i.e., the card capsule), the electronic device opens the ride-hailing application. Due to the limited space of the electronic device's AOD interface, the display height h4 of card 141 is less than the display height h1 of card 111, the display width d4 of card 141 is less than the display width d1 of card 111, and the corner radius c4 of card 141 is greater than the corner radius c1 of card 111. In this way, when switching to AOD, the space occupied by the card corresponding to the ride-hailing order can be minimized, avoiding the card not being fully displayed. In addition, combined with Figure 4 As shown in Figure (b), since the display size of card 141 (i.e. card capsule) is small, card 141 can include some information related to the ride-hailing order (such as the ride-hailing application icon 142 and the text "license plate number XXX" 143). In this way, users can obtain some information about the ride-hailing application without opening the application, making it more convenient to use.

[0056] In another example, when an electronic device displays a card at a designated location on a desktop, the background color can be customized, such as a black or white background. The designated location can be set according to actual needs, such as an area with a camera, and the card's size and corner rounding can also be set as needed. For an example, please refer to [link to example]. Figure 5 , Figure 5 This is an example illustrating a setting with a black background (…). Figure 5 This is a schematic diagram illustrating the display effect of a card (represented in grayscale).

[0057] As can be seen from the above examples, the card display method provided in this application displays cards through the host application of an electronic device in different ways, resulting in different display effects. Furthermore, the content information carried by the card can be selectively set according to the content to be displayed by different host applications and the user's usage habits, thereby achieving the purpose of notifying the user, improving human-computer interaction efficiency, and ultimately enhancing the user experience.

[0058] It should be noted that the above application scenarios are merely illustrative. In another example, this card display method can also be applied to other card display scenarios, such as displaying cards corresponding to food delivery applications or displaying cards for instant messaging applications (such as WeChat). TMThe corresponding cards, etc. Furthermore, it can also be applied to scenarios such as custom rounded corners, static blur, dynamic blur, and custom backgrounds when displaying a purely embedded view (non-card scenario, such as Gaode embedded map), but this application embodiment does not limit this.

[0059] It should also be noted that the above description uses a mobile phone as an example. In another example, the electronic device can also be an action camera (GoPro), a digital camera, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an in-vehicle device, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), etc. This application embodiment does not limit the scope of the application.

[0060] The implementation of electronic device functions typically requires the cooperation of a software system. The following section describes the software system of electronic devices. The software system of electronic devices can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application uses the layered architecture Android system as an example to illustrate the software structure of an electronic device.

[0061] Figure 6 This is a software structure block diagram of the electronic device provided in the embodiments of this application. The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer (framework, FWK), the Android runtime and system libraries (also known as the Native layer), and the kernel layer.

[0062] The application layer can include camera, gallery, calendar, calls, maps, navigation, WLAN (wireless LAN), Bluetooth, music, video, SMS, etc.

[0063] 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. For example... Figure 6 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0064] The Android runtime is responsible for scheduling and managing the Android system. System libraries can include multiple functional modules, such as the surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), and 2D graphics engines (e.g., SGL).

[0065] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0066] As an example of this application, please see Figure 7 The application layer may also include a first application, a host application, a management plugin corresponding to the first application, and a management plugin corresponding to the host application.

[0067] The first application can provide a card view for the cards to be displayed. A card view is a laid-out view that includes the content of the cards to be displayed. In one example, the first application can integrate a card provider, such as TaxiProvider in a ride-hailing application. The card provider is used to provide the card view of the first application. The first application can include one or more card providers. As an example and not a limitation, different card views of the same first application can be provided by different card providers. For example, the cards corresponding to two ride-hailing orders in a ride-hailing application can be provided by TaxiProvider1 and TaxiProvider2 respectively.

[0068] A host application serves as the display medium for a card view, primarily responsible for displaying the card view within its designated area. By way of example, and not limitation, a host application in an electronic device includes at least one of the following: the desktop, the negative one screen, the notification center, banner notifications, the always-on display, and the lock screen.

[0069] The management plugin corresponding to the application (i.e., the first application or the host application) can be either AAR (Android Archive) or JAR (Java Archive). This application embodiment uses AAR as an example for illustration.

[0070] An AAR can include the AAR corresponding to the first application and the AAR corresponding to the host application. The AAR corresponding to the first application can also be called a card kit; please refer to [link / reference]. Figure 7The card kit acts as a bridge between the primary application and the card management service (LiveClipManagerService). Specifically, the card kit integrates card display interfaces, allowing the primary application to establish a communication connection with the card management service through these integrated interfaces, and then interact with the card management service via the card kit. In other words, the primary application does not need to understand the card management service; it can achieve functions such as card access, timed refresh, card caching, card retrieval, and card destruction simply by calling the relevant interfaces provided by the card kit.

[0071] It should be noted that the card kit can be integrated into any application that provides cards in an electronic device. If there are multiple applications, each application can integrate its own corresponding card kit, meaning each application corresponds to one card kit. For example, ride-hailing applications and food delivery applications can both integrate card kits.

[0072] The Host Application's Application Name Archive (AAR) serves as a bridge between the host application and the card management service. Specifically, the Host AAR integrates card display interfaces, allowing the host application to establish a communication connection with the card management service through these integrated interfaces. This enables the host application to quickly access the card management service via the Host AAR, facilitating functions such as host access, requesting to show / hide, obtaining the HostView, resizing, and changing configuration settings.

[0073] It's important to note that Host AARs can be integrated into host applications; that is, each host application on a digital device can integrate a Host AAR. As an example, and not a limitation, different host applications can each integrate their own Host AAR, meaning each host application corresponds to one Host AAR. For instance, a host AAR can be integrated into the desktop of a digital device, the notification center of a digital device, and the negative one screen of a digital device.

[0074] Please continue reading Figure 7 The application framework layer can also include service frameworks such as display service, card management service, and system service.

[0075] The card display service can act as the initiator of card display-related instructions. It receives card display notifications from the first application and then instructs the host application to display, hide, or destroy the card.

[0076] The card management service acts as a bridge between the primary application and the host application. It enables functions such as card lifecycle management, power consumption control, data caching, and exception recovery. The card management service can obtain card display-related instructions from the host application and use system services to send these instructions to the card kit, instructing the kit to retrieve card views from the primary application. Furthermore, the card management service can establish a communication connection with HostAAR using system services and send the retrieved card views to the host application via HostAAR for the host application to display the cards.

[0077] System services have the basic capabilities of native Android services, meaning that system services can provide cross-process data transmission channels, thus enabling cross-process interaction between the first application and the host application.

[0078] In the above Figure 7 Based on the illustrated embodiment, the following will combine Figure 8 Taking a ride-hailing application as an example, the method for displaying cards provided in this application embodiment will be described in detail. This description uses the interaction of multiple modules of an electronic device as an example, and mainly includes some or all of the following:

[0079] S801, In response to a ride-hailing operation, the ride-hailing application generates a ride-hailing order.

[0080] In one example, the ride-hailing action is triggered by a user's need to hail a ride, and the ride-hailing action can include at least one operation. When the user triggers the ride-hailing action, such as when the user submits a ride request, or when a driver accepts the order after the user submits a ride request, the ride-hailing application generates a ride order.

[0081] S802. After a ride-hailing order is generated, the ride-hailing application sends a card display notification to the card display service.

[0082] The card display notification is used to notify the card display service that a card display is required.

[0083] In other words, after a ride-hailing order is generated, the ride-hailing app can notify the card display service to display the card.

[0084] It should be noted that when a ride-hailing application sends a card display notification to a card display service, it may do so through one or more modules. This application embodiment does not limit this.

[0085] S803. Upon receiving a card display notification, the card display service assigns card instance information (cardInstanceId) to the card requested for display by the ride-hailing application. The cardInstanceId is used to uniquely identify a ride-hailing order of the ride-hailing application.

[0086] Each ride-hailing order corresponds to a unique card instance (i.e., cardInstanceId). Since each ride-hailing order corresponds to one card, it can be understood that each card corresponds to a unique card instance.

[0087] Since there may be multiple ride orders in a ride-hailing application, and each ride order needs a corresponding card, in order to facilitate the distinction of which card belongs to which ride order, the card display service assigns card instance information to the card requested by the ride-hailing application when it receives a card display notification from the ride-hailing application.

[0088] S804, The card display service sends the assigned cardInstanceId to the ride-hailing application.

[0089] For example, when a user places two ride-hailing orders (such as order A and order B) using a ride-hailing application, the card display service assigns card instance information 1 to order A and card instance information 2 to order B. The card display service can then send card instance information 1 and card instance information 2 to the ride-hailing application.

[0090] As an example of this application, after receiving the cardInstanceId, the ride-hailing application can associate the cardInstanceId, the ride-hailing application's card provider (i.e., TaxiProvider), and the ride-hailing order. For instance, when the ride-hailing application receives card instance information 1 corresponding to order A, it can associate card instance information 1, TaxiProvider1 corresponding to order A, and order A. Similarly, when the ride-hailing application receives card instance information 2 corresponding to order B, it can associate card instance information 2, TaxiProvider2 corresponding to order B, and order B. This allows the corresponding ride-hailing order or TaxiProvider to be retrieved subsequently based on the cardInstanceId.

[0091] S805, the card display service sends a binding instruction to the card management service, which carries card provider information (AppClipInfo) and cardInstanceId.

[0092] The binding instruction is used to instruct the user to bind to a ride-hailing application. Specifically, it instructs the user to bind to a card provider (i.e., TaxiProvider) within the ride-hailing application, enabling the card management service to subsequently make cross-process calls with the ride-hailing application. This card provider can provide a card view of the cards requested by the ride-hailing application.

[0093] In one example, card provider information may include the package name of the ride-hailing application and the name of the card provider. This card provider information can be obtained from the ride-hailing application. As an example, and not a limitation, the card display service may obtain card provider information from a specified Extensible Markup Language (XML) file via a package manager service (PMS), where the XML file is the file used to store the card provider information.

[0094] In one example, the card display service can send a binding instruction to the card management service by calling the create(AppClipInfo, cardInstanceId) function, instructing the card management service to perform service binding.

[0095] S806. In response to the binding instruction, the card management service sends the binding instruction to the card kit and caches the mapping relationship between AppClipInfo and cardInstanceId.

[0096] In one example, the card management service can send a binding instruction to the card kit by calling the create(AppClipInfo, cardInstanceId) function to bind a card provider in the ride-hailing application.

[0097] S807 and the card kit bind the card provider of the ride-hailing application according to the binding instructions.

[0098] The card kit determines the ride-hailing application's card provider (TaxiProvider) based on the card provider information (AppClipInfo) and initializes the ride-hailing application's card provider (TaxiProvider). After initialization, the card kit can bind its services to the ride-hailing application's card provider (TaxiProvider) so that it can call the ride-hailing application's card provider (TaxiProvider) across processes during subsequent card display.

[0099] In one example, the card kit can bind a card provider in a ride-hailing application via a callback function onCreate(cardInstanceId) based on the binding instruction.

[0100] S808, the mapping relationship between AppClipInfo and cardInstanceId cached by the card provider.

[0101] After the binding is complete, the TaxiProvider stores the AppClipInfo and cardInstanceId corresponding to each other.

[0102] S809. The card provider sends a successful binding notification to the card kit.

[0103] In one example, TaxiProvider can send a successful binding notification to the card kit via a callback, so that the card display service can be notified that the binding service has been completed.

[0104] S810 and CardKit send a successful binding notification to the Card Management Service.

[0105] In one example, the card kit sends a successful binding notification to the card management service via a callback, so that the card management service can then send the successful binding notification back to the card display service.

[0106] S811, The card management service sends a binding success notification to the card display service.

[0107] In this way, the card display service can know that the service binding has been completed.

[0108] Then, the card display service can issue card display instructions to display the cards requested by the ride-hailing application through the host application. Next, combined with... Figure 9 The card display process can be described in detail, and mainly includes the following steps:

[0109] S812, The card display service sends card display instruction 1 to the host application, and card display instruction 1 carries cardInstanceId.

[0110] Card display instruction 1 is used to instruct the host application to display the card requested by the ride-hailing application.

[0111] A host application is a registered application on an electronic device that can display cards. There may be one or more host applications. As mentioned above, a host application may include at least one of the following: desktop, negative one screen, notification center, banner notification, always-on display, and lock screen. A host application can always be active on an electronic device.

[0112] In one example, after the electronic device is powered on, each host application can register for the ride-hailing application's order business. Then, when a ride-hailing order is generated in the ride-hailing application, the card display service sends Card Display Instruction 1 to these host applications. That is, if multiple host applications are registered, the card display service sends Card Display Instruction 1 to each of them.

[0113] For example, taking multiple host applications, including the desktop and notification center, as an example, after receiving a card display notification from a ride-hailing application, the card display service, during the card display process, through... Figure 7 In path L1, send card display command 1 to the desktop and send card display command 1 to the notification center.

[0114] It should be noted that the above registration process can also be carried out at other times, such as when the ride-hailing application is installed on the electronic device, or when the ride-hailing application is updated. This application embodiment does not limit this.

[0115] The following section uses any host application as an example to explain the processing flow after the host application receives the card display instruction 1 sent by the card display service. The processing flow for other host applications is similar.

[0116] S813, The host application sends Card Display Instruction 2 to the Host AAR. Card Display Instruction 2 carries hostInfo, size, cornerRadius, istransparent, isliveBlur and cardInstanceId.

[0117] Host information (i.e., hostInfo) is used to uniquely identify a host application. Host information can be pre-generated by the host application. For example, the host application generates host information when it registers.

[0118] Card size information (i.e., size) is used to indicate the size of the card displayed by the host application. Card size information includes card width and card height, and the unit is PX, which is pixels.

[0119] The corner radius information (cornerRadius) indicates the size of the corner radius of the card displayed by the host application. The unit of the corner radius information is PX, which is pixels.

[0120] The transparency indicator (i.e., istransparent) can be used to indicate whether the card view obtained from the ride-hailing application needs to be set to transparent. For example, when istransparent is true, it indicates that the card view needs to be set to transparent, and when istransparent is false, it indicates that the card view does not need to be set to transparent, or that a card view with a background is needed.

[0121] The dynamic blur indicator (isliveBlur) indicates whether the card should be displayed with a dynamic blur effect. For example, isliveBlur set to true indicates that dynamic blur is needed, while isliveBlur set to false indicates that dynamic blur is not needed. The dynamic blur effect means that when the card is displayed on the interface of the host application (such as the desktop), the user can vaguely see the colors of the host application's interface from the area where the card is located; that is, the colors of the host application's interface can be vaguely seen through the area where the card is located. For example, the WeChat notification card displayed on the desktop is a real-time card, which has a dynamic blur effect.

[0122] In this embodiment, different host applications display different card content and display effects when displaying cards. For example, for a ride-hailing order A in a ride-hailing application, such as... Figure 1 As shown, the desktop 110 of the electronic device can display a card 111 corresponding to the ride-hailing order A. Card 111 includes a ride-hailing application icon 112, text "License plate number XXX, arrival in approximately 2 minutes" 113, text "Mr. Zhang, white" 114, and a call control 115. The size and corner rounding of card 111 are as follows... Figure 1 As shown, card 111 has a dynamic blur effect.

[0123] For example, regarding the same ride-hailing order A, such as Figure 2As shown in Figure (b), the notification center 120 of the electronic device can display a card 121 corresponding to the ride-hailing order A. Card 121 may include a ride-hailing application icon 122, text "License plate number XXX, arriving in approximately 2 minutes" 123, text "Mr. Zhang, white" 124, and a progress bar 125. The size and corner rounding of card 121 are as follows... Figure 2 As shown in Figure (b), the size of card 121 is different from that of card 111, the rounded corners of card 121 are also different from those of card 111, and card 121 has a static blur effect instead of a dynamic blur effect.

[0124] For example, regarding the same ride-hailing order A, such as Figure 3 As shown in Figure (b), the lock screen 130 of the electronic device can display a card 131 corresponding to the ride-hailing order A. 131 may include a ride-hailing application icon 132, text "License plate number XXX, arriving in approximately 2 minutes" 133, and text "Mr. Zhang, white" 134. Card 131 may also include a progress bar 135. The size and corner radius of card 131 are as follows... Figure 3 As shown in Figure (b), the size of card 131 is different from that of card 111, the rounded corners of card 131 are also different from those of card 111, and card 131 may have a background (such as white).

[0125] For example, regarding the same ride-hailing order A, such as Figure 4 As shown in Figure (b), the always-on display 140 of the electronic device can display the card 141 corresponding to the ride-hailing order A. Figure 1 Compared to card 111, card 141 is a card capsule. Card 141 (i.e., the card capsule) may include some information related to the ride-hailing order (such as the ride-hailing app icon 142, the text "license plate number XXX" 143). The size and corner rounding of card 141 are as follows... Figure 4 As shown in Figure (b), the size of card 141 is different from that of card 111, the rounded corners of card 141 are also different from those of card 111, and card 141 may also have a background (such as white).

[0126] This demonstrates that for the same ride-hailing order, different host applications require different specifications and styles for the card view, such as varying requirements for card size, corner radius, transparency, and motion blur. Therefore, after receiving card display instruction 1, the host application can add card setting parameters related to the card view to card display instruction 2 according to its own needs, and then issue card display instruction 2, for example, through... Figure 7Path L2 sends card display instructions 2 to the Host AAR, so that the card kit can subsequently configure the card view required by the host application based on these card setting parameters. These card setting parameters can be pre-generated by the host application, for example, they can be generated as needed during the host application registration.

[0127] In one example, the host application can send a card display command to the Host AAR by calling the showCard function in the Host AAR. For example, the host application can call the showCard(hostInfo, cardInstanceId, size, istransparent, isliveBlur, cornerRadius) function.

[0128] S814, Host AAR sends card display instruction 2 to the card management service.

[0129] Please see Figure 7 The Host AAR forwards the card display instruction 2 to the card management service via path L3. In one example, the Host AAR can communicate across processes with the card management service through a system service; that is, the Host AAR can send the card display instruction 2 to the card management service through the system service to request the card to be displayed.

[0130] In one example, the Host AAR can send a card display command to the card management service by calling the showCard function. For instance, the Host AAR calls the showCard(hostInfo, cardInstanceId, size, istransparent, isliveBlur, cornerRadius) function.

[0131] S815, The card management service determines AppClipInfo based on cardInstanceId.

[0132] according to Figure 8 As described in the illustrated embodiment, the card management service caches the mapping relationship between card instance information (cardInstanceId) and card provider information (AppClipInfo) locally. Therefore, the card management service can determine the card provider information (AppClipInfo) based on the card instance information (cardInstanceId) in order to determine which application needs to display the card, or in other words, which card provider's card in which application needs to be displayed.

[0133] S816, The card management service sends a card display instruction 2 to the card kit corresponding to the ride-hailing application based on AppClipInfo.

[0134] In other words, the card management service determines the corresponding ride-hailing application based on the card provider information (AppClipInfo). Then, see... Figure 7 The card management service uses path L4 to send card display instructions 2 to the card kit corresponding to the ride-hailing application through the system service. The instructions send the host information (hostinfo), card size information (size), card corner radius information (cornerRadius), transparency indicator information (isTransparent), dynamic blur indicator information (isLiveBlur), and card instance information (cardinstanceId) to the card kit so that the card kit can obtain the card view of the corresponding specifications according to these card setting parameters.

[0135] In one example, the card management service can send a card display instruction 2 to the card kit by calling the showCard function. For example, in implementation, the showCard(hostinfo, size, cornerRadius, isTransparent, isLiveBlur, cardinstanceId) function can be called.

[0136] It should be noted that since each Host AAR corresponding to a host application sends card display instructions to the card management service, after the card management service receives the card display instructions sent by each Host AAR corresponding to a host application, the card management service can send card display instructions to the card kit corresponding to the ride-hailing application according to the card provider information carried in each card display instruction. Different card display instructions carry card setting parameters indicated by different host applications. That is, the card management service sends the host information (hostinfo), card size (size), card corner radius information (cornerRadius), transparency indicator information (isTransparent), dynamic blur indicator information (isLiveBlur), and card instance information (cardinstanceId) from each host application to the card kit, so that the card kit can obtain the card view of the corresponding specification according to the card setting parameters indicated by each host application.

[0137] S817, the card kit determines the first embedded window based on the hostinfo. The first embedded window is used by the card kit to embed the card view of the ride-hailing application.

[0138] The first embedded window, SurfaceControlViewHost, is created by the card kit and can be understood as a window belonging to the ride-hailing application. SurfaceControlViewHost includes a SurfaceControl layer, which is the actual layer used to render the card view. Therefore, it's easy to understand that this SurfaceControlViewHost is the window used by the card kit to embed the card view of the ride-hailing application. For different host applications, the card kit can create a corresponding first embedded window.

[0139] As an example of this application, the card kit's determination of the specific implementation of the first embedded window based on hostinfo may include: querying the electronic device's cache to see if a valid layer data package (i.e., SurfacePackage) exists, where the layer data package includes the SurfaceControl layer in SurfaceControlViewHost, meaning the layer data package exists in SurfaceControlViewHost. If a valid layer data package exists, the first embedded window corresponding to that valid layer data package is obtained. If a valid layer data package does not exist, the first embedded window is created.

[0140] In one embodiment, the host application of the electronic device had previously displayed the card corresponding to the ride-hailing order before this request to display it. However, due to a crash or other issue in the host application, the card disappeared, causing the electronic device to trigger this current request to display the card corresponding to the order. In this case, the electronic device's cache contains the layer data packet of the previously created first embedded window, and there is a mapping relationship between it and the hostinfo. Therefore, when the card kit determines the first embedded window, it can query the hostinfo to see if a valid layer data packet exists, in order to determine whether the SurfaceControlViewHost corresponding to the hostinfo needs to be recreated.

[0141] In one possible scenario, if the layer data packet for the first embedded window corresponding to hostinfo exists in the electronic device's cache, the card kit can query the status information of that layer data packet. If the status information indicates that the cached layer data packet for the first embedded window is valid, for example, if the status information is a first value (true), the card kit can directly use that first embedded window for card view embedding. If the status information indicates that the cached layer data packet for the first embedded window is invalid (e.g., an exception occurs), for example, if the status information is a second value (false), the card kit can create the first embedded window corresponding to hostinfo. Afterward, the card kit can save the mapping relationship between hostinfo and the created first embedded window.

[0142] In another possible scenario, the layer data packet for the first embedded window corresponding to hostinfo may not exist in the electronic device's cache. In this case, the card kit can recreate the first embedded window. The card kit can then save the mapping between hostinfo and the created first embedded window so that if the host application crashes while displaying the card, the card kit can use this mapping to find the first embedded window corresponding to hostinfo the next time, avoiding the need to recreate the first embedded window for hostinfo.

[0143] It should be noted that the above implementation of determining the first embedded window based on hostinfo is only exemplary. In another example, after receiving card display instruction 2, the card kit may not query whether there is a valid layer data packet, but directly create a first embedded window. Furthermore, the card kit can cache the mapping relationship between hostinfo and the created first embedded window.

[0144] S818, the card kit sends a layer data packet to the card management service, the layer data packet including the SurfaceControl layer of the first embedded window.

[0145] The SurfaceControl layer is currently empty because the card view requested by the ride-hailing application has not yet been rendered.

[0146] In some examples, to prevent the host application from displaying cards from other applications while the card kit is retrieving the card view from the ride-hailing application's TaxiProvider, the card kit can send a layer data packet containing the SurfaceControl layer in a first embedded window to the card management service before retrieving the card view. This data packet is then sent to the Host AAR via the card management service. The Host AAR then mounts (or embeds) the SurfaceControl layer into a second embedded window of the host application, using this SurfaceControl layer as a placeholder. This second embedded window is created by the Host AAR and can be understood as a window belonging to the host application. The second embedded window is used by the Host AAR to mount the SurfaceControl layer from the SurfaceControlViewHost. In one example, the second embedded window is DynamicCardHostView.

[0147] In one possible scenario, if a valid layer data package exists in the electronic device's cache, the card kit can send the cached layer data package of the first embedded window to the card management service via a callback to the OnSurfacePackageCreated function. For example, the card kit calls back the OnSurfacePackageCreated(cardinstanceId, SurfacePackage) function, where passing cardinstanceId during the OnSurfacePackageCreated callback is to help the host application determine which ride-hailing order's card is being displayed.

[0148] In another possible scenario, if a valid layer data packet is not present in the electronic device's cache, the card kit can create a listener event during the creation of the first embedded window. This listener event is used to monitor whether the creation of the first embedded window has been completed. If the first embedded window has been detected as created, the card kit can send the SurfaceControl layer from the created first embedded window to the card management service via a layer data packet by calling back the OnSurfacePackageCreated function.

[0149] In one example, if the SurfaceControl layer in the first embedded window changes subsequently, the card kit can notify the card management service by calling the OnSurfacePackageChanged function. The card management service can then notify the Host AAR to replace the mounted SurfaceControl layer with the changed SurfaceControl layer.

[0150] S819, Card Management Service sends layer data packets to Host AAR.

[0151] In other words, after receiving the layer data packet, the card management service forwards the layer data packet to the Host AAR corresponding to the host application. As an example of this application, the card management service sends the layer data packet of the first embedded window to the Host AAR corresponding to the host application by calling the OnSurfacePackageCreated function. For example, the card management service calls the OnSurfacePackageCreated(cardinstanceId, SurfacePackage) function.

[0152] S820, Host AAR creates a second embedded window and attaches the SurfaceControl layer from the layer data package to the second embedded window.

[0153] After receiving the layer data packet from the first embedded window, the Host AAR creates a second embedded window (i.e., DynamicCardHostView) to embed the SurfaceControl layer of the first embedded window. Then, the Host AAR retrieves the SurfaceControl layer of the first embedded window from the layer data packet and mounts it onto the second embedded window. This means the SurfaceControl layer mounted in the second embedded window is the same layer as the SurfaceControl layer in the SurfaceControlViewHost of the ride-hailing application. When the card view is rendered on the SurfaceControl layer of the first embedded window, the SurfaceControl layer of the second embedded window is rendered synchronously. The Host AAR can also add placeholders to the first embedded window, such as "Loading".

[0154] In one example, the second embedded window includes a SurfaceView, and the Host AAR uses the SurfaceView to mount the SurfaceControl layer of the first embedded window onto the second embedded window.

[0155] S821, Host AAR sends a second embedded window with a SurfaceControl layer added to the host application.

[0156] In one example, the Host AAR can send a second embedded window with a SurfaceControl layer to the host application by calling the onCardViewCreated function. For example, the Host AAR calls the onCardViewCreated(cardInstanceId, DynamicCardHostView) function.

[0157] S822, The host application adds a second embedded window with a SurfaceControl layer to the location where it needs to be displayed.

[0158] In other words, after the host application receives the second embedded window with the SurfaceControl layer, it adds the second embedded window with the SurfaceControl layer to a preset position that it needs to display.

[0159] For example, taking a desktop application as the host application, such as Figure 11 As shown, before the card kit renders the card view to the SurfaceControl layer, a second embedded window 1101 can be displayed on the desktop 1100 of the electronic device, that is, a placeholder 1102 can be displayed on the desktop 1100 of the electronic device, and the placeholder 1102 is "loading".

[0160] In one example, placeholder 1102 may also be invisible to the user, meaning that the user may not see placeholder 1102 from the electronic device during the card display process.

[0161] In one example, the host application can establish a mapping between cardInstanceId and a second embedded window.

[0162] S823. In a dynamic blur scene, Host AAR sets the background layer in the second embedded window to transparent.

[0163] As mentioned earlier, Host AAR mounts the SurfaceControl layer of the first embedded window to the second embedded window via SurfaceView. Since SurfaceView itself has a built-in black background layer, in one possible implementation, if the host application needs to achieve a semi-transparent or motion-blurred effect when displaying cards, embedding the SurfaceControl layer via SurfaceView in Host AAR can easily cause the underlying black background layer to show through when the card view is subsequently rendered onto the SurfaceControl layer. For example... Figure 10 As shown, this causes the four rounded corners of the card to appear black. Therefore, if the host application specifies requirements such as semi-transparency or motion blur in the card settings parameters, Host ARR can indicate that the SurfaceView is currently in a live card scene (i.e., motion blur), for example, by calling the `setlsLiveClip(true)` function. In this way, the SurfaceView can set its own background layer to transparent, for example, by using the `transaction.setAlpha(sf, 0)` function, to prevent the black background layer of the SurfaceView from showing through when the card is displayed later.

[0164] S824. In the case of requesting a transparent card view, the host application sets a custom background for the card view.

[0165] As an example of this application, if the host application requests a transparent card view, the host application typically needs to customize the background of the card view. For example, it might set the background to black, semi-transparent, or statically blurred (like the static blur effect on cards displayed in the notification center, such as WeChat notification cards). Therefore, when the host application requests a transparent card view, after adding a second embedded window with a SurfaceControl layer to the desired display location, the host application can set a custom background view on the card's parent view, such as a black background view. The parent view is the view in the host application used to accommodate the second embedded window with the SurfaceControl layer.

[0166] It should be noted that, in the case where the host application requests a transparent card view, this embodiment of the application illustrates the example of setting a custom background for the host application after adding a second embedded window with a SurfaceControl layer. In another example, the background can also be set at other times, such as when creating the parent view; this embodiment of the application does not limit this to that.

[0167] S825, the card kit sends a card view retrieval request to the card provider of the ride-hailing application, and the card view retrieval request carries the size.

[0168] The Card View Retrieval Request is used to request the card view.

[0169] In one example, see Figure 7 After the card kit determines the card provider based on the card provider information, it can call the getview(size) function through path L5 to send a card view retrieval request to the TaxiProvider of the ride-hailing application, and send the card size information (i.e., size) of the card view requested by the host application to the TaxiProvider, so that the TaxiProvider can provide the card view required by the host application based on the card size information.

[0170] As an example of this application, a TaxiProvider is used to provide a card view corresponding to a ride-hailing order, that is, a TaxiProvider and a ride-hailing order can be in one-to-one correspondence, or in other words, a TaxiProvider and a cardinstanceId are in one-to-one correspondence.

[0171] It should be noted that there is no strict execution order between S825 and S818. In one possible scenario, if a valid layer data packet exists in the electronic device's cache, S825 can execute after the card kit determines the existence of a valid layer data packet. In another possible scenario, if a valid layer data packet does not exist in the electronic device's cache, S825 can execute after the card kit creates the first embedded window.

[0172] S826. The card provider generates the corresponding card view based on the size.

[0173] In one example, TaxiProvider can determine the required card view size, content composition, and layout based on the card size information. This also determines the style of card view needed by the host application requesting the view. Therefore, upon receiving the card size information, TaxiProvider can generate the required card view for the host application. This card view is transparent.

[0174] For example, taking the host application as the desktop, combined with Figure 1 As shown, TaxiProvider can generate the card 111 required for the desktop based on the card size information indicated on the desktop (such as display height h1 and display width d1) and the data corresponding to the ride-hailing order, that is, generate the card view required for the desktop. Card 111 includes the icon 112 of the ride-hailing application, the text "License plate number XXX · Arrive in about 2 minutes" 113, the text "Mr. Zhang · White" 114, and the call control 115.

[0175] For example, taking the host application as the notification center, combined with... Figure 2 As shown in Figure (b), TaxiProvider can generate card 121, i.e., a card view corresponding to the notification center, based on the card size information indicated by the notification center (such as display height h2 and display width d2) and the data corresponding to the ride-hailing order. Card 121 includes the ride-hailing application icon 122, the text "License plate number XXX, approximately 2 minutes arrival" 123, and the text "Mr. Zhang, white" 124. Figure 1 Compared to card 111 shown, card 121 may also include a progress bar 125.

[0176] S827, The card provider sends a card view to the card kit.

[0177] See Figure 7 After TaxiProvider generates the card view required by the host application, it sends the card view to the card kit via path L6.

[0178] S828, the card kit sends a background view retrieval request to the card provider, and the background view retrieval request carries the size.

[0179] The background view retrieval request is used to request the background view of the card view.

[0180] In other words, in this embodiment of the application, the card kit requests the TaxiProvider of the ride-hailing application to provide a card view and a background view, that is, it requests the TaxiProvider to create a card view and a background view of the card view, so that the card view and the background view can be processed separately according to the needs of the host application.

[0181] In one example, the card kit can send a background view retrieval request to the TaxiProvider by calling the getDrawable(size) function, and send the card size information of the card view requested by the host application to the TaxiProvider so that the TaxiProvider can provide a background view of the corresponding size based on the card size information.

[0182] It should be noted that there is no strict execution order between S828 and S825. For example, S828 can be executed in parallel with S825, or S828 can be executed after S825. This application embodiment does not limit this.

[0183] S829. The card provider generates the corresponding background view based on the size.

[0184] The TaxiProvider of the ride-hailing application generates card views of this size. Each card view corresponds to a background view.

[0185] S830, The card provider sends a background view to the card kit.

[0186] After the ride-hailing application generates a background view, it sends that background view to the card kit.

[0187] It's worth mentioning that the card kit obtains the card view and the corresponding background view from the TaxiProvider of the ride-hailing application. In other words, the card view and the background view are separate. This allows the card view and the background view to be processed separately according to the display requirements of the host application, avoiding the need for the ride-hailing application to do the adaptation itself.

[0188] It should be noted that since the card management service can send card display instructions from each host application to the card kit, the card kit can send the card size information indicated by each host application to the TaxiProvider of the ride-hailing application. This allows the TaxiProvider of the ride-hailing application to provide the card view and background view of the style required by each host application based on the card size information indicated by each host application.

[0189] S831. When the dynamic blur indicator message indicates that dynamic blur is required, the card kit blurs the SurfaceControl layer in the first embedded window.

[0190] To enable a dynamic blur effect when the host application displays cards, CardKit blurs the SurfaceControl layer in the first embedded window. In one example, CardKit can use a native Android interface to set the SurfaceControl layer of the first embedded window to blur.

[0191] It should be noted that the above explanation uses the example of a dynamic blur indicator message indicating that dynamic blur is required. In another example, the dynamic blur indicator message may also indicate that dynamic blur is not required. In this case, the following operation S830 is performed.

[0192] S832. When the dynamic blur indicator information indicates that dynamic blur is not required, the card kit generates a view card with or without a background view based on the transparency indicator information.

[0193] As mentioned earlier, the transparency indicator indicates whether the card view needs to be set to transparent. The card kit uses this indicator to determine whether a transparent card view is needed, generating either a card view with a background view or one without. In one possible scenario, the transparency indicator may indicate the need for a transparent card view. In this case, the card kit does not merge the card view and background view. As an example, and not a limitation, the card kit could remove the background view obtained from the ride-hailing application's TaxiProvider, meaning that the background view is not needed. In another possible scenario, the transparency indicator may indicate the need for an opaque card view. In this case, the card kit merges the card view and background view, resulting in a card view with a background view.

[0194] S833, the card kit trims the rounded corners of the generated card view based on the card's rounded corner information.

[0195] For example, assuming the card's rounded corner information is c1, the card kit will crop the four corners of the generated card view to size c1 to obtain the cropped card view.

[0196] It's worth mentioning that, for different host applications, the card kit generates the card view required by each host application based on its display needs, which avoids the need for ride-hailing applications to adapt themselves.

[0197] S834, the card kit adds the cropped card view to the first embedded window.

[0198] The card kit renders the cropped card view onto the SurfaceControl layer of the first embedded window. In one example, after the cropped card view is added to the first embedded window, the first embedded window notifies the card kit that the card view drawing is complete, and then the card kit performs the following operations.

[0199] S835, the card kit sends a rendering completion notification to the card management service.

[0200] In one example, see Figure 7 The card kit can use path L7 to call back the `onSurfaceViewRendered` function to send a rendering completion notification to the card management service. This notifies the host AAR that the card view has been rendered into the SurfaceControl layer of the first embedded window. Furthermore, to help the host AAR know which card view has been rendered, the card kit can also pass the `cardInstanceId` to the card management service during the callback process, for example, by calling the `onSurfaceViewRendered(cardInstanceId)` function.

[0201] S836, the card management service sends a rendering completion notification to the Host AAR.

[0202] In one example, see Figure 7 The card management service can send a rendering completion notification to the Host AAR by calling the onSurfaceViewRendered function via path L8. For example, the card management service calls the onSurfaceViewRendered(cardInstanceId) function.

[0203] S837, Host AAR removes placeholders.

[0204] Since the SurfaceControl layers in the first and second embedded windows are the same layer, if a cropped card view is added to the SurfaceControl layer of the first embedded window, the same cropped card view will also be added to the SurfaceControl layer of the second embedded window. Therefore, after receiving the rendering completion notification, the Host AAR will delete the placeholder, for example, by determining the corresponding second embedded window based on cardInstanceId, and then deleting the placeholder in the second embedded window. In this way, the host application can successfully display the card view, thus completing the display of the ride-hailing application's card.

[0205] Following the above implementation method, the card can be successfully displayed in each host application. Thus, when the host application is running in the foreground, the user can see the displayed card on the host application.

[0206] It should be noted that since both the first embedded window of the ride-hailing application and the second embedded window of the host application embed SurfaceControl layers, and the card view of the ride-hailing application is rendered on the SurfaceControl layer, after the card view of the ride-hailing application is displayed in the host application, when the ride-hailing order changes, such as a change in the ride-hailing progress, the ride-hailing application can directly modify the card content of the card view rendered on the SurfaceControl layer in the first embedded window according to the changed ride-hailing order. In this case, the card view rendered on the SurfaceControl layer in the second embedded window is updated synchronously, thereby realizing the update of the card corresponding to the ride-hailing order.

[0207] In this embodiment, in response to an order generated by the first application, a first card view and a background view of the first card view associated with the order are obtained. Based on the card setting parameters of the host application, the first card view and the background view are processed to generate a second card view. Then, the host application displays the second card view, thereby displaying the first card. In this way, different styles of cards can be displayed through the host application without requiring the first application to adapt itself, enriching the card display effects and improving card management efficiency.

[0208] Furthermore, when the electronic device displays notification information from the first application in the form of cards, the first application generates a card view and creates a first embedded window, while the host application creates a second embedded window. The SurfaceControl layer in the first embedded window is mounted to the second embedded window, and then the card view is rendered onto the SurfaceControl layer. In this way, the host application displays the card by showing its own second embedded window. Because the host application achieves card display by showing the second embedded window, rather than directly displaying the card view, the first application can create card views including custom card elements according to its own needs. This allows for a more efficient and intuitive presentation of the first application's notification information to the user.

[0209] In addition, when the electronic device displays the card of the first application, displaying the card corresponding to the first application based on the first embedded window can improve the speed of cross-process data transmission, realize the real-time refresh of the card of the first application, thereby ensuring the timeliness of the notification information of the first application and providing a better user experience.

[0210] It should be noted that this application's embodiment uses the provided card display method applied to a real-time card framework (i.e., SurfaceControlViewHost) as an example for illustration. In another example, this method can also be applied to the native Android card framework (i.e., AppWidget). For instance, during implementation, the foreground view (i.e., card view) and background view of the card can be requested from the card provider of the ride-hailing application, and then, based on the card setting parameters of each host application, cards with the style required by each host application can be generated based on the foreground view and background view, thereby being displayed through the host application.

[0211] Please see Figure 12 , Figure 12 This is a flowchart illustrating a method for displaying a card according to another exemplary embodiment. As an example and not a limitation, the method may be as described above. Figure 7 The execution of the electronic device shown may include some or all of the following:

[0212] S1201, In response to the generation of an order in the first application, obtain the first card view and the background view of the first card view of the first application, wherein the first card is used to display information related to the order.

[0213] For example, the first application is Figure 9 In the ride-hailing application shown in the embodiment, the order is a ride-hailing order.

[0214] The specific implementation of step S1201 can be found in steps S801 to S830 of the above embodiments.

[0215] In one example, before obtaining the first card view and background view of the first card view of the first application, the electronic device can also obtain the first target layer in the first embedded window corresponding to the first application. This first target layer is used to render the second card view and create the second embedded window of the second application. The first target layer is embedded into the second embedded window. A placeholder is added to the second embedded window containing the first target layer. The second embedded window with the added placeholder is added to the parent view of the second application, which is used to contain the second embedded window. For a detailed implementation, see [link to implementation details]. Figure 9 Steps S815 to S822 in the illustrated embodiment.

[0216] For example, the first target layer is as described above. Figure 8 and Figure 9 The SurfaceControl layer in the illustrated embodiment. The second card view is a card view rendered within the SurfaceControl layer. The second application can be the aforementioned host application, such as, but not limited to, the desktop, notification center, lock screen, always-on display, or negative one screen.

[0217] It is worth mentioning that, before displaying the first card, the electronic device uses a placeholder by attaching the first target layer to the second embedded window to prevent the second application from displaying cards from other applications before the first card is displayed.

[0218] In one example, the specific implementation of retrieving the first target layer in the first embedded window corresponding to the first application may include: querying whether the first embedded window exists in the electronic device; if the first embedded window exists in the electronic device, retrieving the first target layer from the first embedded window; if the first embedded window does not exist in the electronic device, creating the first embedded window and retrieving the first target layer from the created first embedded window. For a detailed implementation, please refer to [link to implementation details]. Figure 9 S817 in the illustrated embodiment. Thus, if a valid first embedded window exists, it can be used directly, avoiding the need to recreate it and improving processing speed. Of course, if a valid first embedded window does not exist, a first embedded window is created to render the second card view, thereby enabling the card to be displayed synchronously in the host application through the embedded window. For details, please refer to the above.

[0219] In one example, if a second application requests that the first card be displayed with a motion blur effect, after adding a second embedded window with placeholders to the parent view of the second application, the second target layer in the second embedded window is set to transparent. The second target layer is the layer used to embed the first target layer into the second embedded window. Exemplarily, the second target layer is a layer of a SurfaceView.

[0220] It is worth mentioning that when the second application requests to display the first card with a motion blur effect, the color of the second target layer is prevented from showing through when the first card is displayed, thus avoiding affecting the display effect of the first card, by setting the second target layer to transparent.

[0221] In one example, if the second application requests a transparent second card view, a second embedded window with placeholders is added to the parent view of the second application, and then a custom background layer for the second application is set on the parent view.

[0222] It is worth mentioning that when the second application requests a transparent second card view, it means that the second host application needs to customize the background color. Therefore, a custom background layer is set on the parent view so that after the second card view is rendered to the first target layer and the placeholder is removed, the second application can display the first card, and the first card has the background effect customized by the second application.

[0223] S1202. Generate a second card view based on the card setting parameters of the second application, the first card view, and the background view. The second application is an application in the electronic device used to display cards.

[0224] In one example, the card setting parameters include at least one of card rounded corner information, transparency indication information, and dynamic blur indication information. The transparency indication information is used to indicate whether the second card view needs to be transparent, and the dynamic blur indication information is used to indicate whether the first card needs to be displayed with a dynamic blur effect. The dynamic blur effect means that when the first card is displayed on the interface of the second application, the area where the first card is located can blur through the interface color of the second application.

[0225] When the card setting parameters include card corner radius information, transparency indicator information, and motion blur indicator information, the specific implementation of S1202 may include: if the motion blur indicator information indicates that the first card needs to be displayed with a motion blur effect, generating a second card view based on the card corner radius information and the first card view, and blurring the first target layer. If the motion blur indicator information indicates that the first card does not need to be displayed with a motion blur effect, generating a second card view based on the card corner radius information, transparency indicator information, the first card view, and the background view.

[0226] Thus, based on the card setting parameters, a second card view is generated from the first card view and the background view to obtain a card view that satisfies the second application, avoiding the need for the first application to perform adaptation itself and improving the applicability of the card display method.

[0227] In one possible scenario, if the motion blur indicator suggests that the first card needs to be displayed with a motion blur effect, the rounded corners of the first card view are cropped based on the card's rounded corner information. The cropped first card view is then designated as the second card view.

[0228] Thus, if the dynamic blur indicator message indicates that the first card needs to be displayed with a dynamic blur effect, it means that a transparent card view is required, and a dynamic blur effect is also required. Therefore, the rounded corners of the first card view can be directly cropped to obtain a second card view that meets the display requirements of the second application, and the first target layer can be blurred so that a dynamic blur effect can be achieved when it is displayed.

[0229] In another possible scenario, if the motion blur indicator indicates that the first card does not need to be displayed with a motion blur effect, and the transparency indicator indicates that the second card view needs to be transparent, then the rounded corners of the first card view are cropped according to the card's rounded corner information to obtain the second card view. If the transparency indicator indicates that the second card view does not need to be transparent, then the background view is merged with the first card view, and the rounded corners of the merged first card view are cropped according to the card's rounded corner information to obtain the second card view.

[0230] Thus, when the motion blur indicator indicates that the first card does not need to be displayed with a motion blur effect, the second application determines what background style of card view is required based on the transparency indicator. Then, the card is cropped with rounded corners based on the card's rounded corner information to obtain a second card view that meets the background display requirements of the second application.

[0231] For details, please refer to [link / reference]. Figure 9 S831 to S834 in the illustrated embodiment.

[0232] In one example, the card setting parameters also include card size information. Thus, when the first card view and background view are obtained, in response to an order being generated, the card size information is transmitted to the first application so that the first application can generate the first card view and background view respectively according to the card size information, so as to obtain a second card view that meets the size display requirements of the second application.

[0233] It should be noted that the specific implementation of generating the second card view based on the card setting parameters of the second application, the first card view, and the background view described above is only exemplary. In another example, the specific implementation may include other methods. For example, the card setting parameters may include other forms, or the first card view and the background view may be processed first based on the transparency indication information, and then processed based on the dynamic blur indication information and the card rounded corner information. This application embodiment does not limit this.

[0234] S1203. Display a second card view through a second application to display the first card.

[0235] In one example, a specific implementation of S1203 may include: rendering the second card view onto the first target layer of the second embedded window, removing the placeholder in the second embedded window, and, if the interface of the second application is displayed, displaying the second embedded window in the interface of the second application to display the first card in the interface of the second application.

[0236] Thus, by rendering the second card view onto the first target layer and removing the placeholders, the first card is displayed, which means that the first card with a custom style is displayed through the second application.

[0237] In this embodiment, in response to an order generated by the first application, a first card view and a background view of the first card view associated with the order are obtained. Based on card setting parameters of the second application, the first card view and the background view are processed to generate a second card view. The second card view is then displayed through the second application, thereby displaying the first card. In this way, different styles of cards can be displayed through the second application without requiring the first application to adapt itself, enriching the card display effects and improving card management efficiency.

[0238] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. See also... Figure 13The electronic device 100 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, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 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 sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0239] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

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

[0241] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0242] 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 this memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0243] In some embodiments, the processor 110 may include one or more interfaces, such as 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.

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

[0245] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via a USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device 100 via the power management module 141.

[0246] 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, and supplies power to the processor 110, internal memory 121, external memory, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

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

[0248] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0249] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is an integer greater than 1.

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

[0251] Internal memory 121 can be used to store computer-executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created by electronic device 100 during use (such as audio data, phonebook, 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.

[0252] It should be noted that, when electronic devices take on different forms such as mobile phones, tablets, and handheld computers, their structures may include components that are more complex than those in other devices. Figure 13 The fewer structures shown can also include more than Figure 13 More structures are shown.

[0253] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0254] The above-described embodiments are optional embodiments provided by this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the technical scope disclosed in this application should be included within the protection scope of this application.

Claims

1. A method for displaying a card, characterized in that, Applied to electronic devices, the method includes: In response to an order generated by the first application, the first target layer in the first embedded window corresponding to the first application is obtained; Create a second embedded window for a second application, wherein the second application is an application in the electronic device used to display cards; Embed the first target layer into the second embedded window; Add a placeholder to the second embedded window containing the first target layer; The second embedded window with the placeholder added is added to the parent view of the second application, and the parent view is used to accommodate the second embedded window; Obtain a first card view and a background view of the first card view from the first application, wherein the first card is used to display information related to the order; A second card view is generated based on the card setting parameters of the second application, the first card view, and the background view; Render the second card view onto the first target layer of the second embedded window; Delete the placeholder in the second embedded window; When the interface of the second application is displayed, the second embedded window is displayed in the interface of the second application to display the first card in the interface of the second application.

2. The method as described in claim 1, characterized in that, The step of obtaining the first target layer in the first embedded window corresponding to the first application includes: Check whether the first embedded window exists in the electronic device; If the first embedded window exists in the electronic device, the first target layer in the first embedded window is obtained; If the first embedded window does not exist in the electronic device, the first embedded window is created, and the first target layer is obtained from the created first embedded window.

3. The method as described in claim 1 or 2, characterized in that, The card setting parameters include card rounded corner information, transparency indication information, and dynamic blur indication information. The transparency indication information is used to indicate whether the second card view needs to be transparent, and the dynamic blur indication information is used to indicate whether the first card needs to be displayed with a dynamic blur effect. The dynamic blur effect means that when the first card is displayed on the interface of the second application, the area where the first card is located can blur the interface color of the second application. The step of generating a second card view based on the card setting parameters of the second application, the first card view, and the background view includes: When the dynamic blur indication information indicates that the first card needs to be displayed with a dynamic blur effect, the second card view is generated based on the card rounded corner information and the first card view, and the first target layer is blurred. If the dynamic blur indicator information indicates that the first card does not need to be displayed with a dynamic blur effect, the second card view is generated based on the card rounded corner information, the transparency indicator information, the first card view, and the background view.

4. The method as described in claim 3, characterized in that, When the dynamic blur indicator information indicates that the first card needs to be displayed with a dynamic blur effect, generating the second card view based on the card's rounded corner information and the first card view includes: When the dynamic blur indication information indicates that the first card needs to be displayed with a dynamic blur effect, the rounded corners of the first card view are cropped according to the card rounded corner information; The cropped first card view is designated as the second card view.

5. The method as described in claim 3, characterized in that, When the dynamic blur indicator information indicates that the first card does not need to be displayed with a dynamic blur effect, generating the second card view based on the card rounded corner information, the transparency indicator information, the first card view, and the background view includes: If the motion blur indicator indicates that the first card does not need to be displayed with a motion blur effect, and the transparency indicator indicates that the second card view needs to be transparent, then the rounded corners of the first card view are cropped according to the card rounded corner information to obtain the second card view; If the transparency indication information indicates that the second card view does not need to be transparent, then the background view is merged with the first card view, and the rounded corners of the merged first card view are cropped according to the card rounded corner information to obtain the second card view.

6. The method as described in claim 3, characterized in that, The card setting parameters also include card size information; The step of responding to an order generated by the first application by obtaining a first card view of the first card and a background view of the first card view includes: In response to the order being generated, the card size information is transmitted to the first application, so that the first application generates the first card view and the background view respectively based on the card size information.

7. The method as described in claim 1 or 2, characterized in that, After adding the second embedded window with the placeholder to the parent view of the second application, the method further includes: When the second application requests that the first card be displayed with a dynamic blur effect, the second target layer in the second embedded window is set to transparent. The second target layer is a layer used to embed the first target layer into the second embedded window. The dynamic blur effect refers to the fact that when the first card is displayed on the interface of the second application, the area where the first card is located can blur the interface color of the second application.

8. The method as described in claim 1 or 2, characterized in that, After adding the second embedded window with the placeholder to the parent view of the second application, the method further includes: If the second application requests a transparent second card view, a background layer customized by the second application is set on the parent view.

9. The method as described in claim 1 or 2, characterized in that, The second application is the desktop, notification center, lock screen, always-on display, or negative one screen.

10. An electronic device, characterized in that, The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as described in any one of claims 1-9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-9.

Images