Ab Februar 2025 Pflicht (EU AI Act): Anbieter und Betreiber von KI-Systemen müssen KI-Kompetenz nachweisen.
Alle Informatonen 
Apps

Flutter: New Concepts? (Part 2)

Lesezeit
6 ​​min

Notice:
This post is older than 5 years – the content might be outdated.

Building complex applications in Flutter demands a basic understanding of the core concepts. Those concepts include the navigation between screens or saving simple key-value pairs. In this article I will show three of the most common concepts every developer should know.

Before We Are Getting Started

Since Flutter is a cross-platform solution to build mobile applications, it inherits some of the platforms‘ individual concepts. For example, Android provides access to the SharedPreferences API, and iOS uses UserDefaults API. Both provide an interface to the system memory.

Flutter’s basic concept is based on plugins, which we can use to access functionality on both platforms. Plugins extend the core features of the provided Flutter framework in the form of basic packages or third party libraries.

RIP: Three Basic Concepts for Flutter

It is fundamental to know a minimum of basic concepts in every framework. In this article I call this abstract concept RIP. RIP is not an official definition but it will help you remember as soon as a new framework pops up. It excludes REST API calls and any other external interaction, as those features are usually included by third party packages (http or jsoup).

RIP stands for

  • Responsiveness
  • In app routing
  • Persistence

It covers the three most common tasks which have to be handled in any application. With more time and experience we will discover other strategies or designs to build the same functionality.

Responsiveness

A responsive UI is a minimum requirement and needs to be handled with great care. It demands a clear vision of what the app should look like and more importantly, how the app should behave (state management).

Flutter responsive application
Responsive mobile application

In Flutter we have various options to build a responsive UI, as explained in the Flutter GitHub repository from Ian Hickson: Either with the implementation of a LayoutBuilder or the MediaQuery. In this article we will concentrate on the MediaQuery to create a responsive test widget.

Initial application setup

The TestWidget shown above consists of a simple container with fixed dimensions. To transform this widget into a responsive widget, we are calling the MediaQuery.of() method from Flutter’s core package. The method provides the size and orientation of the application (screen) with each build of the widget. The build function is called with every state change. For example, the state changes as soon as the orientation of the application (screen) changes. This state change causes the widget to rebuilt and recalculate the dimensions of the widget.

Call MediaQuery.of() to get screen size as per state

From here on it is possible to either trickle down the height and width or to create a child with the max size of the parent. A proper widget tree planning is crucial at this stage, because the size of all child widgets depends on the parent’s container dimensions. More references about layouts and responsive UIs in Flutter can be found at the end of this article.

In-App Routing

The navigation through application screens can be managed with two routing options.

  1. Routing with defined routes
  2. Routing without defined routes

Routes define a UI representation of a widget and help to keep the code organized. All routes a registered in the root widget (MaterialApp()) and can be retrieved from any point in the application with the Navigator.

Flutter Routing I
Routing I

 

Create, import screens and define routes in MaterialApp()

 

Register the routes in the MaterialApp() root widget

Flutter Routing II
Routing II

Navigation with named routes

The navigation with routes in Flutter runs both ways, either push to a new widget or pop back to where we came from. One little drawback exists, as I could not find a nice way to attach data to the Navigator with a named route. But in Flutter we have other concepts like streams & sinks, which I will talk about in a future article.

Navigation without named routes

If the application does not require a pre-declared routes, it is possible to navigate directly to other screen widgets in Flutter. In this case we can use the MaterialPageRoute builder option. This builder does the same as the pre-declared routes, but only at the defined location.

Persistence

Saving simple key-value pairs is a basic feature and straight forward to implement. The standard solution will be following the 4 steps below which can be found at the official Flutter documentation.

  1. Include library (shared_preferences)
  2. Save a key-value pair
  3. Retrieve a key-value pair
  4. Delete a key-value pair

Add dependency to pubspec.yaml

Save

Retrieve

Remove

Shared preferences are designed to store simple data only (primitive data types). If you’d like to store more and/or structured data you should look into Firebase or an sqlLite solution.

Conclusion

Now we are able to create and manage a responsive UI, navigate through various screens and persist simple key-value pairs. This gives us the basic tooling to create amazing but simple apps.

In the next Blog:  Flutter: The Profiler (Part 3), we are looking deeper into building lightweight responsive layouts. We will build a simple profile app (master/detail), which can be seen as a prototype for many similar structures.

In the meantime, have a look at this Medium post: Flutter layout in a nutshell, or check out my other articles on Flutter.

All Articles in this Series

Read on

Flutter Medium Blog

Find out more about our Android and iOS portfolio or join us as a mobile developer!

2 Kommentare

Hat dir der Beitrag gefallen?

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert