When using GoRouter for declarative navigation, you'll often have to choose between:
- GOING to a route
- PUSHING a route
What is the difference between the two?
A thread. 🧵
To start off, let's consider a simple route hierarchy made of one top route with two sub-routes.
Let's also define 3 pages for our routes:
Now, suppose that we're in the HomeScreen.
From here, we can either call `context.go('/detail')` or `context.push('/detail')`, and end up with the same result.
That is, in both cases we'll have two routes in the navigation stack (home → detail).
From the detail page, we can now call `context.go('/modal')` or `context.push('/modal')`.
This time the result is different:
- If we use "go", we end up with the modal page on top of the *home* page
- If we use "push", we end up with the modal page on top of the *detail* page
That's because "go" jumps to the target route (/modal) by *discarding* the previous route (/detail), since /modal is *not* a sub-route of /detail.
Meanwhile, "push" always adds the target route on top of the existing one, preserving the navigation stack.
This means that once we dismiss the modal page, we navigate back to:
- the home page, if we used "go"
- the detail page, if we used "push"
Here's a short video showing this behavior:
The bottom line?
Think of `go` as a way to *jump* to a new route. This will modify the underlying navigation stack if the new route is not a sub-route of the old one.
On the other hand, `push` will always push the destination route on top of the existing navigation stack.
For more info about GoRouter, make sure to check the official documentation (it's excellent):
What are some popular architectures that are suitable for Flutter App Development (and which one to choose)?
It boils down to what level of complexity you need to handle. 👇
Thread. 🧵
(1/2) Model–view–controller (MVC) is a software design pattern made of 3 types of components:
- Model: directly manages the data, logic, and rules of the application
- View: UI components (widgets)
- Controller: Accepts input and converts it to commands for the model or view
(2/2) MVC typically overloads the model with too much logic, and an additional service layer is often added: MVC+S
The Model should be reactive (e.g. using ChangeNotifier) so that the widgets rebuild when the model changes.
Here's how to use it to hide sensitive info when the app goes to the background. 🧵
How to set it up?
- add the WidgetsBindingObserver *mixin* to one of your classes (generally a State subclass)
- register the observer inside initState (and dispose it when done)
Then, just override the methods for the changes you want to keep track of.
In this case, we listen to app lifecycle changes and update a "foreground" flag via setState().