CN118276856B - Application state management method and device, electronic equipment and storage medium - Google Patents

Abstract

The disclosure provides an application state management method, a component library, electronic equipment and a storage medium, and belongs to the technical field of software development. The application state management method comprises the following steps: acquiring an application state, wherein the application state can only trigger updating through an event; creating one or more of the events, defining the type of the event and processing logic; responding to the operation of a user in the view, and executing the event triggered by the operation; updating the application state and rendering the interface of the view. In the technical scheme, the application state can be updated only through the event, so that the sharing and variation of the application state can be avoided, and the safety and testability of the application state are improved; responding to user operation in the view by defining an event; updating the application state through the execution of the event, and rendering the interface of the view. The method has higher execution efficiency and simpler development flow.

Description

Application state management method, device, electronic device and storage medium

Technical Field

The present disclosure relates to the field of software development technology, and in particular to an application state management method, device, electronic device and storage medium.

Background Art

As the complexity of mobile and desktop applications increases, the need for application state management also grows. Application state management, as a programming paradigm, allows developers to more easily manage the state of the application, that is, the data and interface of the application. The purpose of application state management is to make the changes of application state more predictable, easier to track, and easier to test and debug.

Existing technologies such as Vuex, Redux, SwiftUI, Combine, etc. provide powerful tools for application state management and responsive programming, but they also have some limitations:

First, language and system version restrictions. SwiftUI and Combine are designed for the Swift language and newer Apple operating system versions, which limits their application in older versions of the system or non-Swift environments. This means that developers may not be able to use these tools when cross-platform or supporting older versions of the system;

Second, the complexity of state management. Vuex and Redux provide the ability to centrally manage state, but in large applications, the state tree may become large and complex, increasing the difficulty of maintaining and tracking state changes. This complexity may cause developers to have difficulties in understanding and maintaining state logic;

Third, template code and boilerplate code: When using libraries such as Vuex and Redux, developers often need to write a lot of template code and boilerplate code, which not only increases development time, but also may lead to code redundancy and difficulty in maintenance;

Fourth, performance limitations. Libraries such as Vuex and Redux may encounter performance bottlenecks when processing large amounts of data or high-frequency updates, because each state update needs to pass through the entire state tree, which may lead to unnecessary rendering and performance degradation.

In short, existing application state management frameworks or libraries are often too complex, making it challenging for developers to understand and maintain the code.

Summary of the invention

The present disclosure provides an application state management method, device, electronic device and storage medium to solve the technical problems of low state management efficiency and complex development process in the prior art.

The present disclosure provides this invention summary section to introduce concepts in a brief form, which will be described in detail in the detailed implementation section below. This invention summary section is not intended to identify the key features or essential features of the technical solution claimed for protection, nor is it intended to be used to limit the scope of the technical solution claimed for protection.

In order to solve the above technical problems, the present disclosure provides an application state management method, including:

Get the application status, where the application status can only be updated by events;

Create one or more events, and define the type and processing logic of the events;

In response to the user's operation in the view, executing the event triggered by the operation;

Update the application state and render the interface of the view.

In order to solve the above technical problems, the present disclosure further provides an application state management device, the application state management device comprising:

Event dispatcher, used to respond to user operations in the view and trigger corresponding events;

A state mutator, used to receive the event and update the application state;

A renderer is used to render the interface of the view according to the updated application state.

In order to solve the above technical problems, the present disclosure also provides an electronic device, which adopts the following technical solution, including: a second memory and a processor, wherein the second memory stores a computer program, and the processor implements the above method when executing the computer program.

In order to solve the above technical problems, the present disclosure also provides a computer-readable storage medium, which adopts the following technical solution, including: a computer program is stored on the computer-readable storage medium, and the computer program implements the above method when executed by a processor.

The positive and progressive effects of this disclosure:

In the technical solution disclosed in the present invention, the application state can only be updated by triggering events, which can avoid the sharing and mutation of the application state and improve the security and testability of the application state; by defining events, respond to the user's operations in the view; update the application state through the execution of events, and render the interface of the view according to the changes in the application state. The application state management method disclosed in the present invention has high execution efficiency and simple development process.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a flow chart of an application state management method provided by an embodiment of the present disclosure;

FIG2 is a schematic diagram of an application state management device provided by an embodiment of the present disclosure;

FIG. 3 is a schematic diagram of an electronic device provided according to an embodiment of the present disclosure.

The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that components and elements are not necessarily drawn to scale.

DETAILED DESCRIPTION

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which the present disclosure belongs; the terms used in the specification of the application herein are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure; the term "including" and any corresponding variations in the specification and claims of the present disclosure and the above-mentioned drawings are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of the present disclosure or the above-mentioned drawings are used to distinguish different objects, not to describe a specific order.

Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present disclosure. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

In order to enable those skilled in the art to better understand the technical solution of the present disclosure, the technical solution in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings.

The following introduces the first aspect of the embodiment of the present disclosure: an application state management method.

Fig. 1 is a flow chart of an application state management method provided by an embodiment of the present disclosure. As shown in Fig. 1, the application state management method includes steps S101-S104.

S101, obtaining application status, wherein the application status can only be updated by triggering an event.

It should be noted here that the embodiment of the present disclosure is that the application state represents the data state of the application at a certain moment. Application state management refers to the management method of application state (data) in software development, including the storage, update and monitoring of application state. The application state can be a structure, a class, an enumeration, or a basic type, etc. The application state follows value semantics, that is, a new application state should be returned after each update instead of modifying the original application state, and the application state can only be updated through events. In this way, the sharing and mutation of the application state can be avoided, and the security and testability of the application state can be improved. That is, the application state in this embodiment is designed to be read-only, and any change in the application state is triggered by an event to update, which ensures the immutability and functional update of the application state.

S102: Create one or more events, and define the type and processing logic of the events.

The embodiments of the present disclosure need to explain that an event is a type that complies with the event protocol, which can be a structure, a class, an enumeration, or a closure. Events can be divided into two types, namely events that update the application state and events that perform operations. Events that update the application state are only used to update the application state and do not perform any other operations. Events that perform operations can perform some asynchronous or synchronous operations and then update the application state.

S103: In response to the user's operation in the view, execute the event triggered by the operation.

It should be noted here that the embodiment of the present disclosure is that the user inputs an operation in the view, such as clicking a button or editing text in an input box, triggers a corresponding event, and returns to a new application state by processing the event.

S104, updating the application state and rendering the interface of the view.

The embodiment of the present disclosure needs to explain that after the application state is updated, the updated application state needs to be fed back to the user through the view. Using the view rendering technology to render dynamic data to the view interface can provide users with a more intuitive response result.

Further, in some embodiments of the present disclosure, creating one or more events in the execution step and defining the type and processing logic of the event may be implemented by, but not limited to, the following methods, including:

defining a first type of event for receiving the application state and returning an updated application state; and/or,

A second type of event is defined to receive the application state, perform additional processing, and return the updated application state.

The embodiments of the present disclosure need to explain that the first type of event can be implemented by an event mutator, which can be a pure function for receiving the current application state and returning a new application state. The second type of event can be implemented by an event actor, which can be a side effect function for receiving the current application state and a reference to a memory and performing some additional operations, such as calling an API, sending a notification, storing data, etc.

Furthermore, in some embodiments of the present disclosure, the application state management method further includes:

In response to the operation of the user in the view, triggering middleware corresponding to the operation;

The middleware receives the application state and the event triggered by the operation, and cooperates to implement the update of the application state.

The embodiments of the present disclosure need to be explained here that middleware refers to additional processing logic inserted in the processing data flow or event flow. Middleware can be set as an optional function for receiving the current application state and event as parameters and returning a new application state. Middleware allows additional processing logic to be inserted in the processing data or event flow without modifying the main processing logic. In application state management, middleware is usually used to perform some additional operations such as logging, error handling, asynchronous operations, etc. during the application state change process. For example, when creating a logging middleware, a loggingMiddleware function can be defined, which receives two parameters: the current application state and the event that occurred. Its function is to print out relevant information before the application state changes, and then return the new application state. This middleware does not change the application state, but only adds the logging function. In actual use, the middleware will be inserted into the appropriate position in the application state management process. For example, in a state management library such as Redux, the middleware will be called between dispatching events and executing state changers. Thus, whenever an event is dispatched, the middleware has the opportunity to execute its logic before the application state is updated. In addition, the advantages of middleware are pluggability and composability. Developers can choose to add or remove middleware as needed, or combine multiple middleware together to enhance the functionality of the application. This model improves the maintainability and scalability of the code while keeping the core logic simple.

Further, in some embodiments of the present disclosure, when updating the application state and rendering the interface of the view in the execution step, it can be implemented by but not limited to the following methods, including:

The application state is bidirectionally bound to the view to perform automatic update between the application state and the view.

The embodiments of the present disclosure need to be explained here that the two-way binding and automatic update of the application state and view can improve the responsiveness and user experience of the application. In addition, in some embodiments, an observable object can also be set. In responsive programming, an observable object can be subscribed to so as to notify the subscriber when the application state changes.

Specifically, in order to achieve two-way binding and automatic update of application state and view, responsive components can be introduced to enable the view to automatically respond to changes in application state, thereby achieving responsive updates between application state and view. The main features of responsive components include: first, automatic synchronization, when the value of a state object (such as SVObservable) changes, all UI components bound to the state will be automatically updated without manually calling the update function; second, two-way binding, that is, not only will the UI components respond to changes in application state, but the user's operations on the UI components can also update the application state in turn; third, decoupling, the application state management logic is separated from the UI logic, making the code clearer and easier to maintain. The component structure of responsive components, for example, SVReactive and SVObservable. Among them, SVReactive is a generic structure that provides responsive extension capabilities for any object. It contains a base object and allows developers to define responsive properties related to the object; SVObservable is a core class used to create observable state objects, which allows observers to subscribe to application state changes and notify all subscribers when the application state is updated. The advantages of using responsive components include at least: first, responsive programming, which simplifies the synchronization process from state to UI and improves development efficiency; second, generic design, which allows components to be flexibly used for different types of application state management, enhancing the versatility of components; third, protocol compliance, which ensures the consistency and predictability of application states and events by following specific protocols.

The following is an explanation of some of the working principles of responsive components.

First, the responsive principle of data flow. Responsive programming is a programming paradigm oriented towards data flow and change propagation. In this paradigm, data is regarded as a stream that changes over time, and the purpose of responsive components is to monitor and respond to these data streams. When the data in the data stream changes, all operations that depend on this data are automatically executed, thereby updating the application status and UI.

Second, the core of SVObservable. The SVObservable class is the core of the responsive component, which encapsulates the current value of the application state and provides a subscription mechanism. Developers can create an SVObservable instance to represent a state in the application, and then subscribe to this instance to monitor changes in the application state.

Third, the subscription and notification mechanism. When the value property of SVObservable is set to a new value, it triggers a notification process, which traverses all subscribers and calls their update functions. In this way, any UI component bound to this SVObservable will receive notifications of application state changes and automatically update.

Fourth, bind to UI components. By extending UI components such as UILabel or UIButton, responsive components allow SVObservable to be directly bound to the properties of these components. In this way, when the value of SVObservable changes, the bound UI component will automatically update its display content. When two-way binding is supported, not only will the UI component respond to changes in the application state, but the user's operations on the UI component can also in turn update the application state. This method is applicable to scenarios such as form input and real-time data display, but it is not limited to this.

In one or more embodiments, for example, through a microservice architecture, each service is responsible for the state management of a specific part of the application, and an event bus is used to transmit state updates to achieve asynchronous state updates and reduce performance bottlenecks. First, identify the different parts of the application and create a microservice for each part, each microservice has its own scope of responsibility and state management logic; define an event for each type of state change that may occur in the system, where the event should contain all the necessary information so that other services can understand and respond; select a suitable event bus technology and configure the event bus to support high throughput and reliable messaging; microservices should not call each other directly, but should publish and subscribe to events through the event bus. When a service needs to update the state, it publishes an event to the event bus; each microservice should have an event processor to listen to events on the event bus. When the event processor receives an event, it updates the local state according to the type and content of the event; state synchronization between microservices should be completed through events. When the state of a service is updated, an event is published to notify other services; event processing should usually be asynchronous, which can avoid blocking operations and reduce delays. Asynchronous processing also helps improve the overall performance and scalability of the system.

In one or more embodiments, for example, by implementing a state snapshot function, developers are allowed to capture the application state at any point in time, and by developing a time travel debugging tool, developers are able to trace back to the history of state changes for easier tracking and debugging. In the application's state management system, a snapshot service is introduced to capture and store the complete state of the application at any given point in time. Here, the snapshot, for example, contains all legal relevant state information within all permissions, such as user data, application settings, UI status, etc.; by providing an API or interface, developers are allowed to manually or automatically create state snapshots, and through the time travel debugging tool, developers can browse and load previously created state snapshots. The tool provides a user-friendly interface that displays the timeline and details of state changes. By selecting a specific snapshot, the application will be restored to the state at that point in time for debugging; the state snapshot and time travel debugging functions are integrated into the development environment. During the development process, developers can create snapshots at any time and use the time travel debugging tool when problems arise.

In one or more embodiments, for example, a declarative programming paradigm is used to define the relationship between states and views, so that changes in states are automatically reflected in views, and a state binding library is developed to allow developers to bind application states to view components in a declarative manner. Here, in declarative programming, it is only necessary to describe how the application state and interface should be displayed based on these states, without specifying how to convert from one state to another. Changes in state are automatically reflected in the view because the view is a direct mapping of the state; by creating a library, a set of APIs are provided to allow developers to declare state variables and bind them to view components; here, any changes in state variables should automatically trigger updates to the view; it is also necessary to ensure that the library can handle responsive updates of components. When the state changes, only components that depend on these states will be updated to avoid unnecessary rendering.

The second aspect of the embodiment of the present disclosure is introduced below: an application state management device.

FIG2 is a schematic diagram of an application state management device provided by an embodiment of the present disclosure. As shown in FIG2 , the application state management device is set in the first memory 200, and the application state management device includes:

An event dispatcher 202 is used to respond to a user's operation in the view 201 and trigger a corresponding event 205;

A state changer 206, configured to receive the event 205 and update the application state 208;

The renderer 209 is used to render the interface of the view 201 according to the updated application state 208 .

It should be noted here that in the embodiment of the present disclosure, in state management, the first storage 200 is a container for centrally managing the application state 208, which can ensure the consistency and traceability of the application state 208. The first storage 200 is a generic class that can accept two types of parameters, namely the application state 208 and the event 205. The first storage 200 operates by calling the event distributor 202, which can receive the event 205 and the like as parameters, and then calls the state mutator 206. Among them, the state mutator 206 is an optional function for receiving the current application state 208 and the event 205 as parameters, and returning a new application state 208. The state mutator 206 can be used to implement some common state change logic, such as merging, filtering, sorting, etc. The state mutator 206 can provide consistent and predictable logic when the application state 208 changes, which helps to simplify the state management logic and make it easier to understand and maintain. After executing event 205, the updated application state 208 is returned, and the renderer 209 is called to update the interface of view 201 according to the updated application state 208. Among them, renderer 209 is an optional function for receiving the current application state 208 and event 205 as parameters, and updating the interface display of view 201 according to the change of application state 208. Renderer 209 can use any view framework or library, such as UIKit, SwiftUI, React Native, etc., to implement interface rendering. The workflow of the application state management device disclosed in the present invention ensures that the data flow is unidirectional, from view 201 to the first memory 200, and then updated back to view 201 through the application state 208, forming an overall closed loop. This mode helps to maintain the consistency of application state 208, facilitates developers to understand and track changes in application state 208, and also facilitates testing and debugging of the application state management device. Furthermore, the renderer 209 and the state mutator 206 in this embodiment are designed to allow developers to describe the changes of the application state 208 and the updates of the view 201 in a declarative manner. In addition, the application state management device provided in this embodiment is an independent device, which is conducive to enhancing the portability of the code and the applicability in different environments.

Furthermore, in some embodiments of the present disclosure, the application state management device further includes:

An event mutator 204, configured to receive the application state 208 and return the updated application state 208;

The event actor 203 is used to receive the application state 208 , perform additional processing, and return the updated application state 208 .

It should be noted here that the embodiment of the present disclosure is that the event mutator 204 can be a pure function, which is used to receive the current application state 208 and return a new application state 208. The event actor 203 can be a side effect function, which is used to receive the current application state 208 and a reference to the first memory 200, and perform some additional operations, such as calling an API, sending a notification, storing data, etc.

Furthermore, in some embodiments of the present disclosure, the application state management device further includes:

The middleware 207 is used to receive the application state 208 and the event 205 triggered by the operation, and cooperate to implement the update of the application state 208.

The embodiment of the present disclosure needs to be explained here that the middleware 207 allows the insertion of additional processing logic in the process of processing data or event 205 in the software architecture without modifying the main processing logic. The middleware 207 is an optional function for receiving the current application state 208 and event 205 as parameters and returning a new application state 208. The middleware 207 can be used to implement some additional functions, such as logging, caching, asynchronous operations, etc. In actual use, the middleware 207 will be inserted into the appropriate position in the state management process. For example, in the state management device, the middleware 207 will be called between the dispatch event 205 and the execution state changer 206, so that whenever an event 205 is dispatched, the middleware 207 has the opportunity to execute its logic before the state is updated. The advantage of the middleware 207 is its pluggability and composability. Developers can choose to add or remove the middleware 207 as needed, or combine multiple middleware 207 together to enhance the functionality of the application. This pattern improves code maintainability and extensibility while keeping the core logic concise.

Furthermore, in some embodiments of the present disclosure, the application state management device further includes:

A responsive component is used to bidirectionally bind the application state 208 to the view 201 to perform automatic update between the application state 208 and the view 201.

It should be noted here that the embodiments of the present disclosure allow UI components (e.g., UILabel and UIButton) to automatically respond to changes in the application state 208. By binding a state object (e.g., SVObservable) to a UI component, a developer can implement two-way binding and automatic updating of the application state 208 and the view 201, thereby improving the responsiveness and user experience of the application.

The application state management device disclosed in the present invention allows developers to conveniently manage the application state 208, update the application state 208 in an event 205 driven manner, and use middleware 207 to add additional functions. The application state management device is highly reusable and flexible, and can adapt to different application scenarios and requirements. The application state management device adopts an application state management mode of unidirectional data flow, which can ensure that the changes of the application state 208 are controllable, traceable, testable, and debuggable. In addition, the application state management device can use the syntax specification of Swift, and use protocols and generics to improve the reusability and flexibility of the code.

The design concept of the application state management device of the embodiment of the present disclosure can be briefly summarized as follows: first, a single data source, that is, the entire application state 208 is stored in a single first memory 200, which ensures the consistency and predictability of the application state 208; second, the application state 208 is read-only, that is, the application state 208, as immutable data, can only be requested to be updated through events 205, and cannot be directly modified; third, the state mutator 206, event 205, and middleware 207 perform updates, that is, the update of the application state 208 is completed by the state mutator 206 triggered by event 205, and the middleware 207 provides an extension point to enhance or modify this process.

In addition, the advantages of the application state management device of the embodiment of the present disclosure include at least the following aspects: First, predictability. Since all updates of the application state 208 are processed by the state mutator 206, the changes of the application state 208 are predictable, which is convenient for debugging and testing; Second, modularity. The design of the first memory 200, the application state 208 and the event 205 makes the code easy to modularize, which is convenient for separating concerns and improving the maintainability of the code; Third, the flexibility of the middleware 207. The middleware 207 can be used not only for logging, asynchronous operations, etc., but also for implementing complex functions such as undo or redo; Fourth, responsive binding. By binding the application state 208 to the view 201, the responsive update of the application state 208 can be realized. When the application state 208 changes, the view 201 can be automatically updated.

Below, the specific application of the application state management device disclosed in the present invention is illustrated by example. For example, a counter application is implemented through the application state management device, which can increase, decrease, and reset the value of the counter. First, a structure representing the application state 208 of the counter is defined, which follows the value semantics and implements the Equatable protocol to facilitate the comparison of changes in the application state 208. Then, an enumeration of events 205 representing the counter is defined, which follows the event protocol, implements the type and behavior of the event 205, and how to modify the application state 208 according to the event 205. The enumeration contains three types of events 205, which are to increase, decrease, and reset the value of the counter. Each event 205 defines an event mutator 204 for receiving the current application state 208 and returning a new application state 208. Each event 205 also defines an event actor 203 for receiving the current application state 208 and a reference to the first memory 200, and performing some additional operations, such as printing logs, sending notifications, etc. Finally, an instance of the first storage 200 is created, the initial application state 208 is passed in, a renderer 209 is defined to update the interface of the view 201, and a state mutator 206 is defined to handle the change of the application state 208. In the view 201, according to the user's interaction, the corresponding event 205 is triggered, and the event dispatcher 202 in the first storage 200 is called to update the application state 208 and the interface of the view 201.

In the creation and execution process of the application state management device of the embodiment of the present disclosure, the initialization of the first memory 200 is a preparatory step, which involves setting the initial state and configuring the state management environment. Although this step must be performed when the application is started, it is not required to be performed every time the state changes. The setting of the middleware 207 is an auxiliary step used to enhance the function of application state management, such as adding logging or asynchronous processing, which are usually configured when the application is initialized and are not limited to the core steps of data processing. Defining the logic of how to update the application state 208 according to the event 205 is a preparatory step, which ensures the consistency and predictability of the state change. This logic is defined in the application development phase and called at runtime. The declarative update of binding the application state 208 to the UI can be an auxiliary step to ensure that the UI can respond to the change of the application state 208. This step is performed when the component is created, not in each data processing. Implementing the event protocol and defining how the event 205 triggers the change of the application state 208 can be a preparatory step, which provides rules and logic for the change of the application state 208. The testing of application state 208 and event 205 is a post-processing step to ensure the correctness and stability of the application state management logic. It is usually performed during the development process and before the application is released, rather than during the actual data processing process. This is to discover and fix potential problems before the application is released to ensure the quality of the application. Although these steps are crucial to the establishment and maintenance of the entire state management system, they are not steps that need to be performed every time the application state changes or data is processed. On the contrary, these steps provide the necessary support and infrastructure for application state management to ensure that the core data processing process can proceed smoothly.

The third and fourth aspects of the embodiments of the present disclosure are introduced below: an electronic device and a computer-readable storage medium.

The electronic device includes a second memory and a processor, wherein the second memory stores a computer program, and the processor implements the above-mentioned application state management method when executing the computer program.

A computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the above-mentioned application state management method when executed by a processor.

As shown in Figure 3, it shows a schematic diagram of an electronic device suitable for implementing the embodiment of the present disclosure. The electronic device in the embodiment of the present disclosure is only an example and should not bring any limitation to the function and scope of use of the embodiment of the present disclosure.

3 , the electronic device includes a processing device 301 , a storage device 302 , a sensor device 303 , a bus 304 , an input/output (I/O) interface 305 , a multimedia device 306 , a power supply device 307 , a communication device 308 , and the like.

The processing device 301 (e.g., a central processing unit, a graphics processing unit, etc.) is used to control the overall operation of the electronic device. The processing device 301 may include one or more processors to execute instructions to complete all or part of the steps of the above method. In addition, the processing device 301 may also include one or more modules for processing and interacting with other devices.

The storage device 302 is used to store various types of data. The storage device 302 may include various types of computer-readable storage media or a combination thereof, such as an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above.

Among them, more specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

The sensor device 303 is used to sense the specified measured information and convert it into a usable output signal according to a certain rule, and may include one or more sensors. For example, it may include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor or a temperature sensor, etc., for detecting changes in the opening/closing state, relative positioning, acceleration/deceleration, temperature, humidity and light of the electronic device.

The processing device 301 , the storage device 302 , and the sensor device 303 are connected to each other via a bus 304 . An input/output (I/O) interface 305 is also connected to the bus 304 .

The multimedia device 306 may include input devices such as a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, etc. for receiving input signals from a user. The various input devices may cooperate with various sensors of the above-mentioned sensor devices to complete, for example, gesture operation input, image recognition input, distance detection input, etc. The multimedia device may also include output devices such as a liquid crystal display (LCD), a speaker, a vibrator, etc.

The power supply device 307 is used to provide power to various devices in the electronic device, and may include a power management system, one or more power supplies, and components for distributing power to other devices.

The communication device 308 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data.

The above-mentioned devices can also be connected to the I/O interface 305 to realize the application of the electronic device.

Although the electronic device with various devices is shown in the figure, it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device. When the computer program is executed by a processing device, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

In the context of the present disclosure, a machine-readable medium may be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in combination with an instruction execution system, device, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

The computer-readable medium may be included in the electronic device, or may exist independently without being installed in the electronic device.

Further, computer program code for performing the operations of the present disclosure may be written in one or more programming languages or combinations thereof, including but not limited to object-oriented programming languages, such as Java, Python, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network, or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and/or flow chart, and the combination of the square boxes in the block diagram and/or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

The units involved in the embodiments described in the present disclosure may be implemented by software or hardware, wherein the name of a unit does not, in some cases, constitute a limitation on the unit itself.

The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chip (SOCs), complex programmable logic devices (CPLDs), and the like.

Below, the features of the above-mentioned embodiments according to the present disclosure are briefly summarized and listed.

According to one or more embodiments of the present disclosure, a method for managing application status is provided, which adopts the following technical solution, including:

Get the application status, where the application status can only be updated by events;

Create one or more events, and define the type and processing logic of the events;

In response to the user's operation in the view, executing the event triggered by the operation;

Update the application state and render the interface of the view.

According to one or more embodiments of the present disclosure, a method for managing application status is provided, which adopts the following technical solution, wherein the step of creating one or more events and defining the type and processing logic of the events includes:

defining a first type of event for receiving the application state and returning an updated application state; and/or,

A second type of event is defined to receive the application state, perform additional processing, and return the updated application state.

According to one or more embodiments of the present disclosure, an application state management method is provided, which adopts the following technical solution, and the application state management method further includes:

In response to the operation of the user in the view, triggering middleware corresponding to the operation;

The middleware receives the application state and the event triggered by the operation, and cooperates to implement the update of the application state.

According to one or more embodiments of the present disclosure, a method for managing application status is provided, which adopts the following technical solution, wherein updating the application status and rendering the interface of the view include:

The application state is bidirectionally bound to the view to perform automatic update between the application state and the view.

According to one or more embodiments of the present disclosure, an application state management device is provided, which adopts the following technical solution, including:

Event dispatcher, used to respond to user operations in the view and trigger corresponding events;

A state mutator, used to receive the event and update the application state;

A renderer is used to render the interface of the view according to the updated application state.

According to one or more embodiments of the present disclosure, an application state management device is provided, which adopts the following technical solution, and the application state management device also includes:

An event mutator, configured to receive the application state and return the updated application state;

An event actor is used to receive the application state, perform additional processing, and return the updated application state.

According to one or more embodiments of the present disclosure, an application state management device is provided, which adopts the following technical solution, and the application state management device also includes:

The middleware is used to receive the application state and the event triggered by the operation, and cooperate to implement the update of the application state.

According to one or more embodiments of the present disclosure, an application state management device is provided, which adopts the following technical solution, and the application state management device also includes:

A responsive component is used to bidirectionally bind the application state to the view to perform automatic update between the application state and the view.

According to one or more embodiments of the present disclosure, an electronic device is provided, including a second memory and a processor, wherein a computer program is stored in the second memory, and the processor implements the aforementioned method when executing the computer program.

According to one or more embodiments of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method described above is implemented.

The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other.

In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

Although the subject matter has been described in language specific to structural features and/or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.

Claims (8)

1. An application state management method, comprising:

acquiring an application state, wherein the application state can only trigger updating through an event;

creating one or more of the events, defining the type of the event and processing logic;

Responding to the operation of a user in the view, and executing the event triggered by the operation;

updating the application state and rendering an interface of the view;

wherein said creating one or more of said events defines a type and processing logic of said event, comprising:

Defining a first type of event, wherein the first type of event is realized through an event changer, and the event changer is a pure function and is used for receiving the current application state and returning the updated application state; and/or the number of the groups of groups,

Defining a second class of events, wherein the second class of events are realized through an event behavioural device, the event behavioural device is a side effect function and is used for receiving the current application state and the reference of a memory, executing additional processing and returning the updated application state, and the additional processing comprises calling an API, sending a notification and storing data;

The application state management method further comprises the following steps:

Responding to the operation of the user in the view, and triggering middleware corresponding to the operation;

the middleware receives the application state and the event triggered by the operation and cooperates with the application state to update the application state;

Wherein said middleware means additional processing logic inserted in the processing data stream or event flow, said middleware being set as an optional function for receiving the current application state and said event as parameters, returning a new application state, said middleware allowing additional processing logic to be inserted in the processing data stream or event flow without modifying the main processing logic.

2. The method of claim 1, wherein the updating the application state and rendering the interface of the view comprises:

And binding the application state with the view in a bidirectional manner so as to automatically update the application state and the view.

3. An application state management device for implementing the method according to any of claims 1-2, the application state management device comprising:

the event distributor is used for responding to the operation of the user in the view and triggering the corresponding event;

the state changer is used for receiving the event and updating the application state;

and the renderer is used for rendering the interface of the view according to the updated application state.

4. The application state management device according to claim 3, characterized in that the application state management device further comprises:

The event changer is used for receiving the application state and returning the updated application state;

and the event behaviours are used for receiving the application state, executing additional processing and returning the updated application state.

5. The application state management device according to claim 3, characterized in that the application state management device further comprises:

and the middleware is used for receiving the application state and the event triggered by the operation and realizing the update of the application state in a matching way.

6. The application state management device according to claim 3, characterized in that the application state management device further comprises:

And the responsive component is used for bidirectionally binding the application state with the view so as to automatically update the application state and the view.

7. An electronic device comprising a second memory and a processor, the second memory having a computer program stored therein, the processor implementing the method of any of claims 1-2 when executing the computer program.

8. A computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements the method according to any of claims 1-2.