Routes declaration and usage in flutter

Each screen of our application is called a Route in Flutter. And the responsible to go through these screens is a Navigator.

Defining Routing at the application level

The easiest way to define navigation is by doing it at the MaterialApp declaration.

return MaterialApp(
initialRoute: '/',
routes:< String,WidgetBuilder> {
'/': (context) => new CheckLandingPage(),
'/Login': (context) => LoginPage(),
'/landingPage': (context) => LandingPage(),
},
);

As you can see, the routes  parameter defines a dictionary of String keys. Each key is the name of the path to the page in a web-ish format. Each item contain a function of  type  WidgetBuilder that receives the current context and returns the Widget to show as a page.When we want to navigate to the desired page use the below code.

              Navigator.pushNamed(context, “/landingPage”)

There is also another way of pushing into the stack without using named parameters, follow the below code
 

Navigator.of(context).push(MaterialPageRoute(
builder: (BuildContext context) =>
LandingPage()));
}

In the above code, MaterialPageRoute is used to navigate to another screen without using of named routes.

Passing parameters

If we want to pass parameters without using named parameters then data should be passed in class while pushing use MaterialPageRoute.

Navigator.of(context).push(MaterialPageRoute(
builder: (BuildContext context) =>
LandingPage(data:"hello")));

data should be initialized in LandingPage class in order to access the variable “hello”.

If we want to send parameters using named parameters then here comes “onGenerateRoute” in MaterialApp.

return MaterialApp(
debugShowCheckedModeBanner: false,
initialRoute: ‘/’,
onGenerateRoute: RouteGenerator.generateRoute
 

InitialRoute is the routing loaded when MaterialApp is instantiated.

Now, finally, we can get to the navigation. The parameter passed into the generateRoute function is of type RouteSettings. This type contains the name requested route as well as the arguments passed to that parameter call. We'll use the name to set up a switch statement that returns our home or our login based on the name.

Note: When you map a route to ‘/’ and you use a path like ‘/Login’ the Navigator will push the MyApp and then the LoginView because of the deep linking functionality. Keep that in mind when doing routing.

Update the generateRoute function with a switch statement that returns a  MaterialPageRoute for each of the views. You can use a CupertinoPageRoute as well if you're on iOS and want those default transitions.

Below is the example for RouteGenerator class :

class RouteGenerator {
static Route< dynamic >  generateRoute(RouteSettings settings) {
// Getting arguments passed in while calling
Navigator.pushNamed
final Map args = settings.arguments;
switch (settings.name) {
case '/':
return MaterialPageRoute(builder: (_) => new
CheckLandingPage());
case '/Login':
return MaterialPageRoute(
builder: (_) => LoginPage(),
);
case '/landingPage':
return MaterialPageRoute(
builder: (_) => LandingPage("data":args['data']),
);
default:return _errorRoute();
}}
static Route< dynamic > _errorRoute() {
return MaterialPageRoute(builder: (_) {
return Scaffold(
appBar: AppBar(
title: Text('Error'),
),
body: Center(
child: Text('ERROR'),
),
);
});
}
}