Good morning. My name is Morgan Grainger and though my business cards say "Dreamer," most people would call me a software engineer. I'm really excited to be here this morning to talk to you about using Core Location in iPhone OS 4 or, as I would call it, how location changes everything for your users and your applications, but not to set expectations too high. So let's start off by talking about you. Why are you here this morning? So I'm assuming that you're here because you want to make your applications more location aware and that can mean a few things.

Maybe it means taking your existing application and adding location to make it more intuitive, easier to use to add new features or maybe it means designing entirely new location-aware experiences for your users. Whatever your goal my goal is to help you get there and so I hope you sit back and take in the information and if you have any questions, I'd love to hear them at the end.

So, I'm here to talk about four things today. The first thing I'm going to talk about is why location? Why is it important? Why does it matter? What can you get out of it? The second thing I need to discuss is how does it work? What are the technologies that underlie location services on iOS? After that, I'll get into the details. How do you use it? How do you integrate location services into your application? And the last thing I'm going to talk about are several exciting new location services that we've integrated into iOS 4.

So, let's get started. Why location? Now, location though you know it's kind of a simple thing in principle, it's actually used for a lot of things in practice. On a basic level, location tells you where you are. The built-in Maps application on iPhone and iPad you can hit a button and it shows you a map, maybe you use the compass to show your direction. It's a simple concept, but it's very powerful. Maps is one of the most used location-aware apps on the platform.

Location goes well beyond that though. Location can tell you where you want to go by providing context, by saying well, I'm here if you enter some address where I want to get to, by using GPS and other location services we can guide you along the way and making use of data we can use that to get the user towards their destination step-by-step, but not only for just, it's not only good just for saying here's where I am and here's where I want to go. Location is really powerful when it's integrated as a piece of other applications to make them more intuitive.

Applications like Yelp where, you know, if I say I'm here I'm at the Moscone Center, I'm here for WWDC, I just want to find a place to eat. Without location, I'd have to go and say, yeah, I'm at the Moscone Center, you know, in downtown San Francisco. Before it could load information about what's around me, but with location I can just hit a button, give my authorization, and my location is right there. Even things like Kayak; I need to catch a flight out, if it knows my location, it knows my nearest airport right away, and I can get on to specifying more details.

It breaks down those barriers. And then the last thing it can do is social locations. The idea of sharing my location with others. I can add context, I can make my updates, the things that I share richer by including location information. If I go up to the Golden Gate Bridge, you know, I'm visiting San Francisco and I say, yeah, I'm here, this bridge is really red.

Like they must have to paint it constantly. Because the application knows my location, it already knows where I am, it can, you know, suggest places that I might want to, that I might want to comment on and then it's easier for me to add my information to annotate that location, but it builds a base that I can start with. So those are four things that location can do.

In summary, location is important because it provides context. It allows you to break down barriers between what your user wants to do and how they can get there. It provides that information that otherwise it would have to enter or tell you some other way. It makes your applications easier to use, and more than that, it enables entirely new use cases. So, that's why location and that's the first thing I wanted to talk about today.

The next thing is how does it work? iOS is leading the way with location services in the mobile space and there's actually a lot going on under the hood. So, I'm going to talk about three positioning technologies that are in use on varying devices that run iOS in order to provide location services and then I'm going to talk about what that means in your applications. In addition, we've made some pretty significant improvements in each of the positioning technologies available in the past year, and I'm excited to tell you about how they make your applications usable in more circumstances and improve the quality of services that you can provide for your users.

So we have three positioning methods of iPhone OS; cell positioning, Wi-Fi positioning and GPS positioning. First one I am going to talk about is cell positioning. The way this works is that on devices with cellular radio, we know which cell tower, we know the unique identifier of the cell tower that your device is connected to. If we have a database up in the cloud somewhere that knows the position of that cell tower and we can go and retrieve it, but in turn we can know approximately where your device is.

Now the accuracy of this approach kind of the error, the difference between where the reported location and where your user actually is depends on the range of the cell tower. In urban areas where you've got high density, a lot of cells, each cell will generally serve a smaller area and so the accuracy will be smaller; maybe in the, it'll be more accurate. The error will be smaller.

Maybe appropriately in the 500 meter range whereas in more rural areas where you've got much larger distances between cells the errors can sometimes be greater. The great thing about cell positioning though is that it's nearly ubiquitous. Anywhere that you've got, that you can get cell coverage, we can potentially locate you. Whether you're indoors, whether you're outdoors, it's really one of the most versatile location technologies around. So, that's cell positioning.

Next up is Wi-Fi positioning. This is similar in concept. What we do is we do a scan to see what advertised Wi-Fi hotspots are in range of your device and instead of associating with them as you would do if you were trying to get data, we just note their unique identifier, their Mac address, and do the same sort of correlation going to a server say what's the position of this Wi-Fi hotspot? And if it's in the database, we can locate the user based on that.

Because Wi-Fi hotspots tend to have a smaller range say in generally around 100 meters or so, the accuracy, the estimated error is generally smaller. Often in the 100 meter range. The great thing about Wi-Fi positioning is that most hotspots tend to be indoors and that's precisely the environment in which GPS positioning, which I'm going to talk about next, tends to struggle the most. As long as there are Wi-Fi hotspots in the area, we can potentially locate your user. And so the third technology and the one that people often thing of most when they think of location is GPS positioning.

So, the iPhone 3GS, the iPhone 3G and the iPhone 4 all have a built-in GPS receiver. Essentially what it does is it listens for signals from satellites in orbit and if it can receive enough of them, it can triangulate to determine your position. One thing to note about our GPS is that it's assisted and what that means is that we can make use of a data connection, either a Wi-Fi or a cell data connection, to download assistance information.

Things like where we expect the satellite to be in the sky at a certain point in time. The other type of assistance we provide is location assistance. If the receiver knows approximately where the user is, they can use that information as input to narrow what satellites it should be seeing and, thus, to give you a position more quickly.

Three types of positioning. And while there are those three types from your perspective there's one API, Core Location. We've taken these technologies each with their situations where they work really well and situations where maybe other technologies would work better, and we've integrated them into this one API. We've abstracted them away so from your perspective in your application you just have to say I would like a location, and we provide that for you. Now, I've talked a little bit about comparing the methods, comparing the positioning methods, and what we usually think of first when we think of location is precision.

How close is the reported position to where the user actually is? And so as I've noted GPS is generally the most precise. You can sometimes get positions within five or ten meters, but precision isn't the only criteria on which to judge location technologies. There's a reason that we use all three of them. Another big one is power.

When you just really want to use your application and they want to get a benefit out of it, but they really want their battery to last all day as well and while GPS is really precise, it also takes a lot of battery power when compared to technologies like Wi-Fi positioning and cell positioning.

The third way that I think it's worthwhile to compare positioning technologies is with regards to time. How long does it take to get a position? And this is really important depending on your use case. If you have an application that uses location as a means to an end as a way to get the user some result, something that they want to see, then it may actually be more important to you to get a position quickly than to get a really accurate position. If I want to see what movie theatres are around so I can just, so I can go and see the latest new movie, I want to see what movie theaters are approximately around me really quickly.

Instead if I'm in an environment where GPS positioning is more challenging and you really want to get that precise position, you know, it could be 15-20 seconds before you can show me information on the screen and that's not valuable to me as a user. So, it's important to look at these technologies as complementary.

They each work in different scenarios; they have different characteristics in terms of precision, in terms of power and in terms of time so keep that in mind. Now, the other thing to consider is that iOS is more than just iPhone. We have, you know, all three technologies are on the iPhone and on the 3G iPad, but Core Location is also on the iPod touch and it's actually also on Macs running Snow Leopard.

And as I'm sure you're aware, there are significant number of iPod touch devices in the world, just as an example, and while it may "only" have Wi-Fi positioning, there's still a surprising amount you can do with that technology and it's a disservice to your user base to exclude, you know, such a large percentage of your users just because they only have this one positioning technology. So, it's important to look at your goals.

What are you trying to achieve? What is the use case of your application? What types of positions can you work with? And, say, well on this platform what can I do? And as a, you know, try and design applications in a way such if they're useable in the widest variety of circumstances as possible rather than to say I must have GPS, I must have these technologies in order to use location services.

So those are the three position technologies. Now, we've had each of these three technologies since version 2.0, but in the past year we've made some pretty exciting enhancements in each of these areas, and I'd like to tell you about them one-by-one, by technology, and I'll start by talking about cell positioning. As I described cell positioning earlier, we know what cell tower you're on and then in order to get the position we have to go to a server that knows the position of that cell tower in order to locate the user.

That begs the question, what if the user doesn't have a data connection? This becomes important if say I'm, you know, going on a backpacking trip across Europe and, you know, I'm just taking a trip, I'm taking my iPhone from the US, but I don't want to pay roaming charges so I just have data turned off. I don't have a data connection, but I still like to use location.

And this is especially relevant in the world of the 3G iPad where devices, where we usually have devices that are camped on the 3G Network, but maybe they haven't signed up for data plan so there's no data connection, but we still know what cell they're on so we could use that information for positioning.

Well, we took a look at the way carriers setup their networks and it turns out that cells are actually setup in groups and in addition to a unique cell identifier, there's also an identifier that groups cells in chunks that generally take, you know, between 30 and 50 kilometers. It's kind of analogous to an area code where you've got three digits that generally identify an area and then the latter seven, which give a number within that area.

And because of that if we just have the position of that group of cells, then we can provide an approximate position for the user just based on that, and it turns out that because there's so many cells that are under one of these identifiers, one of these areas, we can actually store the location of the most used, the most often accessed cells right on the device itself. No data connection necessary.

So, in this case if you look at the screen here, this is a screen shot of me testing this out at Apple Campus in Cupertino, I get a position that shows me that I'm in the San Francisco Bay area, and you know, if I'm traveling around that's still valuable information. It still gives an approximate location for my GEO tag photos and videos and for your applications, it can still allow you to get some idea of where the user is. So, this is generally accurate to between 10 and 50 kilometers; it depends on the area.

Now, the question is, what areas do we pre-cache positions on? Well, we went and took the locations, I guess the groups of cells that our users access most often, and lowered them on the device themselves. If you look here I don't have a data connection, and yet I was still able to get a position.

So, we cover a good chunk of the US, a good chunk of Europe and parts of Asian. Again, these are the areas where people are using iPhones most and so in these areas we can get a position without a data connection. We think this really expands the potential for applications to make sure of course location information in a much wider variety of settings.

So, let's cell. Next up is Wi-Fi. The big news with regards to Wi-Fi goes back to, again, to the notion of going up to a server, to a database. Wi-Fi positioning really only works if a server knows where you're located. If a server knows, you say I can see these access points, you need to know where those access points are and so what we focused on in the past year is really improving our sources of data for Wi-Fi positioning.

Our goal was to improve coverage in the areas where people use iOS devices most. So, just to give you an idea of this, this is a map of our coverage under iPhone OS 3.1, and now with iPhone 3.2 and iOS 4, you'll notice that we significantly improved our coverage in the United States. We cover significantly more areas, much better coverage.

If we go and take a look at Europe and Asia, that was our coverage in iPhone OS 3.1, but in iPhone OS 3.2 and iOS 4, again, our coverage is significantly improved, and again, this comes back to expanding the circumstances in which you can locate your user. The closer we get to making location ubiquitous and always available service, the more circumstances you're going to be able to improve the experience for your users. That's really our goal. The other thing we've done with Wi-Fi positioning goes back to, again, this case where you don't have a data connection. So we take a look at this map here, the center of this map is the Moscone Center.

So, let's say I'm here, I've got my iPod touch, I go and get my position I want to see what coffee shops are around, that's great, but as soon as I leave the Moscone Center, I lose my data connection and I lose the ability to lookup Wi-Fi hotspots.

So, what we've done is we've said, well, sure, we'll download the position of the Wi-Fi hotspot you're currently on, the ones that you can see, but what's also down on the position of Wi-Fi hotspots in the radius around your current position. And so in this case, I'm at the Moscone Center the server will go and download the location of hundreds of Wi-Fi access points that cover a several block radius around the convention center.

So, if I'm going down the street, you know, I'm going finding a place to eat, I'm going and checking out different places, my device will solely be able to locate me because of that information that it downloaded at a time that I had a data connection and this is a high-intensity environment. In San Francisco, there are a lot of Wi-Fi access points because there's a lot of people. If you take a look at a lower density environment, this is just inside of Halfmoon Bay; it's on the coast, nice place. I'd recommend visiting.

Again, if you're in a coffee shop you get a position, then we download Wi-Fi hotspots and they cover the entire area so no matter where I am I can get a position without a data connection. It takes this device so you may think, well, it only has data in certain areas, and it makes location more ubiquitous. Again, going back to this idea that we want location to work all the time. That's Wi-Fi positioning. The last one is GPS.

Now, the iPhone 3G and the iPhone 3GS both have GPS receivers. So, does the iPhone 4. What we're really excited about is that the iPhone 4 includes a new GPS receiver that has significantly improved performance in a variety of ways. Now, again, performance means multiple things. And so I'm going to focus on three ways that the GPS receiver in iPhone 4 and, again, it's also included in the iPad as well, I should make that clear, improves on the receiver, the iPhone 3G and the iPhone 3GS.

The first one is what we call acquisition sensitivity, and in plain terms, that means when you can get a GPS fix. Because the receiver is more sensitive, the GPS receiver on iPhone 4 will get a fix in more places. In challenging environments like dense, urban canyon environments, when you're say kind of indoors but maybe you can still see some satellite signals, the GPS in the iPad and iPhone 4 get to position in a much wider variety of circumstances and when it does get a position, it's more accurate. The error between where the user actually is and the reported location is significantly smaller. So just to give you a relative idea of the differences in positioning, I think this chart kind of tells the story.

In our drive test, the receiver in iPhone 4 has been up to three times as accurate as receiver in the iPhone 3G and the iPhone 3GS. That means that the error is only one-third of what it was with the old receiver. So that's a second way to compare performance, but the third way of comparing performance goes back to something I talked about earlier. It goes back to power.

You just want to use your location where application but they're really conscious of battery life. It's something that we take, that we do a lot of work to maintain. And so that's really exciting is that this new receiver uses significantly less power. In a lot of cases, one-third of the power. And this chart here shows tower during acquisition when it's trying to get a signal. In favorable signal environments when you've got an open sky, the new receiver has a little power mode where it uses even less power.

Now, just as a cautionary note here less you think that we've solved the problem of GPS power consumption, there's still a significant difference between GPS power, Wi-Fi power and cell power. Cell is almost free, we just have to do the lookups; Wi-Fi we pay a little bit more for the scans, but it's still relatively cheap; GPS is still more expensive, but the receiver in iPhone 4 we think really improves the user's experience by conserving battery life.

The last thing that I want to talk about with regards to improving GPS performance is sensors. As you heard about at the keynote on Monday, iPhone 4 includes a gyroscope and while the use case shown there was for games, it turns out that the gyroscope along with the other sensors on the device, the accelerometer among others, is really useful for kind of cross checking the information that we get from the GPS.

So, I want to show you this plot from a recent drive test we did in downtown San Francisco and it's important to keep in mind this is a really challenging environment. You've got high density, you've got buildings, you've got multi-path interference, you know, from signals arriving kind of, you know, bouncing off buildings and so forth. So this is a challenging environment for GPS, but it does pretty well. It has us on the road, it detects the turn. One of the things to note about this diagram is the direction of the arrows is the course information.

It's the direction of the GPS thought that the user was heading, but by making use of sensor assistance, we're able to correct the position. You'll notice that the new position stays on the road better, but it also detects the turn a lot better as well. It can detect, you know, as a turn is occurring, and it comes out of the turn with better positioning as well. A couple of notes about this; there is an additional cost associated with this.

We need to have those sensors running, we need to run the algorithms that take the sensor information and, you know, correlate it with the GPS to improve it. So, there is an additional cost. It doesn't come for free, and as a result, it isn't enabled by default. We think it's useful primarily for the vehicular navigation cases where, you know, you've got high speeds, you know, driving is a good example.

I'll show you how you can enable this in your application later, but it's another way that we're making GPS more powerful. So, those are our three technologies and that's how we've improved in the past year, and we're really excited about this. We think that it just opens up a lot more potentials where location is a possibility where it wasn't before.

So, enough with, you know, the high level, how do you use it? How do you make your application location-aware? So, a few things I'm going to talk about I'm going to talk about the primary components of our framework, the pieces; how they fit together to request and receive location updates; how to configure location manager to tell it what type of location you need, what accuracy, things like that; how to handle errors; how the user gives it permission in order to use location; and some best practices for using location services on iOS.

So, as for the components, it's pretty simple. There's, you know, on the base level there's your application, which you're going to have some delegate object that interacts with the framework, and you've got the framework itself and inside the framework the main object that you use to request location services is the CLLocationManager object.

You'll create one of those, you'll set your delegate object at its delegate, your delegate needs to implement the CLLocationManagerDelegate protocol and then in response, the location framework will send what are called CLLocation objects, either data objects that give information with the location back to your delegate and callbacks.

So, the first thing you do is you create a CLLocationManager, you set a delegate and then you call the startUpdatingLocation method on it. This doesn't take any parameters, it doesn't return anything, it just says I would like location updates. Updates are fully asynchronous. It's an asynchronous API and so when the framework has a location and it's determined the position, it will call the locationManager:didUpdateToLocation:fromLocation: delegate callback.

It will call back each time a position comes in and so you'll get these callbacks repeatedly as the user moves, as the framework determines more accurate positions. Now, the location manager is configurable. There are a couple of different ways that you can tell it more about your use case about what type of accuracy you desire and so the first thing is the accuracy. It's what is, kind of how precise a position do you need? And this is measured in the estimated, the difference between where the user actually is and the position that you receive that you're willing to accept. So, this is in meters.

The default is best accuracy, but there are also constants for ten meters, hundred meters, kilometer accuracy and things like that. There's also a special constant that says best and then also enable sensor assistance as I talked about earlier. It's important to set this to a value that makes sense for your use case because, again, if you say you want the best accuracy position possible then the framework is going to go and turn on ever positioning service it has available and, again, so you're paying the cost for all of those services. So, if your application can really get a good position with Wi-Fi positioning, then set it to say, you know, a hundred meters if that's the accuracy that you need.

The second thing that you can provide is a distance filter and this is useful for applications that want to know when the user moves. Maybe you don't need to know, you know, right away, you don't need to get a callback every time they move a little bit. If you're just kind of keeping those callbacks and that's a waste of CPU time, it's a waste of system resources and so by specifying distance filter you can say, well, only tell me once the user's moved a hundred meters or only tell me once the user has moved 500 meters.

One thing about the distance filter though is that let's say we have a 500-meter accuracy position and then all of a sudden we get a 100-meter accuracy position, the framework will tell your delegate object about that new location even if the distance filter has been met, even if you haven't moved that far. That allows your application to make sure of the better location information even if you have a distance filter set.

So, you can set this and still be confident that you will get the best positioning information that the location manager has determined. One other note is that you may want to check to see if location services are enabled prior to calling startUpdatingLocation. I'll talk a little bit more about that later.

Now, Core Location would always be able to determine your position and there are two main errors, there are other errors as well, but these are the two big ones. The first one is Location Unknown, and very simply this just means that the framework couldn't determine your position at that time.

I'll talk a little bit more later about how to handle this, but in brief you should call stopUpdatingLocation in response to this error because if you don't, the framework will just keep spinning and spinning and spinning, trying to get a position, but if the user's environment hasn't changed, you know, things are unlikely to, you know, to suddenly change and it'll suddenly be able to locate you. The other one which I'm going to talk more about on the next slide is CLError Denied, and this means that the user is denied location services authorization for your application.

So in what circumstances does that happen? Well, the first time that you call startUpdatingLocation, the system will pop up a dialog that says that your application wants to use the user's location and these are two choices, OK or don't allow. As of iOS 4, this dialog will only appear once, the user has to make a decision, and the decision sticks. Yes means yes; no means no. So, as long as they get to the dialog once, they won't be prompted again unless they, unless they reset location warnings.

So, one thing to note is this purpose property. So this is new. This allows you to tell the user why your app needs to use location services. You may notice that the camera, for example, uses this to tell users that it wants to GEO tag their photos and videos. That's something really useful, but it's not something that I would think of the first time I'm opening the camera app.

So, if your use of location is maybe not intuitive, it's not something that the users would think of right away, this is especially important, but we think that all applications can benefit from providing this information to the user. This is a property that you set on CLLocationManager. And the last thing is the status bar icon.

This icon will show up whenever any application on the system is using location services as the user's indication that their location is in use, but the user has to make that initial decision, but they can change their mind as well. So, the location services enable switch has always been available.

It's allowed the user to say I don't want any applications to use my location or, yes, enable location services, but in iOS 4 we've added the capability for the user to indicate on an app-by-app basis which applications should be authorized to use location services both in the initial pop up but also after the fact.

One thing to note is that the location arrow, the same one that would normally appear on the status bar, will show up next to any app that has requested the user's location in the past 24 hours and it's designed to give user indication of what applications have used their location recently. And then the last thing is the location services enabled switch for that application.

One thing to note in a multi-tasking world is that if the user flips that switch to Off while your app is running, you will get the CLError denied error from the location manager even if you had previously had been getting positions. So, as soon as that switch goes, your app basically gets cut off from location and that sticks until the user changes their mind. A couple of best practices. Going back to what happens if you get that unknown error, Core Location couldn't locate you.

You really should call stopUpdatingLocation in response to that error. If the user is in a subway tunnel they're, you know, underground somewhere, they're in a parking lot in an underground parking garage, they're in an environment where the situations aren't likely to change immediately and so the, I guess the return for continuing to get location services isn't that great in comparison to the power cost. So, what we recommend is the call stopUpdatingLocation and set a timer for some amount of time out, and try again later.

At that point maybe the user's environment will have changed, conditions will have improved, and will be able to determine their location. And a similar thing goes if your app really wants a certain accuracy of position. If you really want, you know, 50-meter accurate position, but all you're getting is 500-meter accurate position, you know, after a certain amount of time, after a minute or so, something like that, you know, it's unlikely that in this current environment that that precision of location information is available and so you should stop and, again, try again later.

Make use of the information that's available and then try again at a later time. And then one last note is to consider using MapKit. MapKit is a framework that makes it really easy to integrate maps into your application. With only a few lines of code, you can also make your map location aware just by setting one property it shows user location property.

MapKit will take care of using CLLocation, Core Location, under the hood to determine the user's location and display on the map. It's customizable; you can use Key-Value Observing to get the location that's determined. So, if this is an option to your app, it makes things a lot simpler. So that's the third thing that's how to use location services on iPhone OS.

Moving forward. We made some really great enhancements to location services, but what I've talked about so far are things that were available on previous versions of iPhone OS, but with iOS 4, we've really stepped it up. In a multi-tasking world, we want to move closer and closer to this idea of always on location, of ubiquitous location.

Applications that are location aware all the time that users can be confident that, you know, no matter what they're doing that your application is working, that it's providing the service that you've advertised for them and so I'm going to walk through a few use cases where the enhancements that we've made in iOS 4 really open up new possibilities. So the first one is running.

So, I'm a runner, I'm training for the San Francisco Marathon next month although, you know, the iOS, the push to end of iOS really didn't help my training, but I'm still hoping to do it, and I like to use my iPhone to track my runs. I want to, you know, it runs on GPS and as a result it knows kind of how fast I was going, different points of the race, how far I traveled, things like that, but say I get a quick phone call while running, hopefully not too long because I'm kind of out of breath or, you know, I quickly switch over to another application, I really want my app to keep updating my location.

With previous versions of the OS, the application stops as soon as you exit it and location stops, but what I really want is I want the position to continue updating no matter what I'm doing. My desire is to have the same experience with this application whether it's foreground or background.

So, we've added in support for what we call continuous location applications. Applications like RunMonster here that they really want to provide the user that same level of location experience regardless of their state and using this is really straightforward. You just have to add this one key to your application's info P list, it's a configuration file that you set, by adding the user's location background mode once that's set, if your application is using location services, if you've called startUpdatingLocation and then your app goes into the background, it will continue to run in the background as long as you're still requesting location updates. So that means that you can still continue to track them.

Now, we recommend that you, again, even if you're in the background say you're doing a turn-by-turn nav app, something like that, they reached their destination, turn off location services, you know, it's done. It's still expensive so, you know, again keep the user's use case in mind, but for situations where the runner still wants this information, the user really wants that information, you know, regardless of where they are in the system, this is a great solution that enables these types of applications and it requires very little work on the developer's part.

However, there are some situations in which I don't, you know, I don't want to incur the cost of having, you know, high precision location services like GPS all the time, but it would be really great if my applications knew kind of approximately where I was at any given point in time.

So, let's say, again I'm going on a trip, I have an app that say allows me to, you know, write entries, you know, annotate where I was, you know, I want to write an entry that I was at the Golden Gate Bridge, I was at, you know, the Museum of Modern Art, and here's what I thought.

Well, it would be really great if my application knew where I was throughout the day and said, oh, yeah, you were about at the Golden Gate Bridge, you were about there, and put those together and maybe reverse GEO code them for me so, you know, it gives information, and I can annotate those.

Well, if that app has to use GPS, then my battery isn't going to last the day, but if we could use things, say cell positioning and detect when the user has moved a relatively significant distance in order to, you know, and then kind of track their locations at that point in time, that's a much lower cost solution. It's one that then, you know, more adequately balances power versus utility. So, the way this works is the significant location change API and it detects when a device changes cell towers.

And so whenever the device changes cell towers, the framework goes and says, well, has user moved a significant distance? And if it has, it notifies your application of the new location in the background. So, even if it's not frontmost, even if it's suspended, it will wake up your applications so they can deal with this new information and take whatever action it needs to in response to it.

So, again, this uses cell positioning so you should expect location precision in accordance with that. So, again, it will tend to be better in urban areas and more error in rural areas where the distance between cell towers is greater, but in general, you know, intermediary is 500 to 1,000 meters would be something reasonable to expect. One other nice thing with significant location change is that if another application in the system is using location, so say they have a turn-by-turn nav app open and a more accurate position is available, your application will get that application for free in a sense.

You move, every 500 meters that the users move we track based on GPS they move that far, your application will get woken up as a result of that. So, it makes use of the best information available in the system, but if no location where applications are running, it will use cell positioning. Now, we've created a demo app that makes use of this functionality, and I'd like to turn it over to my colleague, Jay Bruins, to give you a demo of it. Jay?

Thanks, Morgan. So, I often wonder when a song comes on the radio or something like that, hey, where was the last time I heard that song? And so I wrote a simple app using iOS 4 and it's a location change API to basically record my location and when I do it, just go ahead and also record what actual media is playing on my phone at the time. So, as a result, I can actually travel through the world and kind of get an idea for, you know, what I was listening to where.

So, it's relatively straightforward app. I'll start up here in the flip-side view, and you see that the user has an option to turn on location. Turn on location. As soon as that happens, you'll go ahead and get the notification with the purpose string explaining that, hey, this is going to stay on in the background, I'm going to keep track of you basically until you turn me off.

So, the user hopefully hits OK because I've given them a clear expectation for what I'm doing and then they can go back into the map view. And so here you'll see that I've got a simulated trip going down 280 and back down to Apple Campus from San Francisco, and you can get an idea of kind of the couple of positions of pins that you would get and so each one of these, you know, is hitting, it's simulated so it's right now, but you get access to the whole location stuff, it's standard callback, but it's a little bit coarser than, you know, you might be used to, but it's really simple to wire up. I carried this demo application around in my phone for a week and didn't really notice any drain on battery life. It was really simple to do and it was a great experience so.

All right. So how do you integrate this into your application? This slide probably looks familiar. It's a slide I put up when I talked about how to use regular location services. At a basic level, all you have to do is replace this call to start updating location with one that's called startMonitoringSignificantLocationChanges.

That indicates to the framework that you want to use the significant location change service, and then as a result, after you call that, you'll get the same location manager didUpdateToLocation:fromLocation: callback whenever one of these significant change events occurs and that's true whether the application is in the foreground, whether it's in the background, if it's displayed in the background, it will be resumed in order to handle the notification.

And so just by making this one change, your application can take advantage of this API. We'll be posting sample code for both this demo and the one that's coming up later today so you can take a look at this for yourself. It's only a few lines. Let's say I have an application where I'm really only interested in, you know, certain locations.

It's great if I know every time a user moved, but in most cases there's only one spot that, only a few spots that are really important to my application. So, just to give you a scenario, if I've got something at the dry cleaners I need to go and pick it up, well, I'm kind of forgetful, I've got full days, and I just keep forgetting to go and pick it up. It would be ideal if I had an application that could tell me, hey, you're close to the dry cleaners, pickup your suit.

Now, if I were to use the significant location change service, then my application would have to, you know, get every position and say, all right, how far away is he? How far away is he? Is he close? Should I notify? When am I going to get another notification? But it would be really nice if there's a way to just say, all right, I'm interested in this position with say this radius around and when the user gets close, notify my application so I can take advantage of that information, take whatever action I need to do.

What we have done to enable this sort of application is to create a new service that we call the region monitoring service, and the way that it works is it works in a very similar way to significant location change, you know, we still detect when we change cell towers, but when we get on a cell tower that we know is close to something that you're interested in, in this case a coffee house, we then notify you in that case and only in that case. Not whenever we switch cell towers, not whenever you just move a specific distance, we'll notify you only when the user is close to locations that your application cares about. So, you get notifications both on entry and exit.

Again, it's based on cell positioning so expect that sort of accuracy and one other thing that's important about this API is that it takes advantage of some new functionality in the baseband software of IPhone 4 so this is currently an iPhone 4 only feature, but for users that have that hardware we think that this makes it really easy for your application to get, to kind of focus in on the areas that are important to it rather than kind of getting woken up constantly. You only get notified when you get close to a region that is important to your app. So, we built a second application that, again, takes advantage of this functionality and, Jay, take it away.

Thanks, Morgan.

So, I wrote a quick app called the Reminders app that will basically help remind me to do things based on my position. So, for example, let's say last night I got a little crazy and my shirt got dirty and I dropped it off at the dry cleaners, but I want to remember that, you know, when I'm on my way out of the city that, hey, I should probably go pick this up. So, what I can do is I can drop a pin that gives me an opportunity to create a new reminder, I go ahead and open it up, and go ahead and say, you know, something like pickup my shirt.

And so what that allowed me to do is when I enter or exit a region around this pin, it'll give me a notification. So, let me go ahead and leverage the fact that when I exit it, I'm going to go ahead and do it and I'll just change the radius of the pin to something relatively large because I don't really care if I'm hanging out tonight, but once I actually go to leave the city, I will care. So, now I've got a relatively large pin, I've got a relatively large, sorry, relatively large area, I can move it around to some other place if I want to be more specific and as a result it just writes it out to Core Location.

If you tell Core Location about this, the app can quit, you can spin it up and you can actually query Core Location to get all of the locations back and you can associate it with your own app data and start displaying stuff again. It was really easy to do, and it just, you know, takes advantage of this. So.

All right. Thanks, Jay. So again.

As Jay mentioned, most of the code involved in building this app was to get the stuff around it. The actual code that coordinates with the location service is surprisingly simple. So, the first thing you need to do is to create what's called a CLRegion object.

A region is defined by three things: by a center, by kind of a center point; by a radius, which is kind of a distance around that center which you kind of want the boundary to be; and then an identifier so you can refer to it later. And once you've created the CLRegion object, then you call startMonitoringForRegion on your CLLocationManager while, in fact, you're passing that region and then when the location service detects that that region has been entered or exited, it calls the appropriate callback on your delegate object to deliver that event. Again, this happens even if your app is in the background, even if it's spinning it will be resumed, and you can take whatever action you would like to in response to that notification.

Now one other thing that's really advantageous about these two new service both of them is that they will actually launch your application if it isn't running. So, if your application got killed say because of memory pressure or the device restarted and the user hasn't run your application yet, then if one of these events comes in, the location service will actually launch your application and to explain this I think it's helpful to take a larger system view.

So far I've been talking about the Core Location framework, but in reality the framework is actually communicating with the service that runs outside your application's address space in its own process. And so that even if your app goes away, that location service is still running, it's still tracking location and can still locate the user and determine when events happened.

Now when an event does come in, so let's say you're using significant location change and it determines a location, the location service will tell it, will ask the system to relaunch your application in the background in order to respond to the event. Well, there's still one piece missing.

In order to deliver the event, your application needs to create a CLLocationManager that the location service can communicate with to deliver that event to your application. So, when launched in the background your application needs to make sure the location manager gets created and then once that's done the location service can pass the location off to the framework to the location manager object which can then pass it to your delegate.

Now, because your application is getting launched in the background, it's worthwhile to go back and talk a little bit about the model view controller paradigm on which iPhone OS applications are based. Generally you've got, you know, your model, which is your data store, you've got your view, which is how it's displayed onscreen, and you've got your controller, which kind of works between the two. It takes data from the model and displays in the view, responds to events in the view, things like that.

Now, what we've seen in a lot of applications is that the location manager is actually a part of the view controller. Maybe the view controller is a delegate or you've got some object that's hanging off the view controller, but when the application is launched in the background because it's not onscreen, the view hierarchy doesn't get setup and so if you create a location manager as part of your view hierarchy, as a part of a view controller, it's never going to get created and as a result, you're never going to get that location event. So, you really need to make sure that in case, in this background launching case, that you create a CLLocationManager location manager and you configure it so it can receive the events.

So how does this work? One of the first things that happens after an application finishes launching is that the app delegate object gets the application didFinishLaunchingWithOptions callback. Very appropriate. And one of the things that's passed as a part of that method call is a dictionary called launch options and in the case where your application was launched because of a location event, the system will pass the UIApplicationLaunchOptionsLocationKey as a part of that dictionary. That's your signal that you're launched because of a location event.

However, it's not always wise to key off of that. If you started, you know, kind of background location services that you want to keep running even for user launcher applications you still want to start those up. So, while it's useful to know that you were launched because of a location event, you can still setup your location services kind of regardless of that key. It's kind of there as a heads up. What you really need to do in this method is to ensure that a CLLocationManager object gets created.

So, in my example here what I've done is I've created a, I have my own object that I'm calling MyApplicationController that takes care of location services for my app. I knew to make sure it gets instantiated and then as a result of that instantiation, it's going to go and create CLLocationManager and configure it. So let's take a look at that.

So in this object init method, we're going to, you know, call super init and then the first thing we're going to do is create a CLLocationManagerObject. We're going to set ourselves as a delegate so it has some way of delivering events and then the last thing that's important to do if you register for the significant location change service, is to, again, call startMonitoringSignificantLocationChanges.

That tells the framework that it's that location manager that's interested in receiving significant location change events as opposed to, you can actually have more than one location manager in your system. So you need to call startMonitoringSignificantLocationChanges on it again and then in response you will get the same location manager did update your location from location callback even if your app is in the background.

If you're registered for region monitoring, then there's no setup like this. You don't need to call start. It will just call your delegate callbacks immediately after being created if an event has occurred. So that's a lot of stuff. There's a lot to be added, there's a lot of things to think about. So I just want to summarize by saying that location is important because it provides context. It makes your applications more intuitive and easier to use by breaking down the barriers between the users wants to do and the steps they need to take to get there.

By taking advantage of this context information, this location information is already available you stay one step ahead of your user. You can customize your application for where they are and that's pretty powerful and you can also enable new use cases. We're just starting to scratch the surface of what location is capable of. We're seeing a social location services and I for one am really excited to see what's coming up next, but it's really important that you use the appropriate technology for your use case.

Users are going to trust location services most if the applications that use it are respectful to their system resources, that they use location in the ways that they say that they will, and in order to surprise and delight your users you need to keep that in mind. You need to provide a compelling user experience and be respectful of their resources. So for more information we have a wonderful evangelist, Mark Malone, who would be more than happy to answer questions. His contact information is there. We have some great documentation as well. The Core Location Framework Reference is your first stop for location information.

There's documentation on every method in the framework as well as Location Awareness Programming Guide, which gives a high-level overview of all of the location related APIs available on iOS, including MapKit, and how they fit together. So take a look at those and then, again, the dev forums. The developer forums are a great place to help each other, to get information, there are also some Apple engineers that contribute from time-to-time as well.