Here is my architecture, I have two statfull widgets: ProfilePicture, RoundedProfilePicture. ProfilePicture is a statefull widget and it has complicated custom code which is very prone to error so I dont want to copy paste it, it utilizes variables from Picture abstract class. (ie. fetches server data and stores them inside variables of Picture). What I want to do is I want to extend from this widgets state so that I can create a new widget RoundedProfilePicture. This widgets state will basically utilize the complicated code from ProfilePicture's state with inheritance and it will add small extra logic to it. So I thought inheritance is the best choice here. Here is what I tried so far
class ProfilePictureState extends State<ProfilePicture> implements Picture{
// SOME LONG COMPLICATED 500 LINE OF CODE
}
class RoundedProfilePictureState extends ProfilePictureState {
#override
void initState() {
super.initState(); // this calls ProfilePictureState.initState() call. I want to call State<ProfilePicture>.initState()
}
}
My problem is void initState() in RoundedProfilePictureState requires me to make a super.initState() call. This call makes a ProfilePictureState.initState() call. I want to call State<ProfilePicture>.initState() because I want to add a different logic in my init state call. So the structure is:
----abstract State class
---ProfilePictureState
--RoundedProfilePictureState
How can I make a call to abstract State class's initState method from RoundedProfilePictureState? Is this possible?
Since no one answered, here is how I solved this. I think this is impossible to achieve. What I did is I moved the code and all the variables to a mixin. Took like an hour or two to do so. I achieved my needs tho.
Related
Looking through the class that defines BlocObserver, all the methods do not have any functionality defined. The BlocObserver does not inherit anything from any other class. It is only connected to the Bloc class by being created during instantiation of a Bloc.
How do the methods in BlocObserver have functionality when they are empty inside BlocObserver?
Read through the BlocObserver definition, and read through the Bloc definition.
What to do
The way you are expected to use BlocObserver is described pretty well in Core Concepts.
Basically, as BlocObserver is an abstract class, you would extend it in your own class, providing implementations for the handler methods as appropriate for your use-case.
So, roughly:
class CustomObserver extends BlocObserver {
#override
void onChange(BlocBase bloc, Change change) {
super.onChange(bloc, change);
// Perform logic based on the change
}
}
Then, you would assign an instance of this class as the static observer on Bloc, for example:
Bloc.observer = CustomObserver();
After this point, you would expect any changes that propagate through Bloc to call your CustomObserver.onChange() method.
How this works
The pattern of providing some framework object a definition of the code you'd like to run when certain events happen is a pretty common one, so it's useful to come to grips with it. Usually (and also in this case) it's way simpler than it appears.
As discussed above, you provide a BlocObserver to Bloc by setting a static member. This means both that:
you can only have one observer in the system at a time, and
any code can access it directly by calling Bloc.observer
Then, when making state changes, you ensure you do so via an instance of BlocBase (such as Cubit), which takes care of calling the appropriate method on our observer.
So, once again using Core Concepts as a base, when calling CounterCubit().increment(), the call stack looks like this:
CounterCubit.increment
CounterCubit.emit/Cubit.emit/BlocBase.emit (through inheritance)
CounterCubit.onChange
BlocBase.onChange
SimpleBlocObserver.onChange
At this point, you're back in your own code, and you can see that SimpleBlocObserver.onChange(...) calls super.onChange(...). No magic, just function calls.
New to riverpod here. (Using Flutter and hooks_riverpod, btw).
Using Hive to store related lists of items. I need to call Hive.initFlutter and wait for Hive to be initialized, and do the same to open hive boxes, once when my app loads. After that, calls to Hive are synchronous.
My original idea (though I'm open to better ideas) was to create a StateNotifier that holds both the lists. This notifier could have a setUp function that's asynchronous. Here's what that looked like, simplified:
class ItemsNotifier extends StateNotifier<ItemsState> {
ItemsNotifier() : super(ItemsState([], []));
setUp() async {
await Hive.initFlutter();
// What is ItemDao? It's a data accessor object singleton used to house Hive logic.
await ItemDao().openBoxes();
// Putting a breakpoint here, I can see by calling `ItemDao().list1` etc that the lists have loaded with items as expected, but setting state here does not trigger a rebuild of the consumer widget.
state.list1 = ItemDao().list1;
state.list2 = ItemDao().list2;
}
...getters and setters and other functions omitted...
}
final itemsProvider = StateNotifierProvider<ItemsNotifier, ItemsState>((ref) {
final notifier = ItemsNotifier();
notifier.setUp(); // I've never seen anything to suggest that calling an async setUp method here is supported, it's just something I tried.
return notifier;
});
class ItemsState {
List<Item> list1;
List<Item> list2;
ItemsState(this.list1, this.list2);
}
As mentioned in the comments, I call an async setUp method while constructing itemsProvider. I put a breakpoint inside the setup method and inside my consumer widget. First the breakpoint inside the widget catches, and we see that list1 is empty, as expected. Next the breakpoint inside the setup method catches. We see that ItemDao().list1 is full of items, so loading from Hive succeeded. So I'd expect calling state.list1 = would cause the consumer to reload as it usually does. But it doesn't. The breakpoint in the widget doesn't catch again, the widget remains empty. Probably because Riverpod isn't expecting async methods to change state from inside the StateNotifierProvider constructor.
So a simple solution to this question might just be an answer to where in the app should I call setUp()? It would need to be somewhere that only runs once when the app starts. In an initState in a stateful widget somewhere? That doesn't quite feel right... as I said, I'm new to using riverpod.
Or if you have an alternate (better) way to architect this out, that would also be helpful.
Solutions considered:
I'll note that I also tried using riverpod's FutureProvider. It works for loading the list. But, as stated in the docs, FutureProvider can't be extended as StateNotifier can, so I'm not sure where I'd put custom setters and getters. And if I wrote one FutureProvider per each list, that wouldn't handle the fact that Hive.initFlutter should only be called once. I could see a ways around this, but it's a bit clunky, and thought I would be better off if someone with more experience advised me. StreamProvider seems basically the same as FutureProvider. Maybe there's a way to compose a FutureProvider inside a StateNotifierProvider? Really not sure what that would look like.
Is it possible to extend a widget? take for instance the CalendarDatePicker widget. I like the existing features but I want to be able to extend it.
I want to be able to have a little dot under each day that has some events whether it is just one or multiple events. If a day doesn't have any events, then nothing needs to show under that day. Events would be coming from a firebase Firestore.
The reasons are:
I like the CalendarDatePicker and I prefer not having to install a new package. I see people are using Table_Calendar. It is nice but I am trying to reuse leverage what is already there and stay away from installing too many packages.
I'd prefer not to design one from scratch when there is one that already does 98% of what needs to get done.
Thanks
You can extend widgets and override its properties and methods with extends keyword (see docs). It is simple OOP inheritance. But anyway you should fully override build method to complement existing UI. Do it, copy existing code from CalendarDatePicker build method to you custom class build method and update this code as you wish:
class CustomDatePicker extends CalendarDatePicker {
const CustomDatePicker({
Key? key,
// here you can use constructor properties that you need
// and pass them to superclass constructor
}) : super(...);
#override
Widget build(BuildContext context) {
// use code from CalendarDatePicker build method
// and update it as you wish
}
}
I have a class Communicator which where I've declared a few functions. Executing those function takes some time and an update of progress is required till all the functions get executed.
Now, I am using the functions of class Communicator in my stageful widget class HomeScreen. I want to pass the progress data from Communicator to HomeScreen and update the widget regularly upon receiving the progress data. How can this be achieved?
Communicator.addSomeListener(_handleSomeEvent); in init, and Communicator.removeSomeListener(_handleSomeEvent) in dispose.
void _handleSomeEvent(SomePayload data) => setState((){});
Your singleton can keep a list of these callbacks, and call them.
One way to that using callbacks like shawnblais explained. You can also do it by state management if you like. Provider will be a good place to start.
I've been reading up a bit about coffeescript's inheritance model and I have the feeling I'm on the fringes of an ideological debate which I really don't understand. So, I would be perfectly happy to find out that I'm just doing things in the wrong way.
Basically what I am doing is writing a set of widgets which, among other things, need to handle events on their DOM elements. I thought a good way to go about this would be to have a class method which would be called once, to delegate all the events which the widget might need. The base widget class might have some simple click handlers, while the subclass might add to that some mouseover handlers or extra click handlers.
However, it appears that I'm not supposed to try and do the equivalent of calling super() inside a static method. There is a workaround which exists, (this.__super__.constructor.METHODNAME() but I've seen a lot of suggestions that this isn't the best way to do what I'm trying to do. Has anyone got any insights on how I should structure this code? Keep using the workaround, or put all the delegation into a totally different place? I can't really just stick it in the prototype, since I won't necessarily have an instance to call the method on (or can I essentially still call a method on the prototype from a static context, like putting SwatchableWidget.prototype.delegateEvents() into an onload function or something?
Here's a bit of code to illustrate what I'm talking about:
class Widget
#testProp: "ThemeWidget"
#delegateEvents: ->
console.log "delegate some generic events"
class SwatchableWidget extends Widget
#testProp2 = "SwatchWidget"
#delegateEvents: ->
console.log "delegate some specific swatchable widget events"
this.__super__.constructor.delegateEvents()
Widget.delegateEvents()
SwatchableWidget.delegateEvents()
Thanks for any help.
I suggest replacing
this.__super__.constructor.delegateEvents()
with
Widget.delegateEvents()
trying to use super to call static methods is not required (and doesn't make much sense)
I don't understand why delegateEvents would be a class-level method, or why Widget.delegateEvents have to be called again from SwatchableWidget.delegateEvents. If it's just class initialization code, you should put it in the class body directly:
class Widget
console.log "delegate some generic events"
...
#testProp: "ThemeWidget"
class SwatchableWidget extends Widget
console.log "delegate some specific swatchable widget events"
...
#testProp2 = "SwatchWidget"
I take it you're waiting for a specific DOM state before running this initialization code? Maybe I could suggest another approach if you told me a little bit more about the preconditions for delegateEvents.
It sounds like you want a different type of inheritance model where each inherited function of a certain type ("parent calling") will walk the inheritance tree and call all its parents with the same name.
You could call any direct parent functions in each child manually as you've written. Then it will float up the inheritance chain anywhere you specify such a relationship.
I would bind the parents delegate call in the constructor to a current class function
delegateparents =>
#call any parent class methods