There are many reasons for looping the login screen. But this case differs from others because of the PATH Which holds all the commands for our computer in their $path. If we do something wrong that causes us to loop the login screen. It won’t allow us to login into your computer.
Before logout from our computer, if we change the $path in the environment file, like if we removed the old PATH and added a new PATH (we accidentally removed “/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin” from ubuntu)
/bin/
Which holds commands like ls, cat, cp, etc.. (for single-user mode).
/sbin/
Which holds commands like init, ip, mount, etc.
/usr/bin/
Which holds commands that are executed by users which are not needed for booting the system. Which are not installed locally should be placed here.
These are some of the file locations, like these, we add more file locations to execute commands.
Save your path like this and restart your environment file to apply changes.
If we did something wrong in our path like saving the file in the below picture
If we restart our file using a source command like below
source /etc/environment
Now the environment file is updated and commands are not going to be executed.
To get all commands to be executed like previously we need to reset the path in the environment file.
Firstly set a temporary path so we can use commands in that terminal, once you close your terminal your path will be disabled.
export PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin”
Now open your environment file
sudo nano /etc/environment
Now set your path like this
Now save file and update file using source.
source /etc/environment
If we don’t do this and restart or shut down your pc, it will go through a continuous loop and never allow you to login to your pc.
Solution for your continuous loop is:
Press ctrl+alt+f3 in your login screen which takes to your terminal, to login to your pc terminal
After login set a temporary path so we can use commands in that terminal as i said before
export PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin”
Now open your environment file
sudo nano /etc/environment
Now after saving the file, update the file using source.
source /etc/environment
Now come out of terminal using
ctrl+Alt+f1 or ctrl+Fn+Alt+f1
(or)
ctrl+Alt+f2 or ctrl+Fn+Alt+f2
It varies based on pc’s
It returns to the login screen, and you can login to your pc as usual.
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’),
),
);
});
}
}
