An iframe cross-window asynchronous callback bridging method, system and medium

Abstract

The application discloses an iframe cross-window asynchronous callback bridging method and system and a medium, and comprises the following steps: a sub-application declares a callback type in an action call parameter in a serializable field; a host parses and verifies, generates a callback descriptor containing a callback identifier, a call identifier, a source window identifier and a life cycle strategy, and registers the callback descriptor to a registry; a local function is generated for each descriptor, and a callback identifier and a source reference are implanted, and after a parameter is injected through a callbacks object, a callbackDispatcher distribution function or a cbk compatible entrance, a target method is called; when the local function is triggered and the state is pending, a return message is assembled and sent to the sub-application window based on the implanted source reference, and the registration state is updated according to the life cycle strategy. The application can realize reliable delivery of asynchronous callback under the condition that a function object cannot be transmitted across windows, and is suitable for iframe scenes.

Description

Technical Field

[0001] This invention relates to the field of web application communication technology, and in particular to an iframe cross-window asynchronous callback bridging method, system, and medium. Background Technology

[0002] In web platforms, the main page and iframe sub-applications often exchange data via the postMessage cross-window communication mechanism to enable host capability calls and asynchronous result feedback. As an embedded page, the iframe sub-application has a JavaScript execution context isolated from the host page, and function objects cannot be directly serialized and passed across windows. However, in complex scenarios such as games, events, payments, and pop-up interactions, when a sub-application initiates a host capability call, it typically needs to register multiple asynchronous callbacks, such as success callbacks, failure callbacks, close callbacks, and progress callbacks. The host side needs to accurately send the result back to the sub-application after the corresponding asynchronous node is triggered, and the sub-application then resumes the execution of the corresponding callback logic.

[0003] Currently, the mainstream approach to handling asynchronous callbacks across iframe windows involves implementing method calls between master and slave applications through state synchronization or SDK interface encapsulation. State synchronization solutions use broadcasting and listening mechanisms to share state changes between master and slave pages, but they don't address the issues of declaring, resuming, and posting back asynchronous callbacks. SDK interface encapsulation solutions use pre-defined, fixed callback fields (such as onSuccess and onFail) to receive results from the host application, but this approach has significant drawbacks, as follows:

[0004] (1) No serializable callback type declaration specification is provided: Sub-applications cannot declare in a structured way which callbacks need to be restored by the host, as well as the lifecycle strategy of each callback (such as one-time triggering or multiple triggering). The host side cannot know which fields in the parameters should be restored as callback functions, and can only rely on preset fixed fields, which lacks flexibility and extensibility.

[0005] (2) Unresolved issue of concurrent isolation of multiple callbacks: When the same sub-application initiates multiple concurrent action calls, or registers multiple callback types in the same action, the preset fixed callback field cannot distinguish between different call instances and different callback types, which is prone to crosstalk, resulting in incorrect distribution or repeated execution of callback results;

[0006] (3) No lifecycle management for callbacks: The existing solution lacks a callback status tracking and timeout cleanup mechanism. When the sub-application window is closed, the source is invalid, or the callback timeout is not triggered, the registered callback becomes a hanging callback, continues to occupy resources, and may still try to send back after the window is invalid, causing invalid communication and memory leaks.

[0007] (4) Failure to verify the validity of the source window of the callback message: When the callback is triggered and the message is sent back, the validity of the original sub-application window and the source identifier are not verified. When the window is closed or the source does not match, the message may be lost or mistakenly sent to the wrong window.

[0008] In summary, asynchronous interactions between iframe sub-applications and the host page have rigid requirements for the declaration, restoration, isolation, postback, and cleanup of callbacks. However, existing state synchronization and SDK interface encapsulation solutions cannot cope with the objective constraint that function objects cannot be passed across windows, as well as issues such as concurrent crosstalk of multiple callbacks, callback hanging, and source failure. This leads to a decrease in the reliability of the return of call results in complex asynchronous interaction scenarios, making it difficult to meet the long-term stable interaction requirements of scenarios such as games, events, and payments. There is an urgent need for a better asynchronous callback bridging solution to solve these core pain points. Summary of the Invention

[0009] The purpose of this invention is to provide an iframe cross-window asynchronous callback bridging method, system, and medium to address the aforementioned problems in the prior art, thereby resolving all or one of the problems existing in the prior art.

[0010] To solve the above-mentioned technical problems, the specific technical solution of the present invention is as follows:

[0011] On one hand, the present invention provides an iframe cross-window asynchronous callback bridging method, including the following steps:

[0012] In response to an action call initiated by an iframe child application to the host:

[0013] Receive the action invocation message sent by the sub-application, parse it to obtain the action name and parameter array, wherein the parameter array contains an embedded callback type declaration field, and the callback type declaration field instructs the host to restore the value of the corresponding parameter position to a local executable function;

[0014] Determine the target host action method based on the action name;

[0015] Obtain the source window identifier and source window reference of the action call message, generate a call identifier for the current action call, and save the source window reference;

[0016] The parameter array is traversed, the callback type declaration field is read and parsed to obtain at least one callback type, the index position of the callback type declaration field in the parameter array is recorded, and the validity of each callback type is verified; a callback identifier and a callback descriptor are generated for each valid callback type, and the callback descriptor is registered in the callback registry; wherein, the callback descriptor at least includes the callback identifier, the call identifier, the source window identifier, and the lifecycle strategy corresponding to the callback type;

[0017] A native executable function is generated for each callback descriptor registered in the callback registry. The callback identifier and the saved source window reference are injected into the native executable function. When the same index position corresponds to one or more callback types, the native executable function corresponding to the one or more callback types is written into the callbacks object, and a callbackDispatcher dispatch function and a cbk-compatible entry point are generated. The callbacks object, the callbackDispatcher dispatch function, and the cbk-compatible entry point are injected into the parameter object corresponding to the index position recorded in the parameter array to replace the callback type declaration field, and the target host action method is called with the reconstructed parameter array.

[0018] In response to the triggering of the local executable function during the execution of the target host action method, the status of the corresponding entry in the callback registry is queried. If the status is not pending, it returns directly; if the status is pending, the callback type of the corresponding entry in the callback registry is read, and combined with the implanted callback identifier and the actual parameters passed in at the time of triggering, a callback return message containing message type, action name, callback type, callback identifier and trigger actual parameters is assembled; and based on the implanted source window reference, the callback return message is sent to the source window of the sub-application through cross-window communication, and the status of the corresponding entry in the callback registry is updated according to the lifecycle strategy.

[0019] As an improved approach, the method for determining the target host action based on the action name includes:

[0020] Search the preset action mapping table for the host method that matches the action name;

[0021] If a hit occurs, the hit host method will be used as the target host action method.

[0022] If a match is missed, the current processing is terminated and an ACTION_ERROR error message is returned to the sub-application.

[0023] As an improved approach, the step of traversing the parameter array, reading the callback type declaration field, and parsing to obtain at least one callback type further includes:

[0024] Iterate through the parameter array. For each parameter of object type, read its callback type declaration field and record the index position of the parameter in the parameter array, which is called the parameter index.

[0025] If the callback type declaration field is a string, a string array, a JSON array string, or a comma-separated string, then each callback type name is standardized into a callback type, and a default lifecycle strategy is assigned to each callback type, wherein the default lifecycle strategy is a one-time callback.

[0026] If the callback type declaration field is a descriptor object or an array of descriptors, then read the callback type and its lifecycle strategy carried by each descriptor.

[0027] As an improved solution, the step of generating a callback identifier and a callback descriptor for each validated callback type, and registering the callback descriptor to the callback registry, further includes:

[0028] Generate a globally unique callback identifier for each callback type;

[0029] The callback type, callback identifier, call identifier, action name, parameter index, lifecycle strategy, and source window identifier are combined into the callback descriptor;

[0030] The callback descriptor is registered in the callback registry, and the registration status is marked as pending.

[0031] As an improved solution, the `callbacks` object, the `callbackDispatcher` dispatch function, and the cbk-compatible entry point are injected into the parameter object corresponding to the index position recorded in the parameter array, further including:

[0032] When the parameter position corresponding to the parameter index corresponds to only one callback type, the generated native executable function is written into the callbacks object, and the callbackDispatcher dispatch function and cbk-compatible entry point are generated and injected with the corresponding parameter object.

[0033] When the parameter position corresponding to the parameter index corresponds to multiple callback types, the generated multiple native executable functions are written into the callbacks object, and dispatched to the corresponding native executable functions through the callbackDispatcher dispatch function or the cbk compatible entry point according to the callback type parameter or the default strategy.

[0034] As an improved approach, updating the status of the corresponding entry in the callback registry according to the lifecycle strategy further includes:

[0035] For descriptors marked as one-time callbacks in the lifecycle strategy, after the local executable function is triggered for the first time, the status of the corresponding entry in the callback registry is updated to consumed and retained until timeout cleanup or unified cleanup is performed and then removed, so that the local executable function corresponding to the callback cannot be repeatedly sent back due to the status query when it is called again in the future.

[0036] As an improved approach, the method of sending the callback postback message to the source window of the sub-application via cross-window communication based on the implanted source window reference further includes:

[0037] Before sending the callback message, the validity of the original message source window is verified by referencing the implanted source window.

[0038] If the source window is available, the current source identifier is retrieved again through the source window reference and matched with the source window identifier during registration; if a match is found, the callback message is sent through cross-window communication with the source window reference as the target.

[0039] If the source window is unavailable, cannot be used as a cross-window message return target, or the current source identifier does not match the source window identifier, the return will be rejected, and the corresponding callback registration item will be set to the final state and removed by the timeout or unified cleanup mechanism.

[0040] As an improved approach, updating the status of the corresponding entry in the callback registry according to the lifecycle strategy further includes:

[0041] For descriptors marked as having multiple callbacks in the lifecycle strategy, the entry is retained and kept in a pending state after each trigger until the preset timeout period is reached or an explicit cancellation instruction is received. Then, the entry status is updated to expired or cancelled and removed by the timeout or unified cleanup mechanism.

[0042] On the other hand, the present invention also provides an iframe cross-window asynchronous callback bridging system, comprising:

[0043] The callback type declaration module is used to enable iframe child applications to declare callback types in action call messages initiated to the host with a serializable parameter structure;

[0044] The callback declaration parsing module is used to traverse the parameter array after the host receives the action call message, read the callback type declaration field and standardize it into a callback type list, and perform a validity check on each callback type;

[0045] The callback descriptor generation and registration module is used to generate a callback descriptor containing a callback identifier, a call identifier, a source window identifier, and a lifecycle strategy for each valid callback type, and register it in the callback registry.

[0046] The local callback restoration and injection module is used to generate a local executable function for each registered callback descriptor, inject it into the corresponding position of the parameter array to replace the callback type declaration field, and call the target host action method with the reconstructed parameter array;

[0047] The callback triggering and message return module is used to assemble callback return messages and send them to the source window of the sub-application via cross-window communication when the local executable function is triggered.

[0048] The lifecycle and concurrency isolation management module is used to update the status of the corresponding entry in the callback registry according to the lifecycle strategy carried by the callback descriptor, and to verify the validity of the source window.

[0049] On the other hand, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the iframe cross-window asynchronous callback bridging method.

[0050] The beneficial effects of the technical solution of this invention are:

[0051] 1. The iframe cross-window asynchronous callback bridging method described in this invention can accurately declare, restore, trigger, return, and clean up asynchronous callbacks of sub-applications under the objective constraint that function objects cannot be serialized and passed across windows. Through callback descriptors and callback registry mechanisms, it effectively resists abnormal interference such as multi-window concurrent crosstalk, callback hanging, source failure, and repeated execution, ensuring that the asynchronous call result is reliably returned to the correct sub-application window. It meets the working requirements of long-term stable interaction in complex iframe scenarios such as game activities, online payments, and pop-up interactions, and makes up for the deficiencies of existing state synchronization and SDK interface encapsulation solutions in asynchronous callback management, and has high application value.

[0052] 2. The iframe cross-window asynchronous callback bridging system described in this invention can achieve the iframe cross-window asynchronous callback bridging method described in this invention through the cooperation of a callback type declaration module, a callback declaration parsing module, a callback descriptor generation and registration module, a local callback recovery and injection module, a callback triggering and message return module, and a lifecycle and concurrency isolation management module.

[0053] 3. The computer-readable storage medium of the present invention can enable the system module to cooperate in order to realize the iframe cross-window asynchronous callback bridging method of the present invention. The computer-readable storage medium of the present invention effectively improves the operability of the iframe cross-window asynchronous callback bridging method. Attached Figure Description

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

[0055] Figure 1 This is a diagram of the callback bridging function architecture in an embodiment of the present invention;

[0056] Figure 2 This is a flowchart of the callback lifecycle management process according to an embodiment of the present invention;

[0057] Figure 3 This is a timing diagram of multiple callback concurrency isolation in an embodiment of the present invention. Detailed Implementation

[0058] The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, so that the advantages and features of the present invention can be more easily understood by those skilled in the art, thereby providing a clearer and more explicit definition of the scope of protection of the present invention.

[0059] In the description of this invention, it should be noted that the embodiments described in this invention are only some embodiments of this invention, not all embodiments; based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0060] The terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, apparatus, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are expressly listed, but may include other steps or units that are not expressly listed or that are inherent to such process, method, product, or device.

[0061] In the description of this invention, it should be noted that:

[0062] An iframe is a container for embedding child pages within a webpage. It allows one independent HTML page to be embedded within another HTML page, with both having their own isolated JavaScript execution contexts.

[0063] SDK stands for Software Development Kit. In this solution, it refers to the software development kit that allows the host page to expose capabilities and call interfaces to iframe sub-applications.

[0064] In this embodiment, CALLBACK is an exemplary name for the message type identifier used by the host page when sending back the asynchronous call result to the iframe sub-application, which is used to distinguish it from other types of cross-window messages. It can be understood that this identifier is only an example, and in the actual implementation it can be any pre-agreed string or enumeration value, such as "__callback__", "cb", etc. This invention does not limit it.

[0065] postMessage is a cross-window communication mechanism provided by the web platform, which allows serializable data to be securely transmitted between different windows or iframes.

[0066] The host is the external main page that carries the iframe sub-application. It is responsible for receiving the capability call requests of the sub-application and delegating the execution of functions on the host side.

[0067] Callback type declaration is a declaration field declared by the sub-application in the action call parameters as a serializable field or structure, which instructs the host to restore the corresponding parameter position to an executable callback function;

[0068] A callback descriptor is a metadata object generated by the host for each callback to be restored. It contains fields such as callback identifier, call identifier, parameter index, lifecycle strategy and source window identifier, which are used to uniquely describe a callback instance.

[0069] The callback registry is a data structure on the host side used to register and manage all callback descriptors, supporting search, status update, and cleanup operations by key combinations;

[0070] The source window identifier (sourceKey) is a unique source identifier that the host assigns or extracts for each sub-application window. It is used to verify the legitimacy of the message source during callback postback.

[0071] The invokeId is a unique identifier generated by the host for each action call, used to isolate multiple concurrent action calls initiated by the same sub-application window and their associated callbacks;

[0072] The callback type is a type identifier string specified by the sub-application in the callback type declaration. It is used to identify the semantic category of this callback (such as success, failure, close, etc.) in the return message so that the receiving end of the sub-application can distinguish different callbacks in the same action call.

[0073] The parameter index (paramIndex) is the index position of the callback type declaration field in the parameter array of the action invocation message. It is recorded in the callback descriptor and is used to inject the generated native executable function into the correct position in the parameter array when the callback is resumed.

[0074] A lifecycle policy is metadata that describes the behavior rules of a callback from registration to cleanup, including one-time consumption, multiple triggers, timeout time, and cancellation method.

[0075] The dispatch function is an aggregate function generated on the host side when multiple callback types are declared in the same parameter position. It is used to encapsulate and dispatch multiple native executable functions. Internally, this function maintains the mapping relationship between callback types and corresponding native executable functions. When called, it dispatches the call to the correct callback processing logic according to the callback type indication passed by the caller.

[0076] The action mapping table is a pre-maintained data structure on the host side, used to store the mapping relationship between action names and corresponding host methods. This allows the host to find the target host action method to be called based on the action name after receiving an action call message from a sub-application.

[0077] In this embodiment, the action invocation type refers to a message type identifier agreed upon between the host and the sub-application, used to distinguish action invocation messages from other messages (such as state synchronization messages, lifecycle messages, etc.). When the sub-application initiates an action invocation to the host, it sets the message type field to this agreed-upon type identifier. As an example, this type identifier could be named STORE_ACTION, but this solution does not limit its specific name, as long as the host and the sub-application agree on it in advance.

[0078] Example 1 provides an iframe cross-window asynchronous callback bridging method to solve the problem that multiple asynchronous callbacks declared by the sub-application cannot be accurately identified, restored, triggered, and posted back by the host when the iframe sub-application runs isolated from the host page and function objects cannot be serialized and passed across windows. Figures 1-3 As shown, it includes:

[0079] S100, Callback Type Declaration Steps, including:

[0080] In the action invocation message initiated by the sub-application to the host, the callback type is declared with a serializable parameter structure;

[0081] The action invocation message contains an action name and a parameter array. The parameter array contains an embedded callback type declaration field, which indicates that the host needs to restore the value of the corresponding parameter position to a locally executable callback function.

[0082] The callback type declaration field can be a string, a string array, a JSON array string, or a comma-separated string, declaring one or more callback types that need to be restored by the host, such as ["success", "fail"]. The callback type declaration field can also be expanded to a descriptor object or an array of descriptors. Each descriptor carries the callback type and its lifecycle strategy, which includes one-time callback, multiple callbacks, and timeout.

[0083] S200, Callback Declaration Parsing and Validation Steps, including:

[0084] S201. After receiving the action call message initiated by the sub-application, the host parses the action name and parameter array in the message;

[0085] S202. The host iterates through the parameter array. For each parameter of object type, it reads the callback type declaration field it carries and records the index position of the parameter in the parameter array, which is called the parameter index.

[0086] S203. If the callback type declaration field is a string, a string array, a JSON array string, or a comma-separated string, the host will standardize each callback type name into a callback type and assign a default lifecycle strategy to each callback type. The default lifecycle strategy is a one-time callback. If the callback type declaration field is a descriptor object or a descriptor array, the host will read the lifecycle strategy in each descriptor.

[0087] S204. The host performs naming convention validation on the type name of each callback to be generated, and only type names consisting of letters, numbers and underscores are allowed to pass. Illegal types will not generate corresponding callbacks, thereby preventing the injection of illegal identifiers.

[0088] S205. The host searches for a host method that matches the action name in the action mapping table based on the action name parsed in step S201. If a match is found, it is recorded as the target host action method for use in subsequent call steps. If no match is found, the current processing is terminated and an ACTION_ERROR error message is returned to the sub-application.

[0089] S300, the callback descriptor generation and registration steps include:

[0090] S301. The host generates a unique call identifier invokeId for the current action call, obtains the unique identifier sourceKey of the message source window, and saves a reference to the source window.

[0091] S302. For each valid callback type, the host generates a globally unique callback identifier (callbackId) and combines the callback type (callbackType), callback identifier (callbackId), invocation identifier (invokeId), action name, parameter index (paramIndex) recorded in step S202, lifecycle policy determined in step S203, and source window identifier (sourceKey) obtained in step S301 into a callback descriptor. Table 1 provides an example of the field structure of the callback descriptor.

[0092] Table 1. Callback Descriptor Field Structure

[0093] Fields meaning Generation or source effect callbackType Callback type name Sub-application declaration Differentiate between success, failure, and close callbacks. callbackId unique identifier for callback Host generation Concurrent isolation and backhaul location invokeId Action call identifier Host-generated or message-carried Bind an action request paramIndex Callback parameter position When parsing parameters, we get Restore to the correct parameter object policy Lifecycle strategy Declaration or default policy One-time, multiple, and timed cleanup sourceKey Source window and source identifier Message event received Preventing cross-origin false callbacks

[0094] S303. The host registers the above callback descriptors in the callback registry, marks the registration status as pending, and splits multiple callbacks into independent callback descriptors to ensure that different callback types under the same action do not overwrite each other.

[0095] S400, local callback recovery and injection steps, including:

[0096] S401. The host locates the corresponding parameter object in the parameter array based on the parameter index recorded in each callback descriptor, and generates a local executable function for each parameter object. When generating the local executable function, the source window reference saved in step S301 and the callback identifier callbackId in the callback descriptor are injected into the local executable function, so that the local executable function carries the source window reference for subsequent message return.

[0097] S402. When the local executable function is triggered, it first queries the registration status of the corresponding callback descriptor in the callback registry. If the corresponding registration entry does not exist, or if the registration entry exists but the status is consumed, expired, canceled, source mismatched, or source unavailable, it returns directly without performing subsequent message assembly and return operations. If the status is pending, it assembles the callback identifier callbackId, callback type, action name, and actual parameters passed at the time of triggering in the callback descriptor into a callback return message of a preset type. In this embodiment, the preset type is exemplarily "CALLBACK" as the message type identifier. In specific implementations, this identifier can be any string or enumeration value that can distinguish callback postback messages from other message types, such as "callback" or "cb," as long as the host and sub-application agree on it beforehand. The invokeId identifier is not included in the postback message by default; it is mainly used internally by the host to locate the corresponding entry in the callback registry for state updates and concurrency isolation. Not exposing it externally reduces the risk of misuse of the call context and decreases message size. In compatibility or debugging scenarios, the invokeId can be optionally included in the postback message through bridge configuration options.

[0098] S402a. When the same parameter index position corresponds to one or more callback types, the host writes the one or more native executable functions into the callbacks object and generates a callbackDispatcher dispatch function and a cbk-compatible entry point. The callbacks object internally maintains the mapping relationship between callback types and corresponding native executable functions. When the callbackDispatcher dispatch function or cbk-compatible entry point is called, it finds and calls the corresponding native executable function according to the callback type indication or default strategy passed by the caller, thereby dispatching the single trigger on the host side to the correct callback processing logic.

[0099] The `callbacks` object described above is a collection of key-value pairs, where the key is the callback type (e.g., "success", "fail") and the value is the corresponding native executable function. This object facilitates direct lookup and invocation of callbacks by type on the host side, and is especially suitable for scenarios that require batch management of multiple callbacks.

[0100] `callbackDispatcher` is a unified dispatch function that accepts a callback type parameter and several arguments. Internally, it looks up the corresponding function in the `callbacks` object based on the type and executes it. This dispatch function simplifies the caller's triggering logic; when the host side is unsure of the specific callback type, dynamic dispatch can be achieved by passing a type string.

[0101] The cbk compatibility entry point is used to ensure compatibility with existing calling methods that use cbk as the callback entry point. In actual use, cbk reuses callbackDispatcher: when the first parameter is a registered callback type and there are subsequent arguments, it dispatches according to that type; otherwise, it calls the default callback function and passes the arguments through.

[0102] The three injection modes can coexist, and the host side can freely choose according to its calling habits, which greatly improves the adaptability of this solution in different engineering environments.

[0103] S403. The host injects the generated local executable function into the corresponding position of the original parameter object, replaces the original callback type declaration field, and completes the reconstruction of the parameter object.

[0104] S404. The host calls the target host action method found in step S205 using the reconstructed parameter object, so that the host method can directly trigger the local executable function when needed.

[0105] S500, callback triggering and result return steps, including:

[0106] S501. During the execution of the host action method, when the trigger node corresponding to a certain callback type is reached, the injected local executable function is called;

[0107] S502. According to the logic of step S402, the local executable function assembles the callback identifier, callback type, action name, and actual parameters into a callback return message of a preset type. Under the default running configuration, the message does not carry the call identifier invokeId. The main reason is that invokeId is used for internal callback registry location and concurrency isolation. Not exposing it externally can reduce the risk of misuse of the call context and reduce the message size. In compatibility or debugging scenarios, the invokeId can be selected to be carried through the bridge configuration item. It should be ensured that the sub-application receiving end has adapted the corresponding parsing logic. After receiving the message, the sub-application distinguishes the multiple callbacks registered in this call according to the callback type and callbackId.

[0108] The callback return type is a pre-agreed message type identifier between the host and the sub-application, used to distinguish callback return messages from other cross-window messages. The sub-application can locate the callback dispatch logic by recognizing this type identifier at the receiving end. As an example, this type identifier could be named CALLBACK, but this solution does not limit its specific name, as long as it is pre-agreed upon by the host and the sub-application.

[0109] S503. The host sends a CALLBACK message to the original sub-application window via postMessage, targeting the source window reference saved in step S301. The message carries the fields assembled in step S502, enabling the sub-application to distinguish multiple callbacks registered in this call based on the callback type and callbackId.

[0110] It is understood that the above-mentioned message type identifier "CALLBACK" is merely an exemplary name used for ease of explanation in this embodiment and does not constitute a limitation on the scope of protection of this invention. In specific engineering implementations, developers can define the message type identifier as any string or value that can uniquely identify the callback message according to the actual communication protocol, as long as the host and the iframe sub-application have a consistent semantic understanding of the identifier.

[0111] It should be noted that while postMessage is used as the specific implementation method for cross-window communication in step S503 above, the "cross-window communication" of this invention is not limited to postMessage. In specific engineering implementations, cross-window communication can also employ other equivalent communication mechanisms provided by the browser platform, such as the MessageChannel interface, the BroadcastChannel interface, or indirect communication methods based on shared storage, as long as the communication mechanism can transmit serializable messages between the host window and the iframe child application window. The above communication mechanisms are all conventional technical means that can be equivalently replaced by those skilled in the art after reading this embodiment, according to the actual application scenario.

[0112] S600, lifecycle and concurrency isolation management steps, including:

[0113] S601. For descriptors marked as one-time callbacks in the lifecycle strategy, the host immediately updates the status of the corresponding entry in the callback registry to consumed after the local executable function is triggered for the first time, and retains it until it is removed during timeout cleanup or unified cleanup, so that the local executable function corresponding to the callback cannot be repeatedly returned due to the status query in step S402 when it is called again in the future.

[0114] S602. For descriptors marked as multiple callbacks in the lifecycle strategy, the host retains the registration item after each trigger until the preset timeout period is reached or the CANCEL_CALLBACK explicit cancellation instruction is received. Then, the status of the registration item is updated to expired or cancelled and removed by the timeout or unified cleanup mechanism.

[0115] S603. Before the CALLBACK message is sent back, the host verifies the validity of the original message source window. It checks the source window reference saved in step S301 to determine whether it can still be used as a cross-window message back-off target. It then recalculates or verifies the current source identifier using the window reference and matches it with the source window identifier sourceKey registered at the time of registration. If the source window is unavailable, cannot be used as a back-off target, or the source identifier does not match the source window identifier sourceKey registered at the time of registration, the back-off is rejected, and the corresponding callback registration item is set to the final state and removed by the timeout or unified cleanup mechanism.

[0116] It should be noted that the above steps overcome the inherent limitation that JavaScript function objects cannot be passed across windows via postMessage by using serializable callback type declarations and callback descriptors. The combined identifier of invokeId and sourceKey allows for independent identification and isolation of multiple sub-application windows, multiple concurrent action calls within the same window, and multiple callback types within the same call, avoiding crosstalk issues caused by fixed callback fields or global mappings in existing solutions. Through lifecycle-state-based consumption, timeout cleanup, and source invalidation handling, hanging callbacks and invalid postbacks are effectively eliminated, thus ensuring the reliability of asynchronous interactions in complex scenarios such as games, events, and payments.

[0117] In summary, this solution implements an iframe cross-window asynchronous callback bridging method that can accurately restore one or more callbacks declared by a sub-application to the host's local functions when function objects are not transitive. It also reliably returns the asynchronous results to the correct sub-application through structured postback messages, and has complete concurrency isolation and lifecycle management capabilities.

[0118] Example 2: This example provides an iframe cross-window asynchronous callback bridging system, which is used to execute the method described in Example 1, including:

[0119] The callback type declaration module is used to: enable sub-applications to declare callback types in action invocation messages sent to the host with a serializable parameter structure; wherein, the action invocation message contains an action name and a parameter array, and the parameter array embeds a callback type declaration field, and the declaration field adopts a string, a string array, a descriptor object, a descriptor array, a JSON array string, or a comma-separated string;

[0120] The callback declaration parsing and validation module is used to: after the host receives the action call message, iterate through the parameter array, read the callback type declaration field and standardize it into a callback type list, validate the naming convention of each callback type name to be generated, and only allow the legally named types to pass;

[0121] The callback descriptor generation and registration module is used to: generate a unique invokeId for the current action call, obtain the sourceKey of the source window, generate a unique callbackId for each valid callback type, combine it with the action name, parameter index, lifecycle strategy and source window identifier sourceKey to form a callback descriptor, and register it to the callback registry, splitting multiple callbacks into independent registration items.

[0122] The local callback recovery and injection module is used to: generate a local executable function based on each callback descriptor. When the function is triggered, it assembles the callbackId, callback type, action name, and actual parameters into a callback postback message. The call identifier invokeId is not assembled into the postback message by default but is only used for internal callback registry location and concurrency isolation in the host. It can be carried in compatibility or debugging configurations. The generated local executable function is injected into the corresponding position of the original parameter object as a callbacks object, a callbackDispatcher dispatch function, or a cbk compatible entry point to replace the callback type declaration field, and the target host action method is called with the reconstructed parameter object.

[0123] The callback triggering and message return module is used to: assemble a CALLBACK message when the host action method triggers the local executable function, and send the CALLBACK message to the original sub-application window via postMessage. The message carries the callbackId, callback type, action name and actual parameters, and can optionally carry invokeId under compatibility or debug configuration.

[0124] The lifecycle and concurrency isolation management module is used to: immediately mark one-time callbacks as consumed and retain the registration item without immediate deletion after triggering; retain multiple callbacks according to the strategy until timeout or cancellation; isolate callback descriptors of multiple concurrent calls in the same sub-application through different invokeIds; verify the validity of the source window before postback; reject postbacks from invalid sources and clean up the registration item.

[0125] Example 3: This example provides a computer-readable storage medium, including:

[0126] The storage medium is used to store computer program instructions for implementing the method described in Embodiment 1; specifically, the executable program can be built into the iframe cross-window asynchronous callback bridging system described in Embodiment 2, so that the iframe cross-window asynchronous callback bridging system can implement the iframe cross-window asynchronous callback bridging method described in Embodiment 1 by executing the built-in executable program.

[0127] Furthermore, the computer-readable storage medium in this embodiment can be any combination of one or more readable storage media, wherein the readable storage medium includes an electrical, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof.

[0128] Unlike existing technologies, this application's iframe cross-window asynchronous callback bridging method, system, and medium can accurately declare, restore, trigger, postback, and clean up asynchronous callbacks in sub-applications, even under the objective constraint that function objects cannot be serialized and passed across windows. It effectively resists abnormal interference such as multi-window concurrent crosstalk, callback hanging, source failure, and repeated execution, ensuring that the asynchronous call result is reliably returned to the correct sub-application window. This meets the working requirements of long-term stable interaction in complex iframe scenarios such as game activities, online payments, and pop-up interactions, and makes up for the deficiencies of existing state synchronization and SDK encapsulation solutions in asynchronous callback management, thus having high application value.

[0129] It should be understood that in the various embodiments of this document, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this document.

[0130] It should also be understood that, in the embodiments herein, the term "and / or" is merely a description of the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following associated objects have an "or" relationship.

[0131] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. 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 document.

[0132] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0133] In the embodiments provided herein, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0134] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments described herein, depending on actual needs.

[0135] Furthermore, the functional units in the various embodiments of this document can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0136] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this paper, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this paper. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0137] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for bridging asynchronous callbacks across iframe windows, characterized in that, Includes the following steps: In response to an action call initiated by an iframe child application to the host: Receive the action invocation message sent by the sub-application, parse it to obtain the action name and parameter array, wherein the parameter array contains an embedded callback type declaration field, and the callback type declaration field instructs the host to restore the value of the corresponding parameter position to a local executable function; Determine the target host action method based on the action name; Obtain the source window identifier and source window reference of the action call message, generate a call identifier for the current action call, and save the source window reference; The parameter array is traversed, the callback type declaration field is read and parsed to obtain at least one callback type, the index position of the callback type declaration field in the parameter array is recorded, and the validity of each callback type is verified; a callback identifier and a callback descriptor are generated for each valid callback type, and the callback descriptor is registered in the callback registry; wherein, the callback descriptor at least includes the callback identifier, the call identifier, the source window identifier, and the lifecycle strategy corresponding to the callback type; A native executable function is generated for each callback descriptor registered in the callback registry. The callback identifier and the saved source window reference are injected into the native executable function. When the same index position corresponds to one or more callback types, the native executable function corresponding to the one or more callback types is written into the callbacks object, and a callbackDispatcher dispatch function and a cbk-compatible entry point are generated. The callbacks object, the callbackDispatcher dispatch function, and the cbk-compatible entry point are injected into the parameter object corresponding to the index position recorded in the parameter array to replace the callback type declaration field, and the target host action method is called with the reconstructed parameter array. In response to the triggering of the local executable function during the execution of the target host action method, the status of the corresponding entry in the callback registry is queried. If the status is not pending, it returns directly; if the status is pending, the callback type of the corresponding entry in the callback registry is read, and combined with the implanted callback identifier and the actual parameters passed in at the time of triggering, a callback return message containing message type, action name, callback type, callback identifier and trigger actual parameters is assembled; and based on the implanted source window reference, the callback return message is sent to the source window of the sub-application through cross-window communication, and the status of the corresponding entry in the callback registry is updated according to the lifecycle strategy.

2. The iframe cross-window asynchronous callback bridging method according to claim 1, characterized in that: The method for determining the target host action based on the action name includes: Search the preset action mapping table for the host method that matches the action name; If a hit occurs, the hit host method will be used as the target host action method. If a match is missed, the current processing is terminated and an ACTION_ERROR error message is returned to the sub-application.

3. The iframe cross-window asynchronous callback bridging method according to claim 1, characterized in that: The step of traversing the parameter array, reading the callback type declaration field, and parsing to obtain at least one callback type further includes: Iterate through the parameter array. For each parameter of object type, read its callback type declaration field and record the index position of the parameter in the parameter array, which is called the parameter index. If the callback type declaration field is a string, a string array, a JSON array string, or a comma-separated string, then each callback type name is standardized into a callback type, and a default lifecycle strategy is assigned to each callback type, wherein the default lifecycle strategy is a one-time callback. If the callback type declaration field is a descriptor object or an array of descriptors, then read the callback type and its lifecycle strategy carried by each descriptor.

4. The iframe cross-window asynchronous callback bridging method according to claim 3, characterized in that: The step of generating a callback identifier and a callback descriptor for each valid callback type, and registering the callback descriptor to the callback registry, further includes: Generate a globally unique callback identifier for each callback type; The callback type, callback identifier, call identifier, action name, parameter index, lifecycle strategy, and source window identifier are combined into the callback descriptor; The callback descriptor is registered in the callback registry, and the registration status is marked as pending.

5. The iframe cross-window asynchronous callback bridging method according to claim 4, characterized in that: The callbacks object, the callbackDispatcher dispatch function, and the cbk-compatible entry point are injected into the parameter object corresponding to the index position recorded in the parameter array, further including: When the parameter position corresponding to the parameter index corresponds to only one callback type, the generated native executable function is written into the callbacks object, and the callbackDispatcher dispatch function and cbk-compatible entry point are generated and injected with the corresponding parameter object. When the parameter position corresponding to the parameter index corresponds to multiple callback types, the generated multiple native executable functions are written into the callbacks object, and dispatched to the corresponding native executable functions through the callbackDispatcher dispatch function or the cbk compatible entry point according to the callback type parameter or the default strategy.

6. The iframe cross-window asynchronous callback bridging method according to claim 5, characterized in that: The step of updating the status of the corresponding entry in the callback registry according to the lifecycle strategy further includes: For descriptors marked as one-time callbacks in the lifecycle strategy, after the local executable function is triggered for the first time, the status of the corresponding entry in the callback registry is updated to consumed and retained until timeout cleanup or unified cleanup is performed and then removed, so that the local executable function corresponding to the callback cannot be repeatedly sent back due to the status query when it is called again in the future.

7. The iframe cross-window asynchronous callback bridging method according to claim 4, characterized in that: The method of sending the callback postback message to the source window of the sub-application via cross-window communication, based on the implanted source window reference, further includes: Before sending the callback message, the validity of the original message source window is verified by referencing the implanted source window. If the source window is available, the current source identifier is retrieved again through the source window reference and matched with the source window identifier during registration; if a match is found, the callback message is sent through cross-window communication with the source window reference as the target. If the source window is unavailable, cannot be used as a cross-window message return target, or the current source identifier does not match the source window identifier, the return will be rejected, and the corresponding callback registration item will be set to the final state and removed by the timeout or unified cleanup mechanism.

8. The iframe cross-window asynchronous callback bridging method according to claim 1, characterized in that: The step of updating the status of the corresponding entry in the callback registry according to the lifecycle strategy further includes: For descriptors marked as having multiple callbacks in the lifecycle strategy, the entry is retained and kept in a pending state after each trigger until the preset timeout period is reached or an explicit cancellation instruction is received. Then, the entry status is updated to expired or cancelled and removed by the timeout or unified cleanup mechanism.

9. An iframe cross-window asynchronous callback bridging system, used to implement the iframe cross-window asynchronous callback bridging method according to any one of claims 1 to 8, characterized in that, The system includes: The callback type declaration module is used to enable iframe child applications to declare callback types in action call messages initiated to the host with a serializable parameter structure; The callback declaration parsing module is used to traverse the parameter array after the host receives the action call message, read the callback type declaration field and standardize it into a callback type list, and perform a validity check on each callback type; The callback descriptor generation and registration module is used to generate a callback descriptor containing a callback identifier, a call identifier, a source window identifier, and a lifecycle strategy for each valid callback type, and register it in the callback registry. The local callback restoration and injection module is used to generate a local executable function for each registered callback descriptor, inject it into the corresponding position of the parameter array to replace the callback type declaration field, and call the target host action method with the reconstructed parameter array; The callback triggering and message return module is used to assemble callback return messages and send them to the source window of the sub-application via cross-window communication when the local executable function is triggered. The lifecycle and concurrency isolation management module is used to update the status of the corresponding entry in the callback registry according to the lifecycle strategy carried by the callback descriptor, and to verify the validity of the source window.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the iframe cross-window asynchronous callback bridging method according to any one of claims 1 to 8.

Images