CN115033331A

CN115033331A - Card display method and related product

Info

Publication number: CN115033331A
Application number: CN202210743655.2A
Authority: CN
Inventors: 刘宏侠; 彭新林
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2022-06-28
Filing date: 2022-06-28
Publication date: 2022-09-09

Abstract

The embodiment of the application discloses a card display method and a related product, wherein the method comprises the following steps: displaying a minus one screen in response to a first operation; acquiring protocol data and card data of the target application in the negative one screen; analyzing the protocol data, determining the card type of a target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative screen according to the card type; displaying the card data in the target card, wherein the card data comprises at least one of: video data, animation data, text data, and picture data. By adopting the method and the device, the card layout diversification can be favorably realized, the video data or animation data and the like can be displayed through the target card, and the card display richness can be favorably improved.

Description

Card display method and related product

Technical Field

The application relates to the technical field of electronic equipment, in particular to a card display method and a related product.

Background

With the progress of multimedia technology, the application range of electronic equipment is wider and wider, and the corresponding functions of the electronic equipment are richer and richer. For example, the application functions and information may be integrated into one interface through a negative screen to help the user obtain information in the application program in time through the negative screen, for example, different application functions may be provided for the user through a card, for example, information such as cate, movie, travel and the like may be searched, or information such as news, stock market conditions, weather conditions and the like may be displayed. The user can add the card corresponding to the application program through the negative screen, but the current card is low in richness, usually displays some text information, and cannot support the display of video software.

Disclosure of Invention

The embodiment of the application provides a card display method and a related product, which can determine the card type and the card layout between a negative screen and a target application through protocol data so as to realize the layout of target cards of different target applications, is favorable for realizing the diversification of the card layout, realizes the display of video data or animation data and the like, and is favorable for improving the richness of card display.

In a first aspect, an embodiment of the present application provides a card display method, where the method includes:

displaying a minus one screen in response to a first operation;

acquiring protocol data and card data of the target application in the negative one screen;

analyzing the protocol data, determining the card type of a target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative screen according to the card type;

displaying the card data in the target card, wherein the card data comprises at least one of: video data, animation data, text data, and picture data.

In a second aspect, an embodiment of the present application provides a card display apparatus, which is applied to an electronic device, and the apparatus includes: a display unit, an acquisition unit, and a layout unit, wherein,

the display unit is used for responding to a first operation and displaying a negative screen;

the acquisition unit is used for acquiring protocol data and card data of the target application in the negative one screen;

the layout unit is used for analyzing the protocol data, determining the card type of a target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative one screen according to the card type;

the display unit is further configured to display the card data in the target card, where the card data includes at least one of: video data, animation data, and text data.

In a third aspect, an embodiment of the present application provides an electronic device, including a processor, a memory, a communication interface, and one or more programs, where the one or more programs are stored in the memory and configured to be executed by the processor, and the program includes instructions for executing steps in any method of the first aspect of the embodiment of the present application.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, where the computer-readable storage medium stores a computer program for electronic data exchange, where the computer program causes a computer to perform some or all of the steps described in any one of the methods in the first aspect of the embodiment of the present application.

In a fifth aspect, the present application provides a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause a computer to perform some or all of the steps as described in any one of the methods of the first aspect of the embodiments of the present application. The computer program product may be a software installation package.

It can be seen that, in the embodiment of the present application, in response to the first operation, a negative one screen is displayed; acquiring protocol data and card data of the target application in the negative one screen; analyzing the protocol data, determining the card type of a target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative screen according to the card type; displaying the card data in the target card, wherein the card data comprises at least one of: video data, animation data, text data, and picture data. So, accessible agreement data realizes confirming to card type and card overall arrangement between burden a screen and the target application to the realization is favorable to realizing that the card overall arrangement is diversified to the overall arrangement of the target card of different target application, and realizes the show to video data or animation data etc. through the target card, is favorable to improving the richness that the card shows.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.

Fig. 1 is a schematic structural diagram of a card display system according to an embodiment of the present application;

fig. 2 is a schematic flowchart of a card display method according to an embodiment of the present application;

FIG. 3A is a schematic diagram of a negative one-screen interaction with a target application according to an embodiment of the present application;

FIG. 3B is a schematic diagram of a negative one-screen interaction with a target application according to an embodiment of the present application;

FIG. 3C is a schematic diagram of a negative one-screen interaction with a target application according to an embodiment of the present application;

fig. 4 is a card diagram of a music application provided in an embodiment of the present application;

fig. 5 is a schematic flowchart of a card display method according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application;

fig. 7A is a block diagram illustrating functional units of a card display device according to an embodiment of the present disclosure;

fig. 7B is a block diagram illustrating functional units of a card display device according to an embodiment of the present disclosure;

fig. 7C is a block diagram illustrating functional units of a card display device according to an embodiment of the present disclosure.

Detailed Description

In order to make the technical solutions of the present application better understood, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present application without making any creative effort belong to the protection scope of the present application.

The terms "first," "second," and the like in the description and claims of the present application and in the above-described drawings are used for distinguishing between different objects and not for describing a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.

1) The electronic device may be a portable electronic device such as a cell phone, a tablet computer, a wearable electronic device with wireless communication capabilities (e.g., a smart watch, smart glasses), a vehicle mounted device, etc., that also includes other functionality such as personal digital assistant and/or music player functionality. Exemplary embodiments of the portable electronic device include, but are not limited to, portable electronic devices that carry an IOS system, an Android system, a Microsoft system, or other operating system. The portable electronic device may also be other portable electronic devices such as a Laptop computer (Laptop) or the like. It should also be understood that in other embodiments, the electronic device may not be a portable electronic device, but may be a desktop computer.

2) Negative one Screen (Assistant Screen): the interface appears after the main interface of the electronic equipment slides to the left. The card display system is used for displaying a plurality of cards corresponding to a plurality of applications (programs), and each application can correspond to one card.

3) Target card or card: the card can be added to a negative screen to provide different application functions of the corresponding application for the user, for example, information such as food, movies and tourism can be searched, or information such as news updates, stock market conditions and weather conditions can be displayed.

In the first section, an exemplary application scenario disclosed in the embodiments of the present application is described as follows.

Fig. 1 shows a schematic structural diagram of a card display system 100 to which the present application is applicable, where the system 100 may include: negative one-screen 101, card service module 102, and card data configuration module 103.

The negative one-screen 101 is connected to a card service module 102, and the card service module 102 can be connected to a card data configuration module 103. The negative one-screen 101 may interact with the card data configuration module 103 through the card service module 102.

The negative screen 101 may be used to display target cards corresponding to one or more target applications, and the card type of the target card may include at least one of the following: video type, animation type, text type, picture type, and the like. In the negative one-screen 101, the layout or card style of each target card may be determined according to its corresponding target application. The target application may include at least one of: video-type applications, music-type applications, shopping-type applications, take-away-type applications, stock-type applications, reading-type applications, etc., without limitation thereto.

Optionally, the negative screen 101 may provide a service of subscribing to a card, and may be used for a user to set or configure a system default or subscribe to a target card corresponding to a target application.

The card service module 102 is equivalent to a data channel, and can be connected to data interaction between the negative screen 101 and a target application, where the target application may include a third-party application, a fast application, a plug-in, and the like, and is not limited herein. The card service module 102 can be used for setting and managing a card life cycle corresponding to each target card; can be used for caching card data, and the card data can comprise at least one of the following: video data, animation data, text data, picture data, and the like, which are not limited herein; the data channel information is different from the card data, the corresponding data channel is different, the card data can be cached content data used for card display, and the data channel information is related to the life cycle of the card and can be used for storing instructions sent to a target application when the life cycle of the card changes.

Optionally, when the card lifecycle corresponding to a certain target card is updated, the card service module 102 may send a card lifecycle update instruction to the negative screen 101 for updating the card lifecycle, and cache the instruction for sending the instruction to the target service for synchronizing the card lifecycle corresponding to the target application.

The target application may provide data, such as protocol data, card data, and the like, to the negative screen 101 and/or the card service module 102 through the card data configuration module 103, which is not limited herein. Of course, the above card data may also be stored in the card service module 102 in advance, so as to be used for correspondingly updating the corresponding display data when the target card is displayed, and the like.

The card data configuration module 103 may be further configured to provide a card configuration function for one or more target applications, where the target applications may configure or set protocol data of their corresponding target cards through the card data configuration module 103, and the protocol data may be used to indicate card layout, card shape, card size, card color, control customization, card type, and the like of the target cards, which is not limited herein.

The card data configuration module 103 may also provide a protocol mode for one or more target applications to describe card layouts, custom animation effects, custom video playback, and the like of corresponding target cards, which is not limited herein.

It can be seen that, in the present application, the negative one-screen 101, the card service module 102, and the card data configuration module 103 may be configured to provide an interface or a platform for a target application, so as to support functions of animation effect customization, video playing, control customization, and the like of the target application, and provide a more complete card life cycle for a target card corresponding to the target application, so as to better manage the target card, so as to provide capabilities of refreshing layout, card rendering, and the like.

It should be noted that, in the present application, the plurality may refer to two or more, and details are not described later.

In the second section, the claims disclosed in the embodiments of the present application are presented below.

Referring to fig. 2, fig. 2 is a schematic flowchart of a card display method provided in an embodiment of the present application, and the card display method is applied to an electronic device.

S201, responding to the first operation, and displaying a negative screen.

The negative one-screen may be the negative one-screen 101 shown in fig. 1.

The first operation may be configured to trigger displaying of a negative screen, and the first operation may be set by a user or default of a system, which is not limited herein. For example, it may be that a swipe operation from another interface to a minus one-screen interface is detected, or another operation such as clicking or flipping up and down is detected. Of course, other triggering methods can be used to enter the negative one-screen interface.

S202, acquiring protocol data and card data of the target application in the negative screen.

The target application may refer to any application that achieves a card display agreement with a negative screen of the electronic device, and may be at least one of the following applications: video-type applications, music-type applications, shopping-type applications, take-away-type applications, stock-type applications, reading-type applications, etc., without limitation thereto.

The protocol data can be used for describing protocol contents set in advance by the target application, such as card layout, card shape, card size, card color, control customization, card type and the like. The protocol data can be a description file in json format; the content specifically included in the protocol data may be determined according to the card type.

For example, for a target card of an animation type, the protocol data may further include an animation effect, which may be embodied by a progress bar, a rotating optical disc, or the like.

For example, if the card data is video data, the card data may be data for video playing, and may be buffered in advance in the card data configuration module shown in fig. 1, so that the video data is played through the target card after the card is displayed.

S203, analyzing the protocol data, determining the card type of the target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative screen according to the card type.

The protocol specification of the protocol data can be set by a user or defaulted by a system, and is not limited herein; the protocol specification can be used to define the protocol content included in the protocol data, and the protocol format, presentation mode, etc. corresponding to the protocol content.

Wherein the card type may include at least one of: video type, animation type, text type, picture type, etc., without limitation.

When the target card corresponding to the target application is created for the first time, the corresponding target card can be generated through the card type and the protocol data; if the target card corresponding to the target application is not created for the first time, the target card is arranged on the negative screen according to the card type, so as to embody the functional effect of the target application in the style of arranging the target card, for example, the functional effect may be a video effect or an animation effect, and the like, which is not limited herein.

For example, a target control corresponding to the template application may be obtained by parsing the protocol data, where the control may be a native control or a custom control, and further, a function and an event capability may be obtained according to the target control extension, for example, the function may be a video capability or an animation capability, and further, the generated target control and function (for example, an animation effect) may be rendered and laid out in a target card through the target card, and then the target card is displayed on a negative screen.

S204, displaying the card data in the target card, wherein the card data comprises at least one of the following data: video data, animation data, text data, and picture data.

The card data can be displayed in the target card after layout, so that video data or animation data and the like can be displayed through the target card.

Therefore, in this example, the protocol data and the card data of the target application in the negative one-screen can be acquired while the negative one-screen display is triggered, the layout of the target card and the card data displayed in the target card can be obtained, and when the subsequent card life cycle of the target card indicates that the display state of the target card is switched from the invisible state to the visible state, it is beneficial to ensure that the target card displays the latest layout or the latest card data, so that the user experience can be improved.

Optionally, the following scenario is addressed: when the electronic equipment detects that the user is switched from the video application A to the negative screen, the application A has a display protocol with the negative screen, and a card A can be displayed on the negative screen to display the video data of the application A; then, the protocol data and the card data corresponding to the application a may be acquired, where the card data may be video data displayed in the next N seconds of the application a actively acquired by the negative one screen (the condition may also be defined according to the protocol data), and then, the protocol data may be parsed to obtain a card layout of the card a and a card type that is a video type, and the card a may be laid out in the negative one screen according to the card layout according to the card type, so as to be used for displaying the video data of the next N seconds corresponding to the application a. Therefore, when the user switches the application A to the background, the video data corresponding to the application A can still be continuously played through the target card so as to remind the user that the current application A is playing the video data, so that the function of the card A is expanded, the online video playing function is realized through one negative screen, and the improvement of user experience is facilitated.

It can be seen that the card display method described in the embodiment of the present application, in response to the first operation, displays a negative screen; acquiring protocol data and card data of the target application in the negative one screen; analyzing the protocol data, determining the card type of a target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative screen according to the card type; displaying the card data in the target card, wherein the card data comprises at least one of: video data, animation data, text data, and picture data. So, accessible agreement data realizes the affirmation to card type and card overall arrangement between burden a screen and the target application to the realization is favorable to realizing card overall arrangement diversification to the overall arrangement of the target card of different target applications, and realizes the show to video data or animation data etc. through the target card, is favorable to improving the richness that the card shows.

In a possible example, before the parsing the protocol data and determining the card type of the target card corresponding to the target application, the method further includes the following steps: determining a card life cycle of the target card, wherein the card life cycle is controlled by a first instruction, a second instruction, a third instruction and a fourth instruction, the first instruction is used for indicating card creation, the second instruction is used for indicating that the display state of the target card is switched from an invisible state to a visible state, the third instruction is used for indicating that the display state of the target card is switched from the visible state to the invisible state, and the fourth instruction is used for indicating that the card is deleted; managing protocol data of the target card according to the card life cycle; or, according to the life cycle of the card, the target application is helped to complete the service requirement.

The target card corresponding to each target application may have its own card life cycle, and the card life cycle may be set by the card service module 102 shown in fig. 1.

Wherein, the card life cycle can be described by a plurality of instructions, and the card life cycle can comprise at least one of the following: the first instruction, the second instruction, the third instruction, the fourth instruction, etc., are not limited herein. The target card can be managed in various states (including a visible state, an invisible state, a deleted state, a setup state and the like, wherein the visible state and the invisible state can be unified into a display state in the application) through the first instruction, the second instruction, the third instruction and the fourth instruction.

After the card service module 102 initially creates the target card of the target application, the card service module 102 may send a first instruction to the target application through the card data configuration module 103 to notify the target application that creating the target card is completed; the second instruction is used for indicating that the display state of the target card is switched from the invisible state to the visible state, the card service module 102 can pull up the target application through the second instruction and send the second instruction to the target application through the card data configuration module 103 to notify the target application that the target card is switched from the invisible state to the visible state at the moment, if the life cycle of the card changes, data updating or data refreshing or data caching and the like may need to be performed on card data or protocol data to prepare for next card layout and/or card data updating in the target card; the third instruction is used to indicate that the display state of the target card is switched from the visible state to the invisible state, and the card service module 102 may send the third instruction to the target application through the card data configuration module 103; the fourth instruction is used for indicating that the card is deleted and the target card is in a deleted state, and sending the fourth instruction to the target application through the card data configuration module 103 so as to notify that the target card corresponding to the target application is deleted, which is beneficial to helping the target to release the corresponding resource in time.

As can be seen, in this example, the management of the target card in various states can be realized through the card lifecycle, and under different conditions, different instructions (for example, the first instruction, the second instruction, the third instruction, and the fourth instruction) sent to the target application are triggered to pull up the target application, so that the target application is in a background state to update data in real time, or release data in time, which is beneficial to better managing the target card in a negative screen, so as to realize multi-card management.

In one possible example, the method for determining the card life cycle of the target card comprises the following steps: if the target card is in a first creation state, sending the first instruction to the target application; in response to a second operation, switching the display state of the target card from the invisible state to the visible state, and sending the second instruction to the target application so that the target application is in a background state; responding to a third operation, switching the display state of the target card from the visible state to the invisible state, and sending a third instruction to the target application; and responding to a fourth operation, deleting the target card and sending the fourth instruction to the target application.

The second operation, the third operation and/or the fourth operation are different from the first operation, and the second operation, the third operation and/or the fourth operation may be set by a user or default, which is not limited herein. The operations corresponding to the second operation, the third operation and the fourth operation may be different or the same.

For example, as shown in fig. 3A, the schematic diagram of interaction with a target application is a negative one-screen, where the negative one-screen includes a target card a, a target card 1, and a target card 2; the target card 1 displays information such as played songs, singers and progress bars of music target applications in an animation state, the target card 2 can be used for displaying news segments of the news target applications, the target card A can be used for displaying tasks planned by a user today, when the electronic equipment detects that the user slides downwards for one negative screen, the target card A gradually slides out of the screen and is out of the display range of the current negative screen, namely the target card A is changed from within the display range of the negative screen to outside the display range, at the moment, as the target card A marks out the display range, the negative screen can be adapted to another target card B in the uppermost display area, and the target card B is used for displaying motion data (including motion mileage, motion burning calories, today motion completion amount and the like) of the user; determining that the display state of the target card A is switched from a visible state to an invisible state, and then the electronic equipment or the negative screen can send a third instruction to the target application A corresponding to the target card A; as shown in fig. 3B, which is an interaction diagram of a negative one-screen and target application, when compared with fig. 3A, the application a draws out a display range of the negative one-screen, where the negative one-screen includes a target card B, a target card 1, and a target card 2, and the target card B is used to display exercise data (including exercise mileage, exercise burning calories, today's exercise completion amount, etc.) of the user; the target card B is gradually changed from the outside of the display range of the negative one screen to the inside of the display range, the display state of the target card B can be determined to be switched from the invisible state to the visible state, and the negative one screen can send a second instruction to the target application B corresponding to the target card B; as shown in fig. 3C, the negative one-screen interaction schematic diagram with the target application is shown, where the negative one-screen interaction schematic diagram includes a target card B, a target card 1, and a target card 2, and when the electronic device detects that the user presses the target card 1 for a long time, the target card 1 may be deleted in the negative one-screen interaction schematic diagram, and the fourth instruction is sent to the target application 1 corresponding to the target card 1 to notify that the target application 1 has deleted the corresponding target card 1.

In a possible example, the method for assisting the target application to complete the business requirement according to the card lifecycle may further include the following steps: if the display state of the card is determined to be switched from the invisible state to the visible state, determining the configuration information of the target card; if the configuration information indicates that the target card supports active refreshing, determining a refreshing interval between the previous sending of the second instruction by the target card and the current sending of the second instruction, and marking the current sent second instruction in an effective state; if the refresh interval is smaller than or equal to the minimum time interval, determining a target instruction sent to the target application, and putting the target instruction into a message queue, wherein the message queue is used for sending the target instruction to the target application, and the target instruction is used for completing the service requirement of the target application.

In this example, if the card service module 102 shown in fig. 1 detects a refresh state instruction that is sent by the target application and needs to refresh its own corresponding display data, the target instruction may be generated when the card life cycle of the target card changes (for example, if it is detected that the display state of the target card is switched from the invisible state to the visible state, etc.), and the update of the display data in the target application is implemented through the target instruction and the message queue.

Wherein, the configuration information may include at least one of the following: whether the target card supports active refresh, a corresponding minimum time interval in the case of active refresh, and the like, are not limited herein.

The card service module 102 records the time for sending the second command each time.

The minimum time interval may be set by the user or default by the system, and is not limited herein. The minimum time interval can be used for evaluating whether the target application needs to update or refresh the display data at the moment, and when the time interval for sending the second instruction twice is smaller than or equal to the minimum time interval, the steps of sending the target instruction and the like can be triggered to ensure that the target application realizes the service requirement of the target application, for example, when a user switches from minus one screen to the target application, the display data of the target application can be ensured to be consistent with the card data in the target card, and can be used for refreshing the display data of the target application.

Optionally, the target instruction may be used to send to the target application for pulling up the target application to enable the target application to fulfill its desired business requirements, for example, refreshing the UI data of the display page, updating the display data in the background, determining the current video playing progress of the user, determining the news segment currently read by the user, and so on.

In specific implementation, if the target application needs to refresh data corresponding to the target card, and when the display state of the target card is switched from the invisible state to the visible state, at this time, a negative screen needs to send a second instruction to the target application, before sending the second instruction, it may be further determined that the target card supports active refresh, and a difference (time interval) between sending times of sending the second instruction at the current time and sending the second instruction at the last time is determined as a refresh interval, and when the refresh interval is smaller than or equal to a minimum time interval, it is determined that the target instruction needs to be sent to the target application.

In this case, a second instruction for switching the display state of the target card from the invisible state to the visible state needs to be sent to the target application, so that data preparation can be directly performed in the callback process of the second instruction, that is, storing the target instruction in the message queue, if the card service module 102 shown in fig. 1 detects a refresh status instruction sent by the target application and requiring refreshing of its own corresponding display data, it indicates that the target application needs to implement data refresh, the target application may pull the target instruction from the message queue, and the card service module 102 may push the card data (which may be the cache data displayed by the current target card) corresponding to the target card corresponding to the second instruction to the target application, so as to implement the refresh of the display data in the target application, or directly pulling the card data corresponding to the target application to realize the business requirement of the user.

As can be seen, in this example, the electronic device may directly perform data preparation in the callback process of the second instruction while the life cycle of the card changes and the second instruction is sent, that is, directly store the target instruction for the service requirement of the target application in the message queue, and when the target application needs data refreshing or data updating, the target application may directly pull the card data corresponding to the target application through the message queue to meet the service requirement of the target application.

In one possible example, the managing the protocol data of the target card according to the card lifecycle includes: responding to a refresh state instruction sent by the target application, and receiving target data corresponding to the refresh state instruction; judging whether the target card supports active refreshing; if the target card is determined to support the active refreshing, updating protocol data of the target card into the target data; if the target card is determined not to support the active refreshing, determining whether the display state of the target card is the visible state; if the display state of the target card is determined to be the invisible state, caching the target data; and if the display state of the target card is determined to be the visible state, updating the protocol data of the target card into the target data.

In this example, when the target application has a service update requirement for the target card in the negative one-screen, for example, a requirement such as a card layout of the target card in the negative one-screen needs to be updated, a refresh status instruction may be directly sent to the card service module 102 shown in fig. 1, where the refresh status instruction may carry target data, and the target data may include protocol data after being updated.

When the corresponding display state is the visible state, the protocol data of the target card can be adapted or updated in time so as to update the data such as the card layout of the target card in time. When the corresponding display state is the invisible state, the target data can be cached, and the computing resources of the electronic equipment can be saved.

As can be seen, in this example, when the target application has a service update demand for a target card in a negative one-screen, a refresh state instruction may be actively sent to the target card corresponding to the target application, and the target data sent by the target application may be adapted according to the display state (visible state or invisible state, etc.) of the target card and whether the target card supports active refresh, etc., so that it is beneficial to implement real-time update of the card layout.

In a possible example, after the target data corresponding to the refresh state command is received in response to the refresh state command sent by the target application, the method further includes the following steps: if the target card is detected to be switched from the invisible state to the visible state, judging whether the target card supports the active refreshing; if the target card is determined to support the active refreshing, updating protocol data of the target card into the target data; if the target card does not support the active refreshing, judging whether the target card corresponds to cache data or not; and if the target card is determined to correspond to the cache data, updating the protocol data of the target card into the cache data.

In a specific implementation, in this example, if the target card is in a state switching condition at this time, particularly when the display state is switched from the invisible state to the visible state, if a refresh state instruction sent by the target application is received at this time, it may be determined whether the target card supports active refresh, and if active refresh is supported, the protocol data of the target card may be directly updated to the target data, and the target data may be analyzed to show a new card layout, and the like. If the active refresh is not supported, whether the target card corresponds to the cache data (the cache data may be target data corresponding to the last refresh state instruction) or not can be further determined, when the cache data is determined to correspond to the target card, the protocol data of the target card is directly updated to be the cache data, the cache data is analyzed to show new card layout and the like, and finally, the target data can be cached. If the target card layout does not correspond to the cache data, the protocol data of the target card can be updated into the target data, and the target data is analyzed to display a new card layout and the like.

It can be seen that, in this example, when the target application has a service update demand for a target card in a negative one-screen, a refresh state instruction may be actively sent to the target card corresponding to the target application, and the target data sent by the target application may be adapted according to conditions such as whether the target card corresponds to cached data and whether the target card supports active refresh, so that real-time update of the card layout is facilitated.

In one possible example, the parsing the protocol data, determining a card type of a target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative screen according to the card type may include: analyzing the protocol data to obtain a description file and card layout information corresponding to the target application; generating a target control according to the description file; determining the card type of the target card according to the target control; and according to the card layout information and the card type, the target card is arranged on the negative screen.

The target control can be a target application custom setting or a native control.

The target control can be used for displaying video data and animation data, and can realize the layout of the video data and the UI layout of the animation data through the card layout information corresponding to the protocol data so as to realize animation effect.

As can be seen, in this example, when a target card is created for the first time or protocol data is analyzed for the first time, a target control corresponding to the target application may be obtained by analyzing the protocol data, a card type may be determined according to the target control, and layout of the target card may be completed according to the card type and card layout information. Therefore, the display of various types of cards is facilitated.

In one possible example, the card type includes at least one of: video type, animation type, text type, and picture type.

In one possible example, the card data is displayed in the target card, and the method may include the following steps: if the card type is determined to be the video type, calling a preset library, and establishing a sub-thread by the first drawing tool to refresh the video data in the target card so as to render the video data in the target card corresponding to the target application.

In one possible example, the negative one-screen establishes a main thread through a second drawing tool to lay out the target card in the negative one-screen through the card layout information.

The preset library may be set by the user or default to the system, and is not limited herein. The preset library may be used to provide standard audio and video components, etc., and may be an ExoPlayer library.

The electronic equipment can comprise a first drawing tool (surface View) and a second drawing tool (View), wherein the first drawing tool can be used for establishing sub-threads, and each target card can correspond to one sub-thread; the second drawing tool can be used for establishing a main thread, and the main thread can be used for finishing the overall layout corresponding to a plurality of target cards in the whole negative one screen.

For example, the card service module 102 may call a method provided by an independent video player (EXOPlayer) inside its corresponding Software Development Kit (SDK), obtain a playing interface (playview) by rendering through the SurfaceView, and call a playing method encapsulated inside the EXOPlayer when playing a video.

Therefore, in the example, the rendering, layout and other work related to each target card and all the target cards in the negative one screen can be distinguished through the sub-thread and the main thread, so that the display and the generation of the cards can be rapidly realized by each target application, and the rendering efficiency can be improved.

In one possible example, the card data is displayed in the target card, and the method may include the following steps: if the card type is determined to be the animation type, animation attribute information corresponding to the protocol data is determined, and rendering of the animation data in the target card is achieved according to the animation attribute information.

The animation attribute information can be used for describing the information such as the effect, UI display, layout and the like of the animation. May include at least one of: the number of playing times, playing period, animation duration, rotation angle, pattern of the rotational speed progress bar, animation duration, pattern of the rotating optical disc, rotation angle of the rotating optical disc, rotation period of the rotating optical disc, etc., are not limited thereto.

Therefore, in the example, the rendering of the animation data can be realized, so that the display of data of various applications is provided for a user, and the richness of the card display is improved.

In one possible example, the animation property information includes at least one of: the type of the progress bar, the animation duration, the type of the rotating optical disc, the rotation angle of the rotating optical disc, and the rotation period of the rotating optical disc.

For example, as shown in fig. 4, the card diagram of a music application is shown, where a target card corresponding to the music application may be used to display a progress of a currently played song, a duration of the song, a singer, and the like, and may also be used to realize presentation of the singer by rotating an optical disc control, display of a progress of the song may be realized by a progress bar control, fast forward of the song may also be realized by a fluctuating progress bar control, and functions of pausing, previous or next of the song, and the like may be realized by controls such as previous, next, and pause, so that an animation effect of the target application may be realized.

Referring to fig. 5, fig. 5 is a schematic flowchart of a card display method provided in an embodiment of the present application, and the card display method is applied to an electronic device.

S501, responding to the first operation, and displaying a negative screen.

And S502, acquiring protocol data and card data of the target application in the negative screen.

S503, determining a card life cycle of the target card, wherein the card life cycle is controlled by a first instruction, a second instruction, a third instruction and a fourth instruction, the first instruction is used for indicating card creation, the second instruction is used for indicating that the display state of the target card is switched from an invisible state to a visible state, the third instruction is used for indicating that the display state of the target card is switched from the visible state to the invisible state, and the fourth instruction is used for indicating that the card is deleted.

S504, responding to the refresh state command sent by the target application, and receiving target data corresponding to the refresh state command.

And S505, judging whether the target card supports active refreshing.

S506, if the target card is determined to support the active refreshing, updating the protocol data of the target card into the target data.

S507, if the target card is determined not to support the active refreshing, determining whether the display state of the target card is the visible state.

And S508, if the display state of the target card is determined to be the invisible state, caching the target data.

S509, if the display state of the target card is determined to be the visible state, updating the protocol data of the target card to the target data.

S510, if the target card is detected to be switched from the invisible state to the visible state, whether the target card supports the active refreshing is judged.

S511, if the target card is determined to support the active refreshing, updating the protocol data of the target card into the target data.

S512, if the target card does not support the active refreshing, judging whether the target card corresponds to cache data or not.

And S513, if the target card is determined to correspond to the cache data, updating the protocol data of the target card into the cache data.

S514, analyzing the protocol data, determining the card type of the target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative screen according to the card type.

S515, displaying the card data in the target card, wherein the card data comprises at least one of the following: video data, animation data, text data, and picture data.

Optionally, the detailed description of step 501 to step 515 may refer to the corresponding steps from step 201 to step 204 of the card display method described in fig. 2, and will not be described herein again.

It can be seen that the card display method described in the embodiment of the present application, in response to the first operation, displays one screen; acquiring protocol data and card data of the target application in the negative one screen; determining a card life cycle of the target card, wherein the card life cycle is controlled by a first instruction, a second instruction, a third instruction and a fourth instruction, the first instruction is used for indicating card creation, the second instruction is used for indicating that the display state of the target card is switched from an invisible state to a visible state, the third instruction is used for indicating that the display state of the target card is switched from the visible state to the invisible state, and the fourth instruction is used for indicating that the card is deleted; responding to a refresh state instruction sent by the target application, and receiving target data corresponding to the refresh state instruction; judging whether the target card supports active refreshing; if the target card is determined to support the active refreshing, updating protocol data of the target card into the target data; if the target card is determined not to support the active refreshing, determining whether the display state of the target card is the visible state; if the display state of the target card is determined to be the invisible state, caching the target data; if the display state of the target card is determined to be the visible state, updating the protocol data of the target card into the target data; if the target card is detected to be switched from the invisible state to the visible state, judging whether the target card supports the active refreshing; if the target card is determined to support the active refreshing, updating protocol data of the target card into the target data; if the target card does not support the active refreshing, judging whether the target card corresponds to cache data or not; if the target card is determined to correspond to the cache data, updating the protocol data of the target card into the cache data; analyzing the protocol data, determining the card type of a target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative screen according to the card type; displaying the card data in the target card, wherein the card data comprises at least one of: video data, animation data, text data, and picture data. When the target application has a service updating requirement for a target card in a negative screen, a refreshing state instruction can be actively sent to the target card corresponding to the target application, and the target data sent by the target application can be adapted according to the conditions of whether the target card corresponds to cache data, whether the target card supports active refreshing and the like; or, the target data sent by the target application can be adapted according to the display state (visible state, invisible state, etc.) of the target card and the condition of whether the target card supports active refresh, etc. So, be favorable to realizing the real-time update to the card overall arrangement to the realization is to the card type between burden screen and the target application and the card overall arrangement's of realization, in order to realize the overall arrangement to the target card of different target application, is favorable to realizing card overall arrangement diversified, and realizes the show to video data or animation data etc. through the target card, is favorable to improving the richness that the card shows.

Referring to fig. 6, fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure, where the electronic device includes a processor, a memory, a communication interface, and one or more programs, and the one or more programs are applied to the electronic device, where the one or more programs are stored in the memory, and the one or more programs are configured to be executed by the processor as instructions for:

displaying a minus one screen in response to a first operation;

It can be seen that the electronic device described in the embodiment of the present application, in response to the first operation, displays a negative screen; acquiring protocol data and card data of the target application in the negative one screen; analyzing the protocol data, determining the card type of a target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative screen according to the card type; displaying the card data in the target card, wherein the card data comprises at least one of: video data, animation data, text data, and picture data. So, accessible agreement data realizes the affirmation to card type and card overall arrangement between burden a screen and the target application to the realization is favorable to realizing card overall arrangement diversification to the overall arrangement of the target card of different target applications, and realizes the show to video data or animation data etc. through the target card, is favorable to improving the richness that the card shows.

In one possible example, before the parsing the protocol data and determining the card type of the target card corresponding to the target application, the program further includes instructions for performing the following steps:

determining a card life cycle of the target card, wherein the card life cycle is controlled by a first instruction, a second instruction, a third instruction and a fourth instruction, the first instruction is used for indicating card creation, the second instruction is used for indicating that the display state of the target card is switched from an invisible state to a visible state, the third instruction is used for indicating that the display state of the target card is switched from the visible state to the invisible state, and the fourth instruction is used for indicating that the card is deleted;

managing protocol data of the target card according to the card life cycle; alternatively, the first and second electrodes may be,

and according to the life cycle of the card, the target application is helped to complete the service requirement.

In one possible example, in said determining the card life cycle of the target card, the program comprises instructions for performing the steps of:

if the target card is in the first creation state, the first instruction is sent to the target application;

in response to a second operation, switching the display state of the target card from the invisible state to the visible state, and sending the second instruction to the target application to enable the target application to be in a background state;

responding to a third operation, switching the display state of the target card from the visible state to the invisible state, and sending the third instruction to the target application;

and responding to a fourth operation, deleting the target card and sending the fourth instruction to the target application.

In one possible example, in said facilitating said target application to fulfill a business requirement according to said card lifecycle, the above program comprises instructions for performing the steps of:

if the display state of the card is determined to be switched from the invisible state to the visible state, determining the configuration information of the target card;

if the configuration information indicates that the target card supports active refreshing, determining a refreshing interval between the previous sending of the second instruction by the target card and the current sending of the second instruction, and marking the current sent second instruction in an effective state;

and if the refresh interval is smaller than or equal to the minimum time interval, determining a target instruction sent to the target application, and putting the target instruction into a message queue, wherein the message queue is used for providing the target instruction for the target application, and the target instruction is used for completing the service requirement of the target application.

In one possible example, in the managing of the protocol data of the target card according to the card lifecycle, the program includes instructions for:

responding to a refresh state instruction sent by the target application, and receiving target data corresponding to the refresh state instruction;

judging whether the target card supports active refreshing or not;

if the target card is determined to support the active refreshing, updating protocol data of the target card into the target data;

if the target card is determined not to support the active refreshing, determining whether the display state of the target card is the visible state;

if the display state of the target card is determined to be the invisible state, caching the target data;

and if the display state of the target card is determined to be the visible state, updating the protocol data of the target card into the target data.

In a possible example, after receiving, in response to a refresh state command sent by the target application, target data corresponding to the refresh state command, the program further includes instructions for performing the following steps:

if the target card is detected to be switched from the invisible state to the visible state, judging whether the target card supports the active refreshing;

if the target card does not support the active refreshing, judging whether the target card corresponds to cache data or not;

and if the target card is determined to correspond to the cache data, updating the protocol data of the target card into the cache data.

In one possible example, in the parsing the protocol data, determining a card type of a target card corresponding to the target application, and in the negative one-screen layout of the target card corresponding to the target application according to the card type, the program includes instructions for performing the following steps:

analyzing the protocol data to obtain a description file and card layout information corresponding to the target application;

generating a target control according to the description file;

determining the card type of the target card according to the target control;

and according to the card layout information and the card type, the target card is arranged on the negative screen.

In one possible example, in displaying the card data in the target card, the program includes instructions for performing the steps of:

if the card type is determined to be the video type, calling a preset library, and establishing a sub-thread by a first drawing tool to refresh the video data in the target card so as to render the video data in the target card corresponding to the target application.

if the card type is determined to be the animation type, animation attribute information corresponding to the protocol data is determined, and rendering of the animation data in the target card is achieved according to the animation attribute information.

In one possible example, the program includes instructions for performing the steps of:

and the negative one screen establishes a main thread through a second drawing tool so as to lay out the target card in the negative one screen through the card layout information.

The above description has introduced the solution of the embodiment of the present application mainly from the perspective of the method-side implementation process. It is understood that the electronic device comprises corresponding hardware structures and/or software modules for performing the respective functions in order to realize the above-mentioned functions. Those of skill in the art will readily appreciate that the present application is capable of hardware or a combination of hardware and computer software implementing the various illustrative elements and algorithm steps described in connection with the embodiments provided herein. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiment of the present application, the electronic device may be divided into the functional units according to the method example, for example, each functional unit may be divided corresponding to each function, or two or more functions may be integrated into one processing unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit. It should be noted that the division of the unit in the embodiment of the present application is schematic, and is only a logic function division, and there may be another division manner in actual implementation.

In the case of dividing each function module by corresponding each function, fig. 7A shows a schematic view of a card display apparatus, which is applied to an electronic device as shown in fig. 7A, the card display apparatus 700 may include: a display unit 701, an acquisition unit 702, and a layout unit 703, wherein,

the display unit 701 is used for responding to a first operation and displaying a negative screen;

the acquiring unit 702 is configured to acquire protocol data and card data of the target application in the negative one-screen;

the layout unit 703 is configured to analyze the protocol data, determine a card type of a target card corresponding to the target application, and layout the target card corresponding to the target application on the negative one screen according to the card type;

the display unit 701 is further configured to display the card data in the target card, where the card data includes at least one of the following: video data, animation data, and text data.

It can be seen that the card display device provided by the embodiment of the application responds to the first operation and displays a negative screen; acquiring protocol data and card data of the target application in the negative one screen; analyzing the protocol data, determining the card type of a target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative screen according to the card type; displaying the card data in the target card, wherein the card data comprises at least one of: video data, animation data, text data, and picture data. So, accessible agreement data realizes the affirmation to card type and card overall arrangement between burden a screen and the target application to the realization is favorable to realizing card overall arrangement diversification to the overall arrangement of the target card of different target applications, and realizes the show to video data or animation data etc. through the target card, is favorable to improving the richness that the card shows.

In a possible example, before the parsing the protocol data and determining the card type of the target card corresponding to the target application, as shown in fig. 7B, fig. 7B shows a schematic diagram of another card display apparatus, on the basis of fig. 7A, the card display apparatus 700 may further include: a determination unit 704 and a management unit 705, wherein,

the determining unit 704 is configured to determine a card lifecycle of the target card, where the card lifecycle is controlled by a first instruction, a second instruction, a third instruction, and a fourth instruction, where the first instruction is used to instruct to create a card, the second instruction is used to instruct to switch a display state of the target card from an invisible state to a visible state, the third instruction is used to instruct to switch the display state of the target card from the visible state to the invisible state, and the fourth instruction is used to instruct to delete the card;

the management unit 705 is configured to manage the protocol data of the target card according to the card lifecycle; alternatively, the first and second electrodes may be,

the management unit 705 is further configured to help the target application complete a service requirement according to the card lifecycle.

In one possible example, in the aspect of determining the card life cycle of the target card, the determining unit 704 is specifically configured to:

if the target card is in a first creation state, sending the first instruction to the target application;

responding to a third operation, switching the display state of the target card from the visible state to the invisible state, and sending a third instruction to the target application;

In a possible example, in terms of helping the target application complete the business requirement according to the card lifecycle, the management unit 705 is specifically configured to:

In a possible example, in terms of managing the protocol data of the target card according to the card lifecycle, the management unit 705 is specifically configured to:

judging whether the target card supports active refreshing;

In a possible example, after receiving target data corresponding to a refresh status command in response to the refresh status command sent by the target application, as shown in fig. 7C, fig. 7C shows a schematic diagram of another card display device, and on the basis of fig. 7A and fig. 7B, the card display device 700 may further include: a judging unit 706 and an updating unit 707, wherein,

the determining unit 706 is configured to determine whether the target card supports the active refresh if it is detected that the target card is switched from the invisible state to the visible state;

the updating unit 707 is configured to update the protocol data of the target card to the target data if it is determined that the target card supports the active refresh;

the determining unit 706 is further configured to determine whether the target card corresponds to cached data if it is determined that the target card does not support the active refresh;

the updating unit 707 is further configured to update the protocol data of the target card to the cache data if it is determined that the target card corresponds to the cache data.

In a possible example, in the analyzing the protocol data, determining a card type of a target card corresponding to the target application, and in the aspect of laying out the target card corresponding to the target application on the negative screen according to the card type, the layout unit 703 is specifically configured to:

generating a target control according to the description file;

determining the card type of the target card according to the target control;

In one possible example, in terms of displaying the card data in the target card, the display unit 701 is specifically configured to:

if the card type is determined to be the video type, calling a preset library, and establishing a sub-thread by the first drawing tool to refresh the video data in the target card so as to render the video data in the target card corresponding to the target application.

It should be noted that all relevant contents of each step related to the above method embodiment may be referred to the functional description of the corresponding functional module, and are not described herein again.

The electronic device provided by the embodiment is used for executing the card display method, so that the same effect as the effect of the implementation method can be achieved.

In case an integrated unit is employed, the electronic device may comprise a processing module, a storage module and a communication module. The processing module may be configured to control and manage actions of the electronic device, and for example, may be configured to support the electronic device to execute steps executed by the display unit 701, the obtaining unit 702, the layout unit 703, the determining unit 704, the managing unit 705, the determining unit 706, and the updating unit 707. The memory module may be used to support the electronic device in executing stored program codes and data, etc. The communication module can be used for supporting the communication between the electronic equipment and other equipment.

The processing module may be a processor or a controller. Which may implement or perform the various illustrative logical blocks, modules, and circuits described in connection with the disclosure. A processor may also be a combination of computing functions, e.g., a combination of one or more microprocessors, a Digital Signal Processing (DSP) and a microprocessor, or the like. The storage module may be a memory. The communication module may specifically be a radio frequency circuit, a bluetooth chip, a Wi-Fi chip, or other devices that interact with other electronic devices.

Embodiments of the present application also provide a computer storage medium, where the computer storage medium stores a computer program for electronic data exchange, the computer program enabling a computer to execute part or all of the steps of any one of the methods described in the above method embodiments, and the computer includes an electronic device.

Embodiments of the present application also provide a computer program product comprising a non-transitory computer readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods as described in the above method embodiments. The computer program product may be a software installation package, the computer comprising an electronic device.

It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, the above-described division of the units is only one type of division of logical functions, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of some interfaces, devices or units, and may be an electric or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in the form of hardware, or may also be implemented in the form of a software functional unit.

The integrated unit may be stored in a computer readable memory if it is implemented in the form of a software functional unit and sold or used as a separate product. Based on such understanding, the technical solution of the present application may be substantially implemented or a part of or all or part of the technical solution contributing to the prior art may be embodied in the form of a software product stored in a memory, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the above-mentioned method of the embodiments of the present application. And the aforementioned memory comprises: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk, and various media capable of storing program codes.

Those skilled in the art will appreciate that all or part of the steps of the methods of the above embodiments may be implemented by a program, which is stored in a computer-readable memory, the memory including: flash Memory disks, Read-Only memories (ROMs), Random Access Memories (RAMs), magnetic or optical disks, and the like.

The foregoing detailed description of the embodiments of the present application has been presented to illustrate the principles and implementations of the present application, and the above description of the embodiments is only provided to help understand the method and the core concept of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, the specific implementation manner and the application scope may be changed, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims

1. A method of card display, the method comprising:

displaying a minus one screen in response to a first operation;

2. The method of claim 1, wherein before parsing the protocol data to determine a card type of a target card corresponding to the target application, the method further comprises:

and according to the life cycle of the card, helping the target application to finish the service requirement.

3. The method of claim 2, wherein the determining the card lifecycle of the target card comprises:

and responding to a fourth operation, deleting the target card, and sending the fourth instruction to the target application.

4. The method of claim 3, wherein said facilitating said target application to fulfill business requirements based on said card lifecycle comprises:

5. The method of claim 3, wherein managing the protocol data of the target card according to the card lifecycle comprises:

judging whether the target card supports active refreshing;

6. The method according to claim 5, wherein after receiving target data corresponding to the refresh state command in response to the refresh state command sent by the target application, the method further comprises:

7. The method according to claim 1, wherein the parsing the protocol data, determining a card type of a target card corresponding to the target application, and arranging the target card corresponding to the target application on the negative one screen according to the card type comprises:

generating a target control according to the description file;

determining the card type of the target card according to the target control;

8. The method of claim 7, wherein the card type comprises at least one of: video type, animation type, text type, and picture type.

9. The method of claim 8, wherein said displaying the card data in the target card comprises:

10. The method of claim 8, wherein said displaying the card data in the target card comprises:

11. The method of claim 10, wherein the animation property information comprises at least one of: the type of the progress bar, the animation duration, the type of the rotating optical disc, the rotation angle of the rotating optical disc, and the rotation period of the rotating optical disc.

12. The method of claim 1 or 9, wherein the negative one-screen establishes a main thread through a second drawing tool to layout the target card in the negative one-screen through the card layout information.

13. A card display apparatus, comprising: a display unit, an acquisition unit, and a layout unit, wherein,

the acquisition unit is used for acquiring the protocol data and the card data of the target application in the negative one screen;

14. An electronic device comprising a processor, a memory, a communication interface, and one or more programs stored in the memory and configured to be executed by the processor, the programs comprising instructions for performing the steps in the method of any of claims 1-12.

15. A computer-readable storage medium, characterized in that a computer program for electronic data exchange is stored, wherein the computer program causes a computer to perform the method according to any one of claims 1-12.

16. A computer program product, wherein the computer program product comprises a non-transitory computer readable storage medium storing a computer program operable to cause a computer to perform the method of any one of claims 1-12.