Question 1

How does Provider work?

Accepted Answer

Separate the three layers: (1) a ChangeNotifier holds the state and calls notifyListeners() when it changes; (2) a ChangeNotifierProvider puts that object in the tree and owns its lifetime — dispose is called for you when the widget leaves; (3) reading — context.watch subscribes, context.read does not. Then close the loop: Provider is built on InheritedWidget, so there is no magic — watch is ultimately a dependOnInheritedWidgetOfExactType call. That last sentence is what lifts the answer to middle level.

Question 2

With Provider, the UI is not updating — what are the likely causes?

Accepted Answer

I check in order: (1) was notifyListeners() actually called — by far the most common cause; (2) is build using read instead of watch — read does not subscribe; (3) was the list or object mutated in place — mutating the same reference and calling notifyListeners() works for Provider, but comparisons in a Selector or an == check may miss it; (4) is the provider in the right place in the tree, with the widget below it. Finish with diagnosis: if I am using a Selector, I verify the selected value genuinely changes.

Question 3

When do you choose Consumer over Selector?

Accepted Answer

A Consumer rebuilds its builder every time the model notifies; a Selector only when the value you select changes. The choice depends on the cost of that rebuild: if the builder is cheap — a single line of text — Consumer wins on simplicity; if it is expensive (a list, a chart) or the model changes frequently (a field ticking every second), Selector earns its keep. One nuance: the selected value is compared with ==, so if you return an object its equality must be defined properly, otherwise the optimisation silently does nothing.

Question 4

What are Provider's weaknesses?

Accepted Answer

Answer honestly — you are not expected to defend the package. (1) Runtime errors: if the provider is missing from the tree you find out at runtime, not compile time (ProviderNotFoundException). (2) Lookup by type: two providers of the same type are awkward to tell apart. (3) Context dependence: reading state outside the widget tree — from a service layer — is inconvenient. (4) ChangeNotifier is mutable, so mutating it accidentally from the UI is easy. Riverpod exists largely to solve those four, and knowing that helps you in the comparison question.

Way to read	Subscribes?	When to use
`context.watch<T>()`	Yes	Inside `build`, when displaying the value
`context.read<T>()`	No	Inside a callback calling a method (`onPressed`)
`Consumer<T>`	Yes, but only its own builder	When you want to narrow the rebuild area
`Selector<T, R>`	Yes, only to the selected slice	When you depend on one field of a large object

Provider and ChangeNotifier

📚 Sources and documentation