Flutter Dependency Inversion For Beginners | Complete Guide

In this Flutter Dependency Injection Tutorial we go through three ways of setting up dependency injection in your code.

[nosmirck]

Great video, however, I believe you need to read a bit more about the concepts, I known they can be confusing, but you got quite a few things wrong.

First of all, the design principle (from the SOLID principles) we want to satisfy is Dependency Inversion, which basically states two things: 1) high level modules should not depend on low level modules, both should depend on abstractions (or interfaces)
2) abstractions should not depend on details or concrete implementations, they should depend upon abstractions.

Now, this means we should provide our dependencies as abstract classes or interfaces that contain nothing more than what defines the class (no details on the implementation).

So, to solve this problem, we rely on one Inversion of Control (IoC) technique.

IoC basically means that, dependant classes should not have the responsibility of creating concrete instances for their dependencies, instead, the flow of control is inverted and delegates the responsibility to something else to provide the class with the concrete implementations of their dependencies, of course, only knowing about the abstractions, not the actual concrete implementation.

Now, Dependency Injection Is an IoC technique, and strictly means injecting the dependencies through constructor (also accepted using with setters, but it's more common with the constructor because is verbose and explicit). This can be implemented manually (like you showed) or through a framework (like Autofac, Ninject, Unity for C#) that will resolve de dependencies in runtime, they depend heavily on reflection in order to instantiate dependant classes without you explicitly passing the dependencies through the constructor, a thing that is not possible with flutter since Dart's mirrors are disabled, however, there are other solutions, using code generation. DI packages for flutter like inject and kiwi rely on this. I personally don't like code generation since I like to have full control on every line of my code, but it's ok to use on some cases, which leads me to what I actually use: Service Locator.

A Service Locator (like get_it) is another technique that helps inverting the control, the dependant classes still have the responsibility of asking for the dependencies, but no need to actually instantiate anything, the locator will take care of that (it has the control, hence, inversion achieved), one disadvantage is that the dependencies are less verbose and strict (you can't know what a certain class needs unless you look at the code, while with DI, just by looking at the constructor, you know exactly what it depends on).

Now, using an InheritedWidget is not a way of achieving Dependency Inversion much less a way to Inject Dependencies.

An Inherited Widget is nothing more than a node in the tree that usually sits on top of all other nodes that might depend on something and it provides the first appearance of said dependency (kind of like a locator, but not really) through a static method, which means this call is cheap, no need to traverse the tree up to look for something, let alone traverse back down to notify dependants, so, the static "of" method (that actually you can call whatever you want, nothing explicitly says it needs to be called "of", it's just a formality, you only need to implement is updateShouldNotify, I could explain deeper, but I'm lazy and this comment is getting too long) will simply call inheritFromWidgetOfExactType that, if you see the implementation, basically returns the first InheritedWidget instance from the bottom up where it was called of the type requested from the BuildContext (current state of the widget tree).

In conclusion, what you try to explain is good, having a good architecture is key, but you messed and mixed concepts, probably because you never had to implement a DI framework or a Service Locator from scratch, which gives a lot of knowledge on how the Inversion of Control works for Dependency Inversion Principle to be achieved.

Hope that helps! And please don't take my comment personally, I just want to make things clear for you and everyone else.

Have a great day and keep making awesome videos!

[officialismailshah]

BEST GUIDE TO DEPENCY INJECTION FOR BEGINNER REALLY HELPED ME A LOT, I AM NEW TO DEPENDENCY INJECTION KIND

[arnaudduquenoy]

Thank you very much ! your tuto is golden :) It missed by exemple in Resocoder tutos WHY using INJECTABLE and you fully explained it!

[alliu]

Thank you for your video, could you publish a video about how to do the test with Provider?

[ketanchoyal]

What if we use get_it and provider library at the same time? then can we inject into object without context?

[rikyriky]

I also use Provider. It is rock solid. No problems at all.

One question: I often need method functions inside of stateful or stateless widgets.

For example:

buildProfileInfoSection()

However, since we cannot use Provider without “context”, it is a pain. So for every method, I have to provide the related provider variable as an argument.

For example:


Or provide the context of the widget as an argument.


StyleProvider styleProvider =


.
.
.
}


Do you know a better approach? Thanks.

[WorstDeveloper]

I'm a beginner and have some questions.
1. How do you update values and listen to values in order to rerender widgets with get_it?
2. Can you explain more about disposal? What is it and how do you do it?

[oliverbytes]

What's the difference by using a Static Class for Services? Or Pros and Cons? Opinions, please. thanks a lot

[nazxuul]

Hi, I am very much a neophyte here and I don't understand the point of get_it. I can easily create a singleton in Dart and import it wherever I need - so why do I need get_it at all? Of course, I have the disposal problem but it seems get_it doesn't solve this.

[SEOTADEO]

good video, I found myself in a place where every service had it's own singleton which produced a lot of boilerplate and made it hard to reset the services at runtime. I'll ise get_it from now on.

[pradeep]

dont u think testing suks when we use singletons, may be im wrong can u provide a widget testing example includes provider with singletons....

[peekpt]

Very nice, I use get _it, but now I will start using provider. BTW the dev is already experimenting lazy loaded providers.

[rubinbajracharya]

Hi there, Can you tell me how we can inject SharedPreferences Instance using get_it and use it as well.

[faizulla]

Dependency Inversion and Dependency Invgection is ather way .... wron topic

[subramaniams]

great video. kindly remove the background music pls. thanks

[faheemahmad]

did not understand at all! need a simple app

[sayedragab]

This is a service locator and not dependency injection

[PaWLO]

Hey a have a problem with get_it. How to register a class which has constructor with parameter? For example I need to create instance of class Foo which has constructor Foo(SomeDependency object). I've tried something like this but won't work: object) => Foo(object));

[nishantdesai]

how to use routing when following provider pattern ?
is there anything we can do about it ? I have a basic todo app with authentication, it has 2 screens
1. screen which lists todos
2. settings screen from where you can logout

now both of these screens will require User instance provider but If I use routing then I cannot share same instance of User provider on both screens right ?
or is there a way to do that other than wrapping your app in provider ? because I might have other 2 providers that I need on both screen and wrapping my app inside all those 3 nested providers does not makes sense because it's just a hack not a solution

[bert.m]

Can you please make a course for flutter, dart, firebase and more ❤️