Layered data driving application development method based on swan gap framework decorator

Abstract

The invention relates to a hierarchical data-driven application development method based on a Model-ViewModel-View three-layer architecture, data-driven automatic state management is realized through the Model-ViewModel-View three-layer architecture, and the core process comprises the following steps: in a Model layer, uniformly processing server and local data, and outputting a standardized entity object; in the ViewModel layer, packaging service logic, and notifying the View layer of the processed data change through a decorator; and focusing on UI display on a View layer, monitoring data change through a decorator, and automatically updating an interface. According to the invention, a swan gap framework decorator, a layered architecture and a data driving mechanism are deeply fused, efficient, low-coupling and maintainable application development is realized, and aiming at the problem of strong coupling of a UI and business logic in swan gap application development, through a standardized data processing flow and automatic state management, the development efficiency is improved. And the maintainability, the testability and the cross-device adaptation capability of the application are improved.

Description

Technical Field

[0001] The present invention relates to cross-device application development technology for the Hongmeng operating system (HarmonyOS), and specifically to a layered data-driven application development method based on the Hongmeng framework decorator. Background Art

[0002] In Hongmeng application development, the traditional development model mixes UI rendering components (Pages modified by @Component. @Component is a decorator used to declare custom components in the Hongmeng ArkUI framework. Page is the basic interaction unit of an application, usually corresponding to a complete user interface (UI)) with business logic, leading to the following technical problems:

[0003] Severe code coupling: UI components directly call network requests and data processing logic. For example, click events on the product list page directly operate the database, which violates the "separation of concerns" principle and increases the difficulty of code maintenance.

[0004] Inefficient state management: Relying on manual UI updates (such as calling a custom refreshUI() method), and failing to fully utilize the responsiveness of decorators such as HarmonyOS @State / @Observed (@State is a decorator used in the HarmonyOS ArkUI framework to declare the internal state of a component, and @Observed is used to modify the data model class, indicating that instances of this class can be monitored by other decorators (such as @ObjectLink or @Prop, @ObjectLink is used to monitor instances of the @Observed class to achieve two-way binding between parent and child components, and @Prop is used to receive immutable data from the parent component, one-way binding)). This results in data changes being out of sync with UI rendering.

[0005] The layered architecture is ambiguous: The responsibilities of the Model layer (data model layer, responsible for handling data acquisition, storage, and operation) and the ViewModel layer (view model layer, responsible for processing business logic, converting Model layer data into a form that can be displayed by the View layer (view layer, i.e. user interface, responsible for displaying data and receiving user input, and handling user interaction events)) are unclear, and some business logic is redundant; the ViewModel layer directly references UI components (such as buttons and text boxes), which destroys layered isolation and makes unit testing difficult to execute independently.

[0006] The information disclosed in this background technology section is only intended to deepen the understanding of the overall background technology of the present invention and should not be regarded as an admission or any form of suggestion that the information constitutes the prior art already known to those skilled in the art. Summary of the Invention

[0007] In response to the defects existing in the prior art, the purpose of the present invention is to provide a layered data-driven application development method based on the Harmony framework decorator, deeply integrating the Harmony framework decorator, layered architecture and data-driven mechanism to achieve efficient, low-coupling and maintainable application development. In response to the problem of strong coupling between UI and business logic in Harmony application development, the maintainability, testability and cross-device adaptability of the application are improved through standardized data processing processes and automated state management.

[0008] In order to achieve the above purpose, the technical solution adopted by the present invention is:

[0009] A layered data-driven application development method based on the Hongmeng framework decorator is characterized by implementing data-driven automated state management through the Hongmeng decorator based on the Model-ViewModel-View three-layer architecture. The core process includes:

[0010] In the Model layer, the server and local data are processed uniformly and standardized entity objects are output;

[0011] In the ViewModel layer, encapsulate business logic and notify the View layer of processed data changes through decorators;

[0012] In the View layer, focus on UI display, monitor data changes through decorators and automatically update the interface.

[0013] Based on the above technical solutions, heterogeneous data sources are converted into unified entity objects through model layer data preprocessing, providing standardized data interfaces;

[0014] The heterogeneous data sources include server API and local Room database.

[0015] Based on the above technical solution, the data preprocessing steps on the server API specifically include:

[0016] Call the server API through the Hongmeng network module to obtain raw data;

[0017] Use a data parser to map raw data into entity classes, including field validation logic;

[0018] The parsed data is subjected to business preprocessing to generate pure business data objects; the business preprocessing includes deduplication of product list data and filtering of sensitive information.

[0019] Based on the above technical solution, the data preprocessing steps in the local Room database specifically include:

[0020] Use the Hongmeng Room database to operate local storage and define data access objects (DAOs) to implement additions, deletions, modifications, and queries.

[0021] Use the @LocalStorage decorator to mark the local state that needs to be persisted, and combine it with the HarmonyOS distributed data service DDS to achieve cross-device data synchronization.

[0022] Based on the above technical solutions, the ViewModel layer business logic is used to isolate UI dependencies, handle complex business logic, and expose observable data through decorators.

[0023] Based on the above technical solution, the ViewModel layer includes the following data acquisition and processing steps:

[0024] Obtain the Model layer data interface through dependency injection and define business methods;

[0025] Call the Model layer to obtain pre-processed data, perform logical processing, and generate final business data;

[0026] When data changes, the ViewModel layer includes the following notification steps:

[0027] Use the @Observed decorator to mark business data variables. When the data changes, the Hongmeng responsive data bus will be automatically triggered to notify subscribers.

[0028] It is prohibited to directly operate UI components in the ViewModel layer to ensure that the business logic can be independently unit tested.

[0029] Based on the above technical solution, at the ViewModel layer, data acquisition and processing specifically include:

[0030] Define the data interface in the Model layer;

[0031] Inject the implementation class through the dependency injection framework in the ViewModel layer;

[0032] Replace real dependencies with mock objects.

[0033] Based on the above technical solutions, at the View layer, decorators are used to monitor data changes to achieve declarative UI rendering and event-driven interaction.

[0034] Based on the above technical solution, the declarative UI rendering and event-driven interaction includes the following data binding and rendering steps:

[0035] Use @ObjectLink in UI components to establish weak references to ViewModel layer objects to avoid memory leaks caused by strong references;

[0036] Declare the local state of the component through @State, use expressions to bind data in the UI template, and when the @Observed data changes, the framework automatically redraws the affected component nodes.

[0037] Based on the above technical solution, the declarative UI rendering and event-driven interaction includes the following user interaction processing steps:

[0038] Map user operations to ViewModel layer method calls, and indirectly trigger UI updates by changing ViewModel data;

[0039] Use @AppStorage to manage global state and share data across pages.

[0040] The layered data-driven application development method based on the Hongmeng framework decorator described in the present invention has the following beneficial effects:

[0041] 1. Decorator-driven automatic decoupling:

[0042] @State implements automatic binding of component state to the UI, @Observed implements cross-layer data change notification, and @ObjectLink ensures weak reference association. Together, the three form a fully automatic link of "data change → UI update", eliminating the need to manually write synchronization code.

[0043] The decorator automatically binds data to the UI, reducing state management code (such as no need to manually write setState or event listening functions).

[0044] 2. Strict hierarchical division of responsibilities:

[0045] The Model layer focuses on data conversion and storage, the ViewModel layer focuses on business logic, and the View layer focuses on UI display. Cross-layer communication is achieved through decorators to avoid logic leakage problems in traditional development.

[0046] The layered architecture provides standardized development templates, which can shorten the development cycle of new features. For example, when adding a new product classification and filtering function, you only need to add filtering logic in the ViewModel layer and update the UI binding in the View layer.

[0047] Code coupling is reduced, and business logic is concentrated in the ViewModel layer. UI exceptions can be quickly located to View layer data binding, and logical errors can be reproduced through ViewModel unit testing.

[0048] 3. Data-driven performance optimization:

[0049] The HarmonyOS framework automatically detects data changes and only updates the affected UI components. Combined with a deterministic latency engine to optimize task scheduling, page rendering performance is improved compared to traditional full-page redrawing.

[0050] The cost of cross-device adaptation has been reduced. Through @AppStorage and distributed data services, the interface and data of mobile phones, tablets and PCs can be synchronized with one development.

[0051] Compared with existing technologies, the core innovations are:

[0052] Use @State / @Observed to implement declarative state management and eliminate manual synchronization code;

[0053] Define the Model-ViewModel-View three layers to clarify their responsibilities and implement automated cross-layer communication through decorators;

[0054] Combined with the distributed characteristics of HarmonyOS, efficient adaptation of "one-time development, multi-terminal deployment" is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] The present invention has the following accompanying drawings:

[0056] The accompanying drawings are provided for a better understanding of the present invention and are not intended to limit the present invention.

[0057] Figure 1 Flowchart of Example 1 of the layered data-driven application development method based on the Hongmeng framework decorator described in the present invention. DETAILED DESCRIPTION

[0058] The present invention will be described in further detail below with reference to the accompanying drawings. The detailed description, which is provided for illustrative purposes only and includes various details to aid understanding of the embodiments of the present invention, should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted from the following description.

[0059] like Figure 1 As shown, the layered data-driven application development method based on the Hongmeng framework decorator of the present invention includes:

[0060] Based on the Model-ViewModel-View three-tier architecture (MVVM architecture), data-driven automatic state management is implemented through the Hongmeng decorator. The core processes include:

[0061] In the Model layer, the server and local data are processed uniformly and standardized entity objects are output;

[0062] In the ViewModel layer, encapsulate business logic and notify the View layer of processed data changes through decorators;

[0063] In the View layer, focus on UI display, monitor data changes through decorators and automatically update the interface.

[0064] The boundaries of the three-layer architecture described in this embodiment are:

[0065] Model layer: data acquisition and preprocessing; the Model layer does not involve business logic;

[0066] ViewModel layer: business logic and data conversion; the ViewModel layer is prohibited from directly operating the UI;

[0067] View layer: pure UI display and interactive response.

[0068] Based on the above technical solutions, heterogeneous data sources are converted into unified entity objects through model layer data preprocessing, providing standardized data interfaces;

[0069] The heterogeneous data sources include server API and local Room database.

[0070] Based on the above technical solution, the data preprocessing steps on the server API specifically include:

[0071] Call the server API through the Hongmeng network module (such as HttpUrlConnection) to obtain raw data (JSON / XML format);

[0072] Use a data parser (such as the Jackson library) to map the raw data into entity classes (such as the GoodsEntity class, which encapsulates product-related data and includes fields such as the goodsId (which uniquely identifies each product ID), the price (which represents the selling price), and the imageUrl (which points to the uniform resource locator (URL) of the product image, through which the product display image can be obtained). This includes field validation logic (for example, the price field must be a positive number and the product ID cannot be empty). The validation rules are defined as follows:

[0073] The product price (price) must be a value greater than 0. If the price field is abnormal (such as a negative number or non-numeric value), it will be automatically replaced with the default value 0 and a warning log will be recorded:

[0074] The product ID (goodsId) cannot be empty and must conform to regular expression rules (e.g., a 10-character alphanumeric combination). If the product ID is missing or incorrectly formatted, the product data will be discarded and an error log will be recorded:

[0075] The parsed data is subjected to business preprocessing to generate clean business data objects; the business preprocessing includes deduplication of product list data and filtering of sensitive information (hiding inventory warning thresholds).

[0076] Based on the above technical solution, the data preprocessing steps in the local Room database specifically include:

[0077] Use the Hongmeng Room database to operate local storage and define data access objects (DAOs) to implement addition, deletion, modification, and query, such as GoodsDao.queryFavoriteGoods();

[0078] Use the @LocalStorage decorator to mark local states that need to be persisted (such as user browsing history), and combine it with the Hongmeng Distributed Data Service (DDS) to achieve cross-device data synchronization;

[0079] @LocalStorage is a custom decorator that associates the marked variable or state with local storage.

[0080] Based on the above technical solutions, the ViewModel layer business logic is used to isolate UI dependencies, handle complex business logic, and expose observable data through decorators.

[0081] Based on the above technical solution, the ViewModel layer includes the following data acquisition and processing steps:

[0082] Obtain the Model layer data interface through dependency injection (such as the dependency injection annotation @Autowired, which is an annotation in the Spring framework for automatic assembly, that is, automatically injecting dependent objects where needed) and define business methods (such as the method fetchRecommendedGoods() for getting recommended goods, which is a custom business method name. Its function is to obtain the recommended goods list from the data source (such as a database, server-side API, etc.) and return it to the caller);

[0083] Call the Model layer to obtain preprocessed data, perform logical processing (such as filtering products according to user preferences, calculating promotional prices), and generate final business data (such as the filtered goods list FilteredGoodsList, which is a custom data structure name used to store a collection of product data after screening or filtering operations. The screening or filtering refers to the list of products filtered from the original product data set according to specific conditions (such as user preferences). Each element represents a product object that meets the screening conditions).

[0084] Based on the above technical solution, when data changes, the ViewModel layer includes the following notification steps:

[0085] Use the @Observed decorator to mark business data variables (such as the displayGoods data set for displaying products). When the data changes (for example, if the filter conditions change, the displayGoods data set for displaying products changes), the HarmonyOS responsive data bus is automatically triggered to notify subscribers.

[0086] It is forbidden to directly operate UI components in the ViewModel layer to ensure that the business logic can be independently unit tested (such as simulating the data returned by the Model layer to verify whether the displayGoods meets expectations).

[0087] @Observed is a decorator used in the HarmonyOS framework to mark observable data. Once the data of a business data variable modified by @Observed changes, the system can automatically detect the change and trigger the corresponding mechanism to notify other parts that depend on the data (i.e., subscribers) to perform update operations.

[0088] Based on the above technical solution, at the ViewModel layer, data acquisition and processing specifically include:

[0089] Define data interfaces in the Model layer, such as GoodsRepository;

[0090] Inject the implementation class in the ViewModel layer through the dependency injection framework, for example, use @Inject to inject the implementation class in the ViewModel layer;

[0091] Replace real dependencies with simulated objects (such as Mock objects).

[0092] Based on the above technical solutions, at the View layer, decorators are used to monitor data changes to achieve declarative UI rendering and event-driven interaction.

[0093] Based on the above technical solution, the declarative UI rendering and event-driven interaction includes the following data binding and rendering steps:

[0094] Use @ObjectLink in UI components to establish weak references to ViewModel layer objects to avoid memory leaks caused by strong references;

[0095] Declare the local state of the component through @State, use expressions to bind data in the UI template, and when the @Observed data changes, the framework automatically redraws the affected component nodes.

[0096] The @ObjectLink decorator is used to establish a weak reference to the ViewModel layer object in the UI component, such as @ObjectLink private goodsModel:GoodsViewModel. A weak reference does not prevent the referenced object from being garbage collected. For example, when the ViewModel layer object is no longer needed, if the UI component holds a strong reference to it, the object will not be recycled, which may cause excessive memory usage. Using @ObjectLink to establish a weak reference means that even if the UI component references the ViewModel layer object, the object can still be garbage collected when there are no other strong references to it.

[0097] The @State decorator is used to declare a component's local state. For example, isLoading:boolean is a local state variable declared with @State that indicates whether the component is loading data. Local state refers to the state within a component, affecting only the component's behavior and display. When a state variable declared with the @State decorator changes, the framework automatically updates the bound UI component.

[0098] The UI template describes the structure and style of the UI component and is usually defined using a markup language (such as XML or JSX in JavaScript). In this template, you can use expressions to bind data so that the UI can display data dynamically. For example, Text(goodsModel.displayGoods[0].name) is an example of using expressions to bind data in the UI template. It displays the name attribute of the first element of the displayGoods array in the ViewModel layer in the text component. When the data in the displayGoods array changes, the text component automatically updates to display the new data.

[0099] Exemplarily, weak references and data binding specifically include:

[0100] Implementation of the weak reference mechanism of @ObjectLink; define the data model modified by @Observed (such as CartModel) in the parent component, and the child component establishes a weak reference association through @ObjectLink:

[0101]

[0102] Weak references ensure that when the parent component is destroyed, the child component does not prevent garbage collection.

[0103] Local state management implementation of @State; use @State to declare private state within the component (such as loading state isLoading:boolean):

[0104]

[0105]

[0106] Implementation of expression binding and automatic update; directly bind ViewModel layer data in the UI template, for example:

[0107] Text(this.cart.totalPrice.toFixed(2)) / / Display the total price of the shopping cart in real time

[0108] When the @Observed marked cart.totalPrice changes, the framework only updates the Text component.

[0109] Based on the above technical solution, the declarative UI rendering and event-driven interaction includes the following user interaction processing steps:

[0110] Map user operations to ViewModel layer method calls, and indirectly trigger UI updates by changing ViewModel data;

[0111] Use @AppStorage to manage global state and share data across pages.

[0112] Common user operations include clicking, sliding, long pressing, and entering text. For example, the mapped method call is: Button("Filter").onClick(()=>goodsModel.applyFilter()), which means that the action of clicking the "Filter" button is captured, thereby triggering subsequent business logic.

[0113] The ViewModel layer receives user operation instructions from the View layer and calls the corresponding business logic method for processing. In Button("Filter").onClick(()=>goodsModel.applyFilter()), goodsModel belongs to the ViewModel layer, and applyFilter() is the business logic method of the ViewModel layer, which is used to handle the business of filtering products. In this scenario, goodsModel.applyFilter() calls the applyFilter() method of the goodsModel object to execute the business logic of filtering products.

[0114] The @AppStorage decorator is used to add additional functionality to a class, method, or variable. In this embodiment, the @AppStorage decorator is used to manage the global state of the application. The state data marked by it can be shared among various pages or components of the application to achieve cross-page data transfer and synchronization. For example, when the global state is the user login token, @AppStorage achieves cross-page data sharing by managing the global state, ensuring that after a successful login, all pages can obtain the user's login information and automatically display the user's avatar.

[0115] The following are specific examples.

[0116] Example 1: Product browsing function development

[0117] Model layer implementation: The model layer undertakes the critical tasks of data acquisition and preprocessing. In Tongfu Cloud Commerce's product browsing function, it first obtains product data from the server. This process involves communicating with the server. Product data obtained through specific network requests is typically in JSON format. This data contains various product information, such as product number, name, price, and image link. However, it may contain inconsistent formatting, incomplete data, or redundant information.

[0118] To address this situation, the Model layer parses the raw data it receives and converts it into a unified entity object, namely an instance of the GoodsModel class. During the parsing process, the data is rigorously verified for accuracy, such as checking whether the product price is a positive number and whether the product number is unique and compliant. Only data that passes these checks is converted into a GoodsModel object, ensuring the reliability of the data for subsequent processing. Therefore, in actual implementation, the following exception handling mechanism can be introduced into the Model layer:

[0119] Network request fault tolerance: Capture HttpError exceptions in server-side API calls and enable a maximum of three retries. If the call still fails, return degraded data (such as a cached product list).

[0120] Database transaction guarantee: Enable transactions in Room database operations to ensure the atomicity of additions, deletions, modifications and queries.

[0121] Processing logic when verification fails: enable default values ​​for fields that fail parsing (such as setting the price field to 0 when it is abnormal) and record the error log.

[0122] In addition to server-side data, the Model layer is also responsible for the storage and management of local data. It will use the local storage function of HarmonyOS to save data such as user browsing history locally. For example, when a user browses a certain product, the relevant information of the product (such as the product number) will be stored locally, and the @LocalStorage decorator is used to mark the local state that needs to be persisted, thereby realizing local persistent storage of data. The advantage of this is that when the user opens the application again, the browsing history can be quickly obtained, providing users with a more convenient shopping experience. Moreover, locally stored data can also be used when the network is unstable or offline, which enhances the availability of the application.

[0123] ViewModel layer implementation: The ViewModel layer is between the Model layer and the View layer, playing an important role as a bridge and business logic processing.

[0124] The product browsing function retrieves pre-processed product data from the Model layer. For example, when a user selects the "Electronics" category on the product category page, the ViewModel layer calls the interface provided by the Model layer to retrieve the product data for that category. This data may contain a large amount of product information, and the ViewModel layer processes it according to business needs.

[0125] One important process is product filtering. For example, based on user preferences, you might want to filter out products within a certain price range, specific brands, or those with certain special attributes. The ViewModel layer also calculates promotional prices. If a product is on sale, it calculates the discounted price based on the promotion rules so that it can be accurately displayed to the user on the product display page.

[0126] In addition, the ViewModel layer will mark the processed data with the @Observed decorator, so that when the data changes, such as the user changes the filter conditions, the new filter result data changes will be automatically monitored and notified to the View layer so that the product display content can be updated in time. For example, by marking the processed data variable (such as displayGoods) with the @Observed decorator, when the data changes (such as the filter condition changes causing the product list to be updated), the HarmonyOS responsive data bus is automatically triggered to notify the subscriber (ie, the View layer). This strictly follows the use of the @Observed decorator in the technical solution, realizes automatic notification of data changes, ensures that the View layer can update the product display content in a timely manner, and maintains consistency between the data and the interface display.

[0127] View layer implementation: The View layer focuses on presenting an intuitive and friendly product browsing interface for users.

[0128] It uses Hongmeng's ArkUI components to build page layouts. On the product list page, a list component is used to display product information. By establishing a weak reference to the ViewModel layer object through @ObjectLink, the product data processed by the ViewModel layer can be obtained, such as the product list displayGoods. Expressions are used to bind data in the UI template, such as displaying the product name goodsModel.displayGoods[0].name. When the data marked with @Observed changes, the framework automatically redraws the affected component nodes and updates the product display.

[0129] In the list, each item displays key product information, such as its name, price, and image. This information is obtained by binding data using expressions in the UI template. For example, the product name is displayed as goodsModel.displayGoods[0].name, which means that the name of the first item in the list, obtained from the ViewModel layer, is displayed on the page. If the item is on sale, the sale price is also displayed.

[0130] The View layer handles user actions accordingly. When the user clicks the "Filter" button, the ViewModel layer's applyFilter() method is called. This action triggers the ViewModel layer to reprocess the product data, filter products based on the user-set filter criteria (such as price range, product category, etc.), and update the displayGoods data. Because displayGoods is marked with @Observed, data changes are automatically notified to the View layer. Upon receiving the notification, the View layer automatically re-renders the product list to display products that meet the filter criteria, enabling real-time interaction between user actions and data display.

[0131] Example 1 can achieve the following data flow:

[0132] The user clicks the "Men's Clothing" button → triggers goodsVM.loadGoodsByCategory("Men's Clothing");

[0133] ViewModel calls the Model layer to obtain data and filter → update displayGoods (@Observed tag);

[0134] The View layer List component detects data changes → automatically re-renders the men's clothing product list without the need for additional code updates.

[0135] Example 2: Cross-device shopping cart synchronization

[0136] The cross-device shopping cart synchronization function is realized based on the technical solution of the present invention, aiming to solve the problem that shopping cart data cannot be synchronized in real time when users switch between different Harmony devices (such as mobile phones, tablets, PCs), and provide users with a seamless shopping experience.

[0137] Global state management: The app uses the @AppStorage decorator to mark and manage shopping cart data. @AppStorage sets shopping cart data as global state, meaning that this data is no longer limited to a single page or component but can be shared across all pages of the entire app and across different devices. Shopping cart data includes information about the items selected by the user, such as item number, name, quantity, price, and other details, as well as related promotional information and special offers. Once this data is centrally managed, it forms a centralized data source accessible across multiple devices.

[0138] Data synchronization mechanism: When a user adds an item to their shopping cart on their phone, this action triggers the corresponding business logic. First, the mobile app organizes the information about the added item, and then uses HarmonyOS's distributed soft bus technology to transmit the changes to the shopping cart data. HarmonyOS's distributed soft bus is an underlying technology for data communication between devices. It establishes efficient and stable connections between different devices, ensuring accurate data transmission.

[0139] Exemplarily, cross-device data synchronization specifically includes:

[0140] Distributed Data Service (DDS) registration; when initializing the shopping cart data in the ViewModel layer, call the Hongmeng distributed data service interface, register the distributed data object, associate the global shopping cart state, and use the cart_key parameter value to uniquely identify the key of the shopping cart data for cross-device identification. Initial shopping cart data (such as an empty array) initialCartData;

[0141] Data change synchronization: When a user operation (such as adding a product) triggers a change in the shopping cart data, the DDS synchronization interface is called to update the data. The local data is updated through the setData() operation, and the cross-device data synchronization is triggered through the syncData() operation to synchronize the data to other devices.

[0142] Cross-device monitoring and response; register data change listeners in the ViewModel layer of other devices (such as tablets and PCs). When the data on the mobile phone changes, other devices obtain the latest data in real time through the listener. Taking the addition of products as mentioned above as an example, on the one hand, the local shopping cart data is updated, and on the other hand, the UI is triggered to automatically update; that is: when tablets, PCs and other devices are in the same HarmonyOS ecosystem and are connected to mobile devices, these devices will receive shopping cart data change notifications from the mobile phone. After receiving the notification, the Tongfu Cloud Commerce application on the device will immediately obtain the latest shopping cart data and update the locally stored shopping cart information. During the update process, the application will strictly check the integrity and accuracy of the data to avoid data loss or errors.

[0143] Automatic UI Updates: As shopping cart data is updated synchronously across devices, the View layer of each device automatically detects data changes. This is because the shopping cart data is marked with the @Observed decorator in the ViewModel layer. Once the data changes, the HarmonyOS responsive data bus will notify all components subscribed to the data, namely the View layer.

[0144] In the View layer, the application uses @ObjectLink to establish a weak reference to the shopping cart data object in the ViewModel layer. Data is bound via expressions in the UI template, such as displaying the product list and total price on the shopping cart page. When data changes, the framework automatically redraws the affected component nodes. For example, the shopping cart icon's badge updates in real time to display the number of items in the cart; the shopping cart page re-renders to display the latest product list and total price, allowing users to see the latest status of the shopping cart in real time across different devices without having to manually refresh the page.

[0145] In cross-device shopping cart synchronization scenarios, shopping cart data, as core business data, is treated just like data retrieved from the Model layer. Applications on different devices (mobile phones, tablets, and PCs) can access and manipulate shopping cart data through dependency injection. Furthermore, this data, originating from different devices, is centrally managed. Similar to converting heterogeneous data sources into unified entity objects, shopping cart data is processed across devices using a unified format and rules, ensuring data consistency and accuracy.

[0146] In a shopping cart synchronization scenario, when a user performs actions on the shopping cart on a device (such as adding or removing items), the ViewModel layer executes business logic based on these actions. For example, calculating the total price of items or processing promotions. Just like filtering items based on user preferences and calculating promotional prices, data processing is performed based on shopping cart actions, and this processing logic is independent of the UI, making it easier to unit test.

[0147] Use the @Observed decorator to mark the shopping cart data variable. When the shopping cart data changes (such as the number of items changing or items being removed), the framework automatically triggers the HarmonyOS responsive data bus to notify subscribers. In shopping cart synchronization, subscribers are the UI components on each device, and data changes are notified to them so that they can update the display.

[0148] In the shopping cart synchronization scenario, the shopping cart UI components (such as the shopping cart list and total price display) on each device establish weak references to the shopping cart data object in the ViewModel layer through @ObjectLink to avoid memory leaks caused by strong references. This way, the UI components can obtain the latest shopping cart data.

[0149] By using expressions in the UI template to bind data, such as displaying product name, quantity, total price, etc. When the shopping cart data changes due to user operations or synchronization between devices, the framework automatically redraws the affected component nodes, allowing the UI to reflect the latest status of the shopping cart in real time.

[0150] In cross-device shopping cart synchronization, shopping cart data is global state, managed using @AppStorage. Shopping cart data across different devices is shared through @AppStorage. When shopping cart data on one device is updated, other devices can immediately access the latest data, achieving cross-device data synchronization, just like cross-page data sharing, except that this spans different physical devices.

[0151] In the shopping cart synchronization scenario, operations such as clicks (such as adding items, deleting items) and swipes (such as viewing more items) performed by users on the device on the shopping cart will be mapped to corresponding method calls in the ViewModel layer. For example, the addItemToCart() method is called when adding items, and the removeItemFromCart() method is called when deleting items. By changing the ViewModel data, UI updates are indirectly triggered to ensure that user operations can be reflected in the shopping cart interface in a timely manner.

[0152] As described above, the interaction of this embodiment implements the following processing flow: user operation → update @AppStorage global status → trigger DDS synchronization → other devices monitor data changes → update local @AppStorage → automatically refresh UI.

[0153] The contents not described in detail in this specification belong to the prior art known to those skilled in the art.

[0154] The above description is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiment. Any equivalent modifications or changes made by those skilled in the art based on the contents disclosed in the present invention should be included in the protection scope recorded in the claims.

Claims

1. A layered data-driven application development method based on the Hongmeng framework decorator, characterized by: Based on the Model-ViewModel-View three-tier architecture, data-driven automatic state management is implemented through the Hongmeng decorator. The core processes include: In the Model layer, the server and local data are processed uniformly and standardized entity objects are output; In the ViewModel layer, encapsulate business logic and notify the View layer of processed data changes through decorators; In the View layer, focus on UI display, monitor data changes through decorators and automatically update the interface.

2. The layered data-driven application development method based on the Hongmeng framework decorator according to claim 1 is characterized in that: Through Model layer data preprocessing, heterogeneous data sources are converted into unified entity objects, providing standardized data interfaces; The heterogeneous data sources include server API and local Room database.

3. The layered data-driven application development method based on the Hongmeng framework decorator according to claim 2 is characterized in that: The data preprocessing steps on the server-side API include: Call the server API through the Hongmeng network module to obtain raw data; Use a data parser to map raw data into entity classes, including field validation logic; The parsed data is subjected to business preprocessing to generate pure business data objects; the business preprocessing includes deduplication of product list data and filtering of sensitive information.

4. The layered data-driven application development method based on the Hongmeng framework decorator according to claim 2 is characterized in that: The data preprocessing steps in the local Room database include: Use the Hongmeng Room database to operate local storage and define data access objects (DAOs) to implement additions, deletions, modifications, and queries. Use the @LocalStorage decorator to mark the local state that needs to be persisted, and combine it with the HarmonyOS distributed data service DDS to achieve cross-device data synchronization.

5. The layered data-driven application development method based on the Hongmeng framework decorator according to claim 1 is characterized in that: Isolate UI dependencies through ViewModel layer business logic processing, handle complex business logic, and expose observable data through decorators.

6. The layered data-driven application development method based on the Hongmeng framework decorator according to claim 5 is characterized in that: The ViewModel layer includes the following data acquisition and processing steps: Obtain the Model layer data interface through dependency injection and define business methods; Call the Model layer to obtain pre-processed data, perform logical processing, and generate final business data; When data changes, the ViewModel layer includes the following notification steps: Use the @Observed decorator to mark business data variables. When the data changes, the Hongmeng responsive data bus will be automatically triggered to notify subscribers. It is prohibited to directly operate UI components in the ViewModel layer to ensure that the business logic can be independently unit tested.

7. The layered data-driven application development method based on the Hongmeng framework decorator according to claim 6 is characterized in that: At the ViewModel layer, data acquisition and processing specifically include: Define the data interface in the Model layer; Inject the implementation class through the dependency injection framework in the ViewModel layer; Replace real dependencies with mock objects.

8. The layered data-driven application development method based on the Hongmeng framework decorator according to claim 1 is characterized in that: In the View layer, data changes are monitored through decorators to achieve declarative UI rendering and event-driven interaction.

9. The layered data-driven application development method based on the Hongmeng framework decorator according to claim 8 is characterized in that: The declarative UI rendering and event-driven interaction includes the following data binding and rendering steps: Use @ObjectLink in UI components to establish weak references to ViewModel layer objects to avoid memory leaks caused by strong references; Declare the local state of the component through @State, use expressions to bind data in the UI template, and when the @Observed data changes, the framework automatically redraws the affected component nodes.

10. The layered data-driven application development method based on the Hongmeng framework decorator according to claim 8 is characterized in that: The declarative UI rendering and event-driven interaction includes the following user interaction processing steps: Map user operations to ViewModel layer method calls, and indirectly trigger UI updates by changing ViewModel data; Use @AppStorage to manage global state and share data across pages.

Images