Interface generation method and electronic equipment
By generating interface description data and preset bridging interfaces, the slow response and complex operation of traditional interface generation methods are solved, enabling fast and automated interface rendering and device function synchronization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GREAT WALL MOTOR CO LTD
- Filing Date
- 2026-01-19
- Publication Date
- 2026-04-21
AI Technical Summary
Traditional interface generation methods struggle to achieve millisecond-level response times, are complex to operate, and cannot directly control the target device's functions, requiring manual data binding processing.
By acquiring function control commands to generate interface description data, determining interface components, and injecting preset bridging interfaces, the system can directly obtain target device function data, bind template variables in component data, and achieve automated bridging and dynamic rendering of interface components.
It achieves millisecond-level response time, reduces the complexity of interface generation, improves efficiency, and supports real-time interface updates and synchronization of target device functional status.
Smart Images

Figure CN121900759A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of intelligent control technology, and in particular to an interface generation method and an electronic device. Background Technology
[0002] With the development of intelligent control technology, the functional coverage of intelligent control scenarios such as smart cockpits and smart homes has been significantly expanded. Taking the smart cockpit scenario as an example, when a user intends to control the vehicle's functions, the artificial intelligence (AI) assistant needs to generate an interface for controlling the vehicle's functions in real time on interactive carriers such as in-vehicle display terminals, mobile phones, or tablets, based on the user's voice intent, such as a user interface (UI), to provide the user with an intuitive and convenient human-computer interaction entry point.
[0003] Traditional interface generation methods require code compilation and deployment, making it difficult to achieve millisecond-level response times. Moreover, traditional interface generation methods cannot directly operate the corresponding functions of the target device, requiring complex operations to achieve this, and data binding also requires manual processing by technical personnel. Summary of the Invention
[0004] This application provides an interface generation method and an electronic device to solve the technical problems in related technologies where interface generation is difficult to meet millisecond-level response and is complex to operate.
[0005] In a first aspect, embodiments of this application provide an interface generation method, including: Obtain function control instructions, and obtain interface description data based on the function control instructions; Based on the interface description data, component data is obtained, and corresponding interface components are determined according to the component data; wherein, the interface components include basic components, layout components and functional components; the functional components are injected with preset bridging interfaces for bridging with the functional interfaces of the target device; The function data of the target device is obtained through the preset bridging interface, and the function data is bound to the template variable in the corresponding component data of the interface component so that the interface component can be updated. Based on the updated interface components, generate and display the target interface.
[0006] Based on the above technical content, this application embodiment obtains interface description data according to the acquired function control instructions. This interface description data describes the interface architecture and constraint specifications of the interface to be generated. Subsequently, based on the interface description data, the corresponding interface components can be determined. That is, component data is obtained from the interface description data, and basic components, layout components, and functional components are determined based on the component data. This eliminates the compilation and deployment process in code generation methods, reduces response time, enables true dynamic rendering, and improves interface generation efficiency. When creating functional components, a preset bridging interface is injected to achieve automatic bridging between the functional components and the target device's functional interface, eliminating the need for complex operations. Furthermore, the functional data of the target device obtained through the preset bridging interface is bound to the template variables in the corresponding component data of the interface component, avoiding extensive manual coding and allowing the interface component to update its own attributes based on the bound functional data. This allows the target interface to be generated and visualized based on the updated interface component, achieving synchronization between interface rendering and the corresponding functional state of the target device. This enables users to perceive the target device's operating status in real time through the visualized target interface and provides reliable data support for subsequent precise control of the target device's functions.
[0007] In one possible implementation, obtaining component data based on the interface description data and determining the corresponding interface components based on the component data includes: The interface description data is parsed to determine the corresponding card; Based on the card, component data is obtained; wherein, the component data includes component type identifier, component attribute description, component hierarchy, as well as template variables, data source and interaction behavior description; Based on the component data, create corresponding basic components, layout components, and functional components.
[0008] In this embodiment of the application, based on the interface description data, the corresponding cards and corresponding card strategies can be determined, and then the component data can be obtained, providing a reliable foundation for the creation of components as underlying elements, thereby realizing the accurate mapping from interface requirements to standardized components and the implementation from abstract requirements to specific components.
[0009] In one possible implementation, the step of creating corresponding basic components, layout components, and functional components based on the component data includes: Using a first preset processor, determine the component implementation class corresponding to the component type identifier in the component data; Based on the component implementation class, corresponding basic components, layout components, and functional components are created; wherein, the first preset processor is used to create corresponding basic components, layout components, and functional components based on the component type identifier; the component implementation class is constructed based on pre-set standardized and unified constraints.
[0010] Here, the first preset processor, based on the component type identifier, can accurately match the corresponding component implementation class, thus ensuring the accuracy of component creation. Furthermore, the component implementation classes have a unified specification, allowing for unified management of both component implementation classes and UI components using the first preset processor, reducing management complexity.
[0011] In one possible implementation, a first preset processor is used to create corresponding basic components, layout components, and functional components based on the component implementation class, including: Using a first preset processor, the basic component is created based on the corresponding component implementation class and component attribute description. For the aforementioned layout component, the layout component is created based on the corresponding component implementation class, component attribute description, and component hierarchy. For the aforementioned functional component, the functional component is created based on the corresponding component implementation class, component attribute description, and injected preset bridging interface.
[0012] Specifically, the system utilizes a first preset processor to create differentiated basic components, layout components, and functional components, adapting to the unique characteristics of each component to ensure accurate functional implementation and avoid functional redundancy or omissions caused by a one-size-fits-all approach. Preset bridging interfaces are injected during the creation of functional components to achieve automated bridging between functional components and the functional interfaces of target devices. These preset bridging interfaces are compatible with heterogeneous target device functional interfaces, eliminating the need to write separate code for each target device function. Furthermore, the first preset processor enables unified management of interface components, reducing management complexity and improving maintenance efficiency.
[0013] In one possible implementation, obtaining the functional data of the target device through the preset bridging interface includes: Determine whether there is a data source in the component data of the basic components, layout components, and functional components; If a data source is available, the data from the data source is obtained using the preset bridging interface of the functional component as functional data.
[0014] In this embodiment, the functional data of the target device's functional interface is obtained only when a data source is detected in the component data, using the preset bridging interface of the functional component. This avoids meaningless empty requests or redundant data loading. Furthermore, the preset bridging interface adapts to heterogeneous target device functional interfaces, and functional data is obtained using the preset bridging interface for all components, eliminating the need to design differentiated data acquisition logic for different components.
[0015] In one possible implementation, the component data of the basic component, layout component, and functional component includes target key-value pairs, which are key-value pairs of text display identifier and corresponding template variable; The step of binding the functional data with the template variable in the corresponding component data of the interface component to update the interface component includes: Determine the target key-value pairs for the corresponding component data of the basic components, layout components, and functional components; Based on the text display identifier, using the second preset processor, the functional data is bound to the template variables in the target key-value pairs of the corresponding component data of the basic component, layout component, and functional component, so that the basic component, layout component, and functional component are updated according to the corresponding component data bound to the functional data; The template variable is to be replaced by the corresponding functional data.
[0016] Here, through a second preset processor such as the Pebble template engine, the automatic binding and replacement of template variables and functional data in component data is realized, with high binding precision and accuracy.
[0017] In one possible implementation, after generating and displaying the target interface, the following is also included: Monitor data changes in the data source so that the interface components can update again based on the monitored data changes; Based on the updated interface components, update the target interface and display it.
[0018] In this embodiment, by registering a data change listener, unified listening to multiple data sources is supported, enabling real-time and accurate monitoring of data source changes. This ensures that data changes are synchronized with the interface display, achieving real-time automatic refresh of the interface without the need for manual update code, thus improving data update efficiency.
[0019] In one possible implementation, the function control instructions include vehicle infotainment function control instructions; The step of obtaining interface description data according to the function control instructions includes: Based on the vehicle infotainment system function control commands, determine the corresponding control intent; Based on the control intent, the corresponding interface architecture and constraint specifications are obtained from the preset knowledge base; wherein, the knowledge base stores the interface architecture and constraint specifications in preset formats corresponding to different control intents; Based on the corresponding interface architecture and constraint specifications, generate interface description data in a preset format.
[0020] Here, based on functional control instructions and a preset knowledge base, interface description data in a preset format is automatically generated to describe the interface architecture and constraint specifications of the interface to be generated. Subsequently, based on the interface description data, the corresponding interface components can be determined to achieve accurate mapping from interface requirements to standardized components and from abstract requirements to concrete components. At the same time, it also improves the matching accuracy between interface description data and functional control instructions and realizes personalized display.
[0021] In one possible implementation, after generating and displaying the target interface based on the updated interface components, the method further includes: Detect whether there is a target device control operation on the target interface; If the target device control operation is detected on the target interface, the corresponding functional logic corresponding to the target device control operation is executed using the corresponding interactive behavior description.
[0022] Here, when a target device control operation is detected on the target interface, the corresponding functional logic can be automatically executed based on the target interface, and the functional data of the target device after the operation is executed can be updated and displayed synchronously, improving the user interaction experience. Furthermore, by performing verifications such as parameter range verification and operation step size limit verification, functional or safety malfunctions of the target device caused by misoperation can be effectively avoided, improving the safety and reliability of the target device operation.
[0023] Secondly, embodiments of this application provide an interface generation apparatus, comprising: The acquisition module is used to acquire function control instructions and obtain interface description data based on the function control instructions.
[0024] The determination module is used to obtain component data based on the interface description data, and determine the corresponding interface component according to the component data; wherein, the interface component includes basic components, layout components and functional components; the functional component is injected with a preset bridging interface for bridging with the functional interface of the target device.
[0025] The binding module is used to obtain the functional data of the target device through the preset bridging interface, and bind the functional data with the template variables in the corresponding component data of the interface component so that the interface component can be updated.
[0026] The generation module is used to generate and display the target interface based on the updated interface components.
[0027] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor. The memory stores a computer program that can run on the processor, and when the processor executes the computer program, it implements the interface generation method as described in any of the first aspects.
[0028] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the interface generation method as described in any of the first aspects.
[0029] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.
[0030] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description
[0031] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0032] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 This is a flowchart illustrating an embodiment of the interface generation method provided in this application; Figure 3 This is a flowchart illustrating an interface generation method provided in another embodiment of this application; Figure 4 This is a schematic diagram of the structure of an interface generation apparatus provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0033] The present application will be described more clearly below with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the function of the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.
[0034] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.
[0035] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0036] In the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0037] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0038] Furthermore, the term "multiple" mentioned in the embodiments of this application should be interpreted as two or more.
[0039] First, the terms used in the embodiments of this application will be explained: AI-Generated UI Protocol: A protocol that describes the structure and attributes of a UI interface using a preset format such as JSON. The AI system directly generates JSON data that conforms to this protocol, which is then parsed locally to render a complete UI interface. This protocol defines the standard format for AI-generated UI interfaces, including elements such as component types, attributes, layout, data binding, and interactive events.
[0040] With the development of intelligent control technology, the boundaries of human-computer interaction scenarios are constantly expanding. AI systems, based on user voice intent, instantly generate interfaces (UI interfaces) on interactive platforms such as mobile phones or tablets to control the corresponding functions of target devices, providing users with an intuitive and convenient human-computer interaction entry point. For example, in a smart cockpit scenario, the AI system instantly generates a UI interface for controlling vehicle functions based on user voice intent; in a smart home scenario, the AI system instantly generates a UI interface for controlling air conditioning and curtains based on user voice intent.
[0041] However, traditional interface generation methods typically employ code generation, where an AI system generates source code in languages such as Java or Kotlin, which is then compiled to display the interface. This results in long response times, making it difficult to achieve millisecond-level response times. Furthermore, the code generation method cannot directly manipulate the corresponding functions of the target device; it requires complex interface calls and access control, leading to high integration costs. Binding functional data to the target device also necessitates manual processing by technical personnel.
[0042] Based on the above problems, the inventors considered that if interface description data about the interface to be generated could be directly generated, and the corresponding interface components could be directly determined based on this interface description data, and then the interface components could be rendered to generate the corresponding interface, the compilation and deployment process would be eliminated, and the response time could be reduced to milliseconds. Furthermore, when creating interface components, if a preset bridging interface for bridging with the target device's functional interface is directly injected, automated bridging between the interface components and the target device's functional interface can be achieved. Then, based on the preset bridging interface, the target device's functional data can be obtained, and the functional data can be bound to the component data.
[0043] In other words, in the embodiments of this application, interface description data is obtained based on the acquired functional control instructions. This interface description data describes the interface architecture and constraint specifications of the interface to be generated. Subsequently, based on the interface description data, the corresponding interface components can be determined. That is, component data is obtained from the interface description data, and basic components, layout components, and functional components are determined based on the component data. This eliminates the compilation and deployment process in code generation methods, reduces response time, enables true dynamic rendering, and improves interface generation efficiency. When creating functional components, a preset bridging interface is injected to achieve automatic bridging between the functional components and the target device's functional interface, eliminating the need for complex operations. Furthermore, the functional data of the target device obtained through the preset bridging interface is bound to the template variables in the corresponding component data of the interface component, avoiding extensive manual coding and allowing the interface component to update its own attributes based on the bound functional data. This allows the target interface to be generated and visualized based on the updated interface component, achieving synchronization between interface rendering and the corresponding functional state of the target device. This enables users to perceive the target device's operating status in real time through the visualized target interface and provides reliable data support for subsequent precise control of the target device's functions.
[0044] First refer to Figure 1 , Figure 1 The illustration shows an application scenario diagram provided according to an embodiment of this application, which involves an interface description data generation layer, a rendering engine layer, a component generation layer, and a target device function layer.
[0045] The interface description data generation layer generates interface description data based on function control instructions. The component generation layer obtains component data based on the interface description data, and then obtains interface components including basic components, layout components, and functional components. At the same time, the functional components are injected with preset bridging interfaces for bridging with the target device function interface of the target device function layer. Through the preset bridging interfaces, the functional data in the target device function layer can be obtained. Then, the rendering engine layer binds the functional data with the template variables in the corresponding component data of the interface components, so that the interface components are updated. Based on the updated interface components, the target interface is generated and displayed.
[0046] The following is combined with Figure 1 Application scenarios, refer to Figures 2-4 This application describes an interface generation method provided according to exemplary embodiments. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way. Rather, the embodiments of this application can be applied to any applicable scenario.
[0047] Optionally, the embodiments of this application can be applied to electronic devices, such as mobile phones, computers, tablets, controllers, etc. In different intelligent control scenarios, the embodiments of this application can be executed by different electronic devices. For example, in an intelligent cockpit scenario, the embodiments of this application can be applied to a controller, which can be an in-vehicle controller, an external controller, or a combination of both. It is a hardware device with data storage, processing, and analysis functions. Here, taking an in-vehicle controller as an example, it can be a cockpit controller (CC), etc.
[0048] In smart home scenarios, the implementation methods of this application can be applied to smart terminals such as mobile phones and tablets.
[0049] refer to Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the interface generation method provided in this application. Figure 2 As shown, the method in the embodiments of this application may include: Step 201: Obtain function control instructions and, based on the function control instructions, obtain interface description data.
[0050] Optionally, function control commands can be triggered by the user. For example, function control commands can be voice commands issued by the user. In a smart cockpit scenario, voice commands can be to turn on the air conditioning comfort mode or adjust the driver's seat. In a smart home scenario, voice commands can be to adjust the air conditioning temperature or open the curtains.
[0051] Based on function control commands, the system identifies the user's control intent and then generates interface description data in a preset format according to that intent. Here, the interface description data describes the interface architecture and constraint rules of the interface to be generated; essentially, it's a collection of descriptive information used to generate the interface. Based on this data, corresponding interface components can be obtained. In this embodiment, a UI interface is used as an example. The interface description data specifically describes the interface structure, functions, and constraint rules of the UI interface to be generated, and the preset format can be JSON.
[0052] Subsequently, based on the interface description data, the corresponding interface components are determined. These interface components meet the requirements of the interface description data for the interface to be generated, so as to achieve accurate mapping from interface requirements to standardized components and from abstract requirements to concrete components.
[0053] Here, the default format is chosen as JSON because JSON uses a minimalist structure of key-value pairs and arrays. Its syntax is lightweight, easy to parse, and free of redundant syntax. It also supports nested hierarchical structures, which can accurately map the hierarchical relationship of the UI interface and has strong extensibility.
[0054] Step 202: Based on the interface description data, obtain the component data, and determine the corresponding interface components according to the component data; wherein, the interface components include basic components, layout components and functional components; the functional components are injected with preset bridging interfaces for bridging with the functional interfaces of the target device.
[0055] Here, basic components provide fundamental and general visualization and simple interactive capabilities. Layout components control the arrangement, spacing, and alignment of components. Functional components interface with the target device's functions and are dedicated components tailored to the target device's business scenarios. The target device is the object to be controlled; for example, in a smart home scenario, the target device could be a smart air conditioner.
[0056] For example, the interface description data is parsed and transformed to obtain component data (ComponentData). Component data can include a component type identifier, which indicates the type of the component. This identifier can be represented by a viewName field combined with key-value pairs, such as "viewName": "AtomicComponent," indicating that the component type is a functional component. Thus, based on the component type identifier, the corresponding standardized component implementation class can be determined from a pre-set component library, and the corresponding interface component can be created, achieving a precise mapping from interface requirements to standardized components.
[0057] It should be noted that in this embodiment, creating, determining, or obtaining an interface component actually means creating, determining, or obtaining an instance of an interface component. In this embodiment, it is abbreviated as creating, determining, or obtaining an interface component.
[0058] Furthermore, when creating functional components, a preset bridging interface IAtomicProvider is injected into the functional components, enabling the interface components to automatically bridge with the target device's functional interface based on the preset bridging interface. Here, the target device functional interface refers to the target device's application programming interface (API), and the preset bridging interface refers to the preset bridging API.
[0059] Step 203: Obtain the functional data of the target device through the preset bridging interface, and bind the functional data with the template variables in the corresponding component data of the interface component so that the interface component can be updated.
[0060] The interface to be generated needs to display the functional data of the target device. The aforementioned functional data refers to the real-time status data of the target device, such as the current backrest angle of the driver's seat and the window height in a smart cockpit scenario, and the temperature of the air conditioner in a smart home scenario.
[0061] Therefore, this embodiment obtains functional data from the target device's functional interface based on a preset bridging interface, such as seat back angle and air conditioning temperature.
[0062] Correspondingly, component data can also include template variables and data sources. Template variables are placeholders enclosed in {{}} in the Pebble template, indicating the positions in the component data that need to be dynamically filled, and also indicating the reference path of the functional data to be bound. That is, template variables are to be replaced by the corresponding functional data and updated as the functional data changes, rather than being fixed constants. For example, Pebble template syntax can be used to represent this, such as "text": "{{data[0].title}}" which means that the text display is bound to the title field of the first element of the corresponding data source array, where {{data[0].title}} is the template variable, data[0].title is the reference path of the template variable, and {{}} is the syntax markup of the Pebble template, indicating that a dynamic variable should be filled here, used to distinguish between static text and the dynamic content to be filled.
[0063] The data source indicates the origin of the functional data, such as the package name of the target device's functional module and the specific data interface name under that functional module. For example, it can be represented by the bind field combined with key-value pairs, such as "bind": "packageName / interfaceName" which represents the package name and data interface name of the data source.
[0064] Once the functional component is created, based on the data source, functional data can be obtained from the target device's functional interface through the functional component's preset bridging interface. Then, the Pebble template engine binds the functional data to the template variables in the corresponding component data of the interface component. In other words, the functional data is filled into the template variables in the corresponding component data to obtain the component data with bound functional data, so that the interface component can update its own attributes according to the corresponding component data with bound functional data.
[0065] It's important to note that for each component in the UI, only components with template variables in their corresponding component data will update their own properties based on the bound functional data. If a component's data does not contain template variables, then that component does not need to be updated.
[0066] Step 204: Based on the updated interface components, generate and display the target interface.
[0067] The rendering process updates the components' own properties, generating the target interface for visualization. The target interface displays the current functional data of the target device, allowing for interaction and control operations. Users can then intuitively perceive the real-time operating status of the target device and achieve intelligent control.
[0068] Of course, it is understandable that if there are UI components that do not need to be updated, then the updated UI components and the UI components that do not need to be updated will be rendered to generate and display the target UI.
[0069] In some embodiments, after the target interface is visualized, the user can interact with it and trigger corresponding target device control operations, such as clicking the button to adjust the driver's seat back angle in a smart cockpit scenario. In this embodiment, after detecting the target device control operation, the corresponding functional logic is executed to control the target device. Furthermore, after the target device control is completed, functional data can be acquired to update and display the target interface.
[0070] The interface generation method provided in this application obtains interface description data based on the acquired function control instructions. This interface description data describes the interface architecture and constraint specifications of the interface to be generated. Subsequently, based on the interface description data, corresponding interface components can be determined. That is, component data is obtained from the interface description data, and basic components, layout components, and functional components are determined based on the component data. This eliminates the compilation and deployment process in code generation methods, reduces response time, enables true dynamic rendering, and improves interface generation efficiency. When creating functional components, a preset bridging interface is injected to achieve automatic bridging between the functional components and the target device's functional interface, eliminating the need for complex operations. Furthermore, the functional data of the target device obtained through the preset bridging interface is bound to the template variables in the corresponding component data of the interface component, avoiding extensive manual coding and allowing the interface component to update its own attributes based on the bound functional data. This allows the target interface to be generated and visualized based on the updated interface component, achieving synchronization between interface rendering and the corresponding functional state of the target device. This enables users to perceive the target device's operating status in real time through the visualized target interface and provides reliable data support for subsequent precise control of the target device's functions.
[0071] In addition, in generating and displaying the target interface, this application embodiment also considers how to further create interface components, update the interface display content, and execute functional logic corresponding to the target device control operation, so as to realize the target device control.
[0072] Figure 3 This is a flowchart illustrating an interface generation method provided in another embodiment of this application, such as... Figure 3 As shown, the method includes: Step 301: Obtain function control instructions, determine the corresponding control intent based on the function control instructions, obtain the corresponding interface architecture and constraint specifications from the preset knowledge base based on the control intent, and generate interface description data in a preset format based on the corresponding interface architecture and constraint specifications.
[0073] The pre-defined knowledge base stores interface architectures and constraint specifications in preset formats corresponding to different control intentions, and the knowledge base follows the AI-generated UI interface protocol. The interface architecture includes the device interface structure and functions, while the constraint rules include field descriptions and preset constraints. Field descriptions are explanatory descriptions of fields, including but not limited to the meaning and purpose of each field. Pre-defined constraints include constraints on specific component attributes and field format constraints.
[0074] Component attribute constraints include those on component size, layout, text style, and nesting level. For example, regarding component size, constraints might include ensuring the component's height / width fills the parent container, adapting its height / width to the content, or using a fixed height / width. For layout, constraints might limit elements to horizontal and / or vertical arrangement to avoid complex layouts that increase rendering load and reduce error probability. For text style, constraints might include large, medium, and small font sizes to prevent arbitrary customization and ensure visual consistency. For nesting level, or the component hierarchy, constraints might limit nesting depth to no more than four levels to avoid rendering blockage.
[0075] Field format constraints, such as the bind field uniformly adopting the format of packageName / interfaceName (the package name / data interface name of the data source), and other field format constraints, will not be listed here.
[0076] Optionally, an AI system can determine the user's control intent based on the function control commands issued by the user, and automatically query and determine the corresponding target device function in the knowledge base based on the control intent. Then, based on the target device function, the corresponding interface architecture and constraint specifications can be determined. The AI system automatically generates corresponding JSON format interface description data based on the corresponding interface architecture and constraint specifications. The interface description data includes descriptions of the corresponding cards and components.
[0077] Here, taking the smart cockpit scenario as an example, function control commands include vehicle infotainment system function control commands. The corresponding control intent can be determined based on these commands. Target device functions include air conditioning control, seat adjustment, and window control.
[0078] As mentioned earlier, the default format is JSON because JSON uses a minimalist structure of key-value pairs and arrays. Its syntax is lightweight, easy to parse, and free of redundant syntax. It also supports nested hierarchical structures, which can accurately map the hierarchical relationship of the UI interface and has strong extensibility.
[0079] In this embodiment, based on function control instructions and a preset knowledge base, interface description data in a preset format is automatically generated to describe the interface architecture and constraint specifications of the interface to be generated. Subsequently, based on the interface description data, the corresponding interface components can be determined to achieve accurate mapping from interface requirements to standardized components and from abstract requirements to concrete components. At the same time, it also improves the matching accuracy between interface description data and function control instructions and realizes personalized display.
[0080] For details on the implementation and principles of step 301, please refer to [link to relevant documentation]. Figure 2 The relevant descriptions in the embodiments will not be repeated here.
[0081] Step 302: Parse the interface description data, determine the corresponding cards, and obtain component data based on the cards. Based on the component data, create the corresponding basic components, layout components, and functional components.
[0082] The card serves as the top-level business container that carries the interface architecture and components. Component data includes component type identifiers, component attribute descriptions, component hierarchy, as well as template variables, data sources, and interaction behavior descriptions.
[0083] The interface description data is parsed, converting JSON data into CardData. This transforms loosely structured, unstructured JSON text into strongly typed, structured data objects that the program can directly recognize and manipulate. CardData includes card type identifiers, indicating the card's type, for example, through a `type` field. Card types include layout cards such as flexbox, list, and matrix layout containers, as well as carrier cards such as web (H5 webpage carrier) and appwidget (native control hosting container).
[0084] Cards serve as containers for components that form the underlying elements, and each card type corresponds to an independent card strategy. Based on the card type identifier, a third preset processor, such as the CardStrategyFactory, selects the corresponding card strategy from a preset strategy mapping table. It's important to note that the card strategy here is a strategy instance. The third preset processor is used to determine the corresponding card strategy based on the card type identifier.
[0085] In some embodiments, card strategies have a unified specification, such as defining the CardCreatorStrategy interface as a unified specification for the creation of all card strategies. This interface includes the createCard() method for creating a card strategy and the getSupportedType() method for declaring the card type identifier corresponding to the current card strategy. This interface is responsible for the layout breakdown, data splitting, and component assembly of the entire card, essentially acting as a higher-level orchestration layer for the component layer.
[0086] In each card strategy implementation, card data is decomposed and converted into component data. This is because card strategies deal with card-level data structures, while components need to conform to the tree input of the component view factory. Based on the obtained component data, corresponding UI components can then be created. For example, in the implementation of the free layout strategy, we will get "viewName": "FlexboxLayoutComponent", and the card-level hierarchy will be converted into a component-level component hierarchy, such as converting it into specific button / text component descriptions.
[0087] Furthermore, when adding a new card type, simply implement the CardCreatorStrategy interface and register it accordingly. If the new card involves a special execution method, you can override the createCard() method in the corresponding card strategy and call the corresponding additional special function service / utility class service.
[0088] In this embodiment, based on the interface description data, the corresponding cards and corresponding card strategies can be determined, and then the component data can be obtained, providing a reliable foundation for the creation of components as underlying elements, thereby realizing the accurate mapping from interface requirements to standardized components and the implementation from abstract requirements to specific components.
[0089] In some embodiments, when creating the corresponding basic components, layout components and functional components, a first preset processor can be used to determine the component implementation class corresponding to the component type identifier in the component data, and based on the component implementation class, the corresponding basic components, layout components and functional components can be created.
[0090] The first preset processor is used to create corresponding basic components, layout components, and functional components based on component type identifiers, such as a component view factory (ComponentViewFactory). Component implementation classes are built based on pre-set standardized and unified constraints. Basic components include button components (ButtonComponent), text view components (TextViewComponent), etc., and layout components include custom layout components (FlexboxLayoutComponent), etc.
[0091] For each component, based on the corresponding component type identifier such as the viewName field, the first preset processor determines the standardized component implementation class of the corresponding component type from the pre-set component library. Specifically, the first preset processor can be used to search the registry in the component library for the registered component implementation classes, thereby determining the component implementation class of the corresponding component type.
[0092] Furthermore, based on the determined component implementation class, the corresponding component is created using the first preset processor. It should be noted that different component types are created differently. In addition, when the first preset processor detects a component type not registered in the registry, it automatically replaces the corresponding component with a generic placeholder component (FallbackComponent) and logs the change. This ensures no system crashes, normal UI display, and supports subsequent controllable expansion of component types based on the logs.
[0093] In some embodiments, component implementation classes are built based on pre-set standardized and unified constraints, that is, component implementation classes have a unified specification, such as defining the IComponent interface as a unified specification for the creation of all component implementation classes, that is, all component implementation classes need to implement this interface.
[0094] Under standardized and unified constraints, all component implementation classes must implement the `create()`, `bind()`, and `getSupportedType()` methods defined in the `IComponent` interface. The `create()` method takes three parameters: the context (e.g., the Android context environment), component data (e.g., component attribute descriptions), and parent container parameters (e.g., a free-layout container), and is used to transform the component into a renderable and displayable actual view. The `bind()` method completes data and event binding after the view is rendered. The `getSupportedType()` method must return its corresponding component type identifier to match the component type identifier in the component data. Furthermore, component implementation classes access configuration data abstracted from the UI description data through the component data.
[0095] In addition, component implementation classes adhere to lifecycle constraints, implementing the `attach()` and `detach()` methods. The former is used to initialize resources and bind dependencies when the component is attached to the parent container / UI, while the latter is used to release resources and remove dependencies when the component is unattached and detached from the parent container / UI. If a component implementation class requires additional dependent services (such as animations, networks, etc.), it needs to implement the `requiredServices()` method, which returns a unique identifier for the additional services required by the component implementation class.
[0096] In this way, all component implementation classes implement the IComponent interface, which has a unified specification, reduces redundant development, and enables unified management of component implementation classes.
[0097] In this embodiment, the first preset processor can accurately match the corresponding component implementation class based on the component type identifier, thereby ensuring the accuracy of component creation. Furthermore, the component implementation classes have a unified specification, and the first preset processor can subsequently be used to achieve unified management of component implementation classes and UI components, reducing management complexity.
[0098] Optionally, the component data also includes component property descriptions and a component hierarchy. Component property descriptions indicate all the properties of the component, including size, style, and layout parameters, and can be represented, for example, through a `props` field. The component hierarchy describes the nesting relationship of components, forming a tree structure, and can be represented, for example, through a `children` array.
[0099] In some embodiments, when creating components of different component types in a differentiated manner, a first preset processor is used to create a basic component based on the component implementation class and component attribute description corresponding to the basic component, to create a layout component based on the component implementation class, component attribute description and component hierarchy corresponding to the layout component, and to create a functional component based on the component implementation class and component attribute description corresponding to the functional component, as well as the injected preset bridging interface.
[0100] For each basic component, the corresponding component attribute description is determined. Using the first preset processor, the component implementation class corresponding to the basic component is instantiated, and the corresponding component attributes are configured to complete the creation of the basic component. For each layout component, the corresponding component attribute description and component hierarchy are determined. Using the first preset processor, the component implementation class corresponding to the layout component is instantiated, and the corresponding component attributes are configured. It is also necessary to traverse the component hierarchy to create related sub-components to complete the creation of the layout component.
[0101] Functional components are specifically designed to integrate atomic components, such as integrating cockpit functions like window control or seat adjustment in a smart cockpit scenario, or integrating curtain control functions in a smart home scenario, to subsequently achieve visual interaction and rapid response of the target device's functions.
[0102] For each functional component, the first preset processor injects the AtomicManager and the preset bridge interface IAtomicProvider. It then automatically searches for the data source, atomic component class name, and atomic component type in the corresponding component property description to execute the loading of the corresponding atomic component. For example, the data source is represented by the `bind` field, and the atomic component class name is represented by `uiClassName`, indicating the fully qualified class name of the atomic component (i.e., the complete path + class name). The AtomicManager uses this fully qualified class name to find and load the corresponding implementation class of the atomic component through reflection. The atomic component type indicates the presentation container of the atomic component, such as a standard Card, a ViewHost embedded in other layouts, or a Dialog.
[0103] The pre-defined bridging interface is used to automate the bridging between functional components and target device functional interfaces. It exposes methods such as `attachSession(sessionId)` and `funcCall(funcName, params)`. The former binds the communication session ID, allowing the target device functional interface to know which component is issuing the command, avoiding command confusion. The latter is used to pass in the name of the target device function to be executed (e.g., adjusting the angle of a vehicle seat back) and parameters (e.g., the specific angle of the seat back). Furthermore, the pre-defined bridging interface is only injected into the functional component when it needs to interact with the target device functional interface, reducing resource consumption. Additionally, the pre-defined bridging interface adapts to heterogeneous target device functional interfaces because functional components only need to call the `funcCall()` method in a uniform manner, and the pre-defined bridging interface can convert the command into a format recognizable by the corresponding target device functional interface.
[0104] In this embodiment, a first preset processor is used to create differentiated basic components, layout components, and functional components, adapting to the unique characteristics of each component to ensure accurate functional implementation and avoid functional redundancy or omissions caused by a one-size-fits-all approach. A preset bridging interface is injected when creating functional components to achieve automated bridging between functional components and the functional interfaces of target devices. Furthermore, the preset bridging interface adapts to heterogeneous target device functional interfaces, eliminating the need to write separate code for each target device function. In addition, the first preset processor enables unified management of interface components, reducing management complexity and improving maintenance efficiency.
[0105] Step 303: Obtain the functional data of the target device through the preset bridging interface, and bind the functional data with the template variables in the corresponding component data of the interface component so that the interface component can be updated.
[0106] In some embodiments, when obtaining functional data through a preset bridging interface, it can be determined whether there is a data source in the corresponding component data of the basic component, layout component, and functional component. If there is a data source, the preset bridging interface of the functional component can be used to obtain the data from the data source as functional data.
[0107] After creating the UI component, check if the component data contains a data source, such as a `bind` field. If a `bind` field is present, request data based on the data source indicated by the `bind` field using the AtomicManager and create a dedicated communication session (AISession). This communication session serves as the sole session for this data request, corresponding to a unique session identifier (`sessionId`), thus avoiding confusion from multiple requests. The communication session also manages the lifecycle of the data source and data change notifications. The AtomicManager binds the communication session to a preset bridge interface. The preset bridge interface, `IAtomicProvider`, retrieves data from the corresponding target device's functional interface as functional data and passes this data to the dedicated data carrier associated with the communication session.
[0108] In this embodiment, the functional data of the target device's functional interface is obtained only when a data source, such as a `bind` field, is detected in the component data. This avoids meaningless empty requests or redundant data loading. Furthermore, the preset bridging interface adapts to heterogeneous target device functional interfaces, and functional data is obtained using the preset bridging interface for all components, eliminating the need to design differentiated data acquisition logic for different components.
[0109] Optionally, the component data for basic components, layout components, and functional components includes target key-value pairs. These target key-value pairs are key-value pairs between a text display identifier and its corresponding template variable. Specifically, the text display identifier is the key, and the template variable is the value.
[0110] In some embodiments, when binding functional data with template variables in the corresponding component data of the interface component to update the interface component, the target key-value pairs of the component data of the basic component, layout component, and functional component can be determined, and according to the text display identifier, the second preset processor is used to bind the functional data with the template variables in the target key-value pairs of the component data of the basic component, layout component, and functional component, so that the basic component, layout component, and functional component are updated according to the component data of the corresponding bound functional data.
[0111] The second preset processor is used to bind functional data to template variables. For example, it can be the Pebble template engine. The calling logic of the Pebble template engine is encapsulated in the TemplateUtil utility class. The TemplateUtil utility class can call the Pebble template engine. It is also used to identify target key-value pairs in the component data and to convert the structure of the functional data into a data structure recognizable by the Pebble template engine. The template variables are to be replaced by the functional data of the corresponding target device.
[0112] As mentioned above, template variables are placeholders enclosed in {{}} within the Pebble template, indicating the positions in the component data that need to be dynamically populated, and also indicating the reference paths to the functional data to be bound. In this embodiment, the TemplateUtil utility class is used to identify template variables of target key-value pairs in the component data using regular expressions, and the structure of the functional data in the data carrier associated with the communication session is converted into a Map / List structure recognizable by the Pebble template engine. The Pebble template engine then finds the corresponding functional data from the Map / List structure based on the reference paths of the template variables, and binds the corresponding functional data to the template variables in the component data, that is, filling the functional data into the corresponding template variables.
[0113] In this embodiment, the Pebble template engine binds the corresponding functional data with the template variables in the component data and outputs plain text. The TemplateUtil utility class is used to convert the plain text into a typed numeric value suitable for the corresponding component attribute type, such as a string, integer, boolean value, and array. Finally, the component data with bound functional data is obtained, so that the interface component can update its own attributes according to the corresponding component data with bound functional data. For example, the interface component updates its own attributes based on the bind() method and the component data with bound functional data.
[0114] In this embodiment, the Pebble template engine enables automatic binding and replacement of template variables and functional data in component data, achieving high binding precision and accuracy. Simultaneously, plain text results are converted into typed numerical values required by the components, balancing the characteristics of the general engine with the strong typing requirements of functional components. Furthermore, the mapping between data sources and template variables is implemented based on communication sessions and the TemplateUtil utility class, ensuring synchronization between subsequent interface rendering and target device control.
[0115] Step 304: Based on the updated interface components, generate and display the target interface.
[0116] After updating its own attributes, the UI component is attached to a card, such as to a free layout container, to render the target UI. Here, "UI component" refers to a UI component instance, and "card" refers to a card instance.
[0117] For the specific implementation method and principle of step 304, please refer to [link / reference]. Figure 2 The relevant descriptions in the embodiments will not be repeated here.
[0118] In some embodiments, after generating and displaying the target interface, changes in the data source can be monitored so that the interface components can be updated again based on the monitored data changes. Then, the target interface is updated and displayed based on the updated interface components.
[0119] As mentioned above, after creating the UI component, based on the data source indicated by the `bind` field, data is requested through the AtomicManager, and a dedicated communication session (AISession) is created. Thus, each data source corresponds to one communication session, and the communication session manages the lifecycle and data change notifications of the corresponding data source. The `sessionMap` manages all communication sessions uniformly, using the session identifier as the key and the communication session as the value.
[0120] Optionally, by registering a data change listener in the communication session, the system can monitor the data source associated with the current communication session. When a data change is detected in the data source, such as when the vehicle system sends a session identifier + changed value (sessionId, payload) in a smart cockpit scenario, the changed value will be updated to the corresponding data carrier based on the session identifier, thus updating the functional data of the target device. This triggers the data binding process, using the TemplateUtil utility class to re-parse the template variables in the component data. It's important to note that while these template variables have been replaced by the corresponding functional data, their mapping relationship with the corresponding text display identifier has been recorded and can therefore be recognized and parsed. The Pebble template engine, based on the reference path of the template variables, determines the corresponding updated functional data, achieving automatic updating of the component data.
[0121] This allows the corresponding UI components to update their own properties based on the `bind()` method and the component data bound to the updated functional data. Specifically, the `TemplateUtil` utility class is used to find the target key-value pairs in the updated component data whose values have changed. The UI component only updates its own properties for the updated functional data (the target key-value pairs whose values have changed), rather than updating all of them. During rendering, only the updated properties of the component are rendered, resulting in only the updated numerical display area on the target interface, rather than redrawing the entire display interface.
[0122] Here, the specific implementation method and principle of this embodiment are described in the relevant descriptions in the foregoing embodiments, and will not be repeated here.
[0123] In this embodiment, by registering a data change listener, unified monitoring of multiple data sources is supported, enabling real-time and accurate monitoring of data source changes. This ensures that data changes are synchronized with the interface display, achieving real-time automatic interface refresh without the need for manual update code. Furthermore, it eliminates the need to create new communication sessions and renders only the updated properties of components, improving data update efficiency, reducing resource consumption, and preventing interface flickering through partial refresh.
[0124] In some embodiments, after generating and displaying the target interface, it is also possible to detect whether there is a target device control operation on the target interface. If a target device control operation is detected on the target interface, the corresponding functional logic corresponding to the target device control operation is executed using the corresponding interactive behavior description.
[0125] The component data also includes descriptions of interactive behaviors, which are described through event objects. These include various event types such as click events (onClick), value change events (onChange), selection events (onSelected), pre-action events (onPreAction), pre-selection events (onPreSelect), and stop tracking events (onStopTrack). All these event objects are placed in a unified `events` structure, such as `"events":{"onClick":{...}}`. Taking a smart cockpit scenario as an example, pre-action and pre-selection events are used for pre-verification of cockpit safety operations such as child locks and driving mode switching, while stop tracking is used to stop navigation or media tracking.
[0126] Furthermore, the `action` field indicates the operation to be performed when the event is triggered, which is the event handling interface. This can be the target device function URI or a system-built-in action (such as the card zoom-in interface operation). Parameters are passed through the `params` field, which is the carrier for passing specific execution parameters to the operation specified in the `action` field. Template variable binding is supported. Taking the smart cockpit scenario as an example, `{{ progress}}`, `{{ isChecked}}`, and `{{ position}}` represent progress, on / off status, and position, respectively. These are automatically replaced with the current actual data of the corresponding interface component when the event is triggered. For example, if the user operates the target interface, drags the window opening slider to 80%, and clicks the confirmation button, the event is triggered, and the template variable `{{ progress}}` corresponding to the `params` field is automatically replaced with 80%.
[0127] The action and params fields are also placed in the events structure, such as “events”: {“onClick”:{“action”: “xxx”, “params”: {“position”: “{{ progress}}”}}}, where xxx is the specific event handling interface.
[0128] After the UI component is created, it uses the `bindData()` method to check if the component data contains event objects, such as checking for the `events` field. If so, the `bindData()` method automatically registers event listeners using the corresponding registration method. When a registered event listener detects a target device control operation on the target interface, such as a click event, this embodiment executes the target device function call based on the event handling interface indicated by the corresponding `action` field, such as the target device function URI. Furthermore, if there is a corresponding `params` field, this embodiment executes the target device function call based on the specific execution parameters indicated by the `params` field and the event handling interface indicated by the `action` field.
[0129] Taking the smart cockpit scenario as an example, the interface corresponds to seat adjustment. Before the user triggers the cockpit control operation, the target interface can display the current seat back angle. After the user clicks the seat adjustment button, the current seat back angle can be adjusted based on the target interface, and after the adjustment is completed, the adjusted seat back angle is updated on the interface.
[0130] In this way, by describing the event interaction behavior, the system can automatically parse event objects, automatically register event listeners, automatically handle template variable replacement, and automatically execute target device function calls without having to manually write event handling code.
[0131] Optionally, when executing the functional logic corresponding to the target device control operation, verification can be performed first, such as parameter range verification and operation step size limit verification. Taking the smart cockpit scenario as an example, in the window control scenario, if the action field points to the URI of the window control function vehicle / window, then the specific execution parameters indicated by the params field are verified to be within the preset range, such as the window opening range of 0~100%. If the execution parameters exceed the preset range, the operation will be rejected. Operation step size limit verification verifies the step size of a single operation for continuous operations. For example, in the window control scenario, the maximum change step size is less than or equal to 5%, thereby preventing rapid changes caused by accidental operation.
[0132] In this embodiment, when a target device control operation is detected on the target interface, the corresponding functional logic can be automatically executed based on the target interface, and the functional data of the target device after the operation is executed can be updated and displayed synchronously, thus improving the user interaction experience. Furthermore, by performing verifications such as parameter range verification and operation step size limit verification, functional or safety malfunctions of the target device caused by misoperation can be effectively avoided, improving the safety and reliability of the target device operation.
[0133] In some embodiments, component lifecycle monitoring is performed. When the component is detected to be destroyed, all data monitoring associated with that component in the sessionMap is automatically cleaned up, and the associated communication session resources are released to prevent memory leaks.
[0134] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0135] Figure 4 This is a schematic diagram of the interface generation apparatus provided in an embodiment of this application. Figure 4 As shown, the interface generation device provided in this embodiment may include: an acquisition module 401, a determination module 402, a binding module 403, and a generation module 404.
[0136] The acquisition module 401 is used to acquire function control instructions and obtain interface description data based on the function control instructions.
[0137] The determining module 402 is used to obtain component data based on the interface description data, and determine the corresponding interface component according to the component data; wherein, the interface component includes a basic component, a layout component and a functional component; the functional component is injected with a preset bridging interface for bridging with the functional interface of the target device.
[0138] The binding module 403 is used to obtain the functional data of the target device through the preset bridging interface, and bind the functional data with the template variables in the corresponding component data of the interface component so as to update the interface component.
[0139] Module 404 is used to generate and display the target interface based on the updated interface components.
[0140] In one possible implementation, the determining module 402 is further used for: The interface description data is parsed to determine the corresponding card; Based on the card, component data is obtained; wherein, the component data includes component type identifier, component attribute description, component hierarchy, as well as template variables, data source and interaction behavior description; Based on the component data, create corresponding basic components, layout components, and functional components.
[0141] In one possible implementation, the determining module 402 is further used for: Using a first preset processor, determine the component implementation class corresponding to the component type identifier in the component data; Based on the component implementation class, corresponding basic components, layout components, and functional components are created; wherein, the first preset processor is used to create corresponding basic components, layout components, and functional components based on the component type identifier; the component implementation class is constructed based on pre-set standardized and unified constraints.
[0142] In one possible implementation, the determining module 402 is further used for: Using a first preset processor, the basic component is created based on the corresponding component implementation class and component attribute description. For the aforementioned layout component, the layout component is created based on the corresponding component implementation class, component attribute description, and component hierarchy. For the aforementioned functional component, the functional component is created based on the corresponding component implementation class, component attribute description, and injected preset bridging interface.
[0143] In one possible implementation, the binding module 403 is also used for: Determine whether there is a data source in the component data of the basic components, layout components, and functional components; If a data source is available, the data from the data source is obtained using the preset bridging interface of the functional component as functional data.
[0144] In one possible implementation, the component data of the basic component, layout component, and functional component includes target key-value pairs, where the target key-value pairs are key-value pairs between a text display identifier and a corresponding template variable; the binding module 403 is further configured to: Determine the target key-value pairs for the corresponding component data of the basic components, layout components, and functional components; Based on the text display identifier, using the second preset processor, the functional data is bound to the template variables in the target key-value pairs of the corresponding component data of the basic component, layout component, and functional component, so that the basic component, layout component, and functional component are updated according to the corresponding component data bound to the functional data; The template variable is to be replaced by the corresponding functional data.
[0145] In one possible implementation, the generation module 404 is also used for: Monitor data changes in the data source so that the interface components can update again based on the monitored data changes; Based on the updated interface components, update the target interface and display it.
[0146] In one possible implementation, the function control instructions include vehicle infotainment function control instructions; the acquisition module 401 is further configured to: Based on the vehicle infotainment system function control commands, determine the corresponding control intent; Based on the control intent, the corresponding interface architecture and constraint specifications are obtained from the preset knowledge base; wherein, the knowledge base stores the interface architecture and constraint specifications in preset formats corresponding to different control intents; Based on the corresponding interface architecture and constraint specifications, generate interface description data in a preset format.
[0147] In one possible implementation, the generation module 404 is also used for: Detect whether there is a target device control operation on the target interface; If the target device control operation is detected on the target interface, the corresponding functional logic corresponding to the target device control operation is executed using the corresponding interactive behavior description.
[0148] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.
[0149] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 5 As shown, the electronic device 500 of this embodiment includes a processor 510 and a memory 520, wherein the memory 520 stores a computer program 521 that can run on the processor 510. When the processor 510 executes the computer program 521, it implements the steps in any of the above-described method embodiments, for example... Figure 2 Steps 201 to 204 are shown. Alternatively, when processor 510 executes computer program 521, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 4 The functions of modules 401 to 404 are shown.
[0150] For example, computer program 521 may be divided into one or more modules / units, one or more of which are stored in memory 520 and executed by processor 510 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 521 in electronic device 500.
[0151] Those skilled in the art will understand that Figure 5 This is merely an example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, buses, etc.
[0152] The processor 510 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.
[0153] The memory 520 can be an internal storage unit of the electronic device, such as a hard drive or memory, or an external storage device, such as a plug-in hard drive, SmartMedia Card (SMC), Secure Digital (SD) card, or Flash Card. The memory 520 can also include both internal and external storage units. The memory 520 is used to store computer programs and other programs and data required by the electronic device. The memory 520 can also be used to temporarily store data that has been output or will be output.
[0154] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0155] An embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described interface generation method.
[0156] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0157] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software 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 this application.
[0158] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0159] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0160] Furthermore, the functional units in the various embodiments of this application 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.
[0161] If the integrated module / 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, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.
[0162] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A method for generating an interface, characterized in that, include: Obtain function control instructions, and obtain interface description data based on the function control instructions; Based on the interface description data, component data is obtained, and corresponding interface components are determined according to the component data; wherein, the interface components include basic components, layout components and functional components; the functional components are injected with preset bridging interfaces for bridging with the functional interfaces of the target device; The function data of the target device is obtained through the preset bridging interface, and the function data is bound to the template variable in the corresponding component data of the interface component so that the interface component can be updated. Based on the updated interface components, generate and display the target interface.
2. The interface generation method according to claim 1, characterized in that, The process of obtaining component data based on the interface description data and determining the corresponding interface components based on the component data includes: The interface description data is parsed to determine the corresponding card; Based on the card, component data is obtained; wherein, the component data includes component type identifier, component attribute description, component hierarchy, as well as template variables, data source and interaction behavior description; Based on the component data, create corresponding basic components, layout components, and functional components.
3. The interface generation method according to claim 2, characterized in that, The creation of corresponding basic components, layout components, and functional components based on the component data includes: Using a first preset processor, determine the component implementation class corresponding to the component type identifier in the component data; Based on the component implementation class, corresponding basic components, layout components, and functional components are created; wherein, the first preset processor is used to create corresponding basic components, layout components, and functional components based on the component type identifier; the component implementation class is constructed based on pre-set standardized and unified constraints.
4. The interface generation method according to claim 3, characterized in that, Using the first preset processor, based on the component implementation class, corresponding basic components, layout components, and functional components are created, including: Using a first preset processor, the basic component is created based on the corresponding component implementation class and component attribute description. For the aforementioned layout component, the layout component is created based on the corresponding component implementation class, component attribute description, and component hierarchy. For the aforementioned functional component, the functional component is created based on the corresponding component implementation class, component attribute description, and injected preset bridging interface.
5. The interface generation method according to any one of claims 2 to 4, characterized in that, The step of obtaining the functional data of the target device through the preset bridging interface includes: Determine whether there is a data source in the component data of the basic components, layout components, and functional components; If a data source is available, the data from the data source is obtained using the preset bridging interface of the functional component as functional data.
6. The interface generation method according to any one of claims 1 to 4, characterized in that, The component data of the basic components, layout components and functional components contain target key-value pairs, which are key-value pairs of text display identifiers and corresponding template variables; The step of binding the functional data with the template variable in the corresponding component data of the interface component to update the interface component includes: Determine the target key-value pairs for the corresponding component data of the basic components, layout components, and functional components; Based on the text display identifier, using the second preset processor, the functional data is bound to the template variables in the target key-value pairs of the corresponding component data of the basic component, layout component, and functional component, so that the basic component, layout component, and functional component are updated according to the corresponding component data bound to the functional data; The template variable is to be replaced by the corresponding functional data.
7. The interface generation method according to any one of claims 2 to 4, characterized in that, After generating and displaying the target interface, the following is also included: Monitor data changes in the data source so that the interface components can update again based on the monitored data changes; Based on the updated interface components, update the target interface and display it.
8. The interface generation method according to any one of claims 1 to 4, characterized in that, The function control commands include vehicle infotainment function control commands; The step of obtaining interface description data according to the function control instructions includes: Based on the vehicle infotainment system function control commands, determine the corresponding control intent; Based on the control intent, the corresponding interface architecture and constraint specifications are obtained from the preset knowledge base; wherein, the knowledge base stores the interface architecture and constraint specifications in preset formats corresponding to different control intents; Based on the corresponding interface architecture and constraint specifications, generate interface description data in a preset format.
9. The interface generation method according to any one of claims 2 to 4, characterized in that, After generating and displaying the target interface based on the updated interface components, the process further includes: Detect whether there is a target device control operation on the target interface; If the target device control operation is detected on the target interface, the corresponding functional logic corresponding to the target device control operation is executed using the corresponding interactive behavior description.
10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the interface generation method as described in any one of claims 1 to 9.