I'm trying to figure out a way to implement the "expandable" behaviour illustrated in https://material.io/design/components/chips.html#input-chips.
I've dismissed using a combination of Stack+Positioned & AnimatedSwitcher, since this would require inserting the input chip at the scaffold's top level, when it's initial position should rather be determined exclusively by it's actual parent (e.g. a wrapping row). Everything else seems to contradict flutter's "overflow is evil" rule, however.
Any ideas?
I was unaware of the Overlay widget's existence and have built my implementation based on that.
Related
I'm having confusion regarding the correct implementation of MVVM architecture in a flutter.
Does MVVM require separating just the UI calls from the UI or
separating the complete logic of the widgets, even if it is to update
a CheckBox?
If using setState does not raise performance issues, should we use it when following MVVM architecture?
If it is okay to have some logic inside of widgets, to what extent
should we do that?
Yes obviously , I suggest you to study Clean Architecture, Basically concept is that, You have to create ViewModel for every screen.
Screen will contain all the Widgets (View)
View Model will contain all functionality and variable which will be hold value which used in Screen (View)
It is perfectly okay for the widget to manage its state internally. It wouldn't make sense e.g. ListView not to manage its scrolling state. The same obviously applies to custom widgets.
See Differentiate between ephemeral state and app state for more information.
In one section of a client's app an expansion panel / accordion is used to open some content. At the same time the AppBar is supposed to animated as is a new route has been pushed but the new route's content should display in the body of the expansion panel.
I have been able to implement this by creating an entirely independent Widget and using a state management library but it is not a tidy solution.
I wondered if it is possible to use the App's main Navigator but not remove the current route's body. This cannot be done with a nested navigator either as the AppBar uses Hero tags that are not reflected between Navigator's.
Is there a simple way to achieve this without using entirely customised state management.
Flutter's in built Navigator, even Navigator 2.0, is well known to not be a particularly friendly interface to use, so I'd recommend the use of a community library that makes things easier.
Auto Route is a popular solution that I use personally and can attest to its quality. For your particular problem it offers navigation observers which you can register. You could use this to trigger the animation of your app bar when the new route is pushed.
It will be a little bit of effort to replace your current navigation with a new library but I'd imagine you'll end up with a cleaner solution at the end instead of customized state management.
I'm trying to implement a breadcrumb widget in my Flutter app and I would like to achieve the following behavior:
Let's say the red outlined area is the space I have for my breadcrumb and that each element of the breadcrumb has a different width. The breadcrumb should be responsive, i.e. it should show elements as long as there is enough space to show them, otherwise, remove some of the elements and add that '...' button in the middle. Clicking on that button shows an overlay that contains the removed elements.
Now, I want to know how much space each breadcrumb element will take before it is laid out on the screen. Only then, I can decide whether there is enough space for it to be shown in the breadcrumb or it should be part of the '...' button.
I tried to use CustomMultiChildLayout which gives you information about how much space a widget takes after laying it out. It also needs to layout each child once, which makes it unuseful in my use case.
P.S: Think about the breadcrumb used in the apple documentation. That's the same behavior I want to achieve.
Short answer, you can't.
You were already using CustomMultiChildLayout, that's good, it shows me that you should have some basic understanding of how flutter rendering pipeline works. Then it should be clear to you of the 3 steps: parent passes down constraints, child reports its size, parent decides where to place the child. So in short, again, you cannot get children's size before layout.
Now move on to the thing you want to achieve. I agree CustomMultiChildLayout cannot achieve what you want to do, but not for the reason you listed. The main problem is CustomMultiChildLayout forces you to layout each child once, and then position them. You must position each child, you cannot skip a child if you don't like it (too big), and you cannot fabricate new stuff that's not your children. If you could achieve these 2 things, then getting children's size after layout isn't going to be a problem.
To achieve those, the easiest way is to use CustomPaint, if everything you need to do, are text-based or just simple shapes. Use TextPainter to layout a text, get its size, then decide whether to paint that text, or paint "..." (skip a child and fabricate your own) instead. You can search on how to do these things easily, but mostly search on TextPainter.
If you want to paint other widgets as your children, and optionally skip some of them while fabricating others, you should write your own RenderObject. That is one level lower than "widgets-level". If you have never done that before, you can research on that topic as well.
This effect
I couldn't find any ways to produce this type of home screen card slide menu effect or any combination of widgets to reproduce this, sure could use some help.
This type of custom Drawer done with Stack, AnimatedBuilder and Transform. Most difficult part there is gesture behavior, that could be copied from original Drawer flutter source code.
Marcin Szałek represented this implementation, alongside with few other features on Flutter Europe.
At this video he describes how he done it.
And this is link to his github with this feature code implemented.
I'm trying to find a way to check the visibility of a Flutter widget when it's either off screen or when it's obscured by another, for example Drawer, Dialog or BottomSheet.
visibility_detector helps with checking whether it's on the screen or not but does not work with the second use case (known limitation).
Is there a lower lever api that I can use to check whether a widget is actually visible to the user?
My use case: I'm adding a widget to the Overlay when something external happens (similar to Tooltip but not on long press). If the user opens for example the Drawer, the widget will appear on top. I want to detect that the child is not visible and delay or cancel the action.
Do I understand your problem?
You have a widget you want to always be on top?
You want the user to interact with that widget first before doing other things?
Use design patterns to make coding easier, your users will thank you.
You can show a Dialog on-top of other widgets with the showGeneralDialog or showDialog functions. Because Dialogs are a design-pattern used in many apps, users will already know how to use them.
Define app behavior with explicit state.
It is too hard to derive app behavior from rendered UI, not all devices are the same size and shape. This means you should try to write a variable that describes your situation and then write the code you need to make that variable's value correct. It sounds like you want a variable like bool overlayIsShowing.