CN113076163A

CN113076163A - Card rendering method and device

Info

Publication number: CN113076163A
Application number: CN202110411345.6A
Authority: CN
Inventors: 王志昱; 王俊祥; 王小建
Original assignee: Beijing Jingdong Tuoxian Technology Co Ltd
Current assignee: Beijing Jingdong Tuoxian Technology Co Ltd
Priority date: 2021-04-16
Filing date: 2021-04-16
Publication date: 2021-07-06

Abstract

The invention discloses a card rendering method and device, and relates to the technical field of computers. One embodiment of the method comprises: receiving a card message transmitted by a server, and acquiring a service identification field and data in the card message; inquiring whether card parameters corresponding to the service identification fields exist in a link table or not; if the card parameters exist, executing a general card rendering logic based on the card parameters and the data, otherwise, executing a common card rendering logic. The implementation method can dynamically configure the control style in the card, is compatible with most card styles in App, realizes flexible online plugging and unplugging capability, is irrelevant to service and can enable the card to be externally energized.

Description

Card rendering method and device

Technical Field

The invention relates to the technical field of computers, in particular to a card rendering method and device.

Background

At present, more and more mobile terminal apps are connected with an Instant Messaging (IM) function, so that a user can send a self-defined card message such as a public article card, a friend business card and a red packet card in WeChat besides text, pictures and voice messages.

Since cards are often associated with App services, the IM SDKs on the market typically do not encapsulate these functions. Every time a new card is developed, the following stages are required: 1-UED (User Experience Design) designer designing a card UI style, 2-a server developer and a mobile developer determine a set of field issuing strategies, namely the corresponding relation between the field in the IM message and the IM card control style, and 3-the mobile developer develops the card UI, receives the IM message, fills card data and displays the card data.

In the process of implementing the invention, the inventor finds that the prior art has at least the following problems:

1. the development of each card needs to be started from the beginning, so that the time and the labor are consumed, and the efficiency is low; under the condition that the App is on-line or does not release a new version, cards cannot be dynamically increased or decreased, only the modification of a local code is strongly depended on, and the operation is not easy;

2. the number of cards and the fields in the IM message analysis class are increased along with the increase of service scenes, so that repeated codes are increased, analysis is slow and time-consuming, and maintenance is difficult;

3. due to reasons such as UED (unified equipment discovery), developer change and the like, card styles developed by the same App at different periods cannot be kept uniform, user experience is reduced, and reuse is difficult.

Disclosure of Invention

In view of this, embodiments of the present invention provide a card rendering method and apparatus, which can at least solve the problem that an instant messaging card in the prior art is not easy to develop and manage.

To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a card rendering method, where a card is an instant messaging card in an application, including:

receiving a card message transmitted by a server, and acquiring a service identification field and data in the card message;

inquiring whether card parameters corresponding to the service identification fields exist in a link table or not;

if the card parameters exist, executing a general card rendering logic based on the card parameters and the data, otherwise, executing a common card rendering logic.

Optionally, the receiving the card message transmitted by the server includes:

receiving a message transmitted by a server, judging whether the message type in the message is a card type, if so, determining that the message is the card message, otherwise, executing rendering logic of non-card messages.

Optionally, the card parameter further includes a lowest version number supported by the card;

the executing general card rendering logic based on the card parameters and data further comprises:

and judging whether the current version number of the application is greater than the lowest version number, if so, executing a universal card rendering logic based on the card parameters and the data, and otherwise, not processing.

Optionally, the method further includes: and receiving the abnormal operation information of the universal card and feeding back the abnormal operation information to the server, so that the lowest version number is modified into any value larger than the version number at the server, and the universal card is offline.

Optionally, the card parameters further include a universal card template identifier and a control style name in the card;

the executing general card rendering logic based on the card parameters and data comprises:

determining a universal card template corresponding to the universal card template identification;

acquiring a control style corresponding to the control style name, and drawing the control style from top to bottom on the universal card template to generate a universal card;

and filling the data onto the general-purpose card for display.

Optionally, the code architecture of the application is divided into a base layer and a service layer;

before receiving the card message pushed by the server, the method further comprises:

the business layer calls a registration method provided by the basic layer, registers the card parameters to the basic layer, establishes a mapping relation between the card parameters and the general card template by taking the general card template identification as a link, and then stores the mapping relation into a link table of the basic layer.

Optionally, before the service layer invokes the registration method provided by the base layer, the method further includes:

receiving a selection of a plurality of card control styles at the base layer to generate a universal card template based on the selected plurality of card control styles; and

a defining operation of the identity of each generic card template is received.

Optionally, the card message further includes a routing protocol field, which is used for processing a click event of the card;

after the executing the general card rendering logic based on the card parameters and the data, and otherwise executing the general card rendering logic, the method further comprises:

responding to the click operation of a general card or a common card, and judging whether the value of the routing protocol field is a webpage link or not;

if yes, jumping to a webpage corresponding to the routing protocol field through a webpage routing callback method of a service layer and displaying;

otherwise, inquiring whether logic for processing the routing protocol field is registered in the service layer through other service routing callback methods of the service layer;

if the judgment result is that the routing protocol field exists, processing the routing protocol field by using processing logic at the service layer to obtain a return value, and if the return value is processed, determining that the routing protocol is processed by the service layer;

and if the judgment result is that the card does not exist or the return value is not processed, popping up prompt information and finishing the card opening process.

Optionally, the service layer registers two callback methods to the base layer, where one callback method corresponds to the web routing method of the base layer, and the other callback method corresponds to the other service routing methods of the base layer.

To achieve the above object, according to another aspect of the embodiments of the present invention, there is provided a card rendering apparatus, where a card is an instant messaging card in an application, including:

the receiving module is used for receiving a card message transmitted by a server and acquiring a service identification field and data in the card message;

the query module is used for querying whether the card parameters corresponding to the service identification fields exist in the link table or not;

and the rendering module is used for executing the general card rendering logic based on the card parameters and the data if the card parameters and the data exist, otherwise, executing the common card rendering logic.

Optionally, the receiving module is configured to:

the rendering module is further configured to:

Optionally, the system further comprises a offline module, configured to:

and receiving the abnormal operation information of the universal card and feeding back the abnormal operation information to the server, so that the lowest version number is modified into any value larger than the version number at the server, and the universal card is offline.

the rendering module to:

and filling the data onto the general-purpose card for display.

further comprising a create linkage table module for:

the business layer calls a registration device provided by the basic layer, registers the card parameters to the basic layer, establishes the mapping relation between the card parameters and the general card template by taking the general card template identification as a link, and then stores the mapping relation into a link table of the basic layer.

Optionally, the system further includes a template establishing module, configured to:

a defining operation of the identity of each generic card template is received.

still include the card click module for:

if yes, jumping to a webpage corresponding to the routing protocol field through a webpage routing callback device of a service layer and displaying;

otherwise, inquiring whether logic for processing the routing protocol field is registered in the service layer through other service routing callback devices of the service layer;

Optionally, the method further includes: the service layer registers two callback devices with the base layer, wherein one callback device corresponds to the webpage routing device of the base layer, and the other callback device corresponds to the other service routing devices of the base layer.

To achieve the above object, according to still another aspect of embodiments of the present invention, there is provided a card rendering electronic device.

The electronic device of the embodiment of the invention comprises: one or more processors; and the storage device is used for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors realize the card rendering method.

To achieve the above object, according to a further aspect of the embodiments of the present invention, there is provided a computer readable medium having stored thereon a computer program, which when executed by a processor, implements any of the card rendering methods described above.

According to the scheme provided by the invention, one embodiment of the invention has the following advantages or beneficial effects: and abstracting and packaging the card styles in the application to obtain a universal card template so as to be compatible with most card styles in the application. In addition, the card supports dynamic configuration of the style, and the control style and the version control field in the card are set in the configuration, so that the display style and the emergency online and offline of the card are dynamically controlled on line.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

FIG. 1 is a schematic main flow chart of a card rendering method according to an embodiment of the present invention;

FIG. 2 is a flow chart diagram of a method for rendering cards, in particular, according to an embodiment of the invention;

fig. 3 is a flowchart illustrating a card routing processing method according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of the main modules of a card rendering apparatus according to an embodiment of the present invention;

FIG. 5 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

FIG. 6 is a schematic block diagram of a computer system suitable for use with a mobile device or server implementing an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Referring to fig. 1, a main flowchart of a card rendering method according to an embodiment of the present invention is shown, including the following steps:

s101: receiving a card message transmitted by a server, and acquiring a service identification field and data in the card message;

s102: inquiring whether card parameters corresponding to the service identification fields exist in a link table or not;

s103: if the card parameters exist, executing a general card rendering logic based on the card parameters and the data, otherwise, executing a common card rendering logic.

In the above embodiment, for the cards in the same App in steps S101 to S102, some layout structures are similar, the same general card template, such as a card sharing an article in a WeChat and a file card, can be shared, and some layout structures are unique, so that the existing common card rendering logic is still adopted.

It should be noted that the scheme aims to be compatible with most of the card styles in the application, and does not consider to be compatible with too complicated or other card styles so as to ensure the usability of the universal card and the high performance of the application. In actual operation, the universal card template can cover 80% -90% of the whole App card, so that the code amount of the card is reduced, and management is facilitated.

Therefore, when a new card development requirement exists, the online can be tested only by finding out a similar abstract card according to the pattern matching and configuring the control patterns and version numbers simply; even if the existing universal card style is not compatible with the card style in the new requirement, the product and the UED can be pushed to follow the style template of the universal card to be designed so as to realize the unification of the card style in the App.

The card message, i.e. the card IM message, includes, in addition to a unique service identifier template field (e.g. access card 01, article card 02) and data of the card, information of a message sender, information of a message recipient, and necessary information for communication with the IM server, such as a chat session id, whether group chat is performed, and the like. The data is information required to be displayed on the card, and takes an article sharing card in the WeChat as an example, and the data comprises article title text, article cover picture addresses, article author text and the like.

When the IM server side pushes a card message to the mobile side, the mobile side firstly obtains a template id field in the card message, and inquires whether a card parameter corresponding to the template id field is registered in the link table, if so, the pushed card is determined to be a general card, and a general card rendering logic is executed, otherwise, the general card rendering logic is executed. The link table is located in a base layer of the App code architecture, and is described with reference to fig. 2 in particular.

For step S103, the card parameter includes, in addition to the unique service identifier template field of the card, a unique template identifier cardType of the card, a version number minVersion of the lowest display of the card, and a name of a control style in the card; the card type is mainly defined by people at present, the form is indefinite, and the card type can be an integer, a character string, a UUID or a string of messy codes, as long as the card type of different universal card templates is not repeated, for example, the card type is 1, and the card type is imgCard.

Because only the card parameters of the universal card are registered in the link table (the service identification field of the common card is not stored in the link table), after the card is determined to be the universal card, the mobile terminal obtains the template identification card type used by the universal card from the card parameters corresponding to the template id field, and further obtains the corresponding universal card template.

Further, when the server side pushes the card message, a clear field, such as a message type field, is set to indicate whether the message is a card type message. Taking the template id in the present solution as an example, the definitions of the fields by different service ends are different, so that the binding relationship is registered to the base layer through the service layer to ensure the robustness of the base layer. It should be noted that there is no card template identifier cardType field in the card message, so that it cannot be determined whether the message transmitted by the server is of the card type through cardType.

The rendering of the card is actually the drawing/rendering of the card and the control styles in the card, such as card round corners, background colors, word sizes, font colors, the width and height of pictures, the placeholder maps of the pictures and the like. The rendering logic is top-down rendering, all controls are traversed from the card layout to the lower layer, after the style name bound by the controls is obtained, the specific control style corresponding to the name is obtained from the style sheet, and then the controls are drawn; if the control style corresponding to the name does not exist, the default style is used for drawing the control. And finally, filling the data in the card message into the card for display.

Furthermore, each universal card has its lowest supported App version number, so the minVersion field is configured in the configuration item of the server configuration layer to implement card version control. When registering data, whether the version number of the current App is higher than minVersion of the card or not needs to be judged, and the card is displayed only when the version number of the current App is higher than minVersion. On the contrary, if a certain universal card is abnormal online, only the configuration layer of the server side needs to modify minVersion in the configuration item corresponding to the card into any value higher than the current App version number, and the subsequent App version cannot be online.

The method provided by the embodiment abstracts and encapsulates the card styles in the application to obtain the universal card template so as to be compatible with most card styles in the application. In addition, the card supports dynamic configuration of the style, and the control style and the version control field in the card are set in the configuration, so that the display style and the emergency online and offline of the card are dynamically controlled on line.

Referring to fig. 2, a flowchart of a specific card rendering method according to an embodiment of the present invention is shown, including the following steps:

s201: receiving a message transmitted by a server, judging whether the message type in the message is a card type, and if not, executing rendering logic of non-card messages;

s202: if so, determining that the message is a card message, and acquiring a service identification field and data in the card message;

s203: inquiring whether card parameters corresponding to the service identification fields exist in a link table or not, and if not, executing common card rendering logic; the card parameters comprise a service identification field, a universal card template identification, a lowest version number supported by the card and a control style name in the card;

s204: if the version number of the application is greater than the lowest version number, judging whether the current version number of the application is greater than the lowest version number, and if not, not processing;

s205: if so, determining a universal card template corresponding to the universal card template identification;

s206: acquiring a control style corresponding to the control style name, and drawing the control style from top to bottom on the universal card template to generate a universal card;

s207: and filling the data onto the general-purpose card for display.

In the above embodiment, for steps S201 to S207, the present solution divides the code architecture of App into a base layer and a service layer; the basic layer mainly provides the realization of a universal card template and is irrelevant to the service; the business layer is mainly responsible for registration of basic card styles and event processing.

The generic card template is defined at the base layer. For example, the cards of articles shared in WeChat and the document cards have similar layout structures although the cards have different details, so that the cards can share one common card template and each common card template can define a unique identification card type. However, there are still some differences in the space, the font size, etc. of the two cards, so that a set of styles still needs to be provided for each card, that is, a one-to-many relationship between the common card template and the card control style is selected by a developer.

The definition of the generic card template follows the following principles: the method covers most card styles in the application as much as possible, and enables the UI rendering efficiency to be the highest as possible. Therefore, developers are required to make certain trade-offs between the versatility of the card and the performance of the system when setting up the universal card template.

It should be noted that different universal card templates may allow overlapping in style, function, etc., but do not overlap as much as possible. Compatibility may be considered if the layout of the various cards is similar, to minimize the number of generic card templates. In addition, the card control style exists in two positions, one is a configuration layer of a server side, and the other is a basic layer of a mobile side. The style in the configuration layer is the style displayed by the final card, the style in the base layer can be regarded as a pocket bottom, and when a control style of a certain card is leaked and matched in the configuration layer, the default style in the base layer can be displayed.

After defining the generic card template and the cardType, the base layer needs to associate the cardType with the specific service card parameters. Considering that IM card styles in different Apps are different and the basic layer does not care about the aspects of service related logic, the scheme extracts the step to the service layer, namely the service layer needs to register card parameters to the basic layer and form a link table in the basic layer for storing the card parameters of different universal card templates. The business layer can store the card parameter configuration of the universal card templates in a mode issued by the server so as to ensure the flexibility of the card style.

And the business layer calls a registration method provided by the basic layer and registers the card parameters to the basic layer. During registration, combining the four parts of template id, card type, minVersion and styles provided by the service layer with the two parts of card type and general card template provided by the base layer, and forming a linked list containing the five parts of template id, card type, minVersion, styles and general card template by taking the card type as a link. A linkage table is maintained in the basic layer, and the registration method is that the data of the business layer is circulated to an inlet of the basic layer so as to store the card parameters provided by the business layer into the linkage table. The pseudo code is: void register (templateId, cardType, minVersion, styles).

In addition, the number and the type of the cards are not considered in the basic layer of the scheme, and the basic layer is only responsible for registering, configuring and rendering the cards. As described above, the basic layer only concerns the binding relationship between the template id and the card type, and the card style, so that if the card is to be deleted, only the configuration item corresponding to the template id of the card in the configuration layer needs to be deleted; when the card is added, the configuration item of the card is only required to be added in the configuration layer. Because the configuration layer is independent outside the App, the purpose of dynamically adding and deleting cards without edition release is also achieved.

According to the method provided by the embodiment, the business layer and the basic layer are separated, and the business layer and the basic layer realize different functions so as to accelerate the card rendering operation.

Referring to fig. 3, a schematic flow chart of a card routing processing method according to an embodiment of the present invention is shown, including the following steps:

s301: responding to the click operation of a general card or a common card, and judging whether the value of the routing protocol field is a webpage link or not;

s302: if yes, jumping to a webpage corresponding to the routing protocol field through a webpage routing callback method of a service layer and displaying;

s303: otherwise, inquiring whether logic for processing the routing protocol field is registered in the service layer through other service routing callback methods of the service layer;

s304: if the judgment result is that the routing protocol field exists, processing the routing protocol field by using processing logic at a service layer to obtain a return value;

s305: if the return value is processed, determining that the service layer has processed the routing protocol;

s306: and if the judgment result is that the card does not exist or the return value is not processed, popping up prompt information and finishing the card opening process.

In the foregoing embodiment, for steps S301 to S306, a navProtocol field needs to be set in the card message sent by the server, which means a routing protocol, so as to process a click event of a general card. It should be noted that navProtocol is a protocol provided by the base layer, and the service layer can only implement click events according to the set of protocols, so if a common card also wants to use the navProtocol scheme, the common card also needs to parse and process the protocol before use.

Different apps are provided with mechanisms capable of opening web page connections, but the implementation modes are different. The basic layer of the scheme considers scenes energized by different apps later, and throws the implementation method for analyzing and processing the navProtocol protocol to a service layer to realize specific routing. And when the webpage needs to be jumped to subsequently, different apps can jump to the internal webpage. Therefore, the basic layer needs to extract a click event processing interface to the service layer, the interface has two methods, one is a method for jumping to a WebView webpage, which can be called a webpage routing method, and the service layer registers a webpage routing callback method with the webpage routing callback method; the second method is a method for processing non-web page jump, which processes service jump logic through a route identifier, which can be called as other service route method, and the service layer registers other service route callback method to it, which returns a value of whether to process completion.

When the service layer initializes the base layer, it needs to register the configuration items obtained from the configuration layer into the base layer, and also needs to set an interface to the base layer, where the interface includes the above-mentioned web routing method and other service routing methods. When the service layer sets the interface to the base layer, the base layer holds the interface, otherwise it is empty. Therefore, the judgment basis of "inquiring whether logic for processing the routing protocol field is registered in the service layer" is to judge whether the interface is empty.

After a user clicks a universal card or a common card, a mobile terminal firstly judges whether a navProtocol field is an H5 link, namely judges whether the navProtocol takes http:// 'or https://' as the beginning, if so, the navProtocol field is a Web link, and jumps to a WebView page to display the Web page through a webpage routing callback method of a service layer; otherwise, inquiring whether logic for processing the routing protocol field is registered in the service layer through other service routing callback methods of the service layer. And after the business layer tries to process the business jump logic, a return value is obtained, if the return value is processed, the business layer is indicated to process the route, otherwise, the business layer is not processed, and at the moment, a user can be reminded of friendly prompts such as 'the function is not supported temporarily' by a pop-up box, and the card opening process is finished.

The method provided by the embodiment also depends on the service layer and the basic layer, realizes a card opening processing mechanism, and increases the navProtocol field in the message, thereby realizing the distinguishing processing of the webpage link and the non-webpage link.

Compared with the prior art, the embodiment of the invention provides a card rendering scheme applied to IM type mobile application based on configuration, which at least has the following beneficial effects:

1. most card styles in App are compatible: operations such as card UI drawing, data filling and the like in the development of the mobile terminal card type message are abstracted and packaged, limited universal styles are used for being compatible with most card styles in application, the iteration efficiency of products is improved, repeated codes are reduced, and unnecessary code errors are avoided;

2. dynamically configurable control styles: the specific display effect of each control in the card is configured in a mode of registering the style by the service layer, and even if the card is online, the style of the online card can be modified by modifying the configuration mode without releasing a new version; similarly, when the existing universal card style and event processing are completely compatible with the card in new requirements, the online user can receive the card without issuing the card;

3. controlling the version of the card: the version number of the universal card is controlled through card parameters, and when a certain card on the line is abnormal, emergency off-line can be realized by modifying the lowest version number in the configuration;

4. fields in the IM message of the universal card are irrelevant to services, so that the universal card can be externally energized and supports other App to be quickly accessed and used.

Referring to fig. 4, a schematic diagram of main modules of a card rendering apparatus 400 according to an embodiment of the present invention is shown, where a card is an instant messaging card in application, and includes:

the receiving module 401 is configured to receive a card message transmitted by a server, and acquire a service identification field and data in the card message;

a query module 402, configured to query whether a card parameter corresponding to the service identifier field exists in a link table;

and a rendering module 403, configured to execute a general card rendering logic based on the card parameters and the data if the card parameters and the data exist, and otherwise execute a general card rendering logic.

In the apparatus for implementing the present invention, the receiving module 401 is configured to:

In the implementation device of the invention, the card parameters further comprise the lowest version number supported by the card;

the rendering module 403 is further configured to: and judging whether the current version number of the application is greater than the lowest version number, if so, executing a universal card rendering logic based on the card parameters and the data, and otherwise, not processing.

The implementation device of the invention also comprises a downloading module used for:

In the implementation device of the invention, the card parameters further comprise a general card template identifier and a control style name in the card;

the rendering module 403 is configured to:

and filling the data onto the general-purpose card for display.

In the implementation device of the invention, the applied code architecture is divided into a basic layer and a service layer;

further comprising a create linkage table module for:

The device also comprises a template establishing module used for:

a defining operation of the identity of each generic card template is received.

In the implementation device of the present invention, the card message further includes a routing protocol field for processing a click event of the card;

still include the card click module for:

The implementation device of the invention also comprises: the service layer registers two callback devices with the base layer, wherein one callback device corresponds to the webpage routing device of the base layer, and the other callback device corresponds to the other service routing devices of the base layer.

In addition, the detailed implementation of the device in the embodiment of the present invention has been described in detail in the above method, so that the repeated description is not repeated here.

Fig. 5 shows an exemplary system architecture 500 to which embodiments of the invention may be applied, including

terminal devices

501, 502, 503, a network 504 and a server 505 (by way of example only).

The

terminal devices

501, 502, 503 may be various electronic devices having display screens and supporting web browsing, and are installed with various communication client applications, and users may interact with the server 505 through the network 504 using the

terminal devices

501, 502, 503 to receive or send messages, and the like.

The network 504 serves to provide a medium for communication links between the

terminal devices

501, 502, 503 and the server 505. Network 504 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

The server 505 may be a server providing various services, and is configured to execute receiving a card message transmitted by a server, and acquire a service identification field and data in the card message; inquiring whether card parameters corresponding to the service identification fields exist in a link table or not; if the card parameters exist, the general card rendering logic is executed based on the card parameters and the data, otherwise, the common card rendering logic operation is executed.

It should be noted that the method provided by the embodiment of the present invention is generally executed by the server 505, and accordingly, the apparatus is generally disposed in the server 505.

It should be understood that the number of terminal devices, networks, and servers in fig. 5 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 6, a block diagram of a computer system 600 suitable for use with a terminal device implementing an embodiment of the invention is shown. The terminal device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.

As shown in fig. 6, the computer system 600 includes a Central Processing Unit (CPU)601 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage section 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for the operation of the system 600 are also stored. The CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, a mouse, and the like; an output portion 607 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 608 including a hard disk and the like; and a communication section 609 including a network interface card such as a LAN card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. The driver 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 610 as necessary, so that a computer program read out therefrom is mounted in the storage section 608 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 609, and/or installed from the removable medium 611. The computer program performs the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 601.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a receiving module, a query module, and a rendering module. The names of these modules do not in some cases form a limitation on the modules themselves, and for example, a receiving module may also be described as a "message receiving module".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise:

According to the technical scheme of the embodiment of the invention, the card rendering mode applied to the IM class mobile application based on the configuration is provided, and compared with the prior art, the card rendering mode at least has the following beneficial effects:

2. dynamically configurable control styles: the specific display effect of each control in the card is configured in a mode of registering the style by the service layer, and even if the card is online, the style of the online card can be modified by modifying the configuration mode; similarly, when the existing universal card style and event processing are completely compatible with the card in new requirements, the online user can receive the card without issuing the card;

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A card rendering method, the card is the instant communication card in the application, characterized by, including:

2. The method according to claim 1, wherein the receiving of the card message transmitted by the server comprises:

3. The method of claim 1, wherein the card parameters further include a lowest version number supported by the card;

4. The method of claim 3, further comprising:

5. The method of claim 1, wherein the card parameters further include a generic card template identification and a control style name in the card;

and filling the data onto the general-purpose card for display.

6. The method according to any of claims 1-5, characterized in that the code architecture of the application is divided into a base layer and a business layer;

7. The method of claim 6, before the service layer invokes the registration method provided by the base layer, further comprising:

a defining operation of the identity of each generic card template is received.

8. The method of claim 6, wherein the card message further comprises a routing protocol field for processing a click event of a card;

9. The method of claim 8, further comprising:

the service layer registers two callback methods to the basic layer, wherein one callback method corresponds to a webpage routing method of the basic layer, and the other callback method corresponds to other service routing methods of the basic layer.

10. The utility model provides a device is rendered to card, card are the instant messaging card in using which characterized in that includes:

11. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-9.

12. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-9.