You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[flutter_adaptive_scaffold] [go_router] Please create documentation for using the AdaptiveScaffold and go_router together #129850
I would like an application with nested navigation that is responsive. See the following example:
This has proven to be exceptionally challenging, given that there is no documentation around how to use the secondaryBody, especially when given a sub-route.
Proposal
After hacking away at the problem for a while, I came up with this solution. I believe there's much room for improvement, however. I would like to see some documentation surrounding this use case, as it seems like it would be a very common way of using this widget.
I've been thinking about my implementation for a while now. There are a couple things that bother me:
Tapping on a navigation item then tapping something on the list shows the details for that item. However, navigating to a different navigation item and back loses the state of the initial route - so you'd have to navigate back to the details.
This solution uses both the AdaptiveScaffold and AdaptiveLayout. In my mind, this is excessive. I should be able to use just the AdaptiveScaffoldor the AdaptiveLayout while still maintaining state. (Much like the Cupertino widgets allow).
Let me know if I'm talking crazy talk, or if you need more information.
It's about to get worse, does anyone realize the MD3 Canonical Layouts are anti-layouts in that its the combo of Flutter Adaptive Scaffold, go router, smart Panes, and smart listDetail and smart card grids that actually form the layout but it will not have a predefined layout class??
It's about to get worse, does anyone realize the MD3 Canonical Layouts are anti-layouts in that its the combo of Flutter Adaptive Scaffold, go router, smart Panes, and smart listDetail and smart card grids that actually form the layout but it will not have a predefined layout class??
Yeah, it's quite a complicated problem. We have abandoned this design completely for now, since we couldn't figure out a good way to implement it.
But I realize that this package is still in early development, so I expect things like this to become clearer along the way.
I came up with a possible solution it involves passing the Go Route(Screen) to the every body breakpoint in the adaptive scaffold and then that screen will use layouts:
small mobile Pane that morphs to two pane
small mobile Pane that morphs to split two pane
the screen layouts will do the hasHinge unfolding and responsive stuff via LayoutBuilder.
If that does indeed work then it would seem that all the secondBody slots will be chalked up
to implement error as they would then not be needed.
And of course I should make the attempt to implement as one CanonicalLayout that
has a Boolean isTwoPane when false would then be SplitPane.
@Hannnes1 this might meet your requirements as well, what do think is the approach do-able in your view?
I came up with a possible solution it involves passing the Go Route(Screen) to the every body breakpoint in the adaptive scaffold and then that screen will use layouts:
small mobile Pane that morphs to two pane
small mobile Pane that morphs to split two pane
the screen layouts will do the hasHinge unfolding and responsive stuff via LayoutBuilder.
If that does indeed work then it would seem that all the secondBody slots will be chalked up
to implement error as they would then not be needed.
And of course I should make the attempt to implement as one CanonicalLayout that
has a Boolean isTwoPane when false would then be SplitPane.
@Hannnes1 this might meet your requirements as well, what do think is the approach do-able in your view?
I haven't had time to test it yet, but that might work
For those that cannot wait on Flutter SDK team, steps to do it:
To make second body slots work, implement
-windowsize enum
-body slot enum, note secondbody slots should only exist for expanded and higher
-buildcontext ext to determine correct window size per width
-body slot inherited widget to pass the body slot enum
*body slot childs get wrapped by inherited widget so that the screen layout is a smart canonical layout that adopts to delivering the right layout to body slot and because its the same screen for all body slots maintains the correct state...even in desktop when changing window sizes and yet delivers the right transition to foldables.
Rewrite the adaptive scaffold using the slot and adaptive layout APIs and supply the correct GoRouter object for StatefulShell Route navigation index...
@fredgrott I'm working on a series of PR's to update to the latest M3 specs and to more align with the new Compose libs for this. Could you provide feedback on those as you are deep into your research on this?
Reacted by snapsl, Maël Chiotti, Yakuran and Rares Vanca
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
hanskokx commentedon Jul 8, 2023
I've been thinking about my implementation for a while now. There are a couple things that bother me:
Tapping on a navigation item then tapping something on the list shows the details for that item. However, navigating to a different navigation item and back loses the state of the initial route - so you'd have to navigate back to the details.AdaptiveScaffoldandAdaptiveLayout. In my mind, this is excessive. I should be able to use just theAdaptiveScaffoldor theAdaptiveLayoutwhile still maintaining state. (Much like the Cupertino widgets allow).Let me know if I'm talking crazy talk, or if you need more information.
3 remaining items
hanskokx commentedon Aug 30, 2023
Yes, that's been resolved.
fredgrott commentedon Sep 18, 2023
It's about to get worse, does anyone realize the MD3 Canonical Layouts are anti-layouts in that its the combo of Flutter Adaptive Scaffold, go router, smart Panes, and smart listDetail and smart card grids that actually form the layout but it will not have a predefined layout class??
Hannnes1 commentedon Sep 19, 2023
Yeah, it's quite a complicated problem. We have abandoned this design completely for now, since we couldn't figure out a good way to implement it.
But I realize that this package is still in early development, so I expect things like this to become clearer along the way.
fredgrott commentedon Sep 21, 2023
I came up with a possible solution it involves passing the Go Route(Screen) to the every body breakpoint in the adaptive scaffold and then that screen will use layouts:
small mobile Pane that morphs to two pane
small mobile Pane that morphs to split two pane
the screen layouts will do the hasHinge unfolding and responsive stuff via LayoutBuilder.
If that does indeed work then it would seem that all the secondBody slots will be chalked up
to implement error as they would then not be needed.
And of course I should make the attempt to implement as one CanonicalLayout that
has a Boolean isTwoPane when false would then be SplitPane.
@Hannnes1 this might meet your requirements as well, what do think is the approach do-able in your view?
Hannnes1 commentedon Sep 25, 2023
I haven't had time to test it yet, but that might work
fredgrott commentedon Aug 7, 2024
For those that cannot wait on Flutter SDK team, steps to do it:
To make second body slots work, implement
-windowsize enum
-body slot enum, note secondbody slots should only exist for expanded and higher
-buildcontext ext to determine correct window size per width
-body slot inherited widget to pass the body slot enum
*body slot childs get wrapped by inherited widget so that the screen layout is a smart canonical layout that adopts to delivering the right layout to body slot and because its the same screen for all body slots maintains the correct state...even in desktop when changing window sizes and yet delivers the right transition to foldables.
Rewrite the adaptive scaffold using the slot and adaptive layout APIs and supply the correct GoRouter object for StatefulShell Route navigation index...
Last step rewrite animated indexed stack per these directions:
Animate changes to IndexedStack #48217 (comment)
That corrects several problems in the framework to make page transition animation work with indexed stacks.
Or if you do want to do that find my substack....and yes its under my nickname...
Its called lets party as we know how to support iPhone foldables before they show up in the marketplace!
martijn00 commentedon Aug 20, 2024
@fredgrott I'm working on a series of PR's to update to the latest M3 specs and to more align with the new Compose libs for this. Could you provide feedback on those as you are deep into your research on this?
martijn00 commentedon Aug 21, 2024
@fredgrott Besides the GoRouter PR i've also opened this one: flutter/packages#7428
It has the base values need to make adjustments to UI which would come in another PR.
[flutter_adaptive_scaffold] Go router sample for AdaptiveScaffold (#7452
snapsl commentedon Sep 14, 2024
The current hinge position calculation in AdaptiveLayout does not work when it is nested inside an AdaptiveScaffold.
stuartmorgan-g commentedon May 15, 2025
Closing, as this package has been discontinued.
github-actions commentedon May 29, 2025
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.