https://flutter.dev/docs/cookbook/effects/photo-filter-carousel#interactive-example
I have a question about the sample at the end of the above page.
However, the question itself has little to do with the subject matter on the above page.
ExampleInstagramFilterSelection is a subclass of StatefulWidget.
State management seems to be done with ValueNotifier + ValueListenableBuilder.
Looking at the code, I thought that ExampleInstagramFilterSelection could be a Stateless Widget, so I tried making it a Stateless Widget and tried it.
There is no particular error, and it looks exactly the same as before the change.
I can't think of the reason why ExampleInstagramFilterSelection is (a subclass of) StatefulWidget like the sample (why it's better to make it a subclass of StatefulWidget). Is there anything?
I can only think of "We might need State in the future", but then I feel like we should just make it a StatefulWidget when we need it.
You are correct, the ExampleInstagramFilterSelection in the above example could be simplified by converting it into a StatelessWidget.
As it is, there is no need to use a StatefulWidget, because the Widget does not need to redraw itself because of a changed member.
All the state handling is done in FilterSelector.
Related
I looked at Riverpod's counter example and noticed it uses ConsumerWidget instead of ConsumerStatefulWidget.
If ConsumerWidget can show state changes, is there any need to use ConsumerStatefulWidget? Why Riverpod, as a state management solution, has both stateful and stateless consumer widgets? It seems there is something I haven't yet comprehend
ConsumerStatefulWidget is here for if you want local state in your widget. Like instantiating an AnimationController
Typically providers are for shared state. But they don't deal with local state.
Hence why you still sometimes need Statefulwidgets (or flutter_hooks if that's your thing)
I'll also add that we can quickly enough replace StatefulWidget with ConsumerStatefulWidget (and State with ConsumerState) to access the ref variable throughout the widget. This is very useful when we have a previously written complex StatefulWidget widget with lots of controllers (well, just imagine!) and suddenly we need to access ref and use Riverpod to its full potential.
Then it becomes obvious and looks amazing!
Afterword: later on you will also find out that ConsumerWidget is actually a ConsumerStatefulWidget :)
In Android, every Fragment can partecipate in populating the options menu (aka "appBar actions", in flutter terms) of the activity, using the Fragment.onCreateOptionsMenu callback.
I would like a similar mechanism also in flutter, i.e. that some widgets are able to add buttons ("actions") to the AppBar.
Threads had already been opened on this topic, but none reports a fully functional example and contains solutions to the precise technical problem I encountered.
To do this, I had thought of using the following 'typical' structure:
a StatefulWidget -to which I have given name ScaffoldHandler (ScaffoldHandlerWidget/ScaffoldHandlerState)- which wraps the entire Scaffold, and which uses InheritedWidget so that widgets further down the widgets tree can get a reference to it in an optimal way (using the classic of() method which executes dependOnInheritedWidgetOfExactType()).
ScaffoldHandlerState keeps in a field the actions set by the various children, and supplies them to the app-bar.
a widget that creates the AppBar. In the build() method it gets the actions to be displayed calling ScaffoldHandlerState.of().
mixin ScaffoldChild on State, which applied to a widget gives it the ability to add actions to ScaffoldHandlerState.
Internally, ScaffoldChild executes ScaffoldHandlerState.of() in didChangeDependencies() (to add actions) and in deactivate() (to remove them).
I originally used initState() and dispose() but this did not handle the case where a ScaffoldChild changes position while not being permanently removed from the widgets tree.
The problem I encountered is that ScaffoldAppBar.build is executed before ScaffoldChild.didChangeDependencies, so when the app-bar is created, ScaffoldChild still has to put its actions in ScaffoldHandlerState.
The curious thing is that this problem is due to the simple linear order in which ScaffoldAppBar and ScaffoldChild are inserted in the page: if instead of a top app-bar I want to create a bottom app-bar, the problem is not there because ScaffoldChild.didChangeDependencies would run before ScaffoldAppBar.build.
As a workaround to overcome the problem, I have inserted in ScaffoldChild.didChangeDependencies a call to scaffoldHandler.setState scheduled by WidgetsBinding.instance.addPostFrameCallback(): thus, after the actions have been inserted in ScaffoldHandler, the app-bar is updated with the new actions.
However, this solution seems like a hack to me.
In stackoverflow I see a lot of problems solved with addPostFrameCallback + setState, and sometimes that solution avoids really understanding where it goes wrong; I am interested in understanding if there are better solutions because my purpose, as well as practical, was to better understand the lifecycle of widgets.
Is there a better solution?
This is my code:
DartPad or Gist
(I tried to shorten it as much as possible, but sorry if it's not really short)
I get the general idea that the StatefulWidget my get rebuild very often, and even get assigned to a different State if not using key in some cases. However the State of that widget always exists in memory. I need to change some data of the State when it's not shown. Is it safe to keep the reference of that State instance for example in a singleton and change its data?
Specifically, I have a StatefulWidget(call it homapage) with PageView. Its State keeps the reference of the PageController. I want to change the controller.page when the screen is showing other tabs rather than homepage. I did this via keeping a reference of the State in a singleton. In order to do it, I need to make the State class public by deleting the _ in front of the State class name. If feels unsafe and against the Flutter design philosophy to me.
The state will be destroyed when a widget that uses that state is no longer in the widget tree. We recommend that you use GlobalKey and don't use a singleton as a reference to the State. Using InheritedWidget is also a good option.
I'm building my first Flutter app, in which I need to refresh a list of data, and every component has some modifiers.
This is the basic architecture.
A big list of data (about 5000 rows) is periodically refreshed from an API inside a RefresherWidget (which is a StatefulWidget that holds the list), and then passed along to the children.
Every RowWidget has a Switch (and Dialogs too) that modifies the data it represents.
Currently, the methods to modify the list are in the RefresherWidget, so I'm passing them as callback functions inside every children until reaching the onChanged callback of the Switch.
But I don't think it's a very clean solution, and I don't know how to implement a better one: I've tried thinking about passing these methods inside an InheritedWidget that stays between RefresherWidget and ListViewWidget, and referencing them using the of function, but I don't know about the perfomance hit I would get if the InheritedWidget gets rebuild.
Also, Streams and BLoCs seem very complicated for what I need to do.
How do you guys usually approach a problem like this?
This is definitely a situation for InheritedWidget or BuildContext in general.
I've tried [...] InheritedWidget [...] but I don't know about the perfomance hit I would get if the InheritedWidget gets rebuild.
You don't have to fear anything. InheritedWidget is built for this exact purpose.
Obtaining the InheritedWidget is very performant (O(1)). And only widgets that depends on the value gets rebuilt – which is optimal too.
I'm just learning flutter - I build a few basic tutorials and am now trying to build a simple notepad application.
https://github.com/sketchbuch/examples_flutter/blob/master/notes/lib/src/components/notepad/notepad.dart
In this file I have a stateful widget which has a state property. What I don't understand is why I need the stateful widget at all... the state class seems to be doing everything including building the list of notes.
Am I doing this right? It doesn't seem right that state builds the whole stateful widget...maybe it is just because my app is basic at the moment but the stateful widget doesn't seem to do anything at the moment.
I just would have thought that the staefulwidget would handle rendering and state would just be an object storing properties
As pointless as an empty StatefulWidget subclass looks like, it is necessary. That class is what allows Flutter to manipulate the State subclass.
Without a StatefulWidget, Flutter is unable to create/update/dispose of a State.
StatefulWidget subclass is also a way to customize the behavior of State by adding fields in StatefulWidget and using them in the State class.
You're saying
My Notepad widget as such is not doing anything but my _NotepadState is. Then why should I use the redundant Notepad widget?
Why is it required?
Your Notepad widget is not alone. It has super classes. It extends StatefulWidget which in turn extends Widget (which extends DiagnosticableTree which extends Diagnosticable).
The super classes are doing all the heavy lifting for you and that you had to write almost zero code. Mostly it is used to accept parameters and create state.
Hope that helps!