Dual-entry modular running method and system for cross-platform applications

Abstract

The application discloses a kind of dual-entry modular running method and system of cross-platform application, it is related to mobile application development field, steps are as follows: define module interface abstract layer, standard business module life cycle method;Provide module manager, register and dispatch business module, manage life cycle event bus, route coordination and navigation closing service;Provide first entry, complete dependent injection, log initialization and root application construction in independent mode;Provide the second entry of embedded running, realize module interface abstract layer, is dispatched by module manager by host application, receives authentication token, returns container entry route and wrapped top-level interface component;First entry and second entry share business code and the above-mentioned service.It realizes the reuse of business code in independent and embedded mode, module dynamic registration and cancellation, solves the problem of low code reuse rate, lack of modularization, life cycle management confusion, improves system scalability and maintainability.

Description

Technical Field

[0001] This invention relates to the field of mobile application development technology, and in particular to a dual-entry modular operation method and system for cross-platform applications. Background Technology

[0002] With the rapid development of the mobile internet, cross-platform application development frameworks such as Flutter and React Native have been widely adopted in the industry, enabling developers to build iOS and Android applications using a single codebase, significantly improving development efficiency. However, in actual business scenarios, an increasing number of applications need to run in both standalone and embedded modes. Standalone mode means the application is launched directly as an independent app, possessing a complete lifecycle and user interface; embedded mode means the application runs as a functional module embedded within a host application, such as embedding a food delivery channel in a food delivery platform or embedding a sub-business module in a large platform.

[0003] Existing technologies have the following drawbacks when handling dual-entry scenarios: low code reusability, with each independent and embedded mode maintaining its own set of entry code, leading to repetitive development of business logic and inconsistencies when requirements change; insufficient modularity, with existing solutions using hard-coding to handle differences between the two entry points, lacking a unified interface abstraction layer, making it difficult for business modules to dynamically register and deregister; chaotic lifecycle management, with the lifecycle of sub-applications controlled by the host in embedded mode, significantly different from independent mode, lacking a unified event management mechanism, and making page state synchronization difficult; complex routing management, with changes in routing within sub-applications in embedded mode requiring synchronous notification to the host, but lacking an effective container routing coordination mechanism; and difficulty in transmitting authentication tokens, as host authentication information needs to be securely transmitted to sub-applications, requiring extensive custom development in existing technologies.

[0004] Therefore, there is an urgent need in this field for a cross-platform application with a dual-entry modular operation method and system that features high code reusability, high modularity, unified lifecycle management, flexible routing coordination, and convenient authentication token transmission. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a dual-entry modular operation method and system for cross-platform applications, in order to solve the problems of low code reuse rate, insufficient modularity, and chaotic lifecycle management in the prior art. By defining a module interface abstraction layer and building a module manager to uniformly schedule business modules, manage page lifecycle event bus and container routing coordination service, the first entry and the second entry share business code and the above services, ensuring that full reuse of business code, unified lifecycle management and flexible routing coordination can be achieved in both independent operation mode and embedded operation mode, thereby reducing development and maintenance costs.

[0006] The specific plan is as follows: In a first aspect, the present invention provides a dual-entry modular operation method for cross-platform applications, the method mainly comprising the following steps: S10, Define a module interface abstraction layer, which includes lifecycle methods for module initialization, authentication token injection, dependency injection, route provision, and top-level interface component wrapping; S20 provides a module manager to register and schedule business modules, and manage the initialization and lifecycle of the page lifecycle event bus, container routing coordination service, and container navigation shutdown service; S30 provides the first entry point, which completes dependency injection initialization, log initialization, and root application construction in independent mode; S40 provides a second entry point for embedded execution. The second entry point implements the interface defined by the module interface abstraction layer. It is scheduled by the host application through the module manager, receives the authentication token injected by the host application, and returns the container entry route and the wrapped top-level interface component. S50, the first entry point and the second entry point share the business code, and share the page lifecycle event bus, container routing coordination service and container navigation shutdown service.

[0007] Furthermore, the module interface abstraction layer also includes methods for obtaining module names, obtaining tokens, routing, and providing localization.

[0008] Furthermore, the module manager adopts a registration-based architecture, which supports the dynamic registration and deregistration of the business modules at runtime. After receiving the authentication token injected by the host application, the module manager distributes the authentication token to the registered business modules.

[0009] Furthermore, the module manager initializes the dependency injection containers of the registered business modules in parallel; the routing method of the module manager adopts the chain of responsibility pattern, traversing the registered business modules to match routes and returning the route constructor of the first successfully matched business module; the top-level interface component wrapping method of the module manager adopts the decorator chain pattern, traversing the registered business modules to wrap basic top-level interface components and returning a composite top-level interface component.

[0010] Furthermore, the first entry point completes dependency injection initialization, log initialization, and root application construction in independent mode, including: completing Flutter engine binding, initializing the dependency injection container, registering basic services, initializing the logging system and enabling automatic capture, and running the root application in an exception capture environment.

[0011] Furthermore, after receiving the authentication token injected by the host application, the second entry point injects the authentication token into the network service and the token refresh manager to complete the network layer authentication state initialization.

[0012] Furthermore, the container entry route returned by the second entry is configured to create a native container page that carries the Flutter module on the host application side, and the wrapped top-level UI component returned by the second entry is sequentially wrapped by state management injection, screen adaptation and translation provider.

[0013] Furthermore, the page lifecycle event bus is a static event bus implemented using the Dart language, employing the observer pattern, and providing lifecycle callbacks for page display, page hiding, foreground / background switching, and page route changes.

[0014] Furthermore, the container routing coordination service is responsible for maintaining the mapping between container identifiers and initial routes, and is used to notify the host application to synchronize the route status when the route changes within the Flutter module; the container navigation shutdown service is used for the Flutter module to actively request the host application to shut down the current Flutter container.

[0015] Secondly, the present invention provides a dual-entry modular operation system for cross-platform applications, used to implement the aforementioned dual-entry modular operation method for cross-platform applications. The system includes an interface abstraction layer definition module, a scheduling management module, an independent entry module, an embedded entry module, and a code sharing module. The interface abstraction layer definition module is used to define the module interface abstraction layer, which includes lifecycle methods for module initialization, authentication token injection, dependency injection, route provision, and top-level interface component wrapping. The scheduling management module is used to provide a module manager, register and schedule business modules, and manage the initialization and lifecycle of the page lifecycle event bus, container routing coordination service, and container navigation shutdown service. The independent entry module is used to provide a first entry point, which completes dependency injection initialization, log initialization and root application construction in an independent mode; The embedded entry module is used to provide a second entry point for embedded operation. The second entry point implements the interface defined by the module interface abstraction layer, is scheduled by the host application through the module manager, receives the authentication token injected by the host application, and returns the container entry route and the wrapped top-level interface component. The code sharing module is used to share business code between the first entry point and the second entry point, and to share the page lifecycle event bus, container routing coordination service, and container navigation shutdown service.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) By sharing business code between the first and second entry points, the independent mode and the embedded mode share the same set of business logic, avoiding redundant development, reducing maintenance costs, and eliminating the need to modify the two ends separately when requirements change.

[0017] (2) By defining the module interface abstraction layer to standardize the access standards of business modules, and combined with the registration architecture of the module manager, dynamic registration and deregistration of business modules are realized, supporting on-demand loading and dynamic management of modules, and improving the scalability of the system.

[0018] (3) The lifecycle events such as page display, page hiding, foreground / background switching and route changes are uniformly managed by the observer pattern through the page lifecycle event bus. In conjunction with the container routing coordination service, the routing synchronization between the sub-application and the host application in the embedded mode is realized, ensuring consistent page state and improving the smoothness of interaction.

[0019] (4) The authentication token injected by the host application is uniformly received through the module manager and distributed to the registered business modules. Sub-applications do not need to care about the details of token acquisition, which reduces development complexity and ensures the security of network layer authentication. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0021] Figure 1 A flowchart of a dual-entry modular operation method for cross-platform applications provided in an embodiment of the present invention; Figure 2 A block diagram of a cross-platform application dual-entry modular operating system provided in this embodiment of the invention; Figure 3 This invention provides a dual-entry modular operating architecture for cross-platform applications. Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention; Figure 5 This is another structural schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] The present invention will be further described in detail below with reference to a specific application embodiment and accompanying drawings. This embodiment is implemented based on the technical solution of the present invention, and provides detailed implementation methods and specific operation processes, but the scope of protection of the present invention is not limited to the following embodiment.

[0023] Example 1 Please see Figure 1 This invention provides a technical solution: a dual-entry modular operation method for cross-platform applications. Specifically, it includes the following steps: S10, Define a module interface abstraction layer, which includes lifecycle methods for module initialization, authentication token injection, dependency injection, route provision, and top-level interface component wrapping.

[0024] S101. Create a module interface abstraction layer in the project. This abstraction layer is defined in the form of abstract classes or interfaces, serving as an interface specification that all business modules should follow, so that each business module has a unified lifecycle management capability.

[0025] S102, Define a module initialization method in the module interface abstraction layer. This method is used to receive initialization parameters passed by the host application or independent entry point, and complete the initialization configuration of the module, including setting the module name, detecting the runtime environment, and loading basic resources.

[0026] S103 defines an authentication token injection method in the module interface abstraction layer. This method is used to receive the authentication token passed by the host application for network request authentication within the module, enabling the module to access host resources in embedded mode.

[0027] S104 defines a dependency injection method in the module interface abstraction layer. This method is used to receive the dependency injection container, enabling the module to register its own dependency services, including network services, data storage services, configuration services, etc.

[0028] S105 defines a route provisioning method in the module interface abstraction layer. This method is used to return the module's routing table or route constructor for the module manager to perform route matching.

[0029] S106 defines a top-level interface component wrapper method in the module interface abstraction layer. This method is used to receive the basic top-level interface component and return a composite top-level interface component after being decorated with module functions, which is used to implement the UI (User Interface) extension capability of the module.

[0030] In practical applications, when developing a new business module, developers can enable the module to adapt to both standalone and embedded modes by implementing all methods defined in the module's interface abstraction layer. For example, when developing an order management module, developers need to implement a module initialization method to receive order configuration parameters, an authentication token injection method to receive user login credentials, a dependency injection method to register the order service, a route provision method to return the order page route, and a top-level UI component wrapper method to embed the order page component into the overall application. This ensures consistent performance regardless of whether the module runs in a standalone app or is embedded in another host application.

[0031] S20 provides a module manager to register and schedule business modules, and manage the initialization and lifecycle of the page lifecycle event bus, container routing coordination service, and container navigation shutdown service.

[0032] S201. Create a module manager instance. This instance adopts the singleton pattern and remains unique throughout the entire application lifecycle. It is used to uniformly manage all business modules, including module registration, deregistration, scheduling, and message distribution.

[0033] S202, Implement the business module registration method in the module manager. This method receives a business module instance, adds the business module to the internal management list of the module manager, and calls the initialization method of the business module in sequence to complete the module startup process.

[0034] S203, Implement the business module deregistration method in the module manager. This method receives the business module identifier, removes the corresponding business module from the internal management list of the module manager, and calls the destruction method of the business module in turn to release the system resources occupied by the module.

[0035] S204. After receiving the authentication token injected by the host application, the module manager iterates through all registered business modules, calls the authentication token injection method of each business module, and distributes the authentication token to each business module so that each module can obtain the latest authentication information.

[0036] The S205 module manager adopts a registration-based architecture, which supports the dynamic registration and deregistration of business modules at runtime. That is, during the application's operation, the host application can add new business modules or remove existing business modules at any time according to actual business needs without restarting the application.

[0037] S206: When registering multiple business modules, the module manager initializes the dependency injection containers of each business module in parallel, that is, it starts the dependency injection initialization process of each module at the same time, thereby improving the module loading efficiency.

[0038] S207, the module manager's route provisioning method adopts the chain of responsibility pattern. When a route needs to be matched, the module manager traverses the business modules in the order of their registration, passes the current route request to the route provisioning method of each business module, and returns the route constructor of the first business module that successfully matches the request.

[0039] S208, the top-level interface component wrapping method of the module manager adopts the decorator chain pattern. When it is necessary to build a top-level interface component, the module manager starts from the basic top-level interface component, traverses the business modules in the order of their registration, takes the component wrapped by the previous business module as the input of the next business module, and finally returns the composite top-level interface component after being decorated by all business modules.

[0040] S209. Create a page lifecycle event bus instance. This event bus is a static event bus implemented in Dart language. It adopts the observer pattern and provides lifecycle callbacks for page display, page hiding, foreground / background switching, and page route changes, which can be listened to and responded to by various business modules.

[0041] S210, Create a container route coordination service instance. This service is responsible for maintaining the mapping relationship between container identifiers and initial routes, and notifying the host application to synchronize route status when routes change within the Flutter module, so as to keep routes consistent in embedded mode.

[0042] S211, Create a container navigation shutdown service instance. This service allows Flutter modules to actively request the host application to shut down the current Flutter container, which is used to implement the exit function of the module in embedded mode.

[0043] S212, the module manager uniformly manages the initialization and lifecycle of the page lifecycle event bus, container routing coordination service, and container navigation shutdown service, so that these services are initialized when the application starts and destroyed when the application exits.

[0044] In specific application scenarios, when the host application starts, the module manager first completes its own initialization, and then sequentially creates the page lifecycle event bus, container routing coordination service, and container navigation shutdown service. Subsequently, the host application adds the registered business modules to the module manager in sequence. For example, an e-commerce host application includes a homepage module, product details module, shopping cart module, and user center module; these modules are registered to the module manager sequentially upon startup. When a user successfully logs in, the host application passes an authentication token to the module manager, which then distributes the token to all registered business modules. Each module uses this token to complete the authentication initialization of its network services. When a user logs out, the module manager redistributes a new empty token to all modules, allowing each module to clear its network layer authentication status without requiring individual notifications.

[0045] S30 provides the first entry point, which completes dependency injection initialization, log initialization, and root application construction in independent mode.

[0046] When an application in standalone mode is launched, the first entry point of S301 first completes the binding of the Flutter engine, which enables the cross-platform UI framework to render the page. At the same time, it completes the initial configuration of the engine, including rendering mode selection, font loading, localized resource configuration, etc.

[0047] S302, the first entry point initializes the dependency injection container, registers basic services such as network services, data storage services, device information services, and configuration services in the dependency injection container for use by the entire application.

[0048] S303 is the first entry point for initializing the logging system, configuring the log level, output format, and log storage path, and enabling the automatic capture function to capture exceptions and errors during application operation, and formatting the captured exception information before writing it to the log file.

[0049] S304, the first entry point is to wrap the root application with an exception capture environment, that is, to add an exception capture component to the outer layer of the root application, so as to display an error message page when an uncaught exception occurs during the application's operation, thus preventing the application from crashing and displaying a blank screen.

[0050] S305: The first entry point loads and starts the root application component. The root application component displays the corresponding page content according to the current route configuration, and at the same time completes the initialization of the page lifecycle event bus and begins to listen for changes in page state.

[0051] In a specific application scenario, when a user launches a standalone food delivery app, the first entry point initializes the Flutter engine, creating a dependency injection container and registering basic services such as network request libraries, local databases, and location services. Next, it initializes the logging system, configures log output to local files, and enables crash handling. Finally, the entire application is wrapped in an exception handling component so that users see error messages instead of a blank screen when exceptions occur. After completing these initialization tasks, the application enters the homepage, awaiting user interaction. While the user browses products in the food delivery channel, the page lifecycle event bus continuously monitors the page's show / hide state to manage the page's status accordingly.

[0052] S40 provides a second entry point for embedded execution. The second entry point implements the interface defined by the module interface abstraction layer. It is scheduled by the host application through the module manager, receives the authentication token injected by the host application, and returns the container entry route and the wrapped top-level interface component.

[0053] S401 creates a Flutter container page in the host application. This page serves as a native container for Flutter modules, embedding the UI content of the Flutter modules and managing the lifecycle of the container page.

[0054] S402, the host application obtains an instance of the second entry point through the module manager and calls the scheduling method of the module manager to hand over control to the second entry point, which then takes over the initialization process of the Flutter module.

[0055] S403, the second entry point, receives initialization parameters from the host application, including the host application's context, configuration information, container identifier, etc., in preparation for subsequent module operation.

[0056] S404, the second entry point receives the authentication token injected by the host application, injects the authentication token into the network service and token refresh manager, completes the network layer authentication state initialization, and is used to enable subsequent network requests to carry the corresponding user identity.

[0057] S405 is the second entry point for initializing the Flutter engine. However, at this time, only the engine's runtime environment is initialized to reduce resource consumption. The complete application framework is not started. The full initialization will be completed when needed later.

[0058] S406, the second entry point initializes the dependency injection container, registers the basic services required for the embedded mode in the container. These services share the same interface definition as the standalone mode, but the implementation is adapted for the embedded scenario. For example, the network service uses the network channel provided by the host.

[0059] S407 initializes the logging system at the second entry point and redirects log output to the host application's logging system to enable unified log management and avoid management chaos caused by independently generated log files.

[0060] S408, the second entry point returns the container entry route to the host application. The host application uses this route to create a native container page, loads the Flutter module in the native container page, and completes the initial page display of the module.

[0061] S409, the second entry point provides a routing method through the module manager, uses the chain of responsibility pattern to traverse the registered business modules to match routes, and returns the route constructor of the first successfully matched business module, which is used to navigate to the target page.

[0062] S410, the second entry point uses the top-level interface component wrapping method of the module manager to traverse the registered business modules using the decorator chain pattern to wrap the basic top-level interface component and return the composite top-level interface component.

[0063] S411, the top-level interface component after packaging is sequentially packaged with state management injection, screen adaptation and translation provider to enable the embedded mode to obtain the same state management, screen adaptation and internationalization capabilities as the standalone mode.

[0064] S412, the second entry point returns the packaged top-level interface component to the host application, which then renders the component into the Flutter container page to complete the UI display of the module.

[0065] In a specific application scenario, when embedding a food delivery channel into a host application, the host application first creates a native container page to host the Flutter module. Then, the host application obtains a second entry point instance for the food delivery module through the module manager and passes the user's current login token to this second entry point. The second entry point injects the token into the network service, enabling subsequent network requests to carry the corresponding user identity. Next, the second entry point returns the homepage route of the food delivery channel to the host application, which sets this route as the initial route for the Flutter container page to display the homepage content of the food delivery channel. Simultaneously, the second entry point returns a top-level component wrapped with state management injection, screen adaptation, and a translation provider, enabling the food delivery channel to obtain consistent state management, screen adaptation, and internationalization capabilities in embedded mode as in standalone mode.

[0066] S50, the first entry point and the second entry point share the business code, and share the page lifecycle event bus, container routing coordination service and container navigation shutdown service.

[0067] S501 ensures that the first and second entry points share the same business code directory within the project. All business modules maintain only one copy of their code. Dual entry point sharing is achieved through project configuration and conditional compilation, avoiding redundant development and code inconsistencies.

[0068] S502, the page lifecycle event bus, is a static event bus that uses the same instance in both standalone and embedded modes. This allows lifecycle events to be listened to and processed uniformly, ensuring that the same page state callbacks are received regardless of the module's operating mode.

[0069] S503, the container routing coordination service maintains the mapping relationship between container identifiers and initial routes. In standalone mode, the container routing coordination service directly handles route jumps within the application, and route changes are directly reflected in the application navigation bar.

[0070] S504 In embedded mode, when the routing changes within the Flutter module, the container routing coordination service notifies the host application to update the routing status synchronously through the native bridging channel, so that the host application knows the current page position of the Flutter module.

[0071] S505, the container navigation shutdown service can directly close the current page or exit the application in standalone mode, following the standard application exit process.

[0072] S506 In embedded mode, the container navigation shutdown service requests the host application to close the native container page that hosts the Flutter module through the native bridging channel. The host application decides whether to close it and the navigation logic after closing.

[0073] S507, the first and second entry points share the dependency injection container configuration of the business module, which is used to ensure that the same business module can obtain the same dependency services in both modes, thus maintaining the consistency of business logic.

[0074] S508 shares the interface definitions and implementation logic of the page lifecycle event bus, container routing coordination service, and container navigation shutdown service with the first and second entry points. The only difference is in the initialization process and running mode, and the core functions are completely reused.

[0075] In a specific application scenario, when a user browses products in the food delivery channel and clicks to enter the product details page, the routing within the Flutter module changes. At this time, the container routing coordination service detects the route change. In standalone mode, it completes the page navigation within the current application; in embedded mode, it notifies the host application via a bridge channel to synchronously update the routing state of the top navigation bar. When the user completes an order in the food delivery channel and wants to return to the host application, it calls the container navigation shutdown service. Upon receiving the shutdown request, the host application closes the native container page hosting the Flutter module, taking the user back to the parent page of the host application. Throughout this process, the page lifecycle event bus continuously listens for page display, hiding, foreground / background switching events, ensuring that the page state is managed accordingly in both standalone and embedded modes. Business code is fully reusable, eliminating the need for separate development and maintenance for different modes.

[0076] Accordingly, see Figure 2 As shown, the present invention also provides a cross-platform application dual-entry modular operation system for implementing the aforementioned cross-platform application dual-entry modular operation method. The system includes an interface abstraction layer definition module, a scheduling management module, an independent entry module, an embedded entry module, and a code sharing module. The interface abstraction layer definition module is used to define the module interface abstraction layer, which includes lifecycle methods for module initialization, authentication token injection, dependency injection, route provision, and top-level interface component wrapping. The scheduling management module provides a module manager, registers and schedules business modules, and manages the initialization and lifecycle of the page lifecycle event bus, container routing coordination service, and container navigation shutdown service. An independent entry module is used to provide the first entry point, which completes dependency injection initialization, log initialization, and root application construction in an independent mode. The embedded entry module is used to provide a second entry point for embedded execution. The second entry point implements the interface defined by the module interface abstraction layer, is scheduled by the host application through the module manager, receives the authentication token injected by the host application, and returns the container entry route and the wrapped top-level interface component. The code sharing module is used for the first entry point and the second entry point to share business code, as well as the page lifecycle event bus, container routing coordination service, and container navigation shutdown service.

[0077] Correspondingly, such as Figure 3 As shown, this invention also provides a dual-entry modular operating architecture for cross-platform applications. This architecture adopts a three-layer design, consisting of an entry layer, a core contract layer, and a business platform layer from top to bottom: The runtime entry layer offers two deployment modes: Entry 1 is an independent project mode, where the cross-platform application is developed, compiled, and deployed as an independent project with a complete project lifecycle; Entry 2 is a submodule integration mode, where the application is integrated as a submodule of other projects, embedded into third-party host applications through dependency referencing to achieve modular reuse. Both entry modes share the same core contract layer and business platform layer, differing only in their startup methods.

[0078] The core contract layer, namely the underlying core contract library of flutter_core, defines the basic contracts and tools for modular operation. It includes four core components: IModule, a module contract interface used to standardize the lifecycle and behavior of all business modules; ModuleManager, a module manager responsible for module registration, loading, scheduling, and lifecycle management; NetworkService, an abstract network request interface used to define unified request parameters and response parsing specifications; and JsonParser, a secure and explosion-proof parser used to provide JSON data parsing and security verification capabilities to prevent malicious data attacks.

[0079] The business platform layer, namely the flutter_platform business platform module, completes the initialization and collaboration of core components through an adaptive assembly mechanism: business services are injected into the platform through the setupInjection dependency injection assembly center, including the DioNetworkService network service implementation and the UserProfileService user configuration service implementation; the MainModule module contract implementation class serves as the core carrier of business logic, constructs the ModuleBEntryPage route bridge container and dynamically manages AppRouter partial nested routes to achieve multi-level, nested page navigation.

[0080] In the business platform layer, setupInjection, the dependency injection assembly center, corresponds to the initialization process of the dependency injection container in step S30; MainModule, the module contract implementation class, corresponds to the business module scheduled by the second entry point in step S40; ModuleBEntryPage, the routing bridge container, corresponds to the container entry route returned in step S408; and AppRouter, the partially nested route, corresponds to the route matched by the chain of responsibility pattern in step S207.

[0081] The three-tier architecture uses the scheduling mechanism of the module manager to transmit data and control flows: the entry layer registers modules to the core contract layer, and the core contract layer schedules the business platform layer to complete the assembly and initialization through the module manager.

[0082] Accordingly, the present invention also provides an electronic device and a computer-readable storage medium, both of which have the corresponding effects of the cross-platform application dual-entry modular operation method provided in the embodiments of the present invention. Please refer to... Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0083] An electronic device provided by an embodiment of the present invention includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the dual-entry modular operation method for cross-platform applications described in the above embodiment.

[0084] Please see Figure 5Another electronic device provided in this embodiment of the invention further includes: an input port connected to a processor for transmitting commands input from the outside to the processor; a display unit connected to the processor for displaying the processor's processing results to the outside; and a communication module connected to the processor for enabling communication between the electronic device and the outside. The display unit can be a display panel, a laser scanner, or the like; the communication method used by the communication module includes, but is not limited to, Mobile High-Definition Link (MHL), Universal Serial Bus (USB), High-Definition Multimedia Interface (HDMI), wireless connectivity: Wireless Fidelity (WiFi), Bluetooth communication technology, Bluetooth Low Energy communication technology, and communication technology based on IEEE 802.11s.

[0085] The present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the dual-entry modular operation method for cross-platform applications as described in any of the above embodiments.

[0086] The computer-readable storage media involved in this invention include random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs (compact disc read-only memory), or any other form of storage media known in the art.

[0087] In summary, this invention defines a module interface abstraction layer as a common interface specification for business modules, and works with a module manager to achieve registration-based scheduling and lifecycle management of business modules. Based on a dual-entry architecture with an independent first entry point and an embedded second entry point, and combined with a shared mechanism of page lifecycle event bus, container routing coordination service, and container navigation shutdown service, this invention enables business code to be fully reused in both independent and embedded modes, modules to achieve dynamic registration and deregistration, lifecycle management to be shared, routing to be coordinated, and authentication tokens to be transmitted. This solves the problems of low code reuse rate, insufficient modularity, chaotic lifecycle management, complex routing management, and difficulty in transmitting authentication tokens in existing dual-entry technologies, improving code reuse rate and modularity, and enhancing the scalability and maintainability of business modules in dual-entry scenarios.

[0088] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0089] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A dual-entry modular operation method for cross-platform applications, characterized in that, Includes the following steps: S10, Define a module interface abstraction layer, which includes lifecycle methods for module initialization, authentication token injection, dependency injection, route provision, and top-level interface component wrapping; S20 provides a module manager to register and schedule business modules, and manage the initialization and lifecycle of the page lifecycle event bus, container routing coordination service, and container navigation shutdown service; S30 provides the first entry point, which completes dependency injection initialization, log initialization, and root application construction in independent mode; S40 provides a second entry point for embedded execution. The second entry point implements the interface defined by the module interface abstraction layer. It is scheduled by the host application through the module manager, receives the authentication token injected by the host application, and returns the container entry route and the wrapped top-level interface component. S50, the first entry point and the second entry point share the business code, and share the page lifecycle event bus, container routing coordination service and container navigation shutdown service.

2. The method for modular operation of a cross-platform application with dual entry points according to claim 1, characterized in that, In step S10, the module interface abstraction layer also includes methods for obtaining module name, obtaining token, routing, and providing localization.

3. The method for modular operation of a cross-platform application with dual entry points according to claim 1, characterized in that, In step S20, the module manager adopts a registration architecture, which supports the dynamic registration and deregistration of the business modules at runtime. After receiving the authentication token injected by the host application, the module manager distributes the authentication token to the registered business modules.

4. The method for modular operation of a cross-platform application with dual entry points according to claim 1, characterized in that, In step S20, the module manager initializes the dependency injection container of the registered business modules in parallel. The module manager's route provisioning method adopts the chain of responsibility pattern, traversing the registered business modules to match routes and returning the route constructor of the first successfully matched business module; the module manager's top-level interface component wrapping method adopts the decorator chain pattern, traversing the registered business modules to wrap basic top-level interface components and returning a composite top-level interface component.

5. The method for modular operation of a cross-platform application with dual entry points according to claim 1, characterized in that, In step S30, the first entry point completes dependency injection initialization, log initialization and root application construction in independent mode, including: completing Flutter engine binding, initializing the dependency injection container, registering basic services, initializing the logging system and enabling automatic capture, and running the root application in an exception capture environment.

6. The method for modular operation of a cross-platform application with dual entry points according to claim 1, characterized in that, In step S40, after receiving the authentication token injected by the host application, the second entry point injects the authentication token into the network service and the token refresh manager to complete the network layer authentication state initialization.

7. The method for modular operation of a cross-platform application with dual entry points according to claim 1, characterized in that, In step S40, the container entry route returned by the second entry is configured to create a native container page that carries the Flutter module on the host application side. The top-level interface component returned by the second entry is sequentially packaged by state management injection, screen adaptation and translation provider.

8. The method for modular operation of a cross-platform application with dual entry points according to claim 1, characterized in that, In step S50, the page lifecycle event bus is a static event bus implemented using the Dart language, adopting the observer pattern, and providing lifecycle callbacks for page display, page hiding, foreground / background switching, and page route changes.

9. The method for modular operation of a cross-platform application with dual entry points according to claim 1, characterized in that, In step S50, the container routing coordination service is responsible for maintaining the mapping between container identifiers and initial routes, and is used to notify the host application to synchronize the route status when the route changes within the Flutter module; the container navigation shutdown service is used for the Flutter module to actively request the host application to shut down the current Flutter container.

10. A cross-platform application with dual entry points and modular operation system, used to implement the method as described in any one of claims 1 to 9, characterized in that, The system includes an interface abstraction layer definition module, a scheduling management module, an independent entry module, an embedded entry module, and a code sharing module; The interface abstraction layer definition module is used to define the module interface abstraction layer, which includes lifecycle methods for module initialization, authentication token injection, dependency injection, route provision, and top-level interface component wrapping. The scheduling management module is used to provide a module manager, register and schedule business modules, and manage the initialization and lifecycle of the page lifecycle event bus, container routing coordination service, and container navigation shutdown service. The independent entry module is used to provide a first entry point, which completes dependency injection initialization, log initialization and root application construction in an independent mode; The embedded entry module is used to provide a second entry point for embedded operation. The second entry point implements the interface defined by the module interface abstraction layer, is scheduled by the host application through the module manager, receives the authentication token injected by the host application, and returns the container entry route and the wrapped top-level interface component. The code sharing module is used to share business code between the first entry point and the second entry point, and to share the page lifecycle event bus, container routing coordination service, and container navigation shutdown service.

Images