Flutter fast navigation with Get
Different, powerful, easy!
Why different?
This is not your average navigation article
Three questions probably came to your mind when you read that title:
- With so many great articles on Flutter navigation out there, did we really need another one?
- Doesn’t this person know Navigation 2.0 is coming so will all change anyway?
- There are code generators to handle this stuff, why not use one of those?
All excellent questions, here are my answers:
- The way to do things with Get is a little different, so this article doesn’t cover the usual syntax
- Get wraps navigation in a microframework, so your code is insulated from any changes made to the underlying platform
- Get is very easy to use, with transformations, nested routes, and other very useful features built-in, so maybe that code generator isn’t needed.
Why powerful?
The introduction to the package says it all…
Get is an extra-light and powerful library for Flutter that will give you superpowers and increase your productivity.
Get can also manage navigation, state, dependency injection, present dialogs, snackbars, bottom sheets, and remove a lot of boilerplate.
Plus, Get let’s us manage our navigation from inside of a controller, model or BLoC, and remove it completely from our pages for a clear separation of responsibilities.
There’s a lot more. Here’s some background on dependency injection and other Get features to get you started.
Why so easy?
It’s all in the syntax
Get comes with two different syntaxes for navigation.
The first closely resembles standard Navigation syntax, but without context. This is great for easy conversion of an existing project, or if you want the benefits of Get navigation without deviating too far from standard code. We won’t be covering this today, but you can check out the documentation for more information
The second is far more concise and easy to read. We’ll be working with this style for the rest of the article.
Here’s what route navigation to, and from a page looks like using standard Flutter Navigation:
Navigator.push(
context,
MaterialPageRoute(builder: (context) => SecondRoute()),
);Navigator.pop(context);
And here’s the same thing with Get:
Get.to(SecondRoute());Get.back();
Spot the difference?
And it’s the same for every navigation call in Flutter, there’s always a much easier syntax in Get. We won’t go through them all, but you can find the list in the Get documentation, and the translations between normal and Get syntax is straight forward.
Another thing that makes Get so easy to use is that it doesn’t need context, so we can make our navigation calls from anywhere.
What we’ll cover
We will be working with simple examples that showcase overall patterns, rather than going through every possible scenario available.
However, if there’s a call in standard Navigation you’d like to use, you can be sure Get has an easier alternative with the same functionality.
We’re going to try out the two options for navigation in Flutter, but with our new navigation superpowers.
First, we’ll work with unnamed routes.
Second, we’ll use the same examples with named routes.
Again, I’ve assumed you understand Flutter navigation basics. Let’s start looking at code.
Unnamed routes
Unnamed routes are more convenient to use than Named routes, but navigation functionality tends to get spread throughout our App. There’s a lot less of it with Get though, so that won’t be as great a concern.
Trip to Page2
Here’s the routing to Page2 passing two parameters (message and status) using Get. As you can see, it’s familiar, but much cleaner than standard Flutter navigation.
We also added a nice rotate transition, and slowed it down to 500 milliseconds for our demo. That would normally require 50–60 lines of code per transition, or a separate package.
We’ve done route transition animations in 2 lines!!
You also may have noticed the Get.snackbar() call in that code. It’s cleaner than standard Flutter, and we didn’t require a Builder or context.
The ‘pop’ is also simple, and we pass back a nice message for Page1 to display in our snackbar.
Trip to Page3
The call to Page3 shows off another way Get can pass arguments without needing to add them to the class constructor, and Page3 has some new tricks for us.
Here’s the routing to Page3, this time passing arguments. I’ve used a string, but this could easily be a list, map, or even an object.
First, we’ll instantiate Page3Controller, then display a message from the controller in the getMessage() method call. To make this happen we used GetBuilder to manage the lifecycle of the controller. This code should look familiar if you’ve used something like Provider, but it’s substantially different in the way it works.
We can display the argument sent to Page3 using Get.arguments. You can see this in the first line after the Widget build.
When the Return button is pressed, the controller is called again, and navigates back to Page1 on behalf of the Page3. No context required!
Here’s a look at the controller. There’s an onInit() method that GetController grants us, which is run when the controller is instantiated. We can also use Get.arguments or any other Get function here, so this is brilliant for things like retrieving an initial list of data from an external source, security checks, or doing some setup work before a page is presented. You’ll be able to do a lot with this feature!
We used Get.offAll(Page1()); to return. That’s the equivalent of the following standard Flutter code:
Navigator.pushAndRemoveUntil(context,
MaterialPageRoute(builder: (BuildContext context) => Page1()), ModalRoute.withName(‘/’),
);We also could have navigated to another page, or simply used Get.back(), all without context, and all from outside of our page.
You can find a gist of the code for Unnamed routes here.
Named routes
Named routes put all route definitions in one place. However, passing parameters has traditionally been more complex as you’ll need to send them indirectly. Get has a few tricks to help us out here.
Let’s start by defining our routes. Again, it’s similar to standard Flutter, but we can also define our transitions. The Page3 definition also has a new parameter, we’ll get to that later.
Trip to Page2
Here’s the routing to Page2 with our two parameters. This time, it’s very different, but also very familiar if you’ve ever done any web development. Our parameters are embedded in the string after the question mark exactly like a web URL string. The parameters are named and separated by the ampersand.
Very, very cool.
Trip to Page3
Here’s our call to Page3. We’ve passed arguments to Page3 and Page3Controller without having to retrieve the data in initState or send it to the controller from our page! This is a fantastic way to simplify our code.
For our return, the controller uses the Get syntax:
Get.offAllNamed(‘Page1’);
You can find a gist of the code for Named routes here.
Bonus features!
Bindings
Get now fully implements a Bindings interface for:
full integration of routes, state manager and dependency manager
This will take us 3 steps:
Step 1, create our Binding class
Step 2, add the binding to the route definition — we saw that in the route definitions snip.
Step 3, remove the creation of our Page3Controller from GetBuilder as this will now be managed by Page3Binding.
So, why is it good to use bindings? To quote the Get documentation again:
When a route is removed from the Stack, all controllers, variables, and instances of objects related to it are removed from memory. If you are using streams or timers, they will be closed automatically, and you don’t have to worry about any of that.
Bindings may well become a star attraction for Get. It will be very interesting to see where creative programmers will take this functionality!
Nested Routes
Get gives us an easy way to nest routes using a unique id to identify groups of routes. Nesting is a complete topic of its own, but the code would look something like this:
So how did we do?
Was it different to normal navigation? Yes, but in a good way!
Was it powerful? Absolutely.
Was it easy? Yep, easier to read, easier to write.
Plus we got those bonus features.
Enjoy.
