This is the 24th day of my participation in the More text Challenge. For more details, see more text Challenge

preface

The previous articles have described the routing of Flutter, including using the built-in Navigator and using the Fluro routing plug-in, both of which are actually suitable for everyday development. However, if you go to the Flutter website, there’s this passage about routing:

To learn about the original (1.0) Navigation and routing mechanism, see the Navigation recipes in the Flutter cookbook and the Navigator API docs. The original navigation model uses an Imperative approach. To learn about Flutter’s updated (2.0) navigation and routing mechanism, which uses a declarative approach, See Learning Flutter’s new navigation and routing system. Note that this new mechanism isn’t a breaking change — you can continue to use the original approach if that serves you well. If you want to implement deep linking, Or take advantage of multiple navigators, check out the 2.0 version.

If you want to implement deep linking, or multi-navigator features, then you can consider 2.0 routing.

Click on that link and it won’t open (don’t think the image won’t load when you see the picture below, it’s a real picture)!

What is the routing of Flutter 2.0?

Fortunately we have a way, went in to see, a little meng, this route how many so many things, half a time will make do not understand.

In general, in order to achieve high level routing, the following things are required:

  • Page: Immutable object used to set the Navigator history stack.
  • Router: Configures the list of pages to be displayed by the navigator. Usually the page changes based on the underlying platform (what is not said about the underlying platform), or the App’s state has changed.
  • RouteInformationParser: From routing information provider (RouteInformationProviderSee,ProviderTake routing information and parse it into a user-defined data type (guess something that handles routing parameters).
  • RouterDelegate: Defines how the route is aware of the behavior of App state changes and how to respond to those behaviors. Its job is to listenRouteInformationParserAnd App state, and then build a navigator for the current list of Pages. Seeing the Delegate assume that this should be managed by the specific routing Delegate, this should be the implementor of the primary behavior of the route.
  • BackButtonDispatcher: Notifies the route of the return button click event.

I don’t know what’s going on from the description above. It’s too complicated and daunting!

The specific mechanism

Fortunately, with a picture, the relationship was finally able to manage smoothly.Here’s an example:

  1. Suppose you need to navigate to a new route, for examplebooks/2.RouteInformationParserConverts it to an abstract data type T defined in the application, such as a data type namedBooksRoutePathIn the class.
  2. RouterDelegateWill call itssetNewRoutePathMethod with this class as its argument, and the application’s state must be updated to reflect these changes (for example, Settings)selectedBooKId) and callnotifyListeners.
  3. whennotifyListenersIt tells you when it’s calledRouterThe reconstructionRouterDelegate(by calling itbuildMethods).
  4. RouterDelegate.builder()Returns a new navigator whose page reflects the changes in app state (e.gselectedBookId).

It’s a little confusing, but we’ve also introduced a custom class called BooksRoutePath, so let’s take a look at the sequence diagram.

This map will make it clearer. It is similar to the previous 1.0 route, where the route is parsed and the matching page is displayed. But this mechanism is more complex, the actual need to understand the code to realize the specific way, the next article demo.