Asynchronous Programming in Flutter - Shallow Dive into Google's Mobile App Framework

This month, Bob continues his look at mobile app programming from the perspective of an embedded system designer. He begins a shallow dive into Flutter, the mobile app framework from Google, by describing his transition from React Native to asynchronous programming in Flutter.

- Bob Japenga

Introduced the Flutter ecosystem and discussed a little about Flutter in my article, “An Embedded Designer Looks at Mobile App Development,” in the April 2024 issue of Circuit Cellar [1]. This month’s article assumes you are familiar with the terms that were introduced previously, so it might be helpful for you to review my earlier column. Some definitions I will be using here are given in Table 1.

Being somewhat crazy, I took the entire app that I wrote in React Native, and rewrote it in Flutter. What an adventure! And it has taken me so much longer than the original React Native app. Overall, I like the Flutter structure better than React Native, but I find the non-orthogonality of the architecture and imprecise documentation completely maddening [2].

Programming in Flutter is like driving in Boston, where there are so many one-way streets that you are sure that some day you will be driving down a one-way street and reach an intersection with four streets all one-way to the spot you are in. “You can’t get there from here!” Sometimes with Flutter, you find yourself unable to define the function you need with the types that you need, because of language restrictions.

FLUTTER/DART ASYNCHRONOUS PARADIGM: UNDERLYING ARCHITECTURE

We embedded systems designers need to know how things work under the hood, because without this information, we normally cannot understand the documentation provided. Here is my peek under the hood of Flutter asynchrony.