Create smartphone applications with Flutter

by | 18.01.2020 | Software development | 0 comments

Frameworks that provide a common code base for mobile application development for both Android and iOS are easy to find today. For example, there is React Native from Facebook, Microsoft offers Xamarin and Google offers Flutter, a corresponding framework. But since Flutter has only been on the market since May 2017, there are no common architecture patterns or a guide to app architecture as known from the Android environment.

I would like to introduce you to a way that I think is well suited for creating medium to large smartphone applications. This way or rather this architectural style is called BLoC.

What is a BloC?

A BLoC is a Business Logic Component, and there may be several of them per application. The core message of the BloC pattern is that everything in the app is mapped as a stream of events. Example: In widget 1 a button is pressed, in widget 2 the UI is supposed to change, so BLoC provides a stream in the middle, which widget 2 can listen to and widget 1 can fill.

A big advantage of this approach is that Dart already provides its own syntax for working with streams, and no additional plugins are needed to implement BLoCs in Flutter.

A real-life implementation with example

Most business apps must always perform the following tasks in some form or another:

Load data from a server.
Process the loaded data.
Display the processed data in the UI.

In my example, these three tasks also have to be performed. My application uses the OpenLigaDb¹ API to load any soccer game using an http get request. The game data is in JSON format and has to be mapped to a suitable data class. The converted data is then displayed on the interface.

In accordance with the three tasks mentioned, the apps usually have three architecture layers. At the beginning of my work with Flutter I had difficulties to structure my files logically. In the end I decided to cut the project according to the individual architecture layers namely the UI, the BloCs and the services. Additionally I use a “models” folder where all data classes are stored.

Filing structure in the Flutter example

The implementation of the data layer

For the service I create a new class FootballService in the football_service.dart file. This class basically consists of the method getMatchData(id) with the match id as parameter. To send a http-get-request, the dart package “http” is used, which is announced in the pubspec.yaml file at the beginning.

The request is sent to the URL “https://www.openligadb.de/api/getmatchdata/$id” and returns the soccer game with the specified id.

Calling the service

The FootballService is now used in the underlying BLoC layer. Every BloC must extend the abstract class bloc and overwrite its dispose method.

The FootballBloc has a public method getMatch() that can be called from the UI, and two private methods that are responsible for creating a random number and mapping the http response to a game object. The game data object looks like this:

Perhaps the most important thing about FootballBloc is the gameStream, which it makes publicly available as a getter. In the next step, the UI can register on this stream to display a newly loaded game.

The management of dependencies

Jetzt stellt sich natürlich die Frage, wie man die BloC der UI bekannt macht? Für dieses einfache Beispiel wäre es möglich, eine Instanz der FootballBlocs in der UI zu erstellen, und darüber die Aufrufe abzuwickeln. Sobald das Projekt jedoch minimal komplexer wird, und man dieselbe BloC in mehreren Widgets benutzen möchte, ist dieses Vorgehen nicht mehr adäquat. Deshalb nutzt man vorzugsweise Provider-Widgets, um seine einzelnen BLoCs der ganzen Anwendung zur Verfügung zu stellen.

Im Ordner blocs sollte dazu ein weiterer Ordner essentials angelegt werden. Darin befinden sich die bloc_provider.dart- und die app_bloc.dart-Datei.

Now the question arises, of course, how to make the BloC known to the UI? For this simple example, it would be possible to create an instance of the Footballbloc in the UI and use it to handle the calls. But as soon as the project becomes minimally more complex, and you want to use the same BloC in several widgets, this approach is no longer adequate. Therefore, it is preferable to use provider widgets to make your individual BLoCs available to the entire application.

To do this, you should create another folder called essentials in the blocs folder. This folder contains the bloc_provider.dart and the app_bloc.dart file.

The AppBloc is a class that instantiates each BloC once and makes it accessible via a getter. In AppBloc the BloCs could communicate with each other if desired. For example, this can be helpful for an app with an authorisation feature. In this example the AppBloc is passed as a constructor argument to the BlocProvider widget. The approach to implement this using an AppBloc that contains all BLoCs does not necessarily have to be the best for every application.

The BlocProvider is a widget by the way. The of() method allows other child widgets to get all BloCs of the AppBlocs via the BlocProvider. For this to work, the BlocProvider widget in the main.dart file must be wrapped around the MaterialApp widget.

After this small but useful detour, we can now move on to creating the UI. This consists of a column widget that displays the text of the currently loaded game and a button below it.

Especially noteworthy are the interactions with the FootballBloc on whose stream you are registered (lines 11 to 15), and the onPressed method of the button (lines 26 to 28).

And this is what the result looks like: 

Flutter Example

Conclusion

I enjoy working with Flutter. From my point of view it is a very useful framework. I am especially impressed by the fact that Flutter, unlike React Native or Xamarin, does not use the native UI components of Android and iOS, but draws the screen content completely by itself with a 2D rendering engine, and yet the Flutter apps look like native apps. Of course, as said before, the architecture patterns and a guide to the app architecture are missing, and using the various widgets also requires some practice at the beginning, but once you get the hang of it, it makes implementation significantly easier. Could the task have been solved differently? Probably. How would you have dealt with it? I’m interested in your opinion and would be happy about an exchange.

 

Notes:

[1] API of OpenLigaDB: https://www.openligadb.de/
Especially the source code and layer architecture is inspired by https://www.raywenderlich.com/4074597-getting-started-with-the-bloc-pattern and David Anaya.

Mark Heimer
Mark Heimer

Mark Heimer is a dual student at t2informatik in cooperation with the Berlin University of Applied Sciences, specialising in computer science. Hackathons and programming computer games are his passion. In his practical phases he is currently developing a t2informatik-internal software for time recording.