A native return adaptation method, system and device for a mobile web application

Abstract

The application discloses a native return adaptation method, system and device of a mobile Web application, relates to the technical field of computer software development, and comprises the following steps: when a pop-up layer opening event is listened to, a pop-up layer ID of the pop-up layer opening event and a corresponding pop-up layer closing method are encapsulated as an entry and stored in a native return stack, and a pop-up layer redundant history record is stored in a history record stack; when a back operation is listened to, a top entry in the native return stack is called, a corresponding pop-up layer closing method is executed on the pop-up layer ID in the top entry, and the current top entry is removed from the native return stack; when a pop-up layer closing event is listened to, an entry corresponding to a pop-up layer ID of the pop-up layer closing event is removed from the native return stack, and the last pop-up layer redundant history record is returned to. In the case of not violating the browser security strategy, the problem that an existing page cannot handle user native return is solved, and the use experience of the user is improved.

Description

Technical Field

[0001] This invention relates to the field of computer software development technology, and in particular to a native return adaptation method, system and device for mobile web applications. Background Technology

[0002] In mobile HTML5 pages, pop-ups or pop-up pages are frequently used. For example, when a user clicks on an attachment item on a page, a preview page pops up to zoom in on an image or display the content of a Word or Excel document. Another example is when a user clicks on a date field in a form, a date editor pop-up slides in from the bottom of the screen to edit the date value. Based on usage habits, users are more likely to use a gesture to return and try to close these pop-ups rather than clicking the close button on the pop-up.

[0003] With touchscreen phones, users can trigger the native back button in mobile browsers using system-level gestures. Therefore, for a better user experience, mobile HTML5 pages need to support users in closing pop-ups or pop-up pages by triggering the native back button. Otherwise, if a user tries to close a pop-up by using gestures, the page will return to the previous history, causing all edits made in the current form to be lost.

[0004] In another scenario, handling native user back actions is also necessary: ​​On an editing page, the normal workflow is for the user to fill in the various fields of a form, click the "Save" button at the bottom of the page, and then return to the previous page after successful saving. However, the user might forget to save and directly return to the previous page. In this case, the page should ideally intercept the user's back action, remain on the current page, and prompt the user that there are unsaved changes, asking if they want to abandon the changes on the current page. If the user triggers the back action by clicking the provided back button, the page can easily achieve the above functionality. However, if the user triggers a native back action, it is difficult for the page to intercept the back action.

[0005] Currently, mobile HTML5 pages can intercept native responses through the following process:

[0006] (1) Whenever a new page is opened, push a redundant history record using the history.pushState method.

[0007] (2) When the user triggers the native back operation, since the page has already pushed a redundant history record in advance, the page will not return directly to the previous page, but will stay in the current page and trigger the popstate event;

[0008] The popstate event is triggered when a browser history entry changes. Specifically, the popstate event is triggered when a user clicks the browser's "back" and "forward" buttons, or when a JavaScript method such as history.pushState is called using JavaScript (a just-in-time compiled programming language).

[0009] (3) Listen for the popstate event on the page. In the callback method of each triggered popstate event, determine whether it is necessary to return to the previous page. If it is necessary to return to the previous page, execute the history.back method. If it is not necessary to return to the previous page, execute the history.pushState method again to push redundant history records, thereby intercepting the native return and executing other business code, such as closing the pop-up layer opened on the page or prompting the user that there are unsaved changes.

[0010] However, malicious web pages can repeatedly intercept users' back actions using the above methods, preventing users from returning to earlier pages. To address this issue, browsers have introduced a series of security strategies, such as ignoring all historical data interactions prior to the first interaction with a user when opening a new page. Most modern mainstream browsers have implemented similar security strategies. If HTML5 pages continue to use this method to intercept users' back actions, not only will it fail, but it will also cause other unexpected routing problems within the single-page application itself.

[0011] For the reasons mentioned above, existing mobile HTML5 pages often do not support closing pop-ups on the page via native backspace, nor do they support other processing of native backspace. Summary of the Invention

[0012] To address the aforementioned issues, this invention proposes a native return adaptation method, system, and device for mobile web applications. Without violating browser security policies, it resolves the problem that existing pages cannot handle native user returns, thereby improving the user experience.

[0013] To achieve the above objectives, the present invention adopts the following technical solution:

[0014] In a first aspect, the present invention provides a native return adaptation method for mobile web applications, comprising:

[0015] When a pop-up open event is detected, the pop-up ID and the corresponding pop-up close method are encapsulated as entries and stored in the native return stack, and redundant pop-up history records are stored in the history stack. If at least two pop-ups corresponding to an interaction are detected at the same time, the time interval between any two redundant pop-up history records stored is greater than a set value.

[0016] When a back operation is detected, the top item in the native back stack is called, the corresponding pop-up close method is executed for the pop-up ID in the top item, and the current top item is removed from the native back stack.

[0017] When a pop-up close event is detected, the entry corresponding to the pop-up ID of the pop-up close event is removed from the native back stack, and the process is moved back to the previous redundant pop-up history.

[0018] As an alternative implementation, when storing redundant historical records from the pop-up layer in the history record stack, a status parameter is added to distinguish the type of redundant historical records.

[0019] As an alternative implementation, when a pop-up close event is detected, the system determines whether the current redundant history record is a redundant history record of the pop-up type based on the status parameters; if so, it goes back to the previous redundant history record of the pop-up.

[0020] As an alternative implementation, the process of detecting a back operation involves: listening to the popstate event and determining whether the popstate event was triggered by a back operation; specifically:

[0021] During page initialization, the history.replaceState method is called to replace the history.state object. The history.state object maintains a position field to record the position of the current redundant history records.

[0022] When the history.pushState method is called to store redundant history of the pop-up in the history stack, a state parameter is added. The state parameter includes a position field, and the value of the position field is equal to the current position field value of the page plus one.

[0023] When listening to the popstate event, get the value of the current page's position field and use it as the new value. Subtract the old value from the new value. When the resulting popstate difference is less than 0, it means that the popstate event was triggered by the back operation.

[0024] As an alternative implementation, the native return adaptation method for the mobile web application further includes: if the client app provides a native return interception interface through the JavaScript SDK, then during the native return adaptation process, it is first determined whether the current execution environment provides a native return interception interface; if a native return interception interface is provided, then a callback method for native return is registered through the native return interception interface.

[0025] As an alternative implementation method, the callback method includes:

[0026] Check if the native back stack is empty. If it is not empty, call the top item in the native back stack, execute the corresponding pop-up close method for the pop-up ID in the top item, remove the current top item from the native back stack, and reject the current back operation.

[0027] If the native back stack is empty, check if there are any unsaved changes on the current page. If so, reject the back operation and display a prompt asking the user if they want to abandon the changes. If the user chooses to abandon the changes, execute the back operation. If the user chooses to cancel, stay on the current page. If there are no unsaved changes, allow the back operation.

[0028] As an alternative implementation, when the client app supports the native return interception interface, when a pop-up open event is detected, only the pop-up open event is stored in the native return stack, without adding redundant pop-up history records.

[0029] Meanwhile, when the pop-up close event is detected, only the entry corresponding to the closed pop-up is removed from the native back stack, and the browser back operation is not performed.

[0030] As an alternative implementation, when the client app supports the native return interception interface, the process of closing the pop-up layer via native return includes:

[0031] The web application initializes and checks the runtime environment; the client APP returns whether it supports the native return interception interface; and the web application registers the callback method of the native return interception interface.

[0032] When a pop-up open event is detected, the pop-up ID and the corresponding pop-up close method are encapsulated as entries and stored in the native return stack.

[0033] When the native return is triggered, the callback method is executed.

[0034] Secondly, the present invention provides a native return adaptation system for mobile web applications, comprising:

[0035] The storage module is configured to encapsulate the pop-up ID and the corresponding pop-up close method into an entry and store it in the native return stack when a pop-up open event is detected, and to store redundant pop-up history records in the history stack; wherein, if at least two pop-ups corresponding to an interaction are detected at the same time, the time interval between storing any two redundant pop-up history records is greater than a set value.

[0036] The back execution module is configured to, when a back operation is detected, call the top item in the native back stack, execute the corresponding pop-up close method for the pop-up ID in the top item, and remove the current top item from the native back stack;

[0037] The shutdown execution module is configured to remove the entry corresponding to the pop-up ID of the pop-up closing event from the native back stack when a pop-up closing event is detected, and then go back to the previous redundant pop-up history.

[0038] Thirdly, the present invention provides an electronic device including a memory and a processor, and computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.

[0039] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0040] This invention proposes a native back navigation adaptation method for mobile web applications, allowing users to close pop-ups via native back navigation. When a user opens a pop-up, a redundant history entry corresponding to the opened pop-up is pushed onto the history stack, and a pop-up close method is also pushed onto the native back navigation stack. The browser's back navigation is monitored, and the native back navigation stack is checked for emptiness. If not empty, an entry is popped up, and the pop-up close method in the entry is executed to close the corresponding pop-up. If the user closes the pop-up by clicking the close button on the pop-up or using other non-native back navigation methods, the corresponding close method needs to be removed from the native back navigation stack, and the redundant history entry's impact on routing is eliminated by executing the `history.back` method. This solves the problem of existing mobile HTML5 pages being unable to handle native back navigation without violating browser security policies, thus improving the user experience.

[0041] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

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

[0043] Figure 1 This is a flowchart of the native return adaptation method for mobile web applications provided in Embodiment 1 of the present invention;

[0044] Figure 2 This is a flowchart of opening a pop-up layer and closing it via native return, as provided in Embodiment 1 of the present invention;

[0045] Figure 3 This is a flowchart of opening a pop-up layer and closing it in other ways, as provided in Embodiment 1 of the present invention;

[0046] Figure 4 This is a flowchart illustrating how a client app can close a pop-up layer via native return when intercepting a native return interface, as provided in Embodiment 1 of the present invention. Detailed Implementation

[0047] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0048] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0049] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form as well. Furthermore, it should be understood that the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0050] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0051] When developing mobile apps, enterprises have three popular development technologies to choose from: native apps, web apps, and hybrid apps. If a native app is chosen, existing native return interception operations can be used. This invention focuses on the scenarios of web apps and hybrid apps.

[0052] Hybrid technology is a development approach that combines native applications with HTML5 web technologies, allowing developers to use both native APIs (native application programming interfaces) and web technologies within a single application. The advantage of this technology is that it maintains the flexibility and cross-platform capabilities of web technologies while leveraging native APIs to improve application performance and user experience.

[0053] Specifically, Hybrid technology achieves this by embedding a WebView component within a native application. A WebView is a special browser window that displays web page content within the native application and can interact with native code. This allows HTML5 pages to access hardware functions such as the device's camera, photo album, and GPS location via JavaScript to call native APIs. For example, when a user selects to upload an image on an HTML5 page, the native image picker can be invoked, instead of being limited to the standard file input on the webpage. This enables attachment upload components on HTML5 pages to also utilize native mobile application capabilities such as taking photos and recording short videos.

[0054] When developing a Hybrid App, if the client App's JsBridge (JSBridge is a bidirectional communication mechanism between JavaScript and native apps, a core bridging technology designed specifically for Hybrid App development) provides an interface for intercepting native back navigation, then this interface can be used to achieve requirements such as closing pop-ups on the page or prompting the user about unsaved changes upon returning. However, not all client Apps provide a native back navigation interception interface in JsBridge. Some client Apps, while providing similar native back navigation interception interfaces in their JS SDK (JS SDK is a JavaScript software development kit for front-end development, providing JavaScript APIs to help developers quickly integrate specific functions into web or mobile pages, such as social sharing, payment, and device information retrieval), may only be effective on Android and not on iOS, or may be subject to other limitations. If the web application only needs to run on the company's own client App, then the client App can be required to support a back navigation interception interface. Some low-code development platforms generate HTML5 code as front-end applications and claim that the code generated by the low-code platform is compatible with various mainstream client apps. Some customers may also need to integrate the application generated by the platform into their own enterprise apps. In this case, it is not possible to rely on all client apps to support the return interception interface in the JS_SDK. There must be a universal routing mechanism based on the capabilities of the Web itself to adapt to the main scenarios that need to adapt to native returns.

[0055] Therefore, this invention provides a native return adaptation method for mobile web applications, which can be used to improve the user experience in pure web app scenarios and hybrid app scenarios where the client JS_SDK does not support the native return interception interface.

[0056] Example 1

[0057] Assume the mobile web application is a single-page application built on the Vue+VueRouter framework. However, this embodiment is not limited to the Vue framework or single-page applications. With certain adaptive modifications, it is also applicable to multi-page applications, applications built using other front-end frameworks, and web applications developed entirely using HTML5, CSS (Cascading Style Sheets, a computer language used to style HTML (an application of Standard Generalized Markup Language) or XML (a subset of Standard Generalized Markup Language), and JavaScript without relying on any front-end framework.

[0058] like Figure 1 As shown, this embodiment proposes a native return adaptation method for mobile web applications, enabling users to close pop-up layers within the page via native return, specifically including:

[0059] S101: When a pop-up open event is detected, the pop-up ID and the corresponding pop-up close method of the pop-up open event are encapsulated as entries and stored in the native return stack, and redundant pop-up history records are stored in the history stack; where, if at least two pop-ups corresponding to an interaction are detected at the same time, the time interval between any two redundant pop-up history records stored is greater than a set value.

[0060] S102: When a back operation is detected, the top item in the native back stack is called, the corresponding pop-up close method is executed for the pop-up ID in the top item, and the current top item is removed from the native back stack;

[0061] S103: When a pop-up close event is detected, remove the entry corresponding to the pop-up ID of the pop-up close event from the native back stack and go back to the previous redundant pop-up history.

[0062] For all pop-up components that can open and need to support closing via native back navigation, two events must be uniformly supported. First, a pop-up open event is thrown when the pop-up component opens the pop-up. The parameters of the pop-up open event include the unique pop-up ID of the opened pop-up and the pop-up close method used to close it. Second, a pop-up close event is thrown when the user closes the pop-up via a non-native back navigation method. The parameters of the pop-up close event include the unique pop-up ID of the opened pop-up.

[0063] Taking a previewable image component as an example, this component displays a thumbnail by default. When the user clicks the thumbnail, a pop-up component opens a full-screen pop-up for viewing the larger image. The pop-up has a close button in the upper right corner; when the user clicks the close button, the pop-up component closes the pop-up. Therefore, this image component needs to throw a pop-up open event after the user clicks the thumbnail, and a pop-up close event after the user clicks the close button in the upper right corner of the full-screen pop-up.

[0064] When a user opens a popup within a web page and triggers the native back action, the browser should be prevented from directly returning to the previous page. To achieve this, a redundant history entry is pushed onto the browser's history stack when the popup is opened.

[0065] It is important to note that due to new browser security policies, history operations performed before a user's first interaction with a web page will be ignored. Therefore, redundant history entries must be added in the event listener callback function of the user's interaction with the pop-up.

[0066] Meanwhile, maintaining a unique native back stack within a web page in a web application can be achieved using an array of objects on a global object. This native back stack stores information about all pop-ups that are currently open on the web page. Each entry in the native back stack is an object containing the unique ID of the corresponding pop-up and a method for closing the pop-up.

[0067] Therefore, the web application listens for the pop-up open and close events of all components in the web page; when a pop-up open event is detected, the following operations are performed:

[0068] (1) Push the parameters of the pop-up opening event (i.e., the pop-up ID and the corresponding pop-up closing method) onto the native return stack.

[0069] (2) By executing the history.pushState method, a redundant history record of the pop-up layer is pushed onto the browser's history stack.

[0070] It's important to note that if your web application uses a routing framework, you should use the methods provided by the routing framework to add redundant history records to the pop-up to avoid affecting the operation of the routing framework itself. For example, when using the VueRouter framework, you should call the `push` method of the route instance to add redundant history records to the pop-up. The `push` method will ultimately call the `history.pushState` method, but it also maintains some internal state of VueRouter during this process.

[0071] For better scalability, when adding redundant pop-up history records, additional state information is set for the newly added redundant history records by passing a state parameter. The state parameter should at least include a field to distinguish the type of redundant history record. This is because the history stack not only includes redundant history records used to support closing the pop-up via native return, but also redundant history records used to support other functions.

[0072] Therefore, when the pop-up close event is detected, the following operations are performed:

[0073] (1) Remove the entry corresponding to the pop-up ID of the pop-up closing event from the native back stack.

[0074] (2) By using history.state, i.e. based on the state parameter, determine whether the current redundant history is a pop-up layer type redundant history; if so, by executing history.back() or history.go(-1) method, go back to the previous redundant history, consume the current redundant history, eliminate the impact of the current redundant history on the route, and avoid the next native return being invalid.

[0075] It's important to note that if your web application uses a routing framework, you should avoid calling the `history.back` method to prevent it from affecting the routing framework. For example, when adding a VueRouter route guard, calling `history.back` will trigger the route guard, but you don't want it to be triggered when the popup is closed. Instead of calling `history.back`, you can call `vueRouterInstance.options.history.go(-1, false)`, which will both allow you to go back one history level and prevent the route guard from being triggered.

[0076] In this embodiment, when implementing the listening for pop-up open and close events, a scenario also needs to be considered: a scenario where a user interacts with a web page and simultaneously opens two or more pop-ups. In this scenario, after a user interacts with the web page, two or more pop-ups open simultaneously, and each pop-up needs to support closing via native backspace.

[0077] This scenario can lead to the `history.pushState` method being called two or more times consecutively. In some older browsers or browsers with special implementations, when `history.pushState` is called twice consecutively, the browser will ignore the first call, and only the second call will actually take effect.

[0078] To ensure compatibility with these browsers, the time interval between any two history storage operations must be greater than a set value. If the time interval between two calls to `history.pushState` is greater than this value, both calls will take effect. Experiments have shown that 200ms is a relatively reliable value, enabling a minimum time interval execution queue. This ensures that the execution time interval between all methods added to the queue is at least 200ms. For methods involving browser history operations, consider placing them in the queue to guarantee their effectiveness.

[0079] Web applications need to listen for native back events on a page and execute business logic code after the user triggers the native back event to implement functions such as closing pop-ups on the page. However, HTML5 does not directly provide native back events, so it is necessary to listen for the popstate event to achieve this.

[0080] The popstate event is triggered when the browser moves forward or backward. Since the pop-up closing operation only needs to be performed when the browser moves back, it is necessary to distinguish whether the popstate event is triggered because the browser moves forward or backward. If the popstate event is triggered because the browser moves forward, no processing is performed.

[0081] Since the popstate event does not specify how the event is triggered in its parameters, the following method can be used to determine whether the popstate event is triggered by the browser back button; specifically:

[0082] (1) When the page is initialized, the history.replaceState method is called to replace the history.state object. The position field is maintained in the history.state object to record the position of the current redundant history records.

[0083] (2) Whenever the history.pushState method is called to store redundant history records in the history stack, the state parameter needs to be passed in, which includes the position field. The value of the position field is equal to the current position field value of the page plus one.

[0084] (3) Whenever the popstate event is triggered, in the popstate event listener method, first get the value of the current page's position field as the new value, and then subtract the old value from the new value; if the result is greater than 0, it means that the popstate event is triggered because the browser moves forward; if the result is less than 0, it means that the popstate event is triggered because the browser moves backward.

[0085] If your web application uses a routing framework, you can check whether the routing framework itself supports distinguishing between browser forward and browser back operations. For example, the VueRouter framework provides the vueRouterInstance.options.history.listen interface, which can be used directly to listen for forward or backward history.

[0086] The web application listens for the popstate event and determines whether the popstate event was triggered by a user-initiated native back action. If so, it performs the following steps:

[0087] (1) Determine if the native return stack is empty; if it is not empty, pop the top item from the native return stack.

[0088] (2) Execute the pop-up layer closing method in the top stack entry, close the corresponding pop-up layer, and remove the current top stack entry from the native return stack.

[0089] This allows for support for users to close pop-ups in web pages via native back navigation.

[0090] Figure 2 The process of opening a pop-up for the user and then closing it via native return includes the following steps:

[0091] (1) The user clicks on an element to open a pop-up layer.

[0092] (2) The pop-up component throws a pop-up open event; the parameters of the pop-up open event include the pop-up ID and the corresponding pop-up close method.

[0093] (3) After receiving the pop-up open event, the Web application pushes the parameters of the pop-up open event onto the native return stack.

[0094] (4) Execute the history.pushState method to add a pop-up layer of redundant history records to the history stack.

[0095] (5) Pop-up component displays pop-up layer.

[0096] (6) After the user triggers the native return, the popstate event is triggered.

[0097] (7) The Web application listens for the popstate event and verifies that it is a back operation. That is, when the popstate difference is <0, it checks whether the native back stack is empty. If it is not empty, it pops the top item from the native back stack and executes the pop-up closing method in the top item to close the corresponding pop-up.

[0098] Figure 3 The process of opening a pop-up for a user and then closing it through other means includes the following steps:

[0099] (1) The user clicks on an element to open a pop-up layer.

[0100] (2) The pop-up component throws a pop-up open event; the parameters of the pop-up open event include the pop-up ID and the corresponding pop-up close method.

[0101] (3) After receiving the pop-up open event, the Web application pushes the parameters of the pop-up open event onto the native return stack.

[0102] (4) Execute the history.pushState method to add a pop-up layer of redundant history records to the history stack.

[0103] (5) The pop-up component displays a pop-up layer and contains a close button.

[0104] (6) When the user clicks the close button of the pop-up, the pop-up component throws a pop-up close event; the parameters of the pop-up close event include the pop-up ID.

[0105] (7) Remove the entry corresponding to the pop-up ID of the pop-up closing event from the native back stack.

[0106] (8) Use history.state to determine whether the current redundant history is a pop-up redundant history; if so, execute history.go(-1).

[0107] (9) Close the pop-up component.

[0108] In this embodiment, if the web application is opened in a client app that provides a native return interception interface in the JS_SDK (JavaScript SDK, a JavaScript toolkit used in web development to integrate specific functions, providing API interfaces that allow developers to call system functions or third-party services in web pages), then the above functionality will be implemented primarily through the native return interception interface provided in the JS_SDK. Specific implementation schemes include:

[0109] When a web application initializes, it first determines whether the current execution environment provides a native return interception interface. Generally, you can learn about the basic information of the current execution environment by looking at navigator.userAgent.

[0110] If the execution environment does not provide an interception interface or it is uncertain whether an interception interface is provided, native return adaptation is achieved through the native return adaptation method of mobile web applications provided in this embodiment;

[0111] If a native return interception interface is provided, then register the callback method for native returns through the native return interception interface.

[0112] In this embodiment, the callback method includes the following steps:

[0113] Check if the native back stack is empty. If it is not empty, pop a native back stack entry, execute the pop-up layer closing method in the entry, and reject this back operation.

[0114] If the native back stack is empty, check if there are any unsaved changes on the current page. If there are unsaved changes, reject the current back operation and display a prompt asking the user if they want to abandon the changes. If the user chooses to abandon the changes, then perform the back operation. If the user chooses to cancel, stay on the current page. If there are no unsaved changes, then allow the current back operation.

[0115] Since the interface directly provides the ability to intercept native return values, when a web application listens for the pop-up open event of a pop-up component, it only needs to push the parameters of the pop-up open event onto the native return stack, without adding any additional history to the browser.

[0116] Meanwhile, when a web application listens for the pop-up component's pop-up close event, it only needs to remove the corresponding native back stack entry from the native back stack; there is no need to perform a browser back operation.

[0117] When the client app supports native return interception interfaces in the JS SDK, the process of a user opening a pop-up and then closing it via native return is as follows: Figure 4 As shown, it specifically includes:

[0118] (1) Web application initialization detection runtime environment.

[0119] (2) Whether the client APP supports the native return interception interface.

[0120] (3) Callback methods of native return interception interfaces registered by Web applications.

[0121] (4) The user clicks on an element to open a pop-up layer.

[0122] (5) The pop-up component throws a pop-up open event; the parameters of the pop-up open event include the pop-up ID and the corresponding pop-up close method.

[0123] (6) After receiving the pop-up open event, the Web application pushes the parameters of the pop-up open event onto the native return stack.

[0124] (7) Pop-up component displays pop-up layer.

[0125] (8) After the user triggers the native return, the client APP executes the registered callback method.

[0126] (9) The Web application determines whether the native back stack is empty; if it is not empty, it pops the top item from the native back stack, executes the pop-up closing method in the top item, rejects the back operation, and stays on the current page.

[0127] (10) The pop-up component closes the corresponding pop-up.

[0128] Because the native return interception interfaces provided by different client app vendors vary significantly in terms of specific method names, parameter structures, calling methods (such as synchronous / asynchronous, callback forms), and behavioral details, an adaptation layer is designed to eliminate the differences between the interfaces provided by different client apps in order to achieve a unified and concise calling logic on the web application side and shield the complexity of the underlying implementation.

[0129] The core implementation method of the adaptation layer is as follows:

[0130] (1) Define the unified strategy interface (JsBridgeStrategy):

[0131] Declare an abstract interface that includes all the native client capabilities that need to be called (such as taking pictures, location, native return interception, etc.).

[0132] The native back interception function is defined as the registerNativeBackInterceptor(handler:Function): void method, which is used to register a callback function to handle the user's native back operation.

[0133] (2) Implement the specific strategy class:

[0134] For each specific client app that needs adaptation (such as client A and client B), create a concrete class that implements the JsBridgeStrategy interface (such as AJsBridgeStrategy and BJsBridgeStrategy). These classes are responsible for encapsulating the specific call details of the interception interface returned by the corresponding client's JS_SDK.

[0135] (3) Implement the adaptation service (JsBridgeService):

[0136] Create a service class, JsBridgeService, that also implements the JsBridgeStrategy interface. This class serves as the core of the adapter layer, and its internal implementation mechanism is as follows:

[0137] (3-1) Environment detection: Determine the current client App environment at runtime.

[0138] (3-2) Strategy selection: Based on the detection results, dynamically select and hold the corresponding specific strategy class instance (such as AJsBridgeStrategy or BJsBridgeStrategy).

[0139] (4) Unified dispatch and assignment:

[0140] When a web application calls methods such as JsBridgeService.registerNativeBackInterceptor(handler), JsBridgeService delegates the actual request to the currently selected specific strategy class instance for execution.

[0141] For example, in client A, the registerNativeBackInterceptor call will be forwarded to the AJsBridgeStrategy method of the same name for execution.

[0142] Example 2

[0143] This embodiment provides a native return adaptation system for mobile web applications, including:

[0144] The storage module is configured to encapsulate the pop-up ID and the corresponding pop-up close method into an entry and store it in the native return stack when a pop-up open event is detected, and to store redundant pop-up history records in the history stack; wherein, if at least two pop-ups corresponding to an interaction are detected at the same time, the time interval between storing any two redundant pop-up history records is greater than a set value.

[0145] The back execution module is configured to, when a back operation is detected, call the top item in the native back stack, execute the corresponding pop-up close method for the pop-up ID in the top item, and remove the current top item from the native back stack;

[0146] The shutdown execution module is configured to remove the entry corresponding to the pop-up ID of the pop-up closing event from the native back stack when a pop-up closing event is detected, and then go back to the previous redundant pop-up history.

[0147] It should be noted that the above modules correspond to the steps described in Embodiment 1, and the examples and application scenarios implemented by the above modules and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should also be noted that the above modules, as part of the system, can be executed in a computer system such as a set of computer-executable instructions.

[0148] In further embodiments, the following is also provided:

[0149] An electronic device includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in Embodiment 1. For brevity, further details are omitted here.

[0150] It should be understood that in this embodiment, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0151] Memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory may also include non-volatile random access memory. For example, memory may also store information about the device type.

[0152] A computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in Embodiment 1.

[0153] The method in Example 1 can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not provided here.

[0154] A computer program product includes a computer program that, when executed by a processor, implements the method described in Embodiment 1.

[0155] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules, which execute in a device on a target real or virtual processor to perform the processes / methods described above. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided among program modules as needed. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside in both local and remote storage media.

[0156] The computer program code used to implement the methods of the present invention may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the computer or other programmable data processing device, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a stand-alone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0157] In the context of this invention, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0158] Those skilled in the art will recognize that the units and algorithm steps described in connection with the various examples of this embodiment can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0159] It should be noted that the collection and processing of relevant data in this invention, when applied in practice, should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0160] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A native return adaptation method of a mobile Web application, characterized in that, Comprise: When listening to the pop-up layer opening event, the pop-up layer ID of the pop-up layer opening event and the corresponding pop-up layer closing method are encapsulated as an entry and stored in the native return stack, and the history. pushState method is executed to store the pop-up layer redundant history record in the history record stack; wherein, if at least two pop-up layers corresponding to an interaction are simultaneously monitored, the history. pushState method is called at least twice in succession, then the time interval of storing the pop-up layer redundant history record by any two times is greater than a set value; and when the time interval of executing the history. pushState method at least twice is greater than a set value, the call of the history. pushState method each time will take effect; When listening to the back operation, the top entry in the native return stack is called, the pop-up layer ID in the top entry is executed to the corresponding pop-up layer closing method, and the current top entry is removed from the native return stack; When listening to the pop-up layer closing event, the entry corresponding to the pop-up layer ID of the pop-up layer closing event is removed from the native return stack, and the last pop-up layer redundant history record is returned; The process of listening to the back operation is: listening to the popstate event, judging whether the popstate event is triggered by the back operation; Specifically: When initializing the page, the history. replaceState method is called to replace the history. state object, and the position field is maintained in the history. state object, which is used to record the position of the current redundant history record; When the history. pushState method is called to store the pop-up layer redundant history record in the history record stack, a state parameter is added, which includes the position field, and the value of the position field is equal to the value of the current position field plus one; When listening to the popstate event, the value of the position field of the current page is obtained and used as a new value, and the new value is subtracted from the old value; when the popstate difference obtained is less than 0, it means that the popstate event is triggered by the back operation; The native return adaptation method of the mobile Web application further comprises: if the native return interception interface is provided in the client App through the JavaScript SDK, then in the native return adaptation process, first judge whether the native return interception interface is provided in the current execution environment, if the native return interception interface is provided, then register the callback method when the native return is executed through the native return interception interface; The native return adaptation method of the mobile Web application further comprises: designing an adaptation layer to eliminate the differences between the native return interception interfaces provided by different client Apps; Specifically: (1) define an abstract interface containing all the client native capabilities that need to be called; among them, the native return interception function is defined as the registerNativeBackInterceptor(handler: Function): void method, which is used to register the callback function for handling user native return operations; (2) For each specific client that needs to be adapted, create a specific class that implements the JsBridgeStrategy interface, which is responsible for encapsulating the specific calling details of the corresponding client JS_SDK native return interception interface; (3) Create a service class JsBridgeService that also implements the JsBridgeStrategy interface, with the following internal implementation mechanism: (3-1) Environment detection: determine the current client environment at runtime; (3-2) Strategy selection: dynamically select and hold the corresponding specific strategy class instance based on the detection result; (4) When the Web application calls the JsBridgeService.registerNativeBackInterceptor(handler) method, JsBridgeService will actually delegate the request to the currently selected specific strategy class instance for execution.

2. The native return adaptation method of a mobile web application of claim 1, wherein, When storing the redundant history records of the popup layer in the history stack, add a state parameter to distinguish the type of redundant history records.

3. The native return adaptation method of a mobile web application of claim 2, wherein, When listening to the popup layer close event, determine whether the current redundant history record is a popup layer type redundant history record according to the state parameter; if so, go back to the previous popup layer redundant history record.

4. The native return adaptation method of a mobile web application of claim 1, wherein, The callback method includes: Determine whether the native return stack is empty, if not, call the top entry in the native return stack, execute the corresponding popup layer close method for the popup layer ID in the top entry, remove the current top entry from the native return stack, and reject this back operation; If the native return stack is empty, determine whether there are unsaved modifications in the current page; if so, reject this back operation and pop up a prompt box to ask the user whether to abandon the modification; if the user chooses to abandon the modification, execute the back operation; if the user chooses to cancel, stay in the current page; if there are no unsaved modifications, allow this back operation.

5. The native return adaptation method of a mobile web application of claim 4, wherein, When the client App supports the native return interception interface, when listening to the popup layer open event, only store the popup layer open event in the native return stack, without adding the popup layer redundant history record; At the same time, when listening to the popup layer close event, only remove the corresponding entry from the native return stack, without performing the browser back operation.

6. The native return adaptation method of a mobile web application of claim 4, wherein, When the client App supports the native return interception interface, the process of closing the popup layer through the native return includes: The Web application initializes the detection of the running environment, the client APP returns whether it supports the native return interception interface, and the Web application registers the callback method of the native return interception interface; When listening to the popup layer open event, encapsulate the popup layer ID and the corresponding popup layer close method of the popup layer open event as an entry and store it in the native return stack; When the native back is triggered, a callback method is executed.

7. A native return adaptation system for mobile web applications, characterized in that, The application discloses a native back adaptation method for a mobile web application, and the method comprises the following steps: The storage module is configured to, when a pop-up layer opening event is monitored, encapsulate the pop-up layer ID of the pop-up layer opening event and the corresponding pop-up layer closing method as an entry and store the entry in the native back stack, and store the pop-up layer redundant history record in the history record stack; wherein, when at least two pop-up layers corresponding to one interaction are simultaneously monitored, the time interval of storing the pop-up layer redundant history records of any two times is greater than a set value; The back execution module is configured to, when a back operation is monitored, call the top entry in the native back stack, execute the corresponding pop-up layer closing method on the pop-up layer ID in the top entry, and remove the current top entry from the native back stack; The closing execution module is configured to, when a pop-up layer closing event is monitored, remove the entry corresponding to the pop-up layer ID of the pop-up layer closing event from the native back stack, and back to the last pop-up layer redundant history record.

8. An electronic device, comprising: The application discloses a native back adaptation method for a mobile web application, and the method comprises the following steps:

Images