Flutter – First Impressions of the New Cross-Platform Technology

Flutter is the latest technology on the market promising “cross-platform development.” Platform-independent development is probably the dream of every developer who deals with mobile applications. One code base for logic and interface, thus reduced effort in development and maintenance, and therefore reduced working hours. With such ideas, even accounting and controlling get weak in the knees. In fact, there are already numerous technologies on the market that have set exactly these points, or at least parts of them, as their goal. React-Native, for example. But obviously none of these technologies has been able to establish itself definitively against pure Android or iOS development. Since the beginning of this year, Flutter has been in beta phase. This is once again a technology that promises “fast development” and “native performance” with just one code base for iOS and Android (https://flutter.io/). But how does Flutter perform in use?

Flutter comes from Google and is based on Dart. As is typical for Google, the documentation around Flutter is quite well done. From getting started to the first working click prototype, you can find a step-by-step guide at https://flutter.io/get-started/install/. Google also offers a whole series of videos on Flutter under the Google Developers Channel on YouTube.

It gets interesting once the prototype is running and you can test the first advertised features, like the “hot-reload” function. Indeed, the update after changes in the code works quite well and reliably, both on the emulator and on connected hardware. Delays only occur when the app crashes or you end it for other reasons. When compiling using the “flutter run” command, a comparison with the last version takes place. However, this comparison works extremely unreliably, so often a version starts on the device/emulator that is actually long outdated. There’s no way around deleting the entire build folder using the “flutter clean” command. It can take a minute before the app starts again after that. During development of an app, this might be a disturbance for some.

First a bit more theory: Flutter is based on reactive programming. The data flow can thus be understood as a tree structure. Changes to an element in this structure are automatically propagated to child elements as well. Google refers to this tree structure as a “widget tree,” where widgets are prefabricated elements that, for example, allow you to determine the position of an element. An overview of existing widgets can be found at: https://flutter.io/widgets/. Of course, there’s no getting around creating your own widgets; there are the two base classes “Stateless Widget” and “Stateful Widget.”

Example: Stateless Widget

A “Stateless Widget” is a static class. In the example, a widget is created that displays a text with font size 15 centered in the middle. The text is passed from a parent widget. What is displayed can thus change at runtime but must be induced from outside.

Example: Stateful Widget

This is also the crucial difference from a “Stateful Widget.” The “setState” method from the example changes the state of the widget with each call. This change is also passed on to child elements and recreates them where necessary.

Something that takes getting used to about widgets is especially the layouting. For example, there’s a Padding widget that, as the name suggests, only serves to create padding around a child element. At the same time, however, there’s also a Container widget that can also create padding around a child element, among other things. This may require some familiarization time until you have an overview of the numerous widgets. On the positive side, however, is the easy use of elements with Material Design: https://flutter.io/widgets-intro/#using-material-components.

Another topic is data storage. A “Stateful Widget” reaches its limits as soon as data needs to be passed down multiple levels in the tree structure or when a child element should change the state of a parent element. Flutter offers its own solution approach as a so-called “InheritedWidget” (https://docs.flutter.io/flutter/widgets/InheritedWidget-class.html). How this is used for data storage is explained very clearly by a user on Stack Overflow: https://stackoverflow.com/a/49492495.

In addition, there are other approaches, such as Redux, which should please some JavaScript / React developers. An overview can be found in the following repository on GitHub: https://github.com/brianegan/flutter_architecture_samples.

In general, the widget concept is easy to understand, the data flow is clearly visible, and elements can be well structured using this concept. The view on iOS and Android devices is also convincing. Flutter manages to make design adjustments obsolete and thus takes a big step towards a “single code base.” An overview of existing apps that use Flutter can be found at https://flutter.io/showcase/. If you’d like to put together a layout yourself and have the corresponding code generated, you can try this on the following page: https://flutterstudio.app/.

Finally, a few thoughts on the future of this new technology. In my view, whether Flutter prevails depends mainly on two factors: First, what happens with Fuchsia, Google’s new operating system based on Flutter. Should Fuchsia actually replace Android, this would herald an enormous increase in the Flutter community. Which brings us to the second point. Currently, the community around Flutter is very small. There are few plugins and libraries, which is likely to deter many development teams initially. Depending on how these points develop in the near future, Flutter will be able to establish itself or not.