Methods, systems, computer devices and computer program products for dynamic switching of multi-state interfaces
By removing the target view in a multi-state interface and updating the displayed content according to the loading status, the problem of independent refresh of sub-display areas in a multi-functional page is solved, improving user experience and interface consistency.
Patent Information
- Application Number
- CN202510855440.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-25
- Publication Date
- 2025-12-02
- Estimated Expiration
- 2045-06-25
AI Technical Summary
Existing technologies make it difficult to independently refresh each sub-display area in a multi-functional page, resulting in a decline in user experience. Especially when the content sources and display logic are different, a unified interface prompt cannot meet the needs of each scenario and is likely to confuse users.
By removing the target view when the data flow manager of the sub-display area generates a data flow event, determining the target callback object based on the loading status, determining the latest state view based on the current and target callback objects, and updating the display content using a dynamic container, independent refresh of multiple sub-display areas of the same interface can be achieved.
It enables independent refreshing of different state sub-display areas on the same display interface, improving the user experience and ensuring the independence and consistency of content display and state switching in each sub-display area.
Smart Images

Figure CN120371448B_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of computer front-end technology, and in particular relates to a method, system, computer device and computer program product for dynamic switching of multi-state interface. Background Technology
[0002] In today's world of increasingly rich internet content, users' expectations for interface feedback are constantly rising. When opening a page, if there's a prolonged period without content or a sudden error, it often creates the illusion of "lag" or "crash." Conversely, well-timed prompts and appropriate transition animations can make users feel smooth and reassured. Especially in scenarios with frequent information acquisition and content updates, clearly conveying statuses such as "preparing," "no data available," or "loading error" to users has become a crucial aspect for applications to improve user experience.
[0003] Meanwhile, as business processes evolve, a single page often hosts multiple functional modules—news recommendations, product lists, comment sections, and more. Each module has different content sources and display logic. Using a single, uniform method to display "Please wait" or "Loading failed" makes it difficult to cater to the specific needs of each scenario and can easily confuse users. If a portion of content fails to display correctly, but the entire page is still blocked, the overall user experience can be significantly compromised.
[0004] Given the above background, there is an urgent need for a page refresh method to improve the user experience. Summary of the Invention
[0005] In view of this, embodiments of this application provide a method, system, computer device, and computer program product for dynamic switching of multi-state interfaces, so as to achieve independent refresh of display areas of multiple different states of the same interface.
[0006] A first aspect of this application provides a method for dynamically switching between multiple states of an interface, the method comprising:
[0007] For each sub-display area of the current display interface, if the target view corresponding to the sub-display area is not empty when the data flow manager of the sub-display area generates a data flow event, then the target view is removed.
[0008] The target callback object is determined based on the loading status of the data stream manager of the sub-display area;
[0009] Determine the latest state view based on the current callback object and the target callback object;
[0010] The display content of the sub-display area is updated based on the dynamic container and the latest state view.
[0011] In one implementation of the first aspect, determining the latest state view based on the current callback object and the target callback object includes:
[0012] If the target callback object is different from the current callback object, the target state view corresponding to the target callback object is determined to be the latest state view;
[0013] If the target callback object is the same as the current callback object, the current state view corresponding to the current callback object is determined to be the latest state view.
[0014] In one implementation of the first aspect, updating the display content of the sub-display area based on the dynamic container and the latest state view includes:
[0015] If the latest state view is the target state view, remove the current state view from the custom dynamic container;
[0016] Load the latest state view into the dynamic container;
[0017] Add the dynamic container to the parent container of the target view and update the display content of the child display area.
[0018] In one implementation of the first aspect, before removing the target view for each sub-display area of the current display interface when the data flow manager of the sub-display area generates a data flow event, if the target view corresponding to the sub-display area is not empty, the method further includes:
[0019] Obtain the context of the target view;
[0020] Based on the context, obtain the parent container of the target view and the index of the target view in the parent container;
[0021] The step of adding the dynamic container to the parent container of the target view and updating the display content of the child display area includes:
[0022] Based on the index of the target view in the parent container, the dynamic container is added to the parent container of the target view, and the display content of the child display area is updated;
[0023] The removal of the target view includes:
[0024] Remove the target view from the parent container based on the index of the target view within the parent container.
[0025] In one implementation of the first aspect, after updating the display content of the sub-display area based on the dynamic container and the latest state view, the method further includes:
[0026] If the data flow manager of the sub-display area successfully acquires the target display data, remove the latest status view from the dynamic container;
[0027] Re-add the target view to its parent container;
[0028] Bind the target display data to the target view and update the display content of the sub-display area.
[0029] In one implementation of the first aspect, before determining the latest state view based on the current callback object and the target callback object, the method further includes:
[0030] Construct a corresponding state view in the callback object corresponding to each loading state of the data flow manager;
[0031] Each loading state of the data flow manager is mapped to its corresponding callback object and stored in a mapping table.
[0032] In one implementation of the first aspect, determining the target callback object based on the loading state of the data stream manager of the sub-display area includes:
[0033] The corresponding target callback object is searched in the mapping table based on the loading status of the data stream manager of the sub-display area.
[0034] A second aspect of this application provides a multi-state interface dynamic switching system, including:
[0035] The removal module is used to remove the target view if the target view corresponding to the sub-display area is not empty when a data flow event is generated by the data flow manager of the current display interface for each sub-display area.
[0036] The callback object module is used to determine the target callback object based on the loading status of the data stream manager of the sub-display area;
[0037] The state view module is used to determine the latest state view based on the current callback object and the target callback object;
[0038] The update display module is used to update the display content of the sub-display area based on the dynamic container and the latest state view.
[0039] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the multi-state interface dynamic switching method as described in the first aspect.
[0040] A fourth aspect of this application provides a computer program product, including a computer program that, when run, causes the multi-state interface dynamic switching method described in the first aspect to be executed.
[0041] The beneficial effect of the first aspect of the embodiments of this application is that, for each sub-display area of the current display interface, when a data flow event is generated by the data flow manager of the sub-display area, if the target view corresponding to the sub-display area is not empty, the target view is removed, then the target callback object is determined according to the loading state of the data flow manager of the sub-display area, then the latest state view is determined based on the current callback object and the target callback object, and finally the display content of the sub-display area is updated based on the dynamic container and the latest state view, thereby realizing independent refresh of each sub-display area in different states of the same display interface.
[0042] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description
[0043] To more clearly illustrate the technical solutions in the embodiments of this application, 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0044] Figure 1 This is a schematic diagram illustrating the implementation process of the multi-state interface dynamic switching method provided in the embodiments of this application;
[0045] Figure 2 This is a schematic diagram of a multi-state interface provided in an embodiment of this application;
[0046] Figure 3 This is a schematic diagram of the structure of the multi-state interface dynamic switching system provided in the embodiments of this application;
[0047] Figure 4 This is a schematic diagram of the computer device provided in an embodiment of this application;
[0048] Figure 5 This is a schematic diagram of a computer program product provided in an embodiment of this application. Detailed Implementation
[0049] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0050] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.
[0051] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0052] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."
[0053] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0054] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0055] This application provides a method for dynamically switching between multiple states of an interface, used to independently refresh multiple sub-display areas of the same interface in different states. The method provided in this application involves, for each sub-display area of the current display interface, when a data flow event is generated by the data flow manager of the sub-display area, if the target view corresponding to the sub-display area is not empty, removing the target view; then determining a target callback object based on the loading state of the data flow manager of the sub-display area; further, determining a latest state view based on the current callback object and the target callback object; and finally, updating the display content of the sub-display area based on the dynamic container and the latest state view, thereby achieving independent refreshing of each sub-display area in different states of the same display interface.
[0056] The multi-state interface dynamic switching method provided in this application embodiment can be applied to computer devices such as mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, and personal digital assistants (PDAs) to refresh various interfaces of these computer devices. This application embodiment does not impose any restrictions on the specific type of computer device.
[0057] like Figure 1 As shown, a first aspect of this application provides a method for dynamic switching of a multi-state interface, the method comprising:
[0058] Step S1: For each sub-display area of the current display interface, if the target view corresponding to the sub-display area is not empty when the data flow manager of the sub-display area generates a data flow event, then remove the target view.
[0059] In an application, a display interface may consist of multiple independent sub-display areas. Each sub-display area is assigned a data flow manager, allowing the display content of these areas to be controlled independently by different data flow managers. A data flow event generated by the data flow manager of a sub-display area indicates that the sub-display area is refreshing the interface.
[0060] In the application, the data flow manager is a middleware implemented using the flow component in Kotlin coroutines for processing asynchronous data streams.
[0061] Step S2: Determine the target callback object based on the loading status of the data stream manager of the sub-display area.
[0062] In the application, a flow has multiple lifecycle operators. Each lifecycle operator, such as flow(), onStart(), onEmpty(), catch(), and collect(), corresponds to a different display state, which is stored in the data template base class. The data state field DataState is updated based on the lifecycle operator to save the display state corresponding to that lifecycle operator. The loading state of the data flow manager is determined based on the read data state field DataState.
[0063] In the application, create an abstract class IStateObserver. <t>`(target:View)` inherits from `Observer`, based on the observer pattern, and is used to receive data; it can display different pages based on `DataState`. It uses the builder pattern to create a `PageLoad` class to add callback objects: `ErrorCallback()`, `EmptyCallback()`, `LoadingCallback()`, `TimeoutCallback()`, and `CustomCallback()`.
[0064] In the application, callback objects are stored in a Map collection, where the keys are of type callbacks and the values are callback objects.
[0065] Step S3: Determine the latest state view based on the current callback object and the target callback object.
[0066] In the application, the current callback object corresponds to the current state view, and the decision on whether to update the latest state view is based on the current callback object and the target callback object.
[0067] In one embodiment, step S3, determining the latest state view based on the current callback object and the target callback object, includes:
[0068] Step S31: If the target callback object is different from the current callback object, determine the target state view corresponding to the target callback object as the latest state view.
[0069] Step S32: If the target callback object is the same as the current callback object, determine the current state view corresponding to the current callback object as the latest state view.
[0070] Understandably, the same callback object corresponds to the same root view, while different callback objects correspond to different root views. If the target callback object is different from the current callback object, it means that the root view needs to be switched. Therefore, the target root view corresponding to the target callback object is set as the latest root view, and subsequent display updates are based on the latest root view. If the target callback object is the same as the current callback object, it means that the root view does not need to be switched, and the current root view is maintained, so no further refresh operation is required.
[0071] Step S4: Update the display content of the sub-display area based on the dynamic container and the latest state view.
[0072] In one embodiment, step S4, updating the display content of the sub-display area based on the dynamic container and the latest state view, includes:
[0073] Step S41: If the latest state view is the target state view, remove the current state view from the custom dynamic container.
[0074] Step S42: Load the latest state view into the dynamic container.
[0075] Step S43: Add the dynamic container to the parent container of the target view and update the display content of the child display area.
[0076] In the application, a custom dynamic container is implemented using LoadLayout View. When the latest state view is the target state view, the latest state view is added to the dynamic container, and then the dynamic container is added to the parent container of the target view, so that the child display area displays the latest state view.
[0077] In one embodiment, step S1, for each sub-display area of the current display interface, before removing the target view if the target view corresponding to the sub-display area is not empty when the data flow manager of the sub-display area generates a data flow event, further includes:
[0078] Step S11: Obtain the context of the target view.
[0079] In applications, within the Android system, Context is the core abstract class that carries application environment information. Its main functions include accessing resources (such as layouts, styles, and strings), launching components, and obtaining system services. In actual development, common Contexts include those bound to Activity, Application, Service, and View. In the multi-state interface dynamic switching method of this invention, it is necessary to obtain the context environment of the target view based on its type, and further obtain its parent container and structural information through this context to achieve accurate view replacement. Therefore: if the target view is of type Activity, the Activity instance can be directly used as the Context, and the root container FrameLayout of the target view can be obtained through its getWindow().getDecorView() or findViewById(android.R.id.content); if the target view is of type View, its context is obtained through the getContext() method; Context is a necessary parameter for subsequently constructing the LoadLayout dynamic container and loading state view layout resources, and all view replacement operations depend on the runtime environment it provides.
[0080] Step S12: Obtain the parent container of the target view and the index of the target view in the parent container based on the context.
[0081] In the application, if the target view is of type View, the parent node of the target view is obtained through targetView.parent, and a cast to ViewGroup is attempted. The position index of the target view (targetView) within the parent container is obtained through parent.indexOfChild(targetView). Since targetView.parent is of type ViewParent, it is necessary to check whether it is a ViewGroup. If the target view's current parent container is null, then the subsequent steps are executed.
[0082] In applications, if the target type is an Activity, the dynamic container (such as a LoadLayout View) is inserted at the default first position (index 0) to achieve state coverage of the entire page. Since the Activity itself does not have a position index in the parent container, the system ensures that its page structure is not destroyed through the default insertion strategy and preserves the original view for subsequent restoration and display.
[0083] Step S43, which involves adding the dynamic container to the parent container of the target view and updating the display content of the child display area, includes:
[0084] Step S431: According to the index of the target view in the parent container, add the dynamic container to the parent container of the target view, and update the display content of the sub-display area;
[0085] The removal of the target view includes:
[0086] Step S13: Remove the target view from the parent container according to the index of the target view in the parent container.
[0087] In the application, before removing the target view, the index of the target view in its parent container is obtained. This index indicates the position of the target view in its parent container. Based on this index, the target view can be removed from its parent container, and the dynamic container can be accurately added to the parent container of the target view, ensuring that the position of the dynamic container in the parent container of the target view is consistent with the position of the target view in the parent container.
[0088] In one embodiment, after updating the display content of the sub-display area based on the dynamic container and the latest state view, step S4 further includes:
[0089] Step S5: If the data stream manager of the sub-display area successfully acquires the target display data, remove the latest state view from the dynamic container.
[0090] Step S6: Re-add the target view to the parent container of the target view.
[0091] In the application, the target view is re-added to the parent container based on its index in the parent container so that the target display data can be displayed normally in the future.
[0092] Step S7: Bind the target display data to the target view and update the display content of the sub-display area.
[0093] In the application, once the data flow manager successfully obtains the target display data, the display content of the sub-display area can be switched from the latest status view to the target display data. This is achieved by first removing the latest status view from the dynamic container to clear its content, then adding the target view to its parent container, and binding the display data to the target view, thus enabling the display of the target display data in the sub-display area.
[0094] In one embodiment, before determining the latest state view based on the current callback object and the target callback object, step S3 further includes:
[0095] Step S301: Construct the corresponding state view in the callback object corresponding to each loading state of the data flow manager.
[0096] Step S302: Map each loading state of the data stream manager to its corresponding callback object and store them in a mapping table.
[0097] In one embodiment, step S2, determining the target callback object based on the loading status of the data stream manager of the sub-display area, includes:
[0098] Step S21: Search the mapping table for the corresponding target callback object based on the loading status of the data stream manager of the sub-display area.
[0099] In one embodiment, such as Figure 2 The multi-state interface 200 shown includes a first sub-display area 201, a second sub-display area 202, and a third sub-display area 203. Each sub-display area corresponds to a data stream manager, which can realize independent data stream processing and independent refresh and display of the sub-display areas. For example, the first sub-display area 201 displays product information, the second sub-display area 202 displays loading, and the third sub-display area 203 displays loading failure.
[0100] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0101] This application also provides a multi-state interface dynamic switching system for executing the steps described in the above-described multi-state interface dynamic switching method embodiments. The multi-state interface dynamic switching system can be a virtual appliance in a computer device, run by the computer device's processor, or it can be the computer device itself.
[0102] like Figure 3 As shown, the multi-state interface dynamic switching system 300 provided in this application embodiment includes:
[0103] A second aspect of this application provides a multi-state interface dynamic switching system, including:
[0104] The removal module 301 is used to remove the target view if the target view corresponding to the sub-display area is not empty when a data flow event is generated by the data flow manager of the current display interface for each sub-display area.
[0105] The callback object module 302 is used to determine the target callback object based on the loading status of the data stream manager of the sub-display area;
[0106] The state view module 303 is used to determine the latest state view based on the current callback object and the target callback object;
[0107] The update display module 304 is used to update the display content of the sub-display area based on the dynamic container and the latest state view.
[0108] In one embodiment, the state view module 303 is used for:
[0109] If the target callback object is different from the current callback object, the target state view corresponding to the target callback object is determined to be the latest state view;
[0110] If the target callback object is the same as the current callback object, the current state view corresponding to the current callback object is determined to be the latest state view.
[0111] In one embodiment, the updated display module 304 is configured to:
[0112] If the latest state view is the target state view, remove the current state view from the custom dynamic container;
[0113] Load the latest state view into the dynamic container;
[0114] Add the dynamic container to the parent container of the target view and update the display content of the child display area.
[0115] In one embodiment, the removal module 301 is configured to:
[0116] Obtain the context of the target view;
[0117] Based on the context, obtain the parent container of the target view and the index of the target view in the parent container;
[0118] The update display module 304 is used for:
[0119] Based on the index of the target view in the parent container, the dynamic container is added to the parent container of the target view, and the display content of the child display area is updated;
[0120] The removal module 301 is used to remove the target view from the parent container according to the index of the target view in the parent container.
[0121] In one embodiment, the updated display module 304 is further configured to:
[0122] If the data flow manager of the sub-display area successfully acquires the target display data, remove the latest status view from the dynamic container;
[0123] Re-add the target view to its parent container;
[0124] Bind the target display data to the target view and update the display content of the sub-display area.
[0125] In one embodiment, the multi-state interface dynamic switching system 300 further includes a mapping configuration module 305, used for:
[0126] Construct a corresponding state view in the callback object corresponding to each loading state of the data flow manager;
[0127] Each loading state of the data flow manager is mapped to its corresponding callback object and stored in a mapping table.
[0128] In one embodiment, the callback object module 302 is used for:
[0129] The corresponding target callback object is searched in the mapping table based on the loading status of the data stream manager of the sub-display area.
[0130] In applications, the modules in the multi-state interface dynamic switching system 300 can be software program modules, or they can be implemented through different logic circuits integrated in the processor, or they can be implemented through multiple distributed processors.
[0131] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 4 As shown, the computer device 4 in this embodiment includes: at least one processor 40 ( Figure 4 (Only one is shown in the diagram) a processor, a memory 41, and a computer program 42 stored in the memory 41 and executable on the at least one processor 40, wherein the processor 40 executes the computer program 42 to implement the steps in any of the above embodiments of the multi-state interface dynamic switching method.
[0132] The computer device may include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art will understand that... Figure 4 The computer device 4 is merely an example and does not constitute a limitation on the computer device 4. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.
[0133] The processor 40 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.
[0134] In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as a hard disk or memory of the computer device 4. In other embodiments, the memory 41 may be an external storage device of the computer device 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 4. Furthermore, the memory 41 may include both internal and external storage units of the computer device 4. The memory 41 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 41 can also be used to temporarily store data that has been output or will be output.
[0135] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.
[0136] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0137] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.
[0138] This application provides a computer program product 5, including a computer program 42. When the computer program 42 is run, the steps in the above-described embodiments of the multi-state interface dynamic switching method are executed.
[0139] If the integrated unit is implemented as 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, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / computer equipment, a recording medium, a computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.
[0140] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0141] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0142] In the embodiments provided in this application, it should be understood that the disclosed computer devices and methods can be implemented in other ways. For example, the computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.
[0143] The units described as separate components may or may not be physically separate. The 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0144] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.< / t>
Claims
1. A method for dynamic switching of multi-state interfaces, characterized in that, The method includes: For each sub-display area of the current display interface, if the target view corresponding to the sub-display area is not empty when the data flow manager of the sub-display area generates a data flow event, the target view is removed; each sub-display area corresponds to one data flow manager, and different sub-display areas correspond to different data flow managers. The data flow manager is a middleware for processing asynchronous data flow based on the flow component in Kotlin coroutines. The target callback object is determined based on the loading status of the data stream manager of the sub-display area; Determine the latest state view based on the current callback object and the target callback object; Determining the latest state view based on the current callback object and the target callback object includes: If the target callback object is different from the current callback object, the target state view corresponding to the target callback object is determined to be the latest state view; If the target callback object is the same as the current callback object, the current state view corresponding to the current callback object is determined to be the latest state view; The display content of the sub-display area is updated based on the dynamic container and the latest state view.
2. The multi-state interface dynamic switching method as described in claim 1, characterized in that, The step of updating the display content of the sub-display area based on the dynamic container and the latest state view includes: If the latest state view is the target state view, remove the current state view from the custom dynamic container; Load the latest state view into the dynamic container; Add the dynamic container to the parent container of the target view and update the display content of the child display area.
3. The multi-state interface dynamic switching method as described in claim 2, characterized in that, Before removing the target view, for each sub-display area of the current display interface, if the target view corresponding to the sub-display area is not empty when the data flow manager of the sub-display area generates a data flow event, the method further includes: Obtain the context of the target view; Based on the context, obtain the parent container of the target view and the index of the target view in the parent container; The step of adding the dynamic container to the parent container of the target view and updating the display content of the child display area includes: Based on the index of the target view in the parent container, the dynamic container is added to the parent container of the target view, and the display content of the child display area is updated; The removal of the target view includes: Remove the target view from the parent container based on the index of the target view within the parent container.
4. The multi-state interface dynamic switching method as described in any one of claims 1 to 3, characterized in that, After updating the display content of the sub-display area based on the dynamic container and the latest state view, the method further includes: If the data flow manager of the sub-display area successfully acquires the target display data, remove the latest status view from the dynamic container; Re-add the target view to its parent container; Bind the target display data to the target view and update the display content of the sub-display area.
5. The multi-state interface dynamic switching method as described in any one of claims 1 to 3, characterized in that, Before determining the latest state view based on the current callback object and the target callback object, the process also includes: Construct a corresponding state view in the callback object corresponding to each loading state of the data flow manager; Each loading state of the data flow manager is mapped to its corresponding callback object and stored in a mapping table.
6. The multi-state interface dynamic switching method as described in claim 5, characterized in that, Determining the target callback object based on the loading status of the data stream manager of the sub-display area includes: The corresponding target callback object is searched in the mapping table based on the loading status of the data stream manager of the sub-display area.
7. A multi-state interface dynamic switching system, characterized in that, include: The removal module is used to remove the target view if the target view corresponding to the sub-display area is not empty when the data flow manager of the sub-display area generates a data flow event for each sub-display area of the current display interface. Each sub-display area corresponds to a data flow manager, and different sub-display areas correspond to different data flow managers. The data flow manager is a middleware for handling asynchronous data flow implemented based on the flow component in Kotlin coroutines. The callback object module is used to determine the target callback object based on the loading status of the data stream manager of the sub-display area; The state view module is used to determine the latest state view based on the current callback object and the target callback object. Wherein, if the target callback object is different from the current callback object, the target state view corresponding to the target callback object is determined to be the latest state view. If the target callback object is the same as the current callback object, the current state view corresponding to the current callback object is determined to be the latest state view. The update display module is used to update the display content of the sub-display area based on the dynamic container and the latest state view.
8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the multi-state interface dynamic switching method as described in any one of claims 1 to 6.
9. A computer program product, characterized in that, Includes a computer program, which, when run, causes the multi-state interface dynamic switching method as described in any one of claims 1 to 6 to be executed.
Citation Information
Patent Citations
Display method and device for page state switching
CN107704241A
Display method and device of multi-state view, computer equipment and medium
CN118484606A