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,
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,
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.
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.
Your idea is 100% protected by our Non-Disclosure Agreement
Businesses are forced to make compromises because of this…
When adopting AI and automation, taking the time to…
Without a strategy built by experts, your business could…
Strategically implementing AI & Automation can drive significant value,…
Data-driven businesses are not only 23 times more likely…
Our key strategies for building a profitable data ecosystem…