What is Flutter?

Since the advent of the Apple App Store (and subsequently, the Google Play Store), there has been a way for organizations to share programs with mobile users in a very controlled and managed way. Much like websites on the internet, mobile apps have proliferated to encompass all aspects of our life. And much like websites, over the years, developers have iteratively discovered and learned the best ways to create reliable, scalable, and intuitive mobile apps.

As developers have learned to work within the mobile ecosystem, they have followed similar design patterns and framework ideas that were created to deal with the web ecosystem. Much like the complications of developing code for multiple browsers on the web, in the mobile ecosystem, there has been the challenge of developing code that can work on both iOS and Android devices, with the dream always being to have one code base that works across all devices, and even the web.

Flutter is a framework that is the culmination of this learning. Like most other frameworks, developers use a programming language specified by the framework and structure their code in a way that aligns with the needs of the framework so that ultimately, the developer creates the least amount of “boilerplate” code and can focus on their business needs. Examples of “boilerplate” code would be how to manage touch input, how to connect to the internet, and how to package the app code so that it works with the App Store, Play Store, or web hosting service.

Flutter is a relatively new framework, yet on Google Trends, Flutter comes out above all of its competitor frameworks such as React Native, Xamarin, Swift, and Kotlin, and the outlook for the next few years is highly positive.

When choosing a new programming language or framework, developers and software companies need to assess certain key aspects of the language or framework to ensure it is easy to pick up and that it has a bright, long-term future. Investing time and money into the learning of a new solution, and then developing a code base and development processes around that language and framework, is incredibly expensive. If that solution becomes outdated after a short period, there is poor support and documentation, there is a lack of new developers available to take the product forward, or the solution has scaling issues or usability problems, then that investment is wasted. For a small start-up or a low-funded project, it can even be terminal. With that in mind, let’s look at some of the aspects that suggest Flutter may be a good long-term investment.

Backed by Google

Flutter, and the Dart programming language it depends on, were created by Google, and although they are open source, they continue to be strongly backed by Google. This ensures the framework has all the tools it needs to succeed in the community, with support from the Google team, presence at big events such as Google I/O, Flutter Forward, and investment into continuous improvement in the code base.

From the launch of the first stable release during the Flutter Live Event at the end of 2018, the growth of Flutter is evident:

• Flutter apps have been installed on hundreds of millions of devices
• More than 700,000 Flutter apps have been released
• Flutter has been used by more than 5 million developers
• It is the 18th most popular software repository on GitHub

Not only has Google backed Flutter, but they have also put it at the heart of their plans. Important Google apps such as Google Ads and Google Pay are Flutter apps, and Google’s future replacement for Android, Fuchsia OS, is built around Flutter.

Fuchsia OS and Flutter

It’s not a secret anymore that Google has been working on a new operating system (OS) called Fuchsia OS, which has long been rumored as a potential future replacement for the Android OS. One thing to pay attention to is that Fuchsia OS may be a universal Google OS that runs on more than just mobile phones, and this would directly affect Flutter adoption. This is because Flutter will be the primary method of developing mobile apps for the new Fuchsia OS, and, not only this, Fuchsia also uses Flutter as its UI rendering engine. With the system targeting more devices than just smartphones, as seems to be the case, Flutter will certainly have a lot of improvements.

The growth of the framework’s adoption is directly related to the new Fuchsia OS. As it gets closer to launch, Google needs to have mobile apps targeting the new system. For example, Google has announced that Android apps will be compatible with the new OS, making the transition to and adoption of Flutter significantly easier.

However, a framework, no matter how good, benefits from a well-designed and elegant programming language that allows developers to focus on the “what” of their app rather than the “how.” The success of Flutter is very much linked to the Dart programming language that the framework uses throughout.

Dart

The Dart programming language was first unveiled by Google at the GOTO conference in 2011, and Dart 1.0 was released at the end of 2013. Initially viewed as a replacement for JavaScript (the main web programming language), the uptake of Dart by developers was relatively low. However, thanks to the emergence of Flutter and its reliance on Dart, the Dart programming language has seen a huge rise in usage.

So, why did the Flutter project choose the Dart programming language? Since its inception, one of Flutter’s main goals was to be a high-performance alternative to existing cross-platform frameworks and also to significantly improve the mobile developer’s experience.

With this in mind, Flutter needed a programming language that allowed it to accomplish these goals, and Dart is the perfect match for the following reasons:

• Dart compilation: Dart is flexible enough to provide different ways of executing the app code depending on the circumstances. Flutter uses Dart ahead-of-time (AOT) compilation with performance in mind when compiling a production-ready version of the application, and it uses just-in-time (JIT) compilation with a sub-second compilation of code in development time, aiming for fast feedback for code changes. Dart JIT and AOT refer to when the compilation phase takes place. In AOT, code is compiled during the build process and before running the code; in JIT, code is compiled while running (check out the Dart introduction section in the next chapter).
• High performance: Due to Dart’s support for AOT compilation, Flutter does not require a slow bridge between realms (for example, non-native Flutter code to native device code), which makes Flutter apps responsive and allows a fast startup.
• Garbage collection: Flutter uses a functional-style flow with short-lived objects, and this means a lot of short-lived allocations. Dart garbage collection works without locks, helping with fast allocation.
• Easy to learn: Dart is a flexible, robust, modern, and advanced language. The language has been adapted as Flutter has become more popular, with lots of syntax improvements to simplify the development experience (syntactic sugar), and fundamental design changes that help with Flutter app creation. Although it is still evolving, the language has a well-defined object-oriented framework with familiar functionalities to dynamic and static languages, an active community, and very well-structured documentation.
• Declarative UI: In Flutter, you use a declarative style to lay out widgets, which means that widgets are immutable and are only lightweight “blueprints.” To change the UI, a widget triggers a rebuild on itself and its subtree, creating a new blueprint that, for the most part, matches the previous blueprint with some changes. This is in contrast to the imperative style (the most common), where you explicitly change specific component properties through function calls after they are created Declarative UI.

We will explore this a lot more throughout this book, but if you want to understand the concept of the Flutter declarative UI at this point, then take a look at the official introduction to declarative UI from Flutter: https://flutter.dev/docs/get-started/flutter-for/declarative.

• Dart syntax for layout and styling: Different from many frameworks that have separate syntax for layout and styling, in Flutter, the layout and styling are specified inline within the Dart code. This gives greater flexibility and reduces the developer’s cognitive load. The use of HTML, JavaScript, and CSS for web page design is an example of the opposite approach where the functionality, layout, and styling are managed through different syntax. Developers need to know HTML, JavaScript, and CSS to create a complete web page. Flutter also has great tools for debugging layout, as well as investigating and refining the rendering performance of your code.

These are great reasons why Dart fits perfectly with Flutter. However, there is an area of Flutter that we haven’t yet explored and is probably the main reason that you are learning and using it, and explains why it is a game-changer in the app development world: a single code base for multiple platforms. Let’s take a look at that now.

One code base to rule them all

The primary goal of the Flutter framework is to be a toolkit for building apps that are equivalent in performance, usability, and features to native apps (apps created directly for iOS or Android) while using only a single code base. You may have heard it stated often that there are big advantages to having a single code base. Let’s see why that is the case:

• Multiple languages to learn: If a developer wants to develop for multiple platforms, they must learn how to do something in one OS and programming language, and later, the same thing in another OS and programming language. The developer then needs to decide whether to focus on one platform for a certain period, causing a mismatch of features/bug fixes between the apps, or constantly switch between platforms, impacting productivity and potentially introducing bugs.
• Long/more expensive development cycles: If you decide to create multiple development teams to avoid the previous issues, there are consequences in terms of cost, multiple deadlines, different capabilities of native frameworks, and disparate sets of bug reports.
• Inconsistency: Different native capabilities, or different development teams developing features in slightly different ways, may lead to inconsistencies between apps, annoying users, and making bug reporting more complicated to diagnose.

Flutter is not the first attempt to create a single code base and there are existing frameworks available that have similar promises. However, they can suffer from some serious drawbacks:

• Performance: Some frameworks use workarounds to allow consistency of user experience across platforms. One of these is to have a web page running inside a native app using a web view (a built-in web browser). This tends to have much worse performance than native apps, leading to a poor user experience.
• Design constraints: Some frameworks are based on languages that were designed before the mobile experience was created. This can mean they are not designed well for certain user interactions or certain device capabilities, leading to complicated or obscure code, and the inherent maintenance issues this can cause.
• Not quite one code base: Although some frameworks suggest a single code base approach to app development, once you get into the details, you will find that you still need to write some platform-specific code, which causes code duplication and allows single platform bugs to creep in.

Now, let’s see how Flutter solves these problems.

Bi-directional communication between Flutter to native

Bi-directional communication between Flutter and native refers to the ability of a Flutter application to communicate with a native application (for example, Android or iOS) and vice versa. Flutter is a mobile app SDK for building high-performance, high-fidelity apps for iOS, Android, and the web using a single code base. Native apps, on the other hand, are built specifically for one platform and are written using that platform’s native language. With bi-directional communication, you can integrate Flutter widgets into an existing native app, or use native components within a Flutter app. This allows for a more seamless user experience and can improve performance by leveraging the strengths of both Flutter and native platforms.

For example, you can use Flutter to build a UI while using native code to access platform-specific features such as cameras, sensors, or storage. Flutter provides several mechanisms for bi-directional communication with native code, such as platform channels, method channels, and event channels.

Overall, bi-directional communication between Flutter and native is a powerful feature that allows developers to create sophisticated mobile applications that leverage the strengths of both Flutter and native platforms.

High performance

At the time of writing, it is hard to say that Flutter’s performance is always better in practice than other frameworks, but it’s safe to say that it aims to be. For example, its rendering layer was developed with a high frame rate in mind. As we will see in the Flutter rendering section, some of the existing frameworks rely on JavaScript and HTML rendering, which might cause overheads in performance because everything is drawn in a web view.

Some use original equipment manufacturer (OEM) widgets but rely on a bridge to request the OS API to render the components, which creates a bottleneck in the application because it needs an extra step to render the user interface (UI). See the Flutter rendering section for more details of the Flutter rendering approach compared to others.

Some points that make Flutter’s performance great are as follows:

• Flutter owns the pixels: Flutter renders the application pixel by pixel (see the next section), interacting directly with the Skia graphics engine or the new Impeller rendering engine.
• No extra layers or additional OS API calls: As Flutter owns the app rendering, it does not need additional calls to use the OEM widgets, so there’s no bottleneck.
• Flutter is compiled to native code: Flutter uses the Dart AOT compiler to produce native code. This means there’s no overhead in setting up an environment to interpret Dart code on the fly, and it runs just like a native app, starting more quickly than frameworks that need some kind of interpreter.

Full control of the UI

The Flutter framework chooses to do all the UI by itself, rendering the visual components directly to the canvas and requiring nothing more than the canvas from the platform. Most of the time, frameworks just reproduce what the platform offers in another way. For example, other web view-based cross-platform frameworks reproduce visual components using HTML elements with CSS styling. Other frameworks emulate the creation of the visual components and pass them to the device platform, which will render the OEM widgets like a natively developed app. We are not talking about performance here, so what else does Flutter offer by not using the OEM widgets and doing the job all by itself?

Let’s see:

• Ruling all the pixels on the device: Frameworks limited by OEM widgets will reproduce, at most, what a native-developed app would as they use only the platform’s available components. On the other hand, frameworks based on web technologies may reproduce more than platform-specific components, but may also be limited by the mobile web engine available on the device. By getting control of the UI rendering, Flutter allows the developer to create the UI in their own way by exposing an extensible and rich Widgets API, which provides tools that can be used to create a unique UI with no drawbacks in performance and no limits in design.
• Platform UI kits: By not using OEM widgets, Flutter can break the platform design, but it does not. Flutter is equipped with packages that provide platform design widgets – the Material set in Android and Cupertino in iOS. We will learn more about platform UI kits in Chapter 5, Building Your User Interface through Widgets.
• Achievable UI design requirements: Flutter provides a clean and robust API with the ability to reproduce layouts that are faithful to the design requirements. Unlike web-based frameworks that rely on CSS layout rules that can be large and complicated and even conflicting, Flutter simplifies this by adding semantic rules that can be used to make complex but efficient and beautiful layouts.
• Smoother look and feel: In addition to native widget kits, Flutter seeks to provide a native platform experience where the application is running, so fonts, gestures, and interactions are implemented in a platform-specific way, bringing a natural feel to the user, similar to a native application.

We refer to visual components as widgets. This is also what Flutter calls them. We will discuss more about this in the Widgets, widgets, everywhere section in this chapter.

Open source framework

Having a big company such as Google behind it is a huge benefit to a framework such as Flutter (see React, for example, which is maintained by Facebook). In addition, community support becomes even more important as it becomes more popular.

By being open source, the community and Google can work together to do the following:

• Help with bug fixes and documentation through code collaboration
• Create new educational content about the framework
• Support documentation and usage
• Make improvement decisions based on real feedback
• Share resources to make bug fixes and develop new features

Improving the developer experience is one of the main goals of the framework. Therefore, in addition to being close to the community, the framework provides great tools and resources for developers. Let’s take a look.

Developer resources and tooling

The focus on developers in the Flutter framework goes from documentation and learning resources to providing tools to help with productivity:

• Documentation and learning resources: Flutter websites are rich for developers coming from other platforms as they include many examples and use cases – for example, the famous Google Codelabs (https://codelabs.developers.google.com/?cat=Flutter).
• IDE integration: Flutter and Dart have a completed, integrated IDE experience with Android Studio, IntelliJ, and Visual Studio Code. Within this book, we will show examples from Visual Studio Code, but these examples will work very similarly in Android Studio and IntelliJ.
• Command-line tools: Dart has tools that help with analyzing, running, and managing dependencies and these are also part of Flutter. In addition, Flutter has commands to help with debugging, deploying, inspecting layout rendering, and integration with IDEs through Dart plugins. Here’s a list of the various commands:

Figure 1.1 – Available commands in Flutter

• Quick setup: Flutter has the create command, as shown in the preceding screenshot, which allows you to create a new and fully functional Flutter project with minimal input. IDEs also offer a Flutter project creation menu option, replicating the command-line functionality.
• Environment issue diagnostics: Flutter comes with the flutter doctor tool, which is a command-line tool that guides the developer through the system setup by indicating what they need to set up a Flutter environment. We will see this tool in action when we set up the project environment very soon. The flutter doctor command also identifies connected devices and whether there are any upgrades available.
• Hot reload: This is a huge benefit to developers and a feature that is getting a lot of attention. By combining the capabilities of the Dart language (such as JIT compilation) and the power of Flutter, it is possible for the developer to instantly see design changes made to code in the simulator or device. In Flutter, there is no specific tool for layout preview. Hot reload makes this unnecessary.

Now that we have learned about the benefits of Flutter, let’s do some exploring.