Better Asynchronous Operations

Better Asynchronous Operations

A slick built-in means to handle Asynchronous Operations

I’ve written up an example app in the GitHub repository called, , discussing its use and its features.

However, the example app used another Mixin as well. One which provided another built-in feature to your State object. This time, it’s a FutureBuilder Widget. That’s what this article will talk about. If you’re not interested, at least this article will demonstrate using a Mixin to you, and a code walk through on how the FutureBuilder Widget works. The screenshot below is of that Mixin where a FutureBuilder Widget resides in the State object’s build() function.

Using the Mixin, FutureBuilderStateMixin, a FutureBuilder Widget is integrated into your State object to better handle any Asynchronous operations that need to be done before the State object can display its content. Akin to the State class’ initState() function, this Mixin provides the State class with the initAsync() function as a slick and easy approach to complete such operations. I use this approach instead of executing asynchronous tasks even before calling the runApp() function as many other developers do.

Future<bool> initAsync() {}

In the first video below, the example app is started up in a simulator. The splash screen that appears is merely a sleepy kitten rolling over in the center of a black background. It runs for about ten seconds. The first screenshot below is that of the State class using the Mixin. You can see how that 10-second time is specified in its initAsync() function. The Splash screen itself is returned by the Mixin’s function, onSplashScreen:

Widget? onSplashScreen(BuildContext context)=> null;

Of course, your Splash screen could be much more elaborate than that. For example, it would have your company logo taking up the whole screen with some spectacular animation. Or nothing at all, as you see in the second video above, in which case it defaults to the appropriate ‘spinner indicator’ depending on the platform.

However, note how modular this approach is. For example, a standard procedure is to open all the databases needed at the beginning of your app. Therefore, opening them in the app’s first State object makes for a logical location. No? ‘Everything in its place’ as it were. You can dictate whether the app continues or stops right there if anything fails at startup. If there are further databases or other asynchronous operations necessary, you can perform those only when necessary in other screens (in other State objects) further on in the app and not before. This saves on resources.

Initiate Your Future

In the screenshot above, you saw highlighted the Mixin implemented to the State class, _MyAppState. Its initAsync() function runs for ten seconds emulating asynchronous tasks running to their conclusion. Note, when using this Mixin, you use the buildF() function instead of the build() function to define the interface.

The first screenshot below is of the Mixin itself. You can see the buildF() and onSplashScreen() functions. The build() function is already implemented running the initAsync() function. The Mixin continues in the second screenshot. There, you can see the initAsync() defaults to true and is actually called once in the runAsync() function with the flag, _ranAsync, set to true. After all, once open, you don’t want to open your databases again for example.

Another Future

The example app is relatively simple, but there are a number HTTP GET requests initiated by user interaction accessing some public API’s. Frankly, these API operations can take time to complete. Such API calls must also fail gracefully as well as wait patiently til completion. All this is provided in the Mixin, FutureBuilderStateMixin.

The screenshot below is of the code involved in each ‘image request’ you see completed in the video. You’re seeing twelve StatefulWidgets displaying their unique images. Each is making an HTTP Get request. Their State class uses the Mixin, FutureBuilderStateMixin, and as such will call their corresponding initAsync() function to complete such tasks.

Your Future Platform

I switched out the platform indicator, UniversalPlatform.isIOS, with bool, true, just to show how funny the CupertinoActivityIndicator Widget looks on an Android phone emulator (see video below). That means, however, when running the example app on an iPhone, you’ll get that spinner instead.

and place some breakpoints here and there and see how it can work for you.

Cheers.

Wait For It

Further on, in the _subcribe() function, after defining the Future object’s THEN clause, a new AsyncSnapshot class object (_snapshot) is created with a ‘connectionState’ value of, ConnectionState.waiting. See the first screenshot below. The Future object is not yet completed, and so the ‘builder’ is first called in the State object’s build() function with that _snapshot object, and it has the ‘connectionState’ value of, ConnectionState.waiting. See the second screenshot below.

The builder, in this example app, is called, _futureBuilder. It is displayed in the first screenshot below. It tests for snapshot.connectionState == ConnectionState.done, and if it’s not, continues to call the onSplashScreen() function. After that, if there’s still no Widget provided, the appropriate spinner is instead returned in the FutureBuilder Widget’s build() function. Still with me?

It’s Your Future

If all goes as intended, the next time the FutureBuilder’s build() function is called again, that Future object will have completed calling the State object’s setState() function and creating a new AsyncSnapshot class object (_snapshot) with a ‘connectionState’ value of, *ConnectionState.done. *All this is done in that THEN clause. See the screenshot below.

Widget build(BuildContext context)=> widget.builder(context,_snapshot);

Build Again

With the setState() function call, the State object’s build() function is called again. Of course, that means the example app’s Widget builder, _futureBuilder, is called again. The screenshot below of this function depicts what happens next. With the following two conditions true,snapshot.connectionState == ConnectionState.done

andsnapshot.hasData,the buildF() function is called.

In the second screenshot above, we see the buildF() function defined in the example app. It returns the StatefulWidget, HomePage. The screenshot below is the State class, HomePageState. It uses the buildIn() function instead because it has the built-in InheritedWidget. However, that's another story.