Using FutureBuilder topic

Wait For The Future

This topic presents what I felt was an essential feature missing in Flutter’s original State class: The means to deal with asynchronous operations in a State object before proceeding to then render its interface. Its been common practice to perform such tasks even before the runApp() function is called! A seemingly disjointed and not a very intuitive approach. Best to keep it clean, keep it concise, and keep it Flutter. Flutter already provides the FutureBuilder widget after all. The FutureWidget is utilised in the StateX class.

Looking at the three gif files. The first one depicts the one StateX object waiting to continue while the second gif depicts twelve StateX objects waiting to continue. Each StateX object has its own individual asynchronous operation going on, and each uses Flutter’s own FutureBuilder widget to wait for such operations to complete.

The third and last gif file depicts the whole process. It’s the startup process of the example app that accompanies the state_extended package. Note, since this app is running on an Android emulator, those spinners are from the CircularProgressIndicator widget. If it were running on an iOS phone, the CupertinoActivityIndicator widget would be used instead to produce the iOS-style activity indicators. Flutter is a cross-platform SDK after all.

The spinner in the first gif file is caused by the controller, ExampleAppController. It’s initAsync() function has a Future.delay() function 'pausing' the app for some ten seconds. You can see this in the first screenshot below. The twelve spinners in the second gif file, is the result of twelve StateX objects each individually waiting for the Internet download of a particular image of a bird, dog, fox or cat. That's seen in the second screenshot below.

app_controller.dart image_api_controller.dart

Note, the Future.delay() function was used for demonstration purposes. There’s no real asynchronous operation going on in the controller, ExampleAppController. However, it could have just as easily been the opening of a database, the calling of web services, and the downloading of data as well. Such operations can now easily be performed in a State Object Controller. Its associated State object will wait until completion with something spinning away on the screen. Alternatively, you are allowed to load a splash screen instead and wait until completion.

By design, the StateX's FutureBuilder widget may be called again and again. Generally, however, the future generated should not be regenerated again and again. After all, you don't want your database opened or your web services called again and again...unless you do. If that's the case, simply implement the asynchronous operation in the runAsync() function instead of the initAsync() function. The example app does just that allowing for new animal images (i.e. new downloads) with every refresh of the screen. However, in the example app, the initAsync() function continues to be implemented, but so is the runAsync() function calling the initAsync() function in turn so the _ranAsync flag is not set. See the two screenshot below. You have that option.

image_api.dart state_extended.dart

Indeed, but in most cases, it is only so to call any and all of its StateXControllers’ own initAsync() functions. Since most asynchronous operations have no direct relation to an app’s interface, you’ll likely have your asynchronous stuff running in a State Object Controller (SOC) with the rest of the app’s business logic.

Mixins

FutureBuilderStateMixin StateX class Using FutureBuilder
Supply a FutureBuilder to a State object.