200 Architecting a Flutter App

Page Table of Contents

• Introduction
• Types of state
• What options are there?
  • Lifting State up
  • Provide/Scoped Model
  • Redux
  • Bloc
• BLoC in depth
• BLoC in Wisgen

Introduction

The Most central topic of architecting a Flutter (Flutter Dev Team 2018g) app is Statemanagement (Flutter Dev Team 2019b). Where does my State sit, who need access to it and how do parts of the app access it? This chapter aims to answer those questions. You will learn about the two types of state, you will be introduced to the most 4 most popular Statemanagement solutions and you will learn one of those Statemanagement solutions (BLoC (Soares 2018)) in detail.

Types of State

The Flutter documentaion (Flutter Dev Team 2019b) differentiates between two types of State: Ephemeral State & App State. Ephemeral State is State that is only required in one location IE inside of one Widget. Examples would be: scroll position in a list, highlighting of selected elements or the color change of a pressed button. This is the type of state that we don’t need to worry about that much or in other word, there is no need for a fancy Statemanagement solution for Ephemeral State. We can simply use a Stateful Widget with some variables and manage Ephemeral State that way (Flutter Dev Team 2019b). The more interesting type of State is App State. This is information that is required in multiple locations / by multiple Widgets. Examples would be: User data, a list of favorites or a shopping car. App State management is going to be the focus of this chapter.

Figure XXX: Ephemeral State vs App State Dession Tree (Flutter Dev Team 2019b)

What options are there?

• Flutter does not impose an approach
• Showcase the most popular ones
• Explain why I choose to go with BLoC
• Options

Lifting State up

• Putting App state up in the Widget Tree
• Pasing it down through constructors
• Or Using inhereted widgets
• Use for tiny apps

Provide/Scoped Model

• One Approach advicate by Google
• Uising a package to hide Inherted widgets behind a nice interface
• Access through context
• used by google internally
• Simple but not really an architecture

Redux

• Port from React
• Good approach if you are already familiar
• Uses a store for BL
• Not that easy to understand

Bloc

• Goal:
  • Extract the Logic into a class that can be calls from 2 different independent interfaces (AngularDart and Flutter)
• Streams
• build by google engniers
• used by google internally
• Google went bach and forth on this as well.
• Why BLoC …
  • Produces nice layered architecture
    • Makes sense for big applications
  • Specifically build for this
  • Used by the people who build the framework
  • -> Not better or worse then Redux, but thats why I choose BLoC

BLoC in depth

• UI only publishes and subscribes
• NO BL in the UI
• Keep it stupid so you don’t need to test it
• All BL should be in BLoC
  • Buisnees Logic Objecs

Figure XXX: Bloc Architecture (Sullivan and Hracek 2018b)

• 4 Rules for BLoCs
  • Only Sinks In & Streams out
  • Dependencies Injectable
  • No Platform Branching
  • Implementation can be whatever you want
• 4 Rules for UI Classes
  • “Complex Enough” views have a BLoC
  • Components do not format the inputs they send to the BLoC
  • Output are formated as little as possible
  • If you do have Platform Branching, It should be dependent on a single BLoC bool output

Figure XXX: Bloc Sink and Stream (Boelens 2018a)

• Build Interface code how you want it to look like -> then make it work

• Pros

  • Change BL more easily
  • Change UI without impacting BL
  • Easily Test BL

• Layered Architecture out of BLoCs

  • Like Uncle Bob says
  • Nice indented Layers
  • use Boundary classes IE interfaces to keep data layer seperat from Buisness Layer

Figure XXX: Bloc Architecture with Layers (Suri 2019)

BLoC in Wisgen

Figure XXX: Wisgen Bloc Architecture (Faust 2019)

Figure XXX: Wisgen Bloc Architecture Dataflow (Faust 2019)

Next Chapter: Testing >

Back to Top