Flutter, present and future of cross-platform mobile development #2

This is the second and last part, of an article made to explain why this great framework could be the best choice for mobile development. The decision to split this exposition into two different columns was to deepen the argument without confusing or boring the reader. I remember that if you don’t know not even a little about Flutter it is recommended to read first our article on Flutter essentials so as to get the message without gaps.

In the first article we examined the two best advantages of Flutter for cross-platform front-end mobile development. Now, let’s go with the third one.

Flutter’s layout

As its name indicates, layout sets the arrangement, the format, the organization of elements. It configures the parts and compose them so as to build something that makes sense, like a template. Among others, it specify the position and size of every piece (in this case, widgets) complying a set of rules (usually constraints). If you are involved in the world of app development, whether web or mobile, layout will be familiar to you.

Normally the way of doing layout is to settle a lot of strict, rigorous rules that cover all widgets, and those rules implement some layout methods. That’s what happen with CSS (in mobile development its the same). The CSS properties (rules) are applied to HTML tags (widgets or elements).

Using those properties are included certain number of layout models (box models, tables, columns and more recently flexboxes and grids in CSS). However, the developer can’t create or add new layout models, they have to be implemented into the language and for all users and developers (on all browsers in CSS, as made with flexbox and grid).

In addition, the rules can interfere and even collide with each other, and as a result elements usually have lots of rules applied, what makes layout slow. It also doesn’t help that the performance is often o(N^2), which means that as a result of an incrementation of the number of elements, layout performance drops even more.

In Google, they found that:

• Most layout frequently is relatively simple and local to a subtree of element, using one layout model (what means low rules needed to catch the behavior)
• Setting aside the typical model of layout you can get relevant performance gains

So they concluded that flipping the ideas about layout it could be clearer and simpler:

• Alternatively to having a big number of layout rules able to be applied to any element, each element would specify its own simple layout model.
• As each element has a much lower layout rules to consider, layout would be optimized.

And that’s what they made with Flutter’s widgets. In fact, in order to simplify layout further, they converted almost everything into a widget.

In Flutter everything is a widget, the layout also. You can check the Widget Catalog on the docs website. As an example, Row layout widget arranges a list of widgets (its children) horizontally. The Align widget aligns its child within itself and optionally sizes itself based on the child’s size. That easy.

Row(
        children: <Widget>[
          Align(
            alignment: Alignment.centerLeft,
            child: Padding(
                padding: EdgeInsets.all(8),
                child: Text("Hello World",
                    style: TextStyle(
                        fontSize: 30,
                        fontStyle: FontStyle.italic,
                        fontFamily: "Roboto",
                        color: Colors.blueGrey))),
          ),
          Align(
            alignment: Alignment.centerRight,
            child: Padding(padding: EdgeInsets.all(8), child: FlutterLogo()),
          ),
        ],
      );

Padding and centering are widgets. Themes are also widgets, which apply to their children. Text style properties are a widget called TextStyle(). And even applications and navigation are widgets.

There are good few of layout widgets. Centers, columns and rows, stacks, lists and grids… And a layout model to make scrolling, the Sliver Layout Model, because layout is so fast that can be used for scrolling. It is not a minor thing, since scrolling have to be so smooth that the user does not know that he is rendering every time. By using layout for scrolling, advanced kinds of scrolling can be implemented in Flutter, like shown in GIF animations below.

Finally, it is quite remarkable that Flutter almost always can do layout in a single pass. That means linear time or O(n) implying the possibility of holding lots of widgets. Anyway Flutter also does caching and other things to avoid doing layout at all, when possible.

Custom-made designing

Moving widgets and its rendering from the platform to the app results in easy customization and new widget’s creation, and developers can completely design according to the company’s brand. It’s more flexible, in one word.

Moreover, Flutter implements a wide range of Material Design tailorable widgets for Android and iOS, built precisely because of the customizability that Flutter offers. Those widgets emulate perfectly the OEM widgets of multiple native platforms. Developers can do the same according to their needs and desires.

Tree managing

If you got here reading, you will know that both Flutter and React (React Native also) use some-kind of widget tree. In reactive web views that tree is the virtual DOM. DOM (Document Object Model) is the interface that treats an HTML document as a tree structure wherein each node represents a part of the document, so as to JavaScript can manipulate these nodes with its API. Virtual DOM, instead, is an abstract version of the DOM based on objects directly in JavaScript.

Reactive web views work like this:

• The virtual DOM, which is immutable, is rebuilt each time anything changes
• The virtual DOM is contrasted to the real DOM so as to get the minimum changes needed, and then those changes are applied to the real DOM to update it
• The real DOM is re-rendered and painted into a canvas

You may now be thinking that it seems stupid or a useless extra work, but it is done like this because it is very expensive to manipulate the HTML or real DOM. React Native works similarly, but instead of DOM and virtual DOM it manipulates the native widgets of the mobile platform, and builds a virtual tree of widgets. That virtual tree of widgets are connected to native widgets by the bridge, keeping the data passed to a minimum.

What about Flutter? As said in the first part of this article, the widgets and the renderer have been moved from the platform to the user’s app itself. That proceeding implies that although React Native was a great innovation for mobile development (Flutter has taken inspiration from it) Flutter has gone further and has taken a much bigger step.

There is no bridge, nor virtual widget tree, nor native widgets needed, and that means three layers removed at a stroke. Flutter simply renders its widget tree and represent it in the platform canvas, which is pretty fast. No more animation performance problems and tricky solutions such as those in React Native, because it occurs in the Flutter realm. Furthermore, its renderer is more original and innovative than that of React Native (and others), repainting “by widget” only those that have to be updated and caching unchanged widgets.

Lastly, highlight that Flutter is open source and its repository is on GitHub, so you can change or modify easily each as needed.

Hot Reload

Apart from widgets, flutter also stands out for the hot reload. This is a fast feature that allows applying changes to a Flutter app while it is running, reloading the code without altering the app state. It is so fast that usually last less than a second, and if there is an error you can fix the error, hot reload and go on.

The inconvenience here is that making a full reload, while is fast compared to other technologies, is slower than native platforms, and specially on iOS it can be a bit annoying. Still and all, I think that advantages worth far more than this trouble. Painting instantly your app after almost every little change is a a very valuable and quoted feature.

Compatibility

If you are used to code native Android apps with Java or Kotlin, library compatibility problems, multidex, Android X, etc will be concepts that you will understand and hate in a certain way. With Flutter that bureaucracy does not exist. Since widgets belong to your app an not to the platform, you avoid these stuff.

Your project will work perfectly on Android from Jelly Bean and iOS from 8.0 in all versions and devices. No more compat libraries. Furthermore testing apps on older versions will be reduced and your app will operate on future OS releases. Nevertheless, if you import libraries made in source code with native code, you can alike get into trouble.

Framework updating

A possible question could then be what happens when a new version of iOS and Android is released. Will it take long for Flutter widgets to be updated if there are some new features, native widgets, or changes in a current widget? Well, it might be, but:

• Google use Flutter internally, so they are incentivized to keep updated the widget sets and close to the current platform widgets.
• Google isn’t the only user of Flutter with an incentive to keep the widgets current. Anyone can easily update widgets, even you.
• In the case that you don’t want to have the new change reflected in your app, you’re good. As widgets are part of your app, they will never change out from under you and break your app or make your app look bad.
• And if that was not enough, you can write your app and use the new widget even on older OS versions.

Packages

Before adding new and complex features to your apps, you can check the Flutter packages repository. From tools and utilities, to multimedia and third-services implementations, you probably will find something useful for your app. Plugins to easily access services (camera, location, acceleration, permissions) are there too.

Open source

As mentioned before, open source and app-rendering make Flutter customizable for every individual app. Almost all is modifiable, concretely everything of the Dart engine:

Closure

I hope that these two articles will cleared you about why Flutter is a very powerful tool that can be the dominant tool in mobile development and why we use it on Stratton Apps. But if not, here we leave a summary of its unique characteristics:

• Reactive views, with no JavaScript bridge
• Fast, smooth, and predictable; code compiles AOT to native (ARM) code
• Comes with beautiful, customizable widgets
• The developer has full control over the widgets and layout
• Great developer tools, with amazing hot reload
• More performant, more compatibility, packages
• Open source and modifiable
• Fast and beautiful apps for multiple platforms from a single easy code

If you want a great, original, fast and responsive app for multiple platforms, do not doubt to contact us at Stratton apps. We will build fastly and cheaply a Flutter solution with backend support if needed.