LuchoTurtle
commented
1 year ago The issue I'm having with this is because of what's asked in the UI at https://github.com/dwyl/app/issues/305. The navbar is explicitly static and persistent when transitioning between the menu and the page.
I'm keeping the code samples simple on purpose as I want to focus on the best course-of-action, not necessarily implementation details.
Way 1
My obvious first step was trying to use the drawer property in the Scaffold. It's easy and it works, we get a simple drawer with an animation.
This can be resized to fit the whole screen. The issue is that the AppBar is overridden. This is not what's asked in https://github.com/dwyl/app/issues/305 and, counter-intuitively, is not what's specified in Material Design's specification.
I tried getting drawer to just be part of the body of the page, below the AppBar. Even though this is doable, it leads to problems as it requires nested scaffolds.
See:
- https://github.com/flutter/flutter/issues/20289
- https://github.com/flutter/flutter/issues/23106
- https://github.com/flutter/flutter/issues/11350
I could alternatively just add a Padding to the drawer but the result is not the same (and also feels like a "hacky" way of resolving this issue).
Way 2
Having this problem, I tried another avenue of not using Drawer with Scaffold.
This required stepping into Animation to get the same effect as a Drawer.
Not going to go into implementations details here, but this would basically require
to have a Stack on every page, to show the menu.
body: Stack(
children: [
AnimatedBuilder(
animation: _menuSlideController,
builder: (context, child) {
return FractionalTranslation(
translation: Offset(1.0 - _menuSlideController.value, 0.0),
child: _isMenuClosed() ? const SizedBox() : const SlidingMenu(),
);
},
),
],
),This yields the following result.
It may seem the correct solution but I notice a clear performance difference when compared with the Drawer. Drawer's animation is much more fluid whilst this one "lags". You can't see in the video due to the frame-per-second I can record on my phone but this is what happens.
Way 3
To try and fix the issue of not having to use a Stack on every page, I tried to persist the AppBar between different pages by passing each page as a child to the Main widget, thus rendering each one inside the Main one.
This only works with named routes.
builder: (context, child) => HomePage(child: child),
initialRoute: '/',
routes: {
'/': (context) => HomePage(),
'/second': (context) => SecondRoute(),
},However, two problems still arise with this option:
- animation is still "laggier" than normal
Drawer. - using named routes is not recommended, as per the documentation in https://docs.flutter.dev/development/ui/navigation#using-named-routes.
- feels like a roundabout way of adding a simple menu.
As per what was discussed in standup, @nelsonic stated that using named routes should not be considered due to performance issues that may arise in the future. With option 3 (and by consequence, option 2), all it remains is option 1 (from what was attempted).
I don't know what other avenue I should try or if I should attempt to try another way, even though it feels "hacky" at this point.
If you want to give an opinion on this @nelsonic , go for it.
nelsonic
Why?
As we're building our
mvp, and doing so in Flutter, we want the onboarding experience to be as seamless and as easy as possible. This concept of Progressive UI/UX will be exemplified in this repo, where navigation will only be shown after a certain action.The navigation will open up to a full screen, where user can be shown which item to go for and redirecting to the page accordingly.
For more information about why this repo exists, please check https://github.com/dwyl/app/issues/305.