Hey, guys, welcome back.
In this lesson, we're going to be setting up our view model for our car listing page.
So we're going to call it car list view model.
So let's go ahead, hit our if you want this folder, go to create class.
And we're calling this one car list view model.
Let's add that.
And then of course, we make it public and our car list view model is going to be a draft class from
our base view model.
And then, of course, basic model.
We already saw that we had to make it partial because of the generated code.
So anything that's going to inherit from it is going to have to follow the same rules because everything
for this class will be generated when we start putting in our observable properties right now.
In terms of how we're getting the cars and remember that we have the car service, right?
So we have to do what we're called dependency injection, which we look at in our fuel.
But we have to do some dependency injection to get that car a copy of the car service into this view
model.
So I'm going to call this car service.
And the property name is going to be car service and are using reference.
And then I'm going to create and assign a field for our car service.
The next thing that I'm going to want is a property that represents an observable collection.
Now, observable collections pretty much would, when they're populated, they're notified that they
have been populated.
So unobservable collection is like a dynamic.
We are filling out list and data binding to something that would create a binding to see that once this
this has changed, I would update my UI to show whatever I am datable to show.
So we'll create a new one, a new property.
I will call this one observable collection.
And this is going to be a car and believe that I need some missing using references.
There we go.
So we have zero collection, we have our car.
And then I just call it cars nice and simply write this one I'm going to get and I'm going to see a
private set because I don't expect this to be set outside of this class.
That's all right.
So we have our observable collection and we have our car service inside our constructor.
Also, whenever this is initialized, I would probably want to set the title of the page that we're
on to be maybe something like car list.
All right.
So title here would be that public property coming from our base fuel model.
But remember that we didn't create it.
It was created because of the generated code for us.
So anytime you try to go to base your model, you're going to see that you have two representations
of it, one inheriting from observable object, which is ours, and then the other one which is the
generated one showing us our public property for a title.
Just the same way if I try to hit F12 on car list view model.
Oh, well, I would have to do that, Mr. Nut, so we can run that experiment later.
If I try to do that from another class, it will actually showed me these two options also, so we can
explore that later on.
Now, while we're here, what we would want to do is implement some commands.
Now we've seen whole verbose the whole notify properties changed was command can be as verbose as that.
But the great thing is that with the NVM toolkit, we have an annotation that we can use called a command.
So a command typically would be what do you want me to do?
Right.
I think that's kind of self-explanatory.
So what do you want me?
What tasks do you want me to carry out?
And then what happens is that in the view we can actually bind to the command.
So I'm just doing all of this buck in code.
Of course, some of these things will change as the app evolves.
What I'm putting in these building blocks that I when we go to the app, you'll see how everything can
get started, right?
So here I'm just going to create an async task and I'll call it get car list.
And some persons would say get cars in sync as they're coding or their naming method for asynchronous
methods.
I tend not to, but it's really neither here nor there.
It's up to you now.
The first thing I would want to do is if it is loading, if is loading, then we return.
So I don't want to do anything if we are loading.
Right.
Doesn't make sense.
Otherwise let us try and let us catch any exception.
And then let's add on finally.
So if you're familiar with exception handling, you have try try this operation catch any error.
But regardless of whether the trial was successful or we caught an error, finally you complete some
action, right?
That's typically what that means.
So what we want to try is one set is loading to true.
Because if is loading was false, then obviously we're able to get the car list.
So we're able to be loading.
Then where I want to check.
Are there any cars in the observable collection right now?
So I can see if.
Cars start any.
If there's anything to avoid and no exception here, what I'll do is set this to a new instance up here.
So is equal to a new instance of that.
Or if you want to use a short on C-sharp, you could just say a new open and close brace parentheses.
Right?
So let's just do that so I can avoid any knowledge steps on here when checking if there's any.
So if there is anything in there, then I want to clear it so it remove everything in there and we clear.
All right?
Otherwise, let us go and fetch a list of cars from our data source.
So at this point I would say car service, which we have injected an instance off that get cars.
No, that was not is synchronous was it.
It was not.
All right.
So don't have to await that.
And then I can see for each car in the list of cars.
I want to populate my observable collection.
So the downside here is that there's no range right in in regular lists and other collection types.
You will see a range that allows you to just see, get a list or a collection and then add the whole
collection in one operation.
Unfortunately, that doesn't exist.
So after use a for each loop for the earth, let me just do that in kind of one line.
You can decide, Oh, you want to write a code?
I mean, you know, whether you want to write it all with all the braces or you just want the one line,
I mean, that's fine.
Now, if we do catch an exception, what I would want to do is write a debugger line to the system.
So we'll say debugger, dot, right line, and I'll have to include a missing reference for that.
And here I just see a system like diagnostics, a debugger dot, right line, and then it will say unable
to get cars.
And we want to see the exception message, of course.
And if we hit an error, no, this is something that we haven't looked at it.
What I want to do is display an alert in the app itself that an arrow was hit.
So I would say, ah, wait, then we can call the shell, right?
And if you look at the IntelliSense coming up, a page that provides fundamental UI features that most
applications require, right?
So now it's nutshell that current dot and then we can say display alert.
And then from here I can see error.
That's the title.
And then we can give them either friendly message.
We could probably output this, but of course you never want to show the user what the exception message
is.
So we could just give them unless the message failed to retrieve list of cars and then we give them
the exit, which would be all key.
Right.
And that's how we would display an alert, no coding patterns.
Some persons would say, no, you don't call the shell directly from the view model.
I mean, that's up to you how complicated you want to get.
We could easily abstract.
That's a way to some other interface and we use that interface through dependency injection and do what
we need to do.
But that's fine.
We can leave it at this for now.
And then finally, whether it was good or not, whether it was successful or not, we want to know make
or is loading set to false?
All right.
So once again, when any time we're changing this value, what happens is that I remember this is on
the base.
So when I change is loading.
What's going to happen is that it's going to notify the UI that is loading has changed.
So if there's any binding that is watching for a change in the value of is loading that whole I notify
property change the work cycle will let the UI know and then that controls going on watching and waiting
on it will know how to behave according to how we set up the binding.
So that's it for setting up our view model for No.
When we come back, we're going to be looking at dependency injection and getting to understand what
exactly happened here and how we're going to get this view model associated with our main page.