Native return adaptation method, system and equipment for mobile Web application

Abstract

The invention discloses a native return adaptation method, system and device for a mobile Web application, and relates to the technical field of computer software development, and the method comprises the steps: when a pop-up layer opening event is monitored, packaging a pop-up layer ID of the pop-up layer opening event and a corresponding pop-up layer closing method into an entry, and storing the entry into a native return stack, storing a redundant historical record of the pop-up layer into a historical record stack; when the backing operation is monitored, calling a stack top entry in the native return stack, executing a corresponding pop-up layer closing method on a pop-up layer ID in the stack top entry, and removing the current stack top entry from the native return stack; and when the pop-up layer closing event is monitored, removing an entry corresponding to the pop-up layer ID of the pop-up layer closing event from the native return stack, and backing to the previous pop-up layer redundant historical record. Under the condition of not violating the security policy of the browser, the problem that the original return of the user cannot be processed by the existing page is solved, and the use experience of the user is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software development, and in particular to a native return adaptation method, system and device for mobile Web applications. Background Art

[0002] Mobile HTML5 pages often involve pop-up layers or pop-up pages. For example, when a user clicks an attachment entry on a page, an attachment preview page pops up, allowing users to zoom in on the image or display the contents of a Word or Excel document. Another example is when a user clicks a date field in a form, a date editor pop-up slides in from the bottom of the screen to edit the date value in the form field. Due to user habits, users often prefer to try to close these pop-ups directly by gesturing back, rather than clicking the close button on the pop-up.

[0003] Through the touch-screen phone's system-level gesture back, users can trigger the mobile browser's native back function. Therefore, for a better user experience, mobile HTML5 pages need to support users in triggering the native back function to close the pop-up layer or pop-up page in the current page. Otherwise, once the user attempts to close the pop-up layer through the gesture back function, the page will directly return to the previous history record, causing all the user's edits in the current form to be lost.

[0004] In another scenario, the user's native return operation also needs to be processed: on an editing page, the normal operation process is for the user to fill in the various fields in the form, and after completing the filling, click the "Save" button at the bottom of the page. After the save is successful, the user returns to the previous page. However, the user may forget to save and return directly to the previous page. In this case, it is best for the page to intercept the user's return operation, stay on the current page, and prompt the user that there are unsaved changes, asking the user whether to abandon the changes on the current page. If the user triggers the return by clicking the back button provided by the page, the page can easily implement the above function. However, if the user triggers the native return, it is difficult for the page to intercept the return operation.

[0005] Currently, mobile HTML5 pages can intercept native responses through the following process: (1) Whenever a new page is opened, a redundant history record is pushed in through the history.pushState method.

[0006] (2) When the user triggers the native return operation, the page will not return directly to the previous page because a redundant history record has been pushed into the page in advance. Instead, the page will stay at the current page and trigger the popstate event; The popstate event is triggered when the browser history entry changes. Specifically, when the user clicks the browser's "Back" and "Forward" buttons, or when using JavaScript (JavaScript is a just-in-time compiled programming language) to call methods such as history.pushState, the popstate event is triggered.

[0007] (3) The page listens for the popstate event. In the callback method of each popstate event, it determines whether it is necessary to return to the previous page. If it is necessary to return to the previous page, the history.back method is executed. If it is not necessary to return to the previous page, the redundant historical records are pushed in again by executing the history.pushState method to intercept the native return. Other business codes can be executed, such as closing the pop-up layer opened in the page or prompting the user that there are unsaved changes.

[0008] However, malicious web pages can exploit this method to repeatedly intercept the user's back action, preventing the user from ever returning to an earlier page. To address this issue, browsers have introduced a series of security policies. For example, after opening a new page, the browser ignores all history operations before the user's first interaction with the page. Newer versions of mainstream browsers have generally implemented similar security policies. However, if an HTML5 page still uses this method to intercept the user's back action, not only will the interception fail, but it will also cause other unexpected issues with the routing of the single-page application itself.

[0009] Due to the above reasons, existing mobile HTML5 pages often do not support closing pop-up layers in the page through native return, nor do they support other processing of native return. Summary of the Invention

[0010] In order to solve the above problems, the present invention proposes a native return adaptation method, system and device for mobile Web applications, which solves the problem that existing pages cannot handle user native returns without violating browser security policies, thereby improving the user experience.

[0011] In order to achieve the above object, the present invention adopts the following technical solutions: In a first aspect, the present invention provides a native return adaptation method for a mobile Web application, comprising: When a popup layer open event is detected, the popup layer ID and the corresponding popup layer close method are encapsulated as an entry and stored in the native return stack, and the popup layer redundant history record is stored in the history stack. If at least two popups corresponding to an interaction are detected simultaneously, the time interval between the storage of any two popup layer redundant history records is greater than the set value. When a back operation is detected, the top item in the native return stack is called, the corresponding popup layer closing method is executed for the popup layer ID in the top item, and the current top item is removed from the native return stack; When a popup layer close event is detected, the entry corresponding to the popup layer ID of the popup layer close event is removed from the native back stack, and the process goes back to the previous popup layer redundant history record.

[0012] As an optional implementation, when storing the pop-up layer redundant historical records in the historical record stack, a state parameter is added to distinguish the types of redundant historical records.

[0013] As an optional implementation, when a pop-up layer closing event is monitored, it is determined based on the state parameter whether the current redundant history record is a pop-up layer type redundant history record; if so, it goes back to the previous pop-up layer redundant history record.

[0014] As an optional implementation, the process of monitoring the back operation is: monitoring the popstate event and determining whether the popstate event is triggered by the back operation; specifically: 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 record. When the history.pushState method is called to store the pop-up redundant history record in the history stack, a state parameter is added. The state parameter includes the position field. The value of the position field is equal to the current value of the position field of the page plus one. When listening for the popstate event, get the value of the position field of the current page and use it as the new value, subtracting the old value from the new value; when the obtained popstate difference is less than 0, it means that the popstate event was triggered by a back operation.

[0015] As an optional implementation, the native return adaptation method of the mobile Web application also includes: if a native return interception interface is provided in the client App through the JavaScript SDK, then during the native return adaptation process, it is first determined whether the current execution environment provides the native return interception interface; if the native return interception interface is provided, the callback method for the native return is registered through the native return interception interface.

[0016] As an optional implementation, the callback method includes: Determine whether the native return stack is empty. If not, call the top item in the native return stack, execute the corresponding popup layer closing method for the popup layer ID in the top item, remove the current top item from the native return stack, and reject the current back operation. If the native back stack is empty, determine whether there are any unsaved changes in the current page; if so, reject the back operation and pop up a prompt box to ask the user whether to abandon the changes; if the user chooses to abandon the changes, perform the back operation; if the user chooses to cancel, stay on the current page; if there are no unsaved changes, allow the back operation.

[0017] As an optional implementation, if the client app supports the native return interception interface, when monitoring the popup layer open event, only the popup layer open event is stored in the native return stack, and no redundant popup layer history is added; At the same time, when a popup layer closing event is detected, only the entry corresponding to the closed popup layer is removed from the native return stack, and the browser back operation is not performed.

[0018] As an optional implementation, when the client app supports the native return interception interface, the process of closing the pop-up layer through the native return includes: The web application initializes and detects the running environment. The client app returns whether the native return interception interface is supported. The web application registers the callback method of the native return interception interface. When a popup layer open event is detected, the popup layer ID and the corresponding popup layer close method of the popup layer open event are encapsulated as an entry and stored in the native return stack; When the native return is triggered, the callback method is executed.

[0019] In a second aspect, the present invention provides a native return adaptation system for mobile Web applications, comprising: The storage module is configured to, when a popup layer open event is monitored, encapsulate the popup layer ID and the corresponding popup layer close method of the popup layer open event into an entry and store it in the native return stack, and store the popup layer redundant history record in the history record stack; wherein, if at least two popup layers corresponding to an interaction are monitored simultaneously, the time interval between the storage of any two popup layer redundant history records is greater than a set value; a back execution module configured to, when a back operation is detected, call the top item in the native back stack, execute a corresponding popup layer closing method for the popup layer ID in the top item, and remove the current top item from the native back stack; The closing execution module is configured to remove the entry corresponding to the popup layer ID of the popup layer closing event from the native return stack when a popup layer closing event is monitored, and go back to the previous popup layer redundant history record.

[0020] In a third aspect, the present invention provides an electronic device comprising a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.

[0021] Compared with the prior art, the present invention has the following beneficial effects: The present invention proposes a native return adaptation method for mobile Web applications, which supports users to close the pop-up layer in the page through native return. When the user opens the pop-up layer, a redundant history record is pushed into the history record stack, and the history record corresponds to the opened pop-up layer, and the pop-up layer closing method is pushed into the native return stack at the same time. The browser back operation is monitored to check whether the native return stack is empty. If it is not empty, an entry is popped up, and the pop-up layer closing method in the entry is executed to close the corresponding pop-up layer. If the user closes the pop-up layer by clicking the close button on the pop-up layer or other non-native return methods, the closing method corresponding to the pop-up layer needs to be removed from the native return stack, and the influence of the redundant history record of the pop-up layer on the routing is eliminated by executing the history.back method. Without violating the browser security policy, the problem that the existing mobile HTML5 page cannot handle the user's native return is solved, thereby improving the user experience.

[0022] Advantages of additional aspects of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0024] Figure 1 Flowchart of the native return adaptation method for mobile Web applications provided in Example 1 of the present invention; Figure 2 Flowchart of opening a pop-up layer and closing the pop-up layer through native return provided in Example 1 of the present invention; Figure 3 A flowchart of opening a pop-up layer and closing the pop-up layer by other means provided in Example 1 of the present invention; Figure 4 A flowchart of closing a pop-up layer through native return when the client App provided in Example 1 of the present invention supports intercepting a native return interface. DETAILED DESCRIPTION

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

[0026] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present invention belongs.

[0027] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that the terms "include" and "comprise" and any variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0028] In the absence of conflict, the embodiments of the present invention and the features thereof may be combined with each other.

[0029] When developing mobile apps, enterprises have three popular development technologies to choose from: native apps, Web apps, and hybrid apps. If you choose to develop a native app, you can use existing native return interception methods. However, this article focuses on Web apps and hybrid apps.

[0030] 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 also leveraging native APIs to improve application performance and user experience.

[0031] Specifically, Hybrid technology is implemented by embedding a WebView component in native applications. WebView is a special browser window that can display web content in native applications and can interact with native code. In this way, HTML5 pages can call native APIs through JavaScript to access the device's camera, photo album, GPS positioning and other hardware functions. For example, when a user chooses to upload a picture on an HTML5 page, the native image selector can be called instead of being limited to the standard file input on the web page. This allows the attachment upload component on the HTML5 page to also perform native mobile application capabilities such as taking photos and shooting short videos.

[0032] 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 API for intercepting native return calls, this client-side native return interception interface can be used to support requirements such as closing pop-ups on page returns or notifying users of unsaved changes when returning. However, not all client apps provide this native return interception interface in JsBridge. Some client apps do provide similar native return interception interfaces in their JS_SDK (JS SDK is a JavaScript software development kit, a front-end development toolkit that provides JavaScript APIs to help developers quickly integrate specific features such as social sharing, payment, and device information retrieval into web or mobile pages), but these interfaces only work on Android, not iOS, or may be subject to other restrictions. If a web application only runs on an enterprise-developed client app, it can be required that the client app support this native return interception interface. Some low-code development platforms will 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 applications generated by the platform into the customer's own app. At this time, we cannot hope that all client apps support the return interception interface in JS_SDK. There must be a universal routing mechanism based on the capabilities of the Web itself to adapt to the main scenarios that require adaptation to native returns.

[0033] Therefore, the present invention provides a native return adaptation method for mobile Web applications, which can be used to improve the user experience in pure WebApp scenarios and Hybrid App scenarios where the client JS_SDK does not support the native return interception interface.

[0034] Example 1 Assume that the mobile web application is a single-page application built with 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 or applications built with other front-end frameworks. It is also applicable to web applications developed entirely using HTML5, CSS (Cascading Style Sheets, a computer language used to represent document styles such as 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.

[0035] like Figure 1 As shown, this embodiment proposes a native return adaptation method for a mobile web application to support users closing a pop-up layer within a page through a native return, specifically including: S101: When a popup layer open event is monitored, the popup layer ID and the corresponding popup layer close method of the popup layer open event are encapsulated as an entry and stored in the native return stack, and a popup layer redundant history record is stored in the history stack; wherein, if at least two popup layers corresponding to an interaction are monitored simultaneously, the time interval between the storage of any two popup layer redundant history records is greater than a set value; S102: When a back operation is detected, the top entry in the native return stack is called, a corresponding pop-up layer closing method is executed for the pop-up layer ID in the top entry, and the current top entry is removed from the native return stack; S103: When a popup layer closing event is monitored, the entry corresponding to the popup layer ID of the popup layer closing event is removed from the native return stack, and the process goes back to the previous popup layer redundant history record.

[0036] All popup components that can open popups and need to support closing them via native return methods must uniformly support two events. First, a popup open event is thrown when the popup component opens a popup. The popup open event's parameters include the unique popup ID of the opened popup and the popup close method used to close the opened popup. Second, a popup close event is thrown when the user closes the popup via a non-native return method. The popup close event's parameters include the unique popup ID of the opened popup.

[0037] Take a previewable image component as an example. By default, this component displays a thumbnail. When a user clicks the thumbnail, a popup component opens a full-screen popup for viewing the larger image. There's a close button in the upper-right corner of the popup. When the user clicks the close button, the popup component closes the popup. Therefore, this image component needs to raise a popup open event when the user clicks the thumbnail, and a popup close event when the user clicks the close button in the upper-right corner of the full-screen popup.

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

[0039] It should be noted that due to the new browser security policy, history operations before the user's first interaction with the web page will be ignored. Therefore, the redundant history record addition operation must be performed in the event listening callback function of the interaction event when the user opens the pop-up layer.

[0040] At the same time, maintaining a unique native return stack within a web page in a web application can be implemented using an object array on a global object. The native return stack is used to store information about all pop-up layers currently open in the web page. Each entry in the native return stack is an object that contains the unique ID of the corresponding pop-up layer and a method for closing the pop-up layer.

[0041] Then, the web application listens for popup layer opening events and popup layer closing events of all components in the web page; when a popup layer opening event is listened for, the following operations are performed: (1) Push the parameters of the popup layer open event (i.e. the popup layer ID and the corresponding popup layer close method) into the native return stack.

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

[0043] It's important to note that if your web application uses a routing framework, you should call the methods provided by the routing framework to add redundant history records to the popup layer 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 routing instance to add redundant history records to the popup layer. The push method will eventually call the history.pushState method, but during this process, some internal states of VueRouter are also maintained.

[0044] For better scalability, when adding popup redundant history, additional state information is set for the newly added popup redundant history by passing in a state parameter (state parameter). The state parameter should at least contain a field to distinguish the redundant history type. This is because the history stack not only includes popup redundant history to support closing the popup via native return, but also includes redundant history to support other functions.

[0045] Therefore, when the popup layer close event is monitored, the following operations are performed: (1) Remove the entry corresponding to the popup ID of the popup close event from the native back stack.

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

[0047] 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, if you add a VueRouter route guard, calling the history.back method will trigger the route guard, but you don't want the route guard to be triggered by closing the popup. In this case, replacing the call to history.back with calling vueRouterInstance.options.history.go(-1, false) will both go back one history record and prevent the route guard from being triggered.

[0048] In this embodiment, when implementing the monitoring of popup layer open and popup layer close events, it is also necessary to consider a scenario where a user interacts with a web page and simultaneously opens two or more popup layers. In this scenario, after a user interacts with the web page, two or more popup layers are opened simultaneously, and each popup layer needs to support closing via native return.

[0049] Then, this scenario will cause the history.pushState method to be called twice or more consecutively. In some lower-version browsers or some browsers with special implementations, when the history.pushState method is called twice consecutively, the browser will ignore the first call and only the second call will actually take effect.

[0050] To maintain compatibility with these browsers, the interval between any two history saves is greater than the specified value. When the interval between two history.pushState calls is greater than the specified value, both calls will take effect. Experimentation has found 200ms to be a reliable value, allowing for a minimum execution interval queue to be established, ensuring that all queued methods are executed at least 200ms apart. For methods that manipulate browser history, consider placing them in a queue to ensure they actually take effect.

[0051] Web applications need to listen for the page's native return event and execute some business logic code after the user triggers the native return, to implement functions such as closing pop-up layers in the page. However, HTML5 does not directly provide a native return event, so it is necessary to listen for the popstate event to achieve this.

[0052] The popstate event is triggered when the browser moves forward or backward. Since operations such as closing the popup layer only need to be performed when the browser returns natively, that is, when the browser moves back, it is necessary to distinguish whether the popstate event is triggered because the browser moves forward or because the browser moves back. If the popstate event is triggered because the browser moves forward, no processing is performed.

[0053] Since the popstate event does not indicate how the event was triggered in its parameters, the following method is used to determine whether the popstate event was triggered by the browser backing out; specifically: (1) When the page is initialized, the history.replaceState method is called to replace the history.state object, and the position field is maintained in the history.state object to record the position of the current redundant history record.

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

[0055] (3) Whenever a popstate event is triggered, in the listening method of the popstate event, first obtain the value of the position field of the current page 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 was triggered by the browser moving forward; if the result is less than 0, it means that the popstate event was triggered by the browser moving back.

[0056] 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 to the forward or backward movement of the history record.

[0057] The web application listens for the popstate event and uses the above method to determine whether the popstate event is triggered by a native return operation triggered by the user. If so, it performs the following steps: (1) Determine whether the native return stack is empty; if it is not empty, pop the top entry from the native return stack.

[0058] (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.

[0059] In this way, it is possible to support users in closing the pop-up layer in the web page through native return.

[0060] Figure 2 The process of opening a popup for the user and then closing the popup through native return includes the following steps: (1) The user clicks an element to open a popup.

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

[0062] (3) After the web application receives the pop-up layer opening event, it pushes the parameters of the pop-up layer opening event into the native return stack.

[0063] (4) Execute the history.pushState method to add pop-up redundant history records to the history stack.

[0064] (5) The pop-up layer component displays the pop-up layer.

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

[0066] (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 determines whether the native return stack is empty; if it is not empty, it pops the top item from the native return stack and executes the popup layer closing method in the top item to close the corresponding popup layer.

[0067] Figure 3 The process of opening a pop-up layer for the user and then closing the pop-up layer by other means includes the following steps: (1) The user clicks an element to open a popup.

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

[0069] (3) After the web application receives the pop-up layer opening event, it pushes the parameters of the pop-up layer opening event into the native return stack.

[0070] (4) Execute the history.pushState method to add pop-up redundant history records to the history stack.

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

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

[0073] (7) Remove the entry corresponding to the popup ID of the popup close event from the native back stack.

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

[0075] (9) The pop-up layer component closes the pop-up layer.

[0076] In this embodiment, if a web application is opened in a client app that provides a native return interception interface in JS_SDK (JavaScript SDK, a JavaScript toolkit used to integrate specific functions in web page development, providing API interfaces that enable developers to call system functions or third-party services in web pages), the native return interception interface provided by JS_SDK will be used to implement the above functions. Specific implementation solutions include: When a web application is initialized, it first determines whether the current execution environment provides a native return interception interface. Generally, the basic information of the current execution environment can be obtained based on navigator.userAgent. If the execution environment does not provide an interception interface or is uncertain whether an interception interface is provided, native return adaptation is implemented using the native return adaptation method for mobile Web applications provided in this embodiment; If a native return interception interface is provided, the callback method for native return is registered through the native return interception interface.

[0077] In this embodiment, the callback method includes the following steps: Check whether the native return stack is empty. If it is not empty, pop up a native return stack entry, execute the pop-up layer closing method in the entry, and reject the current back operation; If the native back stack is empty, check whether there are any unsaved changes in the current page; if there are any unsaved changes, reject the back operation and pop up a prompt box to ask the user whether to abandon the changes; if the user chooses to abandon the changes, perform the back operation again; if the user chooses to cancel, stay on the current page; if there are no unsaved changes, allow the back operation.

[0078] Because the interface directly provides the ability to intercept native returns, when a web application monitors the popup layer open event of the popup layer component, it only needs to push the parameters of the popup layer open event into the native return stack, without adding additional history records to the browser; At the same time, when the web application monitors the pop-up layer closing event of the pop-up layer component, it only needs to remove the native back stack entry corresponding to the closed pop-up layer from the native back stack, and there is no need to perform the browser back operation.

[0079] When the client App supports the native return interception interface in JS_SDK, the user opens a pop-up layer and then closes the pop-up layer through the native return process as follows: Figure 4 As shown, specifically including: (1) Web application initialization detection running environment.

[0080] (2) The client APP returns whether it supports the native return interception interface.

[0081] (3) The web application registers a callback method that returns the native interception interface.

[0082] (4) The user clicks on the element to open the popup layer.

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

[0084] (6) After the web application receives the pop-up layer opening event, it pushes the parameters of the pop-up layer opening event into the native return stack.

[0085] (7) The pop-up layer component displays the pop-up layer.

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

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

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

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

[0090] The core implementation method of the adaptation layer is as follows: (1) Define a unified strategy interface (JsBridgeStrategy): Declare an abstract interface that includes all client native capabilities that need to be called (such as taking pictures, positioning, native return interception, etc.).

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

[0092] (2) Implement specific strategy classes: For each specific client app that needs adaptation (such as client A and client B), create a specific class that implements the JsBridgeStrategy interface (such as AJsBridgeStrategy and BJsBridgeStrategy). These classes are responsible for encapsulating the specific call details of the corresponding client JS_SDK native return interception interface.

[0093] (3) Implementing the adaptation service (JsBridgeService): Create a service class JsBridgeService that also implements the JsBridgeStrategy interface. This class serves as the core of the adaptation layer, and its internal implementation mechanism is as follows: (3-1) Environment detection: Determine the current client App environment during runtime.

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

[0095] (4) Unified calling and delegation: 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.

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

[0097] Example 2 This embodiment provides a native return adaptation system for mobile web applications, including: The storage module is configured to, when a popup layer open event is monitored, encapsulate the popup layer ID and the corresponding popup layer close method of the popup layer open event into an entry and store it in the native return stack, and store the popup layer redundant history record in the history record stack; wherein, if at least two popup layers corresponding to an interaction are monitored simultaneously, the time interval between the storage of any two popup layer redundant history records is greater than a set value; a back execution module configured to, when a back operation is detected, call the top item in the native back stack, execute a corresponding popup layer closing method for the popup layer ID in the top item, and remove the current top item from the native back stack; The closing execution module is configured to remove the entry corresponding to the popup layer ID of the popup layer closing event from the native return stack when a popup layer closing event is monitored, and go back to the previous popup layer redundant history record.

[0098] It should be noted that the above modules correspond to the steps described in Example 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 contents disclosed in the above Example 1. It should 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.

[0099] In further embodiments, there is also provided: An electronic device includes a memory and a processor, and computer instructions stored in the memory and executed by the processor, wherein when the computer instructions are executed by the processor, the method described in Example 1 is performed. For the sake of brevity, no further details are given here.

[0100] It should be understood that in this embodiment, the processor may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), off-the-shelf field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

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

[0102] A computer-readable storage medium is used to store computer instructions, and when the computer instructions are executed by a processor, the method described in Example 1 is performed.

[0103] The method in Example 1 can be directly implemented as a hardware processor, or can be implemented using a combination of hardware and software modules in the processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, it will not be described in detail here.

[0104] A computer program product includes a computer program, which implements the method described in embodiment 1 when executed by a processor.

[0105] 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 contained in program modules, which are executed in a device on a real or virtual processor of a target to perform the process / method described above. Generally, 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 between program modules as needed. The machine-executable instructions for the program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in local and remote storage media.

[0106] The computer program code for implementing the method of the present invention can be written in one or more programming languages. These computer program codes can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the computer or other programmable data processing device, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on a computer, partially on a computer, as an independent software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0107] In the context of the present invention, computer program code or related data can be carried by any appropriate 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 include electrical, optical, radio, acoustic, or other forms of propagated signals, such as carrier waves, infrared signals, and the like.

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

[0109] 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 authorization of laws and regulations and the personal information subject.

[0110] Although the above describes the specific embodiments of the present invention in conjunction with the accompanying drawings, it 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 on the basis of the technical solution of the present invention without any creative work are still within the scope of protection of the present invention.

Claims

1. A native return adaptation method for a mobile web application, characterized in that: include: When a popup layer open event is detected, the popup layer ID and the corresponding popup layer close method are encapsulated as an entry and stored in the native return stack, and the popup layer redundant history record is stored in the history stack. If at least two popups corresponding to an interaction are detected simultaneously, the time interval between the storage of any two popup layer redundant history records is greater than the set value. When a back operation is detected, the top item in the native return stack is called, the corresponding popup layer closing method is executed for the popup layer ID in the top item, and the current top item is removed from the native return stack; When a popup layer close event is detected, the entry corresponding to the popup layer ID of the popup layer close event is removed from the native back stack, and the process goes back to the previous popup layer redundant history record.

2. A native return adaptation method for a mobile Web application according to claim 1, characterized in that: When storing redundant history records in the pop-up layer in the history stack, a status parameter is added to distinguish the types of redundant history records.

3. A native return adaptation method for a mobile Web application according to claim 2, characterized in that: When a popup layer closing event is detected, the state parameter is used to determine whether the current redundant history record is a popup layer type redundant history record; if so, the user goes back to the previous popup layer redundant history record.

4. A native return adaptation method for a mobile Web application according to claim 1, characterized in that: The process of monitoring the back operation is: monitoring the popstate event and determining whether the popstate event is triggered by the back operation; specifically: 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 record. When the history.pushState method is called to store the pop-up redundant history record in the history stack, a state parameter is added. The state parameter includes the position field. The value of the position field is equal to the current value of the position field of the page plus one. When listening for the popstate event, get the value of the position field of the current page and use it as the new value, subtracting the old value from the new value; when the obtained popstate difference is less than 0, it means that the popstate event was triggered by a back operation.

5. The native return adaptation method of a mobile Web application according to claim 1, characterized in that: The native return adaptation method for a mobile web application further includes: if a native return interception interface is provided in the client App through a JavaScript SDK, first determining whether the current execution environment provides the native return interception interface during the native return adaptation process; if the native return interception interface is provided, registering a callback method for native return through the native return interception interface.

6. A native return adaptation method for a mobile Web application according to claim 5, characterized in that: The callback methods include: Determine whether the native return stack is empty. If not, call the top item in the native return stack, execute the corresponding popup layer closing method for the popup layer ID in the top item, remove the current top item from the native return stack, and reject the current back operation. If the native back stack is empty, determine whether there are any unsaved changes in the current page; if so, reject the back operation and pop up a prompt box to ask the user whether to abandon the changes; if the user chooses to abandon the changes, perform the back operation; if the user chooses to cancel, stay on the current page; if there are no unsaved changes, allow the back operation.

7. A native return adaptation method for a mobile Web application according to claim 6, characterized in that: When the client app supports the native return interception interface, when it monitors the popup layer open event, it only stores the popup layer open event in the native return stack, and does not add redundant popup layer history records; At the same time, when a popup layer closing event is detected, only the entry corresponding to the closed popup layer is removed from the native return stack, and the browser back operation is not performed.

8. A native return adaptation method for a mobile Web application according to claim 6, characterized in that: When the client app supports the native return interception interface, the process of closing the pop-up layer through the native return includes: The web application initializes and detects the running environment. The client app returns whether the native return interception interface is supported. The web application registers the callback method of the native return interception interface. When a popup layer open event is detected, the popup layer ID and the corresponding popup layer close method of the popup layer open event are encapsulated as an entry and stored in the native return stack; When the native return is triggered, the callback method is executed.

9. A native return adaptation system for mobile web applications, characterized in that: include: The storage module is configured to, when a popup layer open event is monitored, encapsulate the popup layer ID and the corresponding popup layer close method of the popup layer open event into an entry and store it in the native return stack, and store the popup layer redundant history record in the history record stack; wherein, if at least two popup layers corresponding to an interaction are monitored simultaneously, the time interval between the storage of any two popup layer redundant history records is greater than a set value; a back execution module configured to, when a back operation is detected, call the top item in the native back stack, execute a corresponding popup layer closing method for the popup layer ID in the top item, and remove the current top item from the native back stack; The closing execution module is configured to remove the entry corresponding to the popup layer ID of the popup layer closing event from the native return stack when a popup layer closing event is monitored, and go back to the previous popup layer redundant history record.

10. An electronic device, characterized in that: The method comprises a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method according to any one of claims 1 to 8 is completed.

Images