Hey! Don’t go there!

Navigation in a mobile app is a bit more involved than pushing a route here and popping a route there. Some routes should only be viewed by a user who is authenticated while others are available to the public. Some routes will only behave and display properly if the user has an active internet connection while others show static assets that never change.

Is it possible to verify these requirements are met before loading each new route? With Route Guards, anything is possible.

Route Guards

Route Guards were first introduced in the Angular programming language as interfaces used to control the accessibility of a route based on a given condition. This Angular feature set included methods for monitoring forward and backward navigation, as well as processing the data that was sent from one route to another. As the name indicates, guards would sit between routes and determine if navigation between the two was allowed.

The problem is that Flutter doesn’t provide built-in support for guards so a lot of the navigation-validation-leg-work has to be done inside your route code. For example, you can perform a check in the initialization method of your route to determine if the route should actually be rendered. Or, you could wrap your view in a FutureBuilder and perform your check there. Either way, you would still be pushing the requested route onto your navigation stack which is not ideal.

Auto Route Guards

Luckily, the auto_route package on pub.dev exists. Aside from being a full-fledged navigation solution that makes passing arguments, naming routes, and implementing nested navigation a breeze, it offers support for route guards.

auto_route 2.4.2 — pub.dev
AutoRoute is a declarative routing solution, where everything needed for navigation is automatically generated for you.

You can read more about the actual implementation in the link above, but to summarize, you can extend the AutoRouteGuard class to perform any kind of navigation check you can think of. Each guard class can be used on as many routes as you like and to make the deal even sweeter, each route in your navigation tree can use multiple guards. Below, I’ve shared a few of the guards I’ve created.

Firebase Authentication Guard

Tweet deleted

At Protocol Authentication Guard

Tweet deleted

Connectivity Guard

Time of Day Guard

Navigate Carefully

It should be clear by now that route guarding is potentially very powerful. With a few extra lines of code you can protect user information and avoid making database calls without an internet connection. Certain checks, like checking for an authenticated user or an active network connection, are ideal because they can be made quickly without the user noticing.

That said, route guarding isn’t perfect for all situations. Because the guard logic is executed before the next route is added, you want to avoid making calls that can take a noticeable amount of time to complete…otherwise the user will experience latency. If the delay is long enough, they’ll actually be able to continue using the app between the time the navigation was requested and when it’s performed.

Support Me

If you found this newsletter helpful, consider supporting me on BMAC or GitHub! I’m aiming to send one 2–3 minute newsletter a week to help you become a better Flutter developer.

Joseph Muller is developing Flutter apps for 2021 — www.buymeacoffee.com

Coding In/Writing About Flutter Current Projects:- Stacked architecture tutorials- Att@ched app (@protocol)- Flutter Plugins

Sponsor @jtmuller5 on GitHub Sponsors · GitHub — github.com
GitHub is where people build software. More than 65 million people use GitHub to discover, fork, and contribute to over 200 million projects.