What Is Flutter?

Cross-platform development

My favorite burger joint advertised a new mobile ordering app. I needed the app so that I could quickly hop off a commuter train, grab a burger, and run to a nearby tech meeting. I did this several times each month. But I had a problem: The app ran only on iPhones, and I had an Android phone.

Behind the scenes, the burger joint’s app developers were hard at work converting their iPhone app to an Android app. This was no minor task, because Android’s API doesn’t recognize the same commands as iPhone’s API. Going from one API to the other isn’t straightforward. It’s not a matter of making routine code changes. To convert from one kind of phone to another, developers rewrite thousands (and maybe even millions) of lines of code. The process is time-consuming and expensive.

So I waited and waited for the restaurant to have an Android app. I was so desperate for a delicious cheeseburger that I finally broke down and bought a second phone. But that turned out to be a bad idea. As soon as my new iPhone arrived, the burger place released its shiny, new Android app.

The whole story comes down to things called platforms. People throw around the word platform as if the word means everything and nothing. But to my mind, a platform is a particular operating system along with the hardware the OS runs on.

What makes the Android platform different from its iOS counterpart? To create radio buttons in Android’s API, you write code of the following kind:

A quick-and-easy development cycle

You may have heard stories about the early days of computer programming. I worked for a few summers at the University of Pennsylvania Physics department. I wrote FORTRAN programs and typed them myself on a big deck of punch cards. A 600-line program weighed about 1400 grams (roughly 3 pounds).

I’d carry my program from the punch card machine to the computer operator’s counter, where a permanently surly operator would tell me about the unusually long job-turnaround time.

Four hours later, I’d get back an inch-thick pile of paper with an error message somewhere in the middle of it. I’d go back to the punch card machine, make another card with an added comma in the 23rd column, and do the whole business again.

There’s no doubt about it — a long and arduous development cycle hinders productivity. These days, shaving a few seconds off the turnaround time can make a huge difference.

Here’s what happens when you create an app for mobile devices:

1. You write some code, or you modify some existing code.

   You don’t write Android or iOS code on a phone of any kind. Phones aren’t powerful enough for all the editing and other stuff you need to do. Instead, you create an app’s code on a laptop or desktop computer. This laptop or desktop computer is called your development computer.

2. You issue a command for your development computer to build the code.

   Building the code takes place in several stages, one of which is called compiling. Compiling means automatically translating your program from the source code you wrote to detailed object code instructions. Think of object code as a bunch of zeros and ones. It’s very detailed and extremely unintuitive. Humans hardly ever read or write object code but, at the heart of things, processors respond only to object code instructions.

   For a detailed look at compiling code, see this section’s “What is a compiler?” sidebar.

   In addition to the translation step, the build process connects the program you wrote with additional code that your program needs in order to run. For example, if your program accesses the Internet, the build process integrates your code with existing network code.

   What happens next?

3. The development computer deploys your code to a target device.

   This so-called “device” may be a real phone connected to your computer or a picture of a phone on your computer’s screen. One way or another, your program starts running.

4. You press buttons, type text, and otherwise test your app to find out whether it’s doing the things you want it to do.

   Of course, it’s not doing all those things. So you return to Step 1 and keep trying.

Steps 2 and 3 can be painfully slow. For some simple iPhone and Android apps, I’ve watched for several minutes as my computer prepares code for the program’s next run. This sluggishness reduces my productivity considerably.

But along with Flutter comes some good news. Flutter uses the Dart programming language, and Dart comes with these two (count ’em — two) compilers:

• Ahead-of-time (AOT) compiler

  With an AOT compiler, your development computer translates an entire program and makes the translated code available for devices to run. No further translation takes place when the devices run your program. Each target device devotes its processing power to the efficient running of your code.

  An app running on AOT-compiled code runs smoothly and efficiently.

• Just-in-time (JIT) compiler

  With a JIT compiler, your development computer translates enough code to start the app running. It feeds this code to a test device and continues translating while the test device runs the app. If the developer presses a button on the test device’s screen, the JIT compiler hurries to translate that button’s code.

  An app running on a JIT compiler may appear to be sluggish because the compiler translates code while the app runs. But using a JIT compiler is a great way to test an app.

Here’s what happens when you develop a Flutter app:

1. You write some code.

2. You issue a command for your development computer to build the code.

   The first time around, building code can take some time.

3. The development computer deploys your code to a target device.

   Again, you face a noticeable time lag.

4. In testing your code, you find out that it’s not doing all the things you want it to do.
5. You modify your existing code, and then …

6. You issue a command for your development computer to rebuild the code.

   Here’s where Flutter’s magic happens. Dart’s JIT compiler recompiles only the part of the app that you’ve modified and sends the change straight to the target device. The modified code starts running in a fraction of a second. You save hours of time every day because you’re not waiting for code changes to take effect.

Flutter gives you two ways to apply changes to a running app:

• With hot restart, the app begins its run anew, removing any data that you’ve entered during the most recent test, displaying the app as if you’re running it for the first time.
• With hot reload, the app takes up from where it left off, with the data you last entered intact, if possible. The only changes are the ones dictated by your modifications to the code.

Flutter’s hot restart and hot reload are both blazingly fast. They turn the app development cycle into a pleasure rather than a chore.

Chapter 2 tells you more about building, testing, and rerunning apps.

A great way to think about app development

The language you speak influences the way you think. If you don’t believe me, look up the Sapir-Whorf hypothesis. You’re bound to find it on your favorite linguistics website.

Spoken languages are neither good nor bad, but programming languages can have good qualities and bad qualities. Most hybrid apps are written in the JavaScript programming language. Yes, JavaScript is one of the world’s most widely used languages. But, no, JavaScript doesn’t encourage good software design. It’s easy to write confusing code in JavaScript because its rules are quite permissive. You can write sloppy JavaScript code, and the code runs just fine. That is, it runs fine until someone enters unexpected input. When that happens, you have trouble figuring out how your code was working in the first place. Even when you’re not busy fixing errors, adding new features to JavaScript code can be difficult and frustrating. JavaScript aficionados will argue with every word in this paragraph but, one way or another, JavaScript has its downsides.

Apple’s iOS platform uses the Swift and Objective-C languages, whereas Android uses Kotlin and Java. Objective-C dates back to the early 1980s and, like me, it’s showing its age. The other three languages fare pretty well on the scale of good language features, but none of them is as straightforward and intuitive as Dart.

On top of that, both iOS and Android divide an app’s code into two separate parts:

• Layout: How the app looks.
• Logic: The sequence of instructions that the app performs.

The Android radio button example in this chapter’s earlier section “Cross-platform development” is neither Kotlin nor Java code. It’s XML code (a term that I don’t bother to define here). It has a different format and lives in a different file from the code that responds to radio button choices.

In my Android books, I argue that separating layout from logic is a good thing. It puts distinct aspects of an app into different parts of the code. Developers can maintain each part independently. For an Android developer, that’s a good thing.

But this isn’t an Android book. It’s a Flutter book. So, in this book, I claim that separating layout from logic is not optimal. Here’s why:

You may have heard the all-encompassing mantra of Flutter app development:

In Flutter, almost everything is a widget.

And what is a widget? In a mobile app, every button is one of the app’s widgets. Every text field is a widget. The app itself is a widget. The positioning of buttons and text fields is a widget. The animating of objects from one part of the screen to another is a widget. When you create a Flutter app, you put widgets inside of other widgets, which in turn are inside even more widgets. Listing 1-1 has some fake code that illustrates the point:

LISTING 1-1 Like a Wheel Within a Wheel

// Don’t fall for my trickery. This isn’t real Flutter code!
Application(
Background(
CenterWhateverIsInsideThis(
Button(
onPressed: print("I've been clicked."),
Padding(
Text(
"Click Me"
),
),
),
),
),
)

Listing 1-1 has a Text widget inside of a Padding widget, which is inside of a Button widget inside a CenterWhateverIsInsideThis widget. That CenterWhateverIsInsideThis widget is inside a Background widget, which is inside an Application widget. When I created Listing 1-1, I modeled it after real Flutter code. The real Flutter code creates the app shown in Figure 1-2. When the user presses the Button in Figure 1-2, the words I’ve been clicked appear.

To see the real code that inspired this chapter’s fake code, visit www.allmycode.com/flutter and look for the big download link. The real code is in a file named app0101.

Compare Figures 1-2 and 1-3. Figure 1-2 shows the app as the user sees it. Figure 1-3 shows the same app as the Flutter developer codes it.

If you’re not already a Flutter developer, the word widget might suggest a visible component, such as a button, a slider, an icon, or some other such thing. But in Flutter, things that aren’t really visible are also widgets. For example, in Listing 1-1, CenterWhateverIsInsideThis is a widget. Having layout features like CenterWhateverIsInsideThis be widgets is a powerful idea. It means that Flutter developers can focus their attention on one overarching task — stuffing widgets inside other widgets. Flutter has a certain simplicity and elegance that other app development frameworks don’t have.

Flutter has no built-in widget named CenterWhateverIsInsideThis. But don’t be disappointed. Flutter’s Center widget does what my fictitious CenterWhateverIsInsideThis widget is supposed to do.