Page refreshing method, device and equipment

Abstract

According to the technical scheme, the page refreshing method is provided and comprises the steps that when it is monitored that a first page jumps to a second page, a channel identifier shared between the first page and the second page is generated, and the second page and the first page are homologous pages; based on the channel identifier, establishing a broadcast channel based on an application program interface (API) between the first page and the second page; when it is monitored that a predetermined event occurs on the second page, a first message of the second page is sent to the first page through the broadcast channel, and the first message is used for triggering refreshing of the first page. The problem of state asynchronization between different pages is solved, and the method has the advantages of being high in response speed, high in reliability and low in resource consumption.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer communication, in particular to a page refreshing method, device and equipment. BACKGROUND

[0002] In the operation scenario of multiple pages of a browser, the state asynchrony between different pages is often encountered, which directly affects the user experience. For example, when a user clicks a data list page (hereinafter referred to as a first page) to perform a data editing operation, the browser will open a new browser tab (hereinafter referred to as a second page) of a data detail page. After the user edits and saves the data on the second page, the second page is closed, and when switching back to the first page, it is found that the data on the first page is still the old data before modification. SUMMARY

[0003] The present application provides a page refreshing method, device and equipment, which can improve the efficiency of browser cross-page refreshing and simplify user operation.

[0004] In a first aspect, a page refreshing method is provided, which includes: when it is monitored that a first page jumps to a second page, generating a channel identifier shared between the first page and the second page, the second page and the first page being same-origin pages; based on the channel identifier, establishing an API-based broadcast channel between the first page and the second page; when it is monitored that a predetermined event occurs on the second page, sending a first message of the second page to the first page through the broadcast channel, the first message being used to trigger refreshing of the first page.

[0005] In some implementations, the channel identifier is generated by the first page and transmitted to the second page through a URL parameter.

[0006] In some implementations, the channel identifier is a UUID.

[0007] In some implementations, the channel identifier is generated based on a hash algorithm.

[0008] In some implementations, the predetermined event includes: an event of leaving the second page; and / or, an event of a change in content within the second page.

[0009] In some implementations, the leaving the second page includes: closing the second page; and / or, navigating from the second page to other pages; and / or, refreshing the second page.

[0010] In some implementations, the method further includes: sending, by the broadcast channel, a second message of the second page to the first page, the second message being used to indicate that the predetermined event occurs on the second page; and sending, by the broadcast channel, a response message of the first page to the second page in response to the second message; wherein the first message is generated after the second page receives the response message.

[0011] In some implementations, the listening to the message between the first page and the second page is implemented by a bidirectional subscription message event.

[0012] In some implementations, the method further includes: refreshing the first page based on the first message.

[0013] In some implementations, the refreshing the first page includes: refreshing the first page based on a field that is changed in the second page.

[0014] In some implementations, the method further includes: closing the broadcast channel.

[0015] In a second aspect, a page refreshing apparatus is provided, including: a channel establishing module, configured to generate a channel identifier shared between a first page and a second page when it is monitored that the first page jumps to the second page, the second page and the first page being homologous pages; the channel establishing module is further configured to establish an API-based broadcast channel between the first page and the second page based on the channel identifier; and a message processing module, configured to send a first message of the second page to the first page through the broadcast channel when it is monitored that a predetermined event occurs on the second page, the first message being used to trigger refreshing of the first page.

[0016] In a third aspect, a page refreshing device is provided, including a memory and a processor, the memory being used to store program codes, and the processor being used to invoke the program codes in the memory to enable the vehicle controller to perform the method in any one of the first aspect.

[0017] In the technical solution provided in the present application, when it is monitored that the first page jumps to the second page, a shared channel identifier generated between the first page and the second page is used to establish an API-based broadcast channel between the first page and the second page, and then when it is monitored that a predetermined event occurs on the second page, a first message of the second page is sent to the first page through the broadcast channel to trigger refreshing of the first page, thereby solving the problem of state asynchrony between different pages, and having the advantages of fast response speed, high reliability and low resource consumption. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 is a schematic diagram of a first page and a second page of a browser.

[0019] Figure 2 is a flowchart of a page refreshing method provided by an embodiment of the present application.

[0020] Figure 3 is an interaction diagram between a first page, a second page and a broadcast channel in the page refreshing method of an embodiment of the present application.

[0021] Figure 4 is a schematic diagram of a possible way to refresh the first page.

[0022] Figure 5 is a schematic diagram of a possible implementation of the page refreshing method shown in Figure 1

[0023] Figure 6 is a schematic diagram of a page refreshing apparatus provided by an embodiment of the present application.

[0024] Figure 7 is a schematic diagram of a page refreshing apparatus provided by an embodiment of the present application. DETAILED DESCRIPTION

[0025] The terms used in the embodiments of the present application are merely used for the purpose of describing particular embodiments, and are not intended to limit the present application. The singular forms "a," "an," and "the" used in the embodiments of the present application and the appended claims are intended to include plural forms as well, unless the context clearly indicates otherwise.

[0026] It should be understood that the term "and / or" used herein merely describes an association relationship of associated objects, and means that there can be three relationships, for example, A and / or B, which means that there are three cases of A alone, A and B together, and B alone. In addition, the character " / " herein generally represents an "or" relationship between the front and rear associated objects.

[0027] When a page is operated using a browser, especially when editing a data list page (hereinafter referred to as a first page), the user clicks an "edit" button of a certain data item on the first page, and the browser opens a new browser tab (hereinafter referred to as a second page) to display detailed information of the data, and the user can edit the data on the second page. As shown in Figure 1 Figure 1 ​​For the schematic diagram of the first page and the second page of the browser, the first page 110 is a background management system of a certain brand of automobile, and the vehicle information therein is editable. When the user clicks one of them, for example, clicks the edit button of the vehicle model, the browser will open a second page 120, and the user can input the vehicle model on the second page 120, thereby realizing the information editing and management operation of the product. However, the refreshing of the page often needs to be manually triggered by the user, and therefore, with reference to the first page 110 Figure 1 , when the user modifies and saves the data of the second page 120 and switches back to the first page 110 after closing the second page 120, it is found that the first page 110 still displays the old data before the modification.

[0028] The user can choose to manually refresh the first page. When returning to the first page, the user manually clicks the refresh button, but this refreshing operation is easy to be forgotten by the user. In addition, when multiple users modify the data of the first page at the same time, the data modified by multiple people cannot be displayed on the first page in time, and there is a risk of data asynchronization. In some scenarios, the background management personnel needs to repeat the process of “closing the page-returning to refresh” multiple times, which affects the work efficiency.

[0029] In order to solve the problem of low efficiency caused by manually refreshing the browser page, the user can also set a function of timed refreshing in the browser page. The user edits the data of the second page, saves and closes the second page, and the first page can be automatically refreshed at a set time. For example, the timing setting of automatic refreshing can be 5 minutes, that is, the first page is automatically refreshed every 5 minutes to realize the updating of the content. However, when the page is refreshed in a timed manner, the page will flicker frequently. For example, when processing some data list pages of long lists, the user needs to monitor the page for a long time due to the large amount of content, and the screen flicker caused by the timed refreshing of the page will affect the operation of the user. In addition, when the browser performs timed refreshing, all data needs to be reloaded every time the page is refreshed, which wastes network traffic.

[0030] In the related art, a mode based on a pop-up reminder is considered to prompt the user to perform the refreshing operation, such as that the second page can pop up a prompt box “please return to the original interface to refresh the data” when the user saves and closes the second page, but actual tests show that 82% of the users will directly close the prompt box without performing the operation. In addition, since most browsers have a local cache (localstorage) mechanism, that is, the system will cache the data of the first page by default to speed up the loading, it is possible that even if the data has been modified, the outdated information can still be displayed when loading, which affects the user experience.

[0031] In view of this, this application proposes a page refresh method. When a jump from the first page to the second page is detected, a broadcast channel based on the application programming interface (API) is established between the first page and the second page through a shared channel identifier generated between the two pages. Then, when a predetermined event is detected on the second page, the first message of the second page is sent to the first page through the broadcast channel to trigger a refresh of the first page. This solves the problem of asynchronous state between different pages and has the advantages of fast response speed, high reliability, and low resource consumption.

[0032] The following, combined with Figures 2 to 5 The technical solutions of the embodiments of this application will be described in detail. Figure 2 This is a flowchart illustrating the page refresh method provided in the embodiments of this application. Figure 2 The method shown can, for example, be executed by a browser. Figure 2 As shown, Figure 2 The method 200 shown may include some or all of the following steps.

[0033] In step S210, upon detecting a jump from the first page to the second page, a shared channel identifier (ID) is generated between the first and second pages. The second page and the first page are from the same origin. Same-origin pages, for example, refer to pages with the same protocol, hostname, and port number. In this embodiment, the first page and the second page are a parent and child page from the same origin. The first page can be the parent page, and the second page can be a child page generated based on the first page. In this case, the first page can be called the parent page of the second page, and the second page can be called the child page of the first page. For example, in a browser usage scenario, a user needs to edit a page containing a data list (the parent page). When the user clicks on the corresponding data to be edited, the browser generates a new page for the user to perform more detailed content editing operations (the child page). When the user clicks the data editing button on the parent page, they can jump to the child page to perform editing operations.

[0034] There are several scenarios where a user navigates from the first page to the second page. In some embodiments, navigation to the second page can be achieved by clicking on data that needs editing on the first page, or by clicking a navigation button on the first page. For example, refer to... Figure 1This could be a product's backend information management system; for example, in an e-commerce order management system, customer service representatives need to edit order information, and clicking on the order details page will redirect them to a second page for data editing; or, in a vehicle R&D or production management system, engineers need to edit vehicle factory information and vehicle parameters, which would involve redirecting from the first page to the second page.

[0035] Specifically, a channel identifier is a type of identification information. For example, it can be any type of string, such as #1, or a hexadecimal identifier. In some embodiments, different pages carry different channel identifiers. These channel identifiers can be used to distinguish the identities of different pages or to bind the same page information. For example, the first page and the second page can be bound to the identity of a page from the same origin through the same channel identifier.

[0036] When editing the first page, it may be necessary to edit multiple data items simultaneously, which may result in multiple second pages being opened at the same time. However, in browser page communication, multiple second pages are prone to message crosstalk and / or incorrect message transmission. Therefore, in step 210, the generated channel identifier is shared only between the first and second pages. In other words, a channel identifier exclusive to the first and second pages is generated, which can be used to generate a dedicated broadcast channel between the first and second pages.

[0037] See also Figure 2 In step S220, a broadcast channel based on the application programming interface (API) is established between the first page and the second page based on the channel identifier.

[0038] As mentioned earlier, a broadcast channel can be established between the first page and the second page based on the channel identifier. The channel identifier is shared by both the first and second pages, thus allowing for the binding of a correspondence between them. Based on this channel identifier, a broadcast channel is then created, enabling communication between the first and second pages within the established broadcast channel. For example, when a parent page navigates to a child page, a channel identifier (e.g., #1) is generated. The parent and child pages can share channel identifier #1, and a broadcast channel can be established based on #1. Thus, the parent and child pages sharing channel identifier #1 can communicate within this broadcast channel. In the case of multiple second pages, the first page can be bound to each second page using different channel identifiers, and corresponding broadcast channels can be established based on these different identifiers. Each channel identifier can be completely different, ensuring that communication between each second page and the first page is relatively independent based on different broadcast channels. This effectively prevents message crosstalk and / or incorrect message transmission between different broadcast channels.

[0039] Furthermore, based on channel identifiers, API-based broadcast channels can be established between the first and second pages, enabling communication between them. Traditional browser page communication typically relies on server-client data interaction, such as data push via full-duplex protocols (WebSockets). However, this approach suffers from message transmission delays because the server acts as an intermediary for uploading and downloading page data. Therefore, in this embodiment, an API-based broadcast channel can be established to achieve a server-free communication architecture, enabling peer-to-peer (P2P) communication between the first and second pages. For example, a broadcast channel between the first and second pages can be constructed using the BroadcastChannel API. As a native API of HTML5 browsers, the BroadcastChannel API allows same-origin interfaces to communicate via channel identifiers.

[0040] In this embodiment, the number of first pages is not specifically limited; there can be one or more first pages. Therefore, a broadcast channel binding relationship can be established based on at least one first page and at least one corresponding second page by binding channel identifiers. Specifically, a browser page can have multiple first pages, such as first page a and first page b. Each first page can generate multiple second pages. For example, first page a can generate second pages a1, a2, etc., while first page b can generate second pages b1, b2, etc. First page a can bind a "parent-child" relationship with second page a1 through a channel identifier (such as #1), and can also bind a parent-child relationship with second page a2 through a channel identifier #2; correspondingly, second page b can also bind a "parent-child" relationship with second pages b1 and b2 through channel identifiers &1 and &2, respectively. In actual testing, broadcast channels based on the BroadcastChannel API can support at least 200 sets of "parent-child" pages communicating simultaneously.

[0041] Channel identifiers can be generated by the first page and transmitted to the second page via a uniform resource locator (URL) parameter. For example, when the first page navigates to at least one second page, the first page can directly generate a channel identifier #1 corresponding to at least one second page. This channel identifier #1 can then be passed to the second page via a URL parameter, such as ?Channel=#1. The second page's URL parameter can then include this information segment, thereby achieving channel identifier sharing.

[0042] In some embodiments, the channel identifier can be a universally unique identifier (UUID). A UUID is a 128-bit identifier that can serve as unique identification information in a computer system. For example, when a jump from the first page to the second page is detected, the channel identifier generated by the first page can be a UUID, which is passed to the second page via a URL. As an example, when the first page jumps to the second page, the first page can generate a unique UUID using the UUID v4 algorithm and pass it to the second page in the format of a URL parameter (e.g., ?Channel=3fd4x). Since the UUID generated at any time and in any location is unique, this better ensures that the channel identifiers of the first page and different second pages are unique. Based on this UUID, the first page and the second page can also establish dedicated broadcast channels through the Broadcast Channel API. When multiple second pages are generated, since each UUID is completely different, the channel identifier in each broadcast channel is completely different when the first page communicates with different second pages. This better protects the independence and anti-interference capability of communication between different channels. In actual testing, the error trigger rate of information interference can be reduced from 12% to 0.03%.

[0043] Optionally, the channel identifier can be generated based on a hash algorithm. Encrypting the identifier information using a hash algorithm further ensures the uniqueness of the data and guarantees that the data has not been tampered with during transmission, thus ensuring the authenticity of the data source. In some embodiments, the channel identifier generated by the first page can be generated using the UUID v4 algorithm, and the corresponding URL parameters are converted. Then, the URL parameters are converted using a hash algorithm to generate a unique identifier, which is finally passed to the second page. As an example, the UUID generated by the first page for the second page could be 3fd4x, which can be converted into the URL parameter ?Channel=3fd4x. After hash processing, a unique identifier 550e8400-e29b-41d4-a716-446655440000 is generated. This not only further guarantees the uniqueness of the channel identifier but also ensures the integrity and authenticity of the data during transmission, thereby improving the security and reliability of communication.

[0044] The following is based on Figure 3 For example, describe the steps. Figure 2 The contents of steps S210 to S220. Figure 3 This is an interaction diagram between the first page, the second page, and the broadcast channel in the page refresh method of this application embodiment.

[0045] In step S310, when a jump from the first page to the second page is detected, a channel identifier is generated, which can be generated using the UUID v4 algorithm.

[0046] In step S320, a dedicated broadcast channel between the first page and the second page can be established based on the channel identifier. This broadcast channel can be established using the BroadcastChannel API. For example, the channel identifier generated when navigating from the first page to the second page could be 3fd4x. Then, a dedicated broadcast channel between the first page and the second page, BroadcastChannel(“3fd4x”), can be established using the BroadcastChannel API.

[0047] In step S330, the first page sends a URL parameter to the second page to transmit the channel identifier, thus enabling channel identifier sharing between the first and second pages. For example, the first page sends the URL parameter ?Channel=3fd4x to the second page. (Referring to...) Figure 3 Based on the established broadcast channel, the first and second pages can communicate directly within the broadcast channel without the need for a server as an intermediary for data interaction, and without consuming server storage resources. Compared to traditional polling or WebSocket solutions, the technical solution of this application can significantly reduce communication latency and server load. Actual test results show that, compared with traditional WebSocket solutions, the embodiments of this application can control message transmission latency to within 50 milliseconds and save approximately 82% of server resources.

[0048] Traditional local storage solutions typically rely on polling mechanisms to continuously detect data changes on the second page, and then use a "second page-server-first page" communication method to synchronize the data updates on the first page after the data on the second page is updated. However, since this solution requires data interaction with the server, it has a high response latency (e.g., up to 2 seconds) and also causes additional consumption of system resources.

[0049] To overcome the above problems, embodiments of this application can refresh the first page by monitoring predetermined events on the second page and transmitting event information through a broadcast channel.

[0050] See also Figure 2In step S230, when a predetermined event is detected on the second page, a first message from the second page is sent to the first page via a broadcast channel. This first message triggers a refresh of the first page. In this embodiment, by monitoring whether a predetermined event has occurred on the second page, and upon detecting that the predetermined event has been triggered, the second page sends a first message to the first page via a broadcast channel, triggering a refresh of the first page. Thus, by triggering a predetermined event on the second page and sending a first message to the first page, a refresh of the first page can be achieved.

[0051] The scheduled event occurring on the second page can be either an event indicating an impending departure from the second page or an event indicating a change in the content of the second page. Specifically, in some embodiments, an impending departure event can be understood as an event that occurs before leaving the page. When this event is triggered, the corresponding processing logic can be executed promptly. In computer page operations, the impending departure event is a type of page lifecycle event, commonly referred to as the beforeunload event. Therefore, monitoring scheduled events on the second page can also be achieved by monitoring whether the beforeunload event has occurred on the second page. It should be noted that page lifecycle events include various types, such as events indicating an impending departure from the page (denoted as the beforeunload event), events indicating leaving the page (denoted as the unload event), and events indicating that page resources have finished loading (denoted as the load event). Compared to monitoring other lifecycle events, the beforeunload event is triggered earlier. Taking the unload event as an example, it is usually triggered when the page has started to unload, while the beforeunload event can be triggered just before the user leaves the page. Therefore, by monitoring the beforeunload event, data update instructions or refresh notifications can be sent to the first page in advance before the user has completely left the current page, thereby effectively reducing communication latency and improving the real-time performance of inter-page collaborative responses.

[0052] In other embodiments, the predetermined event can also be an event in which the content of the second page changes, such as when the user edits and saves the second page, which is considered as a change in the content of the second page.

[0053] In some implementations, leaving the second page can involve closing the second page, and / or navigating to another page from the second page, and / or refreshing the second page. Users typically leave the second page when they have finished editing the data on the second page and want to return to the first page to view the updated content. For example, a user might click the close button on the second page to close it, or they might use navigation buttons on the browser (such as forward or back) to navigate to another page, or refresh the second page to confirm that the information has been saved correctly. Therefore, leaving the second page includes, but is not limited to, the methods described above.

[0054] Upon detecting a predetermined event on the second page, the second page sends a first message to the first page, which triggers the first page to perform a refresh operation. The first message can be, for example, a notification signal or an execution signal specifically instructing the first page to refresh. Upon receiving the first message, the first page refreshes the page and retrieves the latest data.

[0055] Furthermore, during communication via the broadcast channel, the second page can forward the first message to the first page through the broadcast channel. In this process, the first page triggers a message dispatch event (denoted as the `message` event), responds to the `message` event, receives the first message from the broadcast channel, and thus refreshes the page.

[0056] Optionally, the first page can proactively fetch the latest data before performing a page refresh. For example, it can request the server to return the latest data content by calling a function interface called refreshData().

[0057] Furthermore, the BroadcastChannel API supports an event-driven mechanism, meaning it can better respond to pre-defined events. For example, when the second page triggers a beforeunload event and / or other events causing changes to the content of the second page, the BroadcastChannel API can respond quickly, enabling rapid information delivery and fast page synchronization with the first page. In actual testing, by monitoring the second page's beforeunload event to refresh the first page within a broadcast channel established using the BroadcastChannel API, the response latency of the first page was reduced from 2000 milliseconds to less than 50 milliseconds, improving interaction efficiency by 97%. Additionally, in stress testing of an e-commerce order management system, the synchronization time for processing 50 orders was reduced from 8 minutes to 2 minutes.

[0058] In some embodiments, when a predetermined event occurs on the second page, a second message from the second page can be sent to the first page, and a response message from the first page to the second message can be sent to the second page. The second message is used to indicate that a predetermined event has occurred on the second page, and the first message is generated after the second page receives the response message.

[0059] The second message can be a message that a predetermined event is triggered by a second page. For example, the second message can be implemented in the form of program code, such as {type: 'PAGE_CLOSE', timestamp: 1711970171}. The code of the second message contains information about the page being closed and timestamp information, which is used to indicate when the second message is sent.

[0060] After the first page receives the second message sent by the second page, it can send a response message generated in response to the second message to the second page. This response message indicates that the first page has successfully received the second message. In some implementations, the response message can be implemented using an acknowledgment (ACK) mechanism. Specifically, based on the ACK mechanism, after detecting the second message, the first page can generate a corresponding response message according to preset message response rules and send this response message back to the second page. The feedback of the response message ensures that the first page has received the second message, which helps to synchronize the states of the first and second pages.

[0061] In some cases, if the second page fails to receive a response message from the first page within a certain period of time, it can be determined that there is a communication failure in the broadcast channel. In this case, it is possible to try to resend the second message and / or send the failure information back to the browser page.

[0062] In some implementations, the first page and the second page can listen for messages by subscribing to message events bidirectionally (denoted as the onmessage event). For example, when the second page sends a second message to the first page, or when the first page sends a response message, the onmessage event can be triggered, allowing both pages to receive each other's messages in real time. This facilitates state synchronization between the first and second pages and enables low-latency channel communication.

[0063] Optionally, the first page can also determine whether the second page has been physically closed by receiving a notification message from the browser, and based on the triggering of the notification message, send a response message to the second page. After receiving the response message from the first page, the second page can send a first message to the first page, which instructs the first page to perform a refresh.

[0064] In some implementations, the first page is refreshed based on the first message. Specifically, in a broadcast channel communication mechanism, the first message can be listened for using the `onmessage` event. When the first page receives the first message, it can immediately trigger the page refresh process without waiting for additional data loading or parsing, thereby reducing the amount of data processed by the page and improving refresh response speed.

[0065] Alternatively, in some implementations, while the first page is listening for the second message sent by the second page, it can also listen for the message refresh event (denoted as the a_refresh event) in the broadcast channel based on the onmessage event. If the a_refresh event is triggered, the first page can also perform a page refresh. In other words, the first page may perform a refresh operation based on the first message from the second page and / or that message refresh event.

[0066] When refreshing the first page, optionally, the first page can be refreshed based on the fields that have changed on the second page. Refreshing the first page based on changed fields can be achieved in several ways. For example, browser server resources can be utilized. When editing the second page, the edited data and / or fields can be uploaded to the server. When the first page is refreshed, only the changed data and / or fields are downloaded from the server, thus refreshing the first page only for the changed parts of the content. Another example is when the second page sends a second message. Since the edited data and / or fields are not numerous and the data volume is small, the changed data and / or field information can be marked in the second message. After receiving the response message from the first page, the marked first message is communicated to the first page, and the content of the first page is updated based on the information marked in the first message.

[0067] After establishing a broadcast channel between the first page and at least one second page, each broadcast channel consumes certain system resources, such as central processing unit (CPU) resources and memory resources. However, compared to the average 38% CPU utilization caused by continuously listening for storage events, the page refresh method involved in this application adopts a design of creating broadcast channels on demand. That is, the second page that the user jumps to only binds the broadcast channel communication relationship with the first page when the user needs to modify the page data. Furthermore, in actual testing, the memory consumption of a single channel is within 3 megabytes, the peak CPU utilization is less than 0.1%, and the resource consumption is reduced by 89%. In addition, the BroadcastChannel API involved in this application supports the browser's native ES6 (ECMAScript 2015) standard, making it more applicable to users and increasing user coverage from 78% to 98%, completely solving the pain point of web browser (Internet Explorer) compatibility.

[0068] Furthermore, in some implementations, the broadcast channel can be closed after the first page is refreshed to release resources and conserve system resources. For example, after at least one second page has finished editing, the first page refreshes, and the browser can then close the dedicated broadcast channel established between the second page and the first page, releasing the resources occupied by the channel. This does not affect communication within the corresponding dedicated broadcast channels established between other second pages and the first page.

[0069] Combination Figure 4 , Figure 4 This diagram illustrates one possible way to refresh the first page. Using the first page as parent page A, the second page as child page B, and a broadcast channel C built based on the BroadcastChannel API with the beforeunload event as a predefined event, we will introduce one method for refreshing the first page.

[0070] In step 401, the user closes subpage B.

[0071] In step 402, the beforeunload event of subpage B is triggered.

[0072] The beforeunload event is triggered before closing child page B, so that the event is triggered earlier and the first message can be sent to the parent page A earlier.

[0073] In steps 403 and 404, subpage B sends the first message to broadcast channel C, and broadcast channel C dispatches a message event to the first page.

[0074] Optionally, the first message can be an instruction indicating that the parent page A needs to be refreshed, or it can be program code information, such as {type: 'PAGE_CLOSE', timestamp: 1711970171}. The first message includes information about the closing of the subpage B and a timestamp, which records the time when the first message was sent.

[0075] In step 403, subpage B can also directly send the first message to parent page A via broadcast channel C.

[0076] In step 404, after receiving the first message, parent page A retrieves the latest data.

[0077] After receiving the first message, parent page A can still fetch the latest data before performing a page refresh. For example, the latest data can be fetched using the program code refreshData()n.

[0078] In step 406, refresh the parent page A.

[0079] In actual testing, by monitoring the triggering of the `beforeunload` event on the second page, the transmission of the refresh message for the first page can be achieved quickly and accurately, with a success rate greater than 99.97%. Furthermore, because it only requires monitoring whether the `beforeunload` event on the second page is triggered, and the first page can receive the first message via a broadcast channel to refresh the page after triggering, it overcomes the problem of excessive data volume during inter-page communication in local caching solutions and solves the signal loss problem that may occur due to page crashes or forced page termination in traditional solutions.

[0080] See also Figure 5 , Figure 5 yes Figure 1 The diagram illustrates one possible implementation of the page refresh method. In the broadcast channel, parent page 510 and child page 520 can communicate based on a shared channel identifier. Parent page 510 is mapped to parent channel 516 in the broadcast channel, and child page 520 is mapped to sub-channel 526. Both the parent and child channels are part of the broadcast channel and share the same channel identifier. Both the parent and child pages have a data refresh module and a data receiving / sending module.

[0081] When a user closes a subpage, a scheduled event (such as the beforeunload event) occurs on the subpage. At this time, the subpage can record the scheduled event trigger message 51 on the subchannel, and then the subpage sends the second message 52 to the parent channel through the subchannel. When the parent channel receives the second message 52, it means that the parent page has received the second message 52.

[0082] In some cases, when a scheduled event occurs on a child page, the parent page can also receive a notification message from the browser to obtain information that the child page has been physically closed, such as third message 53.

[0083] Following this, the parent page can send a confirmation message 54 (acknowledgment message 54) to the child channel, confirming receipt of the second message 52 and / or the third message 53. This confirmation message 54 can also be sent via the ACK mechanism. After the child page receives the confirmation message from the parent page, the second page sends the first message to the parent page, and the parent page responds by performing a refresh operation. In some cases, the parent page can also perform a refresh operation when a message refresh event 55 (i.e., the a_refresh event) is triggered in the broadcast channel.

[0084] The above describes how to refresh the first page when navigating from the first page to the second page. Upon detecting a transition from the first page to the second page, a broadcast channel based on the Application Programming Interface (API) is established between the two pages using a shared channel identifier. Then, when a predetermined event occurs on the second page, the first message from the second page is sent to the first page via the broadcast channel, triggering a refresh of the first page. In this embodiment, by establishing a "parent-child relationship" between the first and second pages, when the second page is opened, the browser can record that it originated from the first page. When the second page is closed, it notifies the first page, similar to sending a message to parents before leaving home. Upon receiving the notification, the first page automatically updates its data. This is equivalent to establishing a "page family group" within the browser, where any changes in any member can promptly notify related pages. This eliminates the need for frequent refreshes and ensures that important updates are not missed. Therefore, it solves the problem of asynchronous states between different pages, offering advantages such as fast response speed, high reliability, and low resource consumption.

[0085] The page update method in this application embodiment is described in more detail below with reference to exemplary JavaScript code that can implement the embodiments of this application. In the examples below, the first page is the parent page, the second page is the child page, a channel ID can be generated according to UUID v4, the parent page and the child page establish a broadcast channel based on the BroadcastChannel API, and the predetermined event that occurs on the second page is the beforeunload event. It should be noted that the examples shown below are only for helping those skilled in the art to understand the embodiments of this application, and are not intended to limit the embodiments of this application to the specific values ​​or specific scenarios exemplified. Those skilled in the art can obviously make various equivalent modifications or changes based on the examples given below, and such modifications or changes also fall within the scope of the embodiments of this application.

[0086] When a parent page navigates to a child page, the parent page can generate a shared channel identifier between the parent and child pages based on the UUID v4 algorithm, for example, 3fd4x. This process can be implemented using the following JavaScript code: / / Generate channel ID on parent page const channelId = crypto.randomUUID(); / / Pass parameters when opening a child page to share the channel ID with the parent page. window.open(`child.html?channel=${encodeURIComponent(channelId)}`); Subsequently, the parent and child pages can establish a broadcast channel based on the BroadcastChannel API. Simultaneously, the parent page passes the generated channel identifier to the child page via a URL. For example, the URL parameter could be in the form of ?channel=3fd4x. Optionally, the channel identifier can also be generated using a hash algorithm, and the URL parameter is encrypted using a hash algorithm before being passed. This process can be implemented using the following JavaScript code: / / Establish a broadcast channel between the parent page and the child page based on the BroadcastChannel API const parentChannel = new BroadcastChannel(channelId); parentChannel.onmessage = handleMessage; / / Get parameters from subpage const urlParams = new URLSearchParams(location.search); const childChannel = new BroadcastChannel(urlParams.get('channel')); Subsequently, the `beforeunload` event of the child page is monitored. When the child page detects that it is about to leave the child page, it can communicate the information that triggered the `beforeunload` event to the parent page in the broadcast channel. After receiving the response message from the parent page, the child page sends a message instructing the parent page to refresh, thereby refreshing the parent page. The parent page can then send a response message back to the child page based on the ACK confirmation mechanism. All the messages mentioned above can trigger the `onmessage` event, enabling each communicating party (e.g., parent page and child page) to achieve accurate message delivery and triggering while adhering to the same-origin policy. This improves the communication success rate between the parties and reduces communication latency.

[0087] Finally, after refreshing the parent page, close the broadcast channel and release system resources.

[0088] The above process can be implemented, for example, using the following JavaScript code: / / Listen for the beforeunload event of the child page window.addEventListener('beforeunload', () =>{ childChannel.postMessage({ type: 'PAGE_CLOSE', timestamp: Date.now(), pageId: window.name }); childChannel.close(); }); / / Parent page's response method function handleMessage(event) { if (event.data.type === 'PAGE_CLOSE') { fetchLatestData().then(updateUI); parentChannel.close();} } The above text combined Figures 1 to 5 The method embodiments of this application are described in detail below, in conjunction with... Figures 6 to 7 This application provides a detailed description of the apparatus and device embodiments. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be found in the foregoing method embodiments.

[0089] Figure 6 This is a schematic diagram of the structure of a page refresh device provided in an embodiment of this application. Figure 6 As shown, the device 600 includes a channel establishment module 610 and a message processing module 620. The channel establishment module 610 is used to generate a shared channel identifier between the first page and the second page when a jump from a first page to a second page is detected, wherein the second page and the first page are from the same origin. The channel establishment module 610 is also used to establish a broadcast channel based on an application programming interface (API) between the first page and the second page based on the channel identifier. The message processing module 620 is used to send a first message from the second page to the first page through the broadcast channel when a predetermined event is detected on the second page, wherein the first message triggers a refresh of the first page.

[0090] In some implementations, the channel identifier is generated by the first page and transmitted to the second page via a URL parameter.

[0091] In some implementations, the channel identifier is a UUID.

[0092] In some implementations, the channel identifier is generated based on a hash algorithm.

[0093] In some implementations, the predetermined events include: an event indicating that the user is about to leave the second page; and / or an event indicating that the content within the second page has changed.

[0094] In some implementations, leaving the second page includes: closing the second page; and / or navigating from the second page to another page; and / or refreshing the second page.

[0095] In some implementations, the message processing module 620 is further configured to: send a second message from the second page to the first page via the broadcast channel, and send a response message from the first page to the second page in response to the second message, wherein the second message is used to indicate that the predetermined event has occurred on the second page; wherein the first message is generated after the second page receives the response message.

[0096] In some implementations, the first page and the second page listen for messages by subscribing to message events in both directions.

[0097] In some implementations, the message processing module 620 is further configured to: refresh the first page based on the fields that have changed in the second page.

[0098] In some implementations, the message processing module 520 is also used to: close the broadcast channel.

[0099] This application also provides a page refresh device, such as... Figure 7 As shown, Figure 7 This is a schematic diagram of the structure of a page refresh device provided in an embodiment of this application. The page refresh device 600 includes a memory 710 and a processor 720. The memory 710 is used to store program code, and the processor 720 is used to call the program code in the memory so that the page refresh device 700 executes the method described in any of the foregoing embodiments.

[0100] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0101] 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.

[0102] In addition, the functional units in the various embodiments of this application 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.

[0103] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0104] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A page refresh method, characterized in that, The method includes: When a jump from the first page to the second page is detected, a channel identifier shared between the first page and the second page is generated, and the second page and the first page are pages from the same origin; Based on the channel identifier, a broadcast channel based on the application programming interface (API) is established between the first page and the second page; When a predetermined event is detected on the second page, a first message of the second page is sent to the first page through the broadcast channel. The first message is used to trigger a refresh of the first page.

2. The method according to claim 1, characterized in that, The channel identifier is generated by the first page and transmitted to the second page via the resource locator URL parameter.

3. The method according to claim 1 or 2, characterized in that, The channel identifier is a universally unique identifier (UUID).

4. The method according to claim 1, characterized in that, The channel identifier is generated based on a hash algorithm.

5. The method according to claim 1, characterized in that, The scheduled events include: The event that indicates the user is about to leave the second page; and / or, The event that the content within the second page changes.

6. The method according to claim 5, characterized in that, Leaving the second page includes: Close the second page; and / or, Navigate to other pages from the second page; and / or, Refresh the second page.

7. The method according to claim 1, characterized in that, The method further includes: The second message from the second page is sent to the first page via the broadcast channel, and the response message from the first page to the second message is sent to the second page. The second message is used to indicate that the predetermined event has occurred on the second page. The first message is generated after the response message is received on the second page.

8. The method according to claim 1, characterized in that, The first page and the second page listen for messages through a two-way subscription to message events.

9. The method according to claim 1, characterized in that, The method further includes: Based on the first message, refresh the first page.

10. The method according to claim 9, characterized in that, Refreshing the first page includes: The first page is refreshed based on the fields that have changed on the second page.

11. The method according to claim 9, characterized in that, The method further includes: The broadcast channel is turned off.

12. A page refresh device, characterized in that, include: The channel creation module is used to generate a shared channel identifier between the first page and the second page when a jump from the first page to the second page is detected, wherein the second page and the first page are pages with the same origin. The channel establishment module is also used to establish a broadcast channel based on the application programming interface (API) between the first page and the second page based on the channel identifier. The message processing module is used to send a first message of the second page to the first page through the broadcast channel when a predetermined event is detected on the second page. The first message is used to trigger a refresh of the first page.

13. A page refresh device, characterized in that, The system includes a memory and a processor, the memory being used to store program code, and the processor being used to invoke the program code in the memory to cause the vehicle controller to perform the method of any one of claims 1 to 11.

Images