Plug-in-based Widget implementation method and related equipment

Abstract

The invention discloses a plugin-based Widget implementation method and related equipment, relates to the field of mobile application development, and mainly aims to solve the problem that the layout of the current Widget function is too rigid and not intelligent enough. The method comprises the following steps: querying a plug-in component information list through a preset identifier to obtain key component information; obtaining a dual-environment view instance based on the key component information; the dual-environment view instance is integrated into a host Wi-get container to achieve a dual-environment operation system of Widget, and the dual-environment operation system comprises a host operation environment and a plug-in operation environment. The Widget implementation method and device are used for the Widget implementation process based on plug-in.

Description

Technical Field

[0001] The present invention relates to the field of mobile application development, and in particular to a plug-in-based Widget implementation method and related equipment. Background Art

[0002] In Android application development, widgets, as an important component of the user interface, can provide users with quick information and operation access without opening the main application. However, traditional widget implementations have significant flaws, limiting their flexibility and intelligence.

[0003] Specifically, they include: 1. High functional coupling and cumbersome updates: Widget functionality is deeply bound to the host application. Any functional iteration or fix requires re-releasing and updating the entire host application, making independent, dynamic updates of the widget impossible. 2. Limited view capabilities and rigid layout: Android's native widget solution only supports the display of specific, system-defined View components and cannot integrate more complex, developer-defined UI components and interaction logic. This results in the widget's layout and functional presentation being overly simple and rigid, lacking flexibility. It cannot be intelligently and dynamically adjusted and adapted to user needs, scenario changes, or device characteristics, limiting the user experience. Summary of the Invention

[0004] In view of the above problems, the present invention provides a plug-in-based Widget implementation method and related devices, the main purpose of which is to solve the problem that the current Widget function layout is too rigid and not intelligent enough.

[0005] To solve at least one of the above technical problems, in a first aspect, the present invention provides a plug-in-based Widget implementation method, the method comprising:

[0006] Query the plug-in component information list by the preset identifier to obtain key component information;

[0007] Acquire a dual environment view instance based on the key component information;

[0008] The dual-environment view instance is integrated into the host Widget container to implement a dual-environment operating system of the Widget, wherein the dual-environment operating system includes a host operating environment and a plug-in operating environment.

[0009] Optionally, the above method further includes:

[0010] Define a globally unique preset identifier in the component configuration of the plug-in application;

[0011] A communication protocol between the plug-in and the host is established through the preset identifier.

[0012] Optionally, querying the plug-in component information list by using a preset identifier to obtain key component information includes:

[0013] Control the host application's query permissions for plug-in applications declared in the configuration file;

[0014] Querying the plug-in component information list based on the preset identifier to obtain an initial query result;

[0015] A validity check is performed on the initial query result to extract key component information.

[0016] Optionally, obtaining a dual-environment view instance based on the key component information includes:

[0017] Delivering a dual-environment context to a plug-in resource based on the key component information, wherein the dual-environment context includes a host context and a plug-in context;

[0018] Calling the predefined view generation interface in the plug-in resource through the reflection mechanism;

[0019] The host context and the plug-in context are passed as parameters to the view generation interface to generate the dual-environment view instance, wherein the dual-environment view instance implements cross-environment compatibility encapsulation.

[0020] Optionally, the step of passing the host context and the plug-in context as parameters into the view generation interface to generate a view instance includes:

[0021] The core logic of the view is loaded using the host context, wherein the core logic includes event processing and data calculation modules;

[0022] The static resources of the view are loaded using the plugin context, wherein the static resources include images, localized texts, and style sheet files.

[0023] Optionally, integrating the dual-environment view instance into a host Widget container to implement a dual-environment operating system for the Widget includes:

[0024] Integrating the dual-environment view instance into the host Widget container to determine the plug-in view;

[0025] The plug-in view is subjected to dual-environment bridging processing to realize a dual-environment operating system of the Widget.

[0026] Optionally, performing dual-environment bridging processing on the plug-in view to implement a dual-environment operating system of the Widget includes:

[0027] Establishing a host runtime environment interception and forwarding mechanism for events of the plug-in view;

[0028] Implementing transparent access to the plugin view in the host environment;

[0029] Establishing a lifecycle linkage mechanism between the plug-in view and the host Widget container, wherein the lifecycle linkage mechanism includes a state synchronization trigger and an abnormality fuse strategy;

[0030] Render the plugin view in the host environment.

[0031] In a second aspect, an embodiment of the present invention further provides a plug-in-based Widget implementation device, including:

[0032] A query unit, configured to query a plug-in component information list through a preset identifier to obtain key component information;

[0033] an acquiring unit, configured to acquire a dual-environment view instance based on the key component information;

[0034] The integration unit is used to integrate the dual-environment view instance into the host Widget container to implement a dual-environment operating system of the Widget, wherein the dual-environment operating system includes a host operating environment and a plug-in operating environment.

[0035] To achieve the above object, according to a third aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored program, wherein when the program is executed by a processor, the steps of the above plug-in-based Widget implementation method are implemented.

[0036] To achieve the above-mentioned objective, according to a fourth aspect of the present invention, there is provided an electronic device comprising at least one processor and at least one memory connected to the processor; wherein the processor is configured to call program instructions in the memory to execute the steps of the above-mentioned plug-in-based Widget implementation method.

[0037] Through the above technical solution, the plug-in-based Widget implementation method and related equipment provided by the present invention solve the problem that the current layout of Widget functions is too rigid and not intelligent enough. The present invention queries the plug-in component information list through a preset identifier to obtain key component information; obtains a dual-environment view instance based on the key component information; and integrates the dual-environment view instance into the host Widget container to implement the Widget's dual-environment operating system, wherein the dual-environment operating system includes a host operating environment and a plug-in operating environment. In the above scheme, the plug-in customized dual-environment view that carries the intelligent layout capability is located and obtained through a preset identifier, and then the dual-environment operating system is used to ensure that the view can run in a securely isolated and seamlessly integrated manner within the host Widget container, thereby completely breaking the view limitations and layout rigidity of the native Widget, and providing infrastructure support for the Widget to achieve flexible, dynamic, and intelligent layout.

[0038] Correspondingly, the plug-in-based Widget implementation device, equipment, and computer-readable storage medium provided by the embodiments of the present invention also have the above-mentioned technical effects.

[0039] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are specifically listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present invention. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0041] Figure 1 A schematic diagram of a plug-in-based Widget implementation method provided by an embodiment of the present invention is shown;

[0042] Figure 2 A schematic block diagram showing the composition of a plug-in-based Widget implementation device provided by an embodiment of the present invention is shown;

[0043] Figure 3 A schematic block diagram of the composition of an electronic device implemented based on a plug-in Widget provided by an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0044] Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present invention and to fully convey the scope of the present invention to those skilled in the art.

[0045] In order to solve the problem that the current layout of Widget functions is too rigid and not intelligent enough, the embodiment of the present invention provides a Widget implementation method based on plug-in, such as Figure 1 As shown, the method includes:

[0046] S101, querying the plug-in component information list through a preset identifier to obtain key component information;

[0047] Before the step S101, the following steps are also included:

[0048] Define a globally unique preset identifier in the component configuration of the plug-in application;

[0049] A communication protocol between the plug-in and the host is established through the preset identifier.

[0050] For example, the essence of the preset identifier is the global addressing anchor of the plug-in component. The "preset identifier" defined in the component configuration of the plug-in application is essentially a logical address label that is unique within the system. This identifier is in the form of a string, and its core function is to provide the host application with an addressing basis for accurately locating the plug-in component. Since the identifier must meet the global uniqueness constraint, it ensures that the host can accurately distinguish the functional modules provided by different plug-ins during querying, avoiding address conflicts in multi-plug-in scenarios. This is equivalent to establishing independent "coordinates" for each plug-in function. The host only needs to use this coordinate to lock the target plug-in resource in the huge component registry of the Android system.

[0051] For example, the communication protocol builds a secure cross-application interaction channel. The "communication protocol" established through preset identifiers is essentially a standardized data exchange rule agreed upon between the host and the plug-in. The protocol includes three core layers of collaborative mechanisms: Addressing layer: The host uses the identifier to initiate a targeted query to the system to obtain the component metadata exposed by the plug-in. Calling layer: Based on the query results, the host dynamically loads the plug-in class through the reflection mechanism and calls its predefined view generation interface. At this point, the protocol stipulates the signature specifications of the interface, such as the dual parameters of the host context and the plug-in context. Resource isolation layer: The protocol enforces the rules for loading runtime resources - event processing and core logic use the host context to ensure permission consistency, while static resources such as images and text are loaded through the plug-in context to achieve resource decoupling. This dual-environment context transfer mechanism not only ensures the safe operation of the plug-in view within the host container, but also retains its independent resource scheduling capabilities.

[0052] This design, through the dual constraints of identifiers and protocols, enables controlled collaboration across application boundaries. Pre-defined identifiers address the problem of "how to find plugins," while the communication protocol defines the interaction rules for "how to safely use plugin functionality." Together, these two form the foundational communication framework of the plug-in architecture, enabling the host to dynamically integrate and run the customized view capabilities provided by plugins without code coupling, while effectively mitigating the risks of resource conflicts and permission violations.

[0053] In one embodiment, querying the plug-in component information list using a preset identifier to obtain key component information includes:

[0054] Control the host application's query permissions for plug-in applications declared in the configuration file;

[0055] Querying the plug-in component information list based on the preset identifier to obtain an initial query result;

[0056] A validity check is performed on the initial query result to extract key component information.

[0057] For example, "the host application declares query permissions in the configuration file" means that the host application declares query permissions in the AndroidManifest.xml file. <queries>The tag explicitly declares access permissions for the target plugin package name or preset identifier. This overrides Android's default cross-app visibility restrictions. Essentially, it declares a legitimate communication contract between the host and the plugin to the system, establishing a whitelist channel for subsequent queries.

[0058] For example, "querying the plugin component information list based on a preset identifier" means the host constructs an Intent request with the identifier as the core filtering condition, such as setting the Action to a preset string and calling the queryIntentActivities() interface of the PackageManager service. The underlying system scans the component registries of all installed applications and returns a dataset of raw components matching the identifier (a ResolveInfo list), including metadata such as the package name, class name, and resource path of the plugin's exposed components.

[0059] The "validity check of the initial query results" mentioned above includes three layers of protection logic: existence check: filters out empty lists or invalid entries to ensure that at least one component is available; reachability check: uses the class loader to detect whether the target class plug-in Activity can be instantiated to avoid the risk of plug-in installation failure or version conflicts; protocol compliance check: verifies whether the component implements the agreed interface, such as the view generation method signature, to ensure the security of subsequent reflection calls.

[0060] The key component information ultimately extracted through this technical solution specifically refers to the verified fully qualified name of the plugin class and its resource handle. This information forms the cornerstone of dynamic loading—the class name is used to reflectively instantiate the functional object, while the resource handle supports subsequent dual-environment resource scheduling. The entire process collaborates through three stages: system-level permission declaration, component metadata retrieval, and multi-dimensional verification. This creates a controllable channel for functional expansion within Android's strict application isolation mechanism.

[0061] S102 acquires a dual environment view instance based on the key component information;

[0062] In one embodiment, obtaining a dual-environment view instance based on the key component information includes:

[0063] Delivering a dual-environment context to a plug-in resource based on the key component information, wherein the dual-environment context includes a host context and a plug-in context;

[0064] Calling the predefined view generation interface in the plug-in resource through the reflection mechanism;

[0065] The host context and the plug-in context are passed as parameters to the view generation interface to generate the dual-environment view instance, wherein the dual-environment view instance implements cross-environment compatibility encapsulation.

[0066] For example, "key component information" refers to the fully qualified name of the plug-in class (such as com.plugin.WidgetViewFactory) obtained through preliminary query and verification. Its essence is the navigation coordinates for locating the plug-in view generation capability; "dual environment context" contains two core parameters: the host context is the handle of the host application runtime environment, which carries the host permission system and system service access capabilities; the plugin context is the entrance to the plugin's own resource sandbox, providing an independent resource loading path but stripping away key runtime permissions.

[0067] The specific collaboration process described above is divided into three phases. In the first phase, the host injects the dual-environment context into the plugin's resource domain. The host context grants the plugin view legal authority to draw interfaces and handle events within the host container. For example, the plugin context provides it with a dedicated resource isolation zone for accessing system services, such as images and multilingual text. This creates a complementary operating foundation of "host permissions + plugin resources." In the second phase, the plugin's predefined view generation interface, such as createPluginView(Context hostCtx, Context pluginCtx), is located and invoked through reflection. Reflection acts as a bridge for cross-application code execution, bypassing the compile-time limitations of traditional component binding and enabling the host to trigger internal plugin methods on demand. In the third phase, the dual-environment context is passed as a parameter to the view generation interface, driving the construction of a dual-environment view instance within the plugin. This instance is essentially a custom View object that has been encapsulated for cross-environment compatibility: at the functional level, its core logic, such as event processing and data calculation, is bound to the host context to ensure that the behavior complies with the host security policy; at the resource level, static resource loading relies on the plug-in context to avoid conflicts with host resources; at the architectural level, cross-environment compatibility encapsulation is achieved through interface constraints, that is, the view is pre-adapted to the dual environment within the plug-in, such as rewriting the resource loading method, so that the same view can respond to host environment events and plug-in resource requests at the same time.

[0068] Using this technical solution, the resulting dual-environment view instance becomes the functional carrier of the host widget container, inheriting the host's environmental compatibility, such as lifecycle synchronization and permission compliance, while retaining the plugin's independent layout capabilities, laying the foundation for subsequent intelligent dynamic rendering. This entire process utilizes a triple design approach: context-separated delivery, reflective dynamic binding, and interface-enforced constraints, achieving seamless integration of cross-application view capabilities while ensuring secure isolation.

[0069] In one embodiment, the step of passing the host context and the plug-in context as parameters into the view generation interface to generate a view instance includes:

[0070] The core logic of the view is loaded using the host context, wherein the core logic includes event processing and data calculation modules;

[0071] The static resources of the view are loaded using the plugin context, wherein the static resources include images, localized texts, and style sheet files.

[0072] For example, the "host context" is the control handle for the host application's runtime environment, carrying its permissions system, access to system services, and lifecycle status. The "plugin context" is the access point to the plugin's independent resource sandbox, retaining only the resource loading path but stripping away critical runtime permissions. The two complement each other through a dual-environment architecture.

[0073] The aforementioned core logic is bound to the host context. The core logic of the view, including user interaction event processing, data calculation, and business logic modules, is mandatory for loading from the host context. The main context inherits the host application's permission identifiers, such as network access and location acquisition, to ensure that the plug-in view complies with system security policies when performing sensitive operations and avoids permission violations. Event processing logic, such as click response and gesture recognition, can directly use the host's environmental parameters, such as theme configuration and screen density, after being bound to the host context, allowing interactive behaviors to seamlessly integrate with the host UI system. The data calculation module accesses its lifecycle status through the host context, achieving state linkage with the host container and reducing the risk of resource leakage.

[0074] The aforementioned static resources are isolated from the plugin context. View static resources, including image assets, localized multilingual text, and stylesheets, are strictly loaded through the plugin context. The plugin context maintains an independent resource index table, completely isolating the ID assignment of plugin resources, such as R.drawable.plugin_icon, from host resources, thus completely avoiding resource ID conflicts. The plugin context points to the private resource path of the plugin APK, allowing the host to load static resources such as images and text added or modified by the plugin without repackaging. When localized text and stylesheets are loaded through the plugin context, they automatically match the current system language, screen size, and other configurations, preserving the plugin's inherent adaptability.

[0075] This division of labor is essentially based on the architectural principle of "dynamic behavior hosted, static resources plug-in." By binding core logic to the host context, plug-in views obtain the "credentials" to securely execute dynamic code within the host container while inheriting the host's environmental compatibility. Loading static resources through the plug-in context establishes a resource supply channel independent of the host, ensuring resource update freedom while avoiding contamination of the host's resource pool. Together, these two contribute to the full operational capability of a dual-environment view instance: the host environment grants it legitimacy and vitality, while the plug-in environment provides a dynamically iterable visual expression platform, jointly supporting the flexible layout and intelligent rendering of plug-in widgets.

[0076] S103: Integrate the dual-environment view instance into the host Widget container to implement a dual-environment operating system of the Widget, wherein the dual-environment operating system includes a host operating environment and a plug-in operating environment.

[0077] For example, the "host widget container" is the component that hosts native Android widgets, providing basic view mounting and system communication capabilities. The "dual-environment runtime system" refers to a parallel execution framework consisting of the host runtime environment (a sandbox that inherits the host application's permissions and lifecycle) and the plugin runtime environment (a plugin resource isolation domain).

[0078] This application adds a custom plugin view as a child control to the host widget container's view tree, enabling it to render in host scenes such as the system desktop. Drawing instructions for the plugin view are then passed to the system rendering pipeline via the host container, but the plugin still maintains control over its internal layout logic. This achieves view layer mounting.

[0079] Dynamic behaviors are taken over by the host runtime environment: event processing, such as clicks and touches, are forwarded to the plug-in view via the host container's event bus to ensure that input responses comply with the host's security policy; lifecycle states, such as container destruction, are synchronously triggered by the host environment to trigger the plug-in view's state callback to avoid memory leaks. Static resources are independently supported by the plug-in runtime environment: operations such as image drawing and text rendering access private resource paths through the plug-in context, which are physically isolated from host resources to form a self-contained visual expression system. A communication channel is established between the two environments. The host environment injects state synchronization triggers, such as screen rotation events, into the plug-in view. The plug-in environment then returns layout recalculation requests through predefined interfaces to achieve intelligent adaptation for cross-environment collaboration.

[0080] This dual-environment runtime system addresses the architectural rigidity of native widgets by balancing environmental isolation with behavioral collaboration. The core logic of the plugin view runs within the host environment sandbox, subject to the host's permission system. Resource loading is contained within the plugin environment, preventing contamination of the host's resource pool. The host container only needs to maintain the basic framework, while the plugin view dynamically provides specific layout capabilities through the plugin environment, enabling "hot swapping" of widget functionality. The dual environments enable bidirectional communication at the protocol layer. For example, when the host notifies you of size changes, the plugin requests data refreshes. This allows the plugin view to adjust its layout strategy in real time based on the host environment's state, supporting adaptive rendering of complex scenes.

[0081] In one embodiment, integrating the dual-environment view instance into the host Widget container to implement a dual-environment operating system for the Widget includes:

[0082] Integrating the dual-environment view instance into the host Widget container to determine the plug-in view;

[0083] The plug-in view is subjected to dual-environment bridging processing to realize a dual-environment operating system of the Widget.

[0084] For example, a dual-environment view instance is embedded as a child control within the host widget container's view tree, completing the physical integration. At this point, the plugin view gains access to the system rendering pipeline, but its internal layout logic remains autonomously controlled. The essence of identifying the plugin view is establishing an environment-association mapping: the host container records the dual-environment context references (host context + plugin context) for the view instance, forming a "container-hosted view, view-bound dual-environment" topology, laying the foundation for subsequent bridging.

[0085] This application establishes a host environment mechanism for intercepting and forwarding plugin view events, such as touch events. The host container prioritizes capturing raw events, forwarding them to the plugin view's core logic after security verification, and using the host context for processing, preventing plugins from directly listening to system events and potentially overstepping permissions. This provides transparent access to plugin views within the host environment. When a plugin view needs to load static resources such as images or text, it automatically redirects to the plugin context resource pipeline, such as pluginContext.getDrawable(). The host container acts only as a transparent proxy and does not participate in resource resolution. The plugin view's state is linked to the host container's through state synchronization triggers (such as onResume / onPause) and exception-handling strategies (such as switching to the default view when the plugin crashes). When the host environment triggers a lifecycle event, the corresponding callback method of the plugin view is synchronously invoked through the bridge layer to ensure consistent memory management with the host. Ultimately, the host environment coordinates the system rendering pipeline. Drawing instructions for the plugin view are delivered to the system via the host container, but internal rendering content is generated by the plugin's resource environment, forming a collaborative rendering model where the host drives the framework and the plugin fills in the content.

[0086] Through these technical solutions, event interception mechanisms reduce security risks, transparent resource access avoids conflicts, and lifecycle linkage improves stability. Ultimately, plugin views can reuse the basic capabilities of the host environment while unleashing the flexibility of custom layouts, completely breaking through the view limitations of native widgets.

[0087] In one embodiment, performing dual-environment bridging processing on the plug-in view to implement a dual-environment operating system of the Widget includes:

[0088] Establishing a host runtime environment interception and forwarding mechanism for events of the plug-in view;

[0089] Implementing transparent access to the plugin view in the host environment;

[0090] Establishing a lifecycle linkage mechanism between the plug-in view and the host Widget container, wherein the lifecycle linkage mechanism includes a state synchronization trigger and an abnormality fuse strategy;

[0091] Render the plugin view in the host environment.

[0092] For example, the host runtime environment acts as a security sandbox, establishing an event filtering layer between the plug-in view and the system: interception: The host container captures raw input events (such as touch and key presses) and performs permission verification (for example, to prevent the plug-in from unauthorized access to sensitive operations); forwarding: Qualified events are directed to the core logic module of the plug-in view via the event bus (processed using the host context). This mechanism ensures that the plug-in can only respond to a limited set of events filtered by the host environment, reducing security risks at the source while maintaining the integrity of interactive functions.

[0093] Transparent access refers to the ability of plugin views to directly access their own resources within the host environment. When a plugin view executes a resource-loading instruction, the access request is automatically redirected to the plugin runtime environment's resource pipeline. The host container acts only as a transparent proxy, not resolving resource paths or IDs. Instead, it directly retrieves the resource byte stream through the pre-bound plugin context (e.g., pluginContext.getResources()). This enables "physically isolated but logically direct" access to plugin resources (such as images and localized text) within the host framework, completely avoiding resource conflicts.

[0094] This application achieves a strong correlation between the two environments' states through state synchronization triggers and an exception circuit breaking strategy: When host container lifecycle events (such as onResume / onDestroy) are triggered, the corresponding callback methods of the plugin view (such as onAttachedToWindow / onDetachedFromWindow) are automatically called. This enables the plugin view to perceive changes in the host environment's state and promptly start and stop background tasks, significantly reducing the probability of memory leaks. When a plugin view crashes or times out, the host environment automatically switches to a degraded view and logs the exception information. This strategy isolates plugin failures within a separate sandbox, preventing the entire host widget from failing. Ultimately, the host runtime environment centrally schedules the system-level rendering pipeline: Drawing instructions for the plugin view are passed through the host container to the system rendering engine. Driven by the plugin's custom logic, static elements such as images and text are loaded through the plugin context. The host context is used to obtain the system canvas object to ensure rendering permission compliance. This creates a collaborative model where "the host provides the canvas, and the plugin draws the picture," satisfying the constraints of the system rendering framework while preserving the layout freedom of the plugin view.

[0095] Through this technical solution, the aforementioned event mechanism achieves controlled free interaction through host proxy filtering, preserving functional integrity while maintaining secure isolation. Transparent access achieves resource decoupling through environment redirection, allowing plugin resources to be updated independently without relying on the host. Lifecycle linkage builds a resilient collaboration framework through state synchronization and circuit breaking strategies, minimizing the impact of plugin failures. Host rendering ultimately completes cross-environment synthesis at the system level, giving plugin views the same rendering capabilities as native components. These four elements together form the technical backbone of the dual-environment operating system, enabling plugin-based widgets to achieve dynamic expansion and intelligent evolution of layout capabilities within Android's strict application isolation model.

[0096] In summary, the plug-in-based widget implementation method provided by the present invention queries and obtains the customized dual-environment view instance provided by the plug-in through a preset identifier. This mechanism breaks through the limitation that native Android widgets can only use predefined system views, allowing the widget container to dynamically integrate any customized UI components designed by developers with richer functions and more flexible layouts. The core defects of rigid layout and single view capabilities are optimized. The obtained custom view instance is integrated into the host widget container, and a dual-environment operating system of host environment + plug-in environment is established: the plug-in customized view is allowed to run within the host widget container, enabling it to utilize the basic capabilities of the host environment such as events and lifecycles. At the same time, the plug-in's own resource context is retained. This enables the plug-in view to carry and apply the intelligent layout logic implemented within it without the host environment forcing its layout behavior to be constrained. The "dual-environment view instance" itself is a plug-in view that has been encapsulated to achieve cross-environment compatibility. It is dynamically injected into the host widget container as an independent functional module and layout carrier. This means that the layout and functional logic of the widget are completely decoupled from the host application and can be independently developed, updated, and deployed. Plugin developers can freely implement complex and intelligent layout strategies in their custom views. The host widget container only needs to provide a running framework without having to predict or hard-code specific layout details, thus naturally supporting layout diversity and intelligent evolution.

[0097] Furthermore, as a response to the above Figure 1 In addition to the implementation of the method shown in the figure, the embodiment of the present invention also provides a plug-in based Widget implementation device for the above Figure 1 This device embodiment corresponds to the aforementioned method embodiment. For ease of reading, this device embodiment will not describe the details of the aforementioned method embodiment one by one, but it should be clear that the device in this embodiment can implement all the contents of the aforementioned method embodiment. Figure 2 As shown, the device includes: a query unit 21, an acquisition unit 22, and an integration unit 23, wherein

[0098] A query unit 21 is configured to query a plug-in component information list using a preset identifier to obtain key component information;

[0099] an acquiring unit 22, configured to acquire a dual-environment view instance based on the key component information;

[0100] The integration unit 23 is configured to integrate the dual-environment view instance into the host Widget container to implement a dual-environment operating system of the Widget, wherein the dual-environment operating system includes a host operating environment and a plug-in operating environment.

[0101] The processor contains a kernel, which retrieves the corresponding program unit from memory. One or more kernels can be configured, and by adjusting kernel parameters, a plug-in-based widget implementation method can be implemented, addressing the current problem of widget functionality being too rigid and lacking in intelligence.

[0102] An embodiment of the present invention provides a computer-readable storage medium, which includes a stored program. When the program is executed by a processor, the program implements the plug-in-based Widget implementation method.

[0103] An embodiment of the present invention provides a processor, which is used to run a program, wherein the plug-in-based Widget implementation method is executed when the program is running.

[0104] An embodiment of the present invention provides an electronic device, comprising at least one processor and at least one memory connected to the processor; wherein the processor is configured to call program instructions in the memory to execute the above-mentioned plug-in-based Widget implementation method.

[0105] An embodiment of the present invention provides an electronic device 30, such as Figure 3 As shown, the electronic device includes at least one processor 301, and at least one memory 302 and a bus 303 connected to the processor; wherein the processor 301 and the memory 302 communicate with each other through the bus 303; the processor 301 is used to call the program instructions in the memory to execute the above-mentioned plug-in-based Widget implementation method.

[0106] The intelligent electronic devices in this article can be PCs, PADs, mobile phones, etc.

[0107] The present application also provides a computer program product, which, when executed on a process management electronic device, is suitable for executing a program that initializes the above-mentioned plug-in-based Widget implementation method steps.

[0108] It should be noted that, in the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0109] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0110] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0111] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0112] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0113] The present application also provides a computer program product, which includes computer software instructions. When the computer software instructions are executed on a processing device, the processing device is caused to execute the following Figure 1 This corresponds to the flow of memory control in the embodiment.

[0114] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0115] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0116] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0117] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0118] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0119] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0120] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.< / queries>

Claims

1. A plug-in based Widget implementation method, characterized in that: include: Query the plug-in component information list by the preset identifier to obtain key component information; Acquire a dual environment view instance based on the key component information; The dual-environment view instance is integrated into the host Widget container to implement a dual-environment operating system of the Widget, wherein the dual-environment operating system includes a host operating environment and a plug-in operating environment.

2. The method according to claim 1, characterized in that Also includes: Define a globally unique preset identifier in the component configuration of the plug-in application; A communication protocol between the plug-in and the host is established through the preset identifier.

3. The method according to claim 1, characterized in that The step of querying the plug-in component information list by using a preset identifier to obtain key component information includes: Control the host application's query permissions for plug-in applications declared in the configuration file; Querying the plug-in component information list based on the preset identifier to obtain an initial query result; A validity check is performed on the initial query result to extract key component information.

4. The method according to claim 1, wherein The acquiring of a dual-environment view instance based on the key component information includes: Delivering a dual-environment context to a plug-in resource based on the key component information, wherein the dual-environment context includes a host context and a plug-in context; Calling the predefined view generation interface in the plug-in resource through the reflection mechanism; The host context and the plug-in context are passed as parameters to the view generation interface to generate the dual-environment view instance, wherein the dual-environment view instance implements cross-environment compatibility encapsulation.

5. The method according to claim 4, characterized in that The step of passing the host context and the plug-in context as parameters into the view generation interface to generate a view instance includes: The core logic of the view is loaded using the host context, wherein the core logic includes event processing and data calculation modules; The static resources of the view are loaded using the plugin context, wherein the static resources include images, localized texts, and style sheet files.

6. The method according to claim 1, characterized in that Integrating the dual-environment view instance into the host Widget container to implement the dual-environment operating system of the Widget includes: Integrating the dual-environment view instance into the host Widget container to determine the plug-in view; The plug-in view is subjected to dual-environment bridging processing to realize a dual-environment operating system of the Widget.

7. The method according to claim 1, characterized in that The dual-environment bridging process is performed on the plug-in view to realize the dual-environment operation system of the Widget, including: Establishing a host runtime environment interception and forwarding mechanism for events of the plug-in view; Implementing transparent access to the plugin view in the host environment; Establishing a lifecycle linkage mechanism between the plug-in view and the host Widget container, wherein the lifecycle linkage mechanism includes a state synchronization trigger and an abnormality fuse strategy; Render the plugin view in the host environment.

8. A plug-in based Widget implementation device, characterized in that: Also includes: A query unit, configured to query a plug-in component information list through a preset identifier to obtain key component information; an acquiring unit, configured to acquire a dual-environment view instance based on the key component information; The integration unit is used to integrate the dual-environment view instance into the host Widget container to implement a dual-environment operating system of the Widget, wherein the dual-environment operating system includes a host operating environment and a plug-in operating environment.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored program, wherein when the program is executed by a processor, the steps of the plug-in-based Widget implementation method according to any one of claims 1 to 7 are implemented.

10. An electronic device, characterized in that: The electronic device includes at least one processor and at least one memory connected to the processor; wherein the processor is used to call program instructions in the memory to execute the steps of the plug-in-based Widget implementation method according to any one of claims 1 to 7.

Images