April 02, 2019 F Is For Flutter We take a look at the nuts and bolts of Google’s open-source mobile SDK Flutter, how it differs from its competitors, and put to some real-world tests. Zlati Pehlivanov The year is 2015, and I’m sitting through the final presentation of the Dart conference. On the stage, the Google team is demoing an experiment of a mobile app build with Dart. During the presentation, the team mentions something called Flutter. This was my first time hearing about it and, needless to say, what followed blew my mind. What Exactly Is Flutter? Flutter is Google’s new open-source software development kit (SDK) for mobile development. It allows native apps to be built on both iOS and Android (and more, but we’ll get to that) from a single codebase. It’s fast, flexible, and full of every feature you’d expect from an SDK that supports multiple platforms. Simply put, Flutter is packed with potential. Now, back to that mind-blowing demo from 2015. The team demonstrated Hot Reload on two devices simultaneously for less than a second. They were targeting 120 frames per second (fps). 120FPS!!! At that time, front-end developers were targeting 60fps — an extremely difficult goal to achieve even on the web. On mobile? Nearly impossible. At this point, I wasn’t necessarily a huge fan of Dart, but I kept an eye on technologies that followed the philosophy of “one codebase, multi-platform support”. I kept the Flutter project home page in my bookmarks and started regularly checking on the status of the project. The Nuts and Bolts of Flutter Flutter is an SDK built on Dart 2. Dart is a general-purpose programming language created by Google. It is an object-oriented, class-defined, garbage-collected language using a C-style syntax that transcompiles optionally into anything you want. It was mostly used to generate JavaScript. Nearly everything in Flutter is widget-based. Widgets are building block — like Legos — that you can stick together, nest, align, animate, etc to build a UI. There are no views in the notion of some XML, HTML, JSX, or whatever. Instead, the views are created programmatically with widgets — even an app is a widget. The business logic for your app is all written in Dart, though. Flutter & Fuchsia Now, about that “and more” I mentioned above. In addition to compatibility with both iOS and Android, Flutter is also the primary UI framework for Fuchsia OS. Fuchsia OS is a new operating system developed by Google that is compatible with virtually any kind of device. If this is your first time hearing Fuchsia, don’t worry; you aren’t behind the times by any means. In fact, Google hasn’t technically launched Fuchsia in any official capacity yet. However, bits and pieces of information have popped up in several IT blogs. It even has a Wikipedia page and an open source repository where you can play around with building the OS for yourself. Some even theorize that it will serve as Google’s replacement for Android and Chrome OS altogether. From the public information that exists, we know that Fuchsia OS is using Flutter SDK for its UI and Flutter is treated as a first-class citizen with Fuchsia. To make the transition smoother, Google announced that Fuchsia OS will support Android apps, at least for some time. That also means that Google likely won’t kill the Play Store which is currently dominated by native Android apps. As more information becomes available and Google inches closer to making an official announcement about Fuchsia OS, it’s likely that Flutter’s presence within it will increase. Without going too deep into the architecture of Fuchsia OS, it is important to note that it’s developed using a new microkernel that’s capable of running on a wide range of devices from low- to high-end. This is a significant departure from Android which is not developed on kernel optimized for ARM processors and mobile device in part. What Differentiates Flutter From Competitors? Flutter’s main list of competitors is comprised of cross-platform frameworks and SDKs like Xamarin, NativeScript, React-Native, Cordova, and Unity. While they all have their differences, they all have one big thing in common; there is a bridge between the JavaScript code and the native APIs. It’s an environment dominated by JavaScript, except Xamarin and Unity which build on top of C# Mono. Only Cordova doesn’t use native components and depends on a native web view to show something on the screen. JavaScript isn’t always the best tool for the job, though. Its loosely-typed nature tends to cause things to not perform as they should. Flutter, on the other hand, doesn’t rely on native components. Everything appearing on the screen is created using a low-level graphics engine called Skia. “Native-looking” widgets are built from the ground up to be a pixel-perfect match of Material and iOS components and provide a way to create your own custom widgets. Some say that changes in iOS and Android might make your app look different from native apps. As far as I can tell though, the Flutter team is constantly improving all sorts of UI discrepancies. By providing you better tooling to actually create your own components that will perform as native ones, Flutter gives you the opportunity to influence the identity of the app. Many big names in the industry prefer a custom UI to stand out from the crowd. That drove the Google team to spend a lot of time perfecting the customizing abilities of the Material Framework. As a result, users can make changes to the Material Framework without changing any of the functionality. None of this was possible until Google I/O 2018. Up until that point, many apps in the Play store were starting to look alike because everybody was using the same Material spec. With Flutter, there’s no such notion of a bridge between native and non-native. Everything is compiled to native ARM code. The way Flutter code communicates with the native APIs is called PlatformChannels. There is a specific interface that your native code needs to implement in order to expose an API used by the PlatformChannel. Flutter SDK achieves communication with the native features written on any supported native language such as Android Java or Kotlin, Objective C, or Swift. Putting Flutter to the Test So all of this sounds great but how does Flutter actually behave when put to use? Is it really as easy to use as its shiny, polished website makes it sound? I decided to find out for myself with a couple of different experiments. In my first attempt using Flutter, I chose to develop a single custom widget that uses most of the animations, clipping, painting, and transformation APIs and widgets. I built a custom element that looks just like a normal Material text input, but with one catch; when clicked it launches a modal dialog with a circle shaped color gradient to choose colors from. For the purpose of this experiment, I decided to use just a couple of stateful widgets communicating up to the widget tree with callbacks and receiving initial data from the input widget. Like so: https://mentormate.com/wp-content/uploads/2019/04/color-picker.mp4 For my second attempt, I wanted something bigger. My interest was already going beyond charts. A colleague gave me an idea to develop an RSS reader with a very specific list of requirements. He wanted the ability to add and remove RSS feeds, support atom, browse all the items from all the feeds sorted by date, save comma-separated keywords, and see feeds filtered by these keywords. This seemed like a perfect challenging project for a brand new Flutter developer. It turns out that most of the features are really easy to build as a UI. The more challenging part was to understand how to create my BLoC(a pattern invented by Google and represents a business logic component, that stands as a middleman between the widgets and the data, which uses Reactive Programming) and how to deal with storing data in the app while reading the RSS and Atom XML. Lucky for me, the Flutter documentation was pretty clear and pub.dartlang.org had everything I needed as open source packages with widgets and some native goodies, like SQLite. https://mentormate.com/wp-content/uploads/2019/04/flutter_rss_reader_2019-03-19-11-43-14.mp4 Final Thoughts The Roadmap recently shared by the Flutter team coupled with the news swirl around Fuchsia both have me optimistic that Flutter is here to stay. The team is making Flutter better with every release by increasing its ergonomics, performance, and development tools. Most native APIs — camera access, in-app browser, web view, Google Maps — are already developed. Only one important API — in-app payments — is still missing, but the Flutter team has stated on multiple occasions that it’s in the works. It’s also visible in the roadmap as well. Two other important things in the works for Flutter are support for web and desktop apps. That means that eventually Flutter could be compiled to JavaScript to run in a web environment and would be possible to embed a flutter app in a desktop environment. From there, Flutter could support all kinds of platforms like mobile, desktop, web, or even IoT. Thanks to all the great things coming from Flutter, it’s a good time to be a mobile — or multi-platform — developer. For me, this was the most hassle-free, quick setup of dev environment comparing with ReactNative and Cordova. I was surprised how quick and easy it was to learn Dart language. I probably haven’t used all the advanced features of the language yet but, coming from Typescript, the static strongly-typed Dart was easy to pick up. Every developer coming from an OOP language can easily begin working with Flutter. I’m really happy with the speed I developed the two experiments demonstrated above. When properly executed, a Flutter project can save money and development time and deliver a highly performant, beautiful result in the iOS or Play store. Various shops have shared their experience with Flutter and are saying it cuts their development time — and team size — in half when compared to native apps. While there are a few limitations, I’m optimistic they will be addressed and resolved soon. Tags MobileDevelopment Share Share on Facebook Share on LinkedIn Share on Twitter Continuation Engineering Plan for maintenance with these 13 tactics. Download Share Share on Facebook Share on LinkedIn Share on Twitter Sign up for our monthly newsletter. Sign up for our monthly newsletter.