A page navigation method, device and readable storage medium

Abstract

The present application discloses a page navigation method, device and readable storage medium, the method comprising the following steps: according to the page jump requirement information, determine the caller from the Flutter side and the Native side of the routing stack framework; wherein both the Flutter side and the Native side expose routing stack information with the same routing stack context data structure, and each engine in the routing stack framework maintains the routing stack context on its own engine, and the Native side maintains the routing stack context of the entire end in the routing stack framework; from the target routing stack context corresponding to the caller, search for routing parameters corresponding to the page jump requirement information; using the routing parameters, perform page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework. In the present application, not only does it have routing navigation capabilities in Flutter hybrid development, but it can also support multiple engines and local views.

Description

Technical Field

[0001] The present application relates to the field of computer application technology, and in particular to a page navigation method, device and readable storage medium. Background Art

[0002] Hybrid development refers to the use of two or more technology stacks for page development in the same App (mobile software). In hybrid development, page jumps between different technology stacks need to be implemented. For example, hybrid development of Native and Flutter requires the following: opening a full-screen Flutter page from a Native page; opening a Flutter partial page from a Native page; holding two or more FlutterViews (Flutter views) in the same Native page at the same time, and supporting hybrid stack jumps with partial views.

[0003] In Flutter Boost, since the Flutter engine can only hold one Flutter container at a time, switching Flutter containers will inevitably cause the logic of the switched page to be suspended, and the Flutter logic in the App background cannot be executed. It cannot solve the scenario where there are multiple FlutterViews in a single page; there is no routing stack maintenance solution, and only the default stack navigation provided by the system can be used.

[0004] In Flutter Thrio, Flutter can only use Navigator to jump to Flutter. It does not support opening a new Flutter container, which causes the jump animation to be inconsistent with the native route, resulting in a sense of disconnection. Multi-engine maintenance takes up a lot of memory. It cannot solve the scenario where there is a local FlutterView in a single page, and does not support Flutter Fragment.

[0005] In summary, the above two solutions only provide routing navigation capabilities in Flutter hybrid development. They do not fully support multiple engines and local views, and do not have a sound routing stack maintenance mechanism. Summary of the invention

[0006] The purpose of this application is to provide a page navigation method, device and readable storage medium, so that the routing stack is maintained in order, which not only has the routing navigation capability in Flutter hybrid development, but also can support multiple engines and local views.

[0007] In order to solve the above technical problems, this application provides the following technical solutions:

[0008] A page navigation method, comprising:

[0009] Receive and parse the page jump request to obtain the page jump requirement information;

[0010] According to the page jump requirement information, determine the caller from the Flutter side and the Native side of the routing stack framework; wherein both the Flutter side and the Native side expose routing stack information having the same routing stack context data structure, and each engine in the routing stack framework maintains the routing stack context on its own engine, and the Native side maintains the routing stack context of all ends in the routing stack framework;

[0011] Searching for routing parameters corresponding to the page jump requirement information from the target routing stack context corresponding to the caller;

[0012] Using the routing parameters, page jump navigation is performed on the corresponding Flutter side and / or Native side in the routing stack framework.

[0013] Preferably, it also includes:

[0014] In the routing stack framework, the interfaceless engine is used as a transfer station for sharing data to achieve communication between engines.

[0015] Preferably, the receiving and parsing of the page jump request to obtain the page jump requirement information includes:

[0016] Receiving the page jump request;

[0017] If the page jump request is a page call request, the page call request is parsed to obtain the page jump requirement information; wherein the page jump requirement information includes the caller and the calling page.

[0018] Preferably, using the routing parameters, performing page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework includes:

[0019] If the caller is the Native side and the calling page has been registered, the Native side is used in combination with the target routing stack context to execute a page opening process corresponding to the page type of the calling page.

[0020] Preferably, the Native side is used in combination with the target routing stack context to execute a page opening process corresponding to the page type of the calling page, including:

[0021] If the page type of the calling page is a Native page, the Native side is used to set the index order in the target routing stack context to 1, open the calling page, put the calling page into the routing stack of the Native side, and trigger the event hook of the Native side.

[0022] Preferably, the Native side is used in combination with the target routing stack context to execute a page opening process corresponding to the page type of the calling page, including:

[0023] If the page type of the calling page is a Flutter page, the Native side is used to set the index order field in the target routing stack context to 1, and the engine identification field in the target routing stack context is used to pass the page information of the calling page from the communication channel of the engine corresponding to the engine identification field to the corresponding engine on the Flutter side, so that the Flutter side puts the page information into its own routing stack, initializes a Flutter container, opens the Flutter container, renders the calling page on the corresponding engine, triggers the event hook, and sends a notification message to the Native side that the calling page has been successfully opened;

[0024] After the Native receives the notification message, the Native side is used to add the calling page to the routing stack of the Native side and trigger the event hook.

[0025] Preferably, using the routing parameters to perform page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework includes:

[0026] If the caller is the Flutter side and the calling page has been registered, the Flutter side is used to execute a page opening process corresponding to the page type of the calling page.

[0027] Preferably, the utilizing the Flutter side and combining the target routing stack context to execute the page opening process corresponding to the page type of the calling page includes:

[0028] If the page type of the called page is a Native page, the Flutter side is used to set the index order field in the target routing stack context to 1, obtain the engine identifier of the corresponding engine, and use the communication channel corresponding to the engine identifier to send the page message of the called page to the Native side, so that after the Native side receives the page message, the calling page is opened, and the calling page is added to the routing stack of the Native side, triggering the event hook of the Native side, and sending a notification message to the Native side that the called page has been successfully opened;

[0029] After the Flutter side receives the notification message, the calling page is added to the routing stack of the Flutter side, and the event hook of the Flutter side is triggered.

[0030] Preferably, the utilizing the Flutter side and combining the target routing stack context to execute the page opening process corresponding to the page type of the calling page includes:

[0031] If the page type of the calling page is a Flutter page, the Flutter side determines whether the calling page corresponds to the current engine of the current Flutter page;

[0032] If the calling page corresponds to the current engine, the Flutter side is used in combination with the target routing stack context to open the calling page using the current Flutter container corresponding to the current engine, or a new Flutter container is used to open the calling page;

[0033] If the calling page does not correspond to the current engine, the calling page is opened using a new Flutter container by utilizing the Flutter side and combining the target routing stack context.

[0034] Preferably, the utilizing the Flutter side and combining the target routing stack context to execute the page opening process corresponding to the page type of the calling page includes:

[0035] If the page type of the calling page is a Flutter partial view, a Flutter container is initialized and the Flutter container is added to the parent container;

[0036] Call the routing navigation method provided by the Flutter container, and pass in the engine identifier and url of the Flutter local view corresponding to the target routing stack context and the identifier field of the local page;

[0037] The opening method of the engine corresponding to the engine identifier is called to notify the Flutter side to open a Flutter page.

[0038] Preferably, the receiving and parsing of the page jump request to obtain the page jump requirement information includes:

[0039] Receiving the page jump request;

[0040] If the page jump request is a page close request, the page close request is parsed to obtain the page jump requirement information.

[0041] Preferably, using the routing parameters, performing page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework includes:

[0042] If the target page is a Native page, the routing stack on the Native side is used to close the last routing information, and an identification field of a local page of the context of the target routing stack in the routing information is obtained;

[0043] Using the identification field of the local page, determine whether the current page has a nested Flutter subview;

[0044] If yes, monitor the destruction event of the Flutter container KantFlutterViewController customized by the technical framework, and when monitoring that the Flutter subview is destroyed, retrieve the multi-engine relationship object maintained by the Flutter engine manager, obtain the engine identifier corresponding to the multi-engine relationship object, and use the Native side to notify the Flutter engine corresponding to the engine identifier to turn off the last corresponding routing information. The Native side uses the turned-off routing information and the second-to-last routing information as input parameters to call the event hook notification;

[0045] If not, the Native side is used to obtain the engine identifier of the last routing information, and the Flutter engine with the corresponding engine identifier is notified to turn off the last routing information corresponding to the Flutter engine. The Native side uses the turned-off routing information and the penultimate routing information as input parameters to call the event hook notification.

[0046] Preferably, the use of the target routing stack context corresponding to the page jump requirement information in the routing stack framework to implement page jump navigation corresponding to the page jump requirement includes:

[0047] If the target page is a Flutter page, the last routing information on the current engine is turned off by using the Flutter side, and the identification field of the local page of the target routing stack context in the routing information is obtained;

[0048] Determine whether the current Flutter page is a partial view by using the identification field of the partial page;

[0049] If yes, the event notification hook is called using the engine corresponding to the routing information turned off on the Flutter side and the second-to-last routing information on the engine as input parameters;

[0050] If not, the routing information of the second-to-last page on the Native side is obtained by requesting the Native side, and the Native side is notified to turn off the last routing information on the Native side. The Flutter side uses the turned-off routing information and the obtained second-to-last routing information as input parameters to call the event notification hook.

[0051] An electronic device, comprising:

[0052] Memory for storing computer programs;

[0053] A processor is used to implement the steps of the above-mentioned page navigation method when executing the computer program.

[0054] A readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned page navigation method are implemented.

[0055] Applying the method provided in the embodiment of the present application, receiving and parsing the page jump request, and obtaining the page jump requirement information; determining the caller from the Flutter side and the Native side of the routing stack framework according to the page jump requirement information; wherein both the Flutter side and the Native side expose routing stack information having the same routing stack context data structure, and each engine in the routing stack framework maintains the routing stack context on its own engine, and the Native side maintains the routing stack context of the entire end in the routing stack framework; searching for the routing parameters corresponding to the page jump requirement information from the target routing stack context corresponding to the caller; and using the routing parameters, performing page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework.

[0056] In the routing stack framework, both the Flutter side and the Native side expose routing stack information with the same routing stack context data structure and have corresponding engines for maintenance. When there is a page jump navigation requirement, intelligent page jump navigation can be implemented based on the corresponding routing stack context. Specifically, after receiving and parsing the page jump request, the jump requirement information can be obtained. Then, based on the jump requirement information, the caller is clarified, and the routing parameters that match the jump requirement information are found from the target router stack context corresponding to the caller. Using the routing parameters, the corresponding Flutter side and / or Native side in the routing stack framework can implement page jump navigation that can meet the page jump requirement information. It can be seen that in this application, based on the target routing stack context, it not only has the routing navigation capability in Flutter hybrid development, but also can be supported on multiple engines and local views.

[0057] Correspondingly, the embodiments of the present application also provide an electronic device and a readable storage medium corresponding to the above-mentioned page navigation method, which have the above-mentioned technical effects and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0059] Figure 1 This is a flow chart of an implementation of a page navigation method in an embodiment of the present application;

[0060] Figure 2 This is a schematic diagram of inter-engine communication in an embodiment of the present application;

[0061] Figure 3 This is a schematic diagram of a scenario in which a Native page opens a full-screen Flutter page in an embodiment of the present application;

[0062] Figure 4 This is a schematic diagram of clicking an icon in a Native live broadcast room to open a Flutter half-screen page in an embodiment of the present application;

[0063] Figure 5 This is a schematic diagram of an embodiment of the present application in which a red envelope module and a widget module are developed by two FlutterViews in a Native live broadcast room;

[0064] Figure 6 It is a navigation routing logic diagram;

[0065] Figure 7 A schematic diagram for another navigation route;

[0066] Figure 8 A navigation routing logic diagram in an embodiment of the present application;

[0067] Fig. 9 This is a schematic diagram of rendering a Flutter View as multiple Tab pages in an embodiment of the present application;

[0068] Fig.10 A schematic diagram of a hybrid routing stack maintenance capability of entering and exiting the stack at any time in a multi-local view scenario in an embodiment of the present application;

[0069] Fig.11 This is a schematic diagram of a routing stack in an embodiment of the present application;

[0070] Fig.12a This is another global schematic diagram of a routing stack in an embodiment of the present application;

[0071] Figure 12b It is a partial schematic diagram of another routing stack 1 in an embodiment of the present application;

[0072] Fig.12c This is a partial schematic diagram of another routing stack 2 in an embodiment of the present application;

[0073] Fig.12d It is a partial schematic diagram of another routing stack 3 in an embodiment of the present application;

[0074] Fig.13 This is a schematic diagram of the structure of a page navigation device in an embodiment of the present application;

[0075] Fig.14 This is a schematic diagram of the structure of an electronic device in an embodiment of the present application;

[0076] Fig.15 This is a schematic diagram of a specific structure of an electronic device in an embodiment of the present application;

[0077] Fig.16 This is a schematic diagram of a page opening process in which the caller is the Native side in an embodiment of the present application;

[0078] Fig.17 This is a schematic diagram of a page opening process in which the caller is the Flutter side in an embodiment of the present application;

[0079] Fig.18 This is a schematic diagram of a pop page opening process in an embodiment of the present application. DETAILED DESCRIPTION

[0080] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0081] Please refer to Figure 1 , Figure 1 This is a flow chart of a page navigation method in an embodiment of the present application, the method comprising the following steps:

[0082] S101, receiving and parsing a page jump request to obtain page jump requirement information.

[0083] Among them, the page jump request can be specifically a page jump request sent by a hybrid-developed APP. For example, when the monitoring user clicks a link or switch button in the page in the APP, and needs to open / or close a certain page / pages (such as a full-screen page / or a partial view with a view or a link function), it is determined that a page jump request has been received, and the page jump requirement is determined based on the user's specific operation behavior. Of course, the page jump request can also be specifically a request that carries page jump requirement information. By performing a corresponding analysis on the request, the page jump requirement information can be directly obtained.

[0084] S102. According to the page jump requirement information, determine the caller from the Flutter side and the Native side of the routing stack framework.

[0085] Among them, both the Flutter side and the Native side expose routing stack information with the same routing stack context data structure, and each engine in the routing stack framework maintains the routing stack context on its own engine, and the Native side maintains the routing stack context of all ends in the routing stack framework.

[0086] S103: Searching for routing parameters corresponding to the page jump requirement information from the target routing stack context corresponding to the caller.

[0087] Specifically, both the Flutter side and the Native side in the routing stack framework expose routing stack information with the same routing stack context data structure; in the routing stack framework, each engine maintains the routing stack context on its own engine (wherein the context may specifically refer to a page), and the Native side maintains the routing stack context of all ends in the routing stack framework.

[0088] The routing stack context data structure (a variable name, such as KantRouteSettings) in this application may specifically include the following fields:

[0089] Field 1, index: int, that is, the index order field, the index in the container where the current Flutter page is located;

[0090] Field 2, url:String, which is the route name field of string type, such as url, which is the url registered by the route;

[0091] Field 3, uniqueId: String, which is a page identification field of string type, such as uniqueId, which is the unique identifier of the page;

[0092] Field 4, entrypoint:String (engine identifier field of string type, such as engine ID), the identifier of the engine where the page is located;

[0093] Field 5, identification field of a local page: Bool, that is, a local view identifier of a Boolean type, such as the identification field of a local page, indicating whether it is a nested page;

[0094] Field 6, params:Object, that is, additional page parameters of dictionary type, such as params, corresponding to page parameters.

[0095] It should be noted that the order of the above six fields is not limited in this application. For easy search, the above six fields can also be divided into a name part such as name and a parameter part such as arguments, where name can correspond to the above fields 1 and 2, and arguments can correspond to the above fields 3 to 6.

[0096] Preferably, in order to facilitate determining the type of page and whether to hide the system navigation bar, you can also set:

[0097] Field 7, platform:String, that is, a string type platform field, such as platform, indicating whether the page is "flutter" or "native";

[0098] Field 8, hideNavBar:Bool, which is a Boolean hidden navigation identifier, such as hideNavBar, indicating whether to hide the system navigation bar.

[0099] Field 7 and Field 8 may correspond to arguments.

[0100] Generally, the Flutter routing stack framework is divided into Android side, iOS side and Dart side. For the convenience of description, Android and iOS are not distinguished below, and the two are referred to as Native side. Since the mixed development in this application takes Flutter development as an example, the Dart side corresponds to the Flutter side (of course, in other embodiments of this application, the Flutter side can be other page development frameworks / technologies).

[0101] The above routing stack context data structure should not only be maintained by implementing a Model (data model, such as data model) on the Dart side, but also an equivalent Model on the Native side, so that the three ends can maintain their respective routing stacks in time when the page jumps.

[0102] Specifically, on the Dart side, a routing stack information list property is exposed, such as KantSettingsList, which is an array structure that is generic to the routing stack page data structure, such as KantRouteSettings, which is a one-dimensional array used to store the routing information pushed into the stack as the routing stack context. In addition, an engine identifier is exposed, which is the Engine identifier.

[0103] On the Native side, a KantSettingsList property is also exposed, which has the same meaning as the Dart side and is used as the routing stack context for the business side to access.

[0104] It should be noted that the routing information path is designed with a field index. This is not the index of the routing stack where the current page is located in other frameworks (if you want to get the index of the routing stack where the current page is located, you can directly cooperate with KantSettingsList to get this index), but refers to the index of the container where the current Flutter page is located. If the Native page defaults to 1, the purpose of this field is to turn on and off the gesture return on the iOS side. Because Flutter's gesture priority is lower than iOS system gestures, if Navigator (Flutter's routing library) is used without any gesture interception processing, then Flutter's side-swipe return gesture will always be covered by iOS system gestures.

[0105] In this application, the maintenance of multi-engine management and multi-engine routing stack is as follows:

[0106] First, multi-engine management. A page registration method (such as registerRoute) and an engine management library (such as Flutter Engine Manager) are maintained within the routing stack framework. The library maintains a content management variable for each engine, such as KantFlutterEngineContext. The key value is the engine identifier, and the value is the Flutter container array, such as Array <kantflutterviewcontrooler>, which is used to store the related FlutterViewControllers on the current engine, so as to maintain the engine switching and mounting FlutterViewController. In addition, the framework also provides an engine startup method (startup).

[0107] The framework manages multiple engines as follows:

[0108] 1. Framework initialization, the Flutter engine manager will initialize an engine array FlutterEngines and a Map (KantFlutterEngineContext);

[0109] 2. The Dart side and the Native side call the registerRoute method as needed to register the page and specify the engine where the page is located;

[0110] 3. On the Native side, several startup engines with specified names are registered with the Flutter engine manager.

[0111] That is, this application encapsulates a Flutter engine manager to manage multiple engines and Flutter containers on the engines.

[0112] The second is the maintenance of multi-engine routing stacks. The framework requires each engine to maintain the routing stack context on its own engine, while the Native side needs to maintain the routing stack context of the entire framework. That is, if there are n engines, then there are n+1 KantSettingsLists that need to be maintained.

[0113] The multi-engine routing stack maintenance strategy is as follows:

[0114] 1. Flutter's routing stack context fields, such as settingsList, only maintain the routing of the current engine;

[0115] 2. Native routing stack context fields, such as settingsList, maintain the routing of all engines;

[0116] 3. RouteSettings maintains an index, which indicates the page number of this route page (page in the routing stack) in the current FlutterViewController;

[0117] 4. Pushing (opening) a native page will put the native page information on the nearest engine;

[0118] 5. In the Flutter partial view context, Naitve's routing stack maintains the Native page information where the current FlutterView is located.

[0119] It should be noted that in the scenario with multiple partial views, this solution still supports Navigator and using the new FlutterViewController to open the page, and after push, that is, after the page is opened, the state of the previous page can still be retained.

[0120] In this way, after the jump requirement information is obtained, the corresponding routing parameters can be obtained by querying the target routing stack context, and the routing parameters can specifically correspond to the parameters of the specific fields included in the above routing stack context data structure.

[0121] By setting the routing stack based on the above routing stack context structure and the above routing stack maintenance strategy, page jump navigation can be realized. In other words, by using the routing parameters corresponding to the page jump requirement information in the routing stack framework, page jump navigation corresponding to the page jump requirement can be realized. That is, the page opening jump and closing jump can be realized.

[0122] S104: Use the routing parameters to perform page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework.

[0123] Specifically, the business side only needs to pass the page name to open the page, and does not need to implement additional opening and closing methods. For example, Flutter Boost requires the business side to implement two methods to open or close the page.

[0124] Applying the method provided in the embodiment of the present application, receiving and parsing the page jump request, and obtaining the page jump requirement information; determining the caller from the Flutter side and the Native side of the routing stack framework according to the page jump requirement information; wherein both the Flutter side and the Native side expose routing stack information having the same routing stack context data structure, and each engine in the routing stack framework maintains the routing stack context on its own engine, and the Native side maintains the routing stack context of the entire end in the routing stack framework; searching for the routing parameters corresponding to the page jump requirement information from the target routing stack context corresponding to the caller; and using the routing parameters, performing page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework.

[0125] In the routing stack framework, both the Flutter side and the Native side expose routing stack information with the same routing stack context data structure and have corresponding engines for maintenance. When there is a page jump navigation requirement, intelligent page jump navigation can be implemented based on the corresponding routing stack context. Specifically, after receiving and parsing the page jump request, the jump requirement information can be obtained. Then, based on the jump requirement information, the caller is clarified, and the routing parameters that match the jump requirement information are found from the target router stack context corresponding to the caller. Using the routing parameters, the corresponding Flutter side and / or Native side in the routing stack framework can implement page jump navigation that can meet the page jump requirement information. It can be seen that in this application, based on the target routing stack context, it not only has the routing navigation capability in Flutter hybrid development, but also can be supported on multiple engines and local views.

[0126] It should be noted that, based on the above embodiments, the embodiments of the present application also provide corresponding improved solutions. In the preferred / improved embodiments, the same steps or corresponding steps as those in the above embodiments can be referenced to each other, and the corresponding beneficial effects can also be referenced to each other, which will not be described one by one in the preferred / improved embodiments of this article.

[0127] In a specific implementation of the present application, considering that engines cannot communicate directly with each other, it is proposed in this embodiment to use the interfaceless engine as a transit station for sharing data in the routing stack framework to achieve communication between engines.

[0128] Please refer to Figure 2 , Figure 2 This is a schematic diagram of inter-engine communication in an embodiment of the present application.

[0129] Among them, the interfaceless engine (i.e. the default engine) acts as a Store (storage space) transfer station and uses the native capability Dispatch (dispatch / distribution) to send shared data to different engines.

[0130] exist Figure 2 Native (the native data model in the figure) establishes three channels with three engines. Figure 2 As shown in the figure, Engine 3 is a non-UI engine, which is used to manage data and is the Store in the model. The DataModel (data model) provided by Native is used to manage the data in the Store for data distribution, that is, as the Dispatch in the model. Figure 1 And Flutter view Figure 2 Belong to two different engines. If Flutter Figure 1 Want to give Flutter a visual Figure 2 To send a status message, you need to maintain the sent data in the Store through Dispatch. If the Store data changes (that is, the state changes, you need to notify the Flutter view Figure 2 ) will trigger Dispatch to send the transformed data to the Flutter view Figure 2 .

[0131] In a specific implementation of the present application, the above step S101 receives and parses the page jump request to obtain the page jump requirement information, which may specifically include:

[0132] Step 1: Receive a page jump request;

[0133] Step 2: If the page jump request is a page call request, the page call request is parsed to obtain page jump requirement information; wherein the page jump requirement information includes the caller and the calling page.

[0134] For ease of description, the above three steps are combined for explanation below.

[0135] That is to say, the received page jump request is specifically a page call request, that is, the page needs to be opened, and the page call request is parsed to finally obtain the caller and the calling page. The caller can be specifically the Native side or the Flutter side, and the calling page refers to the page that needs to be opened, which can be a Native page or a Flutter page.

[0136] For details, please refer to Fig.16 ,If the caller is on the Native side and the calling page has been registered, the Native side is used in combination with the target routing stack context to execute the page opening process corresponding to the page type of the calling page.

[0137] The following uses the page types of the calling page, namely Native page and Flutter page, and page jump navigation to explain:

[0138] If the page type of the calling page is a Native page, the Native side is used to set the index order field in the target routing stack context to 1, open the calling page, put the calling page into the routing stack on the Native side, and trigger the event hook on the Native side.

[0139] If the page type of the calling page is a Flutter page, the Native side is used to set the index order field in the target routing stack context to 1, and the engine identification field in the target routing stack context is used to pass the page information of the calling page from the communication channel of the engine corresponding to the engine identification field to the corresponding engine on the Flutter side, so that the Flutter side can put the page information into its own routing stack, initialize a Flutter container, open the Flutter container, render the calling page on the corresponding engine, trigger the event hook, and send a notification message to the Native side that the calling page has been successfully opened;

[0140] After Native receives the notification message, it uses the Native side to add the calling page to the routing stack of the Native side and trigger the event hook.

[0141] For details, please refer to Fig.17 If the caller is the Flutter side and the calling page has been registered, the Flutter side is used to execute the page opening process corresponding to the page type of the calling page.

[0142] The following uses the page types of the calling page, namely Native page and Flutter page, and page jump navigation to explain:

[0143] If the page type of the calling page is a Native page, the Flutter side sets the index order field in the target routing stack context to 1, obtains the engine ID of the corresponding engine, and uses the communication channel corresponding to the engine ID to send the page message of the calling page to the Native side, so that after the Native side receives the page message, it opens the calling page and adds the calling page to the routing stack on the Native side, triggering the event hook on the Native side, and sending a notification message to the Native side that the calling page has been successfully opened;

[0144] After receiving the notification message on the Flutter side, the calling page is added to the routing stack on the Flutter side and the event hook on the Flutter side is triggered.

[0145] If the page type of the calling page is a Flutter page, the Flutter side determines whether the calling page corresponds to the current engine of the current Flutter page;

[0146] If the calling page corresponds to the current engine, the Flutter side is used in combination with the target routing stack context to open the calling page using the current Flutter container corresponding to the current engine, or a new Flutter container is used to open the calling page;

[0147] If the calling page does not correspond to the current engine, the Flutter side is used in combination with the target routing stack context to open the calling page using a new Flutter container.

[0148] If the page type of the calling page is a Flutter partial view, initialize a Flutter container and add the Flutter container to the parent container;

[0149] Call the routing navigation method provided by the Flutter container and pass in the engine identifier and URL in the context of the target routing stack corresponding to the Flutter local view and the identifier field of the local page;

[0150] Call the opening method of the engine corresponding to the engine identifier to notify the Flutter side to open a Flutter page.

[0151] For ease of understanding, the following is a detailed description of the push page navigation process in different scenarios:

[0152] Generally, opening a page includes but is not limited to the following 5 different scenarios:

[0153] Scenario 1: Flutter → Native;

[0154] Scenario 2: Flutter→Flutter (jump within a single container);

[0155] Scene 3, Flutter→Flutter (open a new container);

[0156] Scenario 4: Native → Flutter

[0157] Scenario 5: Native→Native.

[0158] The following is an explanation of the push (open) page from the perspective of two callers:

[0159] Angle 1: If the caller is the native side:

[0160] First, determine whether the opened page (i.e., the calling page) is a Flutter page or a native page based on the platform field.

[0161] It should be noted that in actual applications, the native side can call the method to open the page (push method) to obtain the route name of the opened page, and then check the route registry. According to the table content, it can be determined whether the page is a Flutter page or a Native page.

[0162] The Native side checks the routing table it maintains to check whether the page is registered;

[0163] If the page opened is not a page in the routing table, the process ends;

[0164] If the page being opened is a page in the routing table;

[0165] If the page being opened is a Native page registered in the routing table, it corresponds to the above scenario Native→Native;

[0166] Set the index of the opened page to 1;

[0167] Open the Native page, add the page to the Native stack, and trigger the event hook on the Native side;

[0168] Native retrieves the routing stack maintained by the Native side, performs a reverse lookup, and finds the engine identification field of the most recent Flutter page information;

[0169] If the Flutter page is not found, it means that it is not a hybrid routing stack and there is no need to notify the Flutter side;

[0170] If the Flutter page is found, get the engine corresponding to the engine ID through its engine ID field;

[0171] If the engine is not started, start the engine first, and obtain the communication channel in the callback of the successful engine start;

[0172] If the engine is started, directly obtain the communication channel of the engine;

[0173] Through the communication channel, the information of the page is passed to the corresponding engine on the Flutter side. After receiving the event, the Flutter side pushes the page information into the stack, triggers the event hook, and ends the process.

[0174] If the page being opened is a Flutter page registered in the routing table, it corresponds to the above scenario Native→Flutter;

[0175] Set the index of the opened page to 1;

[0176] Native uses the engine ID field on the Flutter page to obtain the engine corresponding to the engine ID.

[0177] If the engine is not started, start the engine first, and then get the communication channel in the callback of successful engine startup;

[0178] If the engine is started, directly obtain the communication channel of the engine;

[0179] Through this channel, the information of the page is passed to the corresponding engine on the Flutter side. After receiving the event, the Flutter side pushes the page information into the stack;

[0180] Initialize a Flutter container, open the container, render the Flutter page on the engine, trigger the event hook, and inform the Native side that the opening is successful;

[0181] After receiving the message, Native adds the page to the Native stack and triggers the event hook on the Native side to end the process.

[0182] Angular 2: If the caller Flutter side:

[0183] If the caller is on the Flutter side, the engine must be in the started state, and the platform field can be used to determine whether the opened page (calling page) is a Flutter page or a native page;

[0184] It should be noted that Flutter can check the routing registry maintained by the native side to determine whether the opened page is a Flutter page or a native page.

[0185] Obtain the routing table maintained by the Native side through the communication channel, check the routing table, and check whether the page is registered;

[0186] If the page opened is not a page in the routing table, end the process.

[0187] If the page being opened is a page in the routing table;

[0188] If the page being opened is a Native page registered in the table, it corresponds to the above scenario Flutter→Native;

[0189] Set the index of the opened page to 1;

[0190] The Flutter page obtains the engine ID of the engine, finds the corresponding communication channel, and sends the page message to the Native side;

[0191] After receiving the message, Native opens the Native page and merges it into the Native stack. Then, the Native event hook is triggered and the Flutter side is informed that the opening is successful.

[0192] After receiving the message, Flutter pushes the page into the stack and triggers the event hook on the Flutter side to end the process.

[0193] If the page being opened is a Flutter page registered in the table, obtain the routing stack on the current engine to determine whether the page is on the current engine;

[0194] If the page is from the same engine, determine whether the business side wants to use a new container to open the Flutter page.

[0195] Open with the current Flutter container:

[0196] Get the index of the current Flutter page and set the index of the opened page to index+1;

[0197] Flutter puts the page into the information stack and triggers the event hook;

[0198] Flutter obtains the communication channel of the current engine and informs the Native side that the page has been opened successfully;

[0199] After receiving the message, Native adds the page to the Native stack and triggers the event hook on the Native side to end the process.

[0200] Open with a new Flutter container:

[0201] Set the index of the opened page to 1;

[0202] Flutter puts the page into the information stack;

[0203] Initialize a Flutter container, open the container, render the Flutter page on the engine, and trigger the event hook;

[0204] Flutter obtains the communication channel of the current engine and informs the Native side that the page has been opened successfully;

[0205] After receiving the message, Native adds the page to the Native stack and triggers the event hook on the Native side to end the process.

[0206] If the page is not from the same engine, you need to open a new container to display it, that is, Flutter → Flutter (open a new container);

[0207] Set the index of the opened page to 1;

[0208] Through the two engine identifiers of the current page information and the Flutter information of the opened page, Native is informed to obtain two communication channels;

[0209] Using these two communication channels, the Flutter side uses Native as a transfer to send the opened page information to the corresponding Flutter engine;

[0210] The corresponding Flutter engine pushes the page into the stack, initializes a Flutter container, opens the container, renders the Flutter page on the engine, and triggers the event hook;

[0211] Use the communication channel to inform the Native side that the page has been opened successfully;

[0212] After receiving the message, Native adds the page to the Native stack and triggers the event hook on the Native side to end the process.

[0213] It should be noted that there is a special case where the displayed page is a Flutter partial view. The process is as follows:

[0214] Initialize a Flutter container customized by the technical framework, such as KantFlutterViewController (a customized encapsulated Flutter container), specify its size and position, and add it to the parent container;

[0215] Call a method provided by KantFlutterViewController to open a Flutter page, such as openRoute, and pass in the engine ID and URL of the Flutter partial view to be displayed and the ID field of the partial page (its value is fixed to 1);

[0216] Determine whether the engine with the corresponding engine ID has been started in the App;

[0217] If not, start the engine first, and call the push method in the callback of successful engine startup;

[0218] If it is started, call the push method directly;

[0219] The push method notifies the Flutter side to open a Flutter page, which corresponds to the above Flutter→Flutter (jump within a single container) scenario, and ends the process.

[0220] In a specific implementation of the present application, the above step S101 receives and parses the page jump request to obtain page jump requirement information, including:

[0221] Step 1: Receive a page jump request;

[0222] Step 2: If the page jump request is a page close request, the page close request is parsed to obtain page jump requirement information.

[0223] The page closing request is the request triggered / received when a page needs to be POPed (closed). The target page refers to the corresponding closed page, which can be a full-screen page or a partial view. In this embodiment, the demand information when closing does not require the caller to pass in the target page information. This is because the framework itself can know what the information of the previous page is based on the routing stack.

[0224] Please refer to Fig.18 , the target page can be a Native page or a Flutter page.

[0225] Specifically, if the target page is a Native page, the routing stack on the Native side is used to close the last routing information, and the identification field of the local page of the target routing stack context in the routing information is obtained;

[0226] Use the identification field of the local page to determine whether the current page has a nested Flutter subview;

[0227] If yes, monitor the destruction event of the Flutter container customized by the technical framework, such as KantFlutterViewController. When monitoring the destruction of the Flutter subview, retrieve the multi-engine relationship object maintained by the Flutter engine manager, obtain the engine ID corresponding to the multi-engine relationship object, and use the Native side to notify the Flutter engine corresponding to the engine ID to turn off the last corresponding routing information. The Native side uses the turned-off routing information and the second-to-last routing information as input parameters to call the event hook notification;

[0228] If not, the Native side is used to obtain the engine identifier of the last routing information, and the Flutter engine with the corresponding engine identifier is notified to turn off the last routing information corresponding to the Flutter engine. The Native side uses the turned-off routing information and the second-to-last routing information as input parameters to call the event hook notification.

[0229] If the target page is a Flutter page, use the Flutter side to close the last routing information on the current engine and obtain the identification field of the local page of the target routing stack context in the routing information;

[0230] Use the identification field of the local page to determine whether the current Flutter page is a local view;

[0231] If yes, the event notification hook is called using the engine corresponding to the routing information turned off on the Flutter side and the second-to-last routing information on the engine as input parameters;

[0232] If not, the Native side is requested to obtain the routing information of the second-to-last page on the Native side, and the Native side is notified to turn off the last routing information on the Native side. The Flutter side uses the turned-off routing information and the obtained second-to-last routing information as input parameters to call the event notification hook.

[0233] The following is a comprehensive description of the closing process of various types of target pages. Specifically, when popping the target page, the routing stack maintenance logic is as follows:

[0234] Determine the platform field of the target page to see whether it is a Native page or a Flutter page;

[0235] If it is a Native page:

[0236] The Native routing stack pops the last routing information and obtains the identification field of its local page;

[0237] Determine the identification field of the local page, that is, whether the current page has a nested Flutter subview;

[0238] If the partial page's identification field is true, then the following steps are performed:

[0239] Listen to the KantFlutterViewController destruction event. If it is destroyed, retrieve the multi-engine relationship object KantFlutterEngineContext maintained by the Flutter engine manager to obtain the engine identifiers corresponding to these KantFlutterViewControllers.

[0240] Native notifies the Flutter engines corresponding to these engine identifiers to pop (pull out) their last routing information;

[0241] Native uses the pop (pushed) routing information and the penultimate routing information as input parameters to call the event hook notification and end the process.

[0242] If the partial page's identification field is false, then the following steps are performed:

[0243] Native takes the engine ID of the last routing information;

[0244] Native notifies the Flutter engine with the corresponding engine ID to pop out its last routing information;

[0245] Native uses the pop (pushed) routing information and the penultimate routing information as input parameters to call the event hook notification and end the process.

[0246] If it is a Flutter page:

[0247] On the Flutter side, pop (push out) the last routing information on the current engine, obtain the identification field of its local page, and determine whether the current Flutter page is a local view;

[0248] If the identification field of the local page is true, the Flutter side uses the popped routing information and the second-to-last routing information on the engine as input parameters to call the event notification hook and end the process (because the Native side does not maintain Flutter's local view information, and now the popped page is a Flutter page, only the Flutter side has the routing information).

[0249] If the identification field of the local page is false, the Flutter side requests the Native side to obtain the routing information of the second-to-last page on the Native side (because the previous page may not be from this engine. In this non-local view scenario, obtaining the previous routing information from the Native side is accurate);

[0250] Flutter notifies the native side to close the last routing information on the Native side;

[0251] The Flutter side uses the popped routing information and the penultimate routing information obtained as input parameters to call the event notification hook and end the process.

[0252] After maintaining the routing stack context of the complete framework, the business side can access it as needed, and can also pop and push the stack at any time. At the same time, the framework can provide accurate page information when monitoring life cycle and routing events.

[0253] In order to help those skilled in the art to better understand the technical effects corresponding to the page navigation method provided in the embodiment of the present application, the technical effects of the page navigation method are described in detail below in combination with specific application scenarios and related technical examples.

[0254] Hybrid stack: a hybrid routing and navigation stack. When there are pages developed with more than one technology stack in the same App, a hybrid stack is needed to manage the routing and navigation of the application.

[0255] The page navigation method provided in the embodiment of the present application provides support for three common business scenarios in Flutter hybrid development:

[0256] Scenario 1: Native and Flutter full-screen pages jump to each other, forming a hybrid routing stack:

[0257] like Figure 3 As shown, Figure 3 This is a schematic diagram of a scenario in which a full-screen Flutter page is opened from a Native page in a business in an embodiment of the present application. That is, by clicking the watch record button in the Native page, a Flutter watch record list page can be opened.

[0258] Scenario 2: Opening a Flutter half-screen (partial) page in a Native page

[0259] like Figure 4 As shown, Figure 4 One of the embodiments of the present application is a schematic diagram of opening a Flutter half-screen page by clicking the icon in the upper right corner of the Native live room in the live room business.

[0260] There are also some extended usage scenarios here. For example, some Tab pages (i.e., tab pages) of the Tab module are Flutter, but the Tabbar (tab bar) and the remaining Tab pages are Native implementations.

[0261] Scenario 3: Two or more FlutterViews are held in the same Native page at the same time, and hybrid stack jumps with partial views are supported:

[0262] like Figure 5 As shown, Figure 5 This is a schematic diagram of an embodiment of the present application in which a red envelope module and a widget module are developed by two FlutterViews in a Native live broadcast room. That is, there are multiple FlutterViews in the same Native live broadcast room.

[0263] Flutter hybrid stack solutions include Xianyu's Flutter Boost and Hellobike's Flutter Thrio framework.

[0264] Flutter Boost is an open-source Flutter hybrid framework developed by the Xianyu team. It is mature, stable, and highly influential in the industry. When Flutter jumps to Flutter, it instantiates a new FlutterViewController or FlutterActivity and then uses the native navigation stack to jump, as follows Figure 6 As shown in the figure, the advantage of doing this is that users (business developers) operate the Flutter container just like operating a WebView, and the Flutter page is just like a Web page. The logic is simple and clear, and all navigation routing logic is returned to the native side for processing.

[0265] Flutter Thrio is a hybrid stack framework. Hellobike also used the Flutter Boost framework for hybrid development in the early days, but felt that Flutter Boost's capabilities were simple and its technical solutions were outdated, so it developed Flutter Thrio on its own. The core purpose is to solve the pain points of Flutter Boost and provide more abundant capabilities, including:

[0266] Reuse Flutter containers as much as possible, perfectly support Navigator, and reduce memory usage;

[0267] Support multiple engines;

[0268] The framework provides a more complete lifecycle hook and notification mechanism.

[0269] It can be found that the most important change made by Flutter Thrio compared to Flutter Boost is that in the scenario of Flutter jumping to Flutter, Thrio uses the Flutter Navigator navigation stack instead of instantiating a new Flutter container, thereby reducing memory usage. Figure 7 shown.

[0270] The problems with Flutter Boost are as follows:

[0271] The Flutter engine can only hold one Flutter container at a time. Therefore, when switching Flutter containers, the logic of the switched page will inevitably be suspended, and the Flutter logic in the App background cannot be executed. It cannot solve the scenario of multiple FlutterViews in a single page, that is, it cannot support scenario 3. No routing stack maintenance solution is provided, and only the default stack navigation provided by the system can be used.

[0272] The problems with Flutter Thrio are as follows:

[0273] Flutter Jump Flutter can only use Navigator, and does not support opening a new Flutter container, which causes the jump animation to be inconsistent with the native route, resulting in a sense of disconnection. It supports multiple engines, but does not use FlutterEngineGroup to maintain and manage multiple engines, resulting in huge memory usage. It does not support Flutter Fragment. It cannot solve the scenario of a local FlutterView in a single page, that is, it cannot support scenario 2. It does not support FlutterFragment, so it cannot support scenario 3.

[0274] In summary, the above two solutions only provide routing navigation capabilities in Flutter hybrid development, and the support for multiple engines and local views is not complete, and no sound routing stack maintenance mechanism is provided. The page navigation method provided in this application, in addition to supporting rich routing jump capabilities, is also different from the two designs and provides a set of stack maintenance solutions for hybrid routing jumps under multiple Flutter local views to solve all the defects of the above two frameworks.

[0275] Specifically, the page navigation method provided in this application has two core capabilities on the product side:

[0276] First, the framework layer provides rich routing jump capabilities:

[0277] This technical solution supports three different hybrid jump modes:

[0278] 1. When Flutter jumps to Flutter, you can use parameter control to use a new container to jump to ensure a native-level experience.

[0279] 2. When Flutter jumps to Flutter, you can use Flutter Navigator to jump through parameter control to ensure state persistence.

[0280] 3. Native to Flutter or Flutter to Flutter Flutter not only supports Flutter switching within a single engine, but also supports switching between multiple engine instances to ensure that the Flutter background remains active. (As shown below Figure 8 (shown)

[0281] 2. The framework layer supports a variety of Flutter embedding capabilities:

[0282] This technical solution supports three different Flutter embedding capabilities at the same time:

[0283] 1. Flutter is embedded in the container as a full-screen page. This is the most common scenario in Flutter hybrid development.

[0284] 2. Flutter is embedded into the native page as a single local container and is encapsulated using FlutterFragment (Android) and single-engine FlutterView (iOS).

[0285] 3. Flutter is embedded into the native page as multiple local containers.

[0286] The following is an example of the product side of the sixth capability:

[0287] Example 1: Multiple Flutter partial views as partial components:

[0288] This is the most common scenario in business (see Figure 5 The above description has been made in detail and will not be repeated here.

[0289] Example 2: Multiple Flutter partial views as Tab pages:

[0290] Please refer to Fig. 9 This is an extended application of Example 1, where Flutter View is rendered as multiple Tab pages. Because the entire TabBar component, including the three TabViews, originally belonged to the same native container, Tab2 and Tab3 are separated and rendered as Flutter Views (while TabBar is still Native). This scenario also belongs to Flutter's multiple local views capability.

[0291] However, in this case, Flutter Boost can also be used to implement it because it provides FlutterViewController and FlutterFragment. However, Flutter Boost cannot maintain the record status of multiple Flutter Tabs. For example, if the third Tab is slid halfway and switched to another Tab and then returned, Tab3 will be re-rendered and the status cannot be recorded. And the experience cannot be smooth when swiping left and right between Tabs. This is because FlutterBoost can only provide one active FlutterViewController at most at the same time. When implementing multiple Tabs, it just keeps setting which FlutterViewController is active. In addition, if the application starts with a Flutter Tab page, that is, FlutterView is the root page of the application, this capability is not supported by Flutter Boost and Thrio. That is, this application supports FlutterView as the root page of the application, and also supports multiple local views to be kept alive in the background to meet some business logic or experience requirements.

[0292] Example 3: Hybrid routing stack maintenance with multiple local views:

[0293] In addition to handling multiple Flutter Tab scenarios, it can also take into account the maintenance of routing stacks with multiple local views, and businesses can enter and exit the stack at any time.

[0294] Please refer to Fig.10 For example, if you click the watch record button in the Tab partial view, you will jump to a Flutter full-screen page. If you continue to click the avatar in the watch record page, you can jump to a Native page. Or if you click the My Wish Club button in the Tab partial view, you can jump to a Web page. Clicking a button on the Web page can jump to a Native page (which has been popped out of the stack at this time). If there is a button in that Native page, you can return to the Flutter page after clicking it (which is pushed into the stack again here). That is, the invention supports the maintenance capability of a hybrid routing stack that can be in and out of the stack at any time in multiple partial view scenarios.

[0295] The following is a detailed description of the page navigation method provided by this application from the perspective of technical implementation:

[0296] In order to facilitate the introduction of technical solutions, we first define several engines:

[0297] 1. main: the default engine provided by the framework, no registration required;

[0298] 2. module1: the engine registered additionally by the framework;

[0299] 3. module2: the engine registered additionally by the framework;

[0300] 4. Module3: The engine registered additionally by the framework;

[0301] In addition, a few more pages are agreed upon:

[0302] 1. home: Native root page, not pushed into the stack;

[0303] 1. route_pageA: Flutter page, registered by the main engine, and also registered by the module2 and module3 engines;

[0304] 2. route_pageC: Flutter page, registered by the main engine;

[0305] 3. route_pageE: Flutter page, registered by module1 engine and module3 engine;

[0306] 4. route_nativeA: Native page;

[0307] 5. route_nativeB: Native page, which contains two Flutter partial views: route_pageA (module2) and route_pageE (module3).

[0308] There are several buttons inside each of the above pages, which allow you to jump between them at will.

[0309] The following routing scenarios can be implemented:

[0310] 1. home jumps to route_pageA;

[0311] 2. route_pageA uses the new Activity to jump to route_pageC;

[0312] 3. route_pageC uses Navigator to jump to route_pageA;

[0313] 4. route_pageA jumps to route_nativeA;

[0314] Finally, the routing stacks at both ends are as follows Fig.11 shown.

[0315] It should be noted that in scenarios with multiple partial views, this solution still supports Navigator and using the new FlutterViewController to open the page, and the state of the previous page can still be retained after push.

[0316] Finally, an extremely complex routing jump scenario with a partial view is given to illustrate the maintenance strategy of the multi-engine routing stack of this application:

[0317] 1. First, push the Flutter page route_pageA;

[0318] 2. Use the new ViewController (container) to open the Flutter page route_pageC again;

[0319] 3. Then use Navigator to open the Flutter page route_pageA;

[0320] 4. Then open a native page route_nativeA;

[0321] 5. route_nativeA opens a new Flutter page route_pageE on engine module1;

[0322] 6. Then open a native page route_nativeA;

[0323] 7. Then open a native page route_nativeB. There are two Flutter partial views in route_nativeB, namely route_pageA of module2 and route_pageE of module3.

[0324] 8. Click the button in route_pageE of module3 and use Navigator to jump to route_pageA of the same engine (so this route_pageA is still a local view and will not enter the Native routing stack context according to the rules);

[0325] 9. Finally, click the button in route_pageA of module3 to jump to route_pageA of module1.

[0326] The final framework routing stack context structure is as follows Fig.12a , Figure 12b , Fig.12c and Fig.12d As shown, Figure 12b (correspond Fig.12a a) Fig.12c (correspond Fig.12a b) and Fig.12d (correspond Fig.12a c) in the figure and together form a complete routing stack.

[0327] It can be seen that the page navigation method provided in this application can provide the business with intelligent, diverse, and comprehensive Flutter hybrid routing capabilities, which can meet the business scenarios of implementing multiple Flutter partial views on the business side, and can still enter and exit the stack at any time when multiple partial views jump, maintain complete routing information, and trigger the correct event hook for flexible use by the business side.

[0328] Corresponding to the above method embodiment, the embodiment of the present application further provides a page navigation device. The page navigation device described below and the page navigation method described above can refer to each other.

[0329] See also Fig.13 As shown, the device includes the following modules:

[0330] The page jump requirement information acquisition module 101 is used to receive and parse the page jump request to obtain the page jump requirement information;

[0331] The caller determination module 102 is used to determine the caller from the Flutter side and the Native side of the routing stack framework according to the page jump requirement information; wherein both the Flutter side and the Native side expose routing stack information with the same routing stack context data structure, and each engine in the routing stack framework maintains the routing stack context on its own engine, and the Native side maintains the routing stack context of all ends in the routing stack framework;

[0332] The routing parameter determination module 103 is used to search for routing parameters corresponding to the page jump requirement information from the target routing stack context corresponding to the caller;

[0333] The page jump navigation module 104 is used to use the routing parameters to perform page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework.

[0334] The device provided by the embodiment of the present application is applied to receive and parse the page jump request to obtain page jump requirement information; according to the page jump requirement information, the caller is determined from the Flutter side and the Native side of the routing stack framework; wherein both the Flutter side and the Native side expose routing stack information with the same routing stack context data structure, and each engine in the routing stack framework maintains the routing stack context on its own engine, and the Native side maintains the routing stack context of the entire end in the routing stack framework; from the target routing stack context corresponding to the caller, the routing parameters corresponding to the page jump requirement information are searched; and the routing parameters are used to perform page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework.

[0335] In the routing stack framework, both the Flutter side and the Native side expose routing stack information with the same routing stack context data structure and have corresponding engines for maintenance. When there is a page jump navigation requirement, intelligent page jump navigation can be implemented based on the corresponding routing stack context. Specifically, after receiving and parsing the page jump request, the jump requirement information can be obtained. Then, based on the jump requirement information, the caller is clarified, and the routing parameters that match the jump requirement information are found from the target router stack context corresponding to the caller. Using the routing parameters, the corresponding Flutter side and / or Native side in the routing stack framework can implement page jump navigation that can meet the page jump requirement information. It can be seen that in this application, based on the target routing stack context, it not only has the routing navigation capability in Flutter hybrid development, but also can be supported on multiple engines and local views.

[0336] Corresponding to the above method embodiment, the embodiment of the present application further provides an electronic device. The electronic device described below and the page navigation method described above can refer to each other.

[0337] See also Fig.14 As shown, the electronic device includes:

[0338] A memory 332, for storing computer programs;

[0339] The processor 322 is used to implement the steps of the page navigation method of the above method embodiment when executing the computer program.

[0340] For details, please refer to Fig.15 , Fig.15 A specific structural diagram of an electronic device provided for this embodiment, the electronic device may have relatively large differences due to different configurations or performances, and may include one or more processors (central processing units, CPU) 322 (for example, one or more processors) and a memory 332, and the memory 332 stores one or more computer applications 342 or data 344. Among them, the memory 332 can be a temporary storage or a permanent storage. The program stored in the memory 332 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the data processing device. Furthermore, the central processing unit 322 can be configured to communicate with the memory 332 to execute a series of instruction operations in the memory 332 on the electronic device 301.

[0341] The electronic device 301 may further include one or more power supplies 326 , one or more wired or wireless network interfaces 350 , one or more input and output interfaces 358 , and / or one or more operating systems 341 .

[0342] The steps in the page navigation method described above can be implemented by the structure of an electronic device.

[0343] Corresponding to the above method embodiment, the embodiment of the present application further provides a readable storage medium. The readable storage medium described below and the page navigation method described above can refer to each other.

[0344] A readable storage medium stores a computer program, which implements the steps of the page navigation method of the above method embodiment when the computer program is executed by a processor.

[0345] The readable storage medium may specifically be a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, or other readable storage medium that can store program codes.

[0346] Those skilled in the art may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented with electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.< / kantflutterviewcontrooler>

Claims

1. A page navigation method, characterized in that: include: Receive and parse the page jump request to obtain the page jump requirement information; According to the page jump requirement information, determine the caller from the Flutter side and the Native side of the routing stack framework; wherein both the Flutter side and the Native side expose routing stack information having the same routing stack context data structure, and each engine in the routing stack framework maintains the routing stack context on its own engine, and the Native side maintains the routing stack context of all ends in the routing stack framework; Searching for routing parameters corresponding to the page jump requirement information from the target routing stack context corresponding to the caller; Using the routing parameters, page jump navigation is performed on the corresponding Flutter side and / or Native side in the routing stack framework; Among them, receiving and parsing the page jump request to obtain the page jump requirement information includes: Receiving the page jump request; If the page jump request is a page call request, the page call request is parsed to obtain the page jump requirement information; wherein the page jump requirement information includes the caller and the calling page; Among them, using the routing parameters to perform page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework includes: If the caller is the Native side and the calling page has been registered, the Native side is used in combination with the target routing stack context to execute the page opening process corresponding to the page type of the calling page; wherein, the Native side is used in combination with the target routing stack context to execute the page opening process corresponding to the page type of the calling page, including: If the page type of the calling page is a Native page, the Native side is used to set the index order in the target routing stack context to 1, open the calling page, put the calling page into the routing stack of the Native side, and trigger the event hook of the Native side.

2. The page navigation method according to claim 1, characterized in that: Also includes: In the routing stack framework, the interfaceless engine is used as a transfer station for sharing data to achieve communication between engines.

3. The page navigation method according to claim 1, characterized in that: Utilizing the Native side and combining with the target routing stack context, executing a page opening process corresponding to the page type of the calling page, including: If the page type of the calling page is a Flutter page, the Native side is used to set the index order field in the target routing stack context to 1, and the engine identification field in the target routing stack context is used to pass the page information of the calling page from the communication channel of the engine corresponding to the engine identification field to the corresponding engine on the Flutter side, so that the Flutter side puts the page information into its own routing stack, initializes a Flutter container, opens the Flutter container, renders the calling page on the corresponding engine, triggers the event hook, and sends a notification message to the Native side that the calling page has been successfully opened; After the Native side receives the notification message, the Native side is used to add the calling page to the routing stack of the Native side and trigger an event hook.

4. The page navigation method according to claim 1, characterized in that: The utilizing the routing parameters to perform page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework includes: If the caller is the Flutter side and the calling page has been registered, the Flutter side is used to execute a page opening process corresponding to the page type of the calling page; Among them, using the Flutter side, executing the page opening process corresponding to the page type of the calling page includes: If the page type of the called page is a Native page, the Flutter side is used to set the index order field in the target routing stack context to 1, obtain the engine identifier of the corresponding engine, and use the communication channel corresponding to the engine identifier to send the page message of the called page to the Native side, so that after the Native side receives the page message, the calling page is opened, and the calling page is added to the routing stack of the Native side, triggering the event hook of the Native side, and sending a notification message to the Flutter side that the called page has been successfully opened; After the Flutter side receives the notification message, the calling page is added to the routing stack of the Flutter side, and the event hook of the Flutter side is triggered.

5. The page navigation method according to claim 4, characterized in that: Using the Flutter side, executing a page opening process corresponding to the page type of the calling page includes: If the page type of the calling page is a Flutter page, using the Flutter side, determining whether the calling page corresponds to the current engine of the current Flutter page; If the calling page corresponds to the current engine, the Flutter side is used in combination with the target routing stack context to open the calling page using the current Flutter container corresponding to the current engine, or a new Flutter container is used to open the calling page; If the calling page does not correspond to the current engine, the calling page is opened using a new Flutter container by utilizing the Flutter side and combining the target routing stack context.

6. The page navigation method according to claim 4, characterized in that: Using the Flutter side, executing a page opening process corresponding to the page type of the calling page includes: If the page type of the calling page is a Flutter partial view, a Flutter container is initialized and the Flutter container is added to the parent container; Call the routing navigation method provided by the Flutter container, and pass in the engine identifier and url of the Flutter local view corresponding to the target routing stack context and the identifier field of the local page; The opening method of the engine corresponding to the engine identifier is called to notify the Flutter side to open a Flutter page.

7. The page navigation method according to claim 1 or 2, characterized in that: The receiving and parsing of the page jump request to obtain the page jump requirement information includes: Receiving the page jump request; If the page jump request is a page close request, the page close request is parsed to obtain the page jump requirement information.

8. The page navigation method according to claim 7, characterized in that: Using the routing parameters, performing page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework includes: If the target page is a Native page, the routing stack on the Native side is used to close the last routing information, and an identification field of a local page of the context of the target routing stack in the routing information is obtained; Using the identification field of the local page, determine whether the current page has a nested Flutter subview; If yes, monitor the destruction event of the Flutter container KantFlutterViewController customized by the technical framework, and when monitoring that the Flutter subview is destroyed, retrieve the multi-engine relationship object maintained by the Flutter engine manager, obtain the engine identifier corresponding to the multi-engine relationship object, and use the Native side to notify the Flutter engine corresponding to the engine identifier to turn off the last corresponding routing information. The Native side uses the turned-off routing information and the second-to-last routing information as input parameters to call the event hook notification; If not, the Native side is used to obtain the engine identifier of the last routing information, and the Flutter engine with the corresponding engine identifier is notified to turn off the last routing information corresponding to the Flutter engine. The Native side uses the turned-off routing information and the penultimate routing information as input parameters to call the event hook notification.

9. The page navigation method according to claim 7, characterized in that: Using the routing parameters, performing page jump navigation on the corresponding Flutter side and / or Native side in the routing stack framework includes: If the target page is a Flutter page, the last routing information on the current engine is turned off by using the Flutter side, and the identification field of the local page of the context of the target routing stack in the routing information is obtained; Determine whether the current Flutter page is a partial view by using the identification field of the partial page; If yes, the event notification hook is called using the engine corresponding to the routing information turned off on the Flutter side and the second-to-last routing information on the engine as input parameters; If not, the routing information of the second-to-last page on the Native side is obtained by requesting the Native side, and the Native side is notified to turn off the last routing information on the Native side. The Flutter side uses the turned-off routing information and the obtained second-to-last routing information as input parameters to call the event notification hook.

10. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the page navigation method as claimed in any one of claims 1 to 9 when executing the computer program.

11. A readable storage medium, characterized in that: The readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the page navigation method according to any one of claims 1 to 9.

Images