CN117762537A

CN117762537A - Card sharing method and electronic equipment

Info

Publication number: CN117762537A
Application number: CN202211135455.5A
Authority: CN
Inventors: 靖轲
Original assignee: Petal Cloud Technology Co Ltd
Current assignee: Petal Cloud Technology Co Ltd
Priority date: 2022-09-19
Filing date: 2022-09-19
Publication date: 2024-03-26

Abstract

The embodiment of the application provides a card sharing method and electronic equipment. In the card sharing method, a first application is integrated with a first SDK, a second application is integrated with a second SDK, when a user wants to share a first card in the first application to the second application, sharing information is generated through the first SDK, the sharing information indicates a card file corresponding to the first card, the card file comprises style data and content data of the first card, and the style data comprises hierarchical relations among information elements in the first card, positions and arrangement modes of the information elements and attributes of the information elements. And the second SDK acquires the card file according to the sharing information received by the second application and performs card rendering, so that the first card is displayed on the interface of the second application. The card sharing method and device can enable cards to be shared among different applications, meet requirements of users on card reproduction and card collection, and improve user experience.

Description

Card sharing method and electronic equipment

Technical Field

The embodiment of the application relates to the technical field of electronic equipment, and in particular relates to a card sharing method and electronic equipment.

Background

The card is a component container used for displaying a group of related information in page layout, and is widely applied to electronic equipment for displaying service contents. In general, one or more types of cards, such as a graphic card, a text card, a sliding card, or a list card, are preset in the application, and the content in the card can be dynamically updated by cloud control.

If a user wants to share the card of one application with another application, the card of the same style is preset in the other application, otherwise, the other application cannot receive the shared card, and the user experience is seriously affected.

Disclosure of Invention

The embodiment of the application provides a card sharing method and electronic equipment, which can enable cards to be shared among different applications, and meet the requirements of users on card reproduction and card collection, so that user experience is improved.

In a first aspect, a card sharing method is provided, and the card sharing method is applied to an electronic device, wherein the electronic device comprises a first application and a second application, the first application is integrated with a first Software Development Kit (SDK), and the second application is integrated with a second SDK, and the method comprises: displaying an interface of the first application, wherein the interface of the first application comprises a first card; generating first sharing information through the first SDK in response to the operation of sharing the first card to the second application, wherein the first sharing information indicates a card file corresponding to the first card, and the card file comprises first style data and first content data, and the first style data comprises a hierarchical relation among information elements in the first card, positions and arrangement modes of the information elements and attributes of the information elements; transmitting the first sharing information from the first application to the second application; acquiring the card file through the second SDK based on the first sharing information; and displaying the first card on the interface of the second application according to the card file.

In the embodiment of the application, a lightweight rendering SDK is integrated in an application, and the SDK in a first application generates first sharing information capable of indicating a card file corresponding to a first card. And the SDK in the second application can render the first card according to the card file after acquiring the card file according to the first sharing information. Therefore, interfaces can be copied among applications in the electronic equipment system, the requirements of users on card reproduction and card collection are met, and the user experience is improved.

With reference to the first aspect, in one possible implementation manner, the first sharing information includes a storage path of the card file.

The first application sends the storage path of the card file, so that the amount of data transmitted can be reduced.

With reference to the first aspect, in one possible implementation manner, the first sharing information includes a file name of the card file, where the card file is stored in a preset storage location.

The first application sends the file name of the card file, so that the amount of data transmitted can be reduced.

With reference to the first aspect, in one possible implementation manner, the card file is stored in a common storage space of the electronic device.

The card file is stored in a local common storage space that is accessible to both the first application and the second application. The first application does not need to directly send the card file, and the data transmission quantity can be reduced.

With reference to the first aspect, in one possible implementation manner, the generating, by the first SDK, the first sharing information in response to the operation of sharing the first card to the second application includes: responding to the operation of sharing the first card to the second application, and acquiring the card file by analyzing the information elements on the first card; and storing the card file through the first SDK to generate the first sharing information.

The card file can be obtained by analyzing the information element on the first card, so that cards of any type can be shared between two applications.

With reference to the first aspect, in one possible implementation manner, the obtaining the card file by parsing the information element on the first card includes: analyzing the information elements on the first card through the system capacity of the electronic equipment to obtain an analysis result; and converting the analysis result into the card file through the first SDK.

The operating system of the electronic device has the capability of resolving the interface element, and the information element in the first card can be resolved through the system capability of the electronic device. The SDK of the first application can convert the result analyzed by the operating system into the card file according to the rule, format and the like of the card file, so that the second application can be conveniently etched.

With reference to the first aspect, in one possible implementation manner, the first sharing information includes the card file.

When the first application directly shares the card file to the second application, the storage position of the card file may not be limited, for example, may be stored in a public storage space of the electronic device, or may be stored in a storage space dedicated to the first application. The second application which receives the card file can directly process according to the card file, and the operation flow is simple.

With reference to the first aspect, in one possible implementation manner, the generating, by the first SDK, the first sharing information in response to the operation of sharing the first card to the second application includes: and responding to the operation of sharing the first card to the second application, and reading the card file through the first SDK to generate the first sharing information.

The card file is stored on the electronic device, and the first SDK has a function of reading the card file, so that first sharing information is generated.

With reference to the first aspect, in a possible implementation manner, before the reading, by the first SDK, the card file, the method further includes: analyzing the information elements on the first card through the system capacity of the electronic equipment to obtain an analysis result; converting the analysis result into the card file through the first SDK; and storing the card file through the first SDK.

In this embodiment of the present application, the first SDK has a function of converting an analysis result into a card file and a function of storing the card file.

With reference to the first aspect, in one possible implementation manner, the card file is issued to the first application by a server or a cloud corresponding to the first application.

The card file can be well developed in a development stage, and the first application can acquire the card file corresponding to the card from the server or the cloud.

With reference to the first aspect, in a possible implementation manner, the sending, by the first application, the first sharing information to the second application includes: and sending the first sharing information to the second application by the first application through the system sharing capability of the electronic equipment.

With reference to the first aspect, in a possible implementation manner, the card file includes a first file and a second file, where the first file is used for storing the first type data, and the second file is used for storing the first content data.

In this way, the first pattern data and the first content data may be two files in separate form, facilitating the first application or the second application to directly process (e.g. use or fixedly store) a certain file therein.

With reference to the first aspect, in a possible implementation manner, the information element in the first card includes a first information element, the first information element includes at least one attribute, the attribute includes an attribute name and an attribute value, wherein an attribute value of one or more attributes in the at least one attribute is a placeholder, and the first content data includes an actual value corresponding to the placeholder.

The first content data is separated from the first style data, and the specific style of the card, the display content, or the like can be driven to be changed by changing the actual value in the first content data.

With reference to the first aspect, in a possible implementation manner, displaying, according to the card file, the first card on an interface of the second application includes: creating an information element at an interface of the second application through the second SDK according to the analysis result of the second SDK on the first file, wherein the attribute value of one or more attributes in the at least one attribute of the first information element is a placeholder; and according to the analysis result of the second SDK on the second file, applying an actual value corresponding to the placeholder to an interface of the second application through the second SDK.

The second SDK has a function of converting the card file into a user interface.

With reference to the first aspect, in one possible implementation manner, a data format of the first file is the same as or different from a data format of the second file.

With reference to the first aspect, in a possible implementation manner, the first sharing information further includes a first identifier, where the first identifier corresponds to the first type of data, and the method further includes: and storing the first pattern data and the first identification through the second SDK.

The second application stores the first pattern data and the first identification, and facilitates subsequent direct application of the content of the card in the same form as the first card to the first pattern data.

With reference to the first aspect, in a possible implementation manner, the method further includes: displaying an interface of the first application, wherein the interface of the first application comprises a second card, and the style of the second card is the same as that of the first card; generating second sharing information through the first SDK in response to the operation of sharing the second card to the second application, wherein the second sharing information indicates second content data corresponding to the second card, and the second sharing information further comprises the first identifier; transmitting the second sharing information from the first application to the second application; acquiring, by the second SDK, the second content data and the first style data based on the second shared information, wherein the first style data is acquired based on the first identification; and displaying the second card on the interface of the second application according to the first type data and the second content data.

The style of the second card is the same as that of the first card, the first application can only send the content data of the second card, and the second application combines the content data of the second card with the style data of the first card to render the second card, so that the data transmission quantity can be reduced, and the storage space is saved.

With reference to the first aspect, in a possible implementation manner, before the generating, by the first SDK, second shared information, the method further includes: sending a first message to the second SDK through the first SDK, wherein the first message is used for requesting the identification of a card supported by the second application; and receiving a second message from the second SDK through the first SDK, wherein the second message comprises the identification of the card supported by the second application, and the identification of the card supported by the second application comprises the first identification.

The first application may first request the identity of the card supported by the second application before the first application shares the specific content of the second card with the second application. When the second application is capable of displaying the corresponding card style of the first identifier, the first application may share the second content data without sharing the style data of the second card to the second application. In this way, the size of the shared content can be reduced.

With reference to the first aspect, in a possible implementation manner, before the generating, by the first SDK, first sharing information, the method further includes: and determining that the identification of the card supported by the second application does not comprise a first identification through interaction between the first SDK and the second SDK, wherein the first identification corresponds to the first type data.

Here, the interaction between the first SDK and the second SDK is performed by calling the system capability.

With reference to the first aspect, in one possible implementation manner, the card file is a text file.

The text file is easy to read and write by a technician, and the electronic equipment is convenient to read, write and compress the size.

With reference to the first aspect, in one possible implementation manner, the data format of the card file includes at least one of the following: JSON format, XML format, HTML format.

The card file formed by JSON format, XML format, HTML format, etc. may have a fixed structure capable of embodying a hierarchical relationship between information elements, and according to the fixed structure, parent-child relationships, sibling relationships, or ancestor-offspring relationships that are present between information elements may be resolved.

In a second aspect, a card sharing method is provided and applied to a first electronic device, where the first electronic device includes a first application, and the first application is integrated with a first software development kit SDK, and the method includes: displaying an interface of the first application, wherein the interface of the first application comprises a first card; generating first sharing information through the first SDK in response to the operation of sharing the first card to the second application, wherein the first sharing information indicates a card file corresponding to the first card, and the card file comprises first style data and first content data, and the first style data comprises a hierarchical relation among information elements in the first card, positions and arrangement modes of the information elements and attributes of the information elements; and sending the first sharing information to second electronic equipment, wherein the second electronic equipment comprises the second application, the second application is integrated with a second SDK, and the second SDK is used for displaying the first card on an interface of the second application according to the first sharing information.

In the embodiment of the present application, a lightweight rendering SDK is integrated in a first application, where the SDK in the first application generates first sharing information capable of indicating a card file corresponding to a first card, and the first sharing information may enable the SDK of a second application to render the first card after acquiring the card file. Therefore, interfaces can be copied among applications of different electronic devices, requirements of users on card reproduction and card collection are met, and user experience is improved.

With reference to the second aspect, in one possible implementation manner, the first sharing information includes a storage path of the card file in a cloud space, where the cloud space is shared by the first electronic device and the second electronic device.

The first electronic device sends the card file to the storage path of the cloud space, so that the transmitted data volume can be reduced, and the second electronic device can acquire the card file from the cloud space.

With reference to the second aspect, in one possible implementation manner, the first sharing information includes a file name of the card file, where the card file is stored in a preset storage location in cloud space, and the preset storage location is accessible by the first application and the second application.

The first electronic device sends the file name of the card file, so that the amount of transmitted data can be reduced, and the second electronic device can acquire the card file from a preset storage position in the cloud space.

With reference to the second aspect, in one possible implementation manner, the generating, by the first SDK, the first sharing information in response to the operation of sharing the first card to the second application includes:

Responding to the operation of sharing the first card to the second application, and acquiring the card file by analyzing the information elements on the first card; and storing the card file through the first SDK to generate the first sharing information.

With reference to the second aspect, in a possible implementation manner, the obtaining the card file by parsing the information element on the first card includes: analyzing the information elements on the first card through the system capacity of the first electronic equipment to obtain an analysis result; and converting the analysis result into the card file through the first SDK.

With reference to the second aspect, in one possible implementation manner, the first sharing information includes the card file.

With reference to the second aspect, in one possible implementation manner, the generating, by the first SDK, the first sharing information in response to the operation of sharing the first card to the second application includes: and responding to the operation of sharing the first card to the second application, and reading the card file through the first SDK to generate the first sharing information.

With reference to the second aspect, in a possible implementation manner, before the reading, by the first SDK, the card file, the method further includes: analyzing the information elements on the first card through the system capacity of the first electronic equipment to obtain an analysis result; converting the analysis result into the card file through the first SDK; and storing the card file through the first SDK.

With reference to the second aspect, in a possible implementation manner, before displaying the interface of the first application, the method further includes: and receiving the card file issued by the server or the cloud corresponding to the first application.

With reference to the second aspect, in a possible implementation manner, the sending the first sharing information to the second electronic device includes: and sending the first sharing information to the second application by the first application through mail or a short-range wireless communication technology.

With reference to the second aspect, in one possible implementation manner, the card file includes a first file and a second file, where the first file is used for storing the first type data, and the second file is used for storing the first content data.

With reference to the second aspect, in one possible implementation manner, the information element in the first card includes a first information element, the first information element includes at least one attribute, the attribute includes an attribute name and an attribute value, wherein an attribute value of one or more attributes in the at least one attribute is a placeholder, and the first content data includes an actual value corresponding to the placeholder.

With reference to the second aspect, in one possible implementation manner, a data format of the first file is the same as or different from a data format of the second file.

With reference to the second aspect, in a possible implementation manner, the first sharing information further includes a first identifier, where the first identifier corresponds to the first type of data.

With reference to the second aspect, in a possible implementation manner, the method further includes:

displaying an interface of the first application, wherein the interface of the first application comprises a second card, and the style of the second card is the same as that of the first card;

generating, by the first SDK, second sharing information indicating second content data corresponding to the second card in response to an operation of sharing the second card to the second application, the second sharing information including the first identification;

and sending the second sharing information to the second electronic device, wherein the second sharing information is used for the second SDK to acquire the second content data and the first type data, and the second content data and the first type data are used for the second SDK to display the second card on the interface of the second application.

With reference to the second aspect, in a possible implementation manner, before the generating, by the first SDK, second shared information, the method further includes: sending a first message to the second SDK through the first SDK, wherein the first message is used for requesting the identification of a card supported by the second application; and receiving a second message from the second SDK through the first SDK, wherein the second message comprises the identification of the card supported by the second application, and the identification of the card supported by the second application comprises the first identification.

With reference to the second aspect, in a possible implementation manner, before the generating, by the first SDK, first sharing information, the method further includes: and determining that the identification of the card supported by the second application does not comprise a first identification through interaction between the first SDK and the second SDK, wherein the first identification corresponds to the first type data.

With reference to the second aspect, in one possible implementation manner, the card file is a text file.

With reference to the second aspect, in one possible implementation manner, the data format of the card file includes at least one of the following: JSON format, XML format, HTML format.

In a third aspect, a card sharing method is provided and applied to a second electronic device, where the second electronic device includes a second application, and the second application is integrated with a second software development kit SDK, and the method includes: receiving first sharing information sent by first electronic equipment, wherein the first electronic equipment comprises a first application, a first SDK is integrated in the first application, an interface of the first application comprises a first card, the first sharing information indicates a card file corresponding to the first card, the card file comprises first type data and first content data, and the first type data comprises a hierarchical relation among information elements in the first card, positions and arrangement modes of the information elements and attributes of the information elements; acquiring the card file through the second SDK based on the first sharing information; and displaying the first card on the interface of the second application according to the card file.

With reference to the third aspect, in one possible implementation manner, the first sharing information includes a storage path of the card file in a cloud space, where the cloud space is shared by the first electronic device and the second electronic device.

With reference to the third aspect, in one possible implementation manner, the first sharing information includes a file name of the card file, where the card file is stored in a preset storage location in cloud space, and the preset storage location is accessible by the first application and the second application.

With reference to the third aspect, in one possible implementation manner, the first sharing information includes the card file.

With reference to the third aspect, in one possible implementation manner, the receiving the first sharing information sent by the first electronic device includes: and receiving the first sharing information through mail or a short-range wireless communication technology.

With reference to the third aspect, in one possible implementation manner, the card file includes a first file and a second file, where the first file is used for storing the first type data, and the second file is used for storing the first content data.

With reference to the third aspect, in one possible implementation manner, the information element in the first card includes a first information element, the first information element includes at least one attribute, the attribute includes an attribute name and an attribute value, wherein an attribute value of one or more attributes in the at least one attribute is a placeholder, and the first content data includes an actual value corresponding to the placeholder.

With reference to the third aspect, in a possible implementation manner, the displaying, according to the card file, the first card on the interface of the second application includes: creating an information element at an interface of the second application through the second SDK according to the analysis result of the second SDK on the first file, wherein the attribute value of one or more attributes in the at least one attribute of the first information element is a placeholder; and according to the analysis result of the second SDK on the second file, applying an actual value corresponding to the placeholder to an interface of the second application through the second SDK.

With reference to the third aspect, in one possible implementation manner, a data format of the first file is the same as or different from a data format of the second file.

With reference to the third aspect, in a possible implementation manner, the first sharing information further includes a first identifier, where the first identifier corresponds to the first type of data, and the method further includes: and storing the first pattern data and the first identification through the second SDK.

With reference to the third aspect, in one possible implementation manner, the method further includes:

receiving second sharing information sent by the first application, wherein the second sharing information indicates second content data corresponding to a second card, and the second sharing information further comprises the first identifier, and the style of the second card is the same as that of the first card;

acquiring, by the second SDK, the second content data and the first style data based on the second shared information, wherein the first style data is acquired based on the first identification;

and displaying the second card on the interface of the second application according to the first type data and the second content data.

With reference to the third aspect, in a possible implementation manner, before the receiving the second shared information and the first identifier sent by the first application, the method further includes: receiving a first message sent by the first SDK through the second SDK, wherein the first message is used for requesting the identification of a card supported by the second application; and sending a second message to the first SDK through the second SDK, wherein the second message comprises the identification of the card supported by the second application, and the identification of the card supported by the second application comprises the first identification.

With reference to the third aspect, in one possible implementation manner, the card file is a text file.

With reference to the third aspect, in one possible implementation manner, the data format of the card file includes at least one of the following: JSON format, XML format, HTML format.

In a fourth aspect, a communication system is provided, the communication system comprising a first electronic device comprising a first application integrated with a first software development kit, SDK, and a second electronic device comprising a second application integrated with a second SDK, wherein,

the first electronic device is configured to: displaying an interface of the first application, wherein the interface of the first application comprises a first card; generating first sharing information through the first SDK in response to the operation of sharing the first card to the second application, wherein the first sharing information indicates a card file corresponding to the first card, and the card file comprises first style data and first content data, and the first style data comprises a hierarchical relation among information elements in the first card, positions and arrangement modes of the information elements and attributes of the information elements; transmitting the first sharing information from the first application to the second application;

The second electronic device is configured to: acquiring the card file through the second SDK based on the first sharing information; and displaying the first card on the interface of the second application according to the card file.

With reference to the fourth aspect, in one possible implementation manner, the first sharing information includes a storage path of the card file in a cloud space, where the cloud space is shared by the first electronic device and the second electronic device.

With reference to the fourth aspect, in one possible implementation manner, the first sharing information includes a file name of the card file, where the card file is stored in a preset storage location in cloud space, and the preset storage location is accessible by the first application and the second application.

With reference to the fourth aspect, in one possible implementation manner, the first electronic device is specifically configured to: responding to the operation of sharing the first card to the second application, and acquiring the card file by analyzing the information elements on the first card; and storing the card file through the first SDK to generate the first sharing information.

With reference to the fourth aspect, in one possible implementation manner, the first electronic device is specifically configured to: analyzing the information elements on the first card through the system capacity of the first electronic equipment to obtain an analysis result; and converting the analysis result into the card file through the first SDK.

With reference to the fourth aspect, in a possible implementation manner, the first sharing information includes the card file.

With reference to the fourth aspect, in one possible implementation manner, the first electronic device is specifically configured to: and responding to the operation of sharing the first card to the second application, and reading the card file through the first SDK to generate the first sharing information.

With reference to the fourth aspect, in a possible implementation manner, before the reading, by the first SDK, the card file, the first electronic device is further configured to: analyzing the information elements on the first card through the system capacity of the first electronic equipment to obtain an analysis result; converting the analysis result into the card file through the first SDK; and storing the card file through the first SDK.

With reference to the fourth aspect, in a possible implementation manner, before displaying the interface of the first application, the first electronic device is further configured to: and receiving the card file issued by the server or the cloud corresponding to the first application.

With reference to the fourth aspect, in one possible implementation manner, the first electronic device is specifically configured to: and sending the first sharing information to the second application by the first application through mail or a short-range wireless communication technology.

With reference to the fourth aspect, in a possible implementation manner, the card file includes a first file and a second file, where the first file is used for storing the first type data, and the second file is used for storing the first content data.

With reference to the fourth aspect, in a possible implementation manner, the information element in the first card includes a first information element, the first information element includes at least one attribute, the attribute includes an attribute name and an attribute value, wherein an attribute value of one or more attributes in the at least one attribute is a placeholder, and the first content data includes an actual value corresponding to the placeholder.

With reference to the fourth aspect, in one possible implementation manner, the second electronic device is specifically configured to: creating an information element at an interface of the second application through the second SDK according to the analysis result of the second SDK on the first file, wherein the attribute value of one or more attributes in the at least one attribute of the first information element is a placeholder; and according to the analysis result of the second SDK on the second file, applying an actual value corresponding to the placeholder to an interface of the second application through the second SDK.

With reference to the fourth aspect, in one possible implementation manner, a data format of the first file is the same as or different from a data format of the second file.

With reference to the fourth aspect, in a possible implementation manner, the first sharing information further includes a first identifier, where the first identifier corresponds to the first type of data, and the second electronic device is further configured to: and storing the first pattern data and the first identification through the second SDK.

With reference to the fourth aspect, in a possible implementation manner, the first electronic device is further configured to: displaying an interface of the first application, wherein the interface of the first application comprises a second card, and the style of the second card is the same as that of the first card; generating second sharing information through the first SDK in response to the operation of sharing the second card to the second application, wherein the second sharing information indicates second content data corresponding to the second card, and the second sharing information further comprises the first identifier; transmitting the second sharing information from the first application to the second application;

the second electronic device is further configured to: acquiring, by the second SDK, the second content data and the first style data based on the second shared information, wherein the first style data is acquired based on the first identification; and displaying the second card on the interface of the second application according to the first type data and the second content data.

With reference to the fourth aspect, in a possible implementation manner, before the generating, by the first SDK, second shared information, the first electronic device is further configured to: sending a first message to the second SDK through the first SDK, wherein the first message is used for requesting the identification of a card supported by the second application; and receiving a second message from the second SDK through the first SDK, wherein the second message comprises the identification of the card supported by the second application, and the identification of the card supported by the second application comprises the first identification.

With reference to the fourth aspect, in a possible implementation manner, before the generating, by the first SDK, first sharing information, the first electronic device is further configured to: and determining that the identification of the card supported by the second application does not comprise a first identification through interaction between the first SDK and the second SDK, wherein the first identification corresponds to the first type data.

With reference to the fourth aspect, in one possible implementation manner, the card file is a text file or a binary file.

With reference to the fourth aspect, in one possible implementation manner, the card file is a text file and the card file is in a plain text format.

With reference to the fourth aspect, in one possible implementation manner, the data format of the card file includes at least one of the following: JSON format, XML format, HTML format.

The advantages of the communication system according to the fourth aspect may refer to the advantages of the methods described in the first to third aspects, and are not described here again.

In a fifth aspect, an apparatus is provided, the apparatus being comprised in an electronic device, the apparatus having a function of implementing the actions involved in any one of the possible implementations of the first aspect and the first aspect, or having a function of implementing the actions involved in any one of the possible implementations of the second aspect and the second aspect, or having a function of implementing the actions involved in any one of the possible implementations of the third aspect and the third aspect.

The functions can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules or units corresponding to the functions described above. For example, a display module or unit, a generation module or unit, a transmission module or unit, an acquisition module or unit, a reception module or unit, a processing module or unit, and the like.

In a sixth aspect, there is provided an electronic device comprising: one or more processors; one or more memories; the one or more memories store one or more computer programs comprising instructions that, when executed by the one or more processors, cause the electronic device to perform the method of the first aspect and any of the possible implementations of the first aspect, or to perform the method of the second aspect and any of the possible implementations of the second aspect, or to perform the method of the third aspect and any of the possible implementations of the third aspect.

A seventh aspect provides a computer readable storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform the method of or the method of any of the possible implementations of the third aspect.

In an eighth aspect, there is provided a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of the first aspect and any one of the possible implementations of the first aspect, or performing the method of the second aspect and any one of the possible implementations of the second aspect, or performing the method of the third aspect and any one of the possible implementations of the third aspect.

A ninth aspect provides a chip comprising a processor and a data interface, the processor reading instructions stored on a memory via the data interface, performing the method of any one of the possible implementations of the first aspect and the first aspect, or performing the method of any one of the possible implementations of the second aspect and the second aspect, or performing the method of any one of the possible implementations of the third aspect and the third aspect.

Optionally, as an implementation manner, the chip may further include a memory, where the memory stores instructions, and the processor is configured to execute the instructions stored on the memory, where the instructions, when executed, are configured to perform the method in any one of the foregoing first aspect and any one of the foregoing possible implementation manners of the first aspect, or perform the method in any one of the foregoing second aspect and any one of the foregoing possible implementation manners of the second aspect, or perform the method in any one of the foregoing possible implementation manners of the third aspect.

The chip may be a field programmable gate array or an application specific integrated circuit.

The advantages of the apparatus according to the fifth to ninth aspects may be referred to the advantages of the method according to the first to third aspects, and are not described here again.

Drawings

Fig. 1 is a schematic hardware structure of an electronic device according to an embodiment of the present application.

Fig. 2 is a schematic software structure of an electronic device according to an embodiment of the present application.

Fig. 3 is a schematic diagram of a card application scenario provided in an embodiment of the present application.

Fig. 4 is a schematic diagram of an example application development process.

Fig. 5 is a schematic diagram of a card according to an embodiment of the present application.

Fig. 6 is a schematic flowchart of a card sharing method according to an embodiment of the present application.

Fig. 7 is a schematic diagram of a card according to an embodiment of the present application.

Fig. 8 is an application scenario diagram of a card sharing method provided in an embodiment of the present application.

Fig. 9 is a schematic flowchart of a card sharing method according to an embodiment of the present application.

Fig. 10 is a schematic diagram of data read and written by an SDK application provided in an embodiment of the present application.

Fig. 11 is a schematic flowchart of a card sharing method according to an embodiment of the present application.

Fig. 12 is a schematic diagram of an SDK function provided in an embodiment of the present application.

Fig. 13 is a schematic flowchart of a card sharing method according to an embodiment of the present application.

Fig. 14 is a schematic flowchart of another card sharing method according to an embodiment of the present application.

Fig. 15 is a schematic block diagram of a communication system according to an embodiment of the present application.

Fig. 16 is a schematic block diagram of an apparatus provided in an embodiment of the present application.

Fig. 17 is a schematic block diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings.

It should be noted that, in the description of the embodiments of the present application, unless otherwise indicated, "/" means or, for example, a/B may represent a or B; "and/or" herein is merely an association relationship describing an association object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, in the description of the embodiments of the present application, "plurality" means two or more, and "at least one" and "one or more" mean one, two or more. The singular expressions "a," "an," "the," and "such" are intended to include, for example, also "one or more" such expressions, unless the context clearly indicates to the contrary.

The terms "first" and "second" are used below for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

In order to facilitate understanding, some technical terms related to embodiments of the present application are explained and described below.

A card, which is a component container used to present a set of related information in a page layout, where the information (or element, information element, user Interface (UI) element) may include: pictures, text, videos, lists, asterisks, icons, links, music, input boxes, buttons, other interactable controls, combinations thereof, or the like. The card may carry different types of content, the information therein being unrestricted. In general, the card may be a rectangular block containing certain pictures and text information and serve as a portal to more detailed information, where the color of the card may be clearly distinguished from or hidden in the background color.

A software development kit (software development kit, SDK), broadly refers to a collection of related documents, examples, and tools that assist in developing a certain class of software, such as a collection of development tools when a software engineer builds application software for a particular software package, software framework, hardware platform, operating system, or the like. For example, a developer may package a function of an application into an SDK and communicate with the outside world through an application programming interface (application programming interface, API). The SDK can be added into other application programs, and the application programs directly use the corresponding functions of the SDK through calling the API interface without knowing the implementation principle, so that the development program and the workload can be reduced.

An application programming interface (application programming interface, API), which is a number of predefined functions, is designed to provide applications and developers the ability to access a set of routines based on certain software or hardware without having to access source code or understand the details of the internal operating mechanisms.

The JavaScript object notation (JavaScript object notation, JSON) is a lightweight data exchange format, has the characteristics of good readability and convenience for quick writing, and can exchange data between different platforms. The JSON format file belongs to a text file, wherein the content is in plain text format.

Extensible markup language (extensible markup language, XML), a markup language used to mark electronic files to be structured, can be used to mark data, define data types, and is a source language that allows users to define their own markup language. The XML format file belongs to a text file, wherein the content is in a plain text format.

Hypertext markup language (hyper text markup language, HTML), is a markup language that includes a series of tags by which document formats on a network can be unified, allowing discrete network resources to be connected as a logical entity. The HTML format file belongs to a text file, and the content in the file is in plain text format.

And the placeholder is used for holding the fixed position for adding the symbol of the content at the corresponding position later.

An attribute is a description of the nature of a thing. An attribute name, which is the name of an attribute used to distinguish between different attributes, and an attribute value, which is a specific descriptor, are generally included.

Text files are files based on character encoding. Common codes are ASCII codes, UNICODE codes, etc.

Plain text, i.e., text without any text modification, without any bold, underline, italic, graphic, symbol or special character and special print format. The file in plain text format only holds text and does not hold its format settings. Text files refer to a container, while plain text refers to a content. The text file may contain plain text.

Binary files are files encoded based on values. The meaning of a certain value may be specified, for example, according to a specific application. The binary file mentioned in the embodiment of the present application is a narrow concept with respect to the text file, and is a binary file as long as the file contains other characters than the visible characters.

The method provided by the embodiment of the application is applied to electronic devices, including but not limited to mobile phones, tablet computers, vehicle-mounted devices, wearable devices, augmented reality (augmented reality, AR)/Virtual Reality (VR) devices, notebook computers, ultra-mobile personal computer (UMPC), netbooks, personal digital assistants (personal digital assistant, PDA), smart screens and other electronic devices with display functions or touch screens. The embodiment of the application does not limit the specific type of the electronic device.

Exemplary, fig. 1 shows a schematic hardware structure of an electronic device according to an embodiment of the present application.

As shown in fig. 1, the electronic device 100 may include: processor 110, memory 120, universal serial bus (universal serial bus, USB) interface 130, charge management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headset interface 170D, sensor module 180, camera 191, display 192, keys 193, etc.

Processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and a command center of the electronic device 100, among others. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory, avoiding repeated access, reducing the latency of the processor 110 and thus improving the efficiency of the system.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

For example, the processor 110 and the touch sensor 180E may communicate via an I2C bus interface to implement the touch functionality of the electronic device 100. The processor 110 and the camera 191 may communicate through the CSI interface to implement a photographing function of the electronic device 100. Processor 110 and display 192 may communicate via a DSI interface to implement the display functions of electronic device 100.

It should be understood that the interfacing relationship between the modules illustrated in the embodiments of the present application is only illustrative, and does not limit the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also use different interfacing manners, or a combination of multiple interfacing manners in the foregoing embodiments.

The charge management module 140 is configured to receive a charge input from a charger. The power management module 141 is used to connect the battery 142. The charging management module 140 may also supply power to the electronic device 100 through the power management module 141 while charging the battery 142. The power management module 141 may also be configured to monitor battery capacity, battery cycle times, battery health, and other parameters.

The wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc. The mobile communication module 150 may receive electromagnetic waves from the antenna 1, perform processes such as filtering, amplifying, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can amplify the signal modulated by the modem processor, and convert the signal into electromagnetic waves through the antenna 1 to radiate. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be provided in the same device as at least some of the modules of the processor 110.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as applied to the electronic device 100. The wireless communication module 160 may be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

The electronic device 100 implements display functions through a GPU, a display screen 192, and an application processor, etc. The GPU is a microprocessor for image processing, and is connected to the display 192 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display 192 is used to display images, videos, and the like. The display 192 includes a display panel. The display panel may employ a liquid crystal display (liquid crystal display, LCD), an organic light-emitting diode (OLED), an active-matrix organic light emitting diode (AMOLED), a flexible light-emitting diode (flex), a mini, a Micro-OLED, a quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like. In some embodiments, the electronic device 100 may include 1 or N display screens 192, N being a positive integer greater than 1.

The electronic device 100 may implement photographing functions through an ISP, a camera 191, a video codec, a GPU, a display 192, an application processor, and the like. The ISP is used to process the data fed back by the camera 191. The camera 191 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor. In some embodiments, the electronic device 100 may include 1 or N cameras 191, N being a positive integer greater than 1.

Video codecs are used to compress or decompress digital video. The electronic device 100 may support one or more video codecs. In this way, the electronic device 100 may play or record video in a variety of encoding formats, such as: dynamic picture experts group (moving picture experts group, MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

Memory 120 is used to store data and/or instructions.

Memory 120 may include internal memory. The internal memory is used to store computer executable program code that includes instructions. The processor 110 executes instructions stored in the internal memory to thereby perform various functional applications and data processing of the electronic device 100. The internal memory may include a stored program area and a stored data area. The storage program area can store an operating system; the storage area may also store one or more applications (e.g., gallery, contacts, etc.), and so forth. The storage data area may store data (e.g., images, contacts, etc.) created during use of the electronic device 100, and so forth. In addition, the internal memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, universal flash memory (universal flash storage, UFS), and the like. In some embodiments, the processor 110 may cause the electronic device 100 to perform the card sharing methods provided in embodiments of the present application by executing instructions stored in an internal memory, and/or instructions stored in a memory provided in the processor 110.

The memory 120 may also include external memory, such as a Micro SD card, to extend the storage capabilities of the electronic device 100. The external memory may communicate with the processor 110 through an external memory interface to implement data storage functions. For example, files such as music, video, etc. are stored in an external memory.

The electronic device 100 may implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like. Such as audio playback, recording, etc.

The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an acceleration sensor 180C, a distance sensor 180D, a touch sensor 180E, and some other sensors, etc.

The pressure sensor 180A is used to sense a pressure signal, and may convert the pressure signal into an electrical signal. In some embodiments, pressure sensor 180A may be disposed on display 192. The pressure sensor 180A is of various types, such as a resistive pressure sensor, an inductive pressure sensor, a capacitive pressure sensor, and the like. The capacitive pressure sensor may be a capacitive pressure sensor comprising at least two parallel plates with conductive material. The capacitance between the electrodes changes when a force is applied to the pressure sensor 180A. The electronic device 100 determines the strength of the pressure from the change in capacitance. When a touch operation is applied to the display 192, the electronic apparatus 100 detects the touch operation intensity according to the pressure sensor 180A. The electronic device 100 may also calculate the location of the touch based on the detection signal of the pressure sensor 180A. In some embodiments, touch operations that act on the same touch location, but at different touch operation strengths, may correspond to different operation instructions. For example: and executing an instruction for checking the short message when the touch operation with the touch operation intensity smaller than the first pressure threshold acts on the short message application icon. And executing an instruction for newly creating the short message when the touch operation with the touch operation intensity being greater than or equal to the first pressure threshold acts on the short message application icon.

The gyro sensor 180B, also called an angular velocity sensor, may be used to determine the motion gesture of the electronic device 100. In some embodiments, the angular velocity of electronic device 100 about three axes (i.e., x, y, and z axes) may be determined by gyro sensor 180B. The gyro sensor 180B may be used for photographing anti-shake. The gyro sensor 180B may also be used for navigation, motion sensing of a game scene, for example, the gyro can completely monitor the displacement of a player's hand, thereby achieving various game operation effects, such as changing a horizontal screen to a vertical screen, turning a racing game, and the like.

The acceleration sensor 180C may detect the magnitude of acceleration of the electronic device 100 in various directions (typically three axes). The magnitude and direction of gravity may be detected when the electronic device 100 is stationary. The acceleration sensor 180C may also be used to identify the gesture of the electronic device 100, for applications such as landscape switching, pedometer, etc.

A distance sensor 180D for measuring a distance. The electronic device 100 may measure the distance by infrared or laser. In some embodiments, the electronic device 100 may range using the distance sensor 180D to achieve fast focus.

The touch sensor 180E, also referred to as a "touch panel". The touch sensor 180E may be disposed on the display 192, and the touch sensor 180E and the display 192 form a touch screen, which is also referred to as a "touch screen". The touch sensor 180E is used to detect a touch operation acting thereon or thereabout. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 192. In other embodiments, the touch sensor 180E may also be disposed on a surface of the electronic device in a different location than the display 192.

It should be understood that, in the embodiment of the present application, the sensor module 180 is not limited to the type of sensor, and the sensor module 180 may include more or fewer sensors, and may be specifically determined according to actual needs, which will not be described in detail herein.

The keys 193 may include a power on key, a volume key, etc. The keys 193 may be mechanical keys or touch keys. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100.

It should be understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device may include more or less components than illustrated, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

A schematic diagram of a possible hardware architecture of the electronic device 100 is presented above. The software system of the electronic device 100 may employ a layered architecture, an event driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. Embodiments of the present application are in a layered architecture The system is an example illustrating the software architecture of the electronic device 100.

Fig. 2 shows a software architecture block diagram of an electronic device according to an embodiment of the present application. As shown in fig. 2, the hierarchical architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, it willThe system is divided into four layers, namely an application program layer, an application program framework layer, a system runtime layer (comprising a system library and Android runtime) and a kernel layer from top to bottom. Below the kernel layer is a hardware layer.

The application layer may include a series of Application (APP) packages. As shown in fig. 2, the application package may include applications for cameras, gallery, calendar, phone calls, maps, navigation, WLAN, bluetooth, music, video, short messages, etc.

The application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs of the application layer. The application framework layer includes a number of predefined functions. As shown in FIG. 2, the application framework layer may include a window manager, a content provider, a telephony manager, a resource manager, a notification manager, a view system, a card services engine, and the like.

The window manager is used for managing window programs. The window manager can acquire the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make such data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebooks, etc.

The telephony manager is used to provide the communication functions of the electronic device 100. Such as the management of call status (including on, hung-up, etc.).

The resource manager provides various resources for the application program, such as localization strings, icons, pictures, layout files, video files, and the like.

The notification manager allows the application to display notification information in a status bar, can be used to communicate notification type messages, can automatically disappear after a short dwell, and does not require user interaction. Such as notification manager is used to inform that the download is complete, message alerts, etc. The notification manager may also be a notification in the form of a chart or scroll bar text that appears on the system top status bar, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, a text message is prompted in a status bar, a prompt tone is emitted, the terminal equipment vibrates, and an indicator light blinks.

The view system includes visual controls, such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, a display interface including a text message notification icon may include a view displaying text and a view displaying a picture.

The system runtime layer (library) can be divided into two parts, namely a system library and an Android runtime.

Android runtime (Android run), an Android running environment, includes a core library and virtual machines. Android run time is responsible for scheduling and management of the Android system. The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. The virtual machine executes java files of the application program layer and the application program framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like.

The system library is a support for an application framework and may include a plurality of functional modules, such as: surface manager (surface manager), media library (media library), two-dimensional graphics engine (e.g., SGL), three-dimensional graphics processing library (e.g., openGL ES), image processing library, etc.

The surface manager is used to manage the display subsystem and provides a fusion of 2D and 3D layers for multiple applications.

Media libraries support a variety of commonly used audio, video format playback and recording, still image files, and the like. The media library may support a variety of audio video encoding formats, such as: MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The two-dimensional graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software for providing essential functions of an operating system such as file management, memory management, process management, network protocol stacks, etc. The inner core layer at least comprises a display driver, a camera driver, an audio driver, a sensor driver, a Bluetooth driver and the like.

For convenience of understanding, the following embodiments of the present application will take an electronic device having a structure shown in fig. 1 and fig. 2 as an example, and specifically describe a card sharing method provided in the embodiments of the present application in combination with the drawings and application scenarios.

The card is a new service display technology, and is widely applied to electronic equipment for displaying service contents.

For example, the card can be embedded into various super APP or interaction scenes, so that the user requirements can be better met, and intelligent service capability is provided. For example, referring to fig. 3 (a), a card may be embedded in the short message APP, and the electronic device may provide instant information and reminders, such as trip information, consumption information, express information, schedule information, commute road conditions, weather conditions, etc., to the user through the card in the short message APP.

For another example, in the dynamic layout, the interface is divided into different areas and implemented by cards, the cards are distributed from the cloud configuration, and the contents of the cards can be dynamically matched with different operation activities, user grouping and the like. Illustratively, referring to (b) in fig. 3, the APP may present the information stream through the card. For example, a card with characters as the main part can be used for displaying the information APP, so that the information is concise and clear, and a user is attracted to click and read quickly; the card with the pictures as the main part can be used for displaying the picture APP, has stronger visual impact and infection, and can attract the attention and click of users; the card with the video as the main part can be used for displaying video APP, has dynamic sense and can bring strong sensory impact force.

Typically, the application program is generated after being encoded by a developer and is released to the terminal device to be operated, and the whole development process can include a development stage and an operation stage. Typically, an application program will preset one or more types of cards during the development phase, which are developed using APIs and interface layouts provided by the operating system, and thus are also referred to as native cards. And in the application program operation stage, the cloud controls the display content of the original cards.

Fig. 4 is a schematic diagram of an example application development process. As shown in fig. 4, in the development process of an application, mainly two phases are included: the development stage and the operation stage relate to interaction among developer equipment, a server side and user side terminal equipment, and specifically can comprise the following steps.

Development stage

Step 1, the developer encodes the card and packages and integrates the card into the application.

Specifically, when developing an application, a developer encodes one or more types of cards (i.e., native cards) using the APIs and interface layout provided by the operating system and packages and integrates into the application. Each of the original cards may be given a name, for example, a card of the style shown in fig. 5 (a) may be named "landscape card", and a card of the style shown in fig. 5 (b) may be named "text card". Different types of cards, the names of which are different; cards with the same name belong to the same card. The original card is cured in the application, and the display effect of the card, the name of the card and the number of card types are all unchanged.

Here, the display effect of the card may be understood as a pattern of the card, and may specifically include a shape of the card, a color of the card (such as a text color, a background color), a position layout of the card module, an icon pattern, a frame pattern, and the like.

And step 2, uploading the application to a server side by the developer.

Run phase

And 3, the server side (or the cloud side) issues the card file to the application on the terminal equipment of the user side.

The card file issued by the server side indicates the card name and the content to be displayed. In some embodiments, the card file may also indicate the size of the card, e.g., width, height.

And 4, analyzing the card file by the application on the user side terminal equipment, and rendering the card.

Specifically, the application can analyze the name of the card and the content to be displayed from the card file, complete the rendering process of the card, and present the card to the user on the terminal device. For example, if the application parses the "landscape card", a card as shown in fig. 5 (a) is displayed in the interface, and the parsed display content is displayed in the card. For another example, if the application parses the "text card", a card as shown in fig. 5 (b) is displayed on the interface, and the parsed display content is displayed on the card. In some embodiments, the application may adjust the width-height style of the card based on the card file.

After the application card is issued, the style displayed in the interface is fixed. For example, after the "horizontal graphics card" shown in fig. 5 is issued to the terminal device on the user side, the style shown in the application interface is fixed to be in the left and right of the figure, and cannot be changed to be in the left and right of the figure. The display content of the card is controlled by the server side.

Because the card style is solidified in the application, the information about the card, which can be acquired by the application, is the name and display content of the card, i.e. the information issued to the application by the server side, if the user wants to share the card of a certain application (such as the card content of a schedule) into other applications, the corresponding card needs to be preset by the other applications to display. That is, if other applications display the same card, the card needs to be written in the code in the development stage of the other applications, so that the other applications can know what style of card is displayed according to the name of the card. For example, the first application is preset with a "landscape graphic card" as shown in (a) of fig. 5, and only if the second application is also preset with a "landscape graphic card" as shown in (a) of fig. 5, the second application receives and displays the same card when the user shares a certain "landscape graphic card" of the first application to the second application. If the second application does not preset the corresponding card, the second application cannot receive the card shared by the first application. Therefore, the requirement that the user wants to flexibly and conveniently realize card sharing cannot be met, and the user experience is seriously affected.

Therefore, the embodiment of the application provides a card sharing method, which can conveniently and flexibly share cards among different application programs so as to meet the sharing requirements of different scenes (such as card resculpting, card collecting and the like), thereby improving the user experience.

Fig. 6 shows a schematic flowchart of a card sharing method provided in an embodiment of the present application. The method 600 shown in fig. 6 may be performed by an electronic device, which may be, for example, the electronic device 100 shown in fig. 1.

In this embodiment of the present application, the electronic device includes a first application and a second application, where the first application is integrated with a first SDK, and the second application is integrated with a second SDK, and functions of the first SDK and the second SDK will be described in the following embodiments with specific steps. As shown in fig. 6, the method 600 may include steps S610 to S650.

S610, displaying an interface of a first application, wherein the interface of the first application comprises a first card.

In some embodiments, the first card may include at least one of the following information elements: pictures, text, video, lists, asterisks, icons, links, music, input boxes, buttons, switches, sliders, maps, timers, clocks, dates and calendars, windows, layout elements.

In the embodiment of the application, everything on the screen of the electronic device that can be described is defined as an information element or a UI element.

Wherein the list is used for displaying a plurality of rows and a plurality of columns of data in one column, and the content displayed by the list can be dynamically changed. The asterisks are used to represent groupings for ease of user lookup. The icons refer to graphic symbols having meaning of reference. The input box is used for inputting words or text information. The button is used to perform a specified one of the actions. The switch is used to present two mutually independent selections or states, e.g. on/off. The slider is used to adjust the discrete values over a range. The map is used to present the current location to the user. The timer is used to perform an accurate count down or count up. The clock is used for displaying the current time. The layout element is a container for holding other information elements, such as a rectangular box (div) of the outermost layer of the card. It is understood that other information elements besides layout elements may also have the function of a container, and thus, in the embodiment of the present application, all information elements with sub-elements may be referred to as containers, and the layout elements are a subset of the containers.

In other embodiments, the first card may support micro-interactions (e.g., hovering a cursor over the first card may trigger display of other content), gesture interactions (e.g., sliding up and down to close the first card), and so forth.

The embodiment of the application does not limit the type, style, carried information and the like of the first card.

And S620, generating first sharing information through the first SDK in response to the operation of sharing the first card to the second application.

In this embodiment of the present application, the first sharing information indicates a card file corresponding to the first card. The card file includes first pattern data and first content data.

The card file can comprehensively describe the style of the first card and the content of the first card displayed to the user. In particular, the first pattern data is used to describe the style of the first card, that is, how the first card is displayed, and may also be referred to as a "card template" or a "template" in the embodiments of the present application; the first content data is used to describe the specific content that the first card delivers to the user, i.e. what the first card displays, and may also be referred to as "card data" or "data" in embodiments of the present application. Therefore, after the card file is converted according to the first card, the first card can be re-carved according to the card file.

The patterns mentioned in the embodiments of the present application, particularly, visual patterns, refer to that the object presents to human visual feelings, including at least one of the shape, structure, size, color, dynamic and static of the object, for example. By way of example, the pattern of the first card may include the shape (e.g., rectangle), color (e.g., white, black, color, etc.), size, location, layout, logical configuration, etc. of the information elements carried by the first card.

In some embodiments, the card file may be a text file. The text file is easy to read and write by a technician, and is convenient for the electronic equipment to read, write and compress the size. The content of the text file may be in plain text format, for example.

In some embodiments, the card file may be a binary file. The binary file has high reliability and saves space. The binary file mentioned in the embodiment of the present application may be understood as a binary description file obtained by compiling and compressing the first type data and the first content data.

In some embodiments, to describe the style of the first card, the first style data may include a hierarchical relationship between information elements in the first card, a location and arrangement of the information elements, and attributes of the information elements.

Hierarchical relationships between information elements include parent-child relationships, sibling relationships, and ancestor-offspring relationships.

If two elements are in adjacent upper and lower levels, then the two elements are in a parent-child relationship. For example, if element a directly contains element b, element a and element b form a parent-child relationship, where the element directly containing the child element (i.e., element a) is the parent element (or parent element), and the element directly contained by the parent element (i.e., element b) is the child element.

If at least two elements have the same parent element, the at least two elements are in a sibling relationship with each other.

If two elements span two or more levels, then the two elements are ancestor offspring, where a group of elements of all levels below an element are its offspring elements, and any parent element of an element and all elements above it are its ancestor elements. The parent element also belongs to the ancestor element, the child element also belongs to the offspring element, and the parent-child relationship is a special case of the ancestor offspring relationship. That is, an element directly or indirectly containing a descendant element is an ancestor element, and an element directly or indirectly contained by the ancestor element is a descendant element. Parent-child relationships and ancestor-offspring relationships describe nested relationships between information elements, and sibling relationships describe parallel relationships between information elements.

In some embodiments, the card file may describe hierarchical relationships between information elements through a syntactic structure. In particular, the card file may have a fixed structure capable of embodying a hierarchical relationship between information elements from which parent-child relationships, sibling relationships, or ancestor offspring relationships that exist between information elements may be resolved.

As one example, the data format of the card file may be JSON format.

JSON is a sequence of markers that contains six constructional characters (left brackets "[", left brackets "{", right brackets "]", right brackets "}", colon ":", comma ","), strings, numbers, and three word denominations (false, null, true).

JSON has two representation structures: objects and arrays. The object structure starts with "{" beginning with "}", the middle part is composed of 0 or more key-value pairs "key/value" separated by ":" between key and value. The object held by the brackets "{ … }" is an unordered set of key-value pairs (i.e., key/value pairs, or name/value pairs). The array structure starts with "[" starts with "]", and consists of 0 or more value lists separated by "". The array held in brackets "[ … ]" is an ordered set of values. The above-mentioned value (value) may be one of a string (string), a number (number), a literal value, an object (object), or an array (array) enclosed by a double-quote (i.e., "). That is, JSON may be nested in multiple layers, so JSON format may express hierarchical relationships between information elements in a first card.

As another example, the data format of the card file may be XML format.

XML is a markup language used to mark electronic files to be structured, and can be used to structure, store, and transfer information. XML allows users to define their own tags. Tags in the XML file are divided into a start tag and an end tag, such as < a > and < a >, and form a pair. A pair of tags and the portion within the tags constitute an element. Several sub-tags can be nested in one tag, the XML file has only one root tag, and other tags are descendant tags of the root tag. That is, XML may be nested in multiple layers, so that XML format may express hierarchical relationships between information elements in a first card.

As yet another example, the data format of the card file may be HTML format.

HTML is a markup language, and HTML documents have a series of HTML elements, consisting of a set of tags and attributes. Tags indicate where an element starts and ends, and attributes describe the characteristics of the element. The tags are wrapped with left brackets (i.e., "<") and right brackets (i.e., ">") including a start tag and an end tag, e.g., < p > and </p > as a pair of tags. HTML elements can be infinitely nested, so HTML format can express the hierarchical relationship between information elements in a first card.

Of course, in other embodiments, the card file may also use other data formats capable of expressing the hierarchical relationship between the information elements in the first card, such as protocol buffers (protocol buffers), YAML, avro, etc., which will not be described in detail herein.

The location and arrangement of the information elements is used to determine the specific location of the information element in the first card, e.g. whether a certain information element is located in the upper left, upper right or middle of the first card, whether a certain information element is superimposed on top of another information element, how the multiple sub-elements under the same parent element are arranged, etc. In the embodiment of the present application, the arrangement manner includes an arrangement in a lateral direction, an arrangement in a longitudinal direction, and a stack in a direction perpendicular to the screen.

As an example, the card file (specifically, the first format data) may include position coordinates of the information elements, that is, the card file expresses the positions and arrangement of the information elements through the position coordinates. Here, the position coordinates may be absolute coordinates or relative coordinates, which are not limited in the embodiment of the present application. For example, the position coordinates of the information element are coordinates (absolute coordinates) on the screen of the electronic device; for another example, the position coordinates of the information element are coordinates (relative coordinates) with the upper left corner of the first card as the origin.

As another example, the location and arrangement of information elements may be expressed according to a layout rule of a container. Each container has its own layout rule, for example, the layout rule corresponding to div is that N elements are laid out from left to right in a rectangular frame, each element has a fixed position in div, and then the sub-elements in div are sequentially filled to the corresponding positions from left to right according to the layout rule of div.

The properties of the information element are used to describe the characteristics of the information element itself, so that it can be characterized what the information element is. An information element may have at least one attribute. For example, the attributes of the information elements may include type, style (e.g., color, size), address, specific content, coordinates, and the like. In a specific implementation, the attributes described in the card file may be determined based on the type of information element. For example, for a picture, its attributes may include type, picture address, picture style; for text, its attributes may include genre, text content.

In some embodiments, the attributes of the information element may include generic attributes and unique attributes. Wherein the general attribute is an attribute that is common to all information elements, such as the "id" attribute and the "type" attribute in example 1 described below are general attributes. The unique attribute is then contrary to the generic attribute, i.e. not all information elements have an attribute that can be considered to be a unique attribute, e.g. "src" attribute in example 1 below is a unique attribute of a picture, a "value" attribute is a unique attribute of text, etc.

For convenience of understanding, the content of the card file corresponding to the first card will be exemplarily shown below taking the first card as an example of a graphic card as shown in fig. 7.

Example 1: JSON format

In example 1, the data format of the card file is JSON format, using a pair of brackets { } wraps. The content included in the "card" field is style data and content data (i.e., first style data and first content data) of the first card. By way of example, generic attributes of an information element may include an identification attribute and a type attribute. Wherein the identification attribute may be described by an "id" field, in particular, the "id" field is used to describe a unique tag of the current information element. The type attribute may be described by a "type" field, and in particular, the "type" field may be used to describe the type of the current information element, such as "image" representing a picture and "text" representing plain text. For a picture, it may include specific attributes, such as source attributes and style attributes. The source attribute may be described by an "src" field, which may be used to describe, in particular, the address of the picture. The style attribute may be described by a "style" field, and in particular, the "style" field may be used to describe the width and height of a picture, etc. For text, it may include a characteristic attribute, such as a value attribute, which may be described by a "value" field, which may be used to describe, in particular, the text content.

With continued reference to example 1 above, the first layer under the "card" field is a parent element, the type of the parent element is "div", and the "child ren" field indicates that the parent element includes child elements, specifically, the parent element includes two child elements, one of which is "image" and the other of which is "text". For the child element "image", its attribute may include "id", "type", "src", "style", etc.; for the child element "text", its attributes may include "id", "type", "value", and the like.

In this example, each information element may have a unique identification (i.e., "id") that is used to tag the current information element. Different information elements have different ids.

In this example, "div" defaults to a lateral layout, the child elements are arranged in a left-to-right direction, so the location and arrangement of the two child elements in the card file is dependent on the layout rules of the parent element "div" (also a container). In other words, since the parent element is "div" and "div" has a default layout rule, the positions and arrangement of the two child elements are determined. In other embodiments, a "position" field or other fields may be added to each sub-element in the card file, so as to describe the position coordinates of each sub-element, and so on.

In the card file, the parent element "div" corresponds to the outermost rectangular frame shown in fig. 7, the child element "image" corresponds to the picture region shown in fig. 7, and the child element "text" corresponds to the text region shown in fig. 7. Note that the dashed boxes shown in fig. 7 are only for marking the picture area and the text area, respectively, and are not displayed on the interface.

It will be appreciated that the fields (which may also be referred to as keywords) in the above examples are merely exemplary, and that in actual practice keywords may be adapted, added, deleted depending on the specific form of the information elements in the first card. For example, in the parent element hierarchy, a keyword for describing whether the border of the rectangular frame is displayed, a keyword for describing the background color of the rectangular frame, or the like may be added. For another example, in the sub-element "text" hierarchy, a keyword for describing a color of a text, a keyword for describing a size of a text, a keyword for describing whether the text is inclined or thickened, and the like may be added.

Example 2: XML format

In example 2, the data format of the card file is XML format, the outer label is < div >, the inner label is < image > and < text >, the outer label and the inner label constitute a parent-child relationship between information elements, and the two inner labels constitute a sibling relationship between information elements. That is, the first XML element < div > is the parent element, and the other two XML elements < image > and < text > are child elements of the parent element. Similar to the JSON format, the tag line also provides attribute information for the information element. In this example, "div" defaults to a lateral layout, the child elements are arranged in a left-to-right direction, so the location and arrangement of the two child elements in the card file is dependent on the layout rules of the parent element "div". In other embodiments, a "position" attribute may be added to the tag line corresponding to each sub-element in the card file, so as to describe the position coordinates of each sub-element, and so on.

In the card file, the outer layer label < div > corresponds to the outermost rectangular frame shown in fig. 7, and the inner layer labels < image > and < text > correspond to the picture area and the text area shown in fig. 7, respectively.

Similar to example 1, in example 2, the attributes in the tag line are merely exemplary, and in actual application, the attributes may be adapted, added, and deleted according to the specific form of the information element in the first card. For example, in the outer label, an attribute for describing whether or not the border of the rectangular frame is displayed, an attribute for describing the background color of the rectangular frame, or the like may be added. For another example, in the inner label < text >, an attribute for describing a color of a text, an attribute for describing a size of a text, an attribute for describing whether a text is inclined or thickened, and the like may be added.

In some embodiments, as shown in examples 1 and 2 above, the card file corresponding to the first card may be a complete file (or understood as a document), i.e., the first type data and the first content data may be saved by one file.

Thus, each card can be provided with a corresponding file for storing style data and content data, and the storage, transmission and searching of the electronic equipment are convenient. In addition, the second application may apply the card file directly to the interface in displaying the first card according to the card file.

In some embodiments, as shown in examples 1 and 2 above, the first pattern data and the first content data may not be clearly distinguished. Alternatively, the first pattern data and the first content data are not separated in the same file.

In other embodiments, the first pattern data and the first content data may be separate in the same file, as illustrated in example 3 below.

Example 3:

/>

in example 3, the first type data and the first content data are stored in the same document, but are located under two fields side by side, for example, the first type data under the "template" field and the first content data under the "data" field, which may be bound to the first type data at the time of rendering. In this embodiment of the present application, the first type data is related to a style of the first card, and the first content data is related to information displayed by the first card, and in a specific implementation, the division of the first type data and the first content data may be determined according to actual needs, which is not strictly limited herein.

In some embodiments, the information element in the first card may include a first information element including at least one attribute including an attribute name and an attribute value, wherein the attribute value of one or more of the at least one attribute is a placeholder and the first content data includes an actual value corresponding to the placeholder.

That is, in the first pattern data, the attribute values of one or more attributes of the first information element are represented by placeholders, and the first content data may include actual values corresponding to the placeholders. Still alternatively, it may be understood that the attributes of the information element may include attributes related to style, such as size attributes, and may also include attributes related to content, such as "src" attributes of a picture, a "value" attribute of a text, etc. as shown in example 3, the first style data may indicate which attributes the information element has, wherein the attribute values of some or all of the attributes are placeholders, and the actual values of the attribute values may be stored in the first content data.

In an embodiment of the present application, the information element in the first card may include at least one first information element. That is, some or all of the information elements in the first card may have attribute values of some or all of the attributes stored in the first content data.

In other embodiments, the first pattern data and the first content data may be two files in separate forms. In other words, the card file corresponding to the first card may include a first file for storing the first pattern data and a second file for storing the first content data. For illustration, reference is made to example 4 below.

Example 4:

the first pattern data stored in the first file is as follows:

the first content data stored in the second file is as follows:

example 4 may be understood as storing the first type data and the first content data in example 3 separately, wherein the first file stores the content under the "template" field in example 3 and the second file stores the content under the "data" field in example 3.

The style of the card is generally fixed, the content of the card can be dynamically changed, the first style data and the first content data are respectively stored through two files, the second application can store the style of the first card, so that when the first application shares another card with the same style as the first card, the first application can only send the content data of the other card, and the second application can combine the content data of the other card with the first style data to render the other card.

In this embodiment of the present application, the data format of the first file may be the same as or different from the data format of the second file. For example, the data format of the first file and the second file are both JSON, XML or HTML, or the data format of the first file is one of JSON, XML or HTML, and the data format of the second file is the other of JSON, XML or HTML.

In some embodiments, the data format of the card file includes at least one of: JSON format, XML format, HTML format.

In this embodiment of the present application, the first sharing information indicates a plurality of modes with the card file.

As one example, the first shared information may include a storage path for the card file. That is, the electronic device may store the card file locally, so that the card file may be obtained through a storage path of the card file. It is understood that when the first pattern data and the first content data are not stored separately, the card file is one file, and the storage path of the card file is one piece. When the first pattern data and the first content data are stored separately, the card file includes a first file and a second file, and accordingly, the storage path of the card file is two.

As another example, where the card file includes a first file and a second file, the first file and the second file may be located under the same folder, and the first sharing information may include a previous-level folder path of the card file. The folder where the card file is located can be found through the first sharing information, and then the card file can be found.

As yet another example, the first sharing information may include a file name of a card file, where the card file is stored in a preset save location. That is, the application may store the card file in a preset save location (e.g., under a preset folder), and the file names under the same file are necessarily different, so that the card file can be found in the preset save location by the file names of the card file. It is understood that when the first pattern data and the first content data are not stored separately, the card file is one file, and the file name of the card file is one file. When the first pattern data and the first content data are stored separately, the card file includes a first file and a second file, and accordingly, the file name of the card file includes two.

In some embodiments, where the card file includes a first file and a second file, the previous level folders of the first file and the second file may be the same or different. For example, the first file and the second file may be both stored in a preset folder, or may be stored in two preset folders, which is not limited in the embodiment of the present application.

In some embodiments, the card file may be stored in a common memory space of the electronic device. In particular, the common storage space may be used for any application on the electronic device to store data, and accordingly, any application may access the common storage space. Thus, the first application stores the card file in the common storage space, from which other applications (e.g., the second application) can retrieve the card file.

In other embodiments, the card file may be stored in a memory space of the first application while the first application opens access rights to the second application. Thus, the second application can access the storage space of the first application according to the first sharing information so as to acquire the card file.

In the above-described example, the card file is stored locally, and when the first application sends the first sharing information to the second application, the card file does not need to be directly sent, so that the data transmission amount can be reduced.

As yet another example, the first shared information may include a card file. That is, the first application may directly share the card file to the second application. In this way, the card file may be stored in a common storage space of the electronic device, or may be stored in a storage space dedicated to the first application. The second application which receives the card file can directly process according to the card file, and the operation flow is simple.

In this embodiment of the present application, there are various ways in which the electronic device generates the first shared information through the first SDK.

As an example, in response to an operation of sharing the first card to the second application, the electronic device first obtains a card file by parsing information elements on the first card; and then storing the card file through the first SDK to generate first sharing information.

That is, after the user performs the operation of sharing the first card with the second application, in response to the operation, the electronic device may parse the information element on the first card to obtain the card file, specifically, obtain the first type data and the first content data. After the card file is obtained, the electronic device may store the card file locally through the first SDK, and accordingly, information such as a storage path of the card file, a file name of the card file, a previous-level folder path of the card file, and the like mentioned in the above example may be naturally obtained, so that the first sharing information may be generated.

In some embodiments, the electronic device may parse the information element on the first card through a system capability of the electronic device to obtain a parsing result; and converting the analysis result into a card file through the first SDK.

The operating system of the electronic device has the capability of parsing the elements of the interface, i.e. which elements and the content of the elements are in the interface, e.g. the parsing type is a picture or text, and may parse the content of the picture and text. This way the information elements within the first card can be parsed by the system capabilities of the electronic device. The SDK of the first application can convert the result analyzed by the operating system into the card file according to the rule, format and the like of the card file, so that the second application can be conveniently etched.

As another example, in response to an operation of sharing the first card to the second application, the electronic device reads the card file through the first SDK to generate the first sharing information.

That is, the card file may be stored locally, and when the first card needs to be shared to the second application, the first SDK reads the card file corresponding to the first card, and accordingly, the first sharing information includes the card file.

In some embodiments, the card file may be stored locally prior to the first SDK reading the card file.

As an example, the electronic device may parse the information element on the first card through the system capability of the electronic device to obtain a parsing result; converting the analysis result into a card file through a first SDK; and storing the card file through the first SDK.

As another example, the electronic device may obtain the card file from a server or cloud corresponding to the first application. That is, the card file may be well developed in the development stage, and the server or the cloud corresponding to the first application may issue the card file to the first application, and the first SDK stores the received card file locally.

Since the first sharing information includes the card file, the storage location of the card file is not limited when the first SDK stores the card file. For example, the card file may be stored in random access memory (random access memory, RAM). For example, the card file may be stored in a register, memory, cache, or hard disk.

By way of example and not limitation, the first SDK may write and read card files by calling a system API.

For example, assuming that the system provides a file () API, the first SDK may call when storing the card file:

1) Taking the card file shown in example 1 as an example

File.write(“card.json”)

That is, the card file in example 1 is stored with a file name of card.

2) Taking the card file shown in example 2 as an example

File.write(“card.xml”)

That is, the card file in example 2 was stored with a file name of card.

3) Taking the card file shown in example 4 as an example

File.write(“card.json”)

File.write(“data.json”)

That is, the first-type data in example 4 is stored with a file name of card. The first content data in example 4 is stored with a file name of data.

For example, assuming that the system provides a file () API, the first SDK may call when reading the card file:

1) Taking the card file shown in example 1 as an example

File.read(“card.json”)

That is, the card file in example 1 was read with a file name of card.

2) Taking the card file shown in example 2 as an example

File.read(“card.xml”)

That is, the card file in example 2 was read with a file name of card.

3) Taking the card file shown in example 4 as an example

File.read(“card.json”)

File.read(“data.json”)

That is, the first-type data in example 4 is read, and the file name is card. The first content data in example 4 is read with a file name of data.

In some embodiments, the operation of sharing the first card to the second application may be a click operation, a long press operation, a sliding operation, or other operations of the user, which is not limited in this embodiment of the present application.

S630, the first sharing information is sent to the second application by the first application.

In some embodiments, the electronic device may send the first shared information from the first application to the second application through the system sharing capability.

Electronic devices typically have shared system capabilities that enable text or binary content to be shared between two applications. Therefore, taking the example that the first sharing information includes the card file, the card file may be transmitted to the second application through the system sharing capability provided by the electronic device. Specifically, the first application (specifically, the first SDK) may tell the operating system, through calling an API of the operating system, that the content and the sharing type are to be shared, and the operating system may start the target application (i.e., the second application) according to the sharing type (e.g., the "card type"), and transmit the content (e.g., the card file) to be shared to the second application. Or, the operating system may present a plurality of applications capable of receiving the card to the user, so as to facilitate the user to select the target application from the plurality of applications, and then restart the target application by the operating system, and transmit the content to be shared to the target application.

In some embodiments, the second application (specifically, the second SDK) may tell the operating system that the second application itself may receive the sharing of the card type data when the second application is installed, and when the user needs to share the card of the first application with the second application, the operating system may support transmitting the card file to the second application.

Similarly, when the first sharing information does not directly include the card file, but includes information indirectly indicating the card file (for example, a storage path of the card file, a file name of the card file, a previous folder path of the card file, etc.), the content included in the first sharing information may also be transmitted through the sharing capability of the system.

In other embodiments, if the card file is a binary file, the binary content is shared when the card file is shared with the system capability.

S640, based on the first sharing information, the card file is obtained through the second SDK.

And according to different contents included in the first sharing information, different modes of acquiring the card file through the second SDK are adopted.

As an example, if the first sharing information includes a card file, the second SDK directly obtains the card file.

As another example, if the first sharing information includes the aforementioned storage path of the card file, the second SDK reads the card file according to the storage path of the card file.

As yet another example, if the first sharing information includes the previous-level folder path of the card file, the second SDK may find the previous-level folder of the card file according to the previous-level folder path of the card file, and read the card file from the previous-level folder.

As yet another example, if the first sharing information includes the file name of the card file, the second SDK may read the card file in a preset storage location according to the file name of the card file.

In this step, if the second SDK needs to read the card file, the second SDK may read the card file by calling the system API. The process of reading the card file by the second SDK is similar to the process of reading the card file by the first SDK described above, and specific reference may be made to the above related examples, which are not repeated herein for brevity.

S650, displaying the first card on the interface of the second application according to the card file.

After the second SDK of the second application obtains the card file, card rendering can be performed according to the card file, so that the first card is displayed on the interface of the second application. The card file fully describes the style and the content of the first card, so that the first card can be re-carved in the interface of the second application.

For example, the second SDK may parse the specific content of the card file gradually from top to bottom, and sequentially create information elements on the interface, and after the card rendering is completed, the first card may be displayed on the interface of the second application.

In some embodiments, if the first pattern data and the first content data are separate, such as shown in examples 3 and 4, the second SDK needs to parse out the first pattern data and the first content data, respectively, and then fill the first content data into the corresponding locations.

For easy understanding, taking the card file shown in example 4 as an example, after the second SDK obtains the card file, the second SDK first analyzes the first file, and creates a corresponding information element on the interface of the second application according to the type of the information element; after the first file is processed, the second SDK analyzes the second file, and the obtained data is filled in placeholders in the data of the first type. In this way, the second SDK builds the first card using the first file and the second file.

That is, the electronic device creates an information element at an interface of the second application through the second SDK according to a result of parsing the first file by the second SDK, wherein an attribute value of one or more attributes of the at least one attribute of the first information element is a placeholder. And the electronic equipment applies the actual value corresponding to the placeholder to the interface of the second application through the second SDK according to the analysis result of the second SDK on the second file.

In some embodiments, if the card file is a complete file and the first content data is already filled in the corresponding location, for example, as shown in examples 1 and 2, the second SDK may directly apply the parsing result to the interface of the second application during the parsing and rendering process, without separately parsing a piece of content data.

It should be noted that, the functions of the first SDK and the second SDK in the embodiments of the present application may be the same or different.

For example, if the first application may also receive the card shared by other applications, the first SDK executes the steps executed by the second SDK described above in the process that the first application receives the card shared by other applications. If the second application can also share the card with other applications, the second SDK executes the steps executed by the first SDK described above in the process that the second application shares the card with other applications. In this case, the functions of the first SDK and the second SDK are actually the same, except for the steps performed in the process of the application sharing the card and the process of the application receiving the card.

For another example, if the first application can only share the card with other applications and cannot receive the card shared by other applications, the first SDK has no function of the second SDK. If the second application can only receive the card shared by other applications and cannot share the card with other applications, the second SDK has no function of the first SDK. In this case, the functions of the first SDK and the second SDK are different.

Of course, in order to enable the card application (i.e. the application related to the card) to share the card conveniently and quickly, in a specific implementation, the card application may integrate a card rendering SDK with the same function. Therefore, the user operation application can share the card with other applications, and quick re-engraving of the card is realized.

In some embodiments, the second application may be a card collector for collecting cards of other applications. By the card sharing method, the cards can be conveniently and rapidly collected into the card collector, and user experience is improved.

In the embodiment of the application, the lightweight rendering SDK is integrated in the application, the SDK in the first application can convert the card file corresponding to the first card, and the first application sends the first sharing information indicating the card file to the second application. And the SDK of the second application can render the first card according to the card file after acquiring the card file according to the first sharing information. Therefore, interfaces can be copied among applications in the electronic equipment system, the requirements of users on card reproduction and card collection are met, and the user experience is improved.

Further, for better understanding of the present application, the following describes a card sharing method provided in the embodiment of the present application by referring to fig. 8 to 11 as specific non-limiting examples.

Fig. 8 shows an application scenario diagram provided in an embodiment of the present application. As shown in fig. 8, a first application is integrated with a first SDK and a second application is integrated with a second SDK. The interface of the first application (hereinafter referred to as a first application interface for convenience of description) displays a first card, and the first card displayed on the first application interface is an original card. After the user clicks or long presses to start sharing, by using the card sharing method provided by the application, a card with the same content can be displayed on the interface of the second application (for convenience of description, the card is hereinafter referred to as a second application interface), and the card displayed on the second application interface is a re-etched card of the first card.

It is understood that applications that the electronic device can run include, but are not limited to, a first application and a second application, and further applications may be run in the electronic device, which is not limited in this embodiment of the present application.

Fig. 9 shows a schematic flowchart of a card sharing method provided in an embodiment of the present application. The method 700 shown in fig. 9 is a specific example of the method 600. As shown in fig. 9, the first application integrates a first SDK and the second application integrates a second SDK, and the method 700 may include steps S701 to S709.

S701, the first application interface displays the original card.

Here, the original card is a shared card, which is a specific example of the first card.

S702, a user starts a card sharing function.

For example, the user may initiate the card sharing function by pressing a card long at the first application interface, clicking on a menu, clicking on a card, sliding a card, and so on.

S703, the first application reads the card template and the card data through the first SDK.

Here the card template is a specific example of the aforementioned first pattern data, specifying the location and pattern of specific information elements to define the frame of the original card. The card data is a specific example of the aforementioned first content data for populating the content in the frame.

In this embodiment, the card template and the card data are separate files, for example, the card template may include the first pattern data shown in example 4, and the card data includes the first content data shown in example 4. Here, the card template is a structured text file, and the card data is also a structured text file. The structured text file mentioned in the embodiments of the present application may be understood as text content having a fixed structure.

Specifically, in this step, the first application invokes the interface of the first SDK to read the card template and the card data. In general, terminal systems provide APIs for reading and writing files so that applications can access files and data in the storage system. The card template and the card data in the embodiment of the application are files stored in the system by the first SDK through calling the system API. Accordingly, the first SDK may also read the card template and card data by calling the system API.

Fig. 10 shows a schematic diagram of the first SDK writing and reading card templates and card data.

As shown in fig. 10, after the user starts the card sharing function on the first application interface, the first SDK may start the capability of the operating system to parse the interface elements, and the operating system may parse which information elements and the specific contents of the information elements are in the first card. The first SDK may convert the parsing result of the operating system into the card template and the card data according to a preset rule (e.g., the preset rule specifies which keywords are included in the card template and a hierarchical relationship between the keywords, etc.). After the conversion is completed, the first SDK may call an API (e.g., file. Write ()) provided by the system for file writing to store the card template and card data in the file storage area.

Alternatively, the card template and card data may be stored in the file storage area prior to the user initiating the card sharing function. Then after the user initiates the card sharing function at the first application interface, the first SDK may call an API (e.g., file read ()) provided by the system for file reading to read the card template and card data from the file storage area.

With continued reference to fig. 9, the first SDK may form the read card template and card data into a formatted text, which may be, for example, as follows:

s704, the first application delivers the shared content to the second application through the system capability.

Here, the shared content may be the formatted text in step S703, which is a specific example of the "first shared information" in the foregoing embodiment.

In this step, the first application uses system capabilities (i.e., system sharing capabilities) in sharing text to the second application. Modern terminal devices all have shared system capabilities, which can share text or binary content. This step uses the ability to share text. In some embodiments, in a particular implementation, the delivery of shared content may use the following parameters:

sharing text: { "template": "content of card template", "data": "content of card data" }

Sharing type: card and card

The terminal system (i.e., the operating system) may launch the second application according to the "sharing type" parameter, or present the plurality of target applications to the user, and launch the second application according to the operation of the user to select the second application from the plurality of target applications. Here, the target application may be an application integrating a card rendering SDK (e.g., a first SDK or a second SDK).

And S705, the second application decomposes the card template and the card data from the shared content through the second SDK.

For example, the second SDK may obtain the card template and card data by parsing the "share text" parameter. Taking the example illustrated in step S704 as an example, the second SDK may parse the card template from the "template" field and parse the card data from the "data" field.

S706, the second SDK analyzes the card template and creates information elements according to the type.

The second SDK may parse the contents of the card template step by step from top to bottom, creating information elements according to the types of the respective information elements.

S707, the second SDK binds the card data to the information element.

In this step, the second SDK parses the card data and fills the resulting data into the card template.

For ease of understanding, a detailed process of rendering the card by the second SDK will be described below taking as an example the card template including the content in the first file in example 4 and the card data including the content in the second file in example 4.

The second SDK analyzes the card template:

1) Parsing the "card" field from the text, ending if not present, and continuing parsing the contents of the "card" field if present;

2) The "id" field is parsed to determine if there is an id for the markup root layout. Ending if not, and continuing to parse the next field if so;

3) The "type" field is parsed and specific information elements are created from the values. Such as div, creating a rectangular box;

4) Parsing the "child" field, ending if not present, and continuing parsing the contents in the "child" field if present;

5) Analyzing an 'id' field of the first sub-element, and determining the position of the first sub-element;

6) Parsing the "type" field of the first sub-element, image representing creation of a picture component (i.e., the information element is a picture);

7) Analyzing the 'src' field of the first subelement, wherein the picture component has the src attribute, the attribute value is a placeholder, the format is $ { placeholder }, the attribute value of the placeholder is used for waiting for the card data to be calculated to obtain an actual value for re-application;

8) Analyzing the style field of the first sub-element to obtain a width value and a height value of the picture, and applying the width value and the height value to the picture component in the step 7);

9) Resolving the "id" field of the second sub-element, and determining the position of the second sub-element;

10 Parsing the "type" field of the second sub-element, text representing creating a text component (i.e., the information element is text);

11 Analyzing the value field of the first sub-element, wherein the text component has a value attribute, the attribute value is a placeholder, the format is $ { placeholder }, the attribute value of the placeholder is used for waiting for the card data to be calculated to obtain an actual value for application;

the second SDK analyzes the card data:

1) The second SDK acquires a value named as 'imageUrl' from the card data and fills the value into a picture component with id of 2;

2) The second SDK obtains the value named 'name' from the card data and fills the value into the text component with the id of 3.

In some embodiments, an attribute set may be preset for an information element, for example, the attribute set may include an id attribute, a type attribute, a style attribute, an src attribute, a value attribute, and the like, and the number of attributes that different types of information elements have may be different, for example, a picture may have an id attribute, a type attribute, a style attribute, an src attribute, and a text may have an id attribute, a type attribute, a value attribute.

And when the second SDK analyzes the card template, sequentially analyzing the contents in the card template from top to bottom. Specifically, the second SDK parses each attribute of the root element first, and if the root element includes a sub-element, the second SDK parses each attribute of the sub-element, respectively. Wherein the attribute value of the non-placeholder is directly applied to the component, and the attribute value of the placeholder is applied after waiting for the actual value obtained after the card data is calculated. After the card template is processed, the second SDK analyzes the card data, and the obtained data is used for filling the occupation value in the template. The second SDK can then construct a card using the card template and card data.

It should be noted that, among the above-mentioned attributes, some attributes are common to the information elements, such as an id attribute, a type attribute, etc., and such attributes may be referred to as general attributes, and some attributes are specific to the information elements, such as an src attribute, a value attribute, etc., and such attributes may be referred to as specific attributes.

In the embodiment of the application integrated lightweight rendering SDK, the first SDK may read the card template and card data of the original card, convert the card template and card data into plain text, and transmit the plain text to the target application (i.e., the second application) through the system capability. And integrating the second SDK analysis text by the target application to generate a card. Therefore, interfaces can be copied among all applications in the electronic equipment system, and card collection and sharing are achieved.

Fig. 11 is a schematic diagram illustrating another card sharing method according to an embodiment of the present application. The method 800 shown in fig. 11 is a specific example of the method 600. As shown in fig. 11, the first application integrates a first SDK, the second application integrates a second SDK, and the method 800 may include steps S801 to S803.

S801, the first application writes the card template and the card data into an xml file through the first SDK and stores the xml file in the file storage area.

Illustratively, the xml file may include the contents of example 2 described above, so the card template and card data are not in separate forms, and the xml file does not include attribute values of the placeholder type.

S802, the first application sends the file name or the storage path of the xml file to the second application.

For example, when the xml file is stored in the preset storage location, the first application may send the file name of the xml file. Alternatively, the first application sends the storage path of the xml file to the second application.

S803, the second application reads the xml file through the second SDK and performs card rendering.

And the second SDK analyzes the label in the xml file to obtain a corresponding information element. Such as < image > corresponds to a picture and < text > corresponds to text. The tag row carries the attributes of the information element. The outer label and the inner label constitute a parent-child relationship between the information elements.

For ease of understanding, the detailed process of rendering the card by the second SDK will be described below taking the xml file including the contents of example 2 as an example.

1) The second SDK analyzes the external layer < div > tag and creates a rectangular frame on the interface of the second application;

2) The second SDK analyzes an inner layer < image > tag, adds a picture component in a rectangular frame, applies src and a style, and displays an actual picture;

3) The second SDK analyzes the inner layer < text > tag, adds a text component in the rectangular box, applies text content and displays the text component to the interface.

In this embodiment, the first application stores the card template and the card data to be shared as one file, and only shares the file name or the storage path to the second application, so that the size of the shared content can be reduced. And, the second application may be directly applied to the interface in the parsing and rendering process after reading the xml file.

In the embodiment of the application, the SDK of the first application may convert the card file into a local file, and transfer the file name or the storage path to the target application, where after the target application reads the file, a new card may be generated by analyzing the content.

It is to be understood that the foregoing is only illustrative. In other embodiments, in the method 700 shown in fig. 9, the card data and the card template in the separated form may be shared to the second application by using the method shown in fig. 11, and in the same manner, in the method 800 shown in fig. 11, the card data and the card template that are not separated may be shared to the second application by using the method shown in fig. 9, which is not described in detail herein.

When the functions of the first SDK and the second SDK mentioned in the foregoing embodiments are the same, the SDKs having the functions of the first SDK and the second SDK may be collectively referred to as a card rendering SDK, and the card rendering SDK may be integrated in an application, and be used for acquiring a card file (for example, a card template and card data) in a process that the application shares a card with other applications, and also for converting the card file into a UI interface of the card when the application receives the card shared by other applications.

Exemplary, fig. 12 shows a functional schematic of the card rendering SDK provided in the embodiment of the present application. As shown in fig. 12, taking an example that the card file includes a separate card template and card data, the card rendering SDK may acquire the card template and the card data according to the UI interface of the card, or may render the UI interface of the card according to the card template and the card data. As shown, the UI interface of the card may be a rectangular box with the text "Hello" displayed therein. In some embodiments, the application may obtain the card file through the card rendering SDK.

For example, the content of the card template may be:

for example, the content of the card data may be:

{

“name”:“Hello”

}

in some embodiments, if the application receives a card file as listed above, the card rendering SDK may also convert the card file to a UI interface as shown in fig. 12.

In this example, the manner in which the card rendering SDK obtains the card file according to the UI interface and the manner in which the UI interface is rendered according to the card file may refer to the related content in the foregoing embodiment, which is not described in detail for brevity.

In the embodiment of the application, the card of any style shared by other applications can be displayed by integrating the card rendering SDK provided by the embodiment of the application, so that card copying or card collection is realized.

In some embodiments, the card rendering SDK also has the functions of storing card files, reading card files, invoking system capabilities.

Fig. 13 is a schematic flowchart of another card sharing method according to an embodiment of the present application. The method 900 shown in fig. 13 may be performed by an electronic device, which may be, for example, the electronic device 100 shown in fig. 1. In the embodiment of the application, the electronic device comprises a first application and a second application, wherein the first application is integrated with a first SDK, and the second application is integrated with a second SDK. As shown in fig. 13, the method 900 may include steps S901 to S911.

S901, displaying an interface of a first application, wherein the interface of the first application comprises a first card.

The step S610 is the same as the step S610 in the method 600, and the detailed description of the step S610 is referred to herein for brevity.

S902, in response to the operation of sharing the first card to the second application, first sharing information is generated through the first SDK.

This step is similar to step S620 in the method 600, except that the method 600 is not limited to the storage manner of the first type data and the first content data in the card file, and in the method 900, the card file includes a first file and a second file, where the first file is used to store the first type data, and the second file is used to store the first content data.

In addition, the first sharing information further comprises a first identifier, and the first identifier corresponds to the first type data in the card file. The first identifier is used for identifying the style of the first card, and if the style of the other card is the same as the style of the first card, the first identifier is also used for identifying the style of the other card. That is, cards of the same style correspond to the same logo, the or one logo corresponds to one card style, and different card styles correspond to different logos.

For example, the identifier corresponding to the card style may be a name of the card, such as a name defined by a developer in a card development stage, for example, "text card", "list card", "graphic card", "landscape card", and the like. Alternatively, the identifier corresponding to the card style may be an identifier that is represented by a numerical value, text, symbol, etc. and is customized by an application, for example, the first identifier may be defined by a first SDK, for example, be "first application-style 1", or be a random name.

In some embodiments, the identification for identifying the card style is unique in the electronic device.

Here, the electronic device may further fixedly store the first pattern data and the first identifier through the first SDK, for example, in an external memory of the electronic device, and may still store the data even if the electronic device is powered off.

For the rest of the step S902, reference may be made to the related description of the step S620, which is not repeated herein for brevity.

S903, the first sharing information is sent to the second application by the first application.

The step is the same as the step S630 in the method 600, and the detailed description of the step S630 is referred to herein for brevity.

S904, based on the first sharing information, the card file is obtained through the second SDK.

The card file includes first pattern data and first content data.

The step is the same as step S640 in the method 600, and the detailed description of step S640 is referred to herein for brevity.

S905, displaying the first card on the interface of the second application according to the card file.

The step S650 is the same as the step S650 in the method 600, and the detailed description of the step S650 is referred to herein for brevity.

S906, storing the first identification and the first type data through the second SDK.

It is to be understood that step S906 may be performed simultaneously with step S905, or may be performed before or after step S905, which is not limited in the embodiment of the present application.

S907, displaying an interface of the first application, wherein the interface of the first application comprises a second card.

This step is similar to step S901 and step S610, wherein the description about the first card applies equally to the second card. For details, reference may be made to the descriptions of the step S901 and the step S60, and the details are not repeated here for brevity.

Here, the pattern of the second card is the same as the pattern of the first card. That is, the templates of the first card and the second card are the same, and the content may be different.

S908, generating, by the first SDK, second sharing information in response to the operation of sharing the second card to the second application.

In the embodiment of the application, the second sharing information indicates second content data corresponding to the second card.

In this step, in response to the operation of sharing the second card with the second application, the electronic device may first obtain, through the first SDK, a card file corresponding to the second card, which is referred to as a second card file for convenience of description, and correspondingly, for distinction, a card file corresponding to the first card mentioned in the above embodiment is referred to as a first card file. Similar to the first card file, the second card file can fully describe the style of the second card and the content that the second card presents to the user. For example, the and second card file may include second style data describing the style of the second card, i.e., describing how the second card is displayed, and second content data describing the specific content the second card delivers to the user, i.e., describing what the second card is displaying. The manner of acquiring the second card file is similar to that of acquiring the first card file in step S620, and the detailed description in step S620 may be referred to for brevity and will not be repeated.

Here, in the second card file acquired by the second SDK, the second style data and the second content data are two files in a separated form.

In this embodiment of the present invention, the first SDK may determine whether the styles of the two cards are the same, for example, the first SDK may determine that the style of the second card is the same as the style of the first card according to the first style data and the second style data. Thus, when the first application shares the second card with the second application, only the second content data can be shared, and the second application is indicated that the second card has the same style as the first card.

Thus, in this step, the second sharing information may indicate the second content data. For example, the second sharing information may directly include second content data; or the second sharing information may include a storage path of the second content data, a file name of the second content data in a preset save location, etc. to instruct the second SDK to read the second content data to the corresponding location.

In addition, the second shared information further includes a first identification for the second SDK to acquire the first pattern data.

S909, the second sharing information is sent from the first application to the second application.

And S910, acquiring second content data and first type data through a second SDK based on the second sharing information.

Wherein the first pattern data is obtained based on the first identification. Since the second application stores the first identifier and the first pattern data in step S906, the second SDK may acquire the first pattern data according to the correspondence between the first identifier and the first pattern data in step S.

And S911, displaying a second card on the interface of the second application according to the first type data and the second content data.

The step is similar to step S905 and step S650, and reference is made to the descriptions of steps S905 and S650 for brevity.

In some embodiments, the form of the first card file acquired by the first SDK may not be limited, that is, the first card file may be a complete file including the first pattern data and the first content data, and the second SDK extracts the first pattern data that can be stored separately according to the acquired first card file.

Similarly, in some embodiments, the form of the second card file acquired by the first SDK may not be limited, that is, the second card file may be a complete file including the second style data and the second content data, and the second SDK determines that the style of the second card is the same as the style of the first card according to the acquired second card file, and extracts the second content data that can be used for rendering the card.

In some embodiments, the method 900 may further include, prior to the electronic device generating the second shared information via the first SDK:

sending a first message to a second SDK through the first SDK, wherein the first message is used for requesting the identification of a card supported by the second application;

and receiving, by the first SDK, a second message from the second SDK, the second message including an identification of a card supported by the second application, wherein the identification of the card supported by the second application includes the first identification.

That is, the first application may first request the identity of the card supported by the second application before the first application shares the specific content of the second card with the second application. Wherein the identification of the card supported by the second application indicates the style of the card that the second application is capable of displaying. When the second application can display the corresponding card style of the first identifier, the second application is indicated to store the first style data, and the first application can share only the second content data without sharing the second style data with the second application. The second application may apply the second content data to the pattern of the first card, thereby displaying the second card. In this way, the size of the shared content can be reduced.

In some embodiments, before the electronic device generates the first shared information through the first SDK, the method 900 or the method 600 may further include:

And determining that the first identifier is not included in the identifiers of the cards supported by the second application through interaction between the first SDK and the second SDK.

For example, the electronic device sends a first message to the second SDK through the first SDK requesting identification of the card supported by the second application. The electronic device receives a second message from a second SDK through the first SDK, the second message including an identification of a card supported by the second application.

That is, the first application may first request the identity of the card supported by the second application before the first application shares the specific content of the first card with the second application. Thus, the first application can determine the specific content shared to the second heroic based on the feedback from the second application.

In this embodiment of the present application, the interaction between the first SDK and the second SDK may be implemented by calling a system capability, for example, the first SDK calls the system capability to send a first message to the second application, and the second SDK calls the system capability to send a second message to the first application.

The card sharing method provided in the above embodiment can be applied to sharing cards among different application programs of the same device, and also can be applied to sharing cards across devices. That is, the first application and the second application in the above embodiments may be installed on different electronic devices, for example, the first application may be installed on the first electronic device, the second application may be installed on the second electronic device, and the card may be shared between the first application and the second application. The process of sharing cards across devices is similar to the process of sharing cards with devices, and only the differences will be described in detail with reference to fig. 14, and the remainder of the description will be made with reference to the above.

Fig. 14 shows a schematic flowchart of a card sharing method provided in an embodiment of the present application. The method 1000 shown in fig. 14 may be applied to a communication system that includes a first electronic device that includes a first application that is integrated with a first SDK and a second electronic device that includes a second application that is integrated with a second SDK. As shown in fig. 14, the method 1000 may include steps S1010 to S1050.

S1010, the first electronic device displays an interface of a first application, wherein the interface of the first application comprises a first card.

The step is similar to step S610 in the method 600, and the detailed description of step S610 is referred to herein for brevity.

And S1020, the first electronic device responds to the operation of sharing the first card to the second application and generates first sharing information through the first SDK.

The first sharing information indicates a card file corresponding to the first card. The card file includes first pattern data and first content data.

This step is similar to step S620 in method 600, and the differences will be mainly described below, and the remainder will be described with reference to step S620.

As an example, the first shared information may include a storage path of the card file in a cloud space, where the cloud space is shared by the first electronic device and the second electronic device. The first electronic device can store the card file in the cloud space, and the second electronic device can acquire the card file through a storage path of the card file in the cloud space because the second electronic device can also share the cloud space.

As another example, the first shared information may include a file name of a card file, wherein the card file is stored in a preset save location in cloud space, the preset save location being accessible by the first application and the second application. That is, the first application may store the card file in a preset save location (e.g., under a preset folder) in the cloud space, and the file names under the same file are necessarily different. The second application may also access the preset save location, so the second application may find the card file at the preset save location by the file name of the card file.

In the above-described example, the card file is stored in the cloud space, and when the first application sends the first sharing information to the second application, the card file does not need to be directly sent, so that the data transmission amount can be reduced.

As yet another example, the first shared information may include a card file. That is, the first application may directly share the card file to the second application. The second application which receives the card file can directly process according to the card file, and the operation flow is simple.

And S1030, the first electronic device sends the first sharing information to the second electronic device.

Specifically, a first application on a first electronic device sends first sharing information to a second application on a second electronic device.

By way of example and not limitation, the first application may send the first shared information to the second application via mail or short range wireless communication technology (e.g., bluetooth, zigbee, wireless fidelity (wireless fidelity, wiFi), etc.). For example, using mail transfer as an example, the first application may send the card file to a mail application on the first electronic device and send the card file as an attachment to the recipient. The mail application on the second electronic device can receive the card file and read the card file through the second application, so that sharing of the card file between the first application and the second application is completed.

S1040, the second electronic device obtains the card file through the second SDK based on the first sharing information.

This step is similar to step S630 in method 600, and the differences will be mainly described below, and the remainder will be described with reference to step S620.

And according to different contents included in the first sharing information, the second electronic equipment obtains the card file through the second SDK in different modes.

As another example, if the first sharing information includes the aforementioned storage path of the card file in the cloud space, the second SDK obtains the card file from the cloud space according to the storage path of the card file in the cloud space.

As yet another example, if the first sharing information includes the file name of the card file, the second SDK may obtain the card file according to a preset storage location on the cloud space of the file name of the card file.

S1050, according to the card file, the second electronic device displays the first card on the interface of the second application through the second SDK.

The step is similar to step S650 in the method 600, and the detailed description of step S650 is referred to herein for brevity.

In some embodiments, the first shared information further includes a first identifier, the first identifier corresponding to the first pattern data. The method 1000 may further include: the second electronic device stores the first pattern data and the first identification through the second SDK.

In some embodiments, after step S1050, the method 1000 further comprises:

the first electronic device displays an interface of a first application, wherein the interface of the first application comprises a second card, and the style of the second card is the same as that of the first card;

in response to an operation of sharing the second card to the second application, the first electronic device generates second sharing information through the first SDK, the second sharing information indicates second content data corresponding to the second card, and the second sharing information further comprises a first identifier;

the first electronic device sends the second sharing information to the second electronic device;

the second electronic device obtains second content data and first type data through a second SDK based on the second sharing information, wherein the first type data is obtained based on the first identification;

the second electronic device displays a second card on the interface of the second application according to the first style data and the second content data.

In some embodiments, before the first electronic device generates the second shared information through the first SDK, the method 1000 further comprises:

Sending a first message to a second SDK through the first SDK, wherein the first message is used for requesting the identification of a card supported by a second application;

In some embodiments, before the first electronic device generates the first shared information through the first SDK, the method 1000 may further include: the first electronic device determines that the identifier of the card supported by the second application does not comprise a first identifier through interaction between the first SDK and the second SDK, and the first identifier corresponds to the first type data.

It should be understood that the embodiments related to sharing cards between different applications of the same device may also be applied to a scenario of sharing cards across devices, where only the manner of sending the first sharing information (or the second sharing information) and the manner of obtaining the card file (the first card file or the second card file) by the second electronic device are slightly different, which are described in the description of the method 1000, and the remaining applicable embodiments may refer to the descriptions of fig. 6 to 13, which are not repeated for brevity.

Based on the foregoing description, in the card sharing method provided by the embodiment of the application, the electronic device may share the card with other application programs of the electronic device, so as to realize card sharing among different application programs of the same device, or share the card sharing among different application programs of the same device with other electronic devices, thereby realizing card re-etching or collection and improving experience of users.

The card sharing method provided in the embodiment of the present application is described in detail above with reference to fig. 1 to 14, and the device embodiment of the present application is described in detail below with reference to fig. 15 to 17. It is to be understood that the description of the method embodiments corresponds to the description of the device embodiments, and that parts not described in detail can therefore be seen in the preceding method embodiments.

Fig. 15 shows a schematic block diagram of a communication system according to an embodiment of the present application. As shown in fig. 15, the communication system 1100 includes a first electronic device 1110 and a second electronic device 1120. The first electronic device 1110 may be a specific example of a first electronic device involved in the method shown in fig. 14, and the second electronic device 1120 may be a specific example of a second electronic device involved in the method shown in fig. 14.

In this embodiment of the present application, the first electronic device 1110 is configured to perform the methods and steps performed by the first electronic device in the foregoing method embodiments, and the second electronic device 1120 is configured to perform the methods and steps performed by the second electronic device in the foregoing method embodiments.

In some embodiments, the first electronic device 1110 may include a first display unit 1111, a first processing unit 1112, and a transmitting unit 1113.

The first display unit 1111 is used to perform step S1010 in the method 1000.

The first processing unit 1112 is configured to perform step S1020 in the method 1000. The first processing unit 1111 is also configured to perform a step of generating second shared information.

The transmission unit 1113 is configured to perform step S1030 in the method 1000. The transmitting unit 1112 is further configured to perform the step of transmitting the second shared information.

In some embodiments, the second electronic device 1120 may include a second display unit 1121, a second processing unit 1122, and a receiving unit 1123.

The receiving unit 1123 is configured to perform step S1030 in the method 1000. The receiving unit 1122 is further configured to perform the step of receiving the second shared information.

The second processing unit 1122 is used to perform step S1040 in the method 1000.

The second display unit 1121 is used to perform step S1050 in the method 1000.

Fig. 16 shows a schematic structural diagram of an apparatus provided in an embodiment of the present application. The apparatus 1200 may be located in the electronic device 100 shown in fig. 1, or may be a specific example of the electronic device 100. The apparatus 1200 is capable of performing the various steps in the method of fig. 6 and may embody the embodiments of fig. 7-13 and will not be repeated to avoid redundancy.

As shown in fig. 16, the apparatus 1200 may include a display unit 1210 and a processing unit 1220.

The display unit 1210 may be used to perform the process of displaying the first card in steps S610, S650 in the method 600, or to perform steps S701, S709 in the method 700. The display unit 1210 is mainly used for performing the step of displaying a user interface of the electronic device.

The processing unit 1220 may be used to perform steps S620, S640, S650 in the method 600 or to perform steps S703, S704, S705-S708 in the method 700. The processing unit 1220 is mainly used for executing steps of processing related to the clip file.

Fig. 17 is a schematic structural diagram of an electronic device provided in an embodiment of the present application. The electronic device 1300 shown in fig. 17 may be a specific example of the electronic device 100 of fig. 1.

The electronic device 1300 shown in fig. 17 includes a memory 1310, a processor 1320, and a bus 1330. Wherein the memory 1310 and the processor 1320 are communicatively coupled to each other via a bus 1330.

The memory 1310 may be a Read Only Memory (ROM), a static storage device, a dynamic storage device, or a random access memory (random access memory, RAM). The memory 1310 may store a program, and the processor 1320 is configured to perform the steps of the card sharing method according to the embodiment of the present application when the program stored in the memory 1310 is executed by the processor 1320.

Processor 1320 may employ a general-purpose central processing unit (central processing unit, CPU), microprocessor, application specific integrated circuit (application specific integrated circuit, ASIC), graphics processor (graphics processing unit, GPU) or one or more integrated circuits for executing associated programs to perform the card sharing methods of embodiments of the present application.

Processor 1320 may also be an integrated circuit chip with signal processing capabilities. In implementation, the various steps of the card sharing method of the present application may be performed by integrated logic circuitry of hardware or instructions in software form in processor 1320. The processor 1320 may also be a general purpose processor, a digital signal processor (digital signal processing, DSP), an application specific integrated circuit, an off-the-shelf programmable gate array (field programmable gate array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in the memory 1310, and the processor 1320 reads information in the memory 1310, and performs the card sharing method according to the embodiments of the present application in combination with hardware.

In some embodiments, electronic device 1300 also includes a communication interface 1340. Communication interface 1340 enables communication between electronic device 1300 and other devices or communication networks using a transceiver such as, but not limited to, a transceiver.

Bus 1330 may include a path to transfer information between various components of electronic device 1300 (e.g., memory 1310, processor 1320, communication interface 1330).

The embodiment of the application also provides electronic equipment, which comprises: one or more processors; one or more memories; the one or more memories store one or more computer programs that include instructions that, when executed by the one or more processors, cause the electronic device to perform the various steps or embodiments of the methods shown in fig. 6-16.

Embodiments also provide a readable storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform various steps or embodiments of the methods shown in fig. 6-16.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software 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.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown 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 may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. The card sharing method is characterized by being applied to electronic equipment, wherein the electronic equipment comprises a first application and a second application, the first application is integrated with a first Software Development Kit (SDK), and the second application is integrated with a second SDK, and the method comprises the following steps:

displaying an interface of the first application, wherein the interface of the first application comprises a first card;

generating first sharing information through the first SDK in response to the operation of sharing the first card to the second application, wherein the first sharing information indicates a card file corresponding to the first card, and the card file comprises first style data and first content data, and the first style data comprises a hierarchical relation among information elements in the first card, positions and arrangement modes of the information elements and attributes of the information elements;

transmitting the first sharing information from the first application to the second application;

acquiring the card file through the second SDK based on the first sharing information;

and displaying the first card on the interface of the second application according to the card file.

2. The method of claim 1, wherein the first shared information comprises a storage path of the card file.

3. The method of claim 1 or 2, wherein the first sharing information includes a file name of the card file, wherein the card file is stored in a preset storage location.

4. A method according to claim 2 or 3, wherein the card file is stored in a common storage space of the electronic device.

5. The method of any of claims 2 to 4, wherein the generating, by the first SDK, first sharing information in response to the operation of sharing the first card to the second application comprises:

responding to the operation of sharing the first card to the second application, and acquiring the card file by analyzing the information elements on the first card;

and storing the card file through the first SDK to generate the first sharing information.

6. The method of claim 5, wherein the obtaining the card file by parsing the information element on the first card comprises:

analyzing the information elements on the first card through the system capacity of the electronic equipment to obtain an analysis result;

and converting the analysis result into the card file through the first SDK.

7. The method of claim 1, wherein the first shared information comprises the card file.

8. The method of claim 7, wherein the generating, by the first SDK, first sharing information in response to the operation of sharing the first card to the second application comprises:

and responding to the operation of sharing the first card to the second application, and reading the card file through the first SDK to generate the first sharing information.

9. The method of claim 8, wherein prior to reading the card file by the first SDK, the method further comprises:

converting the analysis result into the card file through the first SDK;

and storing the card file through the first SDK.

10. The method according to any one of claims 1 to 4, 7, wherein the card file is issued to the first application by a server or cloud corresponding to the first application.

11. The method of any of claims 1-10, wherein the sending the first shared information by the first application to the second application comprises:

And sending the first sharing information to the second application by the first application through the system sharing capability of the electronic equipment.

12. The method of any one of claims 1 to 11, wherein the card file includes a first file for storing the first pattern data and a second file for storing the first content data.

13. The method of claim 12, wherein the information element in the first card comprises a first information element comprising at least one attribute comprising an attribute name and an attribute value, wherein the attribute value of one or more of the at least one attribute is a placeholder, and wherein the first content data comprises an actual value corresponding to the placeholder.

14. The method of claim 13, wherein displaying the first card at the interface of the second application according to the card file comprises:

creating an information element at an interface of the second application through the second SDK according to the analysis result of the second SDK on the first file, wherein the attribute value of one or more attributes in the at least one attribute of the first information element is a placeholder;

And according to the analysis result of the second SDK on the second file, applying an actual value corresponding to the placeholder to an interface of the second application through the second SDK.

15. A method according to any one of claims 12 to 14, wherein the data format of the first file is the same as or different from the data format of the second file.

16. The method of any of claims 12 to 15, wherein the first shared information further comprises a first identification, the first identification corresponding to the first pattern data, the method further comprising:

and storing the first pattern data and the first identification through the second SDK.

17. The method of claim 16, wherein the method further comprises:

generating second sharing information through the first SDK in response to the operation of sharing the second card to the second application, wherein the second sharing information indicates second content data corresponding to the second card, and the second sharing information further comprises the first identifier;

Transmitting the second sharing information from the first application to the second application;

18. The method of claim 17, wherein prior to the generating the second shared information by the first SDK, the method further comprises:

sending a first message to the second SDK through the first SDK, wherein the first message is used for requesting the identification of a card supported by the second application;

and receiving a second message from the second SDK through the first SDK, wherein the second message comprises the identification of the card supported by the second application, and the identification of the card supported by the second application comprises the first identification.

19. The method of any one of claims 1 to 18, wherein prior to the generating the first shared information by the first SDK, the method further comprises:

And determining that the identification of the card supported by the second application does not comprise a first identification through interaction between the first SDK and the second SDK, wherein the first identification corresponds to the first type data.

20. The method of any one of claims 1 to 19, wherein the card file is a text file.

21. The method of any one of claims 1 to 20, wherein the data format of the card file comprises at least one of: JSON format, XML format, HTML format.

22. An electronic device, comprising:

one or more processors;

one or more memories;

the one or more memories store one or more computer programs comprising instructions that, when executed by the one or more processors, cause the electronic device to perform the method of any of claims 1-21.

23. A computer readable storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform the method of any one of claims 1 to 21.