[MUSIC] All right, so what I want to do in this lecture is just to set us up for our reverse geocode design, set us up for our case study, try and understand what it is we're going to build. The high-level idea is that we're going to have an application that's roughly laid out like this. We're going to have a map view that's at the top, and that's going to fill up most of the screen. That's that gray box there that has the cross hatches for streets. We're going to have that take up most of our screen. The user should be able to pinch and zoom, move around, pan through the world as you would any map interface. In the center, though, we're going to put a pin, and that pin isn't going to be programmatic, that pin's going to be a graphic. We're going to have that graphic as an image object that's going to be floating on top of the map view. And that will just be kind of a target that we're going to be using for the user to orient where we're going to be doing the reverse geocoding. Down at the bottom, we're going to have a label. That label is where we're going to put the results of the reverse geocoding information. And in our first design we're going to have a button next to the table that's going to cause the reverse geocode to fire off. All right, so the way this would work is that the user is moving around, that pin is going to look like a pin on the map, and there's going to be a dot. And when the user moves the map around so that the dot is located on a specific location, they'll hit the button. And the reverse geocode event will go out to Apple's iOS services to do that. The results will come back, and we'll put the information here in the label. Now, this is going to be the first version that we're going to implement. And what we're going to do in this first version is we're going to just only have the services go when we hit the button. The only thing tricky we're going to do with this user interface, besides that PIN at the top, is that we're going to have the label change size. Because you can have different amounts of placemark data come back, we're going to allow that label to get larger with more data and smaller with less data. And we're going to have the map view adjust so that as the data goes in, the map view goes up and down to accommodate all that data. So we see all the data that's getting put in. That's just going to take a little bit of thought in the constraints that we put on there. Now, Sam's really good about thinking through some of these different ways of doing UIs. And one of the things that he really was interested in doing was getting rid of this button entirely. So in version two of the interface, we're going to get rid of the button, we're going to extend the label the entire length of the bottom. We're not going to be using the toolbar, we're just going to have a label down there. And as the user moves the map around, every time the map settles into a location, we're going to fire off that geocode event. So that the label is constantly getting updated without having to hit the button in order to cause the event to go off. Now, the reason why this is tricky is because we don't want to hit that rate limit. We don't want to send out events too often. So in the second version what we're going to do is we're going to make sure at any given time we only have one reverse geocode event going out to the service. Because a geocode takes a little bit of time to send the information out for the service to calculate the address and to send it back, that amount of time, we're going to assume is a good amount of rate limiting. So if we only have one request in flight at a given time that should be okay. And then when the user stops moving the map, we'll stop sending the request out. All right so that's kind of what we're going to hit in our case study. I just wanted to give you kind of the overview of where we're going, so as we dive into the code, it's not confusing how we're going to get there, okay? All right, let's do that. [MUSIC]