Encapsulation method, generation method and display method of card view generation program
By customizing the encapsulation methods of the View base class and ViewHolder class, the code bloat and coupling problems caused by multiple card styles in RecyclerView are solved, achieving efficient card View generation and display, and reducing development difficulty and maintenance costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- GUIYANG YUWAN SCI TECH CO LTD
- Filing Date
- 2022-08-12
- Publication Date
- 2026-06-26
AI Technical Summary
In Android mobile development, when using RecyclerView, if multiple card styles need to be displayed in the list, existing technologies result in bloated Adapter code and high coupling, increasing development and maintenance costs.
By creating a custom View base class, ViewHolder class, and card type entities, the creation and data binding logic of the card View is encapsulated. The custom View base class is used to generate the corresponding card type ViewHolder object, and data is passed through public functions to achieve decoupling.
It reduces development and maintenance costs, improves code reusability and simplifies Adapter implementation, reduces the need for ViewHolder creation, and is suitable for displaying list data of various card types.
Smart Images
Figure CN115328450B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Android development technology, and more specifically, to a method for encapsulating, generating, and displaying a card View generation program. Background Technology
[0002] In Android mobile development, displaying information in a list is a basic requirement, and the Android platform provides the RecyclerView component to achieve this.
[0003] A key element in using RecyclerView is the adapter, RecyclerView.Adapter. The adapter's main function is to create cards using different RecyclerView.ViewHolders based on the data in the list, and then bind the data to the cards for display. In other words, one card style corresponds to one ViewHolder.
[0004] Please see Figure 1 In existing technologies, implementing lists using RecyclerView generally follows this process:
[0005] 1) Create a ListAdapter class that inherits from RecyclerView.Adapter;
[0006] 2) Create an inner class ViewHolder in ListAdapter, which inherits from RecyclerView.ViewHolder, and generate card Views in the constructor using the layout file. The number of ViewHolder classes needed depends on the number of types of cards in the list.
[0007] 3) The ListAdapter class needs to implement the getItemViewType function to provide RecyclerView with the ability to distinguish card types;
[0008] 4) The ListAdapter class needs to implement the onCreateViewHolder function to generate the corresponding ViewHolder based on the card type;
[0009] 5) The ListAdapter class needs to implement the onBindViewHolder function, obtain the card View through ViewHolder, and bind the data in the list to the card View;
[0010] 6) Set the ListAdapter onto the RecyclerView and populate the data to refresh it. The RecyclerView will then automatically call the functions above to create the card View and bind the data.
[0011] When a list needs to display many card styles, such as a friend's chat page that requires text, images, videos, voice messages, emoticons, red envelopes, gifts, etc., we need to create a large number of ViewHolder classes. This centralized code leads to bloated and redundant code in the Adapter. Furthermore, engineers' misuse of inheritance and polymorphism in programming languages further exacerbates the coupling between cards. Engineers then need to consider and test whether their changes will affect other cards during development and maintenance, resulting in increasingly higher technical costs. Summary of the Invention
[0012] The purpose of this application is to provide an encapsulation method, generation method, and display method for a card view generation program, so as to separate the focus of attention and reduce the coupling between the parts when implementing the list, thereby reducing the development difficulty and maintenance cost.
[0013] To achieve the above objectives, the embodiments of this application are implemented in the following manner:
[0014] In a first aspect, embodiments of this application provide an encapsulation method for a card View generation program, comprising: creating a custom View base class for providing public functions and abstract data binding functions; creating a ViewHolder class for storing card Views and providing public functions; creating a card type entity for providing card information revealing the card type; and creating an Adapter for determining the card type based on the card information, generating a card View corresponding to this card type and inheriting from the custom View base class, and further generating a ViewHolder object corresponding to this card type. The Adapter calls the public functions provided by the ViewHolder class to pass data to the ViewHolder object, and the ViewHolder object calls the public functions provided by the card View to pass data to the card View, so that the card View binds the data passed from the ViewHolder object to the card View through the data binding functions.
[0015] In this embodiment, the created Adapter determines the card type based on the card information, generates a card View corresponding to this card type and inheriting from a custom View base class, and further generates a ViewHolder object corresponding to this card type. The Adapter calls the public function provided by the ViewHolder class to pass data to the ViewHolder object, and the ViewHolder object calls the public function provided by the card View to pass data to the card View, so that the card View binds the data passed from the ViewHolder object to the card View through the data binding function. This solution encapsulates the creation and data binding logic of the card View using a custom View, achieving full decoupling. Each card does not affect the others, reducing development and maintenance costs. Furthermore, the card View generated based on the created custom View base class can be used in any list and any layout, greatly improving reusability. The secondary encapsulation of Adapter and ViewHolder mainly serves to automatically create card Views of the corresponding card type using the custom View base class. By encapsulating the common parts, the implementation of Adapter can be simplified, eliminating the need to create multiple ViewHolders (the ViewHolder class created in this solution is universal), thereby reducing development difficulty and cost.
[0016] In conjunction with the first aspect, in the first possible implementation of the first aspect, a custom View base class is created, including: loading the layout file as a View; defining data entities, which represent the data to be displayed on the card View; exposing functions for the ViewHolder class to call to pass in data; and abstracting data binding functions, which are implemented by the card View to bind the data.
[0017] In conjunction with the first aspect, in the second possible implementation of the first aspect, a ViewHolder class is created, which includes: creating a public RecyclerView.ViewHolder class to store card Views; and exposing functions for the Adapter to call to pass in data.
[0018] In this implementation, a ViewHolder class is created to provide the ability to store View instances (i.e., card Views) and bind data (through a public function, which is called by the Adapter to pass in data, so that the card Views placed in it can bind data). Furthermore, with the ViewHolder class, it is not necessary to create a ViewHolder class for each card View.
[0019] In conjunction with the first aspect, in the third possible implementation of the first aspect, the card information includes a card description and a card category number. Creating a card type entity includes: creating a card type entity; adding a card description for developers to identify; adding a card category number for the Adapter to identify; and creating a custom card View class for creating a card View through a reflection constructor.
[0020] In this implementation, card information includes card description and card category number, which makes it easier for the adapter and developers to identify card types. The custom card view class creates card views through reflection constructor, which supports the creation of card views of various card types.
[0021] In conjunction with the third possible implementation of the first aspect, in the fourth possible implementation of the first aspect, if the card information is abnormal, the custom card View class is also used to create a card View with blank content through the reflection constructor.
[0022] In this implementation, if the card information is abnormal (e.g., the card type cannot be identified), a blank card view can be created through the reflection constructor, which can tolerate the error.
[0023] In conjunction with the first aspect, in the fifth possible implementation of the first aspect, an Adapter is created, including: for the case where the data in the data list corresponds to a single card type: create an Adapter, denoted as SimpleRVAdapter, and no new Adapter needs to be created after the Adapter is created; for the case where the data in the data list corresponds to multiple card types: create an Adapter that inherits from MultipleRVAdapter.
[0024] In this implementation, for cases where the data in the data list corresponds to a single card type: an Adapter is created, denoted as SimpleRVAdapter. After creating this Adapter, no new Adapters need to be created; it can be used directly, simplifying development. For cases where the data in the data list corresponds to multiple card types: an Adapter is created, inheriting from MultipleRVAdapter, to support multiple card types.
[0025] Secondly, embodiments of this application provide a method for generating a card View, applied to a card View generation program obtained by encapsulating a card View generation program based on any one of the first aspects or possible implementations of the first aspect. The method includes: obtaining data to be displayed through an Adapter and determining the card type corresponding to the data to be displayed; generating a card View corresponding to this card type and inheriting from a custom View base class through an Adapter, and further creating a ViewHolder object corresponding to this card type based on this card type and the generated card View, wherein the custom View base class provides public functions and abstract data binding functions, while the ViewHolder class provides public functions; calling the public functions provided by the ViewHolder class through the Adapter to pass the data to be displayed to the ViewHolder object; and calling the public functions provided by the card View through the ViewHolder object to pass the data to be displayed to the card View, so that the card View binds the data to be displayed to the card View through the data binding functions.
[0026] In conjunction with the second aspect, in the first possible implementation of the second aspect, generating a card View corresponding to this card type and inheriting from the custom View base class through the Adapter includes: generating a card View corresponding to this card type and inheriting from the custom View base class by calling the reflection constructor based on the card type corresponding to the data to be displayed, using the custom card View class in the Adapter.
[0027] Thirdly, embodiments of this application provide a method for displaying a card View list, comprising: traversing and refreshing a data list, wherein the data list contains multiple data entries, each data entry having a corresponding card type; passing the current data into a card View generation program obtained by encapsulating a card View generation program based on the first aspect or any possible implementation of the first aspect, running the card View generation method described in the second aspect or the first possible implementation of the second aspect through the card View generation program, generating a card View corresponding to the card type corresponding to the data; and binding the data to the card View through a data binding function to display the data through the card View.
[0028] In this embodiment, the method for displaying a card view list can iterate and refresh the data list, passing the current data into a card view generation program obtained by encapsulating the card view generation program. The card view generation program then runs the card view generation method to generate a card view corresponding to the card type corresponding to the data. Finally, a data binding function binds the data to the card view, allowing the data to be displayed. This fully decouples the card view generation program from the data's card type, reducing development and maintenance costs, improving reusability, and simplifying the Adapter implementation by eliminating the need to create multiple ViewHolders. As a result, most of the code in the card view list display implementation is already encapsulated, requiring only a short codebase for use in various card view display scenarios, significantly reducing development and maintenance costs.
[0029] Fourthly, embodiments of this application provide a storage medium comprising a stored program, wherein, when the program is executed, the device where the storage medium is located executes the encapsulation method of the card View generation program as described in any one of the first aspects or possible implementations of the first aspect, or executes the card View generation method as described in the second aspect or the first possible implementation of the second aspect, or executes the card View display list method as described in the third aspect.
[0030] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0031] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0032] Figure 1 This is a flowchart illustrating the process of implementing a list using RecyclerView in existing technologies.
[0033] Figure 2 A flowchart illustrating the encapsulation method of the card View generation program provided in this application embodiment.
[0034] Figure 3 A flowchart illustrating the method for generating a card View as provided in this application embodiment.
[0035] Figure 4 A flowchart illustrating a method for displaying a list of cards using a Card View, as provided in an embodiment of this application.
[0036] Figure 5 This is a flowchart illustrating a method for displaying a list of cards using a View, as provided in an embodiment of this application. Detailed Implementation
[0037] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.
[0038] To facilitate understanding, the encapsulation process of the card view generation program will be introduced here first. Please refer to [link / reference]. Figure 2 , Figure 2 This is a flowchart illustrating the encapsulation method for a card view generation program provided in an embodiment of this application. The encapsulation method for the card view generation program may include steps S11, S12, S13, and S14.
[0039] To achieve encapsulation, basic elements need to be configured. First, step S11 can be executed.
[0040] Step S11: Create a custom View base class to provide public functions and abstract data binding functions.
[0041] In this embodiment, a custom View base class can first be created to provide public functions and abstract data binding functions. The public functions can be called by the ViewHolder to pass in data, while the abstract data binding functions can be implemented in detail by the subclass View (i.e., the card Views generated by inheriting from the custom View base class), thereby achieving data binding.
[0042] For example, a layout file can be loaded as a View, and then data entities can be defined, which represent the data that needs to be displayed on the card View; public functions can be provided for the ViewHolder class to call to pass in the data; and abstract data binding functions can be implemented by the card View to bind the data.
[0043] Kotlin language code example:
[0044]
[0045] After creating a custom View base class, you can proceed to step S12.
[0046] Step S12: Create a ViewHolder class to store card Views and provide public functions.
[0047] In this embodiment, a ViewHolder class can be created to store card Views and provide public functions.
[0048] For example, you can create a public RecyclerView.ViewHolder class to store card views; then expose functions for the Adapter to call to pass in data.
[0049] The created ViewHolder class can provide the ability to store View instances (i.e., card Views) and bind data (through public functions, which are called by the Adapter to pass in data, so that the card Views placed in it can bind data). Furthermore, with this ViewHolder class, it is no longer necessary to create a ViewHolder class for each card View.
[0050] Kotlin language code example:
[0051]
[0052] After creating the ViewHolder class, you can proceed to step S13.
[0053] Step S13: Create a card type entity to provide card information that reveals the card type.
[0054] In this embodiment, a card type entity can be created to provide card information that reveals the card type and configure the required data.
[0055] For example, card information can include a card description and a card category number, making it easier for developers and the adapter to identify the card type. Therefore, creating a card type entity can be done as follows: create a card type entity; add a card description for developer identification; add a card category number for adapter identification; and create a custom card Viewclass to create the card View using a reflection constructor. The custom card Viewclass creates the card View using a reflection constructor, thus supporting the creation of card Views for various card types.
[0056] In addition, to provide a fault tolerance mechanism, if the card information is abnormal (e.g., the card type cannot be identified), a custom card view class can be used to create a card view with blank content through the reflection constructor, which can provide fault tolerance.
[0057] Kotlin language code example:
[0058]
[0059] After creating the custom View base class, ViewHolder class, and card type entities, the basic elements are ready, and we can now create the crucial Adapter. At this point, we can proceed to step S14.
[0060] Step S14: Create an Adapter to determine the card type based on the card information, generate a card View corresponding to this card type and inheriting from the custom View base class, and further generate a ViewHolder object corresponding to this card type. The Adapter calls the public function provided by the ViewHolder class to pass data to the ViewHolder object, and the ViewHolder object calls the public function provided by the card View to pass data to the card View, so that the card View binds the data passed by the ViewHolder object to the card View through the data binding function.
[0061] In this embodiment, the created Adapter is primarily used to determine the card type based on the card information, generate a card View corresponding to that card type and inheriting from a custom View base class, and further generate a ViewHolder object corresponding to that card type. At runtime, the Adapter can call public functions provided by the ViewHolder class to pass data to the ViewHolder object, and the ViewHolder object can call public functions provided by the card View to pass data to the card View. This allows the card View to bind the data passed from the ViewHolder object to the card View through data binding functions. This achieves the functionality of the Adapter.
[0062] For ease of understanding, let's first provide a simple Adapter that supports only one card type. For cases where the data in the data list corresponds to a single card type: an Adapter can be created, denoted as SimpleRVAdapter. After creating this Adapter, there's no need to create a new one; you can use it directly, making development much simpler.
[0063] Kotlin language code example:
[0064]
[0065]
[0066]
[0067] Having learned about the simple RecyclerView adapter SimpleRVAdapter introduced earlier, this section will introduce the RecyclerView adapter MultipleRVAdapter, which supports multiple card types. For scenarios where the data in the list corresponds to multiple card types, an Adapter needs to be created that inherits from MultipleRVAdapter to support multiple card types. Compared to the Adapter that supports multiple card types, the latter involves configuring all card types and distinguishing card types based on the data. The biggest difference is that a new Adapter needs to be created and inherit from MultipleRVAdapter.
[0068] Kotlin language code example:
[0069]
[0070]
[0071]
[0072]
[0073] Therefore, the encapsulation method of the card view generation program creates an Adapter to determine the card type based on the card information, generates a card view corresponding to this card type and inheriting from the custom View base class, and further generates a ViewHolder object corresponding to this card type. The Adapter calls the public functions provided by the ViewHolder class to pass data to the ViewHolder object, and the ViewHolder object calls the public functions provided by the card view to pass data to the card view, so that the card view binds the data passed from the ViewHolder object to the card view through the data binding function. This solution uses a custom View to encapsulate the creation and data binding logic of the card view, achieving full decoupling. Each card does not affect the others, reducing development and maintenance costs. Furthermore, the card view generated based on the created custom View base class can be used in any list and any layout, greatly improving reusability. The secondary encapsulation of Adapter and ViewHolder mainly serves to automatically create card views of the corresponding card type using the custom View base class. By encapsulating the common parts, the implementation of Adapter can be simplified, eliminating the need to create multiple ViewHolders (the ViewHolder class created in this solution is universal), thereby reducing development difficulty and cost.
[0074] By encapsulating the card view generator's methods, a packaged card view generator can be obtained, enabling the automatic creation of card views of the corresponding card type based on the data. When using the card view generator, the data to be displayed can be input, and its card view generation method will generate a card view of the appropriate card type.
[0075] Please see Figure 3 , Figure 3 This is a flowchart of a method for generating a card View according to an embodiment of this application. In this embodiment, the method for generating a card View may include steps S21, S22, S23, and S24.
[0076] After the data is input, the card view generation program can first run step S21.
[0077] Step S21: Obtain the data to be displayed through the Adapter and determine the card type corresponding to the data to be displayed.
[0078] In this embodiment, the input data to be displayed can be obtained through the Adapter, and the card type corresponding to the data to be displayed can be determined. Here, the card type can be distinguished by implementing getItemViewType.
[0079] After determining the card type corresponding to the data to be displayed, step S22 can be executed.
[0080] Step S22: Generate a card View corresponding to this card type and inheriting from the custom View base class through the Adapter, and further create a ViewHolder object corresponding to this card type based on this card type and the generated card View. The custom View base class provides public functions and abstract data binding functions, while the ViewHolder class provides public functions.
[0081] In this embodiment, a card view corresponding to this card type and inheriting from a custom view base class can be generated through an adapter. The custom view base class provides public functions and abstract data binding functions.
[0082] For example, a custom card view class in the Adapter can be used to generate a card view that corresponds to the card type of the data to be displayed and inherits from the custom view base class by calling the reflection constructor.
[0083] Then, based on this card type and the generated card View, a ViewHolder object corresponding to this card type can be created, where the ViewHolder class provides public functions.
[0084] Here, since the ViewHolder class is generic, there is no need to create a separate ViewHolder class for different card types. Instead, a ViewHolder object corresponding to the card type can be generated, and the generated card View can be stored in the ViewHolder object.
[0085] After generating the corresponding card View and ViewHolder objects for the card type, step S23 can be executed.
[0086] Step S23: Call the public function provided by the ViewHolder class through the Adapter to pass the data to be displayed to the ViewHolder object.
[0087] In this embodiment, the Adapter calls the public function provided by the ViewHolder class to pass the data to be displayed to the ViewHolder object.
[0088] After passing the data to be displayed to the ViewHolder object, step S24 can be executed.
[0089] Step S24: Call the public function provided by the card view through the ViewHolder object to pass the data to be displayed to the card view, so that the card view can bind the data to be displayed to the card view through the data binding function.
[0090] In this embodiment, the ViewHolder object can call the public functions provided by the card View to pass the data to be displayed to the card View. Based on this, the card View can bind the data to be displayed to the card View through the data binding function.
[0091] Here, for an example of how to generate a card view, please refer to the Kotlin language code example provided earlier (mainly for cases where the data in the data list corresponds to multiple card types, which also includes the running process of the card view generation method).
[0092] The encapsulated card view generator obtained by encapsulating the card view generator method can be applied to list implementation scenarios.
[0093] Please see Figure 4 , Figure 4A flowchart illustrating a method for displaying a list of cards using a Card View, as provided in an embodiment of this application. In this embodiment, the method for displaying a list of cards using a Card View may include steps S31, S32, and S33.
[0094] First, in scenarios where a list needs to be implemented, there is a data list that needs to be displayed. The data list contains multiple data items, and each data item has a corresponding card type (it can be a single card type or multiple card types; this embodiment uses multiple card types as an example for explanation). Then, step S31 can be executed.
[0095] Step S31: Iterate through and refresh the data list, which contains multiple data entries, each with a corresponding card type.
[0096] In this embodiment, the data list can be iterated and refreshed, and one piece of data can be obtained each time so that the card view generation method can be run based on this data. Thus, step S32 can be executed.
[0097] Step S32: Pass the current data into the card view generation program obtained by the encapsulation method of the card view generation program, and run the card view generation method through the card view generation program to generate a card view corresponding to the card type corresponding to this data.
[0098] In this embodiment, the current data can be passed into the card view generation program obtained by the encapsulation method of the card view generation program. The card view generation program runs the card view generation method and automatically generates a card view corresponding to the card type corresponding to this data.
[0099] After obtaining the card View corresponding to the card type, step S33 can be executed.
[0100] Step S33: The card view binds data to the card view through the data binding function so that the data can be displayed through the card view.
[0101] In this embodiment, the card view can bind data to the card view through the data binding function so that the data can be displayed through the card view.
[0102] The method for displaying a list using a card view can iterate through and refresh the data list. The current data is passed to a card view generator, which is a wrapper around a card view generator. This card view generator then runs its own generation method to create a card view corresponding to the card type specified in the data. Finally, a data binding function binds the data to the card view, allowing it to be displayed. This decoupling, by using a pre-defined card view generator to create the appropriate card view based on the card type, significantly reduces development and maintenance costs, improves reusability, and simplifies Adapter implementation, eliminating the need for multiple ViewHolders. As a result, most of the code for displaying a list using a card view is already encapsulated, requiring only a few lines of code to be used in various scenarios involving displaying lists using card views, greatly reducing development and maintenance costs.
[0103] For a better understanding of this solution, please refer to [link / reference]. Figure 5 , Figure 5 This is a flowchart illustrating a method for displaying a card view list as provided in an embodiment of this application. Figure 5 As shown, the part filled with gray background is the process that needs to be completed when creating a card view for a piece of data. The rest is run automatically by the encapsulated program (card view generation program). Developers only need to focus on the implementation of these few parts filled with gray background, which greatly simplifies the amount of code and reduces development and maintenance costs.
[0104] This application embodiment also provides a storage medium, the storage medium including a stored program, wherein, when the program is running, the device where the storage medium is located is controlled to execute the encapsulation method of the card view generation program in this embodiment, or execute the card view generation method in this embodiment, or execute the card view display list method in this embodiment.
[0105] In summary, this application provides an encapsulation method, generation method, and display method for a card View generation program. The created Adapter determines the card type based on card information, generates a card View corresponding to that card type and inheriting from a custom View base class, and further generates a ViewHolder object corresponding to that card type. The Adapter calls the public functions provided by the ViewHolder class to pass data to the ViewHolder object, and the ViewHolder object calls the public functions provided by the card View to pass data to the card View, so that the card View binds the data passed from the ViewHolder object to the card View through a data binding function. This solution encapsulates the creation and data binding logic of the card View using a custom View, achieving full decoupling. Each card does not affect the others, reducing development and maintenance costs. Furthermore, the card View generated based on the created custom View base class can be used in any list and any layout, greatly improving reusability. The secondary encapsulation of the Adapter and ViewHolder mainly serves to automatically create card Views corresponding to the card type using the custom View base class. By encapsulating common parts, the implementation of the Adapter can be simplified, eliminating the need to create multiple ViewHolders (the ViewHolder class created in this solution is universal), thereby reducing development difficulty and cost.
[0106] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.
[0107] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A method for encapsulating a card view generation program, characterized in that, include: Create a custom View base class to provide public functions and abstract data binding functions; Create a ViewHolder class to store card Views and provide public functions; Create a card type entity to provide card information that reveals the card type; An Adapter is created to determine the card type based on the card information, generate a card View corresponding to this card type and inheriting from the custom View base class, and further generate a ViewHolder object corresponding to this card type. The Adapter calls the public function provided by the ViewHolder class to pass data to the ViewHolder object, and the ViewHolder object calls the public function provided by the card View to pass data to the card View, so that the card View can bind the data passed by the ViewHolder object to the card View through the data binding function. Create a ViewHolder class, including: Create a public RecyclerView.ViewHolder class to store card views; Publicly expose functions for the Adapter to call and pass in data; Card information includes card description and card category number. Create a card type entity, including: Create a card type entity; Add a card description for developers to identify; Add a card category number for the Adapter to identify; Create a custom card view class to create card views using the reflection constructor.
2. The encapsulation method for the card View generation program according to claim 1, characterized in that, Create a custom View base class, including: Load the layout file as a View; Define a data entity, which represents the data that needs to be displayed on the card view; Public functions are provided for the ViewHolder class to call and pass in data; An abstract data binding function is used, with the data binding implemented by the card View.
3. The encapsulation method for the card View generation program according to claim 1, characterized in that, If the card information is abnormal, the custom card view class is also used to create a card view with blank content through the reflection constructor.
4. The encapsulation method for the card View generation program according to claim 1, characterized in that, Creating an Adapter includes: For cases where data in the data list corresponds to a single card type: Create an Adapter, denoted as SimpleRVAdapter, and do not need to create a new Adapter after creating the first one; For situations where data in the data list corresponds to multiple card types: Create an Adapter that inherits from MultipleRVAdapter.
5. A method for generating a card View, characterized in that, A card View generation program applied to a card View generation program based on any one of claims 1 to 4, the method comprising: Obtain the data to be displayed through the Adapter, and determine the card type corresponding to the data to be displayed; The adapter generates a card view corresponding to this card type and inheriting from the custom view base class. Furthermore, based on this card type and the generated card view, a ViewHolder object corresponding to this card type is created. The custom view base class provides public functions and abstract data binding functions, while the ViewHolder class provides public functions. The data to be displayed is passed to the ViewHolder object by calling the public function provided by the ViewHolder class through the Adapter; By calling the public function provided by the card view through the ViewHolder object, the data to be displayed is passed to the card view, so that the card view can bind the data to be displayed to the card view through the data binding function.
6. The method for generating a card View according to claim 5, characterized in that, Generate a card View corresponding to this card type and inheriting from a custom View base class using an Adapter, including: By using a custom card view class in the Adapter, based on the card type corresponding to the data to be displayed, the reflection constructor is called to generate a card view that corresponds to this card type and inherits from the custom view base class.
7. A method for displaying a list using a card view, characterized in that, include: Iterate through and refresh the data list, which contains multiple data items, each with a corresponding card type; The current data is passed into the card view generation program obtained by the encapsulation method of the card view generation program according to any one of claims 1 to 4. The card view generation program runs the card view generation method according to claim 5 or 6 to generate a card view corresponding to the card type corresponding to this data. The card view binds data to the card view through a data binding function so that the data can be displayed through the card view.
8. A storage medium, characterized in that, The storage medium includes a stored program, wherein when the program is executed, the device where the storage medium is located executes the encapsulation method of the card view generation program according to any one of claims 1 to 4, or executes the card view generation method according to claim 5 or 6, or executes the card view display list method according to claim 7.