Flutter is Google Open Source Project that mixes in several other Google Open Source Projects bought over the years or created in-house – and also public open source libraries and development approaches, not owned by Google but open sourced – with the goal to give developers the tools and frameworks to create the Graphical User Interfaces for all the big user interface platforms. I’ll explain what is it about, some pros and cons of the toolkit, comparisons, personal opinion about it.
Demo – https://www.youtube.com/watch?v=EWU5R7_12wI - So here is an app that reads content from the Internet and displays it on a mobile device. It runs on Android, on iOS with absolutely no code modification. The same code with some parts commented since plugins are not yet supported on those platforms also runs as a Desktop Application and as a Web Front-End Application.
It tries to follow the idea – Write Once – Compile for Platform X (with no changes) – Run. And it seems to do the job, at least close enough.
Why close enough?
First because of the Plugins. There are some Plugins written by the Flutter Team that are likely be very up to date and compatible with the latest version of the SDK and the latest version of the target Platforms and also will target if not 100%, close to all target platforms. And the bad - the Open Source Plugins written by the community - which library is supported for which Platform, for which version? It is a problem common to all Cross Platform And Hybrid Frameworks. The other alternatives have the benefit of time and larger community that have brought the needed features to the framework, but time plays also against them - with the ever changing native frameworks and their dependency on them.
And Second - Because of the Input Methods and Devices. Flutter will try to target a lot of the Platforms. The interaction with the Mobile Devices is with Fingers, Stylus, Voice, Proximity Sensor, less often with a Mouse or Keyboard. Desktop Machines, Laptops, Netbooks are accessed primarily with a Mouse and a Keyboards and rarely with other Input Devices like presenting pointers, drawing pads and so on. TV with some more complex OS (Android, iOS or 3rd party) have also a InfraRed Remote Controller. Other devices that are non of the above – IoT devices, could theoretically have a variety of non-standard Input Methods.
To be able to feel like native for all the Platforms and to be actually useful the One and Only source code must be extensively complete – handling different interactions – hover/mouse-over, on-select, drag, multi-touch, special keys like alt, control, escape, the arrow keys and so on. But even if not all events are handled, it is pretty impressive the amount of unification that could be done with Flutter. Of course if everything else that is custom for your business case works.
How it all happens? You could watch the presentation from the Google Team. https://www.youtube.com/watch?v=IyFZznAk69U I’ll jump into some details about it for you.
Flutter has two layers - The exposed Dart API that you’ll use and the Flutter Engine beneath it.
Skia – Open Source Graphics Library – the C++ Framework used in Chrome - bought and open sourced by Google more than 10 years ago. It is ported to all major systems and it gives a base to Google and the outside developers to create stuff above it and to be able to package native bundles for the different OSes.
Chrome of course is the top client of the framework. And when you succeed with something, you expand it. That's why they are building Flutter with it. It will directly and indirectly improve Skia itself, because of the feedback and because it is all under the Google hat.
With the exception of the SDK and the Plugin Community, (Client) developers are mostly Programming in Dart Programming Language. It is similar to Swift, TypeScript, Kotlin, C#, and many more. The UI Building is very similar to JavaFX Declarative UI and the new SwiftUI.
The Dart code is being interpreted during development with a small layer inserted during development - so on older devices or sometimes it may feel a little bit slower during coding because of the Virtual Machine in the Native Apps, and the Dart to JavaScript Interpreter - additional layer for Web. Your code is compiled to native code ahead of time to native code for Native Apps or to JavaScript for the Web, so in production it should be much faster (let's hope Flutter or Dart team jumps to WebAssembly also - so the end code could get faster).
If you’ve developed any business applications in the last five years, Dart will feel natural and the learning curve will be small. You’ll have all the expected features - null check operator, object oriented paradigms like capsulation, inheritance, type templating, functional/reactive API Like Future, Streams, Default values for parameters, mix-in/extension functions and so on.
Flutter Team has Build some Material Widgets (Appbar, TabBar, (Navigation) Drawer, Buttons, Pickers, Alert Dialog, SnackBar) and some iOS (Cupertino) Widgets (ActionSheet, Dialog, Pickers, Tabs, Bars, etc) that match the native components available on those platforms. Also There are some Common widgets that you should know so you could arrange however you like - Rows, Columns, Image, Padding, Text, Icons. Also for taking advantage of screen space - there are Flexible, Expandable widgets and a MediaQuery API so you could display something differently on different screen orientation, size etc.
Flutter Mobile was marked ready for production in the end of 2018. It currently has a stable version 1.5. You, as an app developer code in Dart Flutter API. For the production all code is transformed, translated and compiled to native binary.
Flutter for Web is currently in a “Technical Preview” phase. Many of the plugins are currently not ported to the Web. Google Developers have a lot of experience of trans-compiling stuff for the Web - Google Web Toolkit using Java, Angular using TypeScript (developed by Microsoft). Now Dart Language - developed internally and open sourced.
What is needed for Flutter to work for the web is re-implementation of the Widgets in Dart to generate the appropriate markup/ JavaScript/ Drawing for the web. And once all is stabilized - all flutter code will magically work on the web without modification.
Flutter for Desktop is still in very early stage of development. The Idea is the same as on the Web and Mobile. For the ChromeOS the layer below could theoretically be thinner because it is developed by Google. ChromeOS supports Android Apps - that is a target platform for Flutter, and also the OS itself is Chrome which is made with Skia/Web Engine.
For a Desktop App for all the Major Platforms - the layer below must be platform-specific - Linux, Windows, MacOS. They’ll try to reuse the code and development experience of Chromium to bring it to Flutter, but still. Everything needs to be touched and tuned up to work properly and it is no easy task.
Flutter for Embedded devices is not ready for production yet. What is needed is the layer below the Flutter SDK to be implemented for the concrete embedded target (probably C/C++ code mapping the same functionality of the Desktop environments). https://github.com/flutter/flutter/wiki/Desktop-shells#tooling.
There are some enthusiasts that have ported Flutter to Raspberry Pi: https://medium.com/flutter/flutter-on-raspberry-pi-mostly-from-scratch-2824c5e7dcb1 so it is all a matter of time.
If you need some native functionality you could write yourself a plugin. It is currently officially supported for Android and iOS:
https://flutter.dev/docs/development/platform-integration/platform-channels
It is straightforward process - you register a plugin channel ID that will be something like a socket or remote procedural code. Then from Flutter code you execute function X and expect result Y. On the mobile native side when received a method call X you do something and return Y. Thanks to the async/reactive nature of the code, you wouldn’t block the user/workflow of the code.
There is no official UI Builder from the Flutter Team yet, but the Community is strong enough and there are even know some paid, free or open source options - Flutter Studio, Meta Flutter App, Widget Maker. Also, if you search enough, you could find a lot of Flutter UI Clones of popular apps codes and also the source codes of some cool UIs.
There are a lot of options out there to choose from - Flutter, Xamarin, React Native, NativeScript, Ionic, Cordova, many more free and paid platforms. If you are not forced to work with concrete framework - you should pick the one that you prefer, know best so you’ll produce something faster and receive the feedback from the world if your thing is good.
Flutter compared to the others has some similarities and some differences. It has a state centered approach and the UI is re-rendered when the state is changed - similar to React Native. It has fast reload/hot reload similar to all other platforms. It will have the benefit like Xamarin in not so distant future to target more than just the Mobile Platforms. It will be a plugin hell very much like the other Platforms and with the time it may improve thanks to the community.
Also Flutter does not use native widgets - it draws them itself. This has its pros and cons. To be not dependent from others is generally a good thing. No external change will break your thing. But in the same time - you have to develop yourself, test, verify clones of all the native components that the users are used to. And since the Flutter code is compiled to binary - code push - upgrading an app without going through the the markets is not available for the moment, because it is tricky to implement such a feature with native code. The result of Flutter for speed reasons is not interpreted in production mode.
Who uses it? Google, Alibaba and many more. What I've shown you is the work in progress of my app what you eat rewritten in Flutter.
At the end of the day “Open Source” is just a label that attracts developers. Making it Developer centered – because of developers, developers, developers - is a key to succeeding. Look what happen to Huawei. You give others the possibility to use without paying what you have created, but most of these users are technical people. The audience that in the end pays the bills and supports whatever project are the non-technical majority. And since – some part of the developer community fall for the illusionary abstraction of mine/yours/open/, they give time, feedback, contribute to the projects, many times without a pay and that is how to scale up the unscalable - the human power.
Top comments (0)