All right, guys.
So the last time we're here, we're setting up our car, this new model, and we got to understand that
it had to interact with our car service.
And the only way we could do that or the best way to do that would be through dependency injection.
So we're going to spend some time understanding what exactly dependency injection is.
And even if you already know what it is, we're going to look at how we actually facilitate it instead
of on my MIUI up.
So dependency injection is essentially a technique for accomplishing a design pattern called inversion
of control.
So essentially they always say new is glue, meaning that the only way this glass can exist is if this
one exists.
So and that is because we created a new instance of this inside of this stress.
So when an object of this exists, then that's the only time an object of this kind exists.
So they are literally glued to each other over a dependency injection, or the pattern of inversion
of control makes it easier to share classes with each other without direct dependencies, meaning that
our car service exists on its own and it's only going to be called upon whenever car least needs it.
The lifecycle of it will be tethered to how we decide to handle its instances, meaning are we're going
to use one instance of it, throw it into applications any time somebody requests it, and this is pretty
much the syntax for requesting it.
We put it in the constructor of the class that is requesting it, and then we initialize a local copy
of it and then we use that local copy throughout our our class operations.
So whenever the life of this class has ended, then the copy would also end.
That's essentially what dependency injection is.
So.
To build on this.
We have the car list view model and then our main page here.
We're going to be retrofitting it to have a dependency on said view model.
So what we need to do then is let our main page know that it needs a copy of our view model to do that
in its constructor.
I'm going to create an instance of CAR.
This view model can just keep the name and then using Visual Studios control that I will create and
assign a field.
So what I use the shortcuts are not.
The principal is the same.
We need a private property.
Sorry, our private field of the type that we are injecting.
It's going to be set to read only because read only means that it can only be given a value instead
of the constructor of the class that it is being declared in.
And then we're going to tell the constructor, get the copy from the Depend, the inversion of control
controller.
Right, which is built into most, most if not all core applications.
And then we initialize a local copy here.
Now that we have local copy, we can do anything that we need to do with that view model.
Right?
Except in this situation, I don't necessarily need a local copy.
Instead, I'm going to see a binding context and we're going to look a bit more at binding context in
a few, but that is what I need for the main, so I really don't need that local copy.
But typically speaking and as we go along, you will see other instances of us using dependency injection
for other services that we may need in that particular moment, but not necessarily forever.
All right.
So I am just going to remove all of this boilerplate code.
And what we just did was get a copy of our car list view model, and then we set the binding context.
So once main page is loaded, he gets the copy and then it sets its binding context.
So what I've said the words are the word binding quite a few times before and all, and we will get
to the details of that in a few.
However, in our program DOT Since there are some configurations that we need to add, then if you're
familiar with core applications, especially since 1986, then this shouldn't look too far into right?
We're building up all of the services that we need and then we return the Build the builder version
of all the services.
So what I need to do now is add my new classes and my new services to the list of services that should
be available for dependency injection.
So I can say a builder dot services, let me get my spending rights builder dot services and then I
can add I can add transient, I can add singleton or I can add scoped.
Now scoped.
Each one is all about the lifetime.
So Singleton pretty much means that it's going to be one instance of this thing.
Throw the entire up scope to me is that is going to have the lifetime that one request is there.
It's going to do what it needs to do and then clause what's it's going to use that one instance for
all of all of the operations it needs during the lifetime of that request and in transit means that
you're going to get a new one every single time it is asked for.
So you always want to make sure that you're choosing the right one based on what you're trying to accomplish
in this situation.
I'm going to be using Singleton, so I went to add Singleton for car service.
I'm also going to add Singleton for the car list view model and I'm going to add it for the main page.
Now all of these need to be included so that dependency injection can work across all instances, and
that's pretty much it.
So as we go along, once again, based on the nature of the service that we're building or the operation
we're trying to carry out, we might end up changing this from Singleton to scoped, or we might add
new services or new view models accordingly.
So let us just do a quick build just to make sure that nothing has been broken and that last activity
indeed broke a few things.
And those are really the event handlers.
So if we go over to main page, we see that on contact clicked, was there on the button, but it no
longer exists in the backend code.
So that's fine.
We can live with that error.
So when we come back, we'll actually look to restructure this entire user interface and start using
our binding context.