Effective State management using Riverpod Gaurav Bhatnagar Satish Kumar Maersk Mobile Team https://bit.ly/bhat_g https://bit.ly/satish_k @bhatnagar_g 

Why “State Management” ? • Managing state is something most developers come to deal with when working on flutter applications • When do you know that you need state management? • It is not necessary that every widget needs its own state management some can be just manage with stateful widgets and setState. 

No content

What is a Provider ? 

Let’s say for instance we have a Tugboats class that handles numberofTugboats and another class Vessel which dependson the Tugboats class. 

If we were to have both as providers, then combining them will look like this. 

Runtime Exception https://bit.ly/3waAXPM 

It is difficult to have more than one provider of the same type, the one closest to the widget intended will always be accessed and hence causing unintended access. https://bit.ly/3waAXPM 

Riverpod • Riverpodis dart solution built from scratch to overcome the complexity of Provider • A Provider(Riverpod) is an object that encapsulates a piece of state and allows listening to that state • Wrapping a piece of state in a provider – • Easily accessing that state in multiple locations. • Enables performance optimizations. • Increases the testability of your application. • Allows easy integration with advanced features, such as logging or pull-to- refresh. 

State management in Action - ChangeNotifier • Theming(Dark/Light) the Mobile application • Global provider to hold the state • .watch, .read, .autoDispose 

Future and Stream Provider • FutureProvider is typically used – • performing and caching asynchronous operations (such as network requests) • nicely handling error/loading states of asynchronous operations • removes redundancies of FutureBuilder • StreamProvider is like FutureProvider but for Stream instead of Future. • StreamProvider is usually used – • it allows other providers to listen to the stream using ref.watch. • it caches the latest value emitted by the stream, ensuring that if a listener is added after an event is emitted, the listener will still have immediate access to the most up-to-date event. Creating the configuration would be done with your typical async/await syntax, but inside the provider. Using Flutter's asset system, this would be: 

Combining Providers is simpler 

Modifier : Family If you want to add external information to construct your provider (that is not necessarily another provider) 

State management in Action – StateProvider • State provider change the state using StateNotifier • Global provider to have state of list items added to cart • Watch the provider state in the app(wherever it needed) • Call to action to change the state 

Testability • Since providers are usually declared as global variables, you might worry about that one. After all, global state makes testing very difficult, because it can require lengthy setUp/tearDown. • But the reality is: While providers are declared as global, the state of a provider is not global. 

Conclusion • RIVERPODhelps manage state of application in a safe way with flexibility of having global scope, similar type of providers and reference-based access. • It is dart-based solution(independent of flutter) where state can be easily autoDisposed when it is no longer used. • Improves Readability, Scalability , Testability and simplifies complex object graphs • If you have an existing app using provider, it is relatively easier to migrate. 

References : • https://bit.ly/3ycyxmy - Flutter State Management with Riverpod: The Essential Guide • https://bit.ly/riverpod_repo - Repo showcasing different scenarios • https://bit.ly/3waAXPM - Riverpod: A deep dive "on the surface" by Kefeh Collins • https://bit.ly/38WkOW9 - The State of Flutter by tomerpacific • https://bit.ly/3LPxsFj - Fun with Flutter Video Blog Series • https://riverpod.dev/ - Remi Rousselet • https://github.com/rrousselGit/riverpod 

No content