Making the app state visible across multiple screens

One phrase that is thrown around a lot in the Flutter community is "Lift State Up." This mantra, which originally came from React, refers to the idea that State objects should be placed higher than the widgets that need it in the widget tree. Our InheritedWidget, which we created in the previous recipe, works perfectly for a single screen, but it is not ideal when you add a second. The higher in the tree your state object is stored, the easier it is for your children widgets to access it.

In this recipe, you are going to add another screen to the Master Plan app so that you can create multiple plans. Accomplishing this will require our State provider to be lifted higher in the tree, closer to its root.

Getting ready

1. You should have completed the previous recipes in this chapter before following along with this one.

How to do it...

Let's add a second screen to the app and lift the State higher in the tree:

1. Update...

Designing an n-tier architecture, part 1 – controllers

There are many architectural patterns that have become popular in the last couple of years – Model View Controller (MVC), Model View ViewModel (MVVM), Model View Presenter (MVP), Coordinator, and several others. These patterns have become so numerous that they are sometimes pejoratively referred to as MV* patterns. This essentially means that no matter which pattern you choose, you need some kind of intermediary object between your model and your view.

A concept that is shared by all the popular patterns is the idea of tiers/layers (we will be using the terms tier and layer interchangeably throughout this chapter). Each tier in your app is a section of the MV* classes that have a single responsibility. The term n-tier (sometimes called a multi-tier architecture) just means that you are not limited on the number of tiers in your app. You can have as many or as few as you need.

The top-most tier is one that you are already...

Designing an n-tier architecture, part 2 – repositories

The next stage of the n-tier architecture we are going to discuss in this recipe is the bottom-most layer: the repositories, or the data layer. The purpose of a repository is to store and retrieve data. This layer can be implemented as a database, web service, or in the case of the Master Plan project, a simple in-memory cache. Unlike the controller layer, which is business logic-aware, the repository layer is only concerned with getting and storing data in its most abstract form. These classes should not even know about the model files that we created earlier.

The reason why repositories are so purposefully ignorant is to keep them focused entirely on their task – persistence. Communicating with a database or a web service can become complicated if you have many small requirements. These concerns are typically beneath business logic and are easier to resolve when you're only focused on abstract objects. Remember...

Designing an n-tier architecture, part 3 – services

The final tier that we will be talking about in this exploration of the n-tier architecture is the services tier. This tier serves as the glue between the controllers and repositories. Its primary job is to transform the data from the generic format used by the storage solution into the actual schema that is used by the controllers and the user interface.

In this recipe, we will be creating serialization and deserialization functions for our models, as well as stitching it all together with a services class.

How to do it...

This recipe will be divided into two components – serialization and integration. We're going to start with the serialization functions and then snap together all the pieces that we built over the last three recipes:

1. Open task.dart and add an id property and a default constructor. This will allow the Task model to be transformed into a generic Model:

import 'package:flutter/foundation.dart...

Making the app state visible across multiple screens

One phrase that is thrown around a lot in the Flutter community is “Lift State Up.” This mantra refers to the idea that State objects should be placed higher than the widgets that need it in the widget tree. Our InheritedWidget, which we created in the previous recipe, now works perfectly for a single screen, but what happens when you add a second?

In this recipe, you are going to add another screen to the Master Plan app so that you can create multiple plans. Accomplishing this will require our State provider to be lifted higher in the tree, closer to its root.

Getting ready

You should have completed the previous recipes in this chapter before following along with this one.

How to do it...

Let’s add a second screen to the app and lift the State higher in the tree:

1. Update the PlanProvider class so that it can handle multiple plans. Change the type of ValueNotifier every time...

Summary

In this chapter, you’ve seen some of the basic concepts of state management in Flutter, while building an app called Master Plan. This app allows users to create plans and add tasks to each plan, and shows how to manage the app state across multiple screens.

In particular, we’ve covered the following topics:

• Model-view separation: you’ve seen the importance of separating the application’s data model from the view layer.
• By keeping the model and view separate, it’s easier to maintain and scale the app as it grows in size and complexity.
• In the MasterPlanApp, you used the Plan and Task classes as data models, and the widgets in the app acted as the view layer.
• In the recipe Managing the data layer with InheritedWidget and InheritedNotifier, you added the PlanProvider class, which extends InheritedNotifier.
• You used it to manage the app’s data layer. Using an InheritedWidget, you could access...