Flutter in business — First steps

Our thoughts on architecture

Mateusz Zając
4 min readJun 9, 2020
Photo by Marvin Meyer on Unsplash

Most of the time you must pay for your app’s technical debt. If you didn’t have good architecture after MVP it’s the right time to stop, to refactor and make your future easier. That’s the fact that writing smaller apps without architecture is easier, it’s hard to disagree, but think as a mature technical expert.

Test coverage, design patterns, code analysis that’s what I’m thinking about. This article will be about our approach to deliver exceptional apps alongside good code quality and team gladness.

Start with architecture

Provider, BLoC, Redux — if those words don’t have a familiar ring, please get basic understanding before moving forward.

All of them have both advantages and disadvantages and a choice it’s up to you.

Having knowledge of Flutter and how people have been adapting to project structure BLoC seems to be the easiest way to start.

IMHO the best way to show and understand how BLoC works is looking at the diagram below.

  1. Presentation layer sends events to BLoC.
  2. Data layer asynchronously performs longer operations ex. gets data from API or database.
  3. BloC yields returned value to UI.

As simple as that.

Implementing the BLoC pattern by yourself it’s really good exercise and you should do it once to fully understand how streams work behind it. If you’ve already done so

And use…

BLoC library

Fortunately, the community did not disappoint. You don’t have to write BLoC every time, just use this handy library — FlutterBloc.

I’d like to point few of the key features:

  • Event — State communication without boilerplate,
  • Dependency Injection through BlocProvider,
  • BlocBuilder to build widget based on received state,
  • BlocDelegate makes handling errors globally much easier,
  • BLoC may (and should!) be tested.

Check out the full lib description on flutter_bloc | Flutter Package

Communicating with REST API

Photo by Leon Seibert on Unsplash

If you create a mobile app, you’re gonna connect with a remote data source. Most common way to do it is REST APIs and JSON. Sure, you’ve done it so many times before so no more explanations.

Coming from Android world indicates you’ve used Retrofit, GSON or Moshi JSON converters. Those are really I mean really great tools.

In Flutter we use either Chopper or Retrofit for Dart.

In both cases you need to define abstract class for your API and generate it using flutter pub run build_runner build.

Next, there’s no GSON like library to convert JSON to POJO. Either you need to write your own mapper function or use json_serializable which automatically generates code for converting to and from JSON by annotating Dart classes. The process itself is pretty straightforward and for sure you will get used to it.

Persist it locally

Photo by Twitter: @jankolario on Unsplash

When it comes to caching our data in most cases Sqflite is our first choice. It’s just an SQLite Dart implementation with support for:

- raw SQL query,

- handy helpers for insert/query/update/delete,

- batch — avoid performance issues.

Analyze code

Having and keeping code style in your projects might be crucial for your team. Same as for architecture it is a crucial factor to maintain quality, consistency between projects and team members.

By default, IDEs have integrated default static analysis, which you can extend and adjust to your needs. Dart has its own lint rules nicely described in their documentation — Effective Dart. If you enjoy that style (which I do) the dev team from Google created a package with that rule set (pedantic | Dart Package)

Worth mention

Checking manually every package version may be a little bit annoying. For Android Studio users you can check out this plugin Flutter Pub Version Checker — for IntelliJ IDEA, Android Studio which does it for you. Highlighting packages with new versions available is convenient.

To be continued…

That’s a quick summary about libraries and approaches we use internally in our company. If you’re looking for some start points it should also help in your project, but as Flutter has been evolving, we had many viable solutions to common problems and that’s only one of them. In the next article I’ll show architecture diagrams, explain specific layers, and implement a list screen (fetching from remote, local persistent).