20

From what I understand about the flutter package, Provider, is that it's a way to share objects between widgets. I know another way of doing this is to create a class, say AppGlobal, and define various static variables that the whole app could use. It's suggested that Provider is a better way of doing that, but I don't understand why that is.

JVE999
  • 3,327
  • 10
  • 54
  • 89
  • AppGlobal negates all the benefits of dependency injection. Study dependency injection. – Ted Henry Feb 08 '20 at 21:54
  • @TedHenry dependency injection doesn't mean what you think it means. And there are serious drawbacks using a service locator, in this instance losing static analysis – Ced Nov 28 '22 at 01:00

2 Answers2

17

An answer to the question should take different aspects into account:

  1. Testability - not much of a difference. Both cases require code change to replace either the singleton itself or the "provided singleton"
  2. Code Coupling - not much of a difference either (see comment on testability)
  3. Scoping - Singletons most often live through the lifecycle of the whole application. It would be error prone to manage a singleton for some widget subtree. Here provider definitely has its strengths by taking care of creation and disposal.
  4. UI updating - when using singletons this must be completely hand coded with setState which will produce lots of error prone boilerplate code. Provider provides this already under the hood.
  5. Listeners - changing state in one part of the application should notify all consumers of that state. With singletons this has to be built by hand. Provider provides this already under the hood.
  6. Lazy Loading - By default, values are lazy-loaded, which means they are called the first time the value is read instead of the first time the provider is created. This can be disabled by lazy: false

Hope this answers the question in more depth.

Jemolah
  • 1,962
  • 3
  • 24
  • 41
4

A quick search through the web and it seems like a global instance of a variable is not the best idea since it is not testable, and it makes the code very coupled with the AppGlobal class.

Here is a link that describes what I am talking about and it does a great job with examples.

Global Access vs Scoped Access with Provider

Rutvik Sanghavi
  • 49
  • 2
  • 2
    Why is a global singleton not testable? I can replace it with some mock. Don't I have to do the same with a class given to provider? What is difference in coupling? To replace the global class I need to change the code. Isn't the same required if I want to change the class given to provider? It seems to me that the advantage of 'Provider' is "scoped access" (including disposal when no longer required). This goes with the disadvantage of lower readability and it would be great to see a performance comparison of both approaches. – Jemolah May 06 '20 at 20:43
  • 1
    @HajoLemcke You are absolutely correct in terms of testability and Scoped Access. However I was mentioning it in terms of Static variable as a whole spread across multiple files/classes. This creates tightly coupled code for larger applications, and it makes it harder to create testing scenarios. I also am not disagreeing to what you are saying, since this almost always ends up in favour to how the specific developer writes code. Performance is usually ignored in a case like this since you will find little to no difference in either case, unless the code is written badly. – Rutvik Sanghavi May 12 '20 at 20:43