Gawan application continuing control method and system, computer equipment and storage medium

Abstract

The invention relates to the field of application control, and discloses a method and a system for continuous control of a swan gap application, computer equipment and a storage medium, the method comprises the following steps: monitoring a current display page through source end equipment, and when the current display page is identified as a function page, recording a unique identifier which takes routing information as a core and is associated with corresponding page function data and real-time state data; when a connection request is received, the source end device sends the unique identifier and the associated data thereof to the opposite end device; the opposite terminal device analyzes the route based on the received information, executes progressive application recovery according to the route, and sequentially completes recovery of corresponding pages, functions and states; according to the method and the device, the problems of inaccurate connection control, improper page recovery opportunity and incomplete function state information in the prior art are solved, and cross-device seamless application connection experience is realized.

Description

HarmonyOS application connection control methods, systems, computer equipment and storage media Technical Field

[0001] This invention relates to the field of application control, specifically to a HarmonyOS application continuity control method, system, computer equipment, and storage medium. Background Technology

[0002] In the HarmonyOS distributed system, the application continuity function allows users to migrate application tasks running on one device to another for continued execution. However, existing continuity implementations have the following limitations: First, the opening and closing of application continuity largely depends on the creation and destruction of functional pages. This approach is difficult to handle dynamic scenarios involving complex jumps between multiple functional pages, and can easily lead to mismanagement of continuity capabilities during page transitions. Second, the target device lacks an intelligent mechanism for determining when to restore page status, making it difficult to bypass splash screens, advertising pages, and other interfaces, thus failing to provide a fast and direct page restoration experience. Furthermore, the information transmitted during continuity is incomplete, typically only including page routes, lacking synchronization support for the dynamic functional states within the page, resulting in the loss of functional states after continuity.

[0003] Therefore, there is an urgent need for a cross-device handover solution that can achieve precise control of handover capabilities and can gradually restore the system from basic navigation to the complete state based on effective information. Summary of the Invention

[0004] In view of this, the present invention provides a HarmonyOS application connection control method, system, computer device and storage medium to solve the problems of inaccurate connection capability activation and deactivation and incomplete cross-device application recovery in the prior art.

[0005] In a first aspect, the present invention provides a HarmonyOS application continuity control method, comprising: when the source device starts the application, it initializes and disables the application continuity capability, thereby establishing a definite initial state for the subsequent implementation of a precise control strategy that enables the application only on the functional page, thus preventing accidental triggering of continuity on non-functional pages from the source.

[0006] Functional pages refer to specific interactive pages in an application that need to support cross-device continuity. These pages deploy a visible area change listener method (onVisibleAreaChange() method) to dynamically manage the start and stop of the application's continuity capabilities.

[0007] When the function page of the source device is displayed, the unique identifier of the function page is obtained through the global state management module, and the application continuity capability is enabled. If a previously recorded unique identifier already exists in the system, the current unique identifier is used to overwrite it. When the function page of the source device is hidden, it is determined whether the unique identifier of the currently hidden page is consistent with the unique identifier currently recorded in the system. If they are consistent, the application continuity capability is disabled. If they are inconsistent, the application continuity capability is kept enabled.

[0008] The global state management module is implemented by a global singleton class named AppContinueManager.

[0009] The unique identifier contains the routing information for the function page and associates the extended data and function status data required by the function page during the connection process.

[0010] To achieve the above control, the functional pages use the `onVisibleAreaChange()` method provided by the HarmonyOS system to monitor their display and hiding states. This method accurately captures the page's state changes in the page stack through callback parameters `isVisible` (visibility) and `currentRatio` (visibility ratio), and is triggered multiple times during page navigation. When the page is displayed (`isVisible=true`), the application continuity capability is enabled and the unique identifier of the current page is recorded; when the page is hidden (`isVisible=false`), the system compares the unique identifier of the current page with the recorded unique identifier, and only disables the application continuity capability if the two match. This mechanism effectively avoids the problem of accidentally disabling the continuity capability when navigating to other functional pages or non-functional pages due to the original page being hidden, ensuring that the continuity capability is only disabled when there are no active functional pages.

[0011] The source device responds to the application continuation request from the peer device via the onContinue() method. Upon response, it first checks for a valid unique identifier. If one exists, it uses the unique identifier as the basic continuation parameter and queries the page function data and real-time status data corresponding to the unique identifier. The unique identifier, page function data, and real-time status data are then sent to the peer device as continuation parameters, reducing redundancy in cross-device data transmission.

[0012] The peer device receives continuation events and parameters through its Ability's onCreate() and onNewWant() lifecycle callback methods. onCreate() is triggered when the application first starts, responsible for initializing and parsing continuation parameters; onNewWant() is triggered when the application is running in the background, and in addition to parsing parameters, it sends an application continuation event notification via the event bus or a custom event mechanism to trigger the subsequent recovery process. The peer device completes navigation and creation of the target page based on a unique identifier, and sequentially performs page-level content restoration, function-level business activation, and state-level parameter restoration based on page function data and real-time status data. This layered recovery strategy aims to achieve complete application state continuation, overcoming the deficiency in existing technologies where only page navigation occurs but functional state is lost.

[0013] The onCreate() lifecycle callback methods include: Initial state control: When the method is executed, setMissionContinueActive(false) is called through the global singleton AppContinueManager to disable the application's default connection capability, establishing a definite initial state for subsequent "connection enabled only on functional pages", thus preventing non-functional pages from accidentally triggering connection from the source; Connection event reception: When the peer device initiates a connection request, causing a cold start of the application, the method identifies the event type through launchParam.launchReason (AbilityConstant.LaunchReason.CONTINUATION is a connection event), parses the route identifier, functional data, and status data in the want parameter, and provides basic parameters for subsequent page recovery.

[0014] The `onNewWant` lifecycle callback methods include: Continuity event identification: When the application is running in the background, a connection request initiated by the peer device will trigger this method. After determining it as a connection event via `launchParam.launchReason`, the connection data (routes, function data, and status data) in the `want` parameter is parsed and stored in `AppContinueManager`. Custom event notification: To bypass the limitation of scenarios where the application's main framework page has already been created, this method sends a custom connection event notification (such as `WTR.emit(WTRKey.entryAbilityEvent)`) through a third-party library, triggering the connection processing logic in the main framework page and avoiding delays in page recovery due to the main framework already being loaded.

[0015] Page-level content restoration: Restores the basic data model and visual framework of the target page, ensuring that users first see a complete and non-blank target page; the system directly fills in the core content area of ​​the page based on the page function data in the continuation parameters, without waiting for a complete network request response.

[0016] Function-level business activation: Based on the restoration of page content, the system detects and automatically activates specific business function modules that need to be continued on the page; the system checks whether there are function tags or specific data types in the continuation parameters, and automatically starts the corresponding business logic accordingly.

[0017] Status-level parameter restoration: The enabled business functions are restored to their specific running parameters at the time of interruption, so as to achieve accurate operation continuation; the system injects the real-time status data in the continuation parameters into the corresponding functional modules.

[0018] Page restoration uses the aboutToAppear() method, which is triggered when a page component is about to be displayed (before rendering is complete). It is used to execute page-level continuation restoration logic and is a key method to solve the problem of poor page restoration timing.

[0019] Bypassing Splash Page Interference: When an application starts, it typically displays a welcome page or an advertisement page first. The aboutToAppear() method of the main frame page is triggered after the splash page disappears. At this time, calling the page restoration method (such as tryHandleAppContinue()) can bypass the splash page and directly jump to the target function page, while also ensuring automatic restoration of the page stack for navigation routes; Event Listener Binding: Add custom continuation event listeners (such as WTR.on(WTRKey.entryAbilityEvent,()=>tryHandleAppContinue())) to receive hot start continuation notifications sent by onNewWant, ensuring that page restoration can be triggered quickly in hot start scenarios; Page Jump Execution: The method calls tryHandleAppContinue() to parse the route identifier stored in AppContinueManager, and completes the target page jump through the routing utility class (such as SkipToNewsDetailUtils), laying the foundation for subsequent function restoration and state recovery.

[0020] Secondly, the present invention provides a HarmonyOS application connection control system, comprising: a capability switch module for enabling or disabling application connection capabilities; a data recording module for recording a unique identifier and associating it with extended data and functional status data related to connection; a request processing module for responding to connection requests from peer devices; and a connection recovery module for receiving data and performing progressive function recovery.

[0021] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the application continuity control method described in the first aspect or any corresponding embodiment thereof.

[0022] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the application continuity control method described in the first aspect or any corresponding embodiment thereof.

[0023] Fifthly, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute the application continuity control method described in the first aspect or any corresponding embodiment thereof.

[0024] This method dynamically manages the on / off state of connection capabilities by monitoring the display and hiding of function pages and associating them with unique identifiers. This enables precise dynamic management of connection capabilities, effectively preventing accidental triggering and abnormal shutdown. It ensures the integrity and structure of the connection context: the defined unique identifier integrates routing information, extended data, and function status data, providing a complete and structured context carrier for connection and solving the problems of state loss and rigid transmission mechanisms. Furthermore, it provides an intelligent and flexible progressive recovery mechanism, allowing the peer device to intelligently resolve the complete identifier and trigger recovery at the appropriate time, improving adaptability to different scenarios and the success rate of recovery. Attached Figure Description

[0025] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0026] Figure 1 is a flowchart illustrating the HarmonyOS application continuity control method according to an embodiment of the present invention; Figure 2 is a flowchart illustrating the source device control application continuity capability according to an embodiment of the present invention; Figure 3 is an architecture diagram of the HarmonyOS application continuity control system according to an embodiment of the present invention; Figure 4 is a hardware structure diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] With the widespread adoption of HarmonyOS's distributed technology, cross-device application continuity has become a core feature for enhancing user experience. Users can seamlessly switch running application tasks between multiple devices such as mobile phones, tablets, and computers to continue operating within the same application on another device. For example, while editing a memo, browsing the web, or playing a video on a mobile phone, users can switch to a tablet to continue the task without having to search for the target content or restore the operation state, greatly improving the convenience of multi-device collaboration. The core of this feature relies on the cross-device application interface, page stack, and business data saving and restoring mechanism provided by the distributed framework. The source device saves business data through a specific interface, while the peer device receives the data and restores the application state through the corresponding interface.

[0029] However, existing application continuity technologies in HarmonyOS still have many shortcomings that urgently need to be addressed, resulting in insufficient accuracy, efficiency, and completeness in the continuity experience, making it difficult to meet user needs in complex scenarios. Firstly, the start and stop control of application continuity capabilities lacks flexibility and precision, making it difficult to adapt to dynamic scenarios involving multi-functional page transitions. Most existing technologies control the start and stop of continuity capabilities through the creation and destruction of functional pages; that is, the continuity function is started when the page is created and stopped when the page is destroyed. However, in practical applications, users often face complex scenarios involving multiple page interactions. This method of binding continuity start and stop to the page lifecycle cannot dynamically identify the currently active core task page, easily leading to problems such as accidentally stopping continuity capabilities when navigating to non-functional pages, and confusion in continuity control when switching between multiple functional pages. This results in users finding the function disabled when they need to continue, or the target page not matching their actual needs.

[0030] Secondly, the target device lacks an intelligent mechanism for determining when to resume page contention, resulting in redundant waiting during the connection process. In existing technologies, after receiving a connection request, the peer device typically follows a complete application startup process, sequentially navigating through non-core interfaces such as the splash screen, ad screen, and application homepage before finally navigating to the target function page. During this process, users need to wait for multiple irrelevant pages to load, which not only prolongs the connection time but also requires manually skipping ads or switching pages. Furthermore, in some scenarios, the peer device may experience delays or failures in navigation to the target page due to startup process interference, further reducing the reliability of the connection.

[0031] Furthermore, the information transmitted during the connection process is often limited in scope and completeness, leading to the loss of functional states and preventing true "seamless connection." Existing connection data transmission technologies typically only include routing information for the target page, fulfilling only the basic requirement of redirecting to that page. They lack synchronous support for the dynamic functional states within the page. For example, video applications can only redirect to the video list page but cannot restore the specific video playback or progress; document editing applications can only open the document's homepage but cannot restore key states such as editing position, font format, and entered content; web browsers can only redirect to webpage links but cannot restore interactive data such as scroll position and form fill content. This deficiency forces users to relocate content and restore operational states after the connection is established, significantly reducing the practical value of cross-device connection.

[0032] Finally, existing technologies lack an effective data consistency verification mechanism, leading to redundancy or mismatch risks in cross-device data transmission. The lack of correlation verification between transmitted data and the target page can result in issues such as mismatches between transmitted data and currently active pages, or expired and unupdated data. This can cause content errors and functional malfunctions when the peer device restores the page. Furthermore, some solutions transmit large amounts of irrelevant data, increasing bandwidth consumption and latency in cross-device communication, further impacting connection efficiency.

[0033] Therefore, there is an urgent need for a cross-device connection solution that can achieve precise connection control, intelligent recovery timing judgment, full functional status synchronization, and data consistency verification, in order to overcome the many shortcomings of existing technologies and improve the accuracy, efficiency, and completeness of cross-device application connection.

[0034] According to an embodiment of the present invention, an embodiment of the HarmonyOS application continuity control method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] The embodiments of the present invention are described below with reference to Figures 1 to 4, and can be used in the aforementioned mobile terminals, such as mobile phones and tablet computers. Embodiments

[0036] In step S101, when the source device initializes, connection capability is activated, and structured data is recorded during application startup, the system interface is actively called in the onCreate lifecycle callback of its main Ability to set the connection capability, which is enabled by default, to a disabled state. This operation establishes a precise control principle of "disabled by default, enabled on demand," eliminating the possibility of accidentally triggering cross-device connection on non-functional pages such as the startup page, advertising page, or application homepage.

[0037] When a user navigates to the video list page (defined as a page supporting follow-up functionality), the system executes the following initialization and monitoring process: Generating and obtaining a unique page identifier: Based on the page path and context parameters, the system dynamically generates a route string to uniquely identify the current page instance, for example: "APP: / home / video_list?channelId=456". This unique identifier is the key index for all subsequent follow-up operations.

[0038] Register a page show / hide listener: Register the onVisibleAreaChange() listener method in the page component and set a reasonable visibility threshold to accurately capture the page's "show" and "hide" events.

[0039] Triggering the display event and activating capabilities: When the system detects a page being displayed (isVisible becomes true), it performs two core operations: recording the unique identifier of the current page in the global management module; and calling the interface to enable the application's connection capability. At this point, the device is ready to be discovered and connected to by other devices.

[0040] During user interaction with the video list page, the system needs to dynamically maintain and update the structured data required for continuity: Data association during list scrolling: When the user scrolls the list, the system listens for changes in the video item currently in the center or first position on the screen. Once a change occurs, it immediately retrieves the video's data model (including core fields such as videoId, title, playUrl, coverUrl, etc.) and updates the currently effective unique identifier accordingly, for example, expanding it to "APP: / home / video_list?channelId=456&focusedVideoId=789", thereby refining the continuity context from "page level" to "specific content item level within the page".

[0041] Playback status tracking: When a user starts playing a video, the system listens for and records the playback progress in real time via player callbacks. This progress value is not stored independently, but is strongly bound to the unique identifier of the currently focused video, ensuring that the status data strictly corresponds to the specific page content item.

[0042] Step S102: Source device intelligently responds to connection request and encapsulates parameters. When another HarmonyOS device sees the "connection icon" on the application icon in the system desktop or task manager and clicks it, the source device will receive the application connection request sent by the system.

[0043] The source device handles this request in the onContinue() system callback, performing a layered validation and data encapsulation process: Validity validation: First, it checks if a valid, unique identifier exists in the global management module. If it does not exist (for example, the application is currently on a settings page that does not support continuing), it directly returns REJECT, rejecting the connection.

[0044] Consistency check: If a unique identifier exists, further verification is performed to confirm whether the current video data model associated with that identifier is still valid and consistent with the parameters (such as videoId) in the identifier. This step prevents the "page and data disconnect" problem caused by data expiration or rapid state changes.

[0045] Structured parameter encapsulation: After all verifications pass, the system begins to organize the connection parameter packet to be transmitted. This parameter packet is transmitted via wantParam and contains at least three levels of information: Unique identifier: serving as the core instruction for recovering the target address.

[0046] Page functionality data: This includes data necessary for quickly restoring page content, such as channel information for the video list and a complete data model of the currently focused video. This data allows the receiving device to immediately render the core page content without relying on network requests.

[0047] Real-time status data: The data necessary to restore business functions to the state before the interruption, which in this scenario is the precise playback progress of the video.

[0048] Agree and send: Finally, the source device returns AGREE, and the HarmonyOS system automatically transmits the encapsulated connection parameter package to the peer device.

[0049] Step S103: The peer device resolves parameters and gradually restores its state. The application on the peer device side is either woken up (cold start) or activated from the background (warm start). The system passes successor events through Ability lifecycle callbacks: Cold start: In the onCreate method, launchParam.launchReason is used to determine if it is a CONTINUATION event.

[0050] Warm start: Receive and parse the continuation parameters in the onNewWant method.

[0051] Regardless of the startup method, the system immediately parses the received connection parameter packet and stores the parsed unique identifier, page function data, and real-time status data in a globally accessible context management object (such as AppContinueManager) for use in subsequent recovery processes.

[0052] Subsequently, the peer device performs a three-layer progressive recovery to achieve a seamless user experience: Page-level content recovery; Route redirection: During the application's main frame page's aboutToAppear() lifecycle, it checks if a unique identifier to be recovered exists in the global management object. If it exists, a routing method (such as router.pushUrl) is immediately invoked to navigate to the target page (video list page) specified by the identifier.

[0053] Data Population: During the initialization phase of the target page (such as aboutToAppear or the first build), the page function data (video data model) temporarily stored in the global management object is checked and used first to directly render the page. This avoids the time spent waiting for network interface responses, achieving instant content presentation, and the user first sees a non-blank, complete page.

[0054] Functional business activation: After restoring the page content, the page logic checks whether the context contains specific types of business data. In this embodiment, if a video data model is detected, it is determined that the video playback function needs to be restored.

[0055] The system automatically initializes the video player component and loads the playUrl from the data model. No user intervention is required; the player enters a ready state immediately.

[0056] State-level parameter restoration: After the player renders the first frame or receives the onPrepared callback, it checks whether there is real-time state data (playback progress) that matches the current video in the global management object.

[0057] If it exists, the player's seekTo method is immediately called to precisely position the playback progress to the recorded number of seconds (e.g., 205 seconds). Once the position is set, playback will start automatically.

[0058] Recovery Completed and Cleanup: After successful recovery, the system immediately clears the temporary connection-related data stored in the global management object to prevent interference with subsequent normal application operations.

[0059] This embodiment achieves complete restoration of the video state, avoiding repetitive operations. By transmitting "page function data + real-time status data" and employing a layered strategy of page-level content restoration, function-level service activation, and status-level parameter restoration, it can not only accurately jump to the target video but also completely restore key states such as video playback progress and video data model. Users do not need to manually search for videos or adjust progress, achieving a seamless "instant continuation and playback" experience. Through mechanisms such as consistency verification between routing identifiers and video data models, and dynamic updates of real-time status data, it ensures the authenticity and validity of continuation parameters transmitted across devices, avoiding continuation anomalies caused by data expiration or data-page mismatch, thus improving the success rate and stability of cross-device continuation. Example

[0060] This example illustrates the method for controlling the continuity of applications on the source device, as shown in Figure 2, through navigation between pages A, B, and C. The page listens for changes in its visible area using the `onVisibleAreaChange()` method (a component visibility change event), thus sensing the page's display and hiding states. This method is called multiple times during page navigation.

[0061] Scenario 1: Only page B is a functional page. In this scenario, the lifecycle of the application's continuity capability is strictly bound to the visibility of page B.

[0062] Redirecting from page A to page B: Event: Listen for the display of page B.

[0063] Action: The system records the unique identifier of the current function page as B and enables the application continuity capability.

[0064] Navigate from page B to page C: Event: Listen for page B being obscured (hidden).

[0065] Action: Because the unique identifier of page B is the same as the unique identifier (B) of the current system record, the application connection capability is disabled.

[0066] Returning from page C to page B: Event: Listen for the display of page B.

[0067] Action: The system records the unique identifier of the current function page as B and enables the application continuity capability.

[0068] Returning from page B to page A: Event: Listening for page B being hidden.

[0069] Action: Because the unique identifier of page B is the same as the unique identifier (B) of the current system record, the application connection capability is disabled.

[0070] Scenario 2: Both pages B and C are functional pages. In this scenario, the control of the application's continuity capability is transferred between B and C, thereby ensuring that the continuity capability remains uninterrupted during the functional page transition.

[0071] Redirecting from page A to page B: Event: Listen for the display of page B.

[0072] Action: The system records the unique identifier of the current function page as B and enables the application continuity capability.

[0073] Navigating from page B to page C: Event sequence and actions: First, the system detects that page B is hidden. Because the unique identifier (B) currently recorded by the system is the same as the unique identifier of page B, the application connection capability is disabled.

[0074] Subsequently, the system detected the display of page C. The system recorded the unique identifier of the current function page as C and enabled the application continuity capability.

[0075] Control handover: After this, even if page B triggers the hidden listener again due to the event sequence, it cannot perform the shutdown operation because its unique identifier is different from the unique identifier (C) currently recorded by the system. At this point, application continuity capability is completely controlled by page C.

[0076] Returning from page C to page B: Event sequence and actions: First, the system detects that page C is hidden. Because the unique identifier (C) currently recorded by the system is the same as the unique identifier of page C, the application continuity capability is disabled.

[0077] Subsequently, the system detected the display of page B. The system recorded the unique identifier of the current function page as B and enabled the application continuity capability.

[0078] Control handover: After this, even if page C triggers the hidden listener again due to the event sequence, it cannot perform the shutdown operation because its unique identifier differs from the unique identifier (B) currently recorded by the system. At this point, application continuity capability has been returned to page B.

[0079] Returning from page B to page A: Event: Listening for page B being hidden.

[0080] Action: Because the unique identifier of page B is the same as the unique identifier (B) of the current system record, the application connection capability is disabled.

[0081] This embodiment clearly demonstrates, through a "unique identifier overlay and display / concealment comparison" mechanism, how to achieve precise control over connection capabilities in complex scenarios involving single-function and multi-function page transitions. This mechanism ensures that connection capabilities are only disabled when the currently active function page is hidden and no other function page takes over, effectively avoiding accidental shutdowns caused by switching between non-function pages or function pages, and achieving reliable handover and continuous maintenance of control between different function pages within the device.

[0082] This embodiment also provides a HarmonyOS application continuity control system, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the systems described in the following embodiments are preferably implemented in software, hardware implementations, or a combination of software and hardware, are also possible and contemplated.

[0083] This embodiment provides a HarmonyOS application connection control system, including: a capability switch module for enabling or disabling application connection capabilities; a data recording module for recording a unique identifier and associating it with extended data and functional status data related to connection; a request processing module for responding to connection requests from peer devices; and a connection recovery module for receiving data and performing progressive function recovery.

[0084] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0085] In this embodiment, the HarmonyOS application continuity control system is presented in the form of functional units. Here, a unit refers to an ASIC (Application Specific Integrated Circuit), a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0086] This invention also provides a computer device having the application connection control device shown in FIG3 above.

[0087] Please refer to Figure 4, which is a schematic diagram of a computer device according to an optional embodiment of the present invention. As shown in Figure 4, the computer device includes one or more processors 10, a memory 20, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components communicate with each other using different buses and can be installed on a common motherboard or otherwise as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 4 uses one processor 10 as an example.

[0088] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0089] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0090] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0091] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0092] The computer device also includes a communication interface 50 for communicating with other devices or communication networks.

[0093] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0094] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0095] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A HarmonyOS application connection control method, applied to source-end devices, characterized in that: include: Monitor the currently displayed page and identify whether the currently displayed page is a functional page; Based on the fact that the currently displayed page is a functional page, the unique identifier of the functional page is recorded through the global state management module, and the unique identifier is updated when the page state changes; In response to switching from the current functional page to another functional page, when the current functional page is hidden, the application connection capability is disabled based on the consistency between the unique identifier of the current functional page and the unique identifier of the current record; when the other functional page is displayed, the application connection capability is enabled, and the unique identifier of the record is updated to the unique identifier of the other functional page; wherein, the functional page is a page that has deployed a visible area change monitoring method; in response to an application connection request, the unique identifier is sent to the peer device.

2. The method according to claim 1, characterized in that, The unique identifier contains the routing information of the function page and is associated with the page function data and real-time status data required by the function page during the connection process.

3. The method according to claim 1, characterized in that, In response to the detection of a function page being displayed, the unique identifier of the function page is recorded as a currently valid identifier, and the application continuity capability is enabled; when the function page is hidden, the application continuity capability is disabled based on the unique identifier being consistent with the currently recorded identifier.

4. The method according to claim 1, characterized in that, The application continuity capability is initialized to a disabled state when the application starts.

5. A HarmonyOS application connection control method, applied to the peer device, characterized in that: include: In response to the unique identifier, the routing information is parsed based on the unique identifier, and application recovery is performed according to the routing information.

6. The method according to claim 5, characterized in that, Executing application recovery based on the routing information includes: opening the corresponding application page based on the page information obtained from the routing information; opening the corresponding application page and function based on the page information and function information obtained from the routing information; and opening the corresponding application page, function, and status based on the page information, function information, and status information obtained from the routing information.

7. The HarmonyOS application continuity control system, characterized in that, The system includes: a capability switch module for enabling or disabling the application connection capability; a data recording module for recording a unique identifier and associating it with extended data and functional status data related to connection; a request processing module for responding to connection requests from the peer device; and a connection recovery module for receiving data and performing progressive function recovery.

8. A computer device, characterized in that, include: A memory and a processor are interconnected, the memory stores computer instructions, and the processor executes the HarmonyOS application connection control method according to any one of claims 1 to 6 by executing the computer instructions.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the HarmonyOS application connection control method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions for causing a computer to execute the HarmonyOS application connection control method as described in any one of claims 1 to 6.

Images