0:27
Many of you are probably familiar with this architecture, or
some of you, it may be your first time hearing about it.
But basically, we want to divide the different tasks that our code
is responsible for into classes in these three categories, model,
view, or controller, instead of having just one class kind of do everything.
0:52
So without getting into too much detail about that,
when we're working with iOS applications,
we're often working with a UI view controller subclass,
which controls one screen's worth of our application in 99% of cases.
Okay, so those are these view controller classes that you see up here.
There are three of them in this application, MeViewController,
EditHobbiesViewController, and NeighborsViewController.
1:27
So those three view controllers correspondingly own the,
quote unquote, Me scene, the Edit Hobbies scene,
and the Neighbors scenes that I showed you in the demo.
1:44
These three scenes come from a storyboard, so a view controller owns a view.
And the views in this case are not being programmatically created
by a class, like a UIView subclass.
They're coming to us from a storyboard, and so
we'll put the storyboard together in the next lesson.
There are also two other classes that aren't custom
subclasses that we will write called HobbyViewCollectionCell and
HobbiesCollectionViewHeader, which helped to just support the way that
2:24
those sections of gray cells where you can pick the hobbies from
are presented nicely.
All right, so those are our views and our controller clauses.
There are also four model classes that we'll be using in this application.
There's a class called base model, which we'll provide to you, which handles some
2:49
of the status objects for
when our application communicates with the server that we're providing for you.
So that we can see if our call was successful or
not, we can look at status.status code or
status.status description and
see was our call successful or not, should we trust the data that we received?
Did the server handle spec and error?
Should we show that on screen?
Those types of things.
So we'll give you this base model class, and then together, we'll implement
3:25
the list of users and hobby clauses.
And there's one more type of
class that we'll be using, which is called a data provider class.
So there are two of those classes that we'll write called UserDP,
User Data Provider, and HobbyDP.
3:47
Those are all the class that you'll need in this application.
So it's a fairly small application.
And I mentioned that it is a client-server application,
we'll be saving our user account and saving our hobbies and
also fetching hobbies to and from the cloud, our server and the cloud.
So I wanted to introduce the architecture to you quickly too.
So we'll be using a restful web service that we be providing for you.
4:22
That's hosted at Amazon Web Services.
And we use ASP.NET with the NVC 4 Framework
to provide that web service to you for those of you who are curious about that.
And behind that, we have our SQL database, so
that's where all of our users and hobbies will be stored.
4:44
All right, let's take a look at how all of these classes work together and
then how we can communicate with the server, so
that we understand what's going on when we look at the code in the next videos.
5:11
So for example, we'll take a look at the Me scene to go through this map here.
So in the Me scene, you saw that I entered a username.
I hit the Submit button.
And then I had a user to work with, and I was able to go and do other things like
save my hobbies or fetch other users that show under my hobbies.
So in the Me scene, when I tap that Submit
5:54
And then it will make a request to my data provider.
So my data provider is going to be the class that's responsible for
talking to the server.
What will happen is I will pass in my user that I've created in
the MeViewController that contains my username and my latitude and
longitude, if I have it, to my data provider.
My data provider will then go talk to my UserModel class, which I've created
an instance of in MeViewController, but I'm handing it to my user data provider.
User data provider will talk to the model,
the user model class, and serialize my user's properties,
in this case, just username and long, into JSON.
And then it can go and work with a connection class that we'll
be providing you, which actually can talk to the Internet.
And we'll provide you with the connection string for
the server so that you can make the call.
So once our data provider has serialized our user into JSON,
it can then send it to the server,
and the server will hopefully successfully create that user for us.
And come back and send us some more JSON back that says okay, we created your user.
Or if something went wrong, it should send us an error back that says okay,
we were not able to create a user.
Once my data provider has received that message back from the server,
it can pass along that response back to my MeViewController,
7:48
If we were successful, then we could show a message like, okay,
your user was created successfully.
To cut down on the amount of work that you'll have to do, we didn't do that.
But we do want to show an error if something went wrong.
8:04
That helps you to know what's going on as you're working on the applications,
so your alert is something that happens in the UI.
So your view controller will want to update the UI state and present an alert
that says oops, something went wrong, whatever the server had told us.
All right, and then the view controller would go in, actually update our view.
So we see that we get all the way from user tapping the views, or
touching something on the views, some kind of event happens.
Our view controller processes that event.
We're going to create an instance of some model class, so user or
a hobby or something, pass that over to a data provider.
Data provider will go talk again to the model class, serialize it into JSON,
pass the JSON to the server, server passes us JSON back.
We go ahead and deserialize that again and then pass
the response back to our view controller, which updates our view once again.
So we've gotten all the way back and forth.
[MUSIC]
Justin-Nicholas ToyamaUCI Extension Instructor
Frank AyarsUCI Extension Instructor
Ralf BrockhausUCI Extension Instructor
