Of course, I may be a little bias here, but I don’t agree with the following points.

“ To me it looks like a less flexible version of scoped_model, with more boilerplate than scoped_model.”

It’s more flexible than scoped_model from where I’m standing. There’s little boilerplate to speak of. Compared to scoped_model, this MVC pattern is a ‘kettle!’ :)

  • “The controller is bound to a single widget, and it seems like only one controller of a kind can exist at a time (static con field)”

The controller is bound to a single State object (in a StatefulWidget) is a good thing. This instills some consistency and continuity. Another developer can walk onto the project knowing that characteristic (i.e. There’s one State Object to this one Controller) instead of hunting around for all State objects that may be associated with that particular Controller. Note, however, a State object can have any number of Controllers:

i.e. (static con field, static con1 field, con2 field, con3 field)

They don’t have to be ‘con’. Name your Controllers whatever you like.(Little Boilerplate remember?).

Of course, this package is all about options, and so binding the Controller is optional as well. Binding would only be done in the first place to allow the Controller to ‘plug into’ that StatefulWidget’s lifecycle:

void initState()
void deactivate()
void dispose()
void didChangeAppLifecycleState(AppLifecycleState state) {
/// AppLifecycleState.paused (may enter the suspending state at any time)
/// AppLifecycleState.resumed
/// AppLifecycleState.inactive (may be paused at any time)
/// AppLifecycleState.suspending (Android only)
void didUpdateWidget(StatefulWidget oldWidget)
void didChangeMetrics()
void didChangeTextScaleFactor()
void didChangeLocale(Locale locale)
void didHaveMemoryPressure()
void didChangeAccessibilityFeatures()
void didChangeDependencies()
void reassemble()

An important feature, and an appropriate one for a Controller to have access to. Controllers are involved in ‘event handling’ after all. But, if you want, simply don’t ‘add’ the Controller to that State object. You can still ‘import’ that Controller into the State object’s dart file and have it do its thing. In fact, you could ‘associate’ any number of State objects to a particular Controller that way. Could get messy and hard to manage such a ‘big’ Controller, but you’ve that option.

  • “The whole widget (page) is rebuilt when the controller state changes”

Indeed, that’s Flutter?! That’s by design?! The State object can be called (by a binding Controller or not) to ‘rebuild’ its StatefulWidget and only that Widget (and its children). Again, that’s a good thing.

  • “Uses inheritance instead of composition, which is against the principles of Flutter”

I know of no such principles of Flutter. Both Inheritance and composition are utilized in the Flutter SDK as well as in this MVC design pattern.

  • “Too tightly coupled to Flutter”

Well…yeah. And that’s a good thing. But again, you can choose not to bind your Controller(s) so tightly and instead use ‘composition.’ Thus introducing your Controller to as many State objects as you want. Again I wouldn’t, but there you go.

Freelance Developer

Freelance Developer