Unlock the Power of Low Code, No Code: Revolutionizing Development

How Flutter’s building blocks give you an edge over other frameworks

Introduction

Before we deep dive into the building blocks of the Flutter, let us go over a short introduction. Flutter is an open-source, cross-platform mobile app UI toolkit developed by Google. Released in May 2017, it has grown exponentially over the last few years to pose a significant competition to React Native. With its single codebase, it allows the creation of native mobile applications to be launched across multiple platforms. This reduces the time taken to code and makes building an MVP easy and rapid.

You can read more about the features of Flutter in detail here. In this blog post, we are going to discuss the building blocks of Flutter. 

The architectural framework

Flutter is designed as a layered system as evident in the image above. Each layer is independent and depends on the layer below. 

Based on the underlying OS, the platform-specific embedder 

  • Presents an entry point
  • Coordinates with the underlying OS [for rendering surfaces, accessibility, and input]
  • Manages the message event loop. 

Flutter app development includes several embedders for popular target platforms, but other embedders also exist. Additionally, the Flutter engine is mostly written in C++ and provides support for all Flutter applications. 

The engine takes care of the following:

  • Rasterizing composited scenes when a new frame needs to be painted
  • Offering low-level implementation of Flutter’s core API

Dart:ui wraps the underlying C++ code in Dart classes, exposing the lowest-level primitives [classes for driving input, graphics, and text rendering subsystems]

Widgets

The basic building blocks of Flutter are the widgets, each one contributing to the app UI design and UX. Widgets in Flutter are designed based on composition to form a hierarchy. Every widget receives context from the parent widget and nests within them. This is consistent until the root widget [MaterialApp or CupertinoApp]. 

User interaction prompts the app to update the UI. The Flutter framework gets notified to replace a widget in the hierarchy with another widget. These are compared and the UI is updated.  

With a pure Dart implementation of both the iOS Switch control and the Android equivalent, Flutter has its own implementations of each UI control.

This feature is incredibly handy in the following ways: 

  • Unlimited extensibility. Developers are not limited to the extension points provided by the OS and can create one arbitrarily.
  • Avoids performance bottleneck. The need to go back and forth between Flutter code and platform code is eliminated.
  • Detaches the application from any OS dependencies. This maintains the visual consistency of the application across all versions of the OS, even control implementation has changed.

Widget Composition

Widgets are typically composed of several smaller, single-purpose widgets that unite to generate potent impact. Minimizing the number of design concepts enables the total vocabulary to be considerable.

The class hierarchy is intentionally wide to maximize the possible number of combinations. This allows the focus to be on small, composable widgets each doing one thing excellently. The abstract core features allow for basic features such as padding and alignment to be implemented as separate components. Traditional APIs have these features built-in to the core of all layout elements.

For instance, centering a widget would require wrapping it in a center widget instead of adjusting a notional Align property.

Layout widgets, such as padding, alignment, rows, columns, and grids do not have a visual representation of their own. Their objective is to regulate an aspect of a different widget’s layout. 

Building widgets

The visual representation of a widget is determined by overriding the build() function to return a new element tree [precisely represents the widget’s part of UI] 

The Flutter framework recursively requires individual widgets to be built until the tree is completely characterized by concrete renderable objects. This helps in building a framework of a renderable object tree by bringing together renderable objects.

It is essential for a widget’s build function to be free of side effects. The Flutter framework does the heavy lifting to ascertain which build methods need to be called based on the render object tree.

Widget state

The Flutter framework has two major classes of widgets: stateful and stateless.

Stateless widgets do not have properties that change over time (for example, a thumbnail or a label). 

Stateful widgets are those whose characteristics evolve based on user interaction or other factors. For instance, if tapping a button causes the number on a counter to increasing, the value of the counter is the state for that widget. When the corresponding value changes, the widget needs to be rebuilt to update its part of the UI. 

Stateful widgets store mutable states in separate classes than subclass States. Their UI is built through their State object.

Disparate state and widget objects allow both stateless and stateful widgets to be treated the same way. This allows the creation of a new instance of the widget at any point without worrying about losing the widget’s persistent state. 

These are some of the features that enable Flutter to build on widgets as a UI construct. There are plenty of resources online to learn more about various components of Flutter. You can find the official documentation here

Josh Software

With a robust UI and a great online community, Flutter is an excellent platform for developing apps. Josh Software is a leader in developing mobile applications. Get in touch to start your mobile app journey with us.

Author
Publish Info
Follow Us On