A Framework for Flutter Part 2

I Like Screenshots. Tap Caption For Gists.

As always, I prefer using screenshots in my articles over gists to show concepts rather than just show code. I find them easier to work with frankly. However, you can click or tap on their captions to see the code in a gist or in Github. Tap or click on the screenshots themselves to zoom in on them for a closer look.

No Moving Pictures, No Social Media

There will be gif files in this article demonstrating aspects of the topic at hand. However, it’s said viewing such gif files is not possible when reading this article on platforms like Instagram, Facebook, etc. They may come out as static pictures or simply blank placeholder boxes. Please, be aware of this and maybe read this article on medium.com

Other Stories by Greg Perry

The State Of Control

The first StatefulWidget, MyHomePage, continues to be pretty straightforward with its State object, _MyHomePageState. You’ll note I consistently keep the State classes private with the use of an underscore. It’s a good habit to get into so to keep that portion of your app out of reach of external agents. It’s important — it retains the state. Anything accessible is controlled using a predefined API (usual in the form of a series of public functions).

Not Good Practice

Below are screenshots of the StatefulWidget, Page1, again. Now, I would not have implemented the way it is myself — with the State object containing and incrementing the counter. It‘s merely done this way to demonstrate how the Controller can now call its own setState() function — outside of the State object’s build() function making for a more responsive and effective Flutter app. The second screenshot conveys what would possibly be the implementation instead — with the Controller itself responsible for incrementing the counter. Regardless, let’s get back to the examples.

State-driven vs. Control-driven

Control The State

Let’s emphasize the fact the Controller now has the State object. This once out-of-reach yet crucial element of Flutter is now readily available to you and all it provides. Not only do you have its setState() function, of course, but you now have access to some of its other important properties. See below.

page_01.dart
page_02.dart
Access to _Page2State and _Page1State

Control Properties

While we’re here, let’s present some further properties that come about with the Controller object’s access to one or more of the App’s State objects. I suspect you’ll find a use for at least two or there if not all in your Flutter apps. For instance, every Controller object has a reference to the ‘first’ State object or the ‘root state’ of the app. A reference to that object comes from the property, rootState, and calling its setState() function may be a common occurrence in your apps. Next, there is the property, lastContext. As the name implies, it’s the latest BuildContext used in the latest build() function. How many times have you needed to use one of Flutter’s Widgets but it requires a BuildContext object? Normally, that would mean you could only use such a Widget in a build() function somewhere. Well, no more. Very powerful.

Control The Data

A quick peek at the Controller class again simply called, Controller, reveals it also extends a class found in the custom framework called, ControllerMVC. This parent class gives access to a State object's capabilities and more. However, in the case of Page 2, this quick look at the Controller class also reveals the count resides in yet another class object called, Model.

controller.dart

A Controlled Response

Granted, you’ve got to use your imagination here with such a simple example app. I mean, three separate classes are involved in incrementing one simple integer value — it’s a bit of overkill. However, your apps are not going to be this simple, and this demonstrates the benefits of breaking up responsibilities of more complex tasks into these categories: A Controller responds to a button tap, for example, and a Model is responsible for storing the data that’s then manipulated. (In this case, the Model does the manipulation itself.) It’s in this way, as you see in the gif file below, the count is retained even when the app retreats back to Page 1. The controller, Controller, remains in memory — as does the count in its Model object.

State of Control

The screenshot above and below continues to be that of the screen, Page 2. We’re looking at its State object now, and again, it’s very much like that for Page 1. I wrote a special class called, BuildPage, for all three of these screens to present the same ‘look and feel’, but it’s here where you see a reference to the previous screen, Page 1. I am literally instantiating the Page 1 StatefulWidget again and calling its public function, onPressed(). See below. Being such a ‘light’ class, calling a StatefulWidget (if written properly with only immutable content) is not much of a burden to resources. After all, the widget tree is being rebuilt again and again in a typical app, and so you’re then free to call its one API — the onPressed() function.

page_02.dart
page_03.dart
page_03.dart
page_03.dart
page_03.dart
Flutter Framework Part 3

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store