I haven't said anything yet. It's all right. Thanks for joining us this morning, starting off your conference, second session of the day. I'm really excited to be here this morning to talk to you about what's new in Core Location. We've got a lot of stuff to talk about today, so let's dive right in.

But before I get started on content, I want to take a few minutes to ask why you're here today. And I suspect there's probably a few reasons for that. I suspect we've probably got a few people in the crowd who are location experts. Maybe you've built some applications that use location. You've seen the potential that it has to improve the experience for your users.

And then, on the other hand, I imagine there are also some people here today for whom this is new to them. Maybe you're looking to develop your first location-aware app. You're not quite sure what it entails, what's involved. So I'm really hoping that today is valuable for both groups of people.

So whether you're here because you've done this before and you're hoping that we've added new things that make it even easier to incorporate location to your application and really expand the possibilities for your users, or whether you're brand new and you want to get started on your first location-aware application, we're really excited that you're here today, and we think we've got a lot of great stuff to show you.

Why? I know that we do this every year, but I think it's really important to just think about what can location do for your application? Why is it powerful? And the answer is that location is really powerful because it provides context about your user. iOS devices, it's really this whole new platform that is inherently mobile. Whether it's an iPhone, an iPod Touch, or an iPad, users just expect to be able to put these in their pocket, put them in a bag, and take them out in completely new surroundings.

So it's not a safe assumption to just assume that the way things are now is the way that things always will be. So using location, you can make it so that your applications already are in tune with where the user is, with the environment that they're in. Whether they're just moving across town or moving to a new country. Using location services, your application can be aware and it can immediately bring the user into a context with which they're familiar.

It really breaks down that barrier between what they're trying to do and getting them to doing it. But not only does it just make your applications more intuitive, we're starting to see brand new use cases for location. Five years ago, the notion that we would have devices in our pocket that allow us to share what we're doing, where we are, and even bring our friends in the action, social location, would be unheard of. And if you look at iOS 5 alone, we as Apple are really starting to bring location into new scenarios in the system.

With the new Twitter integration in iOS 5, we allow users to geotag their location from any application. They just hit a button, and they're already tweeting. We think location-based reminders are going to be huge, so that users can ask to be reminded when they leave a certain location or go to a new location. And location-aware weather just allows you to, at a glance, see the current conditions where you are, no matter how far you've moved since the last time that you set the cities and weather app. So that's us, but it's really just the beginning.

Because what we're really excited about are the possibilities that we can continue to see realized, and the applications that are created by our developers. And these are some of the big examples. We have Yelp and Foursquare, and we have fitness apps, things like that. But what we're really excited about are the applications that we haven't even thought of yet, the applications that are just in your heads, that are just possibilities. And it's our goal to make it possible for you to build those applications, to make it easy for you to just take the location part as a given, so that you can take that and then move on to building the really great user experience.

So, given all that, hopefully I've convinced you that we're really excited about this, and we're really excited to see what you're going to do with it. What are we going to learn about today? I'm going to start off by talking about how to use the Core Location services. We provide three different services. I'm going to talk about each of them, how to use them, and when to use them.

After that, I'm going to talk about authorization, about this notion of putting the user in control of their location information. Users are more likely to use your applications if they feel like they have the final say in how their information is used. And we've gone to a lot of effort to make it possible for your application to be aware of their decisions and respond to it.

And then finally, we're going to talk about some new APIs we've added in Core Location. And the way that I think of this is that it really adds a new layer of meaning, of context to location information. It goes beyond coordinates and moves location into the realm of the way users perceive it. So get ready for that.

So we have these APIs that allow you to get your location. How do you use them? What are they? When should you use them? What I really want to emphasize through all of this is that it's really important to choose the right service for your use case. Applications use location in a wide variety of different ways, whether it's the user looking at their device and looking at a map, using location in a social way, checking in, or really just wanting to be able to use location in the background.

These applications have different location needs. There are different trade-offs that are acceptable to the user and they have different costs as well. So as we go through these, try and think about where your application fits in terms of these services and what the best one to use is.

We have three different positioning methods that underlie these services. The first one is cell positioning, and the way that this works is that devices with cellular radio, so our iPhone devices as well as our 3G-enabled iPads, are connected to a cellular network. And we can get the unique identifier of the cell tower that the device is currently connected to, and then based on that information, if we go to a database and we know where that cell tower is, we can locate the device. Now, because the device stays camped on the cell network, this is a really, really inexpensive form of positioning to do, and it's fast. We immediately know which cell network the device is on, and so we just need to do this database lookup.

Now, because cell towers tend to cover a large region, anywhere between 500 meters up to several kilometers, or in some cases even more than that, this isn't the most accurate method of positioning. But it is the quickest, and it does have the lowest cost in terms of power.

The second type of positioning we have is WiFi positioning. And this works in a similar way to cell positioning, but what the device does is it actually does a scan to see which access points are near the device, in the same way that the AutoJoint scans work, scanning to see if any known networks are around so your device can automatically associate.

And we can pull the MAC address, and again, a unique identifier from each access point, and then by cross-referencing from a database, we know where those access points are, and we thus know where the device is. This is also relatively quick. It's a bit more power intensive, because it requires the device to actually go and do a scan. But it's still relatively quick, because again, it's just a lookup in a database. And because the range associated with WiFi access points tends to be somewhat smaller, this is also more accurate as well.

And then the third notion of positioning is the one that you're probably most familiar with, and that is GPS. And at a very high level, GPS works by having a receiver listening for signals from satellites that are orbiting the Earth. And if it can get signals from enough satellites, it can triangulate to determine the device's position.

So why mention this one last, because it's the most familiar one? I really want to emphasize that these technologies are complementary. There's not one that's better than the other. It's not like GPS is always the one that we want to use. While it does have the best accuracy, it doesn't get a fix quite as quickly as cell or WiFi positioning does.

It can take a number of seconds in order to detect satellites, particularly in challenging positioning environments. And there are some environments that are really difficult for GPS, like an underground parking garage or a subway system. If it doesn't have at least an indirect path to the sky, GPS isn't going to work.

And finally, not all of our devices have GPS receivers. We've shipped a GPS with the iPhone 3G and onward, as well as with our 3G-enabled iPads. But your users who use iPod Touch devices and WiFi-only iPads, or who use your applications in kind of these non-traditional environments where a GPS signal may not be available, want to use your application too. So it's really important to look at these technologies as complementary, and to look at them as a big picture in terms of how they can help your application use location.

So we have three different services provided by the Core Location framework that make use of each of these technologies in different ways to provide services to your application. So you can think of the technologies as the nuts and bolts, the implementation details of how the device positions you. But the services are what your application cares about. They're your entry to the location service. They're what you use to position your application. So these are really the decisions that you make. We abstract away the technologies into these services.

The three services are the standard location service, which is essentially a service aimed at getting your application to the best position as quickly as possible. We have the significant location change service. And the purpose of that service is to allow your device to get regular updates when the user changes their position significantly, even when your device is in the background. And then finally, we have the region monitoring service. And this is a service that allows your application to specify locations and regions of interest that it cares about and get notified by the Core Location framework when the user enters or exits those locations or regions of interest.

So I'm going to start off by talking about the standard location service. Again, this is the most conventional. It's probably the first one that you look at when you think of location. And its goal is to get your application a location quickly and accurately. So you see this in use in Maps. Turn-by-turn navigation applications often use this.

So taking a look at the high level of how this works, if you view your application as a whole, this is really just one part of it. But the Core Location framework is your entry to the location service. It is a set of APIs that you call to use location.

And then inside your application, you will provide a delegate object. We call it a delegate object because you'll need to implement the CL Location Manager delegate protocol. This is essentially a set of methods that your delegate object implements in order to handle locations that are received from the location service. Now, inside the Core Location framework, there are a few components that you'll use. The first is the CL Location Manager. This is the central object that you will use to request locations, as well as determining the authorization state of the device.

Now, when a location is received, that comes back to your delegate object in the form of a CL location object that is essentially a data object that contains all of the information about the location. The coordinates, the accuracy, altitude, timestamp, speed, course, all that information. So how do you receive locations? Well, it's as easy as creating the Core Location Manager, the CL Location Manager object, and then calling StartUpdatingLocation.

You call that API, and then in return, when the service determines a position, it will call you back with the LocationManager didUpdateToLocation, FromLocation, they'll get callback. And that provides you these locations that you use. So at a basic level, it's all very straightforward. You ask for a location, you get a location back. Couldn't be easier.

However, we find that applications often want to customize the types of locations that they get back. And so we have a few ways of doing that, ways of configuring the location manager. The first thing you can specify is a desired accuracy. And this is essentially a way of saying, how accurate a position do I really need? For example, if you have an application that just needs to know what city the user is in or the general vicinity, you don't necessarily need the best accurate position possible.

And in fact, waiting for that position might be a mistake, because it's more important for your user to get-- for you to get a location quickly so you can display something to the user than to get the most accurate position. So desired accuracy is your way of specifying how good of a position that you need. And under the hood, Core Location then determines which technologies to use based on this accuracy. So there could be a significant power savings by specifying a higher location accuracy if your use case doesn't require the best possible. In turn, better user experience.

The other property is the distance filter. And this is really aimed at simplifying the logic for applications who don't necessarily need to know every time the user moves a tiny little bit. For example, if your application just cares if the user changes cities, or changes neighborhoods, or walks some number of blocks, but you don't necessarily care that they moved a few meters down the street, you can specify a distance filter.

And this is essentially how far does the user need to move before you get another location callback. And in fact, if you set this large enough, you know, to kilometers or more, the location service can actually optimize by turning off certain technologies and then restarting them again when it's possible for the user to have moved that distance.

If you say notify me every 10 kilometers, the user is unlikely to move that far in a minute, for example. Don't worry, though. If a better accuracy position becomes available, so let's say there was a 1,000-meter accurate position, and then all of a sudden a 100-meter accurate position comes in, I bet we get a better position, your application will still get notified about that.

So you get the best accuracy position without having to get all these callbacks repeatedly. One other thing that you'll want to notice about CL Location Manager, which I'll come back to later, is the authorization status, which indicates the choice that the user has made about your application with regards to location services.

Now, one note about what we call continuous location applications. These are applications where the user expects the same experience from the application, whether it's in the foreground or whether it's in the background. So examples of this are turn by turn navigation applications. The user wants to go and check their email, but they still need to know when they need to turn right at the next intersection.

Or fitness applications, they still want to track their distance, even if they switch over to the iPod app to change what song they're listening to. If your application's one where the user expects that same experience, that same accuracy, expects the location to continue running, even when the application's in the background, we have a way for you to do that. So what you do is you add a particular plist key to your application's Info.plist. And then once that key is set, as long as the application is using location, it continues to run in the background and receive location information.

Now, as with any of our services, there is a cost to doing this. Obviously, if the GPS is running, that's going to have an effect on the user's battery life, as well as the CPU cost of keeping location running. So we really expect that this will really only be of use for these use cases. But if you need it, here's how to do it.

So that's a standard location service. And it's great if you're really in this environment where you need the user's position as accurately as possible right now. But what if you're in an environment where what you really care about is when the user moves significantly? It'd be kind of wasteful to run the GPS the whole time if all you want to do is detect, all right, well, the user's moved, say, 300, 500 meters. So I want my application to check and see, you know, maybe if another user is nearby that they care about, or maybe I want to transmit that location. Maybe it's a social network, something like that. It'd be really wasteful to run the GPS the whole time.

And if you take a high level picture of what happens to a device when it moves, a variety of things change. For example, the cell tower that the device is camped on changes. It may do scans for AutoJoin and find different access points, or it may camp on different access points if the device moves.

And so we can actually use that information, these new cell towers or seeing different Wi-Fi access points, as a trigger to say, hey, the user's probably moved. And if we know that, then at that point, we can do a position calculation and notify your application if the user has, in fact, moved a significant distance. So we call this the Significant Location Change API.

As I said, it calculates the location when the device moves significantly. And the key advantage to this API that you don't get with the standard location service is that your application does not have to be running in order to receive these updates. And by not running, I mean either it can be in the background suspended, not receiving CPU time, or it can actually be completely terminated, not in memory at all, not running. And it can still be notified in the background when these events occur.

And in iOS 5, we've done a lot of work to improve the performance of this API. Whereas previously it functioned exclusively based on cell towers, we've added a number of these triggers that we talked about to make this API more accurate and ensure that you get the notifications when the users move, even if it's not a huge distance, even if in some cases it's not enough for them to move cell towers. So we think this is a great way to keep your application location aware, aware of the user's context in those situations where it's required.

So how do you use it? So this is kind of the graphic I put up for the standard location service before. And the reason that I put it up here is because it's very similar. But instead of calling startUpdatingLocation, we have a new API called startMonitoringSignificantLocationChanges . And you call this API on the CL Location Manager, and then you get the same delegate callback. You get the same Location Manager, did update to location, from location delegate callback. So you start in a different way, but you get the locations from the same delegate callback.

So that's the significant location change API. And that's great. It keeps your applications kind of in tune with where the user is without the costs of having your application running all the time. But we found that there are classes of applications that don't necessarily need to know every time the user moves.

Rather, what they care about is when the user goes to some locations of interest. So this is very similar to before. We have all these same environmental signals. But rather than notifying you just when the user moves, we can notify you when they get to some area that you care about. In this case, there's a coffee house here that maybe the user wanted to get reminded of when they got near. And so we have the region monitoring API.

And so what this does is it allows your application to register locations of information in a surrounding region, so that when the user enters or exits that region, your application can be notified. And like the significant Location Change API, your application can get launched in the background even if it's not running.

Now, we've had this API since iOS 4, and at the time, it was based on cell positioning. We've made a lot of improvements in iOS 5 to improve accuracy. Again, we're using these triggers that we've defined. So for example, if the user camps on a new Wi-Fi network, they associate or they disassociate, or they turn the screen on their device, we use that as kind of a trigger to know that, hey, the user's environment has probably changed, to check to see whether they've moved. This is the same technology that you'll see in the new Reminders application in iOS 5. So we think we've made a lot of great strides towards building a really robust service that your application can depend on.

So, starting region monitoring. This is a little different in that rather than just saying, "Go, I want to start updating location," you specify the regions that you care about. And there are a few items of interest that make up kind of these regions. There's a coordinate, so a latitude and longitude.

There's a radius, which you can think of that as a boundary at which you want to get these entry and exit notifications. When the user crosses that boundary, you'll get notified. And then an identifier so that you can refer to these regions later. You call the Start Monitoring for Region API on CL Location Manager. And then when an event occurs, you get the Location Manager did enter region or Location Manager did exit region callbacks.

All right. I already mentioned this. One other note is that we also make use of every type of position now. In our iOS 4 API, it was exclusively based on cell positioning. But if for some reason something on the system happens to be using location, we'll use that as well. So that's one other improvement that we've made to region monitoring.

So those are the services. Those are how you use them. That's what they can do. And there's a lot of power there. We think that there's a lot of potential here to enable great new use cases for your applications. But with all these great new use cases, it becomes really important to make sure that the user stays in control of how their location information is used.

The reason for that is that the more confident they are, the more likely they are to use your new applications. And the reality is that no matter how cool your use case is, no matter how amazing it is, even if they paid money for your app and they downloaded it and they're totally on board to use your application, not all users will have location services enabled for your application.

It's just a fact. It's a reality. And so what's really important to do and what will really make your users be more confident in your application is if you detect that and you provide context to the user that allows them to understand the implications of their decision and lets them know what features will and will not be available based on the availability of location services.

So let's walk through some of the ways in which users are allowed to make decisions regarding location services. The first thing is the permission dialogue. This is presented once per application, and it's the user's opportunity to make an additional decision. They can say allow or don't allow. And it's important to have a plan for what happens if they say don't allow, even if that's not what you expect. We have a purpose property that allows you to tell the user why your application needs to use location services.

Now, you may not think this is necessary, but there are a lot of applications where location is really, really useful, but it's not necessarily immediately apparent why it's needed. A good example is the built-in camera app. It geotags photos so that the users can later go into iPhoto, for example, and see where they took their pictures, and even make those great location-based slideshows. But it's not immediately apparent to the user when they open the camera app why they would need to use location. So the purpose property is your way of telling the user why location is important.

There's the status bar icon. This is the user's indication that an application in the system is using location services. And it's important to note that this icon will stay present whenever your application has access to the user's location. So this is straightforward for the standard service. It'll be there whenever you've called Start Updating Location and haven't called Stop Updating Location yet.

But for the significant change in region monitoring services, your application effectively has access to the user's location the entire time that those services are active. Because by virtue of getting notifications every time the user moves, when you don't get a notification, you know the user hasn't moved, for example. As a result, that icon will be present whenever any of the services are in use. So just be aware of that.

If Location Services is turned off on the device, the system will present prompts a limited number of times, letting the user know that they have disabled Location Services, and inviting the user to change their decision. This won't always be shown to avoid essentially pestering the user into turning on Location, but it's a good hint that will show up a few times to let them know why applications cannot use their Location.

So that's what happens in the application. However, the user also has the ability to change their decision and to adjust their preferences in settings, as well as to see which applications have used the location recently. So there's the Master Location Services switch, which controls location for all applications.

There are the list of applications that have used Location. Now, bear in mind that your application will not show up in this list until the first time it uses Location Services. So just including the framework isn't enough. The first time you request a Location Service, you'll get an entry in this list. Your application will.

There's a location arrow, which is the user's guide to which applications have been using their location recently. And it'll be displayed if the application has used the location in the past 24 hours. And then finally, there's the approval switch. And we have methods on-- we have class methods on CL Location Manager that allow you to query this value and respond appropriately to it.

And the way that you do that is with the CL Authorization Status enum and the Authorization Status class method on CL Location Manager. This is new in iOS 4.2, actually. And I wanted to take some time to guide you through kind of the different states that your application can be in with regards to location authorization. There are actually four of them. The first one is that it's just not determined yet. You haven't used a location API, so the user hasn't been prompted yet. They haven't made a choice.

There's the authorization state, which is probably what you want, saying that you're okay, you're good to go, you can use location. There's the denied state, which means that the user has disabled either location services system-wide, or just for your application, your application's individual switch. And then there's this fourth state, which is a little bit subtle. It's the restricted state.

And it's similar to the denied state in that the user cannot use location services for your application. But unlike the denied state, the user cannot authorize your application. And the way that they could get into the state is if parental controls are enabled onto the device. We allow, through parental controls, the ability to restrict changes in location authorization for your application. So if it's either denied, don't allow is hit, or your application hasn't yet been authorized, the dialogue hasn't been presented, you'll end up in this state if restrictions are enabled. But unlike the denied state, the user really can't change the decision. So keep that in mind.

Phew, that's a lot of stuff. There's really a lot to learn about Core Location, how to use it, and we're just adding more. And I'm really excited with this section because it goes beyond coordinates, and latitudes, and longitudes, and speed, and course, and it gets into things that users care about, the way that users think about location. Because coordinates are really only part of the story.

We have this CL Location Manager, and you call Startup Dating Location, and you get locations back, and they come to your API. But they're just numbers. They're just these digits. And while you know what they mean, your users don't. Users don't think in latitude and longitude. They think in terms of descriptions, in terms of addresses. When they think of the Moscone Center, they think of places like, they think of addresses.

And so, to this point, it's been difficult to really do this conversion. The user tells you a location that they care about, and you need to display it on a map, or you need to convert that to coordinates for some other reason. Or you get a location back from the location service, and you want to describe that to the user. So in iOS 5, we are adding geo-coding APIs to make this easier. Thank you. Pretty exciting.

And we're adding both two different types of geocoding. We're adding reverse geocoding, which is the process of taking a coordinate and turning it into an address. And then we're also adding, and this is brand new in iOS, forward geocoding, which allows you to go in the other direction, taking an address and converting it to a lat-long.

So why is this useful? Well, I've already given you the high-level spiel about, you know, makes it meaningful. What are some concrete use cases? For one, it allows you to describe a location. This is the basic, you get a location back, and you want to display it on screen. You can do that. You can also do things like locate an address book contact. You can present UI to allow the user to select one of their contacts, and then immediately know what that means in terms of coordinates.

You can imagine applications like tagging notes with the city where they were written. If you actually, if you have the developer's installed and you go to the Compass application, you can actually tap the bottom bar, and it'll give you a description of where the user is right now.

So that's a concrete example in iOS. The way that you do this is with a new class we're introducing called CL Geocoder. And this is your way of doing both forward and reverse geocoding. Again, forward is address to lat/long. Reverse is lat/long to address. Try and keep those in mind. It's not the most intuitive. This is a fully asynchronous API. Just like CL Location Manager, you're not going to get results back immediately.

So you basically make a request, you get a result back when it's ready. You create one CL Geocoder per request you're going to make. If you need to make multiple requests at the same time, create multiple geocoders. So that's your entry point to geocoding. What you get back is this class that is called CL Placemark.

And this is returned as a result from all geocoding requests, both forward and reverse. It contains a normalized location, which is the location essentially associated with the broader result that was returned. So for example, if you provide a coordinate, and then you get back, you know, a particular address, it will be the coordinate associated with that address.

It'll give you back a region if the result that was returned is actually for some larger landmark, like maybe you just got a neighborhood back, or you got a university campus or something like that. You'll get back what we call an address dictionary, which is an NSDictionary object that contains keys and values in a normalized format that integrates with the address book framework. And then finally, you'll get back some descriptive properties.

These are things like, for example, if I were to geocode one infinite loop Cupertino, California, you'll get back that that's Apple. Or if you geocode an ocean or an inland body of water, you can actually get descriptions back that give you kind of more detailed information about what that geocoded location actually is. As I said earlier, this all integrates really well with the address book framework. So you can take the store of information you already have about essentially locations the users are interested in, and really easily integrate that into your application.

Using CL Geocoder. So CL Geocoder is a blocks-based API. Because it's asynchronous, we actually need you to tell us what to do when we get the results back. In CL Location Manager, we do that via delegate callbacks. You specify an object and basically say, hey, when you're done, call this method, tell me what happened. On CL Geocoder, it's a little different. You provide a block, which is essentially a piece of code that gets executed when the request completes. And we call that the completion handler.

A completion handler takes a couple of arguments. It takes an array of placemarks. The reason it's an array is essentially there may be more than one result. You know, if the user just entered a string that's a little ambiguous, we may not be exactly sure what they meant, so we'll return multiple results. And then if an error occurred, we'll pass you an error instead, letting you know what happened.

So why might a geocode fail? Why might there be an error? The most common is a network error. This is a server-based API, and so a data connection is necessary. On devices that have an always active connection, this isn't such a big deal. But if you're on, say, an iPod Touch, and it's not connected to WiFi, you'll get a network error back. We may not have any results. I think we've done a great job, and you'll hear more about this later about our coverage. But particularly if just the query we got was nonsensical, we can't make sense of it. we may not have any results for you.

If you're doing a reverse geocode, again, coordinates to an address, and we don't have a network connection, we can actually do what's called a partial result device side. We can tell you what country, at the very least, that coordinate is in, just based on a device side database. And then finally, you can cancel requests once they're in flight, and if you do that, you'll get a canceled callback. So those are the reasons why they might fail.

So I mentioned a little bit about the address book and how they work together. But there's a variety of things that you can do. The first thing is you can use the people picker to turn the contact's address into a location. And I'll go through exactly how to do that later. You can store a returned address that you got, say, from a geocode, into the user's address book.

And then finally, you can also use the address book to format a return address in a way that's appropriate for the device's current locale. So that's a lot of stuff. I'd like to invite Richard Heard, who works on our frameworks team, who's going to give you a demo of how all this works. Take it away, Richard.

Thanks, Morgan. So today, I'm going to demonstrate to you a simple geocoding application that uses the geocoding operations So first up, let's have a look at forward geocoding. Forward geocoding is where we take an address, either a string or a dictionary, and convert it into a set of coordinates. So for this example, I'm going to use Castro Street, San Francisco.

I'm going to leave the region hint unset. This implies the device's current location. And now let's perform the geocode. So again, we returned an array of CL placemark objects. So let's have a look at the properties on the placemark. Okay, that looks like Castro Street. So first up, we have our location object, which is a seal location. And the important property here is actually the coordinate.

Next up, we have a region, which in this case is not set. This is only set, again, if it's a large geographic region or area. And finally, we have the normalized address dictionary. In this case, we can see Castro Street, San Francisco, Noe Valley, California, and the postcode. So that's string geocoding. So now, let's have a look at dictionary geocoding. For this example, I'm going to select a contact from the address book.

You'll note that the address here, John's work address, does not actually have a postcode. However, this isn't a problem for the Geocoding API, even when you're using the address dictionary. So let's perform the geocode. Again, an array of CL placemarks. And there we go, 333 Bush. So we have our location.

We have a region, which in this case is not set. And we have a fully formatted address dictionary. You'll note that we've actually been returned the postcode or the zip code. So this is a really cool way of cleaning up an address that you're pulling from the address book. So that's forward geocoding. So now let's have a look at reverse geocoding. In this case, for this example, I'm going to use the device's current location. So there's our standard location alert. Cool. Now let's perform the reverse geocode.

And again, we returned an array of CL placemarks, in this case, one. And here's our address dictionary. So it looks like we're on Fourth Street. I think that's probably the Moscone Center. So here's our region, again, not set, and finally, a normalized location. So that's reversed geocoding. So now I've got a demo of a semi-real-world example, at least.

I was talking to a friend last night, and he's in town for the conference at the moment. And we were trying to work out how far it is from Melbourne to San Francisco. We guessed it was about 12,000 kilometers. But using this example, we now can calculate it exactly. So I'm going to search for Melbourne. Okay. and let's select San Francisco.

Okay. There we go. 12,698 kilometers. So that's geocoding. And this is actually-- this sample application should be available to you today on the session website. So with that, I'd like to hand back over to Morgan, who will go over a little bit more about geocoding. Thanks, Richard. So hopefully that demo gives you just a bit of an idea of what you can accomplish with geocoding.

Now, I'm going to give you just a little bit of an idea of how the API works. I'm going to skip part of this because we're running short on time, and I want to make sure we get to some of the cool other stuff we have to show you. The basics are that you create a CL Geocoder object. It's just a straight alloc init. In this case, we're doing reverse geocoding, so we want to create a location. So you pass in a CL Location coordinate corresponding to, in this case, I believe this is Apple.

And then what you do is you tell the geocoder to reverse geocode the location. So you pass in the CLLocation object, and then the other thing you pass in is this thing that we call a completion handler. And again, this essentially defines what you want to do when the request finishes.

Now, in this case, I'm just kind of iterating through the placemarks and logging them, but you probably want to do something like update your UI, pass the placemarks off to something like that. The demo that Richard showed you has more concrete examples of how to do that. But at a basic level, it's really easy. You just have the location that you need, you pass it in, say, reverse geocode this, and when it's done, here's what I want to do. It really keeps the notion of I want to geocode, and what do I do when it's done really close together.

Now, for forward geocoding, there are two options, as Richard showed. The first one is to use an address string. And this is essentially just a string maybe taken from a user, from a text field, something like that, that describes the dictionary-- or sorry, that describes the address. So in this case, we just have one infinite loop, Cupertino.

But once you have that, the process is, again, very similar. You tell your geocode to geocode this address string. You pass in the string. And then again, you define the completion handler that says, here's what I want to do when it's done. And that's code that you would provide.

The last thing that you can do is to use an address dictionary. And the way that you do this is-- the most common way that you would get an address dictionary is from the Address Book API. But just for clarity here, I'm going to build one myself. So in this case, I've got my street as one infinite loop, my city as Cupertino, and my state as California.

And I want to geocode that. So I have this dictionary that I've created. I pass into the geocoder, I pass the NSDictionary object, and again, I define my completion handler. So you just have your data, you say, "Geocode it." When it's done, here's what I do. It's pretty straightforward.

Now, how do you actually get an address from the address book into the geocoder? So there are actually four different steps. I'm not going to go through the code, but just to give you an idea. The first thing is to present the people picker. This is a standard view controller that's provided by the address book UI class. From there, you allow the user to navigate to retrieve the selected address. You could then geocode it, and then format it however you would like.

So presenting the people picker, you basically create this navigation controller, and this is the UI that you get. It's the standard UI, very similar to the Contacts application. And it provides you with a list. And then from there, you present the view controller. But once you get there, the user will present-- will essentially select an address on a particular contact card.

And then once they select that, you essentially get that address back via a delegate callback from the address UI framework, address book UI framework. Once you have that, it's very similar to before. You just create your geocoder, tell it to geocode that address dictionary, and then do whatever you want in response to it. And then obviously at the end, you need to dismiss your view controller. Again, the sample code shows you how to do this in detail.

So that's a lot about the service and kind of how to use it from our side, but there's a lot of data backing the service as well. So at this point, I'd like to invite up Pierre-Luc Beaudoin, who is one of our iOS server engineers, to discuss the data backing this service.

Thank you. Hi. So I am Pierre-Luc Beaudoin. I work on the iOS server team. By now you are probably very excited about this new service, and... I can see questions that you might have, such as, who's going to be able to use this? And is this going to be limited at first? Well, we are actually very happy to announce that we are launching with global coverage. We have-- thank you. We have extensive coverage for all the major international iPhone markets. We also spent a great deal of time localizing this data. And you should be able to search for any significant city, state, or country in any of these 30 languages.

And let's have an example of what that means. For any point in the world, the user should be able to read the returned address in their language. We also support local languages down to the street level. And let's have an example of what that means. Let's suppose you're a tourist in Brussels, in Europe, and you would like to taste some of the very good local beers.

That's you. Now, you look into your guide and your American guidebook. It sends you to this address. This is the address of a very well-known cafe where you can taste a lot of beers. And by the way, you don't have to be that much specific when you enter an address, but for the sake of this example, let's keep the country in.

Now, suppose you're a French speaker living in Brussels. How would this address look like? It would-- oh, French. It would look like this. Notice how different it is. The ordering has changed. Both the country and city name have changed. Now, how would it look if you're a Dutch speaker living in Brussels? It would actually look like this. Again, a completely different address. Let's compare them.

This happens because every street in Brussels have both a French name and an official Dutch name. But let me reassure you, this is something your application doesn't have to care for, because all happens on the API side. Your application needs to ask the user for an address, And then the user will use their natural language. And our API will return a longitude and a latitude for your application to consume. And there's really nothing else required from your site.

Now, let's have a reverse geocoding example. Let's say you are reverse geocoding a point on the San Francisco City Hall, and your device is set to English. Here's the address it would be given. Now you can see we are returning multiple levels of geographic containment, and from locality and down, those will be localized. So let's see what happens when your device is set to Polish.

In that case, the state and the country name changed, because it happens that San Francisco is the same in Polish. But if your device is set to Russian, it would look like this. Again, from locality and down, it is localized so the users can read it. So let's recap. We are launching a global service with support for multiple languages, and the result will automatically match the device's locale. Thank you.

Thanks, Pierre-Luc. So this is pretty exciting. As he mentioned, we've got this brand new service that does both forward and reverse geocoding that we're launching with global coverage. It's fully localized, and your application doesn't need to care about any of the details. It'll just work for you. You may have some questions.

We already have a reverse geocoding API in MapKit called MK Reverse Geocoder, and we've had it for a while. So you may be wondering, how does this relate to CL Geocoder? And the answer is that CL Geocoder has a number of advantages over the MK Reverse Geocoder. The first one, the most obvious one, is that we do both forward and reverse geocoding. The MapKit team, I'm sure, can tell you that they've gotten many, many requests over the years for forward geocoding. So we think this is a really great step forward.

The other condition that you may be aware of surrounding MK Reverse Geocoder is that it requires that locations be displayed on a map. That's why the API is in MapKit. You are geocoding locations for the purposes of showing them on a map. In CL Geocoder, we've dropped that requirement. You can do forward, you can do reverse geocoding, and you can present those results however you would like to in the context of your application.

As a result, going forward, we are deprecating the MapKit geocoder. We're really excited about CL Geocoder, and we're really looking that moving forward, applications will move to CL Geocoder. But don't worry. We're well aware that a lot of use cases for geocoding are map-based. And we've worked really closely with the MapKit team to ensure that CL Geocoder integrates well with MapKit.

So if you'd like more information on what that means, transitioning your MapKit-based application to use CL Geocoder, and essentially how the two APIs work together, I'd highly recommend going to the MapKit session tomorrow morning, bright and early, in Russian Hill, that talks about-- the title is Visualizing Information Geographically with MapKit. They are talking about how to integrate this new geocoding service into the API.

So, wrapping up, we covered a lot of stuff. Use Location to improve your users' experience. There's a lot of potential. We're just starting to see the beginning. Make sure to choose the right service. We have the standard service, the significant change service, and the region monitoring service. They're designed for different things. They have different trade-offs.

And lastly, we're really looking forward to seeing how you use this new geocoding service to make location data even more meaningful for your users. No matter where they're from, where they're traveling to, what language they speak, your application can provide that experience, and it can get it for free from our new Geocoder API.

If you need more information on any of these new APIs, I'd really encourage you to contact Vicky Murley, who's our evangelist. Her contact information is there. Or consult the documentation. We've updated both the framework reference as well as the location awareness programming guide, with information about geocoding and how all of the services fit together.

And of course, there's always your good friend, the developer forums, that allow you to get help from other developers. With that, oh yes, there are also some more sessions. So I also mentioned the MapKit session, which is tomorrow. And the other thing that we're really excited about, and that you probably heard a bit about yesterday, is that in iOS 5, for the first time, we're adding ways to test your location of your application without getting in a car. We're adding simulator support, and we're adding a bunch of great new developer tools to make that easy.

And we're so excited about that, there just wasn't room for that in the session. So we're having a special session on Friday at 9:00. I'll be there giving that talk. And I hope you'll join me to find out all of the ways that you can build really robust location-aware applications that your users will love. Thank you very much. Thanks for listening.