Advanced Flutter Project - Best Practices - Generic BLoC Providers - Part Three

Repository

https://github.com/flutter/flutter

What Will I Learn?

  • You will learn about BloC Pattern's History
  • You will learn about Generics in Dart
  • You will learn the Best way to implement a BLoC Provider
  • You will learn about the Time Complexity of searching for an Inherited Widget in the Widget tree
  • You will learn about potential Memory leaks that can happen as a result of not closing Streams in Dart
  • You will learn how to deal with performance errors in a BLoC component

Requirements

System Requirements:
OS Support for Flutter:
  • Windows 7 SP1 or later (64-bit)
  • macOS (64-bit)
  • Linux (64-bit)

Required Knowledge

  • A basic knowledge Programming
  • A fair understanding of Mobile development and Imperative or Object Oriented Programming
  • Basic knowledge of the BLoC

Resources for Flutter and this Project:

Sources:

Flutter Logo (Google): https://flutter.io/

Difficulty

  • Advanced

Description

In this Flutter Video Tutorial, we look at the history of the BLoC Pattern and we talk about how to properly implement a generic BLoC provider to harness the time complexity of an Inherited Widget and the Disposal method of a Stateful Widget. The tutorial also covers Dart Generic types and Parameterized Types, along with a few other performance enhancing concepts. This implementation of the BLoC provider follows an agreed upon best practice for the BLoC Pattern that just recently has started to see more heavy use and it is the final evolution of the Provider in this Pattern.

The History of the BLoC pattern and the Inherited vs Stateful Widget dilemma

The BLoC pattern was originally thought up by a group of developers at Google who were working on Angular projects using the Dart programming language. These developers wanted to port their Angular applications into the newly released Flutter Framework. They used the BLoC pattern to create a common Business Logic Component which they shared between the two applications. The original implementations of this BLoC pattern used the Inherited Widget as the BLoC Provider. This was mainly done because searching the Flutter Widget Tree for an Inherited Widget has a constant time complexity cost. In other words, all widgets on the widget tree will take the same amount of time to find the inherited widget.


inherited-provider.png

The architecture looked something like the flowchart above. Generally, the BLoC provider was embedded in the root widget of the application to allow all of the widgets to have access to the BLoC. As Flutter was refocused into a framework that can potentially build applications for not just mobile targets but also desktop and web targets, the size of applications increased. A problem in this architecture was discovered as a result. The BLoC component uses Streams and Sinks, but an Inherited Widget doesn't have a life cycle hook that will allow the user to release the resources used by the BLoC. This can lead to memory problems and in particular, it can cause memory leaks. The proposed solution was to use a Stateful Widget instead of the Inherited Widget.


state-bloc.png

The above picture shows what this new architecture looked like. The Stateful Provider is placed in the root of the app and the State Object associated with the Stateful Widget is used to dispose of the Streams and Sinks in the BLoC. This architecture also has its own set of problems however. Developers can now dispose of resources and avoid memory leaks but the search Time Complexity to find the Provider is increased from Constant Time to Linear Time. The time to find the BLoC provider is now dependent upon where the widget is in the widget tree, with further away widgets taking more time to access the BLoC.

Building a Generic Provider with Inherited and Stateful Widgets

The Solution to the "Inherited Provider vs Stateful Provider" debate was to make use of both widget types to define the component. While this increased the size of the Provider significantly when compared to the old architectures, it removes both the Time Complexity problem and the Memory Leak problems. Also, because Dart features Generic Types, it is possible to build a Polymorphic and Generic Provider which can serve any number of different BLoC types.


inher-stateful-prov.png

In the new architecture, the BLoC is directly embedded into an inherited widget which is wrapped in a Stateful widget. Like with the original architectures, the Provider is usually positioned at the root of the widget tree. The child widgets that need to access the BLoC use the search function of the Inherited widget which keeps the time complexity down at constant time and the BLoC has access to the outer Stateful Widget to dispose of its resources.

The Source Code for this video may be found here: https://github.com/tensor-programming/utopian-rocks-demo/tree/tensor-programming-patch-1

Video Tutorial

Curriculum

Related Videos

Projects and Series

Stand Alone Projects:
Building a Calculator
Movie Searcher Application

Minesweeper Game

Weather Application

Redux Todo App

Curriculum

Proof of Work Done

https://github.com/tensor-programming

H2
H3
H4
3 columns
2 columns
1 column
12 Comments