refactor(gui): Enhanced navigation in preparation for Landscape config #417
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
No longer need to import directly from git Version 0.1.5 already contains the Flutter >3.13 required fixes.
Adding that page is not scope of this PR. Yet, it's due it that the routing needs to change. Having the routes defined clarifies the reasoning behind this PR.
No change in behavior so far. This adds room for more flexible and structured navigation/routing. Soon Landscape config page will demand such solution.
By calling Wizard.of(context).next() It doesn't matter anymore which destination it is.
The page calls init already. Awaiting pumpAndSettle is enough.
SubscriptionStatusPage is sensitive to the current SubscriptionInfo coming from the background agent. WizardRoute.onLoad is a natural place to get this kind of information. Everytime the wizard loads this route, a gRPC call is done to fetch the latest information. As a side effect the buildStartup local function becomes simpler.
This exception should no longer be expected.
d-loose
reviewed
Nov 22, 2023
d-loose
approved these changes
Nov 22, 2023
The builder parameter of the MaterialApp constructor does the job. There is a side effect of not creating the root Navigator. Which is good since we only rely on the Wizard now.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR looks quite silly. Adding the
wizard_routerdependency for so few routes seem overkill. But the addition of the Landscape config page along with the UI redesign foreseeable in this Figma design will require a more structured and yet flexible navigation/routing scheme.I believe
wizard_routercomes in very handy to the rescue due its declarative approach.Most of the time the app is expected to navigate from the
/startuproute straight into the last page of the wizard (the "Subscription Status" page) due the user being somehow subscribed to Pro.But when there is no active subscription information, the "Subscribe now" page must be shown instead. It allows either applying a pro token manually or acquiring one via a purchase (through MS Store). In both scenarios, there is the option of navigating to the "Config Landscape" page (not yet implemented, but shown in Figma). When either of the two possibilities of subscription (manual token applied or purchased via MS Store) is active, then the "Configure Landscape" button must be present, allowing the user to set or update the Landscape client settings. That requires being able to navigate to the Landscape config page and back.
That could be done with the plain Flutter Navigator API 1.0, but I believe the wizard allows a more declarative approach, easier to reason about, thus that's why I'm investing in it right now.
Notice that I also leverage the
WizardRoute'sonLoadcallback to fetch the latest subscription information from the background agent before showing the page that is most sensitive to that data (the "Subscription status" page). That's a natural fit in my opinion. Previously, that piece of code was mixed up with other business, which didn't feel quite right.This PR doesn't change any observable behavior, just adds room for more flexible and declarative routing.
Closes UDENG-1783