Flutter is a new mobile UI framework from Google, that allows you to create native applications on iOS and Android. At the time of writing this blog post, it's still in beta but apparently will hit 1.0 soon!
Now, I gotta say, when I first learned about Flutter, and what it was all about, I was very intrigued!
You see, Flutter is the equivalent of a game-engine but for everyday apps!! I'll let that sink in. It's got an OnDraw function just like a game engine's loop would call (they call it the build function). Under the covers it uses the C++ library Skia to draw pixels directly on the screen. And because its C++ underneath, that means Flutter is cross-platform. Needless to say, this warrants a closer look from anyone who is writing mobile applications.
I'll say it up top! - Flutter looks very cool.
Stepping back a bit, I've always thought that as C++ is the lingua franca of languages, which all systems support, could it be possible for someone to write a cross platform mobile UI framework using SDL or SFML. It was a fleeting thought of course because that's no simple undertaking. Yes, I know we already have the C++ Qt library and QML but the masses aren't exactly flocking to use it.
Then there are game-engines like Unity that can run on all platforms. Again, I have always wondered if it would be be feasible/possible to use it to write a line-of-business app? I mean, it uses C# (which is a win) and the app would run everywhere Unity runs! That's a lot of places. But again, you would have to write the GUI widgets/controls yourself. The amount of work involved would be massive!
Enter Flutter.
Turns out Google was thinking the same thing, because that's what Flutter is all about. It's written in both C++ & Dart. C++ is used for the heavy lifting and the OpenGL calls (via skia), but the core Flutter library is written in Dart. Yes, that means we will be writing Dart code to write the Widgets/Components on the screen.
Incidentally, I first came across Skia when I found SkiaSharp. Skia itself is a C++ open source 2D graphics library and is used in Chrome, Firefox, Android etc and SkiaSharp is a C# port which is used in Xamarin Forms. But I digress...
So what about the GUI elements? Well, the framework calls them Widgets and provides you with containers, buttons, Forms, List Views, Srollers, etc. It's from these foundational Widgets that you create your own custom controls.
Why dart?
Ughhh. Dart? That was my first thought... Why didn't they choose Kotlin. The last mobile app I wrote used Kotlin which is a very nice language and because it is built on the JVM means you can interface with the large set of existing Java libraries out there.
So, at first I was a little disappointed to learn that flutter uses Dart as its primary language. But you know what? After playing with Dart a bit, it's actually a pleasant language.
Now there have been some changes to Dart, since it first came out that I was not aware of. For example, when Dart 1 originally shipped it had optional typing. But thankfully Google saw the error of their ways and for Dart 2 strong mode has been adopted. As Flutter uses Dart 2, this means our code is like C# & TypeScript in that types are required or inferred. This is good news as it means you get all the benefits of static typing.
There are some weird things to get used to though. For example Dart does not have public or private keywords!! Yes, classes can't have private variables!! Coming from other languages where the keywords "public, protected & private" are the norm, these keyword omissions just seems weird to me. There are other oddities like multi-threading that I won't get into here. However, for the most part, if you're coming from JavaScript, Java or C# then Dart is a pleasant language to code in.
I still kinda think it's a shame they didn't go with a more powerful language like Kotlin, especially as JetBrains are working on Kotlin Native which would have solved the iOS side of the story. However I suspect the choice to use Dart was a political one as Google own and control Dart so there won't be any nasty surprises further down the road (cough Oracle)!
Code Sharing versus UI Sharing
Here's the really cool thing I love about Flutter. And that's the fact that the user-interface you design and write, is shared across Android and iOS. Which, when you think about it, makes sense... I mean all it is doing is spitting out the same pixels to the screen. The framework doesn't care that the screen in question just happens to be an iOS screen with a notch on the top! The frameworks game-loop is just calling its OnDraw function.
If you want the same brand theaming across iOS and Android this is great, however Flutter is also platform-aware so if you want to have apple style widget on iOS you can! The choice is yours!
When Xamarin first came out their selling point was that you wrote the business-logic once but then had to write the UI layer twice. In the early days the benefit to developers was more about the "Code Sharing" aspect of the platform rather than the "UI sharing". Of course, since then, Xamarin have introduced Forms which aims at helping developers also write the UI code once.
In comparison, it seems to me that the biggest benefit of Flutter is the "UI sharing" aspect of the framework and the code sharing is secondary. This nicely brings me on to API's...
Accessing Android & iOS APIs - Plugins!
One of the big selling points of Xamarin is that they give you access to the "full spectrum of functionality exposed by the underlying platform". Basically, any APIs you can call from a native iOS or Android app, you can call with Xamarin. It exposes all those native APIs from C#. From a developers point-of-view, you gotta say, that's pretty cool.
The Flutter folk have gone down a different path. Instead of exposing every conceivable API you could call, they allow you to write plugin packages that you can share with the community, These plugins allow you to write dart code that interfaces with a specific set of APIs. This means you can always open up the iOS or android sub-folders and write as much Obj-C/Swift or Java/Kotlin code as you like.
I think anyone who takes even a cursory glance at Flutter will agree that they have got the UI side down. But I think the crucial part of the Flutter story is going to be the interop with the native APIs. For example, if you choose Xamarin, you know the platform APIs are exposed and available for you to call from C# but with Flutter, you are either going to have to rely on the community to provide a plugin that interfaces with the APIs you want or roll up your sleeves and write the platform specific code yourself (and potentially twice).
It's going to be interesting to watch how this side of the story unfolds for Flutter.
Reactive Views & Hot Reloading
Flutter uses the same model as React for building UI. If you think about visual designers like we have had with the likes of Winforms, WPF, Android & iOS, they all focused on the visual layout of the UI alone. One thing that stood out for me straight away was that there isn't a visual designer for flutter. No XAML or XML layout editor.
With Flutter though, you write your UI directly in code! Now before you throw your teddy-bear out the pushchair, it turns out that this isn't a problem because of the fast hot-reload. Essentially the code you change is instantly reloaded in the Emulator which means you get instant feedback.
Here is the obligitory screenshot from the main Flutter website, showing the hot-reload in action:
There is also something called the Widget Inspector which is very cool. Whatever part of the screen you touch, it will tell you what class that region of the code relates to. It allows you to jump straight from the UI to the code!
Building Blocks of an App
There are lots of great articles on how to get started with Flutter, (like these ones here, here & here) but once you have got to grips with all the Widget aspects of the framework, you start to think and have questions about the other building blocks of a mobile app, like I did.
Here are some of the things I have noticed after reading up on Flutter.
Coming from C# / Java where we have great JSON libraries like Json.Net or Gson, I was a little taken aback to realise there was nothing equivalent in Dart. Also, because the official docs mention that runtime reflection is disabled in Flutter the chances of getting a library like Json.Net or Gson are slim to none! Instead, this article explains what it is like to perform JSON serialization/deserializtion in Flutter.
For network comms, the last app I wrote made use of the excellent OKHttp library. Of course, there is no equivalent in Dart. If you intend to do anything like certificate pinning you can make use of this plugin or write the plumbing code yourself.
If you want to make use of a local database, thankfully SQLite is available via the sqflite plugin. This is great write-up on how to incorporate it in your app.
If you are familiar with MVVM pattern, then this article here could be a useful read which uses the ScopedModel plugin. This allows you to automatically update the Widgets in the tree when the model is updated.
If you plan on writing an app that makes use of background notifications, then the latest beta version of Flutter now has a solution. The sample code for background execution of Dart code can be found here.
If you are looking at integrating a map in your application then using Leaflet could be an option until the Google Maps plugin is properly supported. (At the moment, it does not support iOS). There is a good write-up on how to use Leaflet here, and here. The plugin is available here.
At some point you might want to include a webview as part of the app. Yes, there is a plugin for that! This article has a good write-up here and the plugin can be found here .
Finally, I've been looking at what is available with regards to client-side encryption. If you have a need to encrypt/decrypt data using AES/SHA25 then this plugin library uses native platform implementations on both Android/iOS.
Wrapping Up
I am not sure when Flutter is going to hit 1.0. There is still over 4,000 open issues on Github so I guess there is a way to go before they iron out all the remaining severe issues, however, the framework has a lot of promise and is very exciting. Flutter is definitely one to watch!
