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

To explain why this innovative framework could be the best solution for mobile development we are going to separate the reasons in two different articles so as to deepen each reason without confusing or boring the reader. This is the first part, and at the end you will have a link to the second part of this narration.

If you have not already done so and specially if you don’t know nothing about, I strongly recommend reading our article on Flutter essentials. However, we will give a small definition to enter context for those who do not want to read it.

About Flutter

Flutter is an innovative SDK to mainly create applications for Android and iOS (more platforms currently under beta and alpha release). This framework allows developers to build beautiful and high-performance native cross-platform mobile apps only coding once, on Flutter.

And when a new technology goes on the development market, the first thing to look at is what its advantages are. That is, the first question to ask is why use it. In the field of tookit for multiplatform applications development, in addition, there are already many technologies. Cordova, PhoneGap, the new Ionic, etc.

The “native” attribute mentioned above, in case you had not noticed it. But first, we will explain the trouble reviewing how all other technologies work.

Framework-device relationship

The first argument will be the the way Flutter and mobile devices interact. We are going to go over how the framework or the software interacts with the device on all technologies to know how this tie is, how it really works.

The Platform SDKs (Android an iOS)

Both Android, the Google OS released in 2009 and iOS, released in 2008, work about the same way. They are based on different languages (Objective-C and Java) but its operation is the same.

Your app can order the platform to do two different things: create widgets or access services of the mobile device (camera, location, battery, sensors, etc). Those widgets are rendered to a screen canvas, and some events are passed back to the widgets.

Although it is a simple architecture, the problem with this is the fact that you have to create separate apps with two different codes because they have different native languages and widgets.

WebViews

When Android and iOS grew up, and therefore mobile development done so, their classes to manage web content without leaving the app became more and more versatile, and it let the creation of frameworks that take advantage of that webviews to show content in both platforms through them. This is how Phonegap and Apache Cordova came about.

Using the classes WebView (Android) and UIWebView (iOS, now deprecated to WKWebView) they render HTML, CSS and JavaScript code, and there is a communication between the JavaScript of the webview and the native code to access the services. However, as it is difficult for languages like JavaScript to talk directly to native mobile code, they implement a “bridge” that makes connection between the JavaScript realm and the native realm.

Seeing that platform services were typically not called all that often, this did not cause too many performance problems at first. But when app market grew more and more, this technology was revealed as quite limited, specially because of the performance (that’s why Flutter purpose was to make a smooth app for both platforms rendering at 120 FPS, read more here).

Reactive Views

As reactive programming arrived, reactive web frameworks like ReactJS (and others) have become popular mainly because they simplify the creation of web views. In 2015, the React Native creation brought the many benefits of reactive-style views to mobile apps and now is popular.

In React Native the JavaScript realm accesses the platform widgets in the native realm, instead of using the WebView. However, it has to go through the bridge for those as well, and now not only to access native services, but also for rendering. And because widgets are typically accessed quite frequently (up to 60 times per second) specially during animations, transitions, etc, this can cause performance problems and usually are tricky to solve. Native part is fast, JS part is fast, but moving from one to another causes a performance bottleneck, and you have to keep data flow between them at a minimum.

Flutter

Flutter has been inspired by React Native and also uses reactive-style views. However, the creators had a great idea to avoid the connection bridge. Instead of using JavaScript, they used the compiled language called Dart, also developed by Google. Dart is compiled ahead of time (AOT) directly into native code, and that’s how they not only fixed performance problems, but also improved app startup times.

This thing alone (reactive views without bridge) should already be a reason to talk about Flutter as an interesting and innovative development technology which is worth to try, but it is only the appetizer of the Flutter revolution. The main course is its implementation of widgets. The importance is such thate will discuss the operation of flutter in the next section, the Widgets section.

Flutter’s Widgets

Widgets are one of the most important elements of an app. They create and modify the view and are the main behavior and can make or break an application. Services are complementary features that serve widgets to complete an application and give it functionality.

(gif)

Among other, they must be

• Good looking and feeling. Widgets have to look good and be flexible and natural. They have to behave and adapt to on various screen sizes.
• Fast performing: to build the widget tree, inflate the widgets (instantiating their children), lay them out on the screen, render them, and (specially) animate them.
• Extensible and customizable. Modern apps demand personality and style, and developers have to be able to add pleasant new widgets, make others from the first ones and custom-make all the widgets to get the design and model of their brand.

Flutter, instead of using OEM Widgets (widgets of the native platform) or DOM WebViews, has developed a new architecture with widgets that comply the three rules above mentioned.

That’s because this framework moves the widgets and renderer from the native platform into the app, leaving in the platform only a canvas inside which to render those widgets on the device screen, but not the widgets themselves. Services (like camera) and events (timers, touches, etc) are also accessed through the native platform. But the trouble, as seen in react views, was in rendering.

Changing widgets and renderer makes the app weigh a little more. Putting numbers on the table, the minimum size of a Flutter app is about 4.6MB, which is comparable to those build with equivalent development tools. In fact flutter takes advantage of this as well because as the volume and load of the application increase the size does not increase very noticeably. It is up to the developers to decide whether it is worth the benefits of flutter or not.

Finally, comment that although there is still a link between Dart and native code to encode and decode data, this is much faster than the JavaScript bridge.

That’s all folks. As you have seen, in relation to the device Flutter is very forward-looking it is very advantageous compared to others. This is the first point why Flutter It could become the champion of front-end development, especially for mobile applications. The second one is its powerful widgets. In the next article, we will cover the layout, custom designing, tree managing, hot reload, compatibility and more. Hope you liked!