Annotating-based rich client window lifecycle management method and system

Abstract

The application discloses an annotation-based rich client window life cycle management method and system, and particularly relates to the technical field of desktop application development, which comprises the following steps: declaring window configuration attributes through a window definition annotation; obtaining a controller instance through a pluggable Bean factory interface; creating a scene and configuring window attributes by executing a method marked by an initialization annotation; reusing a singleton window through a cache, and automatically maintaining the owner relationship between windows through a window level stack; driving a display callback annotation and a method execution marked by a cleanup annotation through an event listener; and realizing safe switching of an interface thread. The application realizes complete coding of interface development and unified management of window life cycles, supports seamless adaptation of two environments of reflection and a dependency injection container, effectively avoids memory leakage, and improves development efficiency and system stability.

Description

Technical Field

[0001] This invention relates to the field of desktop application development technology, and more specifically, to a method and system for managing the lifecycle of rich client windows based on annotations. Background Technology

[0002] JavaFX is a mainstream rich client interface framework on the Java platform, widely used for developing cross-platform desktop applications. In the traditional JavaFX development model, the interface layout mainly relies on FXML files for declarative definition. The FXML Loader loads and parses the FXML files at runtime and binds them to the Controller class. Controller instantiation and dependency injection need to be managed manually or with the help of a third-party framework.

[0003] When enterprise desktop applications need to integrate the Spring framework to obtain capabilities such as dependency injection and transaction management, existing solutions have the following shortcomings: 1. The interface definition strongly depends on FXML files. The interface structure is separated from Java code. Development and maintenance require switching between the two types of files. FXML does not have the flow control and logical expression capabilities of programming languages. Complex interfaces have deep nesting of XML tags and poor readability. 2. The JavaFX Application lifecycle is managed by the JavaFX runtime, while the Spring ApplicationContext lifecycle is managed by Spring. There are conflicts in their startup order, thread model, and shutdown timing. Existing integration solutions either do not support all Spring features or have cumbersome integration configurations. 3. Lack of a unified window lifecycle management mechanism. Developers need to manually register event listeners for stages such as window initialization, refresh after display, and resource cleanup after closing, resulting in scattered code that is easy to overlook. 4. Lack of flexible control over window singleton caching and non-singleton creation; frequent opening and closing of windows leads to repeated instantiation, resulting in resource waste, or cached window resources are not released in time, leading to memory leaks. 5. The parent-child relationship and hierarchy maintenance of multiple windows need to be implemented manually, lacking a unified window hierarchy stack management; 6. The Bean Factory and window management are tightly coupled, making it impossible to switch the dependency injection implementation without modifying the window management code, resulting in poor environment adaptability.

[0004] To address the aforementioned shortcomings, this invention provides an annotation-based rich client window lifecycle management method and system. Summary of the Invention

[0005] To achieve the above objectives, the present invention provides the following technical solution: On the one hand, this invention provides an annotation-based rich client window lifecycle management method, including: S1. Declare the window's configuration properties through window definition annotations. The configuration properties should include at least the window size, window modal type, whether it is a singleton window, and whether to maintain a window hierarchy stack. S2. In response to the window creation command, the controller instance is obtained through a unified Bean factory interface. The Bean factory interface is a pluggable strategy interface with two modes: reflection Bean factory implementation and container Bean factory implementation. S3. After the controller instance is created, use reflection to find and execute the methods marked with initialization annotations in the controller, obtain the scene root node, create the scene based on the scene root node, and configure window properties and scene properties according to the window definition annotations. S4. Store the association between the controller and the window in the window-controller association cache. If the window definition annotation is configured as a singleton window, then store the association between the controller and the window in the controller-window cache. S5. If the window definition annotation is configured to maintain the window hierarchy stack, the window is pushed onto the window hierarchy stack, and the top window of the window hierarchy stack is set as the owner window of the window; if it is configured not to maintain the window hierarchy stack, the push and owner setting operations are skipped. S6. Register a window show event listener and a window hide event listener for the window. The window show event listener is used to execute the method marked with the show callback annotation in the controller after the window is shown. The window hide event listener is used to retrieve the set of controllers associated with the window from the window-controller association cache after the window is hidden, and execute the cleanup annotation annotation method of each controller in the set of controllers. S7. Remove the window from the window hierarchy stack and clear the record corresponding to the window in the window-controller association cache; S8. In response to the UI thread-safe execution instruction, automatically determine whether the current thread is the UI thread. If not, submit the task to the UI thread for execution through an asynchronous thread switching mechanism; if so, execute directly.

[0006] Preferably, in step S1, the configuration attributes of the window definition annotation also include one or more of the following: window title, minimum window size, maximum window size, whether it is stretchable, icon path, cascading style sheet path, window decoration style, whether it is the main window, and whether it is centered.

[0007] Preferably, in step S2, the reflection Bean factory is implemented for a non-dependency injection container environment. It uses reflection to find the constructor and recursively resolve the constructor parameter dependencies, and has a built-in circular dependency detection mechanism based on thread-local variables. The container bean factory implementation is used in dependency injection container environments to directly delegate bean retrieval methods to the dependency injection container.

[0008] Preferably, before step S2, in the dependency injection container environment, the initialization of the window management method is triggered by listening to the context refresh completion event of the dependency injection container. Specifically, this includes: listening to the context refresh completion event, determining whether the current context is the root context, and if so, obtaining the context of the dependency injection container, using the context's Bean acquisition method as the container Bean factory implementation of the Bean factory interface, and completing the global initialization of the window manager.

[0009] Preferably, in step S3, for a controller configured as a singleton window, the method for initializing annotations is executed only once; For controllers configured as non-singleton windows, the method for initializing annotations is executed every time a window is created.

[0010] Preferably, in step S5, if the window is the main window, the window hierarchy stack retains the main window but does not push it out of the stack. After step S7, there are also resource release steps when the program exits: clear the controller-window cache, window-controller association cache and window hierarchy stack, and if the current implementation uses a reflection Bean factory, clear the dependency resolution context of the reflection Bean factory.

[0011] Preferably, in step S6, when the window display event listener reuses the display in a singleton window, it also executes the display callback annotation method to refresh the window interface data. When a window is hidden, the window hide event listener first executes a method to clean up annotations, then removes the window from the window hierarchy stack, and finally removes the record corresponding to the window from the window-controller association cache.

[0012] Preferably, the method further includes the step of switching scenes within the same window: obtaining the target controller instance corresponding to the target scene, finding and executing the method marked with the display callback annotation in the target controller through reflection, switching the scene of the current window to the new scene corresponding to the target controller, and updating the controller record corresponding to the current window in the window-controller association cache.

[0013] On the other hand, the present invention also provides an annotation-based rich client window lifecycle management system for implementing the above method, including: The multi-level annotation configuration module provides window definition annotations, initialization annotations, display callback annotations, and cleanup annotations. Window definition annotations are used to declare the configuration properties of the window, initialization annotations are used to mark the initialization methods of the window scene content, display callback annotations are used to mark the callback methods after the window is displayed, and cleanup annotations are used to mark the resource cleanup methods after the window is closed. The pluggable Bean Factory abstract module provides a unified Bean Factory interface with two switchable modes: a reflection-based Bean Factory implementation and a container-based Bean Factory implementation. The core module for window management is used to respond to window creation commands, obtain controller instances through the pluggable Bean Factory abstract module, execute methods to initialize annotations to create scenes, configure window and scene attributes according to window definition annotations, manage controller-scene cache, window-controller association cache and controller-window cache, register window show event listeners and window hide event listeners, execute methods to display callback annotations after the window is shown, and execute methods to clean up annotations after the window is hidden. The window hierarchy stack management module is used to maintain a window hierarchy stack based on a double-ended queue, perform window push, window pop and query operations of the top window of the stack, and selectively set the top window of the stack as the owner window of the new window according to the configuration of the window definition annotation when a new window is created. The thread-safe task scheduling module is used to respond to UI thread-safe execution instructions, automatically determine whether the current thread is a UI thread, and submit the task to the UI thread for execution through an asynchronous switching mechanism when it is not a UI thread; The static tool facade module is used to encapsulate the functions of the core window management module, providing entry points for non-container environment startup, container environment startup, new window creation, scene navigation, and resource release. The container integration module is used to listen for the context refresh completion event of the external dependency injection container. When the context refresh is complete, it uses the container's Bean retrieval method as the container Bean factory implementation of the Bean factory interface to complete the global initialization of the window manager and triggers the release of global resources when the container is closed.

[0014] Preferably, when the window definition annotation is configured as the main window, the window hierarchy stack management module retains the main window from being pushed onto the stack; when the window definition annotation is configured not to maintain the window hierarchy stack, the module skips the push-on and owner setting operations.

[0015] The technical effects and advantages of this invention are as follows: 1. This invention declares window configuration attributes through window definition annotations, and marks the three stages of window initialization, refresh after display, and resource cleanup after closing through initialization annotations, display callback annotations, and cleanup annotations, respectively. Developers can complete the interface construction without writing any markup language files, and the interface structure and business logic are centralized in the same file. At the same time, the automatic execution of each lifecycle callback method is driven by a unified window display event listener and window hide event listener, eliminating the need to manually register event listeners, which significantly improves development efficiency and code maintainability. 2. This invention reuses windows configured as singletons by using window-controller associated caching and controller-window caching. Developers only need to control whether a window is in singleton or non-singleton mode through a single attribute of the window definition annotation, taking into account both memory optimization and data isolation requirements. At the same time, it automatically maintains window push and pop operations through the window hierarchy stack. When a new window is created, the top window of the stack is automatically set as the owner window, and when it is closed, it is automatically popped from the stack and the associated cache is cleared. There is no need to manually maintain the parent-child relationship of windows, avoiding memory leaks caused by reference residues.

[0016] 3. This invention abstracts controller instance creation into a pluggable strategy through a unified Bean Factory interface, featuring two switchable modes: reflection Bean Factory implementation and container Bean Factory implementation. The core window management code is completely decoupled from the underlying object creation mechanism, and switching the runtime environment only requires changing the Bean Factory implementation. At the same time, by automatically determining the current thread and switching to the UI thread when it is not a UI thread, it ensures that UI update operations are always executed in the correct thread context, avoiding runtime exceptions caused by cross-thread operations, and effectively ensuring the stability of system operation. Attached Figure Description

[0017] Figure 1 This is a system diagram of the present invention.

[0018] Figure 2 This is a flowchart of the method of the present invention.

[0019] Figure 3 This is a flowchart of the main window startup process of the present invention.

[0020] Figure 4 A flowchart for creating sub-windows in this invention.

[0021] The attached diagram is labeled as follows: 1. Multi-level annotation configuration module; 2. Pluggable Bean factory abstract module; 3. Window management core module; 4. Window hierarchy stack management module; 5. Thread-safe task scheduling module; 6. Static utility facade module; 7. Container integration module. Detailed Implementation

[0022] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0023] This application provides an annotation-based rich client window lifecycle management method and system, applicable to desktop rich client frameworks such as JavaFX and Swing, and also extensible to other UI frameworks with scene and window concepts. Its core concept lies in declaring window configuration and lifecycle callbacks through annotations, combined with a pluggable Bean factory abstraction, to achieve full lifecycle management of window creation, display, hiding, destruction, and resource cleanup. Simultaneously, a built-in thread safety mechanism ensures that all UI operations are executed on the correct thread.

[0024] To facilitate understanding of the technical solution of this application, the key terms are first defined and explained below: Window definition annotation: Annotation used to mark controller classes, which declare various configuration properties of the window corresponding to the controller, including but not limited to window size, modal type, whether it is a singleton window, and whether to maintain a window hierarchy stack.

[0025] Initialization annotation: An annotation placed on a controller class method to perform the initialization construction of the window scene content. The method should construct and return the scene root node, and the window manager creates a scene object based on this root node.

[0026] Display callback annotation: Annotation placed on controller class methods, which is called after each window is displayed to refresh interface data or update UI state.

[0027] Cleanup annotation: Annotations placed on controller class methods are invoked after the window is hidden, and are used to release resources, cancel listeners, clean up temporary data, etc.

[0028] Controller: The class responsible for managing the window's business logic and view control, and establishes an association with a window instance.

[0029] Scene: A scene object in the UI framework that contains the hierarchical structure of view elements within the window.

[0030] Scene root node: The top-level UI element that constitutes the scene view hierarchy. It is the return value of the method that initializes annotations. The window manager builds scene objects based on this root node.

[0031] Bean Factory Interface: A unified abstract interface for obtaining objects, with two implementation modes: reflection-based Bean Factory implementation and container-based Bean Factory implementation.

[0032] Window hierarchy stack: A window Z-order management stack maintained based on a double-ended queue data structure, used to manage the display hierarchy and ownership relationship of windows.

[0033] Window-controller association cache: A cache mapping with the window object as the primary key and the controller instance as the value, used to quickly find the controller associated with the window when an event is triggered.

[0034] Controller-Window Cache: A cache mapping with controller type as the primary key and window object as the value, used to quickly find created window instances in singleton window mode.

[0035] Example 1 As attached Figure 2-4 As shown, this embodiment provides an annotation-based rich client window lifecycle management method, and describes each step of the method in detail: S1. Declare the window's configuration properties using window definition annotations. Specifically: Annotate the controller class with a window definition annotation to declare the configuration properties of the window corresponding to that controller. These configuration properties include at least the window width, window height, window modality type, whether it is a singleton window, and whether to maintain a window hierarchy stack.

[0036] Window width and height determine the initial display size of the window. Modal type controls the blocking behavior of the window on other windows when displayed; possible values ​​include no modality, window-level modality, and application-level modality, each corresponding to a different level of interaction blocking. Singleton window configuration indicates whether only one instance of this type of window is allowed in the application: when configured as a singleton window, multiple requests to open the window will reuse the same window instance instead of creating it repeatedly, thus saving system resources and maintaining window state consistency. Whether to maintain the window hierarchy stack configuration indicates whether the window participates in window Z-order management. When configured to maintain the hierarchy stack, the window is pushed onto the hierarchy stack and managed by the hierarchy when displayed; the new window's display position will cover the existing window.

[0037] In addition to the necessary configuration attributes mentioned above, window definition annotations may optionally include one or more of the following additional configuration attributes: Window title: Used to set the text displayed in the window title bar. Minimum window width and minimum height: Used to limit the minimum size of the window when the user resizes it, preventing the window from being too small and causing incomplete display of interface content. Maximum window width and maximum height: Used to limit the maximum size of the window when the user resizes it. Stretchable: Controls whether the user can change the window size by dragging the window edges; if configured as non-stretchable, the window size is fixed. Icon path: Specifies the location of icon resources displayed in the window title bar and taskbar. Cascading stylesheet path: Specifies the location of stylesheet files applied to the window scenario to achieve a unified and aesthetically pleasing interface style. Window decoration style: Controls whether the window displays decorative elements such as the title bar, maximize button, minimize button, and close button, meeting the display needs of different window types. Main window: Indicates whether this window is the main window of the application; closing the main window is usually associated with the exit behavior of the entire application. Centered display: Controls whether the window is automatically centered on the screen when it is first displayed, improving the user experience.

[0038] S2. In response to the window creation command, obtain the controller instance through a unified Bean Factory interface. Specifically: When a user action or system logic triggers a window open command, the command carries the type information of the target controller class. The window manager responds to the command and initiates the window creation process. The window manager first obtains the controller instance corresponding to the window through a unified Bean Factory interface.

[0039] The Bean Factory interface is designed as a pluggable strategy interface with two switchable implementation modes to adapt to different operating environments.

[0040] The first approach is a reflection-based Bean Factory implementation, suitable for pure Java environments without a dependency injection container. In this model, the Bean Factory uses Java reflection to find the constructor of the target controller class. When the constructor has parameters, it recursively resolves the dependencies of each parameter. That is, for each parameter type, it continues to create instances of it via reflection, and so on, until all dependencies are resolved. This implementation incorporates a circular dependency detection mechanism based on thread-local variables. During the resolution of constructor parameter dependencies, the class currently being created is recorded in a thread-local variable. When the same class being created is encountered again in the same resolution chain, a circular dependency is determined, and a clear exception is thrown, thus avoiding endless recursion or stack overflow problems caused by circular references.

[0041] The second approach is the container-based Bean Factory implementation. This pattern is suitable for environments with dependency injection containers, such as Spring and other IoC containers. In this pattern, the Bean Factory interface does not create objects itself; instead, it delegates the task to the underlying dependency injection container's Bean retrieval methods. The container is responsible for the complete creation of the controller instance and the entire dependency injection process, including handling various injection annotations declared in the controller class, such as autowiring annotations. This pattern fully leverages the container's mature instance management capabilities, ensuring seamless integration with the existing container ecosystem.

[0042] The window manager automatically selects the appropriate factory implementation based on the detection results of the runtime environment, or the developer can explicitly specify the factory type to be used through configuration parameters during system initialization.

[0043] S3. After the controller instance is created, the method annotated with initialization is found and executed using reflection to obtain the scene root node. The scene is then created based on the scene root node, and window and scene properties are configured according to the window definition annotations. Specifically: After the controller instance is successfully created, the window manager scans all methods of the controller class using reflection, finds the methods annotated with initialization, and executes these methods in a predetermined order.

[0044] The initialization method is responsible for constructing the window scene content, specifically including: creating the root node element of the scene. This root node can be a layout container, such as a panel, border layout, grid layout, or other types of UI element groups. The initialization method can construct the root node by loading an external view description file or by programmatically building a UI component tree. After the initialization method completes its execution, it returns the constructed root node object to the window manager. Upon receiving the root node, the window manager creates a scene object based on it and can attach configurations to the scene, including but not limited to applying Cascading Style Sheets, setting the cursor type, and setting the scene's fill color.

[0045] Meanwhile, the window manager reads the configuration properties declared in the window definition annotations on the controller class and applies these properties one by one to the currently created window object. Specifically, the window manager sets the window's width and height, modal type, title text, icon resources, and other properties according to the annotation configuration; controls the window's resizable size according to the stretchability configuration; constrains the window's scaling range according to the minimum and maximum size configurations; determines the window's initial display position according to the centering configuration; and determines the display and hiding of decorative elements such as the window title bar and control buttons according to the window decoration style configuration.

[0046] For controllers configured as singleton windows, the initialization annotation method is executed only once during the entire application lifecycle. That is, the initialization method is executed to build the scene and cache it when the window instance is first created. When the window instance is reused subsequently, the initialization logic is not executed again, thereby optimizing performance and avoiding the resource overhead caused by repeated construction.

[0047] For controllers configured as non-singleton windows, a brand new controller instance is generated each time a window is created, and the method of initializing annotations is executed each time to build independent scene content, so that the window instances do not interfere with each other.

[0048] S4. Store the association between the controller and the window in the window-controller association cache. If the window definition annotation is configured as a singleton window, then store the association between the controller and the window in the controller-window cache. Specifically: After the window and scene are created, the window manager needs to establish and maintain the mapping relationship between the controller and the window so that it can accurately find the controller associated with the current window in subsequent window event handling such as show events and hide events, and then execute the corresponding callback methods.

[0049] Specifically, the window manager stores the association between the current controller instance and the current window object in a window-controller association cache. This cache uses the window object as the primary key and the controller instance associated with that window as the value. For scenarios that support multiple scene switching within the same window, the cache value can be a collection of controllers to support the situation where a window is associated with multiple controllers.

[0050] When a window is defined as a singleton window, in addition to storing the aforementioned window-controller association, the window manager also stores the association in the controller-window cache, using the controller type as the key and the window instance as the value. The purpose of this cache is that when a subsequent request to open a singleton window of the same type is made, the window manager can first check the controller-window cache to see if a window instance of that type already exists. If it does, the window instance can be reused directly, without having to repeat the entire creation process of controller creation and scene construction, thereby improving response speed and ensuring the uniqueness of the singleton window.

[0051] S5. If the window definition annotation is configured to maintain a window hierarchy stack, the window is pushed onto the window hierarchy stack, and the top window of the stack is set as the owner window; if it is configured not to maintain a window hierarchy stack, the push and owner setting operations are skipped. Specifically: The window manager maintains a window hierarchy stack based on a double-ended queue data structure to manage the Z-order display relationship of windows participating in the hierarchy management in the application.

[0052] The window manager reads the configuration in the window definition annotation regarding whether to maintain the window hierarchy stack, and executes different processing logic based on the configuration value.

[0053] If the window definition annotation is configured to maintain a window hierarchy stack, the window manager pushes the window object onto the top of the window hierarchy stack before the window is displayed. Then, the window manager queries the top element of the current hierarchy stack before the new window was pushed—that is, the topmost window before the push—and sets that top-level window as the owner window of the new window. Setting the owner window is crucial in modal window scenarios: when the new window is modal, input events such as mouse clicks and keyboard inputs on its owner window are blocked, thus creating an expected hierarchical blocking relationship between windows at the user interaction level. The user must process the modal window before continuing to operate its owner window.

[0054] If a window definition annotation is configured not to maintain a window hierarchy stack, the window manager skips window push operations and does not perform owner window settings. This configuration is suitable for auxiliary windows that do not need to participate in hierarchy management, such as tool windows, tooltips, or non-modal standalone windows, whose display and interaction are independent of the main window hierarchy.

[0055] S6. Register window show event listeners and window hide event listeners for the window. The window show event listener is used to execute the method annotated with the show callback after the window is shown. The window hide event listener is used to retrieve the set of controllers associated with the window from the window-controller association cache after the window is hidden, and execute the cleanup annotation methods of each controller in the set. Specifically: The window manager registers two types of core event listeners for each created window: window show event listeners and window hide event listeners.

[0056] A window display event listener listens for window display events. This listener is triggered when the window is displayed on the screen, i.e., when it becomes visible. The listener's execution logic is as follows: First, it looks up the controller instance associated with the current window through the window-controller association cache. Then, it uses reflection to scan all methods in that controller annotated with display callbacks and executes these methods sequentially. For singleton windows, when the window is hidden and then displayed again (i.e., in a reuse scenario), the methods annotated with display callbacks will also be executed. This ensures that when a singleton window is reused for display, operations such as refreshing interface data and updating UI state are performed, guaranteeing that the window content is up-to-date each time it is displayed.

[0057] The window hide event listener listens for window hide events. When a window is closed or hidden, i.e., becomes invisible, the listener is triggered. The listener's execution flow includes the following operations: First, it retrieves the set of controllers associated with the current window through the window-controller association cache; then, for each retrieved controller instance, it uses reflection to find methods annotated with cleanup and executes these methods sequentially to perform operations such as resource release, unregistering listeners, and cleaning up temporary data, for example, closing file streams, releasing network connections, removing registered event handlers, and clearing cached data; next, it removes the window from the window hierarchy stack, if it was previously pushed onto the stack; finally, it clears all association records corresponding to the window from the window-controller association cache.

[0058] S7. Remove the window from the window hierarchy stack and clear the record corresponding to the window in the window-controller association cache. Specifically: After the window hide event listener completes the above cleanup operations, the window manager performs a final cleanup confirmation to ensure that resources are completely released. Specifically, this includes: confirming that the window has been removed from the window hierarchy stack; and confirming that the record corresponding to the window in the window-controller association cache has been cleared.

[0059] In practice, the operations of removing the window from the hierarchy stack and clearing cache records can be integrated into the window hide event listener's processing logic, or the cache clearing and stack removal operations can be extracted as independent cleanup steps and executed by the window manager after the window hide event is processed. Regardless of the implementation method, the core purpose is to ensure that no cache records or hierarchy references related to the window remain after the window is closed or hidden, thus avoiding memory leaks caused by residual references.

[0060] It should be noted that if the window definition annotation is configured to maintain a window hierarchy stack, the pop operation in this step will remove the current window from the hierarchy stack, and the hierarchy of the remaining windows in the stack will be updated accordingly. If the window definition annotation is configured not to maintain a window hierarchy stack, no stack operations are involved in this step.

[0061] S8. In response to the UI thread-safe execution instruction, automatically determine whether the current thread is the UI thread. If not, submit the task to the UI thread for execution through an asynchronous thread switching mechanism; if so, execute directly. Specifically: Throughout the entire window lifecycle management process, all operations involving window creation, display, hiding, closing, and execution of controller callback methods must run on the UI framework's interface thread, i.e., the UI main thread. Otherwise, it will cause UI update anomalies, such as thread conflict anomalies or inconsistent interface states.

[0062] The window manager provides a unified, thread-safe execution entry point for the UI. When an external caller, which may come from a background business thread, a scheduled task thread, or a network response thread, submits a task to be executed through this entry point, the internal processing logic is as follows: First, obtain the current execution thread and determine whether the current thread is the UI thread. If the current thread is the UI thread, then execute the submitted task synchronously on the current thread. If the current thread is not the UI thread, then use the asynchronous thread switching mechanism provided by the UI framework, such as putting the task into the message queue of the UI thread, submitting the task to the UI thread, and waiting for the UI thread to become idle before executing it asynchronously.

[0063] This thread safety mechanism is encapsulated in all public APIs of the window manager. Calls to operations such as window creation, display, hiding, closing, and scene switching all pass through this mechanism. Developers do not need to worry about the thread on which the code is running when calling these APIs; the window manager automatically ensures that all UI operations are executed on the correct thread, thus fundamentally avoiding security risks associated with UI operations in a multi-threaded environment.

[0064] In this embodiment, the supplementary explanation for step S2 is as follows: The initialization triggering method in the container environment is as follows: In a dependency injection container environment, the activation of the container bean factory implementation in step S2 is not manually configured by the developer, but is automatically completed by listening to the container's lifecycle events.

[0065] Specifically, the window manager implements the container event listener interface to listen for the container's context refresh completion event. When the container has finished loading and instantiating all Bean definitions, it triggers the context refresh completion event. Upon receiving the event notification, the window manager first determines whether the current context is the root context to avoid duplicate initialization triggers in child contexts, such as child containers in Spring MVC. If it is confirmed to be the root context, it obtains the container's context object, encapsulates the context's Bean retrieval method into a container factory implementation of the Bean Factory interface, and injects it into the window manager, thus completing the global initialization of the window manager within the container environment.

[0066] The window manager also listens for container shutdown events. When the container shuts down normally, the window manager automatically triggers a global resource release step, which clears the controller-window cache, clears the window-controller association cache, and clears the window hierarchy stack. If the current implementation is a reflection bean factory, it also clears the dependency resolution context and component instance cache maintained internally by the reflection bean factory, ensuring that all window resources are released along with the container without leaving any residue.

[0067] In this embodiment, the steps for releasing global resources upon program exit are as follows: When an application exits normally, regardless of whether it is a container environment, the window manager performs global resource release operations. Specifically, this includes: clearing all associated records stored in the controller-window cache; clearing all associated records stored in the window-controller association cache; and clearing all window objects stored in the window hierarchy stack.

[0068] In addition, if the current window manager uses a reflection bean factory implementation, the dependency resolution context maintained internally by the reflection bean factory also needs to be cleared during the global resource release process, including the cache of created component instances and the cache of constructor parameter resolution, to ensure that no state information from the previous runtime remains when the application is restarted.

[0069] If the current environment is a container environment, the release of global resources is triggered by the container shutdown event, and the release order is coordinated with the container lifecycle.

[0070] In this embodiment, the steps for switching scenes within the same window are as follows: The method in this application also supports dynamically switching scene content within the same window instance without closing and recreating the window. The specific implementation steps are as follows: First, obtain the target controller instance corresponding to the target scenario. This controller instance can be passed in by the caller, newly created through the Bean Factory interface, or an existing instance obtained from the cache, depending on the scenario type and configuration.

[0071] Then, by using reflection, we find and execute the methods marked with display callback annotations in the target controller to complete the pre-display preparation of the target scene, such as performing operations such as loading interface data and initializing component states, to ensure that the target scene is ready before being displayed.

[0072] Next, the scene object of the current window is replaced with the new scene object constructed by the target controller, thereby achieving dynamic switching of window content.

[0073] Finally, update the controller record corresponding to the current window in the window-controller association cache, replace the old controller with the new controller, or append the new controller to the controller set corresponding to the window, so that the history of multiple controllers needs to be retained in the same window for later use.

[0074] By using the above scene switching process, effects similar to page navigation or view switching can be achieved without rebuilding the window, thus improving user experience and interface response efficiency.

[0075] In this embodiment, the differentiated behaviors under different configuration combinations are described as follows: For non-singleton windows, a new controller instance is generated and a new scene is built each time a window is created. Each window instance is independent of the others and does not affect them. Closing one window will not affect the state of other windows of the same type.

[0076] For a singleton window, a controller instance and scene are created and stored in the corresponding cache when it is first opened. When it is opened again in subsequent requests, the window manager directly retrieves the existing window instance from the controller-window cache and displays it. At the same time, it triggers the method marked with the display callback annotation to refresh the interface data, without repeating the initialization method, thus ensuring the consistency of the singleton window state.

[0077] For windows configured to maintain a hierarchy stack, their display and hiding are managed uniformly by the hierarchy stack. New windows will overlay existing windows and establish an ownership relationship. Modal windows can correctly block the interaction of the owner window according to the hierarchy relationship. For windows configured not to maintain a hierarchy stack, their display and hiding are independent, do not participate in hierarchy management, and do not affect the hierarchy state of other windows.

[0078] For windows configured as the main window, they remain at the bottom of the stack as permanent elements. Closing or popping ordinary windows from the stack will not cause the main window to be removed, thus ensuring the stability of the application's main window.

[0079] By flexibly combining the above configuration attributes, developers can choose the appropriate configuration scheme according to the business characteristics of different windows to achieve differentiated window behaviors.

[0080] Example 2 As attached Figure 1 As shown, this embodiment provides an annotation-based rich client window lifecycle management system to implement the method in Embodiment 1, as detailed below: Multi-level annotation configuration module 1 This module provides a complete annotation system for declaratively configuring window properties and lifecycle callback behaviors. This annotation system specifically includes the following four core annotations: Window definition annotation: This annotation is applied to the controller class to declare the configuration properties of the window corresponding to that controller. The attribute fields included in this annotation at least cover window width, window height, window modality type, whether it is a singleton window, and whether it maintains a window hierarchy stack. In addition, this annotation can optionally include extended attribute fields such as window title, minimum window width, minimum window height, maximum window width, maximum window height, whether it is stretchable, icon path, Cascading Style Sheet path, window decoration style, whether it is the main window, and whether it is centered. Developers can complete the window configuration declaration by annotating the controller class with this annotation and setting the corresponding attribute values, without writing additional configuration code.

[0081] Initialization Annotation: This annotation is placed on a method in a controller class to identify that the method is responsible for initializing the window scene content. Methods annotated with this annotation are responsible for creating the root node element of the window scene and performing scene-related initialization settings. The result of this method, the scene root node, is retrieved by the window manager and used to construct the scene object.

[0082] Display callback annotation: This annotation is placed on a method in a controller class to identify that the method is a callback method that needs to be executed after the window is displayed. Methods annotated with this annotation are called by the window manager each time the window is displayed. It is suitable for performing operations that need to be executed when the window is displayed, such as refreshing UI data, updating state, and setting focus.

[0083] Cleanup Annotation: This annotation is placed on a method in a controller class to indicate that the method is a resource cleanup method that needs to be executed when the window is hidden. Methods annotated with this annotation are called by the window manager when the window is closed or hidden, and are suitable for performing resource release operations such as canceling timers, unregistering listeners, deleting temporary files, and closing database connections.

[0084] By using the above four annotations together, developers can define window configuration and lifecycle callbacks entirely declaratively, clearly separating window management logic from business logic.

[0085] Pluggable Bean Factory Abstract Module 2 This module defines a unified Bean Factory interface, which declares methods for retrieving object instances based on type. This interface is designed using the strategy pattern and has two independent implementations.

[0086] Reflective Bean Factory Implementation: This implementation is suitable for runtime environments without a dependency injection container. Internally, it uses reflection to create objects and resolve dependencies. When a request is made for an instance of a certain type, this implementation uses reflection to find the constructor for that type. For parameterized constructors, it recursively resolves the types that each constructor parameter depends on, creates instances of each dependency one by one, and then calls the target constructor to complete object creation. This implementation has a built-in circular dependency detection mechanism based on thread-local variables. During recursive resolution, the class type being created is recorded in thread-local storage. If the same type is encountered again during resolution, a circular dependency is determined and an exception is thrown, thus ensuring the robustness of the object creation process.

[0087] Container Bean Factory Implementation: This implementation is suitable for runtime environments with dependency injection containers. Instead of creating objects itself, it holds a reference to the underlying container and delegates requests for objects directly to the underlying container's Bean retrieval method. This implementation enables seamless integration with mainstream IoC containers such as Spring. Controller classes can declare dependencies using the container's injection annotations, and the container handles the complete dependency injection.

[0088] The two factory implementations can be switched through configuration. The system will automatically detect and select the appropriate implementation based on the runtime environment during initialization, or developers can manually specify it according to actual needs.

[0089] Window Management Core Module 3 This module is the central module of the system, responsible for coordinating other modules to complete the full lifecycle management of windows. Its main functions include the following: Response window creation command: This module provides the window creation entry point, receives the creation command containing the target controller type information, and obtains the controller instance through the pluggable Bean Factory abstract module 2.

[0090] Execute scene initialization: After the controller instance is created, this module uses reflection to find the method in the controller marked with the initialization annotation and executes it. It then obtains the scene root node returned by the method and creates a scene object based on the root node.

[0091] Configure window properties: This module reads the configuration properties declared in the window definition annotation on the controller class and applies these properties to the newly created window object one by one, including setting the window size, modal type, title, icon, decoration style, etc.

[0092] Manage various caches: This module maintains a window-controller association cache, storing the associated controller instance with the window object as the primary key; it also maintains a controller-window cache, storing created window instances with the controller type as the primary key, for quick lookup and reuse of singleton windows.

[0093] Register Event Listeners: This module registers show and hide event listeners for each window. The show event listener is triggered after the window is shown, finding the controller through the window-controller association cache and executing the methods marked with the show callback annotation. The hide event listener is triggered after the window is hidden, executing methods to clean up annotations and removing associated records from the cache.

[0094] Through the above functions, the core module 3 of window management realizes closed-loop management of the entire lifecycle from controller instance creation to window destruction.

[0095] Window hierarchy stack management module 4 This module maintains the Z-order relationship of all windows involved in hierarchical management within the application based on a double-ended queue data structure. It provides basic operations such as pushing windows onto the stack, popping windows from the stack, and querying the top window of the stack.

[0096] When a new window is created and its window definition annotation is configured to maintain a window hierarchy stack, the module pushes the new window onto the top of the hierarchy stack, queries the window object that was at the top of the stack before the window was pushed, and sets that object as the owner window of the new window, thereby establishing the correct owner-subordinate relationship in the modal window scenario.

[0097] When a window is closed, the module removes the window from the hierarchy stack and updates the hierarchy state of the remaining windows in the stack.

[0098] For windows configured as the main window, this module sets them to the bottom of the stack during the push operation and checks during the subsequent pop operation: if only the main window remains in the stack, it prevents the main window from being popped, ensuring that the main window always exists in the stack throughout the entire application's runtime.

[0099] For windows configured not to maintain a window hierarchy stack, this module does not perform push operations on the stack, nor does it set an owner window. The display hierarchy of this window is independent of the hierarchy stack management.

[0100] Thread-safe task scheduling module 5 This module ensures that all window operations are executed on the correct thread. It provides a unified task submission entry point, receiving task units to be executed.

[0101] Internally, this module includes thread detection logic: when a task is submitted, it first obtains the currently executing thread and determines whether this thread is the UI framework's UI thread. If the current thread is the UI thread, the module immediately executes the submitted task. If the current thread is not the UI thread, the module submits the task to the UI thread's message queue through the asynchronous thread switching interface provided by the UI framework, waiting for the UI thread to become idle before execution.

[0102] All operations involving window creation, display, hiding, closing, and controller callback method calls are submitted and executed through this module, thus ensuring the safety of window lifecycle management operations in a multi-threaded environment.

[0103] Static Tool Facade Module 6 This module provides a unified static access point and encapsulates the various functions of the window management core module 3, simplifying the usage complexity for external callers.

[0104] The module provides the following entry points: a non-container environment startup entry point, used to initialize the window manager in a pure Java environment, implemented using a reflection-based Bean Factory; a container environment startup entry point, used to initialize the window manager in a dependency injection container environment, receiving a container context object and implementing it using a container Bean Factory; a new window creation entry point, receiving a target controller type parameter and executing the creation and display of the window; a scene navigation entry point, receiving a target window and target controller type parameter and executing scene switching within the specified window; and a resource release entry point, used to trigger global resource release when the application exits.

[0105] The facade module delegates various calls to the corresponding methods of the window management core module 3, providing a simple and easy-to-use operation interface for external callers.

[0106] Container Integration Module 7 This module is used to achieve deep integration between this system and external dependency injection containers, enabling the system to automatically sense and respond to container lifecycle events.

[0107] This module implements the container context refresh event listener interface. After the container has finished loading and instantiating all Bean definitions, it triggers a context refresh completion event. Upon receiving the event notification, this module first determines whether the current context is the root context, executing initialization logic only in the root context to avoid duplicate initialization caused by child contexts. After confirmation, the module obtains the container's context object, encapsulates the context's Bean retrieval method into a container factory implementation of the Bean factory interface, and injects it into the window management core module 3, completing the global initialization of the window manager.

[0108] This module also implements the container shutdown event listener interface. When the container shuts down normally, this module triggers the global resource release operation of the window management core module 3, clearing all caches and hierarchy stacks to ensure that resources are completely released when the application exits.

[0109] Through this container integration module 7, this system can be seamlessly embedded into mainstream dependency injection container environments such as Spring, making full use of the dependency injection and lifecycle management capabilities provided by the container.

[0110] In actual operation, the above modules work together to complete the full lifecycle management of the window.

[0111] Taking the window opening process in a container environment as an example: After the application starts, the container loads all controller classes. The container integration module 7 listens for the container refresh completion event and automatically initializes the window manager. When the user triggers a window opening operation, the static utility facade module 6 receives the call request and forwards it to the window management core module 3. The core module obtains a controller instance from the container through the pluggable Bean factory abstract module 2, executes the controller's initialization method to create a scene, configures window properties according to the window definition annotations, stores the associations in the cache, calls the hierarchy stack management module to handle window pushing and owner settings, registers event listeners, and finally displays the window in the interface thread through the thread-safe task scheduling module 5. After the window is displayed, the display event listener automatically executes the display callback method. When the window is closed, the hide event listener automatically executes the cleanup callback method and clears the cache records.

[0112] Throughout the process, developers only need to annotate the controller class with the corresponding annotations and implement the business methods. All the underlying details of window management are automatically completed by the various modules of the system, achieving a high degree of automation and standardization in window lifecycle management.

[0113] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An annotation-based rich client window lifecycle management method, characterized in that: include: S1. Declare the window's configuration properties through window definition annotations. The configuration properties should include at least the window size, window modality type, whether it is a singleton window, and whether to maintain a window hierarchy stack. S2. In response to the window creation command, the controller instance is obtained through a unified Bean factory interface. The Bean factory interface is a pluggable strategy interface with two modes: reflection Bean factory implementation and container Bean factory implementation. S3. After the controller instance is created, use reflection to find and execute the methods marked with initialization annotations in the controller, obtain the scene root node, create the scene based on the scene root node, and configure window properties and scene properties according to the window definition annotations. S4. Store the association between the controller and the window in the window-controller association cache. If the window definition annotation is configured as a singleton window, then store the association between the controller and the window in the controller-window cache. S5. If the window definition annotation is configured to maintain the window hierarchy stack, the window is pushed onto the window hierarchy stack, and the top window of the window hierarchy stack is set as the owner window of the window; if it is configured not to maintain the window hierarchy stack, the push and owner setting operations are skipped. S6. Register a window show event listener and a window hide event listener for the window. The window show event listener is used to execute the method marked with the show callback annotation in the controller after the window is shown. The window hide event listener is used to retrieve the set of controllers associated with the window from the window-controller association cache after the window is hidden, and execute the cleanup annotation annotation method of each controller in the set of controllers. S7. Remove the window from the window hierarchy stack and clear the record corresponding to the window in the window-controller association cache; S8. In response to the UI thread-safe execution instruction, automatically determine whether the current thread is the UI thread. If not, submit the task to the UI thread for execution through an asynchronous thread switching mechanism; if so, execute directly.

2. The method according to claim 1, characterized in that: In step S1, the configuration attributes of the window definition annotation also include one or more of the following: window title, minimum window size, maximum window size, whether it is stretchable, icon path, cascading style sheet path, window decoration style, whether it is the main window, and whether it is centered.

3. The method according to claim 1, characterized in that: In step S2, the reflection-based Bean Factory implementation is used in a non-dependency injection container environment. It uses reflection to find the constructor and recursively resolve the constructor parameter dependencies. It also has a built-in circular dependency detection mechanism based on thread-local variables. The container bean factory implementation is used in dependency injection container environments to directly delegate bean retrieval methods to the dependency injection container.

4. The method according to claim 1, characterized in that: Before step S2, in the dependency injection container environment, the initialization of the window management method is triggered by listening to the context refresh completion event of the dependency injection container. Specifically, this includes: listening to the context refresh completion event, determining whether the current context is the root context, and if so, obtaining the context of the dependency injection container, using the context's Bean acquisition method as the container Bean factory implementation of the Bean factory interface, and completing the global initialization of the window manager.

5. The method according to claim 1, characterized in that: In step S3, for controllers configured as singleton windows, the method for initializing annotations is executed only once; For controllers configured as non-singleton windows, the method for initializing annotations is executed every time a window is created.

6. The method according to claim 1, characterized in that: In step S5, if the window is the main window, the window hierarchy stack retains the main window but does not push it out of the stack. After step S7, there are also resource release steps when the program exits: clear the controller-window cache, window-controller association cache and window hierarchy stack, and if the current implementation uses a reflection Bean factory, clear the dependency resolution context of the reflection Bean factory.

7. The method according to claim 1, characterized in that: In step S6, when the window display event listener reuses the display in a singleton window, it also executes the display callback annotation to refresh the window interface data. When a window is hidden, the window hide event listener first executes a method to clean up annotations, then removes the window from the window hierarchy stack, and finally removes the record corresponding to the window from the window-controller association cache.

8. The method according to claim 1, characterized in that: It also includes the step of switching scenes within the same window: obtaining the target controller instance corresponding to the target scene, finding and executing the method marked with the display callback annotation in the target controller through reflection, switching the scene of the current window to the new scene corresponding to the target controller, and updating the controller record corresponding to the current window in the window-controller association cache.

9. An annotation-based rich client window lifecycle management system, used to implement the method described in any one of claims 1-8, characterized in that: include: The multi-level annotation configuration module (1) is used to provide window definition annotations, initialization annotations, display callback annotations and cleanup annotations. The window definition annotation is used to declare the configuration attributes of the window, the initialization annotation is used to mark the initialization method of the window scene content, the display callback annotation is used to mark the callback method after the window is displayed, and the cleanup annotation is used to mark the resource cleanup method after the window is closed. The pluggable Bean Factory abstract module (2) is used to provide a unified Bean Factory interface, which has two switchable modes: reflection Bean Factory implementation and container Bean Factory implementation. The core module of window management (3) is used to respond to window creation instructions, obtain controller instances through the pluggable Bean factory abstract module (2), execute the method of initializing annotation annotation to create a scene, configure window attributes and scene attributes according to window definition annotation, manage controller-scene cache, window-controller association cache and controller-window cache, register window display event listeners and window hide event listeners, execute the method of display callback annotation annotation after the window is displayed, and execute the method of cleaning up annotation annotation after the window is hidden; The window hierarchy stack management module (4) is used to maintain the window hierarchy stack based on the double-ended queue, perform window push, window pop and query the top window of the stack, and selectively set the top window of the stack as the owner window of the new window according to the configuration of the window definition annotation when the new window is created. The thread-safe task scheduling module (5) is used to respond to the interface thread-safe execution instruction, automatically determine whether the current thread is an interface thread, and submit the task to the interface thread for execution through an asynchronous switching mechanism when it is not an interface thread. The static tool facade module (6) is used to encapsulate the functions of the window management core module (3) and provides entry points for non-container environment startup, container environment startup, new window creation, scene navigation, and resource release. The container integration module (7) is used to listen for the context refresh completion event of the external dependency injection container. When the context refresh is complete, the container's Bean acquisition method is used as the container Bean factory implementation of the Bean factory interface to complete the global initialization of the window manager and trigger the global resource release when the container is closed.

10. The system according to claim 9, characterized in that: When the window definition annotation is configured as the main window, the window hierarchy stack management module (4) retains the main window from being pushed onto the stack. When the window definition annotation is configured not to maintain the window hierarchy stack, it skips the push-on and owner setting operations.

Images