Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The MVVM Design Using Provider

The MVVM Design Using Provider

This session was on how you can handle state using the MVVM architecture using provider.

Kendi J

July 25, 2020
Tweet

More Decks by Kendi J

Other Decks in Programming

Transcript

  1. 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.
  2. 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
  3. 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;
  4. - 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.
  5. 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.
  6. 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
  7. Consumer - This is a widget inside the provider package

    that is used to register itself as a listener. - Provider.of<T> 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).
  8. 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
  9. MVVM Design Patterns ❖ M - Model => (customer information)

    ❖ V - View => (the UI) ❖ VM - ViewModel => (state, links the View with the Model)
  10. ❖ 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
  11. 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
  12. User name: New password: Confirm password: View Password reset screen

    Customer Model User name: Password: Confirm password:
  13. 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
  14. ❖ 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.