DEV Community: Greg Perry

From The Start

The first set of screenshots below starts with the main () function. Not a hard-and-fast rule, but you’ll notice I use ‘export files’ to keep the number of import statements used to a more manageable nmber. Instead of reams of import statements at the start of every Dart file, I followed the Dart team’s approach to organizing a library package. You can see the next two screenshots export the very files highlighted with red arrows in the first screenshot below. As a result, there’s only one import statement required for the main () function (Tap the screenshots for a closer look).

main.dart

view.dart

First Class

You can see it’s the MyApp widget that’s called in the runApp() function. That class is presented in the first screenshot below — and note only three import statements. Further down the library file, you’re introduced to the State class, _MyAppState (second screenshot below). Here, we encounter the first class from the state_extended package, AppStateX.

my_app.dart

part04_app_statex.dart.dart

A State of Control

In the second screenshot above, you can see how SOC’s are assigned to a State object. Generally, the State object worries about the interface, while those ‘State Object Controllers’ worry about everything else. In the last screenshot above, you can see that the AppStateX class even worries about Error Handling as well as activates its built-in InheritedWidget (more on that later). The AppStateX class is an extension of another class from the state_extended package called StateX.

Build Better

Of course, the AppStateX class has a build() function, but you’re discouraged from using that function in your apps — not directly anyway. However, in this example app, I’ll use it to assign boolean values to Flutter’s development tools. The first screenshot below shows you how that’s done. The video demonstrates those tools. Further note in the first screenshot, the return statement calls AppStateX’s own build() function. In turn, that eventually calls the builder() function (second screenshot) where additional ‘development tool’ values are taken in by the MaterialApp widget.

You see, you’re to ignore the build() function in a StateX object class. You would use the builder() function instead to take full advantage of StateX’s functions and features. If you do use the build() function, it’s then just like another State class.

my_app

The Three Count

The Page1 widget is presented to the user when the app starts up. The second screenshot below conveys the Controller objects instantiated for its State object, Page1State. It’s the third screenshot that displays not one but three counters——each conceived in a different way.

my_app.dart

A Separate State

In the video below, the counter is incremented three times. Note, the Text widget and the setBuilder() function will increment, but the third counter residing in a separate StatefulWidget does not. Perfectly normal.

As you know, in Flutter, a State object’s setState() function will have its build() function called again in the next frame cycle. The video above demonstrates this. The first screenshot above is the example app’s code in the builder() function that’s run again and again with every press of the button. The second screenshot above is the inner workings of the StateX object. You can see it’s there where the builder() function is called. Since the _useInherited variable is set to false, the builder() function is called every time. However, if the variable is set to true, the builder() function is not called ever again! Let’s see how that works below.

Inherited Performance

In the video below, things have changed. When you ‘turn on’ the built-in InheritedWidget (I’ll explain how that’s done shortly), the _useInherited variable is set to true in the StateX object. The first screenshot below highlights what that means.

Build Once And Forget It

The builder() function is only called once and is then wrapped in the built-in InheritedWidget. That means that Text widget will never be called and rebuilt again — it doesn’t increment with every push of the button anymore. You see, the whole screen is no longer rebuilt again and again. Do you follow? However, the other two counters do increment. That’s because they are both dependencies of the StateX object’s built-in InheritedWidget. Only those widgets are rebuilt in the interface making for better performance. This is nothing new in Flutter.

In the second screenshot below, we see the setBuilder() function is very much like the Builder widget supplies a BuildContext parameter and returns a widget. This function is from the Mixin found in the state_extended package called InheritedWidgetStateMixin. We’ve been looking at its inner workings for some time now with its buildF() function (first screenshot below), but now we’ll examine its setBuilder() function.

part04_app_statex.dart

In the second screenshot above, we’re presented with the setBuilder() function. Now you see why the counter is incremented whether the useInherited getter returns true or false — the builder() function is called in either case. Looking at the third screenshot, if set to true, the builder() function is wrapped in the StatelessWidget, StateDependentWidget. It is that widget that becomes a ‘dependent’ of the built-in InheritedWidget using the line:

stateMixin?.dependOnInheritedWidget(context)

I’d say the most powerful feature of Flutter’s InheritedWidget is that whenever it’s called again, its dependency widgets will be rebuilt (their build() functions called again). Nothing new here. It’s all Flutter.

The third and final counter is also incremented. As you see in the first screenshot below, it’s the one encased in a StatefulWidget. Its State object is made an dependent on Page1State’s built-in InheritedWidget as well. In the third screenshot, it’s the Controller object’s buildThisState() function that assigns this dependency.

Less Is More

Let’s look at another example. Viewing the video below, know it is only the red ‘word pairs’ being rebuilt in set intervals — it’s the only portion of the screen changing every few seconds. That is the only portion of the screen being repainted. The rest of the screen is left untouched. The less the Widget tree is rebuilt, the better the overall performance. In the screenshot below, you see it's the getter, wordPair, that supplies these word-pairs. I’ll show how this works next.

In the first screenshot below, the getter uses the SetBuilder widget. This widget is also from the state_extended package. It involves the App State object’s dataObj property. It’s of type object, and so you can pass ‘anything’ down the Widget tree. In the case of this example app, it’s a String object that is passed down. See the second screenshot below.

my_app.dart

The SetBuilder widget rebuilds when that String object changes in value. In the first screenshot below, that occurs when a new word-pair is assigned. Finally, the setter, dataObject, calls the AppStateX’s InheritedWidget with the notifyClients () function. Doing so, will rebuild any and all SetBuilder widgets — in fact, any widget set as a dependency to the AppStateX’s InheritedWidget. Makes for an efficient interface.

part17_app_state_mixin.dart

Note The Change

Finally, the video below demonstrates what happens with the three counters when selecting the Switch, ‘Use built-in ChangNotifier.’ All three counters now increment. It’s easy enough to understand the first two. We’ve returned to rebuilding the whole interface again. Both the Text widget and setBuilder() function will rebuild, but why would the third counter in its separate StatefulWidget? It shouldn’t increment — it’s no longer dependent on an InheritedWidget?! That’s because it’s become a Listener. State Object Controllers have a built-in ChangeNotifier.

part12_rebuild_controller_states_mixin.dart

In the first screenshot above, you can see the Controller’s buildThisState() function will also include Page1’s State object as a ‘State Listener’ if the variable, useChangeNotifier, is set to true. That’s exactly what happens in the video above.

rebuild = addStateListener(state);

In the second screenshot above, you can see the State object’s setState() function is called when that Listener is notified. They’re notified through the Controller which had added them. This is done in the Controller’s version of the setState() function. Note, in the first screenshot below, its setState() function also includes notifying any Listeners:

notifyListeners();

The next two screenshots trace back to Flutter’s own ChangeNotifierclass calling its notifyListeners() function and ‘rebuilding’ any and all State objects assigned. See how that works? Just another way of accessing and rebuilding dispersed and remote State objects — via a State Object Controller.

part02_statex_controller.dart

part12_rebuild_controller_states_mixin.dart

It’s a Do-over

To activate its built-in InheritedWidget, a StateX object must be instantiated with the formal parameter, useInherited, set to true. Notice in the video below, there’s a distinct ‘refresh’ of the screen when the Switch, Use built-in InheritedWidget, is tapped on. That’s because the App’s whole interface is rebuilt again. Note, it’s also rebuilt again with every change of those Development tools settings introduced earlier. The App’s interface is rebuilt when demonstrating much of this example app’s functionality. That means the MaterialApp widget in this example app is being called again and again (see the second screenshot below). Let’s how that’s done.

my_app.dart

In the first screenshot below, selecting the Switch calls the Controller’s method, onChangedInherited(). Two things need to happen to then activate the StateX object’s built-in InheritedWidget: the whole app interface must be rebuilt and that particular StateX object must be recreated.

A New State

In Flutter, State objects are recreated when their Statefulwidget is assigned a ‘new’ Key value. In the second screenshot above, that’s accomplished with the line, page1Key = null;. Again, nothing new here. This is how Flutter works. The second thing to do is simply rebuild the App’s State object:

appState?.setState((){});

Every Controller has a reference for the App’s State object. In the first screenshot below, we see the App’s State object’s builder() function called again. Again, changing any Development tool settings introduced earlier requires the line, appState?.setState((){});.

my_app.dart

In the second screenshot above is the StatefulWidget, Page1. Note, if not explicitly provided one, its Key value is supplied by the screen’s Controller, Controller().page1Key. Remember, however, it was set to null with a tap of a Switch. This means the Key value stored in the class property, _page1Key, has now changed to a completely new value. In Flutter, this causes the State object to be recreated. Being recreated, the value passed to this new State object is now set to true: Controller().useInherited

Keep Control

If you haven’t noticed by now, each State Object Controller class in the example app uses a factory constructor to instantiate only one instance of each class. Three of those classes are conveyed in the screenshots below.

Again, not a hard-and-fast rule, but I’ve found keeping only one instance of the State Object Controllers has proven well-suited for their role: A class object representing the ‘ongoing state’ of the app in a singular instance. An example of this, of course, is the running count that’s displayed. Its ‘interface settings’ is also maintained by a Controller. Further advantages in using this Singleton Pattern will be explained shortly.

example_app_controller.dart

Keep Count

Since it’s a complete recreation of the State object and its counter property, count, we will have to save the count before the switch. Of course, the Controller object will take care of all of this. In the first screenshot below, using its stateInit(State state) function, a controller can determine the StateX object it’s currently working with, and in this case, supply the count to the new screen. Otherwise, after the switch, you would just see zeros. Makes sense?

Make A New Start

Note, the video below further demonstrates this ‘rebuilding of the App’ with the line, appState?.setState((){});.In the video, you see the ‘debug banner’ is turned off and then changing the app’s whole theme from Material3 to Material2. Both required a new call to the App’s MaterialApp widget.

Learn by Example

This is a ‘demonstration’ app as well. And so, as you see in the second screenshot above, the Page1 State object’s initState () function has many examples of how this state_extended package empowers you to make versatile and adaptive code by giving you more than one way to retrieve a State object that makes up your App from anywhere at anytime.

A Singular Approach

By the way, another reason for the Singleton Pattern used by instantiating all the State Object Controllers with a factory constructor is to take advantage of the versability and readability that’s achieved. You can then make any number of construction calls necessary to perform specific tasks throughout the app. An example of this is next.

It’s All Timing

As you many know, it was the WordPairsTimer controller that was providing those red ‘word pairs’ at set intervals using its getter, wordPair. In the first screenshot below, you see this controller follows the Singleton pattern. In the second screenshot below, it’s instantiated as one of the controllers to work with the first screen, Page1State, displaying the word-pairs.

However, this App has a Drawer widget, and whenever it opens, I want to turn off the Timer that’s changing the word-pairs every 5 seconds. The ‘easiest’ means to do this is presented in the third screenshot below — just call the constructor again. The Singleton pattern approach makes this possible.

my_app.dart

Adaptive Abstraction

Those construction calls for the WordPairsTimer controller right there in the first page was more for the benefit of the reader. In truth, I would normally only reference the State object’s controller, con, throughout that interface. This would then incorporate a layer of abstraction to the app. You can see an example of this in the first screenshot below. The interface has no business knowing there’s a word-pair timer running somewhere, and is turned off just before the Drawer is opened. See what I changed I made in the first screenshot below to achieve this.

my_app.dart

example_app_controller.dart

The second screenshot above is of the App’s State object controller, ExampleAppController. You see the new onOpenDrawer() and onCloseDrawer() functions. They, in turn, call their counterparts found in the Controller class. Finally, we see those functions, in the third screenshot above, calling the original methods found in the WordPairsTimer controller. See how that works?

Unknown Potential

Back on the interface side, there’s no hint of what’s going on when the Drawer callback functions fire (see first screenshot below). The WordPair Timer process could be modified down the road or removed outright without changing one bit of the interface. It’s the use of these State Object Controllers that provides this layer of abstraction and makes your code that much more adaptive and its maintenance that much easier.

The Many Constructs

The second screenshot below conveys another example of using multiple constructor calls from the same class. We’re back setting the built-in InheritedWidget on or off with the controller property, useInherited, for the Page 1 screen. Note the readability. Flutter doesn’t allow dynamic instance variables in the class. The initializer list can only initialize instance variables before the constructor body runs. and so this a more.

my_app.dart

Handle Your Errors

You hope for no errors in your app. However, your app will error. You have to prepare for this fact. The StateX package allows you to prepare for this fact whether they're unexpected errors or anticipated errors at times. Maybe there’s a case where intermittent errors are known to occur in your app — a network drop is known to occur, for example. In certain cases, a process is known to fail. This package gives the means to acknowledge such errors and shut down gracefully if not actually overcome the error and continue running.

As an example, in the video below, the app intentionally throws an anticipated error with every push of the counter button (see screenshot below). This example app logs many of the events that occur while running, and you can see the error is recognized in the second screenshot. An onError() method fires in a series of State objects all the way back to the App’s State object, _MyAppState. One of those methods actually recovers from this Exception by incrementing the count regardless.

In truth, it is the App’s State object, _MyAppState, that catches the error. It then begins a series of onError() function calls. It first calls the State object where the error likely originated. When such a State object is found, its Controllers’ onError() methods are called first before calling its onError() method. It is the App’s State object that finally records and logs the error.

Back to our example, the third screenshot below highlights when an onError() method in one of the Controllers recognizes the error and increments the counter regardless. A very simple example, but you get the idea.

part04_app_statex.dart

A Better View

This is not a built-in feature of the state_extended package, but a further demonstration of how to seamlessly implement a feature using a State Object Controller. Instead of the ‘Red Screen of Doom’ that comes with errors while developing in Flutter, how about a more useful, more pleasant-looking error screen? The BuildErrorWidget class integrates such a screen by merely introducing it as a controller to the App’s State object. In the video below, the class allows you to control its use and returns to the original error screen when appropriate while developing, while testing, and while running in production.

The video below demonstrates this with an error explitcity thrown when going to Page 2 in the example app. You’re able to manually ‘trip errors’ in this example app to demonstrate this package’s error handling. In the video, you see the traditional ‘Red Screen of Doom.’ However, when the ‘Custom Error Screen’ is switched on, the BuildErrorWidget class will assign a custom builder to Flutter’s ErrorWidget.builder callback. Now, when such an error occurs, a more helpful error screen is displayed when the intended widget fails to build. Very nice.

my_app.dart

build_error_widget.dart

Trouble From The Start

The video below throws an error right at the start of the app — in the AppStateX’s initAsync() function. It’s usually at startup when things have trouble — more of an effort may be needed to start successfully. In the video, the example app starts up without incident. However, the app is repeatedly restarted with specific settings switched on to show what the package can do for you if and when your app encounters an error right at startup.

The ‘Error initAsync() at Startup’ switch is first turned on. When the app starts up again, you are greeted by the good ol’ ‘Red Screen of Boom!’ Nothing left for you to do but try the app again. Happily, you’re able to get into the app again because it actually ‘recovers’ this time. A snackbar appears with the message, ‘An error at startup, but was caught.’ Going back to the Settings screen, you’ll notice the ‘Catch Error’ option is set, Yes. However, in the video, it is set back to ‘No’ so to again demonstrate the custom error screen with another restart. Again, you can’t continue as the app has once again failed at startup, and you’re presented with an error screen. That’s ok. That’s because the app will catch the error the next time it starts up. The error is overcome once again. Let’s see how.

This video emulates, for example, when the network is down at startup or when it fails to access some critical web service at startup. The app can’t continue — unless it can. That’s where the catchAsyncError() function comes in (see the second screenshot below). The catchAsyncError() function below looks out for an error message containing the string, ‘Error in App’s initAsync()!’ It then acts accordingly. If this function returns false, the error is not successfully caught, it has failed to recover, and so an error screen is presented. Note, when not caught, the property, catchInitAppAsyncError, is set to true for next time. Otherwise, the app will never start up successfully. Smart thinking.

part05_futurebuilder_state_mixin.dart

example_app_conroller.dart

The first screenshot is of state_extended package itself. It’s a snapshot of the build() function called by the StateX class. Highlighted is the catchAsyncError() function call. Your initAsync() function has thrown an error, but you’re given an opportunity to possibly recover from the error with the catchAsyncError() function.

Of course, always returning true and freely ignoring errors would not be advisable. Such decisions will very likely only make your App fail further. It’s for those exceptions where a recovery may be possible or, at the very least, an opportunity to clean up resources and prevent any data corruption before bringing the crash to a ‘soft landing’ and have the app fail gracefully.

To Catch An Error

In the next video below, you have the means to throw an error when attempting to open Page 2 in the example app. Again, the custom error screen is first demonstrated. However, it’s the ‘Catch Error’ option that’s of interest here. When that is switched on, the catchAyncError() function in the second screenshot below will ‘catch’ the error and return true.

another_controller.dart

To Err Is Programming

This example app has throw statements throughout its code. Again, this is to demonstrate this package’s ability to effectively handle errors. Another example is when the ‘Error in Builder’ is switched on. The first screenshot below shows an Exception being thrown. This simulates a Widget failing to be created in a build() function.

page_02.dart

build_error_widget.dart

To Build Or Not To Build

As you know now, any Asynchronous operations that may fail in the initAsync() function may be caught by the catchAsyncError() function. However, an error in a build() function can not be explicitly caught. No, if your build() function fails, it’s an error that should *not* happen in production. It’s an error, it will be recorded and logged, but it is not recoverable. Of course, it’s your app, you can address such errors right in your build() function and maybe even recover from it yourself — there’s just no ready means in the StateX class.

Quick Reference

StateX Class

.appStateX → Retrieves the App's appStateX object. Returns null if not available.StateX

.controller → Retrieves the State object's 'current' Controller.StateX

.deactivated → True if deactivated() was called.StateX

.disposed → True if disposed() was called.StateX

.firstBuild → True if build() not called or called once.StateX

.hiddenAppLifecycle → True if State object was in a 'hidden' state.StateX

.identifier → Unique Srtring identifier foe this StsteX object.StateX

.inactiveAppLifecycle → True if the State object was in an inactive state.StateX

.isLastState → True if it's the 'latest' StateX object created in the app.StateX

.lastSystemEvent → Records the last system event called.StateX

didChangeAccessibilityFeatures
didChangeLocales
didChangeMetrics
didChangePlatformBrrightness
didChangeTextScalFactor
didHaveMemoryPressuure
didRequestAppExit

.pausedAppLifecycle → True if State object was in a paused state.StateX

.resumedAppLifecycle → True if State object was in a resumed state.StateX

add() → Add a Controller to this StateX object.StateX

addAll() → Add a list of Controllers to be associated with this StateX object.StateX

stateByType() → Retrieves another State object by its type. Returns null if not found.StateX

stateById () → Retrieve another State object using its unique String identifier. Returns null if not found.StateX

controllerByType () → Retrieves one of its Controllers by their type.StateX

controllerById () → Retrieves one of its Controllers by their unique String identifier.StateX

StateXController Class

.state → Returns current State object.StateXController

.statex → Retrieves current StateX object.StateXController

.appStateX → References the App's State object.StateXController

.initStateCalled→ True if initState() was already called.StateXController

activateState () → Called when this State object is reinserted into the Widget tree after having been removed by deactivate().StateXController

addState () → Associate this Controller to the specified State object. Returns the State Object's unique String identifier.StateXController

deactivateState () → Called whenever the State object was removed from the Widget tree. Passes the 'current' State object parameter.StateXController

disposeState (covariant State state) → The supplied State object will never build again and taken into Flutter's garbage collection.StateXController

initAsyncState (covariant State state) → Called with every StateX associated qith this Controller initializing any 'time-consuming' operations needed done at startup.StateXController

ofState )() → Retrieves a currently associated State object by its type T. Returns null if not found.StateXController

stateOf () → Retrieves an associated State object by its StatefulWidget. Returns null if not found.StateXController

Initialization Handlers

initAsync () → Initialize any 'time-consuming' operations at the beginning. Implement any asynchronous operations needed done at start up.StateX|StateXController

initAsyncState () → Called with every StateX associated with this Controller Initialize any 'time-consuming' operations at the beginning. Implement any asynchronous operations needed done at start up.StateX|StateXController

initState () → Initialize anything necessary at the beginning. Implement any asynchronous operations needed done at start up.StateX|StateXController

runInitAsync () → Call initAsync() all the time if returns true. Conditional calls initAsync() creating a Future with every rebuildStateX|StateXController

Event Handling

activate () → Called when the State object is reinserted into the Widget tree.StateX|StateXController

deactivate () → Called when the State object is removed from the Widget tree.StateX|StateXController

dependOnInheritedWidget () → Link a widget to the StateX Object's InheritedWidget.StateX|StateXController

detachedAppLifecycleState () → The Flutter engine has detached the app from view and is shutting down.StateX|StateXController

didChangeAccessibilityFeatures () → Called when the current accessibility features have been changed.StateX|StateXController

didChangeDependencies () → Called immediately after initState() or when a widget dependent on an InheritedWidget is to be rebuilt.StateX|StateXController

didChangeLocales () → Called when the device's locale has changed.StateX|StateXController

didChangeMetrics () → Called when the app's UI dimensions change. E.g. when a phone is rotated.StateX|StateXController

didChangePlatformBrightness () → When the device's brightness has changed.StateX|StateXController

didChangeTextScaleFactor () → Called when the platform's text scale changes.StateX|StateXController

didHaveMemoryPressure () → Called when the system is running low on memory.StateX|StateXController

didPop () → Called when this State is popped off a route.StateX|StateXController

didPopNext () → The top route has been popped off returning this State object.StateX|StateXController

didPopRoute () → Called when the app pops the current route. E.g. On Android, called when the back button is presse.StateX|StateXController

didPush () → Called when this State is first pushed as a Route by a Navigator.StateX|StateXController

didPushNext () → New route has been pushed, and this State object's route is no longer current.StateX|StateXController

didPushRouteInformation () → Called when the application pushes a new RouteInformation and a restoration state onto the router.StateX|StateXController

didRequestAppExit () → Called when a request is received from the system to exit the app. Exiting the app can proceed with [AppExitResponse.exit] response, and do not exit with [AppExitResponse.cancel] response.StateX|StateXController

didUpdateWidget () → Called when the State object's StatefulWidget is recreated.StateX|StateXController

dispose () → Called when the [StateX] object will never build again and will be taken into Flutter's garbage collection.StateX|StateXController

handleCancelBackGesture () → Called when a predictive back gesture is canceled indicating that no navigation should occur.StateX|StateXController

handleCommitBackGesture () → Called when a predictive back gesture is finished successfully indicating that the current route should be popped.StateX|StateXController

hiddenAppLifecycleState () → The app is about to be paused (on iOS and Android), or has been minimized (Windows) or is no longer visible (on the web).StateX|StateXController

inactiveAppLifecycleState () → The app is in an inactive state and is not receiving user input.StateX|StateXController

pausedAppLifecycleState () → The application is not currently visible to the user, not responding to user input, and running in the background.StateX|StateXController

reassemble () → Called when the app is reassembled during development, E.g. A hot reload.StateX|StateXController

resumedAppLifecycleState () → The app has returned from the background. Is now visible and ready for user input.StateX|StateXController

setState () → Call build() function of the State object in the next frame cycle.StateX|StateXController

updateShouldNotify () → As a dependency of an InheritedWidget, return true to rebuild the State object.StateX|StateXController

Error Handler

onError () → Offer an error handlerStateX|StateXController

onAsyncError () → In case the initAsync() function has failed in error. This must be handled too. StateX|StateXController

catchAsyncError () → Catch it if initAsync () throws an error. Return true to indicate the error handled. Return false to continue the error handling StateX|StateXController

Next article will cover the following topics:

Event Handling

Remember, if not addressed, the example app's Timer will always be running taking up valuable CPU cycles even when those red Wordpairs are no longer in view. There are event handlers available to the StateX class to address such considerations. The screenshots below and see the Timer is actually terminated when moving off Page 1. Nice.
The didPushNext() method is called when the 'next route' is pushed from this current State object. Note, the _cancelTimer() is called terminating the Timer before the Page 2 screen is displayed. Also, if there's an error, you can see the Timer is terminated in the onError() method. Very nice.

→ Other Articles by Greg Perry

pat01_statex.dart

part01_statex.dart

Testing Your App

If I were you, a great way to get to know StateX would be to step through its accompanying test files that run whenever a new version of its package is pushed up to its GitHub repository.

The screenshots below will give you an idea what will be covered in the nextt article.

test_widget.dart

intergration_testing.dart

Unit Testing

test_app_state.dart

test_statex.dart

test_statexcontroller.dart

test_run_mixins.dart

test_event_handling.dart

reset_page1_count.dart

You Can’t Have It All!

Greg Perry — Thu, 10 Apr 2025 14:48:19 +0000

…or can you?

The last article, It’s Not Flutter, brought a surge of downloads for my Fluttery Framework package. I received some great feedback, and have since then tightened up the code. It does what I always wanted Flutter itself to do:

Run one codebase on more than one platform.

After all, that was Flutter‘s mantra when it first came out, right? Flutter will run your app on your iPhone, on your Android, on the Web, on Windows, and on the Mac, etc — with only one codebase. However, I realized it doesn’t. Not with ease anyway. For me, it needed a few more ‘build’ functions:

build(); You already know this function. It comes with Flutter.
buildAndroid(); Returns a Widget for the Material interface.
buildiOS(); Returns a Widget for the Cupertino interface.
builder(); Runs the desired widget: CupertinoApp or MaterialApp.

Table Of Contents
Multiplatform
· It Can Do It All
· Choice By Design
· Change Face
Time to Initialize
· Startup Time
· Takes Time
Event Handling
· The Events That Take Place
· In The Beginning
· The Route Taken
· Page 1 and 2
· Pop Back
· It’s All Flutter
· To Dispose Of
· Play Well With Others
· Separate Lifecycles
Real-World Example
· Timing is Everything
· Sequence of Events
· It Is Eventful
· The Tree Is Key
· Dispose Disposable?
Error Handling
· The State of Error
· Push for Exception
· It Takes Two
· Counter The Exception
· My Bad
· To The Top
· Other Handlers
· Stops And Starts
· A Bad Build
· Seeing Red Not
· It’s A Little More

What’s in it for me?

What’s in it for me?, you ask. There are a lot ‘State Management’ solutions out there, but what about other capabilities allowing for rapid development and for a reliable deliverable? For a production-worthy, cross-platform app, you also want the following:

Multiplatform, Time to Initialize, Event Handling, and Error Handling

Multiplatform

It Can Do It All

After installing Fluttery, go to the pub.dev directory on your machine and seek out its example folder for an extensive example app. Run this example app on any device you want. It can do it all.

Choice By Design

In Fluttery, every State object offers two additional ‘build’ functions: buildAndroid(); and buildiOS(); The first is for the Material interface design, and the second is for the Cupertino interface design. For example, implement both these functions, and your mobile app will look good on an Android device and on an iPhone. Depending on the platform it’s running on, your app will start with either the CupertinoApp widget, or it will start with the MaterialApp widget.

Frankly, it’ll start up any interface design you choose. You’re free to use a third-party design as well (eg. fluent_ui) using yet another ‘build’ function, buildApp(). See below:

Change Face

In the video below, the example app is switching between the Material interface and Cupertino interface with just a tap—this merely demonstrates how Fluttery will readily run on any accepted platform. The Counter page displayed extends from the class, StateX. It is that class displayed in the first screenshot below. You can see the extra build() functions mentioned above. The example app even switches between version 1 and version 2 of the Material design.

The second screenshot above is the builder() function for the App’s main State object (AppStateX). It is this function that is called again and again when switching between interfaces. It runs either the CupertinoApp widget or the MaterialApp widget — but only if a null comes from the function, buildApp(). See how that works? Let Fluttery worry about all this for you.

Time to Initialize

Startup Time

When I first began working in Flutter, I saw many developers ‘initializing’ their app’s particular functions and features before the function, runApp(), is even called. These were operations that had to be completed or at least initialized before the app even displays its first screen.

Fluttery gives the State class an additional function called, initAsync(), to initialize such features. Think of it as an initState() function for asynchronous operations. Any such operations will be completed before the State object proceeds (using a FutureBuilder). The video below demonstrates this. See the ‘spinner’ going around and around in the center of the screen at startup? That could be any intense operation (eg. opening databases, accessing web services, etc.). Any operation that must be completed before the app can present the demo app. If you like, instead of a spinner, you can display a fanciful startup screen to keep your users entertained while they wait. Let Fluttery worry about all this for you.

Takes Time

The first screenshot above reveals that this app is not opening a database at startup. It’s simply counting to 10 before proceeding — but you get the idea. However, further into the example app, a number of somewhat unreliable web services are being called (see the second screenshot above). Twelve initAsync() functions are utilized to display a grid of animals. You can see twelve spinners appear before pictures of animals are displayed. Note, how some of them take their sweet time to complete. Fluttery has all that built-in.

See how modular the code is? Such asynchronous code is located where it is required and executed when it is needed. That’s very nice. Fluttery even handles any errors that may occur in the initAsync() function and provides a function for you to implement when such errors occur:
void onAsyncError(FlutterErrorDetails details) {

What else do you want?

Event Handling

The Events That Take Place

You want to know what’s going on in your app. There’s so much going on in a typical Flutter app. Fluttery turns to Flutter itself to offer an array of event handlers that will address all that’s going on in your app.

Look at the two screenshots below. They’re the result of debugPrint() functions placed throughout the example app called in Flutter’s many Event Handlers. They print out on your IDE’s console the name of the handler, the Controller, and the State object involved. I’ve placed them throughout the example app for your benefit so you can see the extent of control you have while running your app.

Those two screenshots convey the events fired when simply tapping through the example app’s screens and back again (see video). Pretty intense, right? That’s always going on in your apps — you should be aware of them. The free article below details this further.

In The Beginning

The first screenshot below displays some of the handlers represented by the debugPrint() function calls. Of course, there’s much more going on when starting up your app, but let’s see what’s conveyed here. The first State object, _ExampleAppState, is starting up accompanied by it Controller object, AppController. Note how the State object fires its Controller object’s event handlers before its own — very important.

This order of events is an exception at startup as the remaining screens will call the initState() function first then the initAsync() function. It’s unique at startup because that’s when you would initialize the many functions and features you want to accompany your app.

The Route Taken

See how Fluttery highlights when a Route is taken moving from one screen to another? The home screen, of course, is opened at startup, and that’s represented by the didPush() function. Even before the State object’s initState() function is called, its didPush() function is called — very useful.

The list of didChangeMetrics() functions in the screenshot below tells you the interface is finalizing its components’ size and position. Things will soon settle down, and the app will then wait for user input — and it gets it right away. The current Controller and State object notes we’re pushing onto another screen with the function call, didPushNext(). Think of this event as, “We’re now leaving ‘CounterController’ and _CounterPageState and pushing to the ‘next’ screen. Act accordingly.”

I haven’t ‘reinvented the wheel’ here. This is all coming from Flutter. I simply consolidated these capabilities into my ‘framework package’ called, Fluttery.

Page 1 and 2

We’re arriving on Page 1 in the next screenshot below. Even before its State object’s initState() function is called, its Controller’s and then its own didPush() function is called. Very nice. What follows, of course, are their initState(), their didChangeDependencies(), and their initAsync() functions before Page 1 is displayed. After all that, we can tell we’re moving off Page 1 with the didPushNext() function calls. See how this works? We go all the way to Page 3 in this exercise.

Pop Back

In the next few screenshots, let’s start heading back from Page 3 back to the home screen. With Fluttery, you can run code when such events happen. For example, you can restart features when returning to previous screens, or validate data retrieved when leaving a screen, etc. You can control the processes involved when switching between your app’s screens.

It’s All Flutter

Please, take a look at the screenshot below. If you know Flutter, you’ll know what’s happening in the sequence of events displayed there. This involves Page 3 in the example app. Now, its State object doesn’t have an accompanying Controller object, but that’s perfectly fine. No law says you need to use them. You can see it ran its initAsync() function (only to call debugPrint() mind you), but then Page 2 calls its didPopNext() function? Flutter’s telling you we’re coming back to Page 2 — act accordingly.

What follows then is very interesting. The State object in Page 3 calls its didPop(), its deactivate(), and its dispose() in that order. Page 3 is closing and being cleared from memory — and you have the handlers available to address when a State object is shutting down. That’s very very nice. Particularly with how unreliable the dispose() function can be. More on that next.

To Dispose Of

The next screenshot has Page 2 closed and cleared from memory. We see its accompanying controller named ‘Controller’ is calling its event handlers as well. However, note the oddity in the Controller’s dispose() function.

Page 1 and Page 2 share a controller named ‘Controller.’ It has retreated to its previous and first associated State object, Page1State. That’s because we don’t want any reference to a State object that’s about to ‘go away’ from memory — if and when it calls its dispose() function. ‘If and when?’, you say? More on that shortly.

In the final screenshot below, Page 1 is now being cleared from memory. There should be no reference to its only State object by the time this dispose() function is called. At this point, the controller should have no associated State object, and so it returns null below. Makes sense?

Play Well With Others

Now, as much as you would like it to be the case, yours will not be the only app running on your user’s device. There are also event handlers for when your user moves off your app (placing it in the background) only to return from some other app at some point later. You should handle such situations as well.

Let’s look at the video below. Tapping Android’s ‘Recents’ button will place the example app in the background. Another tap on the app itself returns it to the foreground. You will want to handle the events that occur during this time. You have the handlers to do it. Please, tap on the screenshots below for a closer look.

Separate Lifecycles

These are handlers you haven’t seen before. Note the order they are called. They’re fired ‘from the ground up’ up to the currently displayed screen running the State object, _CounterPageState.

Returning to the app, the last screen’s controller and State object are the last objects to fire their ‘resumed’ event handlers. See below.

Below, the event handlers are all listed together. You can see these ‘system’ event handlers behave a little differently than those you’ll encounter in Flutter itself. They are dependent on the particular platform the app is running on — some don’t exist depending on the platform. Notice your app returns to the foreground only after running the ‘hidden’ and ‘inactive’ functions once again. Finally, the function, resumedLifecycleState() is called in the Controller and the didChangeAppLifecycleState() function with the parameter value, AppLifecycleState.resumed, is called in the State object. Fluttery is doing this all for you. Event handling is very important.

Real-World Example

Timing is Everything

Let’s give you a real-world example of its importance. When this example app starts, there’s a ‘word-pair’ displayed in red and placed in the center of the screen. To produce these pairs, a Timer is calling the package, english_words, at a steady interval. It’s always running in the background. Granted, it’s not taking up too much resources, but imagine a more substantial process always running in the background — one running in your own app. You should have some control over these background processes.

In the video below, when we tap off the first screen to Page 1 screen, the Timer is stopped. It would be a waste running this process in the background when it is no longer needed. The first screenshot shows the event handlers involved. Note, the second screenshot handles a different scenario altogether. The second scenario shows the Timer initialized at startup and turned off when the app closes using the ‘deactivate’ event. By the way, when is the ‘activate’ event triggered? I’ll tell you soon. Hint: Widget tree.

In the first screenshot above, the didPushNext() method is triggered when the ‘Page 1’ button is pressed. Again, this is all about routes. You’re about to leave this first screen being ‘pushed to the next screen.’ Hence, the Timer is stopped with the function call, _cancelTimer(). Note in the video we return from Page 1 almost immediately (i.e. The ‘next screen’ is popped almost immediately). That means the didPopNext() function back in the first screen is fired and initializes the Timer again with _initTimer(). See how that works?

Sequence of Events

Revisiting Android’s ‘Recents’ button, when placing this example app in the background, a whole different sequence of events occurs below. In the first screenshot, you see the three event handlers involved. They're listed in the order they are fired in the controller, EnglishWords Timer. In the second screenshot of that very same controller, you see the event handler, resumedAppLifecycleState(). Again, it’s called when the example app is returned to the foreground. See how that all works? It’s how Flutter works. Fluttery just gives you the functions to work with it.

It Is Eventful

Back in that video, the _cancelTimer() function is called a total of five times. That’s because, as you’ve seen in the graphic below, Flutter will go back through those event handlers when bringing the app back into focus. That’s just the way it is. I involved all three methods here to demonstrate this. In truth, I would have only placed the _cancelTimer()method in the inactiveAppLifecycleState() method — for a total of two calls. The method, resumedAppLifecycleState(), is then called going back so to initialize the Timer again. Perfect.

The Tree Is Key

Now, back to the ‘activate’ event. Know that a State object’s deactivate() event handler is triggered in two instances: when their widget is closing and when their widget is moved around the Widget tree. The Widget tree makes Flutter fast. Widgets are moved around the tree to improve performance. When a widget is ‘reinserted’ into the Widget tree, its State object’s activate() event handler is called — restarting the Timer in our case. See how that works?

Dispose Disposable?

This is all because I don’t trust the dispose() function. I need to call the _cancelTimer()routine and stop the Timer. However, I usually don’t use the dispose() method to do this. It’s unreliable to run any mission-critical operations and or release any substantial resources. You see, it’s to the Virtual Machine’s (VM) (i.e. Flutter Engine) discretion to call a State object’s dispose() function as part of its garbage collection responsibilities. You will have no idea when that happens. Due to some memory constraints, it’s not called at all — at least not when you may want to. The deactivate() method is more reliable and is more consistent. I use the deactivate() method, but that means I also use the activate() method — in case the Widget is moved around the Widget tree — the Timer must be initialized in our case. That’s just the way it is.

What else do you want?

Error Handling

Error handling is paramount. Your app is going to fail for any number of reasons, and you must have the code to address it. Your app must fail gracefully and close vulnerable resources before crashing. Your error handling should report and or log the problem with pertinent information. If the situation permits, maybe your app can even recover and continue on. Granted, recovery is the exception, but Fluttery offers the possibility.

The State of Error

Every State object has the onError() function. An error thrown in a Fluttery app will involve a State object if the code that errored was working ‘in’ that State object. The State object’s onError() function is called:
void onError(FlutterErrorDetails detials) {

Push for Exception

In the video below, the example app throws an Exception with every tap on the ‘Counter’ button (+), but you’d never know it. The Exception is still reported and logged by its Error Handler, but the State object’s onError() function recognizes this particular Exception, and attempts to increment the counter regardless.

A very very simple scenario, where the Exception is anticipated (i.e. it’s explicitly thrown). However, Fluttery allows you to take into account such scenarios. You may have situations in your app where the typical process will encounter anticipated exceptions —and possibly you’re then able to overcome them.

app_counter.dart

It Takes Two

In Flutter, there are two types of ‘errors.’ In Flutter itself, with certain bits of code, an exception is anticipated to occur from time to time. Such code is likely called within a try-catch statement to indeed catch such exceptions. In the catch clause, an Exception object is instantiated and ‘handled’ accordingly.

The other type of error is considered ‘an error on the part of the developer.’ However, even an unanticipated issue must be addressed. For such failures, it’s preferred the Error class and its subclasses be used.

An Error object represents a program failure that the programmer should have avoided. — Google Search.

Counter The Exception

In the first screenshot above, when switched on, the State object, _CounterPageState, explicitly throws, Exception('Fake error to demonstrate error handling'). The next screenshot is of that State object’s onError() routine. It is seeking out that specific problem and addressing it accordingly.

My Bad

Now, ‘handle your errors’ does not mean ‘ignore them completely.’ That’s a no, no. I’m sure you could find a way, but I wouldn’t ignore any errors or exceptions. Even with the ‘Counter’ button problem seemingly ‘handled,’ the example app’s error handler doesn’t neglect to record and report the problem as well. See the console screenshot below:

To The Top

Again, every State object has an onError() function. An exception will be sent to the State object that the troublesome code was likely working with. Regardless, the App’s first State object’s onError() routine is always called. Being the ‘head honcho’ of State objects in your app, the AppStateX object is notified of all exceptions or errors that may occur in your app.

Above is the screenshot of State object, _CounterPageState, again. It fires its onError() routine with every tap of the button. The second screenshot is of the AppStateX object, _ExampleAppState, displaying its onError() routine. It takes in that particular exception as well. Broadcasting errors to the ‘governing part’ of an app is just good practice. For example, when working with a team of developers, one programmer can’t just hide their errors while developing some remote screen somewhere—all errors are sent to the App’s ‘main’ State object as well.

Other Handlers

With Fluttery, you’re free to utilize other third-party error handlers like Firebase Crashlytics, Catcher 2, etc. These products will notify you directly about a problem right then and there. You can then be more proactive when addressing such issues.

Below is a screenshot of what an App’s initAsync() function could contain, for example, when setting up Firebase Crashlytics as its Error Handler and reporting system.

Stops And Starts

Fluttery provides an important capability to your apps. Again, it allows your app to perform extensive and complicated operations asynchronously using the function, initAsync(). Every State object in Fluttery has one so as to localize such operations to run when and where they’re required.

These operations are likely critical and must be completed successfully for your app to proceed. The need for error handling during such operations will be of great importance. A handler to log, report, and possibly even recover from errors in the function, initAsync(), may prove very helpful to you.

In the video below, an initAsync() function explicitly throws an Exception (if permitted) when the ‘Page 1’ button is tapped. The first screenshot has the Exception thrown, while the second screenshot introduces you to the onCatchAsyncError() function. Note, that specific Exceptions are anticipated in this function and will return true when encountered. Consequently, the ‘Page 1’ screen appears seemingly without incident.

However, they are still Exceptions, and so error handlers log it accordingly. Note below, a console lists the debugPrint() function outputs indicating the many handlers involved.

The exception occurred in ‘Page 1’ and so its onError() is called. The app’s main State object, _ExampleAppState, will then call its onError() function. Being an ‘Asynchronous’ error, its onCatchAsyncError() function is then called. That’s the second screenshot above, and because it returns, true, the ‘Page 1’ screen appears.

Now, below is what happens if it returns false (see the second screenshot below). The screen, Page 1, fails outright and the good old ‘Red Screen of Doom’ is instead displayed. If running in Production, it turns out to be an ugly, ‘Grey Screen of Doom.’

Now, what’s stopping you from always returning true when errors occur in an initAsync() function? Remember, these operations are likely critical and must be completed successfully. Frankly, if you ignore such errors, that’s on you. They’re still reported to the ‘main’ State object in your app.

A Bad Build

In the video below, another exception occurs in a ‘build’ function obligated to return a Widget. It occurs when moving to Page 2. The first screenshot below displays the throw statement involved.

In the second screenshot below, you can see in Flutter itself, the build() function is called in a try-catch statement. When an error occurs right in a build() function, something has to be displayed, and so the ErrorWidget.builder() produces the good old ‘Red Screen of Doom.’

Seeing Red Not

As you see in the first screenshot below, from the very beginning, the App’s State object, _ExampleAppState, has been using Fluttery’s standard Error Handler: AppErrorHandler.errorHandler
Of course, you’re free to assign your own Error Handler.

You’re also free to assign your own ‘Error Widget Builder’ to display a screen when a build() function fails. In the first screenshot below, Fluttery offers a more helpful and more aesthetically pleasing screen using the parameter value, AppErrorHandler.displayErrorWidget.The videos below have the same two errors that were tripped above. This time, however, you’re not seeing red.

It’s A Little More

There you have it. The Fluttery State class has a little more functionality (i.e. a few more functions) to supply ‘a little more’ of what I feel is required for a production-worthy, cross-platform app:

Multiplatform, Time to Initialize, Event Handling, and Error Handling

Further information is in the ‘Little More’ series of free articles (see below). I feel you’re going to want this. It’s all comes from Flutter. Just consolidated into one package: Fluttery Framework

Cheers.

The Fluttery Framework

Greg Perry — Wed, 29 Jan 2025 16:26:52 +0000

A Framework that works with Flutter and works like Flutter

Mike Rydstrom is known to post on his Twitter account a list of the Top 30 State Management library packages used by Flutter developers. Below, I believe, is the latest dated August 14, 2022. Tap on it to get a closer look.

Google didn’t release Flutter ‘hard coded’ to one particular architecture. They left it to the IT industry to come up with different ways to work with Flutter. Hence the list above. After all, programming languages are called upon to work in almost every Use Case on Earth! Computer software can be found running in everything from a toaster to a nuclear submarine. By that very fact, it has to be intrinsically adaptive so as to meet very diverse and very complicated problem domains. Google knew you simply can’t supply a ‘one-size-fits-all’ approach when developing software. And so, I suspect that list will only grow longer.

Of course, your users and particularly your boss will insist you only use the ‘best one’ listed above — which, as I’ve just hinted, is an impractical demand. However, time is money and in many cases, I suspect you’ll choose one simply because it follows a design pattern or style you’re familiar with. Still, other developers will look at that list, visit forums, ask around, and then simply pick what seems to be the most popular. Easy peasy.

However, it’s not so easy. I’ve looked at that list — for most, you have to learn how to use your chosen approach. Today, I’ll introduce you to yet another library package. One I feel stands out from the rest. ‘Keep it Flutter’ has been my motto when building this framework. Most of those other library packages don’t work like Flutter itself. They sit on top of Flutter and have their own way of doing things. There‘s a learning curve not only to learn how Flutter works but how your chosen library package works as well.

Below is a ‘paywalled’ article about the Provider package. The article is written by Suragch — one of my favorite writers. I’ve always liked the title, Making sense of all those Flutter Providers. The Provider state management package was written by Remi Rousselet, and to me, looks a lot like the Provider Model introduced by Microsoft in 2002 — I suspect many of today’s Provider users were ASP.Net developers.

Remi did some great work, but I chose not to use Provider. After all, Flutter has its own means of State Management. I wrote a framework to more effectively and more efficiently work with Flutter — like Flutter.
Making sense all of those Flutter Providers

If you’re new to Flutter and want to learn Flutter, learn how to use this library package. Unlike those others, it’s a framework that works with Flutter, works like Flutter, and looks like Flutter. If you have a few years of experience in Flutter, you’ll recognize how this framework works. In this series of articles, you’ll be introduced to the Fluttery Framework through the demonstration of a number of example apps.

Fluttery Framework on Pub.dev

Let’s begin.

Works with Flutter, Works Like Flutter

This framework implements a SOC (State Object Controller) to accompany every State object used in your Flutter app. It does this by introducing the class, StateX, which ‘extends’ Flutter’s State class to now include a controller. It is this controller object that performs the event handling and business rules specific to your app — much like the many Controller objects already found in Flutter. Again, I’m ‘keeping it Flutter.’

Indeed, there are a number of widgets in Flutter with a named parameter called, controller. The widgets, TextField and SingleChildScrollView are two quick examples. They take in a controller object that provides an initial value or an initial position respectively as well as handle the common events and circumstances involved in their typical operation. It was back in 2018 when I first began working in Flutter that I quickly found it very productive and advantageous to introduce such a controller to Flutter’s own State class.

Below are two screenshots of those two widgets I mentioned above — each with its own controller parameter highlighted with a little red arrow.

date_picker.dart

By Example

Now, what better way to illustrate the implementation of the StateX class and the Fluttery Framework than demonstrating it in an example app? The Stocks example app implements the Fluttery Framework. This little app supplies the option, ‘dev tools’, in its Drawer widget demonstrating the many development tools available to you when working in Flutter. In truth, it’s the Fluttery Framework that makes these tools readily available to you, and I’ll show you how in later articles but for now, let’s look at this StateX class and its controller.

The State Extended

In the first screenshot below, you’re introduced to the StateX class for the first time. The little red arrows highlight this class and how its accompanying controller, DevTools, is instantiated. It’s the StatefulWidget, StockSettings, that presents the list of switches you see turning on and off an assortment of development tools. (Note, these tools can only be accessed while developing in your IDE or when you compile your Flutter app in debug mode.)

The second screenshot above is a portion of that State object’s build() function displaying two of those switches. Note the distinct separation of work: the State object’s build() function is concerned with ‘how’ things are displayed in the interface (i.e. with its Switch widgets) while its controller instantiated to the property variable, con, is more concerned with what’s actually being displayed as well as any event handling —this separation of responsibility is a core concept in clean architecture.

The Controller Pattern

By the way, that’s the consistent pattern you’ll see in the Fluttery Framework example apps:

A controller is passed to the StateX object’s parent class constructor, it’s then assigned to a property variable (usually named ‘con’) either in the StateX class’ constructor or in its initState() function. That ‘con’ variable is then referenced here and there in the build() function and in any other function defined in that class and will primarily be involved in the app’s overall business logic and event handling.

The first screenshot is again displayed below for your review. Further below, you’ll find those development tools displayed individually. Most are concerned with the fine-tuning of your app’s interface. In time, you’ll find them very useful in certain circumstances.

Set The State

Now, all that flash and color you see displayed above just doesn’t magically appear when using Flutter. As a quick aside, we know HTML is a declarative programming language. When there’s a change made to a webpage, in most cases, that whole webpage is rendered all over again to then display that change. Well, Flutter apps create their interfaces in a pseudo-declarative fashion as well. This declarative characteristic of ‘rebuilding the interface all over again from scratch’ comes with every new call to a State object’s build() function —the returning widget is often the result of a bunch of other widgets being built all over again. However, that call has to be made in the first place using the State object’s setState() function.

You can readily see above those Switch widgets being turned on and off. However, that’s only because the StatefulWidget, StockSettings, is being rebuilt all over again. More accurately, its State object, _StockSettingsState, is having its build() function called again and that function’s content is being rebuilt all over again. In that screen full of Switch widgets, that State object’s setState() function is being called somewhere. But where?

Below, you see the ‘Performance overlay’ switch being turned on and off repeatedly. The first screenshot below highlights the Switch widget’s onChange() function. With every tap of the widget, that onChange() function is called, and as you can see, its controller is in charge of handling that event. So where is the setState() function call? The Switch can be seen turning on and off with every tap. There has to be a setState() function being called?! Well yes, yes there is. Look at the second screenshot below.

The second screenshot above is of the setter, showPreformanceOverlay, found in the controller, DevTools. There you see the new Switch value being received and recorded (true equals ‘on’ and false equals ‘off’). However, you also see a setState() function call! When a controller is taken in by the StateX object, it can do whatever a State object can do…and more. The controller, DevTools, extends from another class found in the Fluttery Framework called, StateXController.

class DevTools extends StateXController {

The DevTools class was instantiated and passed to the State object’s parent constructor, remember? It now has access to that State object and all its capabilities. Below, that one line is commented out and the program runs again. It reveals that this access is indeed true. The switch continues to be turned on and off, however, nothing appears to be happening. That’s because the screen simply hasn’t been refreshed — the widgets involved have not been rebuilt. In other words, the State object’s setState() function hasn’t been called again — through its controller, DevTools. We’re failing in our State Management duties. However, the performance overlay is indeed on when returning to the app’s home screen.

Keeping It Flutter

Note, how I ‘kept it Flutter,’ with a separate subclass derived from the class, StateXController, yet using the very same function name, setState()? It simply calls the original setState() function in a State object! All the packages on that list are doing the same thing. Note, some are even calling the markNeedsBuild() function deeper in the Flutter framework itself to achieve the same thing. Something I chose not to do.

That function resides in the Element class, and personally, that’s too deep in Flutter’s own framework. It’s in the realm where the Google engineers only play. The markNeedsBuild() function is not part of the public API like setState() — it’s the setState() function that calls the markNeedsBuild() function. Frankly, there‘s the chance that the markNeedsBuild() function will go away a few years from now when they release Flutter 7.0 for example. Like any shop, Google will want its software to easily evolve and has only designated the setState() function to be used when notifying Flutter of a change-in-state.

Again, those other packages up on that list are using completely different paradigms to perform their State Management (i.e. to call setState() in some State object) using completely different function names.

Keep it Flutter.

Back to Fluttery. Note, these SOC’s (State Object Controllers) can be assigned, to any number of StateX objects throughout the lifetime of a Flutter app. For example, with each new StateX object (i.e. with each successive screen), a controller can be shared among them working with a particular State object before retreating back to the previous State object when that screen closes. Sure, Flutter’s State objects are to retain the state of the app, but now you have a StateXController object providing steadfast logic, and indeed, managing that state. The graphic below illustrates this “Last In First Out” (LIFO) relationship that occurs when a SOC is shared among progressive and then receding Flutter screens.

Further, your StateX object is allowed to take in as many controllers as you like. Each controller can be responsible for a particular functionality — ready to react to the many events that originate from that StateX object. See the graphic below. This ability encourages modular programming and allows for parallel development. Very nice.

Developing Your Tools

By the way, I should explain how those development tools are then displayed to you after you’ve selected one or more. In Flutter, rebuilding that screen full of Switch widgets isn’t enough. Yes, that’ll show the switch has changed, but nothing else would happen. You would have to also render the whole app over again! More accurately, call the setState() function of the app’s first State object. With me so far? I’m keeping it Flutter.

There’s a StateX object that’s the first State object or root State object for your app when using the Fluttery Framework. And in this case, we have to call its setState() function to now display that Performance Overlay for example. Let’s show you how that works. However, I bet you’ve already got a good guess…if you know Flutter.

The screenshot above shows part of the Drawer widget displaying the option, Debug Tools. Again, it’s a controller (this one is called StockHomeController*)* that handles things if the option is tapped on. Unbeknownst to you, that controller calls the controller, DevTools, to bring up that screen of switches —thus deligating the work among different controllers and keeping it modular. See the first screenshot below.

Note, that ‘Debug Tools’ option will not appear if the app is released into production (see above) courtesy of the Flutter Framework’s static getter, App.inDebugger (also App.inDebugMode). This Fluttery Framework library package doesn’t just provide a means for State Management. It’s a framework! Frameworks are supposed to make development a little easier. Anyway, the majority of Flutter’s development tools aren’t available in Production anyway — why confuse the user with such an option?

Remember to tap on the screenshots for a closer look. If you’re on your phone, you can then use two fingers to zoom in even further.

After the ‘Performance Overlay’ switch is turned on and the user closes that window, the DevTools Controller calls the setState() from its property variable, _state. See the second screenshot above. The third screenshot above highlights where that variable is initialized and what it is assigned to. It’s assigned the app’s State object (the first State object), and it’s assigned in the controller’s initState() function. Now, guess where that initState() function is called.

It's called by the StateX object, _StockSettingsState, in its own initState() function. Remember, the DevTools controller was passed to that StateX object’s parent class constructor. Not only does the controller now have access to that StateX object and all its capabilities, but that StateX object now has access to that controller…and all its functions.

As you know, in Flutter, when a State object is to be displayed for the first time (i.e. before it calls its build() function for the first time) its initState() function is first called. The same, of course, is true for any StateX object in the Fluttery Framework. When a StateX object calls its initState() function, any StateXController(s) taken in by that time will have their own initState() functions called as well. Easy peasy. These SOC’s (State Object Controllers) share some of the same functions as their associated StateX object making for more efficient development frankly. That’ll be demonstrated in articles to come.

See how this all comes together? Notice how this framework behaves like Flutter because it was written to behave like Flutter? When it comes to State Management, things appear to be working out just fine, don’t they?

State and Control

And that’s about it. It’s those two classes, StateX *and *StateXController, that make up the core of the Fluttery Framework. Any additional classes introduced to you in this framework will be a subclass of one of these two classes— one of which, of course, is the subclass of Flutter’s own State class.

In The Beginning

An example of this is seen in how a typical Flutter app starts up when using the Fluttery Framework. Let’s finish this first article in the series by examining the Stocks example app’s main.dart file. As you can see in the screenshot below, there really isn’t much to it. That’s by design. The remaining source code is safely inside the src folder. The runapp() function only requires one lone Widget as a parameter. The app really begins with that one lone Widget called, MyApp.

The StatefulWidget, MyApp, has a parent class called, AppStatefulWidget. Tap on the first screenshot below for a closer look. Pretty straightforward. It’s the widget I recommend you pass to the runApp() function because it then calls its createAppState() function to create the Fluttery Framework’s AppState object. That’s the ‘first’ State object for your Flutter app and, of course, is a subclass of the StateX class. You can see in the second screenshot below, it has a named parameter called, controller.

Keeping it Flutter.

The third screenshot is that of the AppStocks class — a subclass of the AppController class which, in turn, is a subclass of the class, StateXController. Both the AppState and AppController class have their specialized roles to play when making your Flutter app development that much easier and that much more productive. I mean, tap on the caption under the second screenshot below, and it’ll take you to the Fluttery Framework’s GitHub repository. There, you’ll see how many parameters the AppState class has available to you to define the ‘look and feel’ of your next Flutter app. The source code is all documented. You can figure it out. But don’t worry, we’re just getting started with this series of articles.

State My Admittance

Finally, as you may have long realized by now, I really shouldn’t be explicitly comparing this framework to the Dart packages in that list above. Those are library packages simply offering an approach to State Management, this is much more…it’s a Framework.

The classes, StateX *and *StateXController, that make up the core of the Fluttery Framework, would be a more accurate comparison to that list. I wrote the state_extendedpackage to more effectively and more efficiently implement State Management with Flutter; like Flutter. It just happens that this framework uses it as well.

It’s the Fluttery Framework that implements the rest. That is, it implements things that should come with your app in the first place — standard functions and features to be found in any production release, Frameworks are to assist developers in building their apps — make development that much faster and that much easier. Frameworks do the ‘heavy lifting’ and provide standard capabilities reliably and consistently so the developer doesn’t have to every time. They’re to provide aspects of development we developers are guilty of not considering as much as we should. Error handling comes to mind. Unfortunately, when it comes to error handling, our priority is to write code that works —we tend not to consider what should happen if something goes wrong. This series will address all of that in time.

Until then, I invite you to download the example app, *Stocks*, and take the Flutter Framework for a test drive. ‘Keeping it clean,’ ‘Keeping it simple’ and ‘Keeping it Flutter’ has made my projects adaptive, scalable, and maintainable. True, there are a lot of Flutter developers out there using the top-three State Management library packages up on that list.

I can only assume they just don’t know about this framework yet. ;)

Cheers.

→ More Stories by Greg Perry

A Fluttery Digest

Greg Perry — Wed, 29 Jan 2025 16:22:52 +0000

A compilation of Fluttery Framework Articles

It’s Not Flutter

Little More Efficient

Little More Control

Little More Error Handling

Little More Life Cycle Handling

Little More Adaptive

The Fluttery Framework

It’s Not Flutter

Greg Perry — Fri, 06 Dec 2024 19:05:02 +0000

It’s Not Flutter

Keep It Simple, Keep It Flutter

I don’t use BLoC. I always felt using a Stream was a bit of overkill to call a setState() function whenever a change-in-state. Yes, it’s a means to do so independent of the Widget tree, but Streams were meant for streams of data not for event handling. However, my real issue is with the ‘Provider Model’ design pattern used by BLoC.

It’s not Flutter.

Control Your Build

Below is a side-by-side comparison of the example app’s Settings page. The first screenshot below is the original BLoC version with its BlocBuilder() function while the second screenshot uses the StateXController class, and its setBuilder() function. Both are functions that rebuild with a setState() function call leaving the rest of the interface untouched.

Note how some of the logic (how values are conceived) is more readily visible in the BLoC version. For example, in the first screenshot, the property, WeatherState, is exposed in the interface while the Controller version in the second screenshot only displays designated properties and necessary functions from the Controller object, _con.

Supplying such a layer of abstraction encourages better modularity, better adaptation, better scalability, and generally better maintenance of the software. It provides the interface that's needed without revealing how it’s provided. That way, in the future, you can change how that’s done with ease without changing one bit of the interface.

settings_page.dart

Inherited Builds

In the BLoC version, the BlocProvider implements an InheritedWidget and makes the app’s remaining interface, WeatherAppView, a dependency of that InheritedWidget — a means to ‘rebuild’ that Widget again and again when necessary. See the first screenshot below.

In the second screenshot below, the StateX version utilizes an InheritedWidget as well. However, the widget, WeatherAppView, is replaced by the State object, _WeatherAppState, that defines the overall ‘look and behavior’ of the app.

This may be an unfair comparison at this point, as the Fluttery Framework is designed to produce ‘production-ready’ apps while the BLoC version is merely a very simple example app. Therefore, I’ll limit this article to comparing the ‘differences’ made to conceive the same interface and behavior. For more information on the Fluttery Framework, see the ‘Little More’ Series.

app.dart

weather_app.dart

Control is Everything

Back to the BLoC version, as a dependency, the WeatherAppView widget will be rebuilt again if and when the value, toColor, has changed. You can see that highlighted in the first screenshot below. Again, the logic is exposed in the interface.

The next two screenshots below are from the Fluttery version of the app but are not the corresponding interface. Instead, it’s of the controller, WeatherController. That’s because that specific logic is found in the Controller and not in the interface. Again, it is the Controller that determines what widget is rebuilt and why.

app.dart

weather_controller.dart

In the BLoC version, the class, WeatherCubit, is somewhat equivalent to the class, WeatherController, in the Fluttery version. Both fetch new Weather information, and both deal directly with the data source involved.

weather_cubit.dart

weather_conroller.dart

A Single Simple Solution

Note, how the Controller uses a factory constructor to make only one instance of this class. This implements the Singleton design pattern and is, more often than not, very suitable for the role of a State Object Controller: It retains ‘a running account’ of the app’s state, its logic, and the current data involved. Further, it makes that one instance readily available throughout your app if you like using very little boilerplate code. Much of what makes up the Provider Model, is instead achieved by a factory constructor. Keep it simple. Keep it Flutter.

context.read<Weatheruit>.refreshWeather(); vs.
WeatherController().refreshWeather();

Going back to the example app comparisons. You can see in the first screenshot below, how the BLoC version relies on the Widget tree to retrieve the one instance of WeatherCubit. This is so as to call its functions, refreshWater() and fetchWeather(). The State object in the second screenshot below merely uses the local variable, con. It originally came about from the constructor call, WeatherController().

extension ReadContext on BuilldContext { T read<T>() { return Provider.of<T>(this, listen: false); } }

weather_page.dart

The same approach is found in the Settings page respectively.

settings_page.dart

In The Beginning

Note how the WeatherCubit class is defined nowhere near where it is first used. This practice is a throwback to when the Provider design pattern was first introduced with ASP.Net 2.0. Generally, everything was defined at the start of the app.

In the BLoC example app, the BlocProvider will only create an instance of the WeatherCubit class when it’s first required. When instantiated, it’s then stored in an internal variable, _value(second screenshot below). In the first screenshot below, the WeatherCubit class is defined at the start of the app. For this app, it is only stored in the variable, _value, (making for a pseudo-Singleton approach) when first required to determine the app’s background color (third screenshot below).

app.dart

inherited_provider.dart

app.dart

In the Controller version, a WeatherController instance is only created when it’s first required as well. With its factory constructor, it is that instance that is then used throughout the app. Done.

At the start of this example app, the *inTheme *clause is used to supply the color scheme — one of many options available to you when using Fluttery (see Little More Adaptive). In the second screenshot below, of course, it’s the same instance used to fetch the weather info.

weather_app.dart

weather_page.dart

The Hive Mind

By default, the BLoC version uses a popular lightweight NoSQL database called Hive. As such, working through the class, WeatherCubit, the Weather object’s data is saved to this database assumingly to demonstrate that capability. Thus, I noted when restarting the app, it wouldn’t fetch that city’s current weather info., but simply retrieve the past data stored in the Hive database. It may make for an out-of-date weather reading, but again, it demonstrated that capability. In the video below, the weather is only updated with another explicit fetch of the data.

main.dart

hydrated_bloc.dart

Fluttey doesn’t offer a database. Like Flutter, that’s left to the developer. As for the example app, I chose only to save the city name using the device’s stored-preferences infrastructure. The next time the app started up, that city name would be looked up again with the usual API call.

In the first screenshot above, Felix chose to initialize the database at the beginning of the app. Again, a common practice in the past. The Fluttery version is more State-centric. The data source is only required in the State object, _WeatherPageState, where data is retrieved (first screenshot below). Of course, in the second screenshot below, it is its Controller that takes care of all this. Because the Controller was passed into that State object (see line below), its initAsync() function is called and performs the fetch. A spinner is displayed until that weather info is fetched from the Web service (see video below).

_WeatherPageState() : super(controller: WeatherController()) {

part01_statex.dart

weather_controller.dart

Again, I chose only to save the city name using the Prefs package. It works with the plugin, shared_preferences. which, depending on the platform, wraps the NSUserDefaults (in iOS) and the SharedPreferences (in Android), to provide persistent storage.

Let’s leave it there.

Note, if this app supplied real-time forecasts, I’d use a Stream.

Cheers.

How To Use ChangeNotifier

Greg Perry — Fri, 29 Nov 2024 16:59:26 +0000

How To Use ChangeNotifier

It can’t be used in certain cases. Not directly anyway.

Have you ever tried to use the ChangeNotifier as a Mixin on a State class? You can’t do it.

class NotifierState extends State<NotifierWidget> with ChangeNotifier;

If you try, your State class will no longer call its dispose() method, and you need to call its dispose() method to ‘clean’ things up in many cases. However, the ChangeNotifier is a Mixin with its own dispose() method, and it doesn’t extend a parent class with a dispose() function. Therefore, as you can see in the second screenshot below, its dispose() method doesn’t have to call, super.dispose(). It just won’t work as a Mixin on any class that has its own dispose() method. However, there is a way to introduce a ChangeNotifier with a Mixin by doing it indirectly.

change_notifier.dart

Supply the Mixin, ImplNotifyListenersChangeNotifierMixin, to your State class, and place the method call, disposeChangeNotifier(), to its dispose() method. You‘ll then have a ChangeNotifier working with your State class.

  @override
  @mustCallSuper
  void dispose() {
    // Call the dispose of the implementation of Change Notifier
    disposeChangeNotifier();
    super.dispose();
  }

Grab a copy of this Mixin below:

import 'package:flutter/material.dart';

import 'listenable_widget_builder.dart';

mixin ImplNotifyListenersChangeNotifierMixin {
  //

  // Instantiate the Change Notifier
  void initChangeNotifier() {
    _implChangeNotifier ??= ImplNotifyListenersChangeNotifier();
  }

  /// A flag. Instantiated Change Notifier
  bool get hasChangeNotifierImpl => _implChangeNotifier != null;

  /// Don't forget to call dispose() function!
  void disposeChangeNotifier() {
    _implChangeNotifier?.dispose();
    _implChangeNotifier = null;
  }

  // Implementation of the ChangeNotifier
  ImplNotifyListenersChangeNotifier? _implChangeNotifier;

  /// Returns a widget from builder assuming the current object is a [Listenable]
  /// const SizedBox.shrink() otherwise
  Widget setBuilder(MaybeBuildWidgetType? builder) {
    // Ensure the ChangeNotifier is initialized
    initChangeNotifier();

    if (builder != null) {
      _widgetBuilderUsed = true;
    }
    return ListenableWidgetBuilder(
      listenable: _implChangeNotifier,
      builder: builder,
    );
  }

  /// A flag. Noting if the function above is ever used.
  bool get setBuilderUsed => _widgetBuilderUsed;
  bool _widgetBuilderUsed = false;

  /// Whether any listeners are currently registered.
  bool get hasChangeListeners => _implChangeNotifier?.hasChangeListeners ?? false;

  /// Call all the registered listeners.
  bool notifyListeners()  {
    final notify = _implChangeNotifier != null;
    if (notify) {
      _implChangeNotifier?.notifyListeners();
    }
    return notify;
  }

  /// Register a closure to be called when the object changes.
  bool addListener(VoidCallback listener) {
    final add = _implChangeNotifier != null;
    if (add) {
      _implChangeNotifier?.addListener(listener);
    }
    return add;
  }

  /// Remove a previously registered closure from the list of closures that are
  /// notified when the object changes.
  bool removeListener(VoidCallback listener) {
    final remove = _implChangeNotifier != null;
    if (remove) {
      _implChangeNotifier?.removeListener(listener);
    }
    return remove;
  }
}

/// Implementing ChangeNotifier
class ImplNotifyListenersChangeNotifier with ChangeNotifier {
  /// Whether any listeners are currently registered.
  bool get hasChangeListeners => super.hasListeners;

  /// Call all the registered listeners.
  @override
  // ignore: unnecessary_overrides
  void notifyListeners() => super.notifyListeners();

// The 'unnecessary overrides' prevent the Dart Analysis warning:
// The member 'hasListeners' can only be used within instance members of
// subclasses of 'package: change_notifier.dart'.
}

The trick is when you attach this Mixin, it supplies a ChangeNotifier as field property instead (see first screenshot below). In the second screenshot, a ChangeNotifier is instead attached to a very simple class. It is that class that is then instantiated as a field property in the method, initChangeNotifier()(see first screenshot below).

part14_change_notifier_class.dart

A closer look at the Mixin below, reveals how the traditional methods found in the ChangeNotifier are then mirrored in this Mixin. You can see in the third screenshot below, the methods notifyListeners(), addListener(),and removeListener() are all called by functions of the same name.

Further note, the ChangeNotifier field property is nullable. A Mixin can’t have a constructor, and so it’s up to the user to properly use the Mixin and to call both the method, initChangeNotifier(), and the method, disposeChangeNotifier(), when appropriate. If not done so, the Mixin will not crash, but instead just not work properly. It’s on you to work it properly.

part14_change_notifier_class.dart

Add Some Class

Note, what you could do is specially assign such a Mixin to a State class, but it wouldn’t be very practical. You would have to dedicate a new Mixin to each State class. That’s because you would have use the on clause (see the first screenshot below) to reference that specific State class. However, you can then include a dispose() method in the Mixin. It would be called by the State object. See how that works?

impl_change_notifier_mixin.dart

counter_listenable.dart

class _MyHomePageState extends State<MyHomePage> with ImplNotifyListenersChangeNotifierMixin;

The second screenshot above is a simple counter app utilizing this particular Mixin. With every push of the button, you then use the functions setBuilder() and notifyListeners() to only rebuild the Text widget containing the count. The rest of the screen is left untouched.

That’s the primary purpose of the setBuilder() function found in the Mixin. It returns a Widget defined by its supplied builder, and that Widget is only rebuilt with the function call, notifyListeners(). Your interface could be dotted with these setBuilder() functions. For better performance, only those areas of the screen are rebuilt instead of the whole screen.

The class, StateXController, in the example app, flutter_weather, has its own dispose() function. Therefore, in the first screenshot below, you can see the Mixin is attached to this class, and the method, disposeChangeNotifier(),is called in its dispose() method. In the second screenshot, you see the function, setBuilder(), is called.

part13_statex_controller.dart

settings_page.dart

In the video above, you see this simple app allows you can tap to another screen and switch the city of Chicago’s temperature from Celsius to Fahrenheit (°C to °F). Again, the second screenshot above shows how this second screen is implemented. When the user taps on the Switch widget to change from Celsius to Fahrenheit, the class, StateXController, calls the function, notifyListeners(). That will call the Widget builder in the setBuilder() function again rebuilding the Switch widget with now the toggled isCelsius value. Easy peasy.

Lastly, let’s examine the setBuilder() function in the first screenshot below. It utilizes the StatefulWidget, [ListenableWidgetBuilder]. You’ll have to get a copy of this StatefulWidget as well to use the Mixin. This StatefulWidget takes in the ChangeNotifier as a [Listenable] and its State object, _ListenableState, adds the function, _callBuild(), as a listener (see the second screenshot below). In the third screenshot below, you can see the function, _callBuild(), merely calls the build() function listed further below. See how that works?

part14_change_notifier_class.dart

part15_listenable_widget_builder.dart

I hope this has given you some insight about the ChangeNotifier.

Cheers.

Little More Efficient

Greg Perry — Fri, 25 Oct 2024 16:08:55 +0000

A Little More Framework for the Flutter Framework makes for better apps

Part of the ‘Little More’ Series, this article will highlight the ability of updating only those parts of your app’s interface that have changed. Flutter’s InheritedWidget provides the means, but many apps continue to have their whole interface rebuilt. This only degrades performance.

Depend On It

Using Flutter, for example, you can have three widgets each displaying an image of a animal. Each widget ‘depends’ on the same InheritedWidget. In Flutter, if that InheritedWidget is called again, all three of those animal widgets are rebuilt and will display a new image. Only those areas of the screen are updated. Tap on the video below and see for yourself.

The first screenshot below displays the example app, builtin_inherittedwidget_example. It’s a StateX object (see state_extended package) assigned as a ‘dependency’ to a particular InheritedWidget using the function, dependOnInheritedWidget(). The second screenshot below is the code for the footer buttons that are pressed one after the other in the accompanying video. Each ‘onPressed’ function is also highlighted with a red arrow.

Note, how the arrows highlight the separation of responsibilities in the code. The variables ‘_con’ and ‘con’ in each screenshot performs the ‘event-handling’ and ‘logic’ involved in the code. The rest of the code is only concerned with the interface (see Little More Control).

In this example app, four StateX objects have the named parameter, useInherited, set to true (see screenshots below). That means each will use their built-in InheritedWidget. Each represents a particular animal, and each will manipulate three additional StateX objects that display an image of that animal.

inherit_bird.dart and inherit_cat.dart

inherit_dog.dart and inherit_fox.dart

The first screenshot below displays the built-in InheritedWidget. It’s called, StateXInheritedWidget. Any ‘dependent’ Widgets will be rebuilt when that InheritedWidget is called again. In Flutter, when you call an InheritedWidget again, its corresponding InheritedElement object will eventually call the function, notifyClients(). See the second screenshot below. There, the InheritedWidget’s dependencies are notified in turn, and they are rebuilt.

06_inherited_widget_state_mixin.dart

framework.dart

Note, if the property, useInherited, is set to false, the builder() function is instead called with every rebuild (the third screenshot above). Things work like Flutter’s original State class calling the build() function. The resulting child widget is returned completely foregoing the built-in InheritedWidget.

Make A Splash

As an aside, I thought I’d introduce a simple little splash screen, a little kitten, to the example app. See the video below. Using Fluttery, you’re given three ways to introduce a Splash Screen. See the second screenshot below. The first parameter, splashScreen, takes precedence, but instead of instantiating a widget right there in the initialization, you have the option to instantiate a widget either with the ‘on’ method or with the ‘inline’ method. Note, the ‘inline’ version takes last precedence.

A Splash Screen in Fluttery remains displayed until all the start up operations are completed. The three ‘cat’ image widgets in the example app now also display the little kitten. Cute, no? It takes time to complete such a network call to download an image; best to have something ‘spinning’ while you wait.

main.dart

The Future Is Now

Each StateX object in this example app has a built-in FutureBuilder as well. How many times have I seen apps instantiate Widgets and Classes even before the runApp() function is called?! An example of this is displayed below. They’re instantiated and set up nowhere near where they’ll be used, but since there’s no logical place to perform such operations, the developer has no other choice! Not good.

You need a logical place so such tasks. They have to be completed before a particular screen is displayed, and in the StateX class, such a place is in the function, initAsync().

The first screenshot below is the example app’s first initAsync() function. For demonstration purposes, the app is delayed ten seconds so you can appreciate how cute the little kitten is at startup. Again, this ‘logic’ is found in a Controller class and nowhere near the interface. Nice.

image_api_controller.dart

The example app relies on four public API’s to retrieve images. The first screenshot below, for example, gives you the API used to retrieve bird images. They’re not the fastest Web services in the World. They are prone to lag and complete failure frankly, and so as you see in the second screenshot above, the process is pretty involving. However, it’s necessary, and so it too is tucked away in a initAsync() function found in another Controller class, ImageAPIController.

The ‘image’ Widget has the class type, ImageAPIStateX, and it takes in this Controller (second screenshot below). The Controller, ImageAPIController, performs the actual data retrieval (the image download) while the StatefuleWidget worries about how that data is displayed. Very nice.

network_bird.dart

Controlling Events

Again, the four animal-type InheritedWidgets are inserted into the Widget tree in the app’s home screen. See the first screenshot below. Each with a unique SOC (State Object Controller). For example, the InheritBird class has the controller, BirdController. See the second screenshot below.

inherit_bird.dart

Using Fluttery, each Controller object will have a reference to its assigned StateX object. Doing so provides the means to assign dependency as well as call the built-in InheritedWidget again. See the second screenshot below.

firstState?.dependOnInheritedWidget(context);

firstState?.notifyClients(context)

bird_controller.dart

inherit_controller.dart

That very same Controller is assigned to the corresponding ‘Image’ widget that displays an animal image. For example, in the first screenshot below, you see the class, NetworkBird. *It displays a bird image — assigned the appropriate API information. The State class, *_NetworkBirdState, continues on the second screenshot where the Controller object, BirdController, then registers this Widget (really it registers its StatefulElement object, context) as a dependency to the InheritedWidget in the State object, InheritBird. Easy Peasy.

network_bird.dart

See below, and you’ll find each type of animal has its own Controller:

bird_controller.dart and cat_controller.dart

dog_controller.dart and fox_controller.dart

Take the time to download the example app, and review the process yourself. Note, how the whole process is broken down into parts and delegated to separate classes. This promotes modular development and code reuse and consequently more efficient and more effective implementation and maintenance.

TL;DR

I’ll continue with a deeper dive into the inner workings of Flutter‘s StatefulWidget, State class, Futurebuilder, and InheritedWidgets. Nothing new here. Merely implementing capabilities already found in Flutter as well as following some ‘good programming practices’ every developer should know.

Control Your Future

Once the initAsync() function is called and creates a Future for a StateX object, in most cases, you don’t want to create that Future again. These are synchronous operations that need to be completed once before the StateX object can display its interface.

Such operations would include establishing connections to Web services and or the opening of databases. Opening such connections again and again with every interface change would be grossly inefficient. Unless, of course, you’re calling an particular public API to retrieve a new animal image.

In the first screenshot below, you can see the StateX’s runInitAsync() function is used to determine if its corresponding initAsync() function is to be called again or not. The runInitAsync() function is implemented in the second screenshot below and only returns false when appropriate.

I’ve placed a menu option in this example app to demonstrate how the images would simply not change at all if the runInitAsync() functions involved always returned false. Please, examine the video.

part05_futurebuilder_state_mixin.dart

Going To Dark Side

Again, there are situations where the runInitAsync() function should return false. Rebuilding the app’s whole interface to convey it in dark mode would be one of them. In the screenshot below, when the darkMode() function is called from the app’s menu, not only is the app’s theme toggled (the whole interface rebuilt with the call,App.setState()), but a particular property created for the example app is set to false:

runInitAsync = false;

That property you’ve already seen in the implemented runInitAsync() function displayed above. The first video below runs things properly, but the second video demonstrates what happens if you don’t ever return false in the runAsync() function. Again in most cases, you don’t want to create the Future again (the database is already open). However, if you always return true in the example app, you’ll inappropriately lose your animal images when changing back to dark mode.

return appController.runFuture && appController.runInitAsync

Let’s continue down the example app’s popup menu and see how one can now interfere with those built-in InheritedWidgets.

There’s No Inheritance

Deselect the menu option, Use InheritedWidget, and you’ll have a rather boring example app on your hands. Remember, it’s the four StateX objects listed below that represent the four types of animals displayed. They use their built-in InheritedWidget to take in three additional widgets as ‘dependencies’ to then display those animals in a grid.

In the video below, you can see when the ‘New Cats’ button is pressed, three new cat images appear (the API is providing duplicate images, but you know what I mean). As the video continues, you can see the app is no longer working. The menu option, Use InheritedWidget,is deselected — the named parameter, useInherited, is therefore set to false.

inherit_bird.dart and inherit_cat.dart

inherit_dog.dart and inherit_fox.dart

Note, you can still just tap on individual images and a new image appears. That’s because that’s a separate process. The onTap() method merely calls the setState() function of the associated State object. See the second screenshot below. In the video above, that would be the State class, _NetworkCatState. The setState() method is called, but not before its initAsync() function will load a new image. That’s because the global flag, runInitAsync, was set to true (the first screenshot below). See how this works?

image_api_controller.dart

Going Home

You may have noticed with every menu option selection, the whole screen gets refreshed with a grid display of new animal images. It’s a necessary step in Flutter as that portion of the widget tree is being rebuilt. The app’s home page is a StatefulWidget called, HomePage, and the build() function for its State object gets called with the first two menu option selections.

As you see in the second screenshot below, it’s the controller called,HomeController,that calls that build() function. It’s the controller assigned to the State class,_HomePageState(first screenshot below). Note, State Object Controllers tend to utilize a factory constructor allowing for commands like the one listed below. You’re not instantiating a new instance of the class but working instead with the original instance:

HomeController().setState((){});

Turn To Black

The menu option, Dark Mode, involves the Fluttery Framework’s App object. With Fluttery, you can reassign your app’s overall color theme using the following command:

App.themeData = darkMode;

This command appears in the darkMode() method (second screenshot below) and is called when you select the menu option, Dark Mode. See the first screenshot below. Using Fluttery, the whole interface is then rebuilt with the call,App.setState().Let’s see how that works next.

app_menu.dart

I have the video changing the app to dark mode listed below again. In the first screenshot below, the app’s first State object, AppState,takes in the StatefulWidget, HomePage,as the app’s home page. When the AppState’s build() function is called again (second screenshot below), the MaterialApp widget that makes up this app (running in an Android emulator) is created again. This time, with a ‘dark mode’ theme. Yes, as the video would suggest, this all runs in a flash. Flutter’s widget tree is efficiently fast.

app_state.dart

Recreate State

Lastly, you must be aware that State objects, though recreated in ScrollViews and such lists, are only recreated in Flutter if its StatefulWidget counterpart is called with a ‘new’ key value.

You can see, in the screenshots below, how I guarantee a State class is recreated with strategically placed UniqueKey() functions.

app_statefulwidget.dart

Little More Control

Greg Perry — Fri, 09 Aug 2024 19:48:13 +0000

A Little More Framework for the Flutter Framework makes for better apps

Part of the ‘Little More’ Series, this article will review how introducing a Controller class to Futter’s State class not only encourages clean architecture but provides a State Management solution to your app.

site:flutter.dev insubject:"controller"

A Google search of the Flutter website (flutter.dev) highlights the many Widgets and other classes that include the named parameter, controller:

In each case, a separate class object assists its host Widget by performing its designated tasks. Delegating work to a separate class mirrors the separation of responsibilities advocated by software design patterns. In this case, this usually involves the decoupling of the app’s interface (view) from its event handling, logic, and business rules (controller). Fluttery uses the [StateX] package because it allows State objects to have their own Controllers.

The Play Store app, [Pexel Preview], uses the Fluttery Framework. Below is a screenshot of that app’s AppState object that defines its general look and behavior(see Little More Adaptive). Highlighted with arrows are the Controllers assigned to perform particular tasks. Again, a State object’s Controllers tend to work the logic while the State object itself with its build() function is more concerned with the interface — a separation of responsibilities is made readily apparent.

Delegate, Delegate, Delegate

In the first screenshot below, the tabs displayed in an example app’s main screen are highlighted with arrows. Each is conceived by the class, GridViewScreen. In the second screenshot below, each is assigned a different Controller object. At a glance, this tells you all three will have the same general appearance while those three different Controllers would suggest there will be three separate and distinct processes going on.

In truth, the only difference between these three Controllers is the data source and the title. Not the best example, but it does demonstrate how a State Object Controller (SOC) allows for this separation of responsibility. Each Controller accesses a different data source (model). You can switch out the data source within the Controller class itself without changing one bit of code on the interface side. This arrangement encourages more modular code. It promotes high cohesion and low coupling — all good attributes to have in software.

app_scaffold.dart

categories_controller.dart

Frankly, as seen in the last screenshot above, we can take it further and give no hint at all, on the interface side, what’s involved in those three tabs. Note, how the use of a Controller class also allows for a degree of abstraction. This makes for more adaptive and more robust software.

State Object Controller

You create a SOC by extending the class, StateXController (No relation to the GetXController class). It’s made up of code to reference and work with any and all the State objects it’s assigned to during the app’s lifecycle.

categories_controller.dart

recent_pics_controller.dart

top_vids_controller.dart

Control The Scope

The Controller class is yours to implement in any fashion you require frankly. For example, taking advantage of object-oriented principals, one Controller class used in the [Pexel Preview] app is actually made up of three other classes. Class hierarchies also tend to make for more adaptive and more scalable software.

grid_view_screen.dart

class hierarchy

Note, how the other areas of the app (its interface and its data) have no idea this hierarchy exists—another characteristic of a clean architecture.

Control The State

Because a ‘Controller’ class is introduced to the State class, Fluttery has introduced a particular architecture — one that assigns distinct ‘roles’ to State objects and their Controllers. In particular, this arrangement allows you to rebuild your app’s interface from outside the Widget tree at any time and from anywhere — a core feature achieved by all State Management solutions.

Call setState() outside the State class anytime, anywhere

The term, State Management, originated from Web developers working with the ‘stateless’ environment that is the HTTP protocol — HTML pages famously did not retain state. State Management came about with the use of Sessions, Client-side cookies, etc. Since Flutter already retains state right out of the box, I would suggest Google took liberties and chose the term to advertise Flutter to the large Web development community.

I'd prefer they didn't use the term, but they are a for-profit company after all. They want everyone to use Flutter. For Flutter, State Management best refers to the faithful rebuild of the current interface if and when the information displayed in that interface has changed:

Which State Management

Again, the current pile of ‘State Management solutions’ keeps track of the current interface displayed and will rebuild it when appropriate to convey changes. The screenshots below showcase how a State object keeps track of its controllers, and how the controllers themselves can update the interface at any time and from anywhere.

The third screenshot is of Page 2’s controller class, and you can see there are many ways to update that interface. You always have reliable access to a particular State object to rebuild that portion of the screen.

Again, a Controller class is not new to Flutter. The code in the State class involves the interface while the code in the State Object Controller class involves everything else — a proven efficiency yet ‘keeping it Flutter.’

Cheers.

Little More Error Handling

Greg Perry — Fri, 02 Aug 2024 15:44:22 +0000

A Little More Framework for the Flutter Framework makes for better apps

Part of the ‘Little More’ Series, this article will detail the Error Handling available to you when using the Fluttery Framework.

Handle your errors. True, you’re the greatest programmer that ever lived, and your code will never crash. However, I’m seeing code out there that assumes everything will run as expected, and we know that’s not good. Your code must anticipate the unexpected. It must! Here’s how.

In the first screenshot below, we see a Fluttery Framework example app starting up. Note, that’s not your traditional runApp() function. The original runApp() function is called, but not before establishing some error handling first (see second screenshot below).

Even before that, when using Fluttery, if the Widget instantiated and passed to that runApp() function extends the class, AppStatefulWidget, it creates the AppErrorHandler class object already right in its constructor (see third screenshot). And so, right from the start, your app has an Error Handler ready to go! Tap the screenshot’s captions to view the code.

main.dart

run_app.dart

app_statefulwidget.dart

If you like, you’re then free to call the App’s Error Handler yet again (see below) and establish any third-party error handler (Firebase Crashlytics, Catcher 2, etc.). They will then catch errors for you in the fashion that they do.

working_memory_app.dart

The State of Error

In the video below, there’s an exception thrown with every tap of the button, but you’d never know it. The exception is recognized right there in the State class resulting in the counter incrementing correctly.

In Fluttery, every State object can perform its own error handling. Imagine a particular error is thrown in your app from time to time. A network drop for example. Whatever it may be, your app encounters an error in certain circumstances, but you’re ready for it. Your State object has a built-in error handler:

void onError(FlutterErrorDetails details) {

The video depicts the Fluttery Framework’s own example app. You can see in the first screenshot below, a FloatingActionButton widget (if not testing the app) will explicitly throw an Exception. The second screenshot is of the residing State object. Its Error handler calls the onPress() function in response to this particular error and successfully increments the counter.

app_counter.dart

It’s a very simple example, but it does demonstrate the potential here to modularize the error handling in your app. Isolating parts of your code more susceptible to error simply makes for a more reliable and more robust app.

Pass It On

The error now continues up the Widget tree. It may be handled by the State object, but every error is an ‘app error’ and will be logged by the App’s State object in its own onError() function. For example, the error introduced above is running from a phone emulator. Hence, the error is eventually reported in the IDE’s console screen. See below.

When I say ‘handled by the State object’, I mean acknowledges the error and may even address the error. However, any error must then propagate further up to the App’s Error Handler. You don’t want seemingly ‘handled’ errors stopped at a State object’s onError() function. Such an arrangement I feel would be prone to abuse — developers would whole-heartedly stop the propagation and ignore errors! That wouldn’t be good either.

No, the developers overseeing the app as a whole (i.e. with access to the App’s State object) should have the final say and meet each error in their own Error Handler. Note how Fluttery works for the lone developer as well as in a team environment.

Further, do you see how Fluttery naturally compartmentalizes the app’s code? I feel Flutter is naturally ‘State-object-centric’ as the Google engineers intended. Each State object could stand alone as its own particular app in a sense, and this concept is only accentuated using the Fluttery Framework package.

As for the App State object, it has two Error Handlers. You may have established a third-party Error Handler, and they will catch errors certainly, but these errors will also pass through the onErrorHandler() function and the inErrorHandler() function if you’ve implemented them.

You’ll find the App’s State object has a number of functions prefixed with ‘on’ and ‘in’ (see Little More Adaptive). Traditionally, the ‘on’ version, if implemented, will supersede the ‘in-line’ version. However, I’ve placed so much emphasis on Error Handling that I allow for both the ‘on’ and ‘in-line’ versions to run in turn. In my mind, you can’t have enough Error Handling! Implement them both if you want.

The two screenshots below demonstrate how they’re used. The ‘on’ version is in the first screenshot below — a standalone function called after the third-party Error Handler if any is called, or it’s called on its own in response to an error in the app. The second screenshot displays the ‘in-line’ version. It’s always found passed to the App State’s constructor, and is always called right after the ‘on’ version.

You can see I’ve even overridden the State object’s onError() function. You’re free to override it if you must. However, please don’t ignore errors — it won’t benefit anyone in the end. Regardless, you have complete power over your app’s error handling.

app.dart

With Fluttery, you’ve no excuses. Despite your obvious prowess, errors will occur in your code. Fluttery invites you to acknowledge errors where they’re likely to occur — right in the running State object. They then go to the App’s first State object. It’s the class that governs not only how the app looks and behaves, but how it handles its errors as well.

Cheers.

Little More Life Cycle Handling

Greg Perry — Fri, 26 Jul 2024 17:39:28 +0000

A Little More Framework for the Flutter Framework makes for better apps

As part of the ‘Little More’ Series, this article will review the Life cycle events that should be considered when running your app. Events that are made readily available to you when using the [Fluttery Framework] package.

iOS Application Life Cycle

Android Application Life Cycle

Like its iOS and Android counterparts (see above), Flutter StatefulWidgets have their own life cycle. Below is a graphical depiction of that Life cycle as it’s currently understood. Follow the arrows, and you’re following the ‘sequence of function calls’ when certain circumstances occur. Using the Fluttery Framework, your State object will always have a corresponding function to address any such event — as best as it‘s able anyway.

You see, Flutter is a cross-platform solution — the Flutter engine runs on top of a completely different operating system depending on the device. As such, there are two separate life cycles involved when it comes to Flutter (denoted in the graphic by the dotted line). Unfortunately, as of this writing, these two life cycles do not acknowledge each other at all.

For example, Flutter will not call a StatefulWidget’s deactivate() and dispose() functions whenever a user has ‘unfocused’ your app with some hand gesture — only to terminate it soon after. For those developers working on the mobile platforms in particular, this has become an issue.

With Fluttery Framework, however, an effort is made to call the deactivate() and dispose() functions of all the app’s StatefulWidgets whenever such a scenario occurs (See second screenshot below). Unfortunately, as of this writing, it comes down to the particular operating system involved whether they’re called or not:
“AppLifeCycleState.detached is not called when app is closed quickly”

state_extended.dart

The video below has the example app, widgetsbinding_observer_example, running on a mobile phone emulator. This app is peppered with print() functions so to convey when particular events are triggered and in which State object. In the video, the app loses focus right away but then is returned to the foreground — only to lose focus again before being terminated. Without intervention, that screen’s deactivate() and dispose() functions would never have been called. The graphic is again presented below for you to compare with the adjacent print() function calls.

Rule #2 To Keep In Mind

Regardless of platform, remember to close databases and other time-critical resources in the **hiddenAppLifeCycleState() method only to open them again in the method, **resumeAppLifeCycleState(), if and when the user returns to your app.

This can get really complicated, but the Fluttery Framework is here to help you.

Another quick example is demonstrated in the video below. Page 1 and Page 2 are two StatefulWidgets called one after the other. The user then returns from Page 2 to Page 1. Again, the example app with its many print() functions details all the events that occur (see below). In this case, you can see when Page2 was closed, the functions, deactivate() and dispose(), are called in quick succession.

Better To Deactivate Than Dispose

Remember this: You’ll have no idea when a State object’s dispose() is called — if ever. This function is called by the Flutter engine as part of its ‘garbage collection’ process. It’s to the engine’s discretion when the dispose() function is called (or never called under certain memory constraints), and so, if your StatefulWidgets have any time-critical resources being freed and such, it would be more reliable to do so in their deactivate() functions and not in their dispose() functions.

Rule #1 To Keep In Mind

Regardless of platform, if no longer required by the closing StatefulWidget, remember to close any databases and any time-critical resources in its **deactivate() method only to open them again in its method, **activate(), if the running StatefulWidget is not being closed but instead is being moved around the Widget tree (e.g. Reordering items in a ListView widget).

The Series of Events

Let’s quickly go through the event functions calls listed above and suggest what they represent. As you know, when a State object is first created, it is these two functions below that are called. The first State object is called, _AppState.

The Fluttery Framework is ‘aware’ a router is involved in this example app, and so the ‘home’ screen with its State object, _Page1State, is started up and will soon call its initState() function, but not before its event function, didPush(), is called firsr. This allows you to run code ‘when a StatefulWidget is just opened by a Router.’

The next two print() functions are displayed below. They tells us ‘Page 1’ is now being displayed with a zero count.

Because this was run on a mobile phone emulator, the painting and sizing of the app’s interface triggers the didChangeMetrics() in the two StatefulWidgets that make up the app so far. Note, how they’re called in the order they were instantiated — with the help of the Fluttery Framework.

The next line tells Page 1 that the next screen to be displayed has been selected while the second line tells Page 2 it came about because of a router. Note, there’s no reinventing the wheel to achieve this. Fluttery is just implementing what’s already there in Flutter to note these events.

The next three lines tells you ‘Page 2’ is now displayed with a count of zero.

In the next screenshot below, both the first screen and second screen are notified when the user has returned back to Page 1. Great stuff!

Consequently, Page 2 is about to be removed from memory. Therefore, the next two lines appear. Again, the deactivate() is a better place to ‘clean up things’ before returning to the previous screen. The dispose() function just happens to be called right after deactivate() frankly. Under different circumstances beyond your control, it could just as easily never be called.

Timing is Everything

Playing around with the example app, you’ll discover that Page 5 has a Timer displaying ‘Word Pairs’ introduced in the Flutter website’s codelab called, “First Flutter app”. See below.

Look how the Timer object is handled. It’s turned on and turned off when appropriate. You have the ready-means to handle all your running resources effectively and efficiently using Fluttery. Moving on from Page 5 to the next Pages without addressing the Timer object, or an active stream or some other free-running process is just sloppy! In a sense, you’ve just implemented a memory leak otherwise!

The second screenshot is the very code called when moving from Page 5 to Page 6 and back. Highlighted by the first red arrow is the Timer being turned off while the second red arrow highlights the Timer being turned back on. The first screenshot lists the print statements conveying the event functions involved in the video — its last portion showing the app closing is again displayed further on below.

You can see how the ‘Operating System Events’ are covered by the Fluttery Framework. You can see this by comparing the print statements to the life cycle graphic below. Note, being on a phone emulator running on a laptop, Fluttery even recognizes the memory constraint that occurs by calling the function, didHaveMemoryPressure().

Look how all the Operating System Event functions in all the State objects currently running in the app all fire in turn and in the order they were instantiated. The host device is up to something, and all the running State objects should be aware of it.

The example app, [widgetsbinding_observer_example], has nine separate screens called one after the other. Note, how the State objects and their accompanying controllers (Business Logic Components like in the BLoC architecture) are triggered in the order they were instantiated.

Download the example app, [widgetsbinding_observer_example], and see how Fluttery is working for you to make your Flutter app more aware of the platform device it runs on. It’s a necessity if you want a better app.

Cheers.

Little More Adaptive

Greg Perry — Sat, 20 Jul 2024 15:53:11 +0000

A Little More Framework for the Flutter Framework makes for better apps

I began working on this [Fluttery Framework] package in 2018 to help with my apps — supplying the typical functions and features needed by a production-worthy app.

As part of the ‘Little More’ Series, this article will focus on Fluttery’s high adaptivity that is simply achieved by consolidating what Flutter already provides you.

Flutter apps traditionally begin with a Widget passed to the runApp() function. Using Fluttery, an app starts with a StatefulWidget passed to the runApp() function, and it is called, AppStatefulWidget. That means a State object called, AppState, is your app’s first State object and directs your app’s overall appearance and behavior. Below are screenshots of three apps using the Fluttery Framework. Tap them individulally for a closer look. Tapping their corresponding captions will direct you to their source code.

app.dart

app.dart

If you know Flutter, you’ll know Fluttery. You’ll also know of the many parameters available to you when using the MaterialApp widget or the CupertinoApp widget. All those parameters and more are listed in the AppState class making for a very adaptive Flutter app indeed. See below. You’re free to even use third-party packages like Fluent_UI calling its widget, FluentApp, instead.

app_state.dart

One common complaint by seasoned developers now working in Flutter is, because of its declarative approach, the many parameters to a class object in Flutter have to be passed already ‘compiled’ and supplying a value before the ‘App’ State object is even instantiated. The String parameter, title, found in the MaterialApp and the Cupertino widget is a quick example of this.

However, many class objects in Flutter do take in a named function as a parameter allowing for a computation to occur only ‘when that parameter value is needed.’ This approach offers more options. The Google engineers themselves knew the value of this because they included a function parameter called, onGenerateTitle, along with the parameter, title. For example, doing this allows developers to supply a localized title to their apps by calling the onGenerateTitle() function. If the function parameter, onGenerateTitle, is passed, it takes precedence over the parameter, title.

However, most of the remaining parameters in the MaterialApp widget and CupertinoApp widget do not have a function parameter equivalent. It would make an app more adaptive if that was the case. It would allow for more options, more functionality, and more adaptiveness to the developer, wouldn’t it?

It would.

Note what’s highlighted with an arrow in the three screenshots below. The first screenshot has the original source code with the traditional parameter, title, assigned the String, ‘Demo App’. The next two screenshots only come about using the Fluttery Framework.

Instead of using the function parameter, onGenerateTitle, you have the separate onTitle() function to reliably generate your title. In the third screenshot, ‘in-line’ function parameter, onGenerateTitle, can be replaced with the function parameter, inTitle(), as it too generates the app’s title right there in the constructor. Not the best example. However, this means every parameter now has an ‘on’ and an ‘in-line’ function parameter! This gives you options, and I like options.

app.dart

With Fluttery, every parameter introduced to you earlier also has a corresponding ‘on’ function allowing you to supply values only when required and, in some instances, only when your app is ready to supply them. This means more capability for you.

As you see in two screenshots depicting the AppState class below, if an explicit parameter value is not provided (i.e. equals null), the if-null operator (??) will call the appropriate ‘on’ function.

app_state.dart

In the first screenshot below, you see how the State object’s initState() function is replaced by its ‘in-line’ counterpart. It’s called right there in the constructor showing the initialization required. However, it behaves like its corresponding ‘on’ function — called only when needed. Another example is the second screenshot showing the supported Locales right there in the constructor call, and how a third-party package deals with the app’s translated text.

There’s no re-inventing of the wheel here. It’s just a little tweaking of a great cross-platform solution. Fluttery just makes software development that much more adaptive.

Cheers.

The ‘Little More’ Series

Greg Perry — Fri, 19 Jul 2024 19:10:03 +0000

The ‘Little More’ Series

A Little More Framework for the Flutter Framework makes for better apps

Little more Adaptive
Little more Life Cycle Handling
Little more Error Handling
Little more Control
Little more Efficient
Little more App
Little more Ability

I’ve always said, as great as Flutter is, you will not create a ‘production-worthy’ app using Flutter right out of the box. Of course, making such a statement is not without some pushback:

“I don’t understand why I should use and learn some Fluttery Framework, when I already use and know Flutter.” — reddit.com/r/FlutterDev

“I would definitely say you can build a production-ready app right out of the box, it all depends on the feature requirements.” — reddit.com/r/FlutterDev

Prove It

That was about a year ago, and I’m still steadfast in my position. I began the [Fluttery Framework] package back in 2018 supplying the typical functions and features needed for a production-worthy app. It certainly made my Life easier when building apps as it became a culmination of what Flutter already offered as well as sound Dart packages from the Flutter community.

Each article in this series will have a title suggesting what I felt the ‘right out of the box’ Flutter needed a ‘little more’ of to produce apps ready for release. In most cases, it was simply a matter of implementing the very classes and core packages already found in Flutter.

It’s a Choice Not a Chore

My motto has always been ‘Keep It Flutter’ when writing Fluttery. It works with Flutter; not on top of it as a separate approach. It doesn’t impose itself on you. It works with Flutter because it works like Flutter — it looks like Flutter. If you know Flutter, you’ll know Fluttery.

I needed a framework to quicken the building of Flutter apps; to enhance the building process resulting in a reliable and robust end product. However, as Dave Farley suggests, one that wouldn’t impede my code but fulfill the needs of each unique project. Have I done it? You be the judge.

Cheers.