In plain English: So what the heck is Flutter and why is it a big deal?

Scott Stoll
Flutter Community
Published in
13 min readMay 3, 2018

--

Let me get this out there first: This article is meant to give you a general, extremely vague understanding of what Flutter is and why you should bother to care. It is absolutely not technical (or even technically correct) and it’s not meant to be. It’s meant to give you the general idea because you’re sitting there saying: “Why the heck is everyone is so worked up about this Flutter thing?”

To that end, I’m just going to start throwing points out there and building on each in a way that hopefully makes some sense.

1) Is Flutter really cross-platform? Yes? No?

Answer: Both. This is the part where you look at me and say: “Scott, your help isn’t helping.”

So let’s break it down just a little. Can you write once and deploy to both Android and iOS? Yes. In fact, it’s more than that. There are desktop embeds already being polished for Mac, Linux and I believe people are already working hard on a Windows desktop embed. Additionally, Flutter is designed not only to work on the upcoming Fuchsia OS, it drives the entire Fuchsia UI.

So do you write once and deploy to Android and iOS? No… You write once and deploy to six different platforms, including Android and iOS. You deploy to Mac / Linux / Widows desktops plus Android, iOS and Fuchsia mobile devices.

So in that sense, it is cross-platform. Now we look at why it’s not cross platform:

Because it doesn’t use the underlying Android or iOS platforms (for much). Flutter is it’s own thing, but it’s missing the code to directly handle things like the camera, Bluetooth and other hardware. So, for those things, it talks directly to the platform and gets it to handle that stuff. But for business logic, UI and drawing to the screen, Flutter just tells the platform framework: “Hold my beer, I got this.”

Think of it this way: Flutter is (kind of, sort of, like) a full screen 2D game. Like any other full screen 2D game, it takes over completely. It has it’s own interface. No, those are actually not the stock UI component’s you’re touching; more on that later. Flutter is a full screen app that writes it’s own graphics straight to the graphics hardware via the Skia engine (the one that powers Chrome and has been real-world tested and used for years). Because of this, it’s performance is great. Flutter gets 60fps consistently, even on older hardware. One presentation in Cologne said they were getting 120 fps in some tests.

Approaches that actually are cross platform send their code to the platform in order to run. I want to thank Ahmed Abu Eldahab (known as @dahabit in Flutter’s gitter channel) for letting me use his slides for my presentations. These can give us a quick understanding of what’s going on. When you look at Ahmed’s slides, you want to keep in mind that the left side of the dashed line (in green) is your app while the right side is the platform and your device.

The OEM SDK’s have their apps written in their respective languages. Then what the app needs from the UI (Cupertino and Material Design) is passed to it and the UI section draws to the canvas, as well as handling other events. In the case of Android, there is also the JVM to consider but it’s already represented here within the blocks.

Then there are the attempts to create cross platform solutions with Javascript. The Javascript is translated into something the underlying framework can understand and then that bridge is what talks to the OEM UI. This extra step of using a bridge take resources and time, impacting performance.

Actual cross platform approaches have their code sent to the SDK libraries, again creating another step that takes time, resources and can adversely impact performance. Also, like all of the above approaches, they still use the stock OEM UI component system. This (mostly) limits what you can do to what is available within that UI system.

Then there’s Flutter. The first thing to notice is Flutter uses native ARM binary. It’s compiled ahead of time, no JVM needed. This means it’s fast. Really fast. Next, it tells the whole framework UI system: “Take a break, I’m doing this my way.” That give you incredible capabilities, as you will see.

Notice how in all of the above situations it was the OEM UI systems that talked to the graphics hardware and handled writing to the canvas. But Flutter uses it’s own graphics engine, the Skia engine. That engine is compiled into the app itself, for now. There is talk that a downloadable library including this and other things is in the works, which will allow individual Flutter apps to have a smaller footprint since these things won’t have to be compiled into every app.

Like the rest of the Flutter app, the Skia engine is already compiled to binary; making it so fast that “It’s got a smoke trail better than a Cohiba” (a brand of cigar). “Meep! Meep!” goes the Roadrunner.

I did mention that some devs in Cologne Germany were getting 120 fps, right?

So what the heck is that Platform Channels thing? Short version: Remember I said that Flutter doesn’t use the underlying platform “for much”. Well, Flutter needs to send the underlying platform on a few errands here and there, for things like Blutooth, GPS, Camera, etc.. But there is another cool trick you can use.

You can access any part of the platform you want. You can have the platform handle some things and Flutter handle others. However any code that your write for the platform, you’re going to have to write an if statement that checks what device it is and then write your platform specific code twice, once for each phone platform. And there thus far has been no prediction regarding how that’s going to affect your ability to run your code on the desktop embeds or Fuchsia.

2) I mentioned that the way Flutter has it’s own UI system gives you incredible capabilities. This is where you can have some real fun.

Have you ever wanted to really mess with people’s heads and put an iOS interface on an Android app? How about an Android interface on an iOS app? How about your own custom interface that looks exactly the same on both? Do you think Squircles look cool on iOS and wish you could use them on Android?

You can do all that and much, much more.

The secret lies in the fact that, as Ahmed’s images show, Flutter isn’t using the OEM widget code. Instead, the Flutter framework contains widgets that were made to look exactly like the stock OEM widgets, pixel for pixel. The UI widgets that look like OEM widgets even move with the same acceleration and coasting performance as their platform counterparts, making them not just look but also feel just like what you’re already used to.

And that’s the point… It’s about what you’re already used to. If users downloaded a Flutter app and saw all kinds of strange widgets that they had never encountered before, that’s not a good thing. People like what they’re comfortable with and they’re comfortable with what they’re used to. So the idea is to write an app in Flutter because it allows you to deploy to both types of phones and because it’s so much easier to work with (that’s next) but that your users are never supposed to be able to tell the difference. If they download an app that says it does X, then they expect to see an interface that looks like what they would expect from an app that does X; so Flutter can give that to them.

It also can do something the the users of older iPhones are going to love… it can put the latest and greatest interfaces on older phones and it will look and feel just like a new phone. This means that as long as you’re using apps made in Flutter, you will be able to keep using your older phones. The UI will look and feel exactly like you just spent $1000USD to buy a new phone but it didn’t cost you anything at all.

It won’t make your older phone good forever, at some point the architecture won’t be able to run future code; but your older phones will be useful for a lot longer than older phones have been in the past.

3) A small bone for the real techies out there. If you know Android really well, you probably know the ins and outs of the View class. For those who don’t know, this class is a basic foundation in Android… and the View class file is 26,487 lines.

Twenty-six thousand, four hundred eighty seven lines… used over and over and over again in the Android OEM UI. When some Flutter people hear that, they turn pale.

Android is using an inheritance based setup. Flutter uses composition. In Android, if you nest a lot of UI components then you can run into performance issues really quickly but we don’t have that problem in Flutter.

4) The second to last big thing to understand is Dart. Don’t believe the rumors, Dart is very much alive and actually a joy to use, coming from Java and the Android SDK. It’s not fair to blame Java for the fact that using it in Android can be… difficult to read. And I don’t.

You might hear some people saying things like Dart doesn’t compile to JS well or is slower on the web than JS and those things are true… which is why they gave up on trying to push Dart on the web as a JS competitor in 2014. So if people are saying things like that, tell them that their information is 4 years out of date. We don’t use Dart on the web at all and our release code doesn’t use a VM, we release in ahead of time compiled, native binary.

Dart is a C-style language, so don’t believe the people screaming that they don’t want to learn another language because it will be so hard and oh my god I just don’t have the time and, and, and…

There was a test. Some people were placed in front of code they’d never seen and asked to do a few tasks with it. Create functions, use lambdas, write an if statement and for loop or three. When they hit a point where the syntax was a little different than they were used to, the IDE told them what to do and they adapted in seconds. Within a few minutes they were cruising along as if they’d known the language for years. Then they asked participants what language they thought they were working in.

They had no idea it was Dart.

Dart and Flutter’s power doesn’t come from some big difference compared to other languages because when you’re typing in Dart it doesn’t look all that different from other languages, for the most part. Its power comes from some of the things built into the language and framework. You don’t have to worry about a bunch of types like float, char, array and others. You have String, Int and List for your basics. There are, of course, Enums and Typedefs, as well as a few custom types that make your life a lot easier, such as Widget. We have lambdas and ternary operators and we make use of both them inside of the UI code to make run time decisions about what UI elements to show. This means that you can have your UI code making decisions about whether to put an image or text or both in that next view of your list view. (Flutter doesn’t need a separate reclycler view because of the way things are handled under the hood. For all intents and purposes you can just think of the stock Flutter ListView as a reclycler view in Android.)

Now, as a prefix to the following, we’re going to define a line here as being terminated at the end of a statement, so you can’t cheat by putting an entire app on one line.

A common app in Android that has a URL builder, JSON fetch, JSON parse, stores data in JSON objects, has a recycler view and XML code for the UI; such an app would be pretty tough to do in under 150 lines of code, including the UI (XML for Android). That’s tough, but maybe not impossible for a dev with 10 or 20 years of experience. But with Flutter a noob can do it in under 150 lines even with sloppy code (the UI and logic are both in Dart so there’s no XML).

And I’ve been told that a highly experienced dev might be able to pull it off in under 50 lines… if you bet them money that it can’t be done.

Dart 2 is technically in Beta but it’s the default in Flutter already and we’re using it every day. And though Flutter is technically in Beta you have to remember that the framework was mature enough that many companies were already using it for production code when it was in Alpha. And FYI, Flutter’s “Beta” is just the the previous month’s most stable Alpha. Most of the regulars just run the bleeding edge Master branch with no issues at all but once every two to three months you might hit a bug… Which is pretty impressive when you consider that there’s a version change about every 36 hours.

Lastly, the UI code is really easy to read once you see the syntax for what it is. Every child is actually a constructor for an anonymous class however in Dart 2 we no longer need to use the “new” keyword. Since you normally expect anonymous classes to be instantiated with a new keyword, this can be a little confusing until it sinks in and you get used to it. Set your IDE colors so that constructors will be their own, special color. That will make your life easier for the first month or two.

A colon (:) appears at the end of every parameter for those anonymous classes, and you’ll see them everywhere. The UI code for Flutter is written in Dart, just like the business logic is. The difference is that the UI code is nested and full of parameters.

Here’s an example: Let’s say you want a Container that is blue with some text in it, the text should be centered both vertically and horizontally and it needs to run right to left. That’s too easy. So let’s have a little more fun and decide what the text will be at run time.

We don’t need a state, so we use a Stateless Widget for our foundation.

  • This Widget is made of other Widgets, kind of like a List of Lists. So we return a Widget tree, starting with a Container.
  • The color: statement is an optional parameter; here we make the Container blue.
  • The child: is inside the container and Center will center its child on both the vertical and horizontal axis. The Center also had a child: and here that child: is our Directionality.
  • Rich text needs a direction specified because not all languages run in the same direction and we don’t make assumptions. Note, the text direction “TextDirection.ltr” could be decided at run time the same way we’re setting the text’s String at run time here, but by checking the default language instead of a random bool.
  • The Directionality widget also has a child: … but I’ll bet you guessed that already.
  • Now we get to our Text. In a Text Widget, the very first parameter must be the string. In this case, it’s all we need. But instead of the usual Text(“Hello World”), we’re tossing a coin to see which string to use. We do this by generating a random boolean and then using a ternary statement. And no, my use of the new keyword was not a mistake, just like the fact that I used single quotes for one string and double for the other wasn’t a mistake. I wanted to show you there is more than one way to do these things. Here’s our ternary statement:
new Random().nextBool() ? “Hello World” : ‘Goodbye Cruel World’ ;

In case you don’t use those, here is the same logic in a regular if which will not work in Flutter UI code. This is why we use the ternary… because even though a regular if statement works fine in your business logic, it won’t work inside of Flutter’s UI constructors.

EDIT: Almost two weeks after publishing this article I was shown an approach that will enable the use of a regular if in the UI code. What you do is set the value of a parameter to be a function, and then make the function inline instead of calling in a function that is elsewhere. If playing with this style, please remember to keep it simple, and readable.

if (new Random().nextBool()) {
return “Hello World”;
} else {
return “Goodbye Cruel World”;
}

In the immortal words if Zig Ziglar: “Are you convinced yet or do I need to tell you more?”

Here is where to get started:

The official Flutter website: https://flutter.io

The Flutter repo on Github: https://github.com/flutter/flutter

Gitter: The official place to come and ask for real time, live help with Flutter: https://gitter.im/flutter/flutter

Flutter Architecture samples by Brian Egan: https://github.com/brianegan/flutter_architecture_samples

Beyond that, VoidRealms’ YouTube channel has done a long series starting from basic dart all the way up through an entire Pizza Ordering app!

And by the time you’ve finished the Pizza Ordering app you’ll have accumulated your own list of links and resources people have recommended to you so you don’t really need anything else from me.

To sum up, this article wasn’t really meant to teach you anything about Flutter. It’s mean to recruit you to the Dark Side.

Or is that the Dart Side?

--

--

Scott Stoll
Flutter Community

Freelance Flutter Developer | Speaker | Workshop Presenter. Organizer of GDG Cleveland. Twitter: @scottstoll2017