“How do you not have to create a property called `counter` in the State too?”
From your question, yes, my guess is you’re still on the ol’ Flutter learning curve. It’s a journey. And so, the short answer: I don’t need to, and the setState() is used by Flutter to ‘repaint’ the screen allowing you to see the counter increment.
Now for the long answer.
In your question, you have this sentence: “MVController’s`setState` which is calling MVCState’s `reState` which is calling State<>’s `setState` with the callback `counter++` but now you are in the State class which doesn’t have any property called `counter`.”
You should stop right at ‘MVController’s `setState` because that’s the rest is the MVC framework. Sure, a developer should understand how their framework works to take advantage of its features, but they should not dwell on it when creating their own app. Frameworks are tools. Like the Flutter ‘framework’, this is just another layer to help you write apps.
“And why doing all this stuff if we’re simply calling the getter con.counter in the view, as we could simply increment the counter in the Controller itself right away, right ?”
Why doing all this stuff? How does this other layer help you write apps? Because time is the enemy. It takes time to write code, and there’s no time given to you to do it. Reusable code is called for, and that’s what you’re seeing at the start of your statement, ‘…which is calling MVController’s`setState`.’
Not only this silly little example, but a huge app with dozens of developers involved, could us all the code beyond MVController’s`setState` with the very same results: faster development.
“I don’t seem to understand how this task separation is effectively working here.”
It’s effective because you can readily and quickly change out the what the property, counter, and what the function, incrementCounter, does in the app.
Yeah, with such an example, it’s a hard stretch of the imagination to see that, but that’s only due to the simplicity of the example.
MVC and other ‘frameworks’ like it, are used to take time off writing code. Three separate areas were dreamed up in the case of the MVC framework. An area for ‘Viewing the data’, an area for ‘the Source of the Data’, and area to ‘control’ how and what data is viewed and manipulated.
Remember, the View knows how to talk to the Controller, and so the View code knows the properties and the function names of the Controller. Hence, we can see the function, incrementCounter, and the property, counter, in the View code.
What’s in the function, incrementCounter? Who knows. In real-world projects, I was assigned developer for only the View part of the app. There’s someone else (or another team) assigned to the Controller part of the app.
Further, the Controller developer(s) need not know where the Model stuff comes from. The data source may change over time (there’s that four-letter word again), but the Controller simply needs to know how to talk to the Model and that’s all. Besides the other guys down the hall (we don’t like those guys) are responsible for the Model part.
“ And why doing all this stuff if we’re simply calling the getter con.counter in the view, as we could simply increment the counter in the Controller itself right away, right ?”
You could, but I don’t believe you would see the counter increment.
So how does MVC benefit the lone developer working on their little apps? It helps you when you have to go back to it months or years later (time again). You know of the three separate areas that exist. The app is broken up into separate manageable pieces, and that fact can help you run down changes or issue that much easier. That much faster. Time is the enemy.