Card display method, electronic equipment and readable storage medium

Abstract

The invention discloses a card display method, electronic equipment and a readable storage medium, and belongs to the technical field of terminals. The method comprises the steps that in response to order generation of a first application program, a first card view of a first card of the first application program and a background view of the first card view are obtained, the first card is used for displaying information related to an order, and according to card setting parameters of a second application program, the first card view and the background view, the first card view is used for displaying information related to the order; a second card view is generated, the second application program is an application program used for displaying the card in the electronic equipment, and the second card view is displayed through the second application program so as to display the first card. According to the method and the device, cards of different styles can be displayed through the second application program without self adaptation of the first application program, so that the display effect of the cards is enriched.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to a card display method, an electronic device and a readable storage medium. Background Art

[0002] With the rapid development of terminal technology, the functions of electronic devices such as mobile phones and tablet computers are becoming more and more abundant. For example, electronic devices can display notification information of a certain application to users in the form of cards. The notification information can be text messages, itinerary information, taxi information, food delivery information, etc. Summary of the invention

[0003] The present application provides a method for displaying a card, an electronic device, and a readable storage medium, which can enable the electronic device to have different display effects when displaying application cards through different host applications, without the need for the application to adapt itself. The technical solution is as follows:

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

[0005] In response to the generation of an order of a first application, a first card view of a first card of the first application and a background view of the first card view are obtained, wherein the first application is an application in an electronic device that needs to display cards related to the order, and the first application may be a third-party application or a system application, and the first card is used to display information related to the order. Then, the electronic device generates a second card view according to the card setting parameters of the second application, the first card view, and the background view, wherein the second application is an application in the electronic device for displaying cards. Thereafter, the second card view is displayed through the second application to display the first card.

[0006] In this way, by obtaining the separated first card view and the 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. Cards of different styles can be displayed through the second application without the need for the first application to adapt itself, which enriches the display effect of the card and improves the management efficiency of the card.

[0007] As an example but not limitation, the second application is a desktop, a notification center, a lock screen, an off screen, or a negative screen. In the implementation process, the electronic device can display the first card in each second application according to the above method, so that when the second application runs to the foreground, the user can see the displayed first card in the second application running in the foreground, thereby increasing the display position of the first card.

[0008] As an example of the present application, before obtaining the first card view of the first card of the first application and the background view of the first card view, the electronic device obtains the first target layer in the first embedded window corresponding to the first application, the first embedded window is used for the first application to embed the second card view, the first target layer is the real layer used to render the second card view in the first embedded window, that is, the first target layer is used to render the second card view. After that, the electronic device creates the second embedded window of the second application, that is, the second embedded window is an embedded window for the second application. In this way, the first target layer is embedded into the second embedded window, so that the first target layer is used to occupy the second embedded window, so as to avoid the second application from displaying the card view of other applications in the second embedded window. In addition, a placeholder can be added to the second embedded window embedded with the first target layer, so as to occupy the placeholder. 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. 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 realizing the display of the first card.

[0009] As an example of the present 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 to 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, displaying the second embedded window in the interface of the second application to display the first card in the interface of the second application.

[0010] In this way, by rendering the second card view into the first target layer and deleting the placeholder, the first card is displayed, that is, the first card with a custom style is displayed through the second application.

[0011] As an example of the present 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 means that the electronic device has created a first embedded window before. In this case, the previously created first embedded window can be used directly, that is, 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 means that the electronic device has not created the first embedded window before. In this case, the electronic device creates the first embedded window and obtains the first target layer from the created first embedded window.

[0012] In this way, when there is a valid first embedded window, the first embedded window can be used directly to avoid the need to recreate it, which can improve the processing speed. Of course, when there is no valid first embedded window, the first embedded window is created to render the second card view through the first embedded window, so that the card can be displayed synchronously in the host application through the embedded window.

[0013] As an example of the present application, the card setting parameters include card corner fillet information, transparency indication information, and dynamic blur indication information, wherein 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 as a dynamic blur effect, wherein 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 vaguely show the interface color of the second application. In this case, the specific implementation of the electronic device generating the second card view according to the card setting parameters of the second application, the first card view, and the background view may include the following two possible situations:

[0014] In the first case, 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 according to the card corner information and the first card view, and the first target layer is blurred. Specifically, when the dynamic blur indication information indicates that the first card needs to be displayed with a dynamic blur effect, the corners of the first card view are cropped according to the card corner information, and the cropped first card view is determined as the second card view.

[0015] In this way, when the dynamic blur indication information 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 required, so 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 displayed.

[0016] In the second case, when the dynamic blur indication information indicates that the first card does not need to be displayed as a dynamic blur effect, the second card view is generated according to the card rounded corner information, the transparent indication information, the first card view and the background view. Specifically, when the dynamic blur indication information indicates that the first card does not need to be displayed as a dynamic blur effect, if the transparent indication information indicates that the second card view needs to be transparent, 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 transparent indication information indicates that the second card view does not need to be transparent, 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.

[0017] In this way, when the second application requests a transparent second card view, it means that the second host application needs a customized background color, so a custom background layer is set on the parent view, so that after rendering the second card view to the first target layer and removing the placeholder, 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 the present application, the card setting parameters also include card size information. In this case, the electronic device obtains the first card view of the first card of the first application and the background view of the first card view in response to the order of the first application. The specific implementation may include: in response to the order generation, transmitting the card size information to the first application, so that the first application generates the first card view and the background view respectively according to the card size information. That is, when obtaining the first card view and the background view, the card size information is transmitted to the first application, so that the first application can generate the first card view and the background view that meet the size display requirements of the second host application according to the card size information.

[0019] As an example of the present 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 added to the parent view of the second application, the second target layer in the second embedded window can also be set to be transparent, and 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 means that when the first card is displayed on the interface of the second application, the area where the first card is located can vaguely show the interface color of the second application.

[0021] In this way, when the second application requests to display the first card with a dynamic blur effect, by setting the second target layer to be transparent, the color of the second target layer is prevented from showing through when displaying the first card, thereby affecting the display effect of the first card.

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

[0023] In this way, when the second application requests a transparent second card view, it means that the second host application needs a customized background color, so a custom background layer is set on the parent view, so that after rendering the second card view to the first target layer and removing the placeholder, 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, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method for displaying a card as described in the first aspect is implemented.

[0025] In a third aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is executed on a computer, the computer executes the method for displaying a card described in the first aspect.

[0026] In a fourth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute the method for displaying a card as described in the first aspect.

[0027] The technical effects obtained by the above-mentioned second aspect, third aspect and fourth aspect are similar to the technical effects obtained by the corresponding technical means in the above-mentioned first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

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

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

[0036] Fig. 9 is a flowchart of a method for displaying a card according to another exemplary embodiment;

[0037] Fig.10 is a schematic diagram showing a display effect of a layer according to an exemplary embodiment;

[0038] Fig.11 is a schematic diagram showing a display effect of preloading of a card according to an exemplary embodiment;

[0039] Fig.12 is a flowchart of a method for displaying a card according to another exemplary embodiment;

[0040] Fig.13 The diagram is a schematic structural diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0041] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0042] It should be understood that the "multiple" mentioned in this application refers to two or more. In the description of this application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in order to facilitate the clear description of the technical solution of this application, the words "first" and "second" are used to distinguish between the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the words "first" and "second" do not limit the quantity and execution order, and the words "first" and "second" do not limit them to be different.

[0043] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0044] In order to be able to more intuitively display the notification information of a certain application (hereinafter referred to as the first application) to the user, the electronic device can display the notification information through a card (or widget, part, component, etc.). The first application is an application in the electronic device that needs to publish notification information. The first application can be an application that comes with the electronic device, or it can be a third-party application. For example, the first application is a travel application, a delivery application, etc. The travel application is an application that provides users with services such as taxis, ticket bookings, and travel reminders, such as travel applications such as taxi applications and map applications. The delivery application is an application that provides users with delivery services for items such as express and meals, such as delivery applications that are takeout applications and express delivery applications.

[0045] In some embodiments, when the electronic device displays the notification information of the first application in the form of a card, the card can be created according to the predefined native card elements and the card can be displayed. Among them, the original card elements are usually predefined interface elements based on the Android native card framework (i.e., AppWiget). That is to say, for the first application, when the electronic device displays the card corresponding to the first application, the card corresponding to the first application can only include native card elements and cannot carry the custom card elements of the first application. For example, taking the notification information as the order-related information of the taxi application as an example, when the electronic device displays the card corresponding to the taxi application, the taxi application running in the electronic device creates the corresponding card according to the native card elements, and serializes the card according to the preset rules to obtain the card data of the card corresponding to the taxi application. The taxi application can send the card data to the host application of the electronic device. Afterwards, the host application creates and displays the card corresponding to the taxi application according to the card data, wherein the card only includes the native card elements supported by the Android native card framework. In addition, the taxi application can call predefined functions, such as the set text function and the set translation function. Correspondingly, the host application can also call predefined functions, such as the set text function and the set translation function. Among them, the electronic device can pre-establish the corresponding relationship between the set text function that can be called by the taxi application and the set text function that can be called by the host application, and pre-establish the corresponding relationship between the set translation function that can be called by the taxi application and the set translation function that can be called by the host application. In this way, the taxi application can call the set text function of the taxi application to update the text elements in the card. When the taxi application calls the set text function of the taxi application to update the text elements in the card, based on the pre-established corresponding relationship, the set text function that can be called by the host application corresponding to the set text function of the taxi application can be first determined. Therefore, the host application can call the set text function corresponding to the host application to update the text elements in the card.

[0046] Of course, the taxi application can also call the set translation function of the taxi application to update the display position of the card. When the taxi application calls the set translation function of the taxi application to update the display position of the card, based on the pre-established correspondence, the set translation function that can be called by the host application corresponding to the set translation function of the taxi application can be determined first. Thus, the host application can call the set translation function corresponding to the host application to update the display position in the card.

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

[0048] In addition, when the electronic device displays the notification information of the first application in the form of a card, the card can be displayed respectively by at least one host application in the electronic device, wherein the host application is an application for displaying the card. As an example and not limitation, the host application can be but is not limited to the desktop, negative one screen, notification center, banner notification, screen off or lock screen of the electronic device.

[0049] Different host applications usually have different display effects when displaying cards. In some embodiments, special effects such as blurring of cards cannot be achieved, or the first application needs to adapt to special scenarios such as blurring of cards separately. To this end, an embodiment of the present application provides a method for displaying cards, which enables the host application to display cards with display effects such as blurring customized by the host application without the need for separate adaptation of the first application. And the method supports the first application to create a card view including custom card elements according to needs, and display the card view, so as to more effectively and intuitively display the notification information of the first application to the user.

[0050] In one example, the display effects include custom rounded corners, dynamic blur, static blur, custom background, etc. Next, taking the electronic device as a mobile phone and the first application as a taxi-hailing application as an example, several display effects of cards involved in several exemplary application scenarios are introduced.

[0051] In an exemplary application scenario, when a user needs to take a taxi, he can use the taxi application on the mobile phone to place an order for the taxi. When the taxi order is generated (for example, the driver accepts the order), the mobile phone can display the corresponding cards of the taxi application in multiple host applications (such as the desktop, notification center, lock screen, etc.).

[0052] In one example, when the mobile phone displays the desktop, the user can see the following on the mobile phone desktop: Figure 1 The card 111 shown, that is, the card 111 can be displayed at the top of the mobile phone desktop 110. The card 111 may include an icon 112 of a taxi application, a text 113 of "License plate number XXX·Arrival in about 2 minutes", and a text 114 of "Master Zhang·White". The card 111 may also include a call control 115, which may be used to contact the driver who accepts the order. The display height of the card 111 is h1, the display width of the card 111 is d1, the rounded corner size of the card 111 is c1, and the card 111 has a dynamic blur display effect when displayed ( Figure 1 ), that is, the user can see the background color of the desktop of the mobile phone from the area where the card 111 is located, but the background color of the desktop that can be seen is not completely clear.

[0053] In an example, see Figure 2 In (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 on the top status bar of the display screen, in response to the pull-down operation, such as Figure 2 As shown in FIG. 1( b ), the mobile phone displays a notification center 120, and a card 121 is displayed in the notification center 120. Figure 2 As shown in FIG. 1( b ), the card 121 may include an icon 122 of a taxi-hailing application, text 123 of “License plate number XXX·Arrival in about 2 minutes”, and text 124 of “Master Zhang·White”. Figure 1Compared with the card 111 shown in the figure, the card 121 may also include a progress bar 125. The progress bar 125 may more intuitively prompt the user of the processing progress of the taxi order. The display height of the card 121 is h2, the display width of the card 121 is d2, and the rounded corner size of the card 121 is c2. The card 121 has a static blur effect. Exemplarily, the display height h2 of the card 121 is less than the display height h1 of the card 111, the display width d2 of the card 121 may be equal to the display width d1 of the card 111, and the rounded corner size c2 of the card 121 may be less than the rounded corner size c1 of the 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, so that the space occupied by the card corresponding to the taxi order can be reduced, so that the mobile phone can display more cards corresponding to other notification information, and then the user does not need to flip through the operation to view more notification information cards, which can improve the efficiency of human-computer interaction.

[0054] In another example, see Figure 3 In (a) of FIG. 1 , after the card 111 is displayed on the desktop 110 of the electronic device, when the electronic device receives a lock screen operation from the user (such as pressing a lock screen key), the electronic device enters a lock screen state. When the electronic device is in the lock screen state, in response to a touch operation of the user on the display screen of the electronic device, such as Figure 3 As shown in FIG. 1 (b), the electronic device displays a lock screen interface 130, and a display card 131 is displayed in the lock screen interface 130. Figure 3 As shown in FIG. 1( b ), the card 131 may include an icon 132 of a taxi-hailing application, text 133 of “License plate number XXX·Arrival in about 2 minutes”, and text 134 of “Master Zhang·White”. Figure 1 Compared with the card 111 shown in the figure, the card 131 may also include a progress bar 135. The progress bar 135 may more intuitively prompt the user of the processing progress of the taxi order. The display height of the card 131 is h3, the display width of the card 131 is d3, and the rounded corner size of the card 131 is c3. Exemplarily, the display height h3 of the card 131 is smaller than the display height h2 of the card 111, the display width d3 of the card 131 is smaller than the display width d1 of the card 111, and the rounded corner size c3 of the card 131 is smaller than the rounded corner size c1 of the card 111. In addition, the card 131 is located at the lower side of the lock screen interface 130, while the card 111 is located at the top of the desktop 110, that is, the display position of the card 131 is different from the display position of the card 111.

[0055] In another example, see Figure 4 In FIG. 1 (a), after the card 111 is displayed on the desktop 110 of the electronic device, when the electronic device receives a screen-off operation (such as pressing a lock screen key) from the user, 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 touch operation (such as a sliding operation) on card 141 (i.e., a card capsule), the electronic device opens a taxi application. Since the space of the electronic device's always on display interface is limited, 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 rounded corner size c4 of card 141 is greater than the rounded corner size c1 of card 111. In this way, when switching to the always on display interface, the space occupied by the card corresponding to the taxi order can be minimized to avoid the card from being unable to be 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 relevant information of the taxi order (such as the icon 142 of the taxi application and the text 143 of "license plate number XXX"). In this way, the user does not need to open the taxi application to obtain some information of the taxi application, which is more convenient to use.

[0056] In another example, when the electronic device displays a card at a specified location on the desktop, the background color can be customized, such as a black background or a white background. The specified location can be set according to actual needs, such as the specified location is an area where a camera is located, and the size and rounded corner size of the card can also be set according to needs. For example, see Figure 5 , Figure 5 is a method according to an exemplary embodiment of a method of setting a black background ( Figure 5 Schematic diagram of the display effect of a card (represented by a grayscale image in FIG).

[0057] It can be seen from the above examples that the method for displaying cards provided in the embodiment of the present application, when displaying cards through the host application of the electronic device, has different display modes for different host applications, that is, different display effects. Moreover, according to the content to be displayed by different host applications and the user's usage habits, the content information carried by the card can be set with emphasis to achieve the purpose of notifying the user, and can also improve the efficiency of human-computer interaction, thereby improving the user experience.

[0058] It should be noted that the above application scenarios are only exemplary. In another example, the card display method can also be applied to other application scenarios for displaying cards, such as displaying cards corresponding to food delivery applications, or displaying cards corresponding to instant messaging applications (such as WeChat). TM) corresponding cards, etc. For another example, it can also be applied to scenes such as custom rounded corners, static blur, dynamic blur, custom background, etc. when displaying a pure embedded view (View) (non-card scene, such as Amap embedded map), which is not limited in the embodiments of the present application.

[0059] It should be noted that the above description is based on the example that the electronic device is a mobile phone. In another example, the electronic device may also be a sports camera (GoPro), a digital camera, a tablet computer, a desktop, a laptop, a handheld computer, a notebook computer, a vehicle-mounted device, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), etc., which is not limited in the embodiments of the present application.

[0060] The realization of electronic device functions usually requires the cooperation of software systems. Next, the software system of electronic devices is introduced. The software system of electronic devices can adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of this application takes the Android system with a layered architecture as an example to illustrate the software structure of the electronic device.

[0061] Figure 6 It is a software structure diagram of the electronic device provided in the embodiment of the present application. The layered architecture divides the software into several layers, each layer has 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, namely, the application layer, the application framework layer (framework, FWK), the Android runtime (android runtime) and the system library (also called the Native layer), and the kernel layer.

[0062] The application layer may include camera, gallery, calendar, call, map, navigation, WLAN (wireless local area network), Bluetooth, music, video, short message and the like.

[0063] The application framework layer provides application programming interface (API) and programming framework for the applications in the application layer. The application framework layer includes some predefined functions. Figure 6 As shown, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

[0064] Android runtime is responsible for the scheduling and management of the Android system. The system library can include multiple functional modules, such as: surface manager, media library, 3D graphics processing library (such as: OpenGL ES), 2D graphics engine (such as: SGL), etc.

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

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

[0067] The first application can be used to provide a card view of the card to be displayed. The card view refers to a view that has been laid out and includes the card content to be displayed. In one example, a card provider (also known as Provider) may be integrated into the first application, such as TaxiProvider integrated into the taxi application. The card provider is used to provide a card view of the first application. The first application may include one or more card providers. As an example and not a limitation, different card views of the same first application may be provided by different card providers. For example, the cards corresponding to two taxi orders in the taxi application may be provided by TaxiProvider1 and TaxiProvider2, respectively.

[0068] The host application can be used as a display carrier of the card view, and is mainly responsible for displaying the card view in its own specified area. As an example and not limitation, the host application in the electronic device includes at least one of the electronic device's desktop, negative one screen, notification center, banner notification, off screen, and lock screen.

[0069] The management plug-in corresponding to the application (ie, the first application or the host application) may be an AAR (android archive) or a JAR (Java Archive). The embodiment of the present application is illustrated by taking the management plug-in corresponding to the application as an AAR as an example.

[0070] 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, see Figure 7, the card kit can serve as a bridge for interaction between the first application and the card management service (LiveClipManagerService). That is, the card kit can integrate the relevant interfaces of the card display, so that the first application can establish a communication connection with the card management service through the relevant interfaces of the card display integrated by the card kit, and then interact with the card management service through the card kit. In other words, the first application does not need to understand the card management service, and can implement functions such as card access, timed refresh, card cache, card acquisition and card destruction by only calling the relevant interfaces provided by the card kit.

[0071] It should be noted that the card kit can be integrated into the first application, that is, all applications that provide cards in the electronic device can integrate the card kit. In the case of multiple first applications, different first applications can integrate their corresponding card kits, that is, each first application corresponds to a card kit. For example, a taxi application can integrate a card kit, and another example is a food delivery application can also integrate a card kit.

[0072] The AAR corresponding to the host application (also called Host AAR) can serve as a bridge for interaction between the host application and the card management service. That is, the Host AAR can integrate the relevant interfaces of card display, so that the host application can establish a communication connection with the card management service through the relevant interfaces of card display integrated by the Host AAR. In this way, the host application can quickly access the card management service through the Host AAR to help the host application realize functions such as host access, request to show / hide, obtain HostView (host view), size change, configuration (config) change, etc.

[0073] It should be noted that Host AAR can be integrated into the host application, that is, each host application of the electronic device can integrate Host AAR. As an example but not a limitation, different host applications can each integrate their own Host AAR, that is, each host application corresponds to a Host AAR. For example, the desktop of the electronic device can integrate Host AAR, the notification center of the electronic device can integrate Host AAR, and the negative one screen of the electronic device can also integrate Host AAR.

[0074] Please continue to see Figure 7 The application framework layer can also include service frameworks such as card display service (DisplayService), card management service and system service (Service).

[0075] The card display service can be used as an initiator of instructions related to card display. The card display service is used to receive a card display notification from a first application, and then notify the host application to display a card, hide a card, or destroy a card.

[0076] The card management service is a bridge connecting the first application and the host application. The card management service can implement functions such as card lifecycle management, power consumption control, data caching, and exception recovery. The card management service can obtain the host application's card display-related instructions, and use the system service to send the card display-related instructions to the card kit to instruct the card kit to obtain the card view from the first application. The card management service can also be used to use the system service to establish a communication connection with the HostAAR, and send the obtained card view to the host application through the Host AAR for the host application to display the card.

[0077] The system service has the basic capabilities of Android native services, that is, the system service can provide a data transmission channel across processes, so that the first application and the host application can interact across processes.

[0078] In the above Figure 7 Based on the embodiment shown, next Figure 8 , taking the first application being a taxi-hailing application as an example, the method for displaying a card provided in the embodiment of the present application is described in detail. Here, the method is described by taking the interaction of multiple modules of an electronic device as an example, and may mainly include the following parts or all of the contents:

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

[0080] In one example, the taxi-hailing operation is triggered by a user when he needs to take a taxi, and the taxi-hailing operation may include at least one operation. When the user triggers the taxi-hailing operation, for example, the user submits a taxi-hailing request, or the driver accepts the order after the user submits the taxi-hailing request, the taxi-hailing application generates a taxi-hailing order.

[0081] S802: After a taxi order is generated, the taxi application sends a card display notification to the card display service.

[0082] Card display notification is used to notify the card display service that a card needs to be displayed.

[0083] That is, after a taxi order is generated, the taxi application can notify the card display service to display the card.

[0084] It should be noted that when the taxi-hailing application sends a card display notification to the card display service, the card display notification may be sent to the card display service through one or more modules, which is not limited in this embodiment of the present application.

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

[0086] One taxi order corresponds to one unique card instance information (ie, cardInstanceId). Since one taxi order corresponds to one card, it can be understood that one card corresponds to one card instance information.

[0087] Since there may be multiple taxi orders in the taxi application, each taxi order must have a corresponding card. Therefore, in order to distinguish which card belongs to which taxi order, when the card display service receives the card display notification sent by the taxi application, the card display service allocates card instance information to the card requested to be displayed by the taxi application.

[0088] S804: The card display service sends the allocated cardInstanceId to the taxi-hailing application.

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

[0090] As an example of the present application, after receiving the cardInstanceId, the taxi application can associate the cardInstanceId, the card provider of the taxi application (i.e., TaxiProvider), and the taxi order. For example, when the taxi application receives the card instance information 1 corresponding to order A, the card instance information 1, the TaxiProvider1 corresponding to order A and order A can be associated, and when the taxi application receives the card instance information 2 corresponding to order B, the card instance information 2, the TaxiProvider2 corresponding to order B and order B can be associated. In this way, the corresponding taxi order or TaxiProvider can be queried according to the cardInstanceId later.

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

[0092] The binding instruction is used to instruct the binding of the taxi application, specifically, to instruct the binding of the card provider (i.e., TaxiProvider) in the taxi application, so that the card management service can subsequently make cross-process calls with the taxi application. The card provider can provide a card view of the card requested to be displayed by the taxi application.

[0093] In one example, the card provider information may include the package name of the taxi-hailing application and the name of the card provider. The card provider information may be obtained from the taxi-hailing application. As an example and not a limitation, the card display service may obtain the card provider information from a specified Extensible Markup Language (XML) file through a package manager service (PMS), where the specified XML file is a file for storing the card provider information.

[0094] In one example, the card display service may send a binding instruction to the card management service by calling the create(AppClipInfo, cardInstanceId) function to instruct 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 to bind the card provider in the taxi application by calling the create(AppClipInfo, cardInstanceId) function.

[0097] S807. The card kit binds to the card provider of the taxi-hailing application according to the binding instruction.

[0098] Card Kit determines the TaxiProvider of the taxi application based on the card provider information (AppClipInfo) and initializes the TaxiProvider of the taxi application. After the initialization is completed, Card Kit can bind the service with the TaxiProvider of the taxi application so that the TaxiProvider of the taxi application can be called across processes during the subsequent card display process.

[0099] In one example, the card kit can bind the card provider in the taxi application by calling back the onCreate(cardInstanceId) function according to the binding instruction.

[0100] S808: The card provider caches the mapping relationship between AppClipInfo and cardInstanceId.

[0101] After the binding is completed, the card provider (TaxiProvider) stores the AppClipInfo and cardInstanceId in correspondence.

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

[0103] In one example, TaxiProvider may send a binding success notification to the card kit via a callback, so that the card display service is notified through the card kit that the binding service has been completed.

[0104] S810. The card kit sends a binding success notification to the card management service.

[0105] In one example, the card kit sends a binding success notification to the card management service by way of a callback, so that the card management service feeds back the binding success notification 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 be informed that the service binding has been completed.

[0108] After that, the card display service can issue a card display instruction to display the card requested by the taxi application through the host application. Fig. 9 The card display process is introduced, which mainly includes the following steps:

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

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

[0111] The host application is an application registered in the electronic device that can display cards. The number of host applications may be one or more. As mentioned above, the host application may include at least one of the desktop, the negative one screen, the notification center, the banner notification, the off screen, and the lock screen. The host application can always be alive in the electronic device.

[0112] In one example, after the electronic device is turned on, each host application can register the order service of the taxi application, so that when a taxi order is generated in the taxi application, the card display service will send a card display instruction 1 to these host applications. That is, when there are multiple registered host applications, the card display service sends a card display instruction 1 to each of the multiple host applications.

[0113] For example, taking multiple host applications including the desktop and the notification center as an example, after the card display service receives the card display notification from the taxi application, during the card display process, the card display service Figure 7 Path L1 in the example sends a card display instruction 1 to the desktop, and sends a card display instruction 1 to the notification center.

[0114] It should be noted that the above registration process can also be performed at other times, for example, when the taxi-hailing application is installed on the electronic device, or when the taxi-hailing application is updated, and the embodiments of the present application are not limited to this.

[0115] Next, taking any host application as an example, the processing flow after the host application receives the card display instruction 1 sent by the card display service is explained, and the processing flows related to other host applications are similar.

[0116] S813. The host application sends a card display instruction 2 to the Host AAR. The card display instruction 2 carries hostInfo, size, cornerRadius, istransparent, isliveBlur, and cardInstanceId.

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

[0118] The card size information (ie, size) is used to indicate the size of the card displayed by the host application. The card size information includes the card width and the card height, and the unit is PX, that is, pixels.

[0119] The card corner radius information (ie, cornerRadius) is used to indicate the corner radius of the card displayed by the host application. The unit of the card corner radius information is PX, that is, pixel.

[0120] The transparency indication information (i.e., istransparent) can be used to indicate whether the card view obtained from the taxi application needs to be set to transparent. For example, when istransparent is true, it is used to indicate that the card view needs to be set to transparent. When istransparent is false, it is used to indicate that the card view does not need to be set to transparent, or a card view with a background is required.

[0121] The dynamic blur indication information (i.e., isliveBlur) is used to indicate whether the card needs to be displayed with a dynamic blur effect. For example, when isliveBlur is true, it is used to indicate that dynamic blur is required, and when isliveBlur is false, it is used to indicate that dynamic blur is not required. The dynamic blur effect means that when a card is displayed on the interface of a host application (such as a desktop), the user can vaguely see the interface color of the host application (such as a desktop) from the area where the card is located, that is, the area where the card is located can vaguely show the color of the interface of the host application. For example, the WeChat notification card displayed on the desktop is a real-time card, which has a dynamic blur effect.

[0122] In the embodiment of the present application, different host applications display different card contents and display effects when displaying cards. For example, for a taxi order A of a taxi application, Figure 1 As shown, the desktop 110 of the electronic device can display a card 111 corresponding to the taxi order A, and the card 111 includes an icon 112 of the taxi application, a text 113 of "License plate number XXX·Arrival in about 2 minutes", a text 114 of "Master Zhang·White", and a call control 115. The size and rounded corner size of the card 111 are shown in FIG. Figure 1 As shown, card 111 has a motion blur effect.

[0123] For example, for the same taxi order A, Figure 2As shown in FIG. 1(b), the notification center 120 of the electronic device may display a card 121 corresponding to the taxi order A. The card 121 may include an icon 122 of the taxi application, text 123 of "License plate number XXX·Arriving in about 2 minutes", text 124 of "Master Zhang·White", and the card 121 may also include a progress bar 125. The size and rounded corner size of the card 121 are shown in FIG. Figure 2 As shown in FIG. 1 (b), the size of card 121 is different from that of card 111, the size of the rounded corners of card 121 is also different from that of card 111, and card 121 has a static blur effect rather than a dynamic blur effect.

[0124] For example, for the same taxi order A, Figure 3 As shown in FIG. 1(b), the lock screen interface 130 of the electronic device may display a card 131 corresponding to the taxi order A, which may include an icon 132 of the taxi application, text 133 of "License plate number XXX·Arriving in about 2 minutes", and text 134 of "Master Zhang·White". The card 131 may also include a progress bar 135. The size and rounded corner size of the card 131 are shown in FIG. Figure 3 As shown in FIG. 1 (b), the size of the card 131 is different from that of the card 111, the size of the rounded corners of the card 131 is also different from that of the card 111, and the card 131 may have a background (eg, white).

[0125] For example, for the same taxi order A, Figure 4 As shown in FIG. 1( b ), the screen-off interface 140 of the electronic device may display a card 141 corresponding to the taxi order A. Figure 1 Compared with the card 111 shown in FIG. 1 , the card 141 is a card capsule. The card 141 (i.e., the card capsule) may include some information related to the taxi order (e.g., the icon 142 of the taxi application, the text 143 of "license plate number XXX"). The size and rounded corner size of the card 141 are as follows: Figure 4 As shown in FIG. 1 (b), the size of card 141 is different from that of card 111, the size of the rounded corners of card 141 is also different from that of card 111, and card 141 may also have a background (eg, white).

[0126] It can be seen that for the same taxi order of the taxi application, different host applications require different card view specifications and styles, such as different requirements for card size, corner radius, transparency, dynamic blur, etc. Therefore, after receiving the card display instruction 1, the host application can add card setting parameters related to the card view in the card display instruction 2 according to its own needs, and issue the card display instruction 2, for example, through Figure 7Path L2 in the card display instruction 2 is sent to the Host AAR, so that the card kit can be used to configure the card view required by the host application according to these card setting parameters. Among them, these card setting parameters can be pre-generated by the host application, for example, they can be generated according to requirements when the host application is registered.

[0127] In an example, the host application may send the card display instruction 2 to the Host AAR by calling the showCard function in the Host AAR. For example, the host application may call the showCard(hostInfo, cardInstanceId, size, istransparent, isliveBlur, cornerRadius) function.

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

[0129] See also Figure 7 , Host AAR forwards the card display instruction 2 to the card management service through path L3. In one example, Host AAR can perform cross-process communication with the card management service through the system service, that is, Host AAR can send the card display instruction 2 to the card management service through the system service to request the card management service to display the card.

[0130] In one example, the Host AAR may send the card display instruction 2 to the card management service by calling the showCard function of the card management service. For example, the Host AAR calls the showCard(hostInfo, cardInstanceId, size, istransparent, isliveBlur, cornerRadius) function.

[0131] S815. The card management service determines AppClipInfo according to cardInstanceId.

[0132] according to Figure 8 It can be seen from the records of the illustrated embodiment that the card management service locally caches the mapping relationship between the card instance information (cardInstanceId) and the card provider information (AppClipInfo), so the card management service can determine the card provider information (AppClipInfo) based on the card instance information (cardInstanceId), so as to determine which application needs to display the card, or determine 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 taxi-hailing application according to AppClipInfo.

[0134] That is, the card management service determines the corresponding taxi application based on the card provider information (AppClipInfo). Then, see Figure 7 The card management service uses the system service through path L4 to send a card display instruction 2 to the card kit corresponding to the taxi-hailing application, and sends the host information (hostinfo), card size information (size), card corner information (cornerRadius), transparent indication information (isTransparent), dynamic blur indication information (isLiveBlur) and card instance information (cardinstanceId) to the card kit, so that the card kit obtains a card view of corresponding specifications according to these card setting parameters.

[0135] In one example, the card management service may send the 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 may be called.

[0136] It should be noted that, since the Host AAR corresponding to each host application sends a card display instruction to the card management service, after the card management service receives the card display instruction sent by the Host AAR corresponding to each host application, the card management service can send a card display instruction to the card kit corresponding to the taxi application according to the card provider information carried in each card display instruction. Different card display instructions carry the card setting parameters indicated by different host applications, that is, the card management service sends the host information (hostinfo), card size (size), card corner information (cornerRadius), transparent indication information (isTransparent), dynamic blur indication 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 specifications according to the card setting parameters indicated by each host application.

[0137] S817. The card kit determines a first embedded window according to hostinfo. The first embedded window is used for the card kit to embed a card view of the taxi-hailing application.

[0138] The first embedded window is SurfaceControlViewHost. SurfaceControlViewHost is created by CardKit and can be understood as a window belonging to the taxi-hailing application. SurfaceControlViewHost includes the SurfaceControl layer, which is the real layer used to render the card view. So it is not difficult to understand that the SurfaceControlViewHost is a window for CardKit to embed the card view of the taxi-hailing application. For different host applications, CardKit can create a corresponding first embedded window.

[0139] As an example of the present application, the card kit determines the specific implementation of the first embedded window according to hostinfo, which may include: according to hostinfo, querying whether there is a valid layer data packet (i.e., SurfacePackage) in the cache of the electronic device, and the layer data packet includes the SurfaceControl layer in the SurfaceControlViewHost, that is, the layer data packet exists in the SurfaceControlViewHost. If there is a valid layer data packet, obtain the first embedded window corresponding to the valid layer data packet. If there is no valid layer data packet, create the first embedded window.

[0140] In one embodiment, the host application of the electronic device had displayed the card corresponding to the taxi order before requesting to display the card corresponding to the taxi order. However, due to problems such as a crash in the host application, the card disappeared, causing the electronic device to trigger a display request for the card corresponding to the order card. In this case, the layer data packet of the first embedded window created last time will exist in the cache of the electronic device, and there will be a mapping relationship with hostinfo. Therefore, when determining the first embedded window, the card kit can query whether there is a valid layer data packet based on hostinfo, so as to determine whether the SurfaceControlViewHost corresponding to hostinfo needs to be recreated.

[0141] In one possible case, when there is a layer data packet of the first embedded window corresponding to hostinfo in the cache of the electronic device, the card kit can query the status information of the layer data packet. When the status information indicates that the layer data packet of the cached first embedded window is valid, for example, the status information is the first value (true), the card kit can subsequently directly use the first embedded window to embed the card view; when the status information indicates that the layer data packet of the cached first embedded window is invalid (such as an exception), for example, the status information is the second value (false), the card kit can create the first embedded window corresponding to hostinfo. Afterwards, the card kit can save the mapping relationship between hostinfo and the created first embedded window.

[0142] In another possible case, the layer data packet of the first embedded window corresponding to hostinfo does not exist in the cache of the electronic device. In this case, the card kit can recreate a first embedded window, and then the card kit can save the mapping relationship between hostinfo and the created first embedded window, so that when the host application crashes during the card display process, the card kit can query the first embedded window corresponding to hostinfo according to the mapping relationship next time, avoiding the need to recreate the first embedded window corresponding to hostinfo next time.

[0143] Of course, it should be noted that the above-mentioned specific implementation of determining the first embedded window based on hostinfo is only exemplary. In another example, after receiving the 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, where the layer data packet includes the SurfaceControl layer of the first embedded window.

[0145] Because the SurfaceControl layer has not yet rendered the card view requested by the taxi application, the SurfaceControl layer is empty at this time.

[0146] In some examples, in order to avoid the host application displaying cards of other applications during the process of the card kit obtaining the card view from the TaxiProvider of the taxi application, before the card kit obtains the card view from the TaxiProvider of the taxi application, the card kit can send the SurfaceControl layer in the determined first embedded window to the card management service through a layer data packet, and then send it to the Host AAR through the card management service, so that the Host AAR mounts (or embeds) the SurfaceControl layer into the second embedded window of the host application, and then uses the SurfaceControl layer for placeholder. Among them, the second embedded window is created by the Host AAR, which can be understood as a window belonging to the host application. The second embedded window is used for the HostAAR to mount the SurfaceControl layer in the SurfaceControlViewHost. In one example, the second embedded window is DynamicCardHostView.

[0147] In one possible case, when there is a valid layer data packet in the cache of the electronic device, the card kit can send the layer data packet of the cached first embedded window to the card management service by calling back the OnSurfacePackageCreated function. For example, the card kit calls back the OnSurfacePackageCreated(cardinstanceId, SurfacePackage) function, where the cardinstanceId is passed when calling back the OnSurfacePackageCreated function to facilitate the host application to determine which card corresponding to the taxi order is displayed.

[0148] In another possible case, when there is no valid layer data packet in the cache of the electronic device, the card kit can create a listening event in the process of creating the first embedded window, and the listening event is used to listen to whether the first embedded window has been created. When it is monitored that the first embedded window has been created, the card kit can call back the OnSurfacePackageCreated function to send the SurfaceControl layer in the created first embedded window to the card management service through the layer data packet.

[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 back the OnSurfacePackageChanged function, so as to notify the Host AAR through the card management service to replace the mounted SurfaceControl layer, that is, replace it with the changed SurfaceControl layer.

[0150] S819. The card management service sends a layer data packet to the Host AAR.

[0151] That is, 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 back the OnSurfacePackageCreated function. For example, the card management service calls back the OnSurfacePackageCreated(cardinstanceId, SurfacePackage) function.

[0152] S820. Host AAR creates a second embedded window and mounts the SurfaceControl layer in the layer data packet to the second embedded window.

[0153] After receiving the layer data packet of the first embedded window, Host AAR creates a second embedded window (i.e., DynamicCardHostView) for embedding the SurfaceControl layer of the first embedded window. Afterwards, Host AAR obtains the SurfaceControl layer of the first embedded window from the layer data packet, and then mounts the SurfaceControl layer of the first embedded window on the second embedded window, that is, the SurfaceControl layer mounted in the second embedded window is the same layer as the SurfaceControl layer in the SurfaceControlViewHost of the taxi-hailing application. When the card view is rendered on the SurfaceControl layer of the first embedded window, it is rendered synchronously on the SurfaceControl layer of the second embedded window. Afterwards, Host AAR can also add a placeholder in the first embedded window, for example, the placeholder can be "Loading".

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

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

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

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

[0158] That is, after receiving the second embedded window with the SurfaceControl layer added, the host application adds the second embedded window with the SurfaceControl layer added to a preset position that the host application needs to display.

[0159] For example, if the host application is the desktop, Fig.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, the placeholder 1102 may also be imperceptible to the user, that is, during the card display process, the user may not be able to see the placeholder 1102 from the electronic device.

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

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

[0163] As mentioned above, Host AAR mounts the SurfaceControl layer of the first embedded window to the second embedded window through SurfaceView, and SurfaceView itself has a black background layer. Therefore, in one possible implementation, if the host application needs to achieve a semi-transparent or dynamic blur effect when displaying a card, after Host AAR embeds the SurfaceControl layer through SurfaceView, when the card view is subsequently rendered to the SurfaceControl layer, it is easy to cause the underlying black background layer to show through when displayed, for example Fig.10 As shown, the four rounded corners of the card are displayed in black. Therefore, when the host application defines the card setting parameters that indicate semi-transparency or dynamic blur, the Host ARR can indicate that the SurfaceView is currently a real-time card scene (i.e., dynamic blur), for example, by calling the setlsLiveClip(true) function. In this way, SurfaceView can set its own background layer to be transparent, for example, through the transaction.setAlpha(sf, 0) function to set transparency, to avoid the black background layer of SurfaceView from showing through when the card is displayed later.

[0164] S824: When a transparent card view is requested, the host application sets a background of a customized card view.

[0165] As an example of the present application, if the host application requests a transparent card view, the host application usually wants to customize the background of the card view, for example, the background may be set to black, translucent, static blur (such as the card displayed in the notification center has a static blur effect, such as the WeChat notification card displayed in the notification center is static blur), etc. Therefore, in the case where the host application requests a transparent card view, after adding the second embedded window with the SurfaceControl layer added to the position to be displayed, the host application can set a customized background view on the parent view (view) of the card, such as setting a black background view on the parent view. The parent view is a view in the host application that is used to accommodate the second embedded window with the SurfaceControl layer added.

[0166] It should be noted that, in the case where the host application requests a transparent card view, the embodiment of the present application is described by taking the host application setting a customized background after adding a second embedded window with a SurfaceControl layer as an example. In another example, it can also be set at other times, such as when creating a parent view, and the embodiment of the present application is not limited to this.

[0167] S825. The card kit sends a card view acquisition request to the card provider of the taxi-hailing application. The card view acquisition request carries the size.

[0168] The card view acquisition request is used to request to acquire the card view.

[0169] In one example, see Figure 7 After the card kit determines the card provider according to the card provider information, it can call the getview(size) function through path L5 to send a card view acquisition request to the TaxiProvider of the taxi 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 according to the card size information.

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

[0171] It should be noted that there is no strict execution order between S825 and S818. In one possible case, if there is a valid layer data packet in the cache of the electronic device, S825 can be executed after the card kit determines that there is a valid layer data packet. In another possible case, if there is no valid layer data packet in the cache of the electronic device, S825 can be executed after the card kit creates a new first embedded window.

[0172] S826. The card provider generates a corresponding card view according to the size.

[0173] In one example, TaxiProvider can determine the card view size, card content, and layout of the card content based on the card size information, and can also determine what style of card view the host application currently requesting the card view needs. Therefore, after receiving the card size information, TaxiProvider can generate the card view required by the host application based on the card size information. The card view is a transparent view.

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

[0175] For example, taking the host application as the notification center, combined with Figure 2 As shown in (b) of FIG. 1 , TaxiProvider can generate a slice 121 according to the card size information (such as display height h2 and display width d2) indicated by the notification center and the data corresponding to the taxi order, that is, generate a card view corresponding to the notification center. Card 121 includes an icon 122 of the taxi application, text 123 of "License plate number XXX·Arrival in about 2 minutes", and text 124 of "Master Zhang·White". Figure 1 Compared to the illustrated card 111 , the card 121 may further include a progress bar 125 .

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

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

[0178] S828. The card kit sends a background view acquisition request to the card provider. The background view acquisition request carries size.

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

[0180] That is, in the embodiment of the present application, the card kit requests the TaxiProvider of the taxi application to provide a card view and a background view respectively, 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 later.

[0181] In one example, the card kit can send a background view acquisition request to TaxiProvider by calling the getDrawable(size) function, and send the card size information of the card view requested by the host application to TaxiProvider, so that TaxiProvider can provide a background view of corresponding specifications according to 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. The embodiment of the present application does not limit this.

[0183] S829. The card provider generates a corresponding background view according to the size.

[0184] The TaxiProvider of the taxi-hailing application generates a card view of this size, where one card view corresponds to one background view.

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

[0186] After the taxi app generates the background view, it sends it to the card kit.

[0187] It is worth mentioning that the card kit obtains the card view and the background view corresponding to the card view from the TaxiProvider of the taxi application, that is, the card view and the background view are separated, so that the card view and the background view can be processed separately according to the display requirements of the host application in the future, avoiding the need for the taxi application to adapt 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 taxi application, so that the TaxiProvider of the taxi application can provide the card view and background view of the style required by each host application according to the card size information indicated by each host application.

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

[0190] In order to enable the host application to achieve a dynamic blur effect when displaying the card, the card kit blurs the SurfaceControl layer in the first embedded window. In one example, the card kit can use the Android system native interface to set the SurfaceControl layer of the first embedded window to be blurred.

[0191] It should be noted that the above description is based on the example that the dynamic blur indication information indicates that dynamic blur is required. In another example, the dynamic blur indication information may also indicate that dynamic blur is not required. In this case, the following operation S830 is performed.

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

[0193] As mentioned above, the transparency indication information is used to indicate whether the card view needs to be set to transparent. The card kit indicates whether a transparent card view is needed based on the transparency indication information, and generates a card view with a background view or without a background view accordingly. In one possible case, the transparency indication information indicates that a transparent card view is needed. In this case, the card kit does not merge the card view with the background view. As an example and not a limitation, the card kit can delete the background view obtained from the TaxiProvider of the taxi application, that is, the background view does not need to be used. In another possible case, the transparency indication information indicates that an opaque card view is needed. In this case, the card kit merges the card view with the background view to obtain a card view with a background view.

[0194] S833. The card kit crops the rounded corners of the generated card view according to the card rounded corner information.

[0195] Exemplarily, assuming that the card corner radius information is c1, the card kit crops the four corners of the generated card view to the size of c1 to obtain a cropped card view.

[0196] It is worth mentioning that for different host applications, the card kit generates the card view required by each host application according to the display requirements of each host application, which can avoid the need for the taxi application to adapt itself.

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

[0198] That is, the card kit renders the cropped card view to 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 completed, 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 call back the onSurfaceViewRendered function through path L7 to send a rendering completion notification to the card management service, so as to notify the Host AAR through the card management service that the card view has been rendered to the SurfaceControl layer of the first embedded window. Furthermore, in order to facilitate the Host AAR to know which card view has been rendered, during the callback process, the card kit can also pass the cardInstanceId to the card management service through the callback function, such as the card kit calling back the onSurfaceViewRendered(cardInstanceId) function.

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

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

[0203] S837, Host AAR deletes placeholders.

[0204] Since the SurfaceControl layer in the first embedded window and the SurfaceControl layer in the second embedded window are the same layer, when the card view after cropping and other processing is added to the SurfaceControl layer of the first embedded window, the card view after cropping and other processing is also added to the SurfaceControl layer of the second embedded window. Therefore, after receiving the rendering completion notification, the Host AAR deletes the placeholder, for example, determines the corresponding second embedded window according to the cardInstanceId, and then deletes the placeholder in the second embedded window. In this way, the host application can successfully display the card view, thereby completing the display of the card of the taxi application.

[0205] According to the above implementation, the card can be successfully displayed on each host application. In this way, 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 the SurfaceControl layer is embedded in the first embedded window of the taxi-hailing application and the second embedded window of the host application, the card view of the taxi-hailing application is rendered on the SurfaceControl layer. Therefore, after the card view of the taxi-hailing application is displayed in the host application, when the taxi order changes, such as the progress of the taxi, the taxi 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 taxi order. In this case, the card view rendered on the SurfaceControl layer in the second embedded window is synchronously updated, thereby realizing the update of the card corresponding to the taxi order.

[0207] In an embodiment of the present application, in response to the generation of an order by the first application, a first card view of the first card related to the order and a background view of the first card view are obtained. According to the card setting parameters of the host application, the first card view and the background view are processed to generate a second card view, and then the second card view is displayed by the host application, thereby realizing the display of the first card. In this way, cards of different styles can be displayed by the host application without the need for the first application to adapt itself, which enriches the display effect of the card and improves the management efficiency of the card.

[0208] Furthermore, when the electronic device displays the notification information of the first application in the form of a card, the first application generates a card view, creates a first embedded window, and 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 to the SurfaceControl layer. In this way, the host application displays the second embedded window hanging under itself to realize the display of the card. Since the host application can realize the card realization by displaying the second embedded window instead of directly displaying the card view, the first application can create a card view including custom card elements according to its own needs. In this way, the notification information of the first application can be displayed to the user more effectively and intuitively.

[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 increase the speed of cross-process data transmission and realize 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 the embodiment of the present application is described by applying the provided method of displaying cards to a real-time card framework (i.e., SurfaceControlViewHost) as an example. In another example, the method can also be applied to an Android native card framework (i.e., AppWiget). For example, during the implementation process, the foreground view (i.e., card view) and background view of the card can be requested from the card provider of the taxi application, and then the card setting parameters of each host application are set based on the foreground view and background view to generate the style of the card required by each host application, so as to be displayed through the host application.

[0211] See also Fig.12 , Fig.12 is a flowchart of a method for displaying a card according to another exemplary embodiment. As an example but not a limitation, the method can be as follows: Figure 7 The electronic device shown may be executed and may mainly include part or all of the following contents:

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

[0213] Exemplarily, the first application is Fig. 9 In the illustrated embodiment, the taxi-hailing application program, the order is a taxi order.

[0214] The specific implementation of step S1201 may refer to steps S801 to S830 in the above embodiment.

[0215] In one example, before obtaining the first card view of the first card of the first application and the background view of the first card view, the electronic device may also obtain the first target layer in the first embedded window corresponding to the first application, and the first target layer is used to render the second card view and create a second embedded window of the second application. The first target layer is embedded in the second embedded window. A placeholder is added to the second embedded window in which the first target layer is embedded. The second embedded window in which the placeholder is added is added to the parent view of the second application, and the parent view is used to accommodate the second embedded window. For specific implementation, see Fig. 9 Steps S815 to S822 in the illustrated embodiment.

[0216] Exemplarily, the first target layer is the above Figure 8 and Fig. 9 The SurfaceControl layer in the illustrated embodiment. The second card view is a card view rendered in the SurfaceControl layer. The second application may be the above-mentioned host application, for example, the second application may be, but is not limited to, the desktop, notification center, lock screen, off screen, or negative one screen.

[0217] It is worth mentioning that before displaying the first card, the electronic device mounts the first target layer to the second embedded window to take up place, thereby preventing the second application from displaying cards of other applications before displaying the first card.

[0218] In one example, 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, obtain the first target layer in the first embedded window. If the first embedded window does not exist in the electronic device, create the first embedded window, and obtain the first target layer from the created first embedded window. For specific implementation, see Fig. 9 S817 in the illustrated embodiment. In this way, when there is a valid first embedded window, the first embedded window can be used directly to avoid the need to recreate it, which can improve the processing speed. Of course, when there is no valid first embedded window, the first embedded window is created to render the second card view through the first embedded window, so that the card can be displayed synchronously in the host application through the embedded window. For details, please refer to the above.

[0219] In one example, when the second application requests to display the first card as a dynamic blur effect, after adding the second embedded window with the placeholder added to the parent view of the second application, the second target layer in the second embedded window is set to transparent, and the second target layer is a layer used to embed the first target layer into the second embedded window. Exemplarily, the second target layer is a layer of SurfaceView.

[0220] It is worth mentioning that when the second application requests to display the first card with a dynamic blur effect, by setting the second target layer to be transparent, the color of the second target layer is avoided from showing through when displaying the first card, thereby affecting the display effect of the first card.

[0221] In one example, when the second application requests a transparent second card view, after the second embedded window with a placeholder added is added to the parent view of the second application, a background layer customized by 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 a customized background color, so a custom background layer is set on the parent view so that after rendering the second card view to the first target layer and removing the placeholder, 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 according to card setting parameters of a second application, the first card view, and the background view. The second application is an application for displaying cards in an electronic device.

[0224] In one example, the card setting parameters include at least one of card corner rounding 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, wherein 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 vaguely show the interface color of the second application.

[0225] In the case where the card setting parameters include card corner fillet information, transparency indication information, and dynamic blur indication information, the specific implementation of S1202 may include: when the dynamic blur indication information indicates that the first card needs to be displayed as a dynamic blur effect, a second card view is generated according to the card corner fillet information and the first card view, and the first target layer is blurred. When the dynamic blur indication information indicates that the first card does not need to be displayed as a dynamic blur effect, a second card view is generated according to the card corner fillet information, the transparency indication information, the first card view, and the background view.

[0226] In this way, according to the card setting parameters, a second card view is generated based on 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 adapt itself, thereby improving the application applicability of the card display method.

[0227] In a possible case, 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, and the cropped first card view is determined as the second card view.

[0228] In this way, when the dynamic blur indication information 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 required, so 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 displayed.

[0229] In another possible case, when the dynamic blur indication information indicates that the first card does not need to be displayed as a dynamic blur effect, if the transparent indication information indicates that the second card view needs to be transparent, 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 transparent indication information indicates that the second card view does not need to be transparent, 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.

[0230] In this way, when the dynamic blur indication information indicates that the first card does not need to be displayed with a dynamic blur effect, the background style of the card view required by the second application is determined according to the transparent indication information, and then the rounded corners are cropped according to the card 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 Fig. 9 S831 to S834 in the illustrated embodiment.

[0232] In one example, the card setting parameters also include card size information, so that when obtaining the first card view and the background view, 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 according to the card size information, so as to obtain the second card view that meets the size display requirements of the second application.

[0233] It should be noted that the above-mentioned 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 is only exemplary. In another example, its specific implementation may also include other methods. For example, the card setting parameters may also include other forms, or the first card view and the background view may be processed first according to the transparent indication information, and then processed according to the dynamic blur indication information and the card rounded corner information. The embodiments of the present application are not limited to this.

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

[0235] In one example, the specific implementation of S1203 may include: rendering the second card view to the first target layer of the second embedded window, deleting the placeholder in the second embedded window, and displaying the second embedded window in the interface of the second application while displaying the interface of the second application, so as to display the first card in the interface of the second application.

[0236] In this way, by rendering the second card view into the first target layer and deleting the placeholder, the first card is displayed, that is, the first card with a custom style is displayed through the second application.

[0237] In an embodiment of the present application, in response to the generation of an order by the first application, the first card view of the first card related to the order and the background view of the first card view are obtained. According to the card setting parameters of the second application, the first card view and the background view are processed to generate a second card view, and then the second card view is displayed by the second application, thereby realizing the display of the first card. In this way, cards of different styles can be displayed by the second application without the need for the first application to adapt itself, which enriches the display effect of the card and improves the management efficiency of the card.

[0238] Fig.13 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Fig.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, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. Among them, the sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light 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 to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0240] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0241] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0242] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, 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 understandable that the interface connection relationship between the modules illustrated in the embodiment of the present application is only a schematic illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0245] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. While the charging management module 140 is charging the battery 142, it may also power the electronic device 100 through the power management module 141.

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

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

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

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

[0250] The external memory 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 memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0251] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created by the electronic device 100 during use (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0252] It should be noted that when the electronic device is in the form of a mobile phone, a tablet computer, a handheld computer, etc., the structure of the electronic device may include Fig.13 The structure shown in the figure is less than Fig.13 More structures are shown in .

[0253] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of 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, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (such as: coaxial cable, optical fiber, data subscriber line (Digital Subscriber Line, DSL)) or wireless (such as: infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server or data center that includes one or more available media integrations. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a digital versatile disc (DVD)), or a semiconductor medium (such as a solid state disk (SSD)).

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

Claims

1. A method for displaying a card, characterized in that: Applied to electronic equipment, the method comprises: In response to an order being generated by a first application, obtaining a first card view of a first card of the first application and a background view of the first card view, wherein the first card is used to display information related to the order; generating a second card view according to a card setting parameter of a second application, the first card view and the background view, wherein the second application is an application for displaying cards in the electronic device; The second card view is displayed through the second application to display the first card.

2. The method according to claim 1, characterized in that Before obtaining the first card view of the first card of the first application and the background view of the first card view, the method further includes: Obtain a first target layer in a first embedded window corresponding to the first application, where the first target layer is used to render the second card view; Creating a second embedded window of the second application; Embedding the first target layer into the second embedded window; Adding a placeholder in the second embedded window in which the first target layer is embedded; The second embedded window with the placeholder added thereto is added to the parent view of the second application, and the parent view is used to accommodate the second embedded window.

3. The method according to claim 2, characterized in that The displaying the second card view by the second application to display the first card includes: Rendering the second card view into the first target layer of the second embedded window; Deleting 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.

4. The method according to claim 2 or 3, characterized in that The obtaining of the first target layer in the first embedded window corresponding to the first application comprises: Querying whether the first embedded window exists in the electronic device; When the first embedded window exists in the electronic device, acquiring the first target layer in the first embedded window; When 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.

5. The method according to any one of claims 2 to 4, characterized in that: The card setting parameters include card rounded corner information, transparency indication information, and dynamic blur indication information, wherein 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, wherein 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 vaguely show the interface color of the second application; The generating a second card view according to 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 according to the card rounded corner information and the first card view, and the first target layer is blurred; When the dynamic blur indication information indicates that the first card does not need to be displayed with a dynamic blur effect, the second card view is generated according to the card corner radius information, the transparency indication information, the first card view and the background view.

6. The method according to claim 5, characterized in that When the dynamic blur indication information indicates that the first card needs to be displayed with a dynamic blur effect, generating the second card view according to the card 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 determined as the second card view.

7. The method according to claim 5, characterized in that When the dynamic blur indication information indicates that the first card does not need to be displayed as a dynamic blur effect, generating the second card view according to the card rounded corner information, the transparency indication information, the first card view and the background view includes: In a case where the dynamic blur indication information indicates that the first card does not need to be displayed with a dynamic blur effect, if the transparent indication information indicates that the second card view needs to be transparent, 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, 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.

8. The method according to claim 5, characterized in that The card setting parameters also include card size information; In response to the order of the first application being generated, obtaining a first card view of a first card of the first application 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 according to the card size information.

9. The method according to any one of claims 2 to 8, characterized in that After adding the second embedded window with the placeholder added thereto into the parent view of the second application, the method further includes: When the second application requests to display the first card as a dynamic blur effect, setting a second target layer in the second embedded window to be transparent, the second target layer being a layer used to embed the first target layer into the second embedded window; 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 vaguely show the interface color of the second application.

10. The method according to any one of claims 2 to 8, characterized in that After adding the second embedded window with the placeholder added thereto into the parent view of the second application, the method further includes: In the case where the second application requests a transparent second card view, a background layer customized by the second application is set on the parent view.

11. The method according to any one of claims 1 to 10, characterized in that The second application is the desktop, notification center, lock screen, off screen or negative one screen.

12. An electronic device, characterized in that: The electronic device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 11 when executing the computer program.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the method according to any one of claims 1 to 11.

Images