[MUSIC]

Okay, so here we are.

Let's take a look at the Architectures application.

So, the first thing that I want to point out is that we're using MVC Architecture,

so Model View Controller Architecture.

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.

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.

And I just showed you those three in the demo.

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.

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

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

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

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.

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.

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.

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.

Okay, so most things will start in our view controller because we'll likely

need the user to tap on something on the screen before anything else happens.

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

button, then my view controller, my MeViewController,

will get the Submit button pressed, function called from UIKit.

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,

and my MeViewController will do what's appropriate at that time.

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.

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]

HoBshare Overview Part 2

Toward the Future of iOS Development with Swift

与讲师见面