Named routes and dynamic routes

Flutter routes are classified into named routes and dynamic routes
  • Dynamic routing is what we usually write
Navigator.push( context,
           MaterialPageRoute(builder: (context) {
              returnDetailPage(); })); },)Copy the code
  • After routing
  1. Register routing table
 routes:{
  	"detail_page":(context) = > DetailPage(),
   	"/":(context) = > MyHomePage(title: 'the app page')}Copy the code
  1. Routing hop
 Navigator.pushNamed(context, "detail_page", {Object arguments})
Copy the code

The characteristics of these two routes

  • Dynamic routing: distributed management The header file of the destination route must be imported every time a route is redirected. Advantage: The compiler can directly detect errors when the name or parameters of the destination route are changed.
  • Named route: Centralized route forward management requires only the registered key value in the routing table. Advantages: No import header file is required for route forward

In my experience, the preferred approach for development is to use named routes. Of course, there is no absolute right or wrong, after knowing the pros and cons of both, combined with their current business can make a wise choice. There is a big difference in the use of these two routes, so what is the difference in the implementation principle? To illustrate the problem, I drew a picture, as follows.

As can be seen from the figure above, in fact, the named route can find the corresponding router according to the incoming name and then call the method of dynamic routing, so there is no essential difference. The advantage of this design is that dynamic routing and named routing are compatible with each other, and this programming method is worth learning.

Problems with Navigator 1.0

The diagram above has an array of _history, which some might call a routing stack, but it’s important to note that the routing stack uses an array, not a stack, for its data structure. But _history is private and does not allow external classes to manipulate it, so if you want to manipulate _history you can only do it through push pop pushReplacement and other methods provided by the system. So the problem with 1.0 is that you can’t manipulate _history flexibly. Let’s say we have a business like this

Call up our app through a web page and then go to ScreenA -> ScreenB -> ScreenC and end up at ScreenC, but I want the user to see ScreenC directly and not see a transition from ScreenA to ScreenC. Given this business situation maybe Navigation 1.0 can also be implemented, which isto do push and then forbid the animation, it seems to be possible, but it would be more elegant if _history could be operated directly, for example we can jump in the following way

Navigator.pushNamed(context, "/ScreenA/ScreenB/ScreenC")
Copy the code

What if I also want to pass in parameters, we can write it like this

Navigator.pushNamed(context, "/ScreenA/ScreenB/ScreenC? name=zhansan&age=12")
Copy the code

Yi? That’s a familiar feeling and it looks a lot like a link on the Web side. This was not easy to achieve in 1.0, so the Flutter launched Navigator2.0

How does Navigator 2.0 address more complex business situations

How does Flutter solve this problem in Navigator 2.0? Probably the easiest way to do this isto change _history from private to public. In Navigator 2.0, Flutter solves this problem in a more subtle way. To illustrate this process, I drew the following diagram

So Navigator passes in a file calledpages, and then passes the elements in the Pages array_history.addAll()Method transformation to_history, then the developer can pass the operationpagesAnd this array will do the operation_historyThe other advantage of this design is that Navigator 2.0 is fully compatible with Navigator 1.0, because the principle is ultimately approvedpush popEtc., in fact, are operating_historyArray, which fits perfectly with the 1.0 design

Add (ScreenA) pages. Add (ScreenB) pages. Add (ScreenC) pages.

ScreenA ScreenB ScreenC can be added to _history without pushing. Now that the principles are clear, all that remains is to write the code. For the API designed in Navigator 2.0 and how to use it, go to github.com/coder-dongj… Download the code and see for yourself

Finally: the furthest distance in the world is to know and to do