Method for binding UI interface and data and electronic equipment

Abstract

The invention discloses a UI interface and data binding method and electronic equipment, relates to the field of electronic equipment, and can avoid repeated development in the application development process and improve the application development efficiency. The method comprises the following steps: declaring a binding relationship between a first control and first metadata in an interface description file of a first application, specifying a first data source corresponding to first metadata bound with the first control; declaring a binding relationship between the second control and the first metadata in an interface description file of the second application, and appointing a second data source corresponding to the first metadata bound with the second control; when the first application runs, displaying a first control according to the content of the first metadata corresponding to the first data source; and when the second application runs, displaying the second control according to the content of the second metadata corresponding to the second data source.

Description

[0001] This application is a divisional application. The original application has the application number 202110621395.7 and the original application date is June 3, 2021. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to the field of electronic devices, and more particularly to a method for binding a UI interface to data and an electronic device. Background Technology

[0003] The Model-View-ViewModel (MVVM) architecture is a software architecture pattern. The MVVM architecture separates the development of the graphical user interface (GUI) from the development of business logic or backend logic (data model).

[0004] like Figure 1 As shown, applications based on the MVVM architecture are abstracted into Model (i.e., data, also known as backend data), View (i.e., the UI interface), and ViewModel. Application developers can define the ViewModel and bind various controls in the UI interface to the data through the ViewModel. In this way, when the UI interface changes, the data updates automatically accordingly. When the data changes due to business logic updates or other reasons, the UI interface also updates automatically. This automatic updating process of data and UI interface eliminates the need for users to write complex and repetitive program code, reducing the development cost for application developers.

[0005] Currently, the MVVM architecture is primarily implemented based on Google®'s DataBinding library. Application developers use Android Studio (an Android® integrated development environment) that integrates the DataBinding library to develop application interface description files, etc. Specifically, application developers can define a specific ViewModel for a particular interface based on its design. This specific ViewModel provides data to that specific interface, contains data processing business logic, and communicates with the Model. Then, developers declare the binding relationship between specified UI controls and this specific ViewModel in the interface description file. Subsequently, Android APT (a tool for processing annotations) is used to pre-compile the interface description file, generating several files with binding logic, such as Extensible Markup Language (XML) files, Java files for binding settings, BR class files, and Mapper files, to implement the binding between the UI interface and data, thereby completing the application development based on the MVVM architecture.

[0006] It's important to note that in this technical solution, each application developer needs to define a specific ViewModel for their respective interfaces. Furthermore, the DataBinding library only helps application developers complete data binding between a specific ViewModel and a specific View within a specific interface; the logic between specific ViewModels and Models, as well as the internal logic of the Model module, still needs to be implemented by the application developers. Understandably, different interfaces within the same application may need to bind the same data, or interfaces in different applications may also need to bind the same data. Therefore, application developers still need to define different ViewModels for different interfaces or different applications, and develop separate code for the interactions between each ViewModel and Model. This results in significant repetitive development and low application development efficiency. Summary of the Invention

[0007] This application provides a method for binding UI interfaces and data, as well as an electronic device, which can avoid repetitive development during application development and improve application development efficiency.

[0008] To achieve the above objectives, the embodiments of this application provide the following technical solutions: A first aspect provides a method for binding a UI interface with data, comprising: running a device to install an installation package of a first application and an installation package of a second application, wherein the installation package of the first application includes a first interface description file, the first interface description file contains the binding relationship between a first control and first metadata in the first interface of the first application, and the first metadata bound to the first control corresponds to a first data source; wherein the installation package of the second application includes a second interface description file, the second interface description file contains the binding relationship between a second control and first metadata in the second interface of the second application, and the first metadata bound to the second control corresponds to a second data source; the running device receives a first operation from a user to open the first interface of the first application, and in response to the first operation, the running device displays the first control in the first interface of the first application according to the first metadata corresponding to the first data source; the running device receives a second operation from a user to open the second interface of the second application, and in response to the second operation, the running device displays the second control in the second interface of the second application according to the first metadata corresponding to the second data source.

[0009] In other words, the binding relationship between the first control and the first metadata is declared in the interface description file of the first application, and the first data source corresponding to the first metadata bound to the first control is specified; the binding relationship between the second control and the first metadata is declared in the interface description file of the second application, and the second data source corresponding to the first metadata bound to the second control is specified; when the first application is run, the first control is displayed according to the content of the first metadata corresponding to the first data source; when the second application is run, the second control is displayed according to the content of the second metadata corresponding to the second data source.

[0010] Metadata, also known as intermediary data, relay data, or intermediate data, is data about data, such as information describing data properties. Therefore, the first metadata provided in this application embodiment can be used by both the first and second applications. This eliminates the need for developers of both applications to duplicate development work related to the first metadata, thereby improving application development efficiency.

[0011] In one possible implementation, the first interface description file uses a first interface description language, and the second interface description file uses a second interface description language. The first interface description language and the second interface description language are different.

[0012] In practical implementation, metadata can be defined using a declarative approach. That is, defining metadata is independent of the interface description language used by the developer. In other words, the UI interface and data binding method provided in this application embodiment can support developers in using any interface description language to develop applications, and the developed applications can run on any operating platform.

[0013] In one possible implementation, the first interface description file uses any one of the following interface description languages: Extensible Markup Language (XML), Domain-Specific Language (DSL), or Embedded Domain-Specific Language (EDSL); the second interface description file uses any one of the following interface description languages: XML, DSL, or EDSL.

[0014] In one possible implementation, the binding relationship between the first control and the first metadata includes: the binding relationship between the first control and one or more attributes of the first metadata; in response to the first operation, the running device displays the first control in the first interface of the first application according to the first metadata corresponding to the first data source, including: in response to the first operation, the running device displays the first control in the first interface of the first application according to one or more attributes of the first metadata corresponding to the first data source.

[0015] In one possible implementation, the binding relationship between the first control and one or more properties of the first metadata includes: the first control corresponding to a first operational expression, or the first control corresponding to a first function, or the first control corresponding to a first interface; wherein the first operational expression includes one or more properties of the first metadata; the parameters of the first function include one or more properties of the first metadata; and the input parameters of the first interface include one or more properties of the first metadata.

[0016] Therefore, the binding tool provided in this application embodiment, in addition to directly updating the content of the read data source onto the display interface, can also preprocess the content of the read data source and update the display interface with the preprocessed content. Preprocessing can be achieved through arithmetic expressions, functions, binding interfaces, etc. For example, it can merge (e.g., concatenate), convert (e.g., base-24 to base-12, case conversion, simplified / traditional Chinese character conversion, date format conversion, currency conversion, etc.) the content of attributes from multiple metadata, and perform calculations. This eliminates the need for application developers to write corresponding program code, simplifying the development process and improving application development efficiency.

[0017] In one possible implementation, in the first interface description file, the first control is also bound to one or more attributes of the second metadata, and the second metadata bound to the first control corresponds to a third data source; when the running device displays the first control in the first interface of the first application in response to the first operation, the running device displays the first control in the first interface of the first application according to the first metadata corresponding to the first data source and the second metadata corresponding to the third data source.

[0018] In other words, the first control can be bound to multiple properties of multiple metadata.

[0019] In one possible implementation, the data formats of the first data source and the second data source are the same.

[0020] It should be noted that the data source in this document is data that meets the same or similar preset format as the metadata definition, or the binding tool provided in this application embodiment can convert data of different formats into the aforementioned preset format. In other words, the data sources in this application embodiment have a unified format, or data sources of the same business type have a unified format, or data sources of the same data type have a unified format. Since the data sources have a unified format or a certain type of data has a unified format, the binding tool provided in this application embodiment can automatically specify the binding relationship between metadata and data sources according to the data sources corresponding to the metadata specified in the layout file, and set monitoring for data sources bound with metadata. This reduces the development workload of developers and improves the development efficiency of applications.

[0021] In one possible implementation, the installation package of the first application and / or the installation package of the second application contain a definition file for the first metadata.

[0022] In one example, the installation package of the application (first application and / or second application) also includes a metadata definition file. In other examples, the metadata definition file may also be maintained on a server (e.g., a server providing binding tools, or a server running the device). For example, all applications may correspond to one or more metadata definition files, or different types of applications may correspond to different metadata definition files, or different metadata types may correspond to different metadata definition files. Therefore, the installation package of the first application and / or the second application may not include the metadata definition file, and the running device may download the metadata definition file from the server.

[0023] In one possible implementation, the definition file for the first metadata is a JSON file.

[0024] Understandably, JSON is a lightweight data-interchange format that uses a text format completely independent of programming languages ​​to store and represent data, thus avoiding the constraints of application development languages ​​and platforms. In other words, developers can parse the aforementioned metadata definition file when developing application A using any language and running on any platform.

[0025] In one possible implementation, the definition file of the first metadata includes the format standard, name, description, data type, one or more attributes contained in the first metadata, and information about one or more attributes.

[0026] The description can be used to define the purpose of the first metadata. This provides a preset format for metadata definition.

[0027] In one possible implementation, the first application installation package also includes a third interface description file. The third interface description file contains the binding relationship between the third control and the first metadata in the third interface of the first application. The first metadata bound to the third control corresponds to a fourth data source. The third interface is different from the first interface, and the fourth data source is the same as or different from the first data source.

[0028] In other words, not only can different applications reuse the same metadata, but different interfaces of the same application can also reuse the same metadata, and the metadata reused by different interfaces can specify the same or different data sources.

[0029] In one possible implementation, in response to the first operation, after the running device displays the first control in the first interface of the first application based on the first metadata corresponding to the first data source, the method further includes: after the running device detects that the first metadata corresponding to the first data source has changed, displaying the first control in the first interface of the first application based on the changed first metadata corresponding to the first data source; or, after detecting that the first control has changed, updating the first metadata corresponding to the first data source based on the change of the first control.

[0030] Therefore, it is evident that when the binding tool on the running device side only reads the data content of the changed attributes and only updates the UI controls bound to the changed attributes, it helps to speed up the update of the UI interface on the running device and improve the response efficiency of the application. It is understandable that when a piece of metadata contains many attribute values, or the data volume corresponding to the attribute values ​​is large, or when the data corresponding to the metadata comes from different applications, different running devices, or servers, reading the data content of the changed attributes and updating the UI controls bound to the changed attributes helps to speed up the update of the UI interface of the primary application on the running device and improve the response efficiency of the primary application.

[0031] In one possible implementation, the first interface description file includes the binding relationship between the first control and the first attribute of the first metadata in the first interface of the first application, and the binding relationship between the fourth control and the second attribute of the first metadata in the first interface of the first application; and the first metadata bound to the fourth control corresponds to the first data source; after the running device detects that the first metadata corresponding to the first data source has changed, it displays the first control in the first interface of the first application according to the changed first metadata corresponding to the first data source, including: when the running device detects that the first attribute of the first metadata corresponding to the first data source has changed, but the second attribute of the first metadata corresponding to the first data source has not changed, the running device refreshes the first control in the first interface of the first application according to the change of the first attribute of the first metadata corresponding to the first data source, but does not refresh the fourth control in the first interface of the first application.

[0032] In one possible implementation, the first interface description file also includes the binding relationship between the first metadata bound to the first control and the first data source.

[0033] Secondly, a method for developing an application is provided, comprising: a development device displaying a first development interface of a first application; in response to receiving a first operation from a user on the first development interface, the development device generating a first interface description file, the first interface description file including the binding relationship between a first control and first metadata in the first interface of the first application, and the first metadata bound to the first control corresponding to a first data source; the development device generating an installation package of the first application based on the first interface description file; the development device displaying a second development interface of a second application; in response to receiving a second operation from a user on the second development interface, the development device generating a second interface description file, the second interface description file including the binding relationship between a second control and first metadata in the second interface of the second application, and the first metadata bound to the second control corresponding to a second data source; the development device generating an installation package of the second application based on the second interface description file.

[0034] Therefore, when developing interface description files for different applications, the same metadata (i.e., the first metadata) can be reused. This way, developers of different applications do not need to repeat the development work related to this metadata, thereby improving the development efficiency of applications.

[0035] In one possible implementation, the binding relationship between the first control and the first metadata includes: the binding relationship between the first control and one or more properties of the first metadata.

[0036] In one possible implementation, the binding relationship between the first control and one or more properties of the first metadata includes: the first control corresponding to a first operational expression, or the first control corresponding to a first function, or the first control corresponding to a first interface; wherein the first operational expression includes one or more properties of the first metadata; the parameters of the first function include one or more properties of the first metadata; and the input parameters of the first interface include one or more properties of the first metadata.

[0037] In one possible implementation, in the first interface description file, the first control is also bound to one or more properties of the second metadata, and the second metadata bound to the first control corresponds to a third data source.

[0038] In one possible implementation, the first interface description file uses a first interface description language, and the second interface description file uses a second interface description language. The first interface description language and the second interface description language are different.

[0039] In one possible implementation, the first interface description file uses any one of the following interface description languages: Extensible Markup Language (XML), Domain-Specific Language (DSL), or Embedded Domain-Specific Language (EDSL); the second interface description file uses any one of the following interface description languages: XML, DSL, or EDSL.

[0040] In one possible implementation, the installation package of the first application and / or the installation package of the second application contain a definition file for the first metadata.

[0041] In one possible implementation, the definition file of the first metadata includes the format standard, name, description, data type, one or more attributes contained in the first metadata, and information about one or more attributes.

[0042] In one possible implementation, the first interface description file also includes the binding relationship between the first metadata bound to the first control and the first data source.

[0043] Thirdly, a running device is provided, comprising: a processor, a memory, and a display screen, wherein the memory and the display screen are coupled to the processor, the memory is used to store computer program code, the computer program code including computer instructions, and when the processor reads the computer instructions from the memory, the running device executes the UI interface and data binding method described in the first aspect and any possible implementation thereof.

[0044] Fourthly, a development device is provided, comprising: a processor, a memory, and a display screen, wherein the memory and the display screen are coupled to the processor, the memory being used to store computer program code, the computer program code including computer instructions, wherein when the processor reads the computer instructions from the memory, the development device executes the application development method described in the second aspect and any possible implementation thereof.

[0045] Fifthly, an apparatus is provided, comprising an operating device or a development device, having the function of implementing the behaviors of the operating device or development device as described in the foregoing aspects and any possible implementations thereof. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes at least one module or unit corresponding to the aforementioned function. For example, a communication module or unit, and a processing module or unit, etc.

[0046] A sixth aspect is to provide a computer-readable storage medium including computer instructions that, when executed on a running device or development device, cause the running device or development device to perform the methods of the first aspect, the second aspect, and any possible implementation of the first aspect or the second aspect.

[0047] Seventh aspect, a computer program product is provided, which, when run on a computer, causes the computer to perform the methods of the first aspect, the second aspect, and any possible implementation of the first aspect or the second aspect.

[0048] Eighth aspect, a chip system is provided, including a processor, which, when executing instructions, performs the methods described in the first aspect, the second aspect, and any possible implementation of the first or second aspect.

[0049] It is understood that the beneficial effects achieved by the methods, operating devices, development devices, apparatuses, computer-readable storage media, computer program products, and chip systems provided in the second to eighth aspects above can be referenced to the beneficial effects in the first aspect and any of its possible design embodiments, which will not be repeated here. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of an MVVM architecture; Figure 2 A schematic diagram illustrating a UI interface and data binding method provided in an embodiment of this application; Figure 3 A flowchart illustrating a method for updating a UI interface based on data, provided in an embodiment of this application; Figure 4 A schematic diagram illustrating a method for updating data and updating the UI interface of a running device, provided in an embodiment of this application; Figure 5 This is a schematic diagram illustrating a method for converting different data formats using an operating device, as provided in an embodiment of this application. Figure 6 This is a schematic diagram of the structure of an operating device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of another operating device provided in an embodiment of this application; Figure 8 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0051] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0052] This application provides a method for binding a UI interface with data, which can be applied to both the application development stage and the application runtime stage.

[0053] I. Application Development Stage In this embodiment, the developer declares the binding relationship between specific UI controls and metadata in the application's interface description file, and specifies the source of the data corresponding to the metadata in the binding relationship, thereby establishing a binding relationship between specific UI controls and data in the UI interface. For example, Figure 2 As shown, the UI is a contact's interface, which includes control 1. In the interface description file corresponding to this contact's interface, control 1 is bound to metadata (specifically, an attribute within the metadata), and the source of the data corresponding to the metadata is specified. Subsequently, the content of the corresponding data is obtained through the bound metadata and the corresponding data source, thereby realizing the binding between control 1 and the data.

[0054] Metadata, also known as intermediary data, relay data, or intermediate data, is data about data, such as information describing data properties. This metadata can be predefined, allowing developers of various applications to use it directly. Alternatively, the metadata can be defined by the developer of a specific application, allowing developers of other applications to use it directly. Or, the metadata can be defined by a developer when developing a specific interface of an application, but can also be used directly when developing other interfaces of the same application. In other words, the metadata provided in this application embodiment can be used by multiple interfaces of the same application or different applications. Furthermore, the metadata provided in this application embodiment embodiment enables the reuse of multiple interfaces, which helps reduce the workload of developers in repetitive development and improves development efficiency.

[0055] In practical implementation, metadata can be defined using a declarative approach. That is, defining metadata is independent of the interface description language used by the developer. In other words, the UI interface and data binding method provided in this application embodiment can support developers using any interface description language to develop applications, and the developed applications can run on any operating platform. Interface description languages ​​include Extensible Markup Language (XML), Domain Specific Language (DSL), and Embedded Domain Specific Language (EDSL), etc. Operating platforms can include Google's Android system, Apple's iOS system, or Huawei's HarmonyOS system, etc. In other words, the UI interface and data binding method provided in this application embodiment can achieve cross-language and cross-platform UI interface and data binding. For example, if developer 1 defines metadata 1 when developing application A, where application A is an application running on the Android system and its interface description language is XML. When developer 2 is developing application B that runs on the HarmonyOS system, and application B uses EDSL as its interface description language, it can still directly declare the binding relationship between the UI controls of a certain interface in application B and metadata 1.

[0056] Specifically, developers use an integrated development environment (IDE) on the development device to develop applications. IDE tools typically include code editors, compilers, debuggers, and graphical user interfaces, forming a unified software service suite that integrates code writing, analysis, compilation, and debugging capabilities. For example, typical Android system IDE tools include Android Studio and DevEco Studio. Exemplarily, in this application embodiment, the development device can be a computer, mobile phone, tablet computer, server, etc., and this application does not impose any special limitations on the specific form of the development device. The structure of the development device can be referenced... Figure 6 The description of the operating device 100 will not be repeated here. It is understood that the development device may include more or fewer components than the operating device 100, or combine some components, or separate some components, or have different component arrangements. The components illustrated may be implemented in hardware, software, or a combination of both.

[0057] In some examples, embodiments of this application provide a UI interface and data binding tool (hereinafter referred to as the binding tool), which can be integrated into an IDE tool as a library. Alternatively, developers can import the binding tool provided by embodiments of this application into an IDE tool by adding a dependency library. Then, developers can call the capabilities provided by the binding tool to develop the application's interface. It should be noted that the module applied to the development device in the binding tool provided by embodiments of this application is also referred to as the development device-side binding tool.

[0058] The application's interface development includes interface description and interface behavior definition. Interface description refers to describing the UI layout, controls used, and the visual style of the layout and controls using an interface description language. In this embodiment, developers can use any interface description language, such as XML, DSL, EDSL, etc., to create an interface description file, also known as a layout file. Interface behavior definition refers to defining the dynamic changes or responses of the interface, such as responses to user UI operations. In this embodiment, interface behavior definition can be developed using programming languages ​​such as Java and C++ to create a program code file.

[0059] For example, in step 1), when developing the interface description file of application A (e.g., specifically the interface description file for interface 1 of application A), the developer can define new metadata using a preset format and use the newly defined metadata, or directly use existing metadata. The existing metadata can be metadata defined by the developer when developing other interfaces of application A (e.g., interface 2 of application A), or metadata defined by other developers when developing other applications (e.g., application B). In one specific embodiment, the developer can define metadata in a JavaScript Object Notation (JSON) file. In other words, the metadata definition file is a JSON file. It is understood that JSON is a lightweight data exchange format that uses a text format completely independent of programming languages ​​to store and represent data, thereby avoiding the constraints of the application's development language and platform. In other words, the developer can parse the aforementioned metadata definition file when developing application A using any language and running on any platform.

[0060] The following is an example of a preset format provided in an embodiment of this application.

[0061] Metadata standards: xxx / / Used to describe the format standards, etc., of the defined metadata Metadata name: MetaData1 / / The name of the defined metadata Metadata description: xxx / / Used to describe the purpose of the defined metadata, etc. Metadata type: xxx / / This specifies the data type of the defined metadata. It can be a basic type (such as int, string, object, integer, etc.) or a composite type (i.e., nested multiple basic types). Metadata attributes: / / Used to define the content of each attribute (or field) in the metadata. Attribute1Name / / Used to define the name of attribute1 in the metadata Type: xxx / / Used to define the type of attribute 1 in the metadata, such as int, string, object, integer, etc. Constraints: xxx / / Used to define constraints for attribute 1 in metadata, such as the range of values ​​for attribute 1, etc., which can be omitted. Attribute 2 Name Type: xxx Constraints: xxx Attribute 3 Name Type: xxx Constraints: xxx For example, the metadata of flight information can be defined using the above preset format as follows: { "id": "com.example.middleplatform.harmonymiddleplatformdemo.meta-data.flightInfo", / / Identifier of metadata "title": "flight schema", / / Name of metadata "$schema": "http: / / json-schema.org / draft-04 / schema#", "description": "flight description", / / Purpose of metadata - used to describe flight information "type": "object", / / Type of metadata "properties": { "_id": { / / Name of attribute 1 in metadata - used to describe flight number "type": "integer" / / Type of metadata attribute 1 }, "flightName": { / / Name of attribute 2 in metadata - used to describe the airline "type": "string" / / Type of metadata attribute 2 }, "source": { / / Name of metadata attribute 3 - used to describe the origin "type": "string" / / Type of metadata attribute 3 }, "destination": { / / Name of metadata attribute 4 - used to describe the destination "type": "string" / / Type of metadata attribute 4 }, "time": { / / Name of metadata attribute 5 - time "type": "string" / / Type of metadata attribute 5 } } } For example, the metadata for an alarm clock message can be defined using the above preset format as follows: { "id": "com.example.meta-data.alarm", "title": "alarm schema", "$schema": "http: / / json-schema.org / draft-04 / schema#", "description": "alarm description", / / Used to describe alarm information "type": "object", "properties": { "id": { / / Name of metadata attribute 1 - id "type": "integer" }, "hour": { / / Name of attribute 2 in metadata - hour "type": "integer" }, "minutes": { / / Name of metadata attribute 3 - minutes "type": "integer" }, "daysofweek": { / / Name of metadata attribute 4 - Weekday settings "type": "integer" }, "enabled": { / / Name of metadata attribute 5 - whether it is enabled "type": "integer" }, "message": { / / Name of metadata attribute 6 - message "type": "string" } } } Step 2) The developer declares the binding relationship between UI controls and metadata in the interface description file of interface 1. Specifically, the binding tool provided in this application embodiment can support the developer to declare the binding relationship between a UI control and one or more attributes of a metadata in the interface description file, as well as the binding relationship between a UI control and multiple attributes of multiple metadata, and the binding relationship between multiple UI controls and one attribute of a metadata.

[0062] Scenario 1: Declare the binding relationship between a UI control and a property of metadata. For example, in the interface description file of interface 1, the format "UI control identifier: @{metadata name.property name}" is used to declare the binding relationship between the UI control in interface 1 and the property in the metadata.

[0063] For example, taking the metadata of the flight information above as an example, it can be declared in the interface description file as: View1: @{flight schema.id}. As another example, taking the metadata of the alarm information above as an example, it can be declared in the interface description file as: View2: @{alarm schema.daysofweek}.

[0064] Scenario 2: Declare the binding relationship between a UI control and multiple properties of one or more metadata. Method 1: Developers can use computational expressions to declare the binding relationship between a UI control and multiple properties of one or more metadata.

[0065] For example, `UI control 1: @{metadata name 1.property name 1} + @{metadata name 1.property name 2}` can be used to declare the binding relationship between UI control 1 and metadata 1 (the metadata corresponding to metadata name 1) for property 1 and property 2. In other words, the displayed content of UI control 1 is the concatenation of the contents of property 1 and property 2 in metadata 1. To put it another way, the displayed content of UI control 1 is simply the content of property 1 and property 2 in metadata 1, without any other content (including spaces or symbols). Optionally, developers can also declare that spaces, punctuation, or strings are added when concatenating the attribute content of metadata. For example, `UI control 1: @{metadata name 1.property name 1} + ":" + @{metadata name 1.property name 2}` can also be used to declare the binding relationship between UI control 1 and metadata 1 for property 1 and property 2. The difference is that, in addition to the contents of property 1 and property 2 in metadata 1, the displayed content of UI control 1 also includes a colon (":") between the contents of property 1 and property 2 in metadata 1. Of course, “:” can also be replaced with other symbols, strings, spaces, etc. The specific splicing method is not limited in the embodiments of this application.

[0066] For example, TextView1 is used to display the time, including hours and minutes. Taking the metadata of the alarm clock information above as an example, the developer can declare the binding relationship as follows: TextView1:@{alarm schema.hour} + ":" +@{alarmschema.minutes}. Then, when the device is displaying the interface, if the content of alarm schema.hour is "10" and the content of alarm schema.hour is "20", then the content of TextView1 in the interface displayed by the device will be "10:20".

[0067] For another example, UI control 1: "@{metadata name 1.property name 1} +@{metadata name 1.property name 2} + @{metadata name 2.property name 3}" can be used to declare the binding relationship between UI control 1 and property 1, property 2 of metadata 1, and property 3 of metadata 2 (the metadata corresponding to metadata name 2). In other words, the displayed content of UI control 1 is the concatenation of the content of property 1, property 2, and property 3 of metadata 1.

[0068] Of course, the binding method of arithmetic expressions can also support binding a control to a property of metadata.

[0069] Method 2: Developers can also declare the binding relationship between a UI control and multiple properties of one or more metadata using functions. For example, "UI control 1: *{function name 1 (metadata name 1.property name 1, metadata name 2.property name 2)}" can be used to declare the binding relationship between UI control 1 and properties 1 and 2 of metadata name 1. That is, the displayed content of UI control 1 is the result of the operation of properties 1 and 2 of metadata 1 using function 1 (the function corresponding to function name 1). Here, function 1 can be a predefined function provided by the binding tool, a function defined by the developer of application A, or a function defined by the developer of another application. Optionally, if the function is defined by the developer of application A, the definition of the function is included in the installation package of application A along with the interface description file and passed to the running device. Optionally, if the function is predefined by the binding tool or defined by the developer of another application, the definition of the function can also be included in the installation package of application A along with the relevant program code of the binding tool and passed to the running device. Alternatively, the running device can download the definition file of the function from the server.

[0070] For example, TextView2 is used to display the time zone. Developers can define function 1, whose input parameter is the hour of the time, and whose output parameter is the time zone corresponding to that hour. Taking the metadata of the alarm clock information above as an example, developers can declare the binding relationship as follows: TextView1: * ClockMetaData.getTimeZone(@{ClockMetaData.hour}). Here, ClockMetaData.getTimeZone() is the defined function 1, used to output the time zone corresponding to that hour.

[0071] Of course, the function method can also support binding a control to a property of metadata.

[0072] Method 3: Developers can also declare the binding relationship between a control and multiple properties of one or more metadata by calling the binding interface.

[0073] In other words, the binding tool provides a corresponding programmatic binding interface. Developers can call this binding interface and input the names and properties of the UI control and metadata to be bound to achieve the binding. For example, "binding interface (UI control 1, metadata name 1. property name 1, metadata name 1. property name 2)" is used to bind UI control 1 and property 1 and property 2 of metadata 1.

[0074] Optionally, this binding interface can also implement certain functions, such as displaying the time in base-24 or base-12. Let's continue with the example of alarm clock metadata. For instance, the binding interface could be (TextView1, alarmschema.hour, alarm schema.minutes). After obtaining the hour and minute metadata, this binding interface will convert the time into base-24 or base-12 and display it in TextView1.

[0075] Of course, calling the binding interface can also support binding a control to a property of metadata.

[0076] Scenario 3: Declare the binding relationship between multiple properties of a UI control and a property of a metadata.

[0077] In some scenarios, a UI control may include multiple properties, and these properties correspond to a single property in metadata. For example, a UI control might be a timepicker with AM / PM, hour, and minute properties. This UI control might correspond to a metadata property, such as the time property. Developers can then bind these multiple UI control properties to a single metadata property using functions or by calling a binding interface. Specific binding methods can be found in the descriptions of methods 2 and 3 in Scenario 2, and will not be elaborated upon here.

[0078] Therefore, the binding tool provided in this application embodiment, in addition to directly updating the content of the read data source onto the display interface, can also preprocess the content of the read data source and update the display interface with the preprocessed content. For example, it can merge (e.g., concatenate), convert (e.g., base-24 to base-12, case conversion, simplified / traditional Chinese character conversion, date format conversion, currency conversion, etc.), and perform calculations on the attributes of multiple metadata. This eliminates the need for application developers to write corresponding program code, simplifying the development process and improving application development efficiency.

[0079] Step 3) The developer specifies the source of the data corresponding to the bound metadata in the interface description file corresponding to Interface 1 (hereinafter referred to as the data source). The data source includes data in the same application on the same device, data in different applications on the same device, data in the same application on different devices, data in different applications on different devices, server data, etc.

[0080] It should be noted that the data source in this document is data that meets the same or similar preset format as the metadata definition, or the binding tool provided in this application embodiment can convert data of different formats into the aforementioned preset format. In other words, the data sources in this application embodiment have a unified format, or data sources of the same business type have a unified format, or data sources of the same data type have a unified format. Since the data sources have a unified format or a certain type of data has a unified format, the binding tool provided in this application embodiment can automatically specify the binding relationship between metadata and data sources according to the data sources corresponding to the metadata specified in the layout file, and set monitoring, etc., for data sources bound with metadata.

[0081] In existing Databinding toolkits, the format of the Model varies. Developers not only need to define specific ViewModels for specific interfaces and declare the binding relationships between UI controls and specific ViewModels in the layout file, but also need to manually set the binding relationships between specific ViewModels and Models, and set monitoring relationships in the Model based on these binding relationships. In other words, developers also need to develop corresponding program code to set specific ViewModel-Model binding relationships and monitoring relationships in the Model. However, the binding tool provided in this application embodiment can automatically specify the binding relationship between metadata and data sources, and set monitoring for data sources bound with metadata. Therefore, the binding tool provided in this application embodiment reduces the developer's workload and improves application development efficiency.

[0082] It's important to note that the same metadata can specify different data sources. For example, in Interface 1 of Application A, Control 1 is bound to Metadata 1, specifying that the data source for Metadata 1 is data from the same application on the same device. In Interface 1 of Application A, Control 2 is also bound to Metadata 1, but specifies that the data source for Metadata 1 is data from the server. As another example, in Interface 1 of Application A, Control 1 is bound to Metadata 1, specifying that the data source for Metadata 1 is data from the same application on the same device. In Interface 3 of Application B, Control 3 is also bound to Metadata 1, but specifies that the data source for Metadata 1 is data from the server. Therefore, the same metadata can specify different data sources, allowing applications on the same device or on different devices to reuse the same metadata, reducing the workload for developers and improving application development efficiency.

[0083] Step 4) The developer packages the interface description file of application A, the program code of application A, and related display resources into the installation package of application A, and then puts the installation package of application A on the app store.

[0084] In one example, the installation package of application A includes a metadata definition file (e.g., a JSON file). In other examples, the metadata definition file may also be maintained on a server (e.g., a server providing binding tools, or a server running the device). For instance, all applications may have one or more metadata definition files, different types of applications may have different metadata definition files, or different metadata types may have different metadata definition files. Therefore, the installation package of application A may not include a metadata definition file, and the running device may download the metadata definition file from the server.

[0085] II. Application Operation Phase When a running device (an electronic device running application A) downloads and installs the installation package of application A from an application market, and runs application A, the running device can use the binding tool provided in this application embodiment to achieve two-way binding between UI controls and data in interface 1. In one example, the installation package of application A also carries the relevant program code of the binding tool. After the running device decompresses and installs the installation package of application A, it obtains the relevant program code of the binding tool, which enables two-way binding between UI controls and data in interface 1. In another example, the installation package of application A may not carry the relevant program code of the binding tool. In this case, the running device needs to pre-install the relevant program code module of the binding tool before running application A. For example, the pre-installed operating system of the running device contains the relevant program code module of the binding tool, or the running device can download and install the relevant program code module of the binding tool from a server (e.g., a server that provides the binding tool, or a server of the running device). It should be noted that the module applied to the running device in the binding tool provided in this application embodiment is also called the binding tool on the running device side.

[0086] Specifically, the running device can parse the metadata information bound to the UI controls in Interface 1 based on the metadata definition file (which can be included in the installation package of Application A or downloaded from the server) and the interface description file of Interface 1 of Application A, and identify the data source corresponding to the metadata bound to the UI controls in Interface 1. Then, the running device obtains the data content from the corresponding data source and sets the content of the corresponding UI controls in Interface 1 according to the obtained data content. Furthermore, the running device can monitor the data corresponding to the metadata bound to the UI controls in Interface 1, and also monitor the UI controls in Interface 1. When a change is detected in the data corresponding to the metadata bound to the UI controls in Interface 1, the content of the corresponding UI controls in Interface 1 is refreshed accordingly. When changes are detected in the UI controls in Interface 1 (including the displayed content of the UI controls, the state of the UI controls, user operations on the UI controls, etc.), the data corresponding to the UI controls is modified accordingly.

[0087] Since the binding tool on the developer side in this application embodiment allows developers to declare and bind UI controls and metadata using computational expressions or functions, correspondingly, the binding tool on the device side also includes calculating the read data based on the computational expressions or functions and then displaying the calculation results on the interface. For example... Figure 3 The process shown involves the device reading data from a specified data source and then determining whether the binding relationship contains an arithmetic expression or function. If it does, the corresponding arithmetic expression or function is invoked to perform calculations on the read data, and the result is displayed in a specific UI control within the UI interface.

[0088] Conversely, when the operating device detects a change in the content of a specific UI control in the UI interface, the operating device performs the inverse operation based on the above-mentioned arithmetic expression or function, and uses the result of the inverse operation to update the data in the corresponding data source.

[0089] In some embodiments of this application, when the binding tool on the running device side detects a change in the data corresponding to certain metadata, it rereads the data content corresponding to the metadata to update the UI controls bound to the metadata in the UI interface. That is, when the metadata contains multiple attributes, it does not distinguish which attribute(s) among the multiple attributes in the metadata has changed; it directly rereads the data content of all attributes of the metadata. Then, it updates all UI controls bound to the metadata in the UI interface according to the reread data content.

[0090] In other embodiments of this application, when the binding tool on the running device side detects a change in data corresponding to certain metadata, it specifically distinguishes which attribute(s) in the metadata have changed data content, and only updates the UI controls bound to these changed attributes in the UI interface. In one specific implementation, the binding tool on the running device side reads the data content of all attributes in the metadata, compares it with the previous data content, and determines the changed attributes in the metadata. However, based on the obtained data content of the changed attributes, it updates the UI controls bound to these changed attributes in the UI interface. In another specific implementation, each data source can add an identifier bit to the data to mark whether the data has changed. Then, the binding tool on the running device side can only read the identifier bits of each attribute in the metadata to determine which attributes in the metadata have changed data content. Then, it only reads the data content of the changed attributes and updates the UI controls bound to these changed attributes.

[0091] Therefore, it is evident that when the binding tool on the running device side only reads the data content of the changed attributes and only updates the UI controls bound to the changed attributes, it helps to speed up the update speed of the running device's UI interface and improve the application's response efficiency. This is understandable when a piece of metadata contains many attribute values, or the data volume corresponding to those attribute values ​​is large, or when the data corresponding to that metadata comes from different applications, different running devices, or servers. In such cases, reading the data content of the changed attributes and updating the UI controls bound to those changed attributes helps to speed up the update speed of application A's UI interface and improve application A's response efficiency.

[0092] Similarly, in some embodiments, when the binding tool on the running device side detects a change in the UI of application A, it can read the content of all UI controls in the UI and update the data of all attributes in the corresponding metadata in the data source based on the read content of all UI controls. In other embodiments, when the binding tool on the running device side detects a change in the UI of application A, it reads the content of the changed UI controls and updates the data of the corresponding attributes in the corresponding metadata in the data source based on the changed UI controls.

[0093] For example, such as Figure 4 As shown, assume that in application A, control group 1 in the UI is bound to metadata 1, and metadata 1 is bound to data 1. Specifically, control 1 is bound to attribute 1 in data 1, and control 2 is bound to attribute 2 in data 1. Similarly, control group 2 in the UI is bound to metadata 2, and metadata 2 is bound to data 2. Specifically, control 3 is bound to attribute 3 in data 2, and control 4 is bound to attribute 4 in data 2. When application A is running on a device, if the device-side binding tool detects a change in the content of control 4 in the UI while the content of the other controls remains unchanged, the tool reads the content of control 4 and updates the content of attribute 4 in data 2. Likewise, if the tool detects a change in the content of attribute 1 in data 1 while the content of the other attributes remains unchanged, the tool reads the content of attribute 1 and updates the content of control 1.

[0094] Furthermore, as mentioned earlier, the data provided by each data source is in the same or similar format as the preset format defined in the metadata, or the binding tool provided in this application embodiment can convert data in different formats provided by each data source into the aforementioned preset format. In some specific implementations, the binding tool on the running device side also includes a data standardization interface, used to convert data in different formats from different applications or different devices into a format that is the same as or similar to the aforementioned preset format. For example, such as Figure 5 As shown, in the interface description file of application A running on the running device, the specified metadata source can be data from other applications on the same running device (e.g., application B on the running device), data from applications running on other running devices (e.g., application A or application C), or data from a server (e.g., data from application A, application C, or application D). It is understandable that when different data sources provide data in different formats, the binding tool on the running device side can convert the acquired data into the same or similar format as defined in the metadata.

[0095] For example, the operating device in the embodiments of this application may be a mobile phone, tablet computer, personal computer (PC), personal digital assistant (PDA), smartwatch, netbook, wearable electronic device, augmented reality (AR) device, virtual reality (VR) device, in-vehicle device, smart screen, etc. This application does not impose any special restrictions on the specific form of the operating device.

[0096] Figure 6 A schematic diagram of the operating device 100 is shown. The operating device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, an internal memory 140, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, and a display screen 190, etc.

[0097] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the operating device 100. In other embodiments of this application, the operating device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0098] Processor 110 may include one or more processing units, such as an application processor (AP), a graphics processing unit (GPU), a controller, a baseband processor, etc. These different processing units may be independent devices or integrated into one or more processors.

[0099] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0100] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0101] In some embodiments of this application, the processor 110 includes a UI interface and data binding module, i.e., a binding tool on the running device side, used to implement two-way binding between UI controls and data in interface 1. For example... Figure 7 As shown, the binding tools on the device side can specifically include modules such as binding relationship management, data reading, data updating, interface monitoring, and interface refresh. The following will combine... Figure 7 Taking the interface 1 of the running device 100 running application A as an example, the working process of the binding tool on the running device side in the running device 100 is explained.

[0102] The binding relationship management module in running device 100 records the binding relationships between UI controls and metadata in interface 1, as well as the correspondence between metadata and data sources, derived from the metadata definition file and the interface description file of interface 1 of application A. Then, the data reading module of running device 100 reads data from running device 100 or from other devices (such as running device 200 or a server) based on the data source corresponding to the metadata. The interface refresh module of running device 100 sets the content of the corresponding UI controls in interface 1 based on the read data source content. Furthermore, the interface monitoring module of running device 100 monitors whether the UI controls in interface 1 have changed (including the displayed content of the UI controls, the state of the UI controls, and user operations on the UI controls). The data monitoring module in running device 100 also monitors whether the data bound to the UI controls in interface 1 has changed.

[0103] When a change is detected in the metadata associated with a UI control in Interface 1, the data monitoring module notifies the interface refresh module, which then refreshes the content of the corresponding UI control in Interface 1. When a change is detected in a UI control in Interface 1, the data monitoring module notifies the data update module, which then modifies the content of the data source corresponding to that UI control.

[0104] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the operating device 100. In other embodiments of this application, the operating device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0105] The wireless communication function of the operating device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. The mobile communication module 150 can provide wireless communication solutions including 2G / 3G / 4G / 5G for use on the operating device 100. The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies for use on the operating device 100. The wireless communication module 160 can be one or more devices integrating at least one communication processing module.

[0106] The running device 100 implements display functions through a GPU, a display screen 190, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 190 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0107] The display screen 190 is used to display images, videos, etc. The display screen 190 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the operating device 100 may include one or N display screens 190, where N is a positive integer greater than 1.

[0108] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the operating device 100. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0109] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge device 100, and can also be used for data transfer between device 100 and peripheral devices. It can also be used to connect headphones for audio playback.

[0110] Internal memory 140 can be used to store executable program code, including instructions. Internal memory 140 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.). The data storage area may store data created during the use of the device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 140 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of the device 100 by running instructions stored in internal memory 140 and / or instructions stored in memory located within the processor.

[0111] The operating device 100 can implement audio functions, such as music playback and recording, through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, and an application processor.

[0112] This application also provides a chip system, such as... Figure 8As shown, the chip system includes at least one processor 1101 and at least one interface circuit 1102. The processor 1101 and the interface circuit 1102 are interconnected via lines. For example, the interface circuit 1102 can be used to receive signals from other devices (e.g., memory). As another example, the interface circuit 1102 can be used to send signals to other devices (e.g., processor 1101). Exemplarily, the interface circuit 1102 can read instructions stored in memory and send those instructions to the processor 1101. When the instructions are executed by the processor 1101, the electronic device can perform the steps executed by the operating device 100 (e.g., a mobile phone) or development device in the above embodiments. Of course, the chip system may also include other discrete components, which are not specifically limited in this application embodiment.

[0113] This application also provides an apparatus included in an electronic device, which has the function of implementing or developing device behavior as described in any of the methods in the above embodiments. This function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes at least one module or unit corresponding to the above function. For example, an input module or unit, a display module or unit, an output module or unit, and a processing module or unit, etc.

[0114] This application also provides a computer storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform any of the methods described in the above embodiments.

[0115] This application also provides a computer program product that, when run on a computer, causes the computer to perform any of the methods described in the above embodiments.

[0116] It is understood that the aforementioned electronic devices, etc., include hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above-mentioned functions. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this invention.

[0117] This application embodiment can divide the above-mentioned electronic device into functional modules according to the method example described above. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0118] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0119] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0120] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for binding a UI interface to data, characterized in that, include: The device runs an installation package for a first application. The installation package includes a first interface description file and a third interface description file. The first interface description file contains the binding relationship between a first control and first metadata in the first interface, and the first metadata bound to the first control corresponds to a first data source. The third interface description file contains the binding relationship between a third control and the first metadata in the third interface of the first application, and the first metadata bound to the third control corresponds to a fourth data source. The third interface is different from the first interface, and the fourth data source may be the same as or different from the first data source. The operating device receives a first operation from the user to open the first interface. In response to the first operation, the running device displays the first control in the first interface of the first application according to the first metadata corresponding to the first data source; The operating device receives a third operation from the user to open the third interface. In response to the third operation, the running device displays the third control in the third interface of the first application based on the first metadata corresponding to the fourth data source.

2. The method according to claim 1, characterized in that, The first interface description file uses any one of the following interface description languages: Extensible Markup Language (XML), Domain-Specific Language (DSL), or Embedded Domain-Specific Language (EDSL).

3. The method according to any one of claims 1-2, characterized in that, The binding relationship between the first control and the first metadata includes: the binding relationship between the first control and one or more attributes of the first metadata; In response to the first operation, the running device displays the first control in the first interface of the first application based on the first metadata corresponding to the first data source, including: In response to the first operation, the running device displays the first control in the first interface of the first application according to one or more attributes of the first metadata corresponding to the first data source.

4. The method according to claim 3, characterized in that, The binding relationship between the first control and one or more attributes of the first metadata includes: The first control corresponds to a first operational expression, or the first control corresponds to a first function, or the first control corresponds to a first interface; Wherein, the first operational expression includes one or more attributes of the first metadata; the parameters of the first function include one or more attributes of the first metadata; and the input parameters of the first interface include one or more attributes of the first metadata.

5. The method according to any one of claims 1-4, characterized in that, In the first interface description file, the first control is also bound to one or more properties of the second metadata, and the second metadata bound to the first control corresponds to a third data source; In response to the first operation, when the running device displays the first control in the first interface of the first application, the running device displays the first control in the first interface of the first application according to the first metadata corresponding to the first data source and the second metadata corresponding to the third data source.

6. The method according to any one of claims 1-5, characterized in that, The installation package of the first application contains the definition file of the first metadata.

7. The method according to claim 6, characterized in that, The definition file for the first metadata is a JSON file.

8. The method according to claim 6 or 7, characterized in that, The definition file of the first metadata contains the format standard, name, description, data type, one or more attributes contained in the first metadata, and information about the one or more attributes.

9. The method according to any one of claims 1-8, characterized in that, In response to the first operation, after the running device displays the first control in the first interface of the first application according to the first metadata corresponding to the first data source, the method further includes: After the operating device detects that the first metadata corresponding to the first data source has changed, it displays the first control in the first interface of the first application according to the changed first metadata corresponding to the first data source; or, if it detects that the first control has changed, it updates the first metadata corresponding to the first data source according to the change of the first control.

10. The method according to claim 9, characterized in that, The first interface description file contains the binding relationship between the first control in the first interface of the first application and the first attribute of the first metadata, and the binding relationship between the fourth control in the first interface of the first application and the second attribute of the first metadata; Furthermore, the first metadata bound to the fourth control corresponds to the first data source; After the operating device detects a change in the first metadata corresponding to the first data source, it displays the first control in the first interface of the first application according to the changed first metadata corresponding to the first data source, including: When the running device detects that the first attribute of the first metadata corresponding to the first data source has changed, but the second attribute of the first metadata corresponding to the first data source has not changed, the running device refreshes the first control in the first interface of the first application according to the change of the first attribute of the first metadata corresponding to the first data source, but does not refresh the fourth control in the first interface of the first application.

11. The method according to any one of claims 1-10, characterized in that, The first interface description file also includes the binding relationship between the first metadata bound to the first control and the first data source.

12. A method for developing an application, characterized in that, include: The development device displays the first development interface of the first application; In response to receiving a first operation from a user on the first development interface, the development device generates a first interface description file. The first interface description file includes the binding relationship between a first control and first metadata in the first interface of the first application, and the first metadata bound to the first control corresponds to a first data source. The development device displays the third development interface of the first application; In response to receiving a third operation from the user on the third development interface, the development device generates a third interface description file, which includes the binding relationship between the third control and the first metadata in the third interface of the first application, and the first metadata bound to the third control corresponds to a fourth data source. The development device generates the installation package of the first application based on the first interface description file and the third interface description file.

13. The method according to claim 12, characterized in that, The binding relationship between the first control and the first metadata includes: the binding relationship between the first control and one or more attributes of the first metadata.

14. The method according to claim 13, characterized in that, The binding relationship between the first control and one or more attributes of the first metadata includes: The first control corresponds to a first operational expression, or the first control corresponds to a first function, or the first control corresponds to a first interface; Wherein, the first operational expression includes one or more attributes of the first metadata; the parameters of the first function include one or more attributes of the first metadata; and the input parameters of the first interface include one or more attributes of the first metadata.

15. The method according to any one of claims 12-14, characterized in that, In the first interface description file, the first control is also bound to one or more properties of the second metadata, and the second metadata bound to the first control corresponds to a third data source.

16. The method according to any one of claims 12-15, characterized in that, The first interface description file also includes the binding relationship between the first metadata bound to the first control and the first data source.

17. A method for binding a UI interface to data, characterized in that, include: The device runs an installation package for a first application and an installation package for a second application. The installation package for the first application includes a first interface description file, which contains the binding relationship between a first control and first metadata in the first interface of the first application, and the first metadata bound to the first control corresponds to a first data source. The installation package for the second application includes a second interface description file, which contains the binding relationship between a second control and the first metadata in the second interface of the second application, and the first metadata bound to the second control corresponds to a second data source. The operating device receives a first operation from the user to open the first interface of the first application. In response to the first operation, the running device displays the first control in the first interface of the first application according to the first metadata corresponding to the first data source; The operating device receives a second operation from the user to open the second interface of the second application. In response to the second operation, the running device displays the second control in the second interface of the second application based on the first metadata corresponding to the second data source.

18. The method according to claim 17, characterized in that, The first interface description file uses a first interface description language, and the second interface description file uses a second interface description language. The first interface description language and the second interface description language are different.

19. The method according to claim 17 or 18, characterized in that, The first interface description file uses any one of the following interface description languages: Extensible Markup Language (XML), Domain-Specific Language (DSL), or Embedded Domain-Specific Language (EDSL); the second interface description file uses any one of the following interface description languages: XML, DSL, or EDSL.

20. The method according to any one of claims 17-19, characterized in that, The binding relationship between the first control and the first metadata includes: the binding relationship between the first control and one or more attributes of the first metadata; In response to the first operation, the running device displays the first control in the first interface of the first application based on the first metadata corresponding to the first data source, including: In response to the first operation, the running device displays the first control in the first interface of the first application according to one or more attributes of the first metadata corresponding to the first data source.

21. The method according to claim 20, characterized in that, The binding relationship between the first control and one or more attributes of the first metadata includes: The first control corresponds to a first operational expression, or the first control corresponds to a first function, or the first control corresponds to a first interface; Wherein, the first operational expression includes one or more attributes of the first metadata; the parameters of the first function include one or more attributes of the first metadata; and the input parameters of the first interface include one or more attributes of the first metadata.

22. The method according to any one of claims 17-21, characterized in that, In the first interface description file, the first control is also bound to one or more properties of the second metadata, and the second metadata bound to the first control corresponds to a third data source; In response to the first operation, when the running device displays the first control in the first interface of the first application, the running device displays the first control in the first interface of the first application according to the first metadata corresponding to the first data source and the second metadata corresponding to the third data source.

23. The method according to any one of claims 17-22, characterized in that, The installation package of the first application and / or the installation package of the second application contain the definition file of the first metadata.

24. The method according to claim 23, characterized in that, The definition file of the first metadata contains the format standard, name, description, data type, one or more attributes contained in the first metadata, and information about the one or more attributes.

25. The method according to any one of claims 17-24, characterized in that, The first application installation package also includes the third interface description file, which contains the binding relationship between the third control and the first metadata in the third interface of the first application, and the first metadata bound to the third control corresponds to a fourth data source, wherein the third interface is different from the first interface, and the fourth data source is the same as or different from the first data source.

26. The method according to any one of claims 17-25, characterized in that, In response to the first operation, after the running device displays the first control in the first interface of the first application according to the first metadata corresponding to the first data source, the method further includes: After the operating device detects that the first metadata corresponding to the first data source has changed, it displays the first control in the first interface of the first application according to the changed first metadata corresponding to the first data source; or, if it detects that the first control has changed, it updates the first metadata corresponding to the first data source according to the change of the first control.

27. The method according to claim 26, characterized in that, The first interface description file contains the binding relationship between the first control in the first interface of the first application and the first attribute of the first metadata, and the binding relationship between the fourth control in the first interface of the first application and the second attribute of the first metadata; Furthermore, the first metadata bound to the fourth control corresponds to the first data source; After the operating device detects a change in the first metadata corresponding to the first data source, it displays the first control in the first interface of the first application according to the changed first metadata corresponding to the first data source, including: When the running device detects that the first attribute of the first metadata corresponding to the first data source has changed, but the second attribute of the first metadata corresponding to the first data source has not changed, the running device refreshes the first control in the first interface of the first application according to the change of the first attribute of the first metadata corresponding to the first data source, but does not refresh the fourth control in the first interface of the first application.

28. The method according to any one of claims 17-27, characterized in that, The first interface description file also includes the binding relationship between the first metadata bound to the first control and the first data source.

29. A method for developing an application, characterized in that, include: The development device displays the first development interface of the first application; In response to receiving a first operation from a user on the first development interface, the development device generates a first interface description file. The first interface description file includes the binding relationship between a first control and first metadata in the first interface of the first application, and the first metadata bound to the first control corresponds to a first data source. The development equipment generates the installation package of the first application based on the first interface description file; The development device displays the second development interface for the second application; In response to receiving a second operation from the user on the second development interface, the development device generates a second interface description file. The second interface description file includes the binding relationship between the second control and the first metadata in the second interface of the second application, and the first metadata bound to the second control corresponds to a second data source. The development equipment generates the installation package of the second application based on the second interface description file.

30. The method according to claim 29, characterized in that, The binding relationship between the first control and the first metadata includes: the binding relationship between the first control and one or more attributes of the first metadata.

31. The method according to claim 30, characterized in that, The binding relationship between the first control and one or more attributes of the first metadata includes: The first control corresponds to a first operational expression, or the first control corresponds to a first function, or the first control corresponds to a first interface; Wherein, the first operational expression includes one or more attributes of the first metadata; the parameters of the first function include one or more attributes of the first metadata; and the input parameters of the first interface include one or more attributes of the first metadata.

32. The method according to any one of claims 29-31, characterized in that, In the first interface description file, the first control is also bound to one or more properties of the second metadata, and the second metadata bound to the first control corresponds to a third data source.

33. The method according to any one of claims 29-32, characterized in that, The first interface description file also includes the binding relationship between the first metadata bound to the first control and the first data source.

34. An operating device, characterized in that, include: A processor, a memory, and a display screen, wherein the memory and the display screen are coupled to the processor, the memory being used to store computer program code, the computer program code including computer instructions, wherein when the processor reads the computer instructions from the memory, the operating device performs a UI interface and data binding method as described in any one of claims 1-11, or performs a UI interface and data binding method as described in any one of claims 17-28.

35. A development device, characterized in that, include: A processor, a memory, and a display screen, wherein the memory and the display screen are coupled to the processor, the memory being used to store computer program code, the computer program code including computer instructions, wherein when the processor reads the computer instructions from the memory, the development device performs the development method of the application as described in any one of claims 12-16, or performs the development method of the application as described in any one of claims 29-33.

36. A computer-readable storage medium, characterized in that, The method includes computer instructions that, when executed on an electronic device, cause the electronic device to perform a method for binding a UI interface to data as described in any one of claims 1-11, or a method for binding a UI interface to data as described in any one of claims 17-28, or a method for developing an application as described in any one of claims 12-16, or a method for developing an application as described in any one of claims 29-33.

Images