Your Second Flutter App

Nov 30 2021 · Dart 2.13, Flutter 2.2.3, Visual Studio Code

Part 5: Meet Inherited Widgets

32. Learn Flutter State Management

Episode complete

Play next episode

About this episode
Leave a rating/review
See forum comments
Cinema mode Mark complete Download course materials
Previous episode: 31. Introduction Next episode: 33. Create an Inherited Widget

Get immediate access to this and 4,000+ other videos and books.

Take your career further with a Kodeco Personal Plan. With unlimited access to over 40+ books and 4,000+ professional videos in a single subscription, it's simply the best investment you can make in your development career.

Learn more Already a subscriber? Sign in.

Heads up... You've reached locked video content where the transcript will be shown as obfuscated text.

The problem we have in the RW Courses App at the moment is due to having state that needs to be shared between the courses page and the filter page. That state represents the current filter value, the user has selected on the filter page. You need that state to be communicated to the courses page, so it can filter the course list without requiring the user to restart the app. You need a mechanism to share the filter state between the different widgets and screens of the app. Within the flutter ecosystem, there are a number of tools available to manage the state of your app. These include StatefulWidgets, InheritedWidgets, the Provider package, ScopedModel, and the Redux pattern, and the BLoC pattern. In this course, you're going to look at the most basic approach to sharing state using an InheritedWidget. We have a more advanced course available on the provider package, and we'll add other courses covering the other state management approaches in the future. Using an InheritedWidget, lets you lift state up in the widget tree. You move state to the common ancestor of widgets that need to know that state. In the case of the RW Courses app, you need the filter state to be above the courses page widget in the filter page widget. You don't want to move the state any higher than that common ancestor, since it's possible that different parts of your widget tree will need to know completely different state. In the case of this sample app, you'll need to share state across both screens, so we'll move the state up above the material app object.