& The MVVM Design Using Provider Kendi J 

What is State Management? This probably the most commonly asked question in Flutter and most people wonder which is the best practice to use while managing state. - In Flutter however I would say that state management is a combination of the architecture and low-key DI where data changes over the lifecycle of an app making the UI to react by giving the expected output. 

Types of State Management - Local State (setState) - a state that is used to hold on data after rendering a widget. - Global State - - Inherited Widget - Redux - Scoped Model - Flutter BloC - Provider 

Provider “This is the recommended way to manage state for apps of all sizes.” - Chris Sells, Product Manager, Flutter. - Provider is a mixture between Dependency Injection and State Management built with widgets for widgets. - It’s like a way of using Inherited Widget * - This may sound daunting when you first dig into it because of many classes you could use like changeNotifier, consumers, streamProviders, valueNotifiers etct; 

No content

- In order for us to understand how Provider works in simple terms, let's break it down into three simplified tasks that needs to be done: Let’s have an emergency scenario where you’ve been invaded by robbers.What would you do? ★ Sound the alarm - This Notifies your neighbours/police that things have changed from the norm. ★ Escape - Find an alternative door to exit to safety hence Providing Access ★ Seek help - The Consumers of your alarm have come to see what’s going on so they can be the Providers of security. 

No content

Notifiers - These are classes that notify the providers that something has changed. - Examples: - changeNotifier - A class that can be extended or mixed such that it provides a change notification API using VoidCallback for notifications - valueNotifier - This is a changeNofier that holds a single value. When this value is changed with something that’s not the old value as evaluated by the equality operator, this class therefore notifies its listeners. 

Listener MyApp Material App Widget Widget Widget Widget Producer Listener Consider this app structure 

Lifting State Up (setState) ● They emmite some event and change some internal app state ● First common ancestor ● Need to rebuild themselves the the state changes This method is not efficient because: ➔ It has too many boilerplate code ➔ Too many unnecessary rebuilds Producer Widget Listeners 

Listener MyApp Material App Widget Widget Widget Widget Producer Listener Provider 

Consumer - This is a widget inside the provider package that is used to register itself as a listener. - Provider.of syntax is used: - When you want to access a value that is available by the provider - Retrieve the value/object that you ask for - To register current widget as a listener, where the widget identifies as (context). 

Design Patterns ❖ The best patterns to solve some problems ❖ Consist of relationships between classes and objects ❖ They speed up your development ❖ They are indipendent programs ❖ They are flexible, reusable and mainatinable 

MVVM Design Patterns ❖ M - Model => (customer information) ❖ V - View => (the UI) ❖ VM - ViewModel => (state, links the View with the Model) 

The MVVM design hierarchy ViewModel View Model Event Bind Update Notify 

❖ Model - This contains the logic part of the app - It contins information such as the customer info that is saved in the cloud or DB ❖ ViewModel - This ensures that the View and the Model do not communicate directly so as to avoid messy code which nearly imposible to maaintain ❖ View - This is the app UI that users interract with 

Why we need MVVM Design Structure? - Ideally the model and view can communicate directly. However this is not a good practice. - But why? Model View 

User name: New password: Confirm password: View Password reset screen Customer Model User name: Password: Confirm password: 

User name: New password: Confirm password: User name: New password: Confirm password: User name: New password: Confirm password: Code to validate values from the view. View ViewModel Model 

❖ ViewModel - gets data from the ViewPassword reset screen and supplies this data to the Model - Data is already validated by the time it reaches the model ❖ Model - Mapping the view directly to the model will bring issues. - Your model should not have confirm password field because this is not the information that you will write on the DB/Cloud. 

No content

No content