[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]
