BuildContext plays an important role while developing Mobile Application using Flutter. It is used to provided reference to the location of widget inside widget tree and also being use as reference to alter UI and display many components on the screen. Among these and all other, one important part of the application where it plays a key role is to Navigate to & between screens. As being an important aspect of application, there are some places where an absence of BuildContext becomes a blocker for a developer to display, update some UI changes or move to specific screens. To tackle one of the situations of all other, is to move to specific screen without using BuildContext is explained and developed further in this article.  

First of all, let’s put some lights on NavigatorState class which provides state of Navigator widget which is used to navigate to different screens using different methods. By creating a GlobalKey of this NavigatorState class we can get the current state of Navigator and use one of the different methods to move to specific screen based on our requirements. Three things we needed to do here so we can achieve our desired tarted,  

  • Key should be accessible in our application from a generalized place. 
  • Our application should be assigned this Key under Material App widget. 
  • Build Navigation methods to move to between routes. 

For first point, a singleton class will be a best solution to manage GlobalKey and accessing same instance of class throughout the application so we can easily call different methods. So, let’s include a class in new file, name it as AppNavigator as below. 

Here, we do have a final static private parameter called _instance which will hold an instance of this class. We also have a private constructor AppNavigator._() so no instance of this class can be instantiable from outside of this class. At last, we need to define a getter which will return back an only one instance of this class when accessed. Along with these all, we also have declared a GlobalKey of type NavigatorState named navigatorKey as final inside this class. Using this navigatorKey we’ll route to different screens of our application by calling methods we’re going to declare under this singleton class. To access instance of this class we can use syntax as  AppNavigator.instance and access static parameter and methods if available from any place of our application without passing BuildContext specifically.

Fron second point, we should be assigning this navigatorKey to parameter called navigatorKey of MaterialApp widget which will be linked to Navigator of our application. This same key will be used to obtain current state and initiate different direction flows between different screens of our application. 

n above image, we can see we have defined multiple routes under MaterialApp widget where each individual one is linked to a specific screen of our application. By default, initially, screen define with AppHome() widget will be represented.  

At last, we have to define multiple routing methods which will perform below operations,  

  1. Take user from one screen to another 
  2. Take back to previous screen 
  3. Replace existing screen with another 
  4. Remove current screen from stack and add new on top of remaining (same as 3rd one but in different way) 
  5. Take back to specific screen available under stack 
  6. Remove all screens from stack and add new specific screen 

Each of these operations will be performed inside singleton class which we have defined earlier and it will make use of declared navigatorKey to perform these operations. See below.  

As we can see, all the methods are using current state of navigatorKey to perform specific operation. Only required thing is a route name where we want user to redirect to. To access these methods, we can use an instance of singleton class as AppNavigator.instance.navigateTo(RouteName).  

To showcase, usage of each method we have define routing to different screens with different approach as mentioned below with output.  

  • navigateTo – AppHome to ScreenOne, ScreenOne to ScreenTwo,  
  • goBack – ScreenTwo to ScreenOne (using button) 
  • removeUntil – from ScreenFour to ScreenOne (directly by removing all in between screens) 
  • removeAndPush – ScreenThree to ScreenFour (by replacing third screen with fourth one) 
  • replaceWith – ScreenFour to ScreenFive (same as above but direct replacement) 
  • removeAllAndNavigateTo – ScreenFive to AppHome (moving back to initial state) 

So, this is how we can move in between different screens (in other context different routes) using a GlobalKey defined for NavogatorState without depending on BuildContext. Hope this article gives a concept to our readers and we’ve many more like this in pipeline. So, stay tune for them all. 

Get a Free Quote On your Project today!

Your idea is 100% protected by our Non-Disclosure Agreement

Talk to an Expert