Hi everyone. Welcome. My name is Patrick; I'm an iPhone Engineer on the Core Location team. Today I'll be talking to you about Finding Your Place with Core Location. So why location? Well, location is really compelling because it's not just about navigation. It allows us to find and visualize information in a geographical sense.

Now, as I was preparing this talk I was going to put some samples together of how you can use location services, but we've offered location services on the iPhone for the past year, and really I thought it would be cool just to actually grab some of the examples on my own phone and show you some of the great things you've done.

Because really you've pushed the potential of our technology. Yelp . Yelp uses location to allow you to find nearby venues and restaurants so you don't have to walk around hungry anymore. Brightkite. Brightkite uses location to geotag a specific spot. Now a geotag is a message of a picture that you could leave virtually at a location, and someone else with that App could come to the location and see that message like oh Patrick was here yesterday and had Cappuccino.

I think I'll try that out. Indie Bound uses location to help you find that nearby bookstore so you can pick up the title you've been looking for. Geocaching. Geocaching uses location to help you go on a little treasure hunt with friends and find that geocach or that hidden item in your neighborhood.

You could also set up geocaches for others to find; so that's pretty cool. And of course during the campaign you could use the Obama app to find nearby political events. Lastly, Tweetie. Tweetie uses location to allow you to update your Twitter page and look at nearby Tweets. So these are all fantastic examples and there are thousands of other apps on the App Store that really use location in unique ways. Actually I was at the Smule talk during lunch yesterday and they were showing some really fantastic pieces of location.

For instance the Ocarina app shows using location in various places around the world. So the underlying technology that actually makes this all possible is Core Location. Now that's a Framework for both iPhone and iPod Touch. But this talk is also addressing one more platform and that's Snow Leopard.

So it's really exciting now that we have location technology on the Mac. So I'll be talking about this API for both of these platforms today, and if there's something that's very specific to a particular platform; for instance iPhone versus the Mac, then I'll point that out to you just so you are aware.

And if you are planning on writing on that cross-platform location app, do review the documentations; the API is similar but there are some minor differences like one method name is different. So please, if you're going to write that cross-platform app just make sure you check out the information that's available.

So how does Core Location work? Well Core Location is really unique because it abstracts all the location technologies on the device. This is both Mac, iPod Touch and the iPhone. And what makes this really unique is that since it abstracts this technology you could use the same API on these different platforms and still achieve what you're looking for.

So for this example, I'll be talking about iPhone because it has the most location technologies available. The first being cell positioning; iPhone can use the cell towers around it to determine where it's located; iPhone can also perform a Wi-Fi scan to look at the neighboring Wi-Fi networks and use that information to determine where it's located.

And of course iPhone has GPS. So it uses all these technologies together. Now, this is actually information that you're possibly already familiar with because this is what we were talking about last year. So what's new? Well, we thought about what we already had available on the device, and that's the accelerometer. Now what's unique about accelerometer is that it actually can give us some information about changes in force. So what we can determine from that is looking at accelerometer we can tell if we're very still or we can tell if we've started to move again.

So what's unique about this is we can tell if we stopped moving or started moving. So, you might be familiar with a pedometer app in the App store. Pedometers allow you to track how many paces you've walked, and can tell you how many feet you walked just by observing and monitoring accelerometer information.

So we kind of do the same thing but we do it to aide the GPS and the location technology. So what that means we can better track you and try to prevent cases of overshooting. So this is something that all devices will get for free with iPhone 3.0 so we have better tracking.

And of course we have a new sensor and that sensor is Compass. So Compass is a new service in Core Location and it provides some advanced features that actually use location technology which I'll talk more about later, and Compass actually does the same thing as the accelerometer and assists in tracking for turns.

So all of these technologies together really make Core Location unique; because of this unified framework that combines all of these various things together in unique ways to complete one another. So, Core Location provides us unified front and that's what I'll be talking about today. So, let's talk about the location portion first in more detail.

So finding your location in your app. So your location is your geographic position which includes latitude, longitude and altitude. Now we accompany that information with an accuracy value and this accuracy value is very important. The reason for that is because these different types of location technology have different types of precision; so with these different types of precision, for example, a cell position might be a little bit rougher than a GPS position.

So this accuracy is something that you should really pay attention to; and when you're designing your location app it's something you should keep in mind for the use case of what's appropriate for your app. So I'll be talking about all the various types of location technology from least precise to most precise. When I go through these, think about what accuracy or type of location is valuable to your app because there are tradeoffs for having a more precise location than a less precise location.

So if you're writing a weather app for example, you might not need to know the exact street that the device is on. For example, you could just know that oh I'm in this neighborhood so that's the weather in that region. So let's start talking about Cell. Cell gives you a position between 1 - 3 km; it's extremely fast to get this type of position because an iPhone is already talking to the cell towers and already has that information available. So it's extremely fast which means that it can actually calculate this position pretty quickly.

So it takes less power. Now, we have actually on 3.0 added a second tier of cell positioning but the API is still the same; and that means if you're in a less dense cellular area and you can't get a 1 - 3 km fix, we could at least give you a 12 km position.

So, we've done this by design and you're probably thinking well why would I need something that rough? Well, it can allow you to start pre-fetching information for a geographic location. And by pre-fetching information that's particular to your geographic location, as you continue to improve that measurement and wait for that better location information to arrive, then you have something that you could display to the user and not take the user's time so much. That's pretty cool.

And we have Wi-Fi positioning. Wi-Fi positioning is within 100 m. What's very unique about Wi-Fi is this the only location technology that's on Snow Leopard. So what the device does in this type of scenario is that it will scan all around looking at the neighboring Wi-Fi networks, and it will look at those Mac addresses; it takes the Mac address information and it will send it to a server. And that server will do some calculations and send back to your device some particular information on where the device is located. So, this is a slightly longer process than Cell, so it means it takes more power.

And so this is something you have to think about to yourself-- OK do a need a 100 m accuracy versus the cell positioning which is 1 - 3 km so it's just something to keep in mind. Another good point about Cell and Wi-Fi is that both of these technologies work really well indoors. So, you can definitely get a fix with one of these types of location technology.

Also these technologies will send you a location update when it's been calculated. On the contrary until the next technology which I'm going to talk about which is of course the GPS. So the GPS will give you a position under 40 m and that position is given to you in heartbeat update-- meaning it comes at a very frequent rate.

So, because of this and the GPS uses different types of hardware, it actually is more power intensive. But it does accompany the location information with a little bit of more data which is the speed you're traveling at and the course which is the direction you're traveling. So, all this is pretty useful; and again if you're thinking about the use case for your app, you have to think about what type of accuracy do you want to achieve? As Core Location will use these technologies in the background to come up with the solution that you're looking for. So, as I was saying, it takes a while to calculate depending on what type of accuracy you're looking for. And this is the user's time we're thinking about because they'll be looking at their app as it's trying to determine and measure your calculation.

So, if you have a more precise location what actually happens is that you're given a rough location, and then as the device is calculating your next location, it's trying to refine that measurement in that position. So it's giving you location information and closing in on that accuracy that you're looking for. So, if you're taking more time that also means that it's consuming more power so you do need to be aware that when you're using a location technology, you're definitely using more power on the device so it's just something to think about.

Let's talk about how this actually works in your application. As you can see here, we have two primary components-- you have a controller in your application that will receive notifications from the framework and then of course you have the Core Location Framework. Now if we zoom into these two components we have these classes in this breakdown which I can talk to you about. So, the controller in your app will implement this protocol.

It's the LocationManagerDelegate protocol and that means it can implement some methods to receive these notifications. In the Core Location Framework itself it has the LocationManager. Now the Manager is really important because that's where you can configure the type of locations you'd like to receive, and it lets you turn on this location engine which will start providing you with location updates and using power; and also when you stop it, it will stop it from sending you location updates and stop using power.

So, that location information and directional information is actually provided by these two gray boxes-- the location object and the heading object which I'll talk about a little bit later. So these are kind of like the overall views of the two primary components. So before we actually start requesting location information, we have to specify that desire to accuracy.

Now remember we talked about the tradeoffs, about the more precise accuracy, the more time it will take and the more power it may consume, so this is where you actually specify that. So you tell the desired accuracy how precise of a location you desire. And once that's configured, we can call startUpdatingLocation. So immediately this will start consuming power because the Location Manager is hard at work trying to calculate that measurement. Once that it starts calculating those measurements it will send those location objects to your app and through the delegate callback.

And that will continue until you have received the Location Manager object that really fits the needs of or the use case of your application. So once this has happened, you simply call stopUpdatingLocation and stopUpdatingLocation will take the Location Manager to stop working on the measurements and you can start conserving power again so this is very important. So you may be thinking to yourself OK I can start and stop this engine to receive all this location information.

Well, that does control the frequency or rate that you receive the location information, but there's also another type of configuration that I'd like to tell you about and that's the distance filter. So the distance filter does save you a little bit of power in terms of IPC. What this does is it actually tells the device OK don't send me a location update until I've actually moved a particular distance.

So once a device is moved that particular distance, then it will send you the location update. So this is another way you can control how frequent notifications are coming to your app. That's pretty unique. So we've talked about how to use location technology now; let's talk more about how to make the most of it. So there are some pretty unique points that I'd like to share with you in order to make the most of this framework. So for efficiency, Core Location may cache location objects; but depending on the use case of your app, it really depends on your intentions.

You should actually check the timestamp for these location objects before using them; because you don't want a user to see an older location than what's necessary for your use case. So my first recommendation to make the most of the Core Location is to really check that timestamp and make sure it fits your use case. Another viewpoint to take is location privacy. So some users don't want to use location services or may not want a particular application to use location services. And for that there are two dialogues and this is both for Snow Leopard and for the iPhone as well.

So this is presented to the user until they accept or they can push "Don't Allow". What "Don't Allow" means is that they do not desire to use the location services. I do recommend to you that if they do push "Don't Allow" to provide them with some type of use case for your application.

For example, maybe it means to enter in a zip code. So, this dialogue gets displayed as soon as you call startUpdatingLocation. And you won't receive location measurements until the user pushes OK. You should keep in mind that there is a global setting for both Snow Leopard and the iPhone as well. And that global setting is a setting that allows a user to decide if they should use location technology in general.

But what I'd like to point out to you that if the user doesn't use location technology, we should really understand that and instead of calling startUpdatingLocation, we should check to see if they have that switch off; because we don't want to bother the user with dialogue boxes and messages.

So I recommend checking out the Location Manager's property and that's locationServicesEnabled, so check that property before calling startUpdatingLocation just to save the user who may not desire to user location services; and they'll get a more pleasant experience out of your application. So, it's important to think about error handling too; and error handling is you'll receive NS errors through the same delegate callback system that I had described earlier for location objects. So you'll implement a delegate callback and that with that delegate callback you can receive these errors.

And there are only two types of errors you should worry about: The first one is error denied and that's when the user pushes that "Don't Allow" button. So you'll receive that delegate callback with that particular information. And we have location unknown. Location unknown is an OK error. It basically means that location services are hard at work in the background and that you'll receive a location pretty soon so just hang in there it's working on it.

So these are two types of errors that can occur. I'd like to talk to you a little bit about power saving. As I said before starting and stopping the Location Manager-- actually when you call start, you start consuming power; when you call stop you stop using power. And if you take anything away from making the most of the core location of these points that I'm telling you, I find this one to be very important.

So if the user is using their device in an area that's very hard to detect, they measure their location, then that desired accuracy you requested could not be reached or may not be reached for a great period of time. So, the core location is hard at work, it's closing in on that desired location giving you more and more location information, the desired accuracy is closing and closing in and it's not quite reaching that desired accuracy you specified originally.

So what this means is we recommend setting a timer just as soon as you call startUpdatingLocation. So when you set that timer, it will start ticking down and if that timer expires before you received the desired location of your choice, then just simply call stopUpdatingLocation and use the information you've already we received.

So we recommend doing that to conserve power. Another point with regard to conserving power is you receive the LocationUnknown. So for example, if the user disconnects their external GPS or if they're using their Mac and they move out of range of a Wi-Fi network, you should call stopUpdatingLocation when you receive that LocationUnknown and start a timer. And what this means is basically you like to wait out this period of difficult environment to calculate a location.

So as soon as that timer has expired, you can call startUpdatingLocation again and start hopefully receiving measurements for that new environment that the user may have moved into. So this is just a tip or a pointer that you can use to deal with some of these environments that might be difficult to calculate a location in.

So, that's the first part of my talk where I focused on location technology. So we talked about the desired accuracy that you need to specify and how important that is because it depends on the latency-- how long it takes to get that location, and how much power it takes to get the precise location that you're looking for.

We talked about some of the basics-- the API, and we also talked about how to make the most of the framework to really benefit your app; such as looking at those timestamps, understanding the user's privacy and trying to avoid prompting them with a dialogue if they've got location services turned off and things of that nature.

So let's talk about Direction. So what is important about Direction? Well, Direction is definitely a means to assist in navigation. And aside from navigation, it's also very interesting to view information in a directional sense. So I'll talk more about both of those points today and I'll also talk about a couple different ways you can get directional information from iPhone.

And the first, many of you have probably already used, that's course. So course is actually the direction you're traveling in. So if I'm walking across the stage this is the direction I'm traveling in. This is provided to you in the CLLocation object and that's calculated based on your path of travel.

So you have to be moving for this to happen. Now some of you might have written apps that uses technology already, and you may notice that for example if you have a Compass app in the car and it's using course and you turn it, it's still giving you the direction that the car is moving in. Well that's why we have Heading.

And Headings was provided by the new magnetometer or the Compass in iPhone 3GS. So this is available even when you're stationary so you don't have to be moving for this to be calculated. And it's a direction just like course -- 0 to 359o. And what's unique is a heading is the direction you're facing. So if I'm traveling backwards, my course is this way; but I'm facing this direction which is my heading. So these two points can be different; so that's just something to keep in mind.

So let's talk more about Heading since it's new. In iPhone 3GS we have a new sensor and that's the magnetometer and that provides a heading information. So what that means is that it gives you a direction to Magnetic North; and what's really cool about this is the device actually can give you that direction no matter what orientation you're holding the device in.

And we also provide these X, Y, Z values that represent the vector or the magnetic line that's pointing toward magnetic north. So that's available through the API and actually I'll show you a little demo about this. So, how does this work exactly? Well, the magnetometer aligns itself with the earth's magnetic field.

And the earth magnetic field is this physical phenomenon surrounding the earth and it's slightly different than what we're used to. What we're used is the North Pole; and that North Pole is True North. Cartographers when they drawn maps usually reference their map based on the North Pole or True North.

So we have this difference here. We have all compasses that show this magnetic direction and then we have True North which is what maps you. So if we're comparing our heading on a map, it may be different because depending on where you're located, the earth's magnetic field is very different.

So for example, I'm on a road and I'm using a magnetic compass, depending on where I am it may not be pointing directly down the road if that road is aligned with True North. Wouldn't it be excellent if we had a compass that could actually display both? You can clap. So that's what's really unique about iPhone. The iPhone GPS can actually display both True north and Magnetic North.

So what does this mean exactly? So magnetic compasses show this direction so for example if you're in San Francisco, a magnetic compass will point 14o in one direction, different from True North; and the same compass in New York City will point 14o in the other direction. But what's really cool about Core Location and since it already has its location technology, we can determine where you're located, we can do some calculations to determine what the field is like at your location, and then we can automatically correct this and show you True North. So what does this mean? It means if you're using a map your compass will actually point in the correct direction as opposed to a magnetic direction.

So if you're in Paris it might point slightly off in one direction, and as I said here in San Francisco, it points 14o slightly in another direction and also in New York City. So it's really great as you can see these blue arrows here, that's why I'm trying to represent the true North Direction and this red arrow is the magnetic North Direction that most traditional Compasses show. So let's talk about how we can actually use the magnetometer in the iPhone. So just as you would configure the Location Manager for location technology, we use the Location Manager also for the heading and the magnetometer.

So to check and see if a device has a magnetometer available in it, we have this property on the Location Manager called Heading Available. So simply check this property to determine if the device has a Compass available. And similar to the location technology we have another property which is Heading Filter. Now what this means is you're telling Core Location only give me heading information if the device is turned a certain particular amount of degrees, so you could say only give me updates if they move the device every 45o.

So how do you actually get heading information? Well they can have this diagram; this may look very familiar to you. And we've actually done this by design, so the heading API is very similar to the location API. When you call startUpdatingHeading, you'll start receiving heading information in these CLHeading objects; and when you call this the device will start using hotware because it's using the magnetometer. When you call stopUpdating Heading you'll stop receiving heading updates and you'll start conserving power.

So this True Heading I was talking about earlier or the direction to the North Pole at True North, the direction that maps use, I had mentioned that this uses location. So the device has to have determined a location within a particular period of time. Otherwise this value is reported as -1.0 until a location has been determined.

And a rough location is OK so you can use that CLThreekilometersAccuracy, desired accuracy. So you tell the Location Manager I'd like a ThreekilometerAccuracyLocation and using that location information, Core Location will automatically fill this field in with a true heading information based on where the device is located. So the default apps on iPhone that use heading information, they all display True Heading and when True Heading's not available, they'll fall back to the Magnetic Heading. So it's just something to keep in mind. So let me start off by showing you a quick Demo; and this Demo is really to demonstrate how you can use the raw data and start using the Compass information.

Can we switch over the demo machine? I have a sample project here and it's actually available on the Attendee website so if you want to follow along you can just look up the Core Location Session, and under there this code is available. Now this project is called testometer and it's a quick project I've put together and it allows us to use the magnetometer to observe magnetic fields. The reason why I did this is it gives a good example as to how you can use this Compass raw date of that X, Y, Z I described.

So here we have this testometer project and you can see the two primary components I talked about earlier-- the Gold Box which is Core Location, and then we have a controller in our app which is the testometer view controller. So this is the primary view in the application that will allow us to receive this heading information. So if we take a glance at the header, we can see where-- including the Core Location framework and we're implementing the Location Manager Delegate protocol. Now we have a few labels that we'll be using and even a graph.

Now if we jump into the implementation with us, there are a few things that are kind of cool to look at. So we have a viewDidLoad so this is called once that primary view is loaded, and this is where we initialize and create that Location Manager that I talked about-- that whole engine that controls the location and the heading information.

So we allocate that here, and then we check to see if the device has a heading available. So in this particular case, you'd have to think about how you can still provide something useful to the user, maybe not show heading information or you could even fall back to course. Of course that's appropriate for your app so that's a property you should check.

And here's that filter that I mentioned before. We're just saying we want every heading calculation that's been determined. And now we're saying OK let's make this controller class the delegate to Location Manager. So this class is going to be receiving those notifications. And here's where we call startUpdatingHeading.

What this means is that we want to start receiving that heading information. So as these heading events arrive, they arrive through this pointer object here; and because I wanted to make a magnetic field detector, I'm using this variable that's called a magnitude. Really that's allowing us to measure the size of that magnetic vector that's coming off the phone. So it will allow us to really determine the strength of that magnetic field that the sensor is looking at.

So we have these X, Y, Z values and we perform the computation, and we also copy over the heading information. And then we call update and update will actually update the UI so we're updating these four labels we have, and then we're updating a little graph so you can visually see these updates.

Just to show you, here's the properties that are in this heading object; so as I said we have a Magnetic Heading and then we have True Heading which is -1 until you determine a location; we are provided timestamp and X, Y, Z and I'll talk about accuracy in a moment.

So if we could switch over to the Wolfvision so here we have an iPhone 3GS and as you can see we have the default Compass app here and here's the testometer project we just looked up the code for. So if I launch this app, so here we have it.

Pretty simple application; we have this text view up here that determines the strength of the magnetic field and then we have these raw magnetic values below the X, Y, Z and I'm plotting these in real time so you can see the history of the data as it changes. So as you can see X is red, Y is green, so if I turn the device on the X Y plane and turn it back, you can actually see the X and Y cross over each other.

So what's also unique here, I have a house magnet and as I hold it close to the device, you can see the magnetic fields fluctuating so it's detecting when I move that device in. So as you can see this is picking up a lot of magnetic activity around the display here. So if we could switch back over the slides. So that's our first demo.

It's a pretty simple starter app just to get you started. So as you noticed as I was giving that demo, the device had that fluctuating magnetic field which is pretty interesting. So what that means there is magnetic fields around us everywhere, and all compasses are affected by them. So what that means if your Mac or even the iPhone itself can produce some type of magnetic field; and all of these fields can confuse a traditional needle compass and it can even interfere with an iPhone Compass.

But the disadvantage to a needle compass or other compass devices is that they can't detect or know when they're being interfered with but that's unique for them. We do something a little different. With that heading object we provide accuracy, so we've actually determined a way to figure out how inaccurate that compass reading could be based on other interfering magnetic fields.

So it's pretty cool. So that headingAccuracy value will actually act more dynamically if you're using location information. So I recommend trying it out and checking in to it. So how does it behave? Well if you have small types of magnetic changes in the magnetic field, that headingAccuracy value will fluctuate.

So what that means is the heading information you're receiving has that appropriate Heading Accuracy value, the headingAccuracy value may change from 40o and it may improve up to 10o. What this means is that heading value that is being given to you, is plus or minus this headingAccuracy. So what's cool is you can actually use this in your UI in unique ways; so the Maps application-- I've kind of darkened the background just so you can see this more vividly.

But as you can see the flashlight or this white cone that indicates the heading or the direction you are pointing the device. So as you move it the map will rotate but that's the direction it's facing. So if there is a lot of interference this cone is a little bit wider. But, as the accuracy improves of if you move away from interference, then that cone shrinks.

And it's kind of a unique way just to communicate to the user that it's not exactly precise, but there's some interference. And of course the finer the width of the cone, the more precise. So there's a lot of really unique ways you can take advantage of this. For instance, if you're making a Compass application, you can have that needle kind of quiver like a traditional compass if you're waving a magnet near it so there are some cool things about it.

Well what happens if you have large swarms of magnetic interference? So that headingAccuracy value will be reported as -1. And that just means I wouldn't trust the heading information-- that magnetic heading value that's being delivered in that heading object. So if that's unreliable or actually if you introduce more magnetic exposure, like very strong magnetic exposure to the device, then it will stop propagating those magnetic heading values, the CL heading value and it will start propagating this heading failure. So that's just saying that something is preventing the device from calculating any type of heading; that there's just too much magnetic exposure. And I've only seen this if I held like a very high powered magnet over the device.

So as soon as that source moves away, it will stop sending these error messages and it will start sending the traditional heading information back to you again. So if there are these different interfering fields with the compass, it is important to know that you can improve this accuracy. And there's a couple of ways you can improve it. So as I said before you can move away from that source of heavy interference; or we actually use movement to differentiate two magnetic fields.

So what does that mean exactly? Well the earth magnetic field is everywhere around us. But it's hard to differentiate that from a magnetic that you're holding close to the device. So we recommend that you actually move the device in a 3D motion, and that movement will sample the magnetic information all around the device, and it can differentiate and detect the interfering field as part of that device or the earth magnetic field. So by movement it can actually improve itself and improve its reading.

So that's pretty cool. So you can move away from a magnetic source and by moving away you can improve your accuracy again; and if you're in a clean magnetic environment just by moving the device, helps it tune in to that earth magnetic field and cancel out any interference that's coming from the device itself possibly.

So that's how you improve your compass accuracy. Now as I said you're moving the device so it's good to notify the user that they may need to move their device to improve accuracy; or move away from this interference. So we have an optional message that you could use, and you'll receive a delegate callback for this message. And what that means is just tell your user OK move your device or move away from that magnetic source.

This automatically gets dismissed once the device filters out that interference. Or you can manually dismiss it; for example, if the user goes into your settings view away from the main compass view, they you may want to call this dismissed value just so this display isn't over whatever you're looking at.

So that's everything about direction. We talked about course, we talked about heading, so course is the direction you travel in; talked about heading which is provided by the compass and that's the direction you're facing; we talked about magnetic north and true north. Magnetic North is the direction of the earth's magnetic field which compasses align with, and then we have True North where the North Pole, the direction we're most familiar with; the direction of the North Star that cartographers use when they create maps.

And we talked about using this API and how we could create a simple magnetic field detector and how important that heading accuracy is to determine if there's interference; and to just visually show to the user that there might be some type of interfering field. So that's the second part of my talk, and now I'd like to talk to you about Beyond Navigation.

So Beyond Navigation is actually quite exciting and there are a few topics I'd like to discuss. There are some additional use cases for Compass other than just determining direction. And I' like to talk about some of the other platforms you should be aware about. And then depending on the use case of your app, you have some options on frameworks you could use.

So what's really cool about Compass is that you can actually use it to view a virtual landscape. So we may not be at Apple's Campus right now looking at the courtyard, but by holding up our device and panning that device left and right, we could actually visually give an experience like we're at that location.

So it's pretty exciting. So the same can be applied to a game so you can actually use Compass to determine if your player in that game should turn down the hallway or turn left or turn right and that's pretty cool. But you might be thinking to yourself, "Patrick, you cannot already do this with accelerometer if you're holding the device." Well accelerometer is a little different. Accelerometer is when you're tilting that does the action but Compass itself you're physically moving in a particular direction.

It's a little bit of a difference in user experience. Augmented Reality. Augmented Reality is another really cool concept. So we have these really special devices that can tell us where we're located, and now can tell us which direction we're facing. So imagine all of us here right now, we're standing in front of the Apple Store in New York. Well let's find out some more information about this Apple Store.

We hold up our device and through the camera it's displaying the Apple Store but it can overlay some additional information. So oh we're looking at the Apple Store, here's the address, this is just an example. It gives you that concept that information can be overlaid in real time, and you can see additional information that you traditionally wouldn't see.

So that's pretty cool. Another kind of neat use case to kind of think about is Reconstructing Media. So the camera on iPhone will accompany and imbed heading information in the [inaudible] data and you can even use heading as you're taking pictures. You can store heading information yourself. And what's really cool about this is if we take pictures in several different directions, we can actually use that heading information to automatically merge an image together. So this is just one use case example.

There are many different types of use cases about restructuring media, but this is just to kind of give you a little brainstorm about the possibilities of Compass. Because otherwise if you're doing this it's very difficult; you have to provide a UI to have the user align these images as they're taking the pictures; so we're trying to think of a less painful way for the user to experience something unique from Compass. So, something you should keep in mind is that Compass measures the direction off the top of the device.

So, if you're writing a game app and it uses Compass and landscape, you should be aware that you need to shift that. Because the intention of your UI may be different than what the device hardware is calculating. So just provide an offset to shift it over and if you're using the device and landscape in the other direction, you can shift it over as well.

There's just some things to keep in mind; and do be aware that if you are applying this shift to the heading value so it's working in landscape, you will be wrapping around when you hit that 359o or you're coming back to 0o. So let me show you a quick demo.

So I put another quick application together just to kind of give you an idea of some of the potential of Compass. I call this Spectacle-- so basically what this allows is if we're on a virtual plane, I can actually turn the device and we're actually looking at Mars in different directions. So I know what some of you maybe thinking. This is out of this world. But it's just one of the potential use cases you could do. So here what we're doing is we're animating an offset for an image view. So that's one really interesting potential use case.

Could we switch back over to the slides please? Oh another point that I should mention to you is that you can actually even overlay core animation layers, and depending on the direction the device is being moved in, you can rotate or move those core animation layers and create an application like a kaleidoscope for example. So there are a lot of really cool things you can do with directional information.

So some other points I'd like to make and when using the Core Location Framework do be aware that there's multiple platforms that you're supporting; and if you're writing that navigation app that was for iPhone previously, be aware that it's now possible for iPod Touches to have an external GPS. So don't just limit your app.

You have more potential customers now. It's also good to know that you should be aware if you're writing a location app for the Mac, that Mac may not have a Wi-Fi card for example So just some things to keep in mind. Also, depending on your use case, some of you may have attended the MapKit session this morning.

Now MapKit's a really cool framework and that actually sits on top of Core Location; and you can receive location information from MapKit. So MapKit provides you with map views so you can display maps in your application, and it provides some other cool things like reverse Geocoding so you can take a latitude, longitude, convert that to an address or a neighborhood name; and as I said it uses Core Location, so you can retrieve location information from MapKit.

So when you're building and designing your app you should be thinking about what's appropriate or what's the appropriate use case for your application. So because there's definitely a tradeoff here, you can choose from a couple different frameworks. So if you're using location, if you don't have a mapview, it's probably most efficient to just call a Core Location directly instead of calling it through the MapKit framework. Compass is provided by Core Location so you'll have to talk to Core Location directly for the Compass information. And of course, turn by turn you have to use Core Location, and if you're using mapviews and reverse Geocoding then you can use MapKit.

So just some use cases to think about. And that wraps up everything I wanted to chat with you about today. So we talked about finding your location, how appropriate it is to set that desired accuracy, and how Core Location is the unified framework for providing you with different types of location information; and we talked about direction-- so the difference between course and heading; we talked about how iPhone can show Magnetic North and True North using location information.

Then we kind of went beyond navigation and talked about some fun use cases that you can implement with heading information; and supporting multiple platforms, and thinking about what framework might be most appropriate for your app. There's more information. Please contact our Evangelist, Matt Drance, and you can check out the API references online.