Good morning. Thank you for making the effort to be here at 9:00 on a Friday morning, night after the bash. Hope you had a great time there, and I hope you're ready to have a great time learning about how to test your location application without leaving your chair. I'm really excited about what this means for you and for your applications. So let's dive right in.

So, we know testing is important. Testing is the barrier between your mistakes and our mistakes and our users seeing those mistakes. It's the layer between conception and having an idea and shipping. It's the difference between a great idea and a great release. So, why don't we do more of it? Well, that's kind of a philosophical question.

It can be complicated, and we're not going to get to all of that today. But we are going to talk a little bit about why we don't do more of it. And we're going to talk a little bit about how we can make it easier, and especially how we can make it easier to test location-aware applications.

So that's the goal of the session today, to figure out how we can take our applications and make it so that they work better for all of our users, no matter how they use our application, no matter where they are, that all of our users can take advantage of these great applications.

Because the reality is that it's a big world out there. People live in different countries, different locales. They live in urban areas. They live in rural areas. And it's likely that you don't live in all of those places at the same time. You live in a particular area, and it's likely that the people that you work with and test your applications only live in a subset of those areas as well.

And to this point, the best way to test one of these applications has been to go and drive. Now, we at Apple do a lot of driving, and it's an important part of our testing. And it's important for us because we need to make sure that our devices in real-world situations get more and more accurate with each release, that our GPS works better, that all of our different positioning technologies work well together.

And while you as a developer may have a bit of a classier car, you're still stuck with essentially the same problem. You want to test your application, you need to go and drive. But there are still limits to this. You're not going to be able to get the test coverage that will allow you to be confident that your users in other areas and other countries that maybe live way out in a rural area or live in a really dense downtown urban core are going to have the same experience that you're having. And so our goal when kind of taking a look at this was to allow you to have that confidence while sitting at your computer, while sitting in your chair, as the title of the session indicates.

So, what we're going to talk about today? We're going to talk about where we have seen location-aware applications commonly fail in the past. I call this a cautionary tale. How can you make sure that your application doesn't have many of those same issues? And then finally, we're going to talk about the tools that we've added to make it easier for you to do just that.

So, why test your location-aware application? I'm going to go through a case study where, while the details may have been changed, it really hits on a lot of the big themes that we see in location-aware applications. So in case you can't really tell from the session that I did earlier this week or from this one, I'm really excited about the potential created by location-aware applications.

I think that they provide a great way for our devices to become more in tune with where our users are and the environment that they're in. And we're seeing kind of all these different, these new use cases that really kind of wouldn't have been all that common just a few years ago.

You know, social location, geocaching, geotagging photos, you know, having fitness activities, having my phone be able to track where I am. So I got inspired and decided to create my own location-aware application, and I'd like to demo that for you now. So let's take a quick look at that. All right, so I'm just going to run this application for you.

So, I'm going to show you what it does. And the concept is pretty simple. It's an application that allows me to find parks close to where I am. So, it's pretty basic right now, but essentially what I'm going to do is I'm going to say find nearby parks, and it's just going to show some near me. And so you can see there's Golden Gate Park, Buena Vista, Mission Dolores. And then the other thing I can do is ask to be reminded when I get close to one of these particular parks. I'll show you that functionality later.

So that's the basic idea. It's just a very simple application that figures out where I am, figures out which parks are nearby. Now, if I were building this application to ship to the App Store, I would probably have some sort of server that I would query this data from. But if we go to my application, you can see that the way I'm storing the data is actually in a number of property list files.

So I basically just have an index file that kind of tells me where, you know, gives me an index into other property list files. And so I can go into the one near San Francisco, and I can see the names of the parks and the latitudes and longitudes. So again, a very simple approximation of a database. But for the purposes of this example, it will work.

So, that's the basic idea of how this application works, and this is what we're going to be working with throughout the presentation. And as you can see, it seems to work pretty well for me, right? You know, I'm in California, and I say go to nearby parks, and it's working great. So, I'm really excited with this application, and I think it's ready for prime time.

I want to talk a little bit about how we generally go from conception of an idea to the final release. You know, we go and implement something and then as we test it, we find issues and problems come up and we figure them out and we deal with them. And in this case, I've kind of grouped my bugs into some categories.

We've got our critical bugs, the must-fix, the show stoppers. We've got the annoyances, the things that our users will notice but probably aren't show stopping. Maybe it doesn't affect a large number of people or it's a minor annoyance. And you've got the enhancements, the things that you want to do to make your application even better.

So as I develop my application, I go through and address the really critical bugs. I go and get rid of most of these annoyances, maybe even get through most of the enhancements. We'll leave teleportation for a future release. And my app is ready to go. So I submit it to the App Store, and I'm really excited. And the next day I wake up, I check my email, and I've got all of these complaints from users who are just complaining that my application doesn't work. And worse than that, I go to the app store, and people aren't very happy there either.

And I think this is one of the more subtle points associated with testing. There's definitely a cost to testing, but there's also a cost to not testing. There's the support cost, dealing with these users. There's the reputation cost of dealing with these reviews. And kind of if users try your application once and it doesn't work, it can be hard to get them back.

So where did I go wrong? What did I do? What could I have done better? Well, if we go back to my list of bugs, the problem wasn't that I had bugs that I didn't fix. I wasn't trying to ship poor-quality software. The problem was the bugs that I didn't know about.

And really, the issues that we see with location-aware applications are these bugs that just are not necessarily apparent when you're developing the application. It may work really well for you and your environment, but without having access to this broad range of environments where your users are using location, it's really hard to find these issues prior to release.

So what we're going to do is we're going to go through some of these reviews that were left in the app store. We're going to figure out what's wrong. We're going to use some of the new tools that we've added in iOS 5 to make it easier. I'm going to talk about three main tools today.

The first one is the iOS Simulator, which has been enhanced with full location support. The second one is Xcode, which has a lot of great new location-aware features. And the third one is the UI Automation Framework, which is a way of creating automated repeatable tests for your applications. All of these have new location support in iOS 5.

So, where do apps commonly fail? For the purposes of this exercise, my application has all of these problems illustrated. So we're going to kind of go through them and figure out what we can do to correct the problem. So first of all, I've got a user who's complaining to me that my application just doesn't do anything. And the only other piece of information I have is, if I get this, is that they hit cancel on the location prompt. So they denied authorization for my application to use location services.

Now, the thing is that this is going to happen. Even if users pay money for your app, even if you think they're going to be really excited, users may hit that button by accident. They may not necessarily be sure why your application needs to use location. It's going to happen. And if the application just stops working, users are going to notice. And from their perspective, your application just doesn't work. And they don't even get to see any of the cool features that you spent all this time implementing.

The best applications, as a baseline, continue to function. As you'll see, my application doesn't. And they degrade gracefully, and what I mean by that is providing the maximum amount of functionality possible given the user's decision. So maybe your application can't get the user's location, but what it can do is maybe provide them some other way of inputting a zip code or an address or something like that and operating on that basis.

And then finally, if you've got a feature that just really needs location in order to function, let the user know in some way. You don't want to be intrusive, but it's important that they're at least aware that if they want to use your application, that they need to authorize it in order to do so.

So the tool that we're going to use to kind of explore these sorts of issues is the IOS Simulator. And I'm really excited that in IOS 5, the location-- sorry, the IOS Simulator is a bonafide simulation of device location features, which is really exciting. And so what that means is you'll get the standard location prompt just as you would on a device. This is not something that we had in IOS 4. You will get the status bar icon up in the status bar when it's appropriate.

You will get the Location Services menu that allows you to essentially view the behavior there, as well as change authorization states for your application. And then finally, you get the option to reset location warnings, which is essentially a way of resetting the system back to its initial state location-wise, again, just as you would on a device. So let's take a look at how we can use the iOS simulator to take our one-star application and get it up a little higher. So let's go back to the demo. All right, so here's where I was before I was showing you my application working.

But what I'm going to do is I'm actually going to go into Settings, and under Location Services, you can see Location Services are on. And my application is authorized because I hit OK on the prompt earlier. So what I'm going to do is I'm going to turn Location Services off for my application. Going to menu out and go back to my app.

And I'm just clicking around and it's not responding. And even worse, if I just close it entirely... And come back to it. I launched it and I'm just getting a black screen. So as I, just as somebody who automatically hit OK on the location prompt, didn't see this behavior at all. But all I had to do was make that different decision, and now my application just isn't working.

So, one other thing I want to show you in the simulator is the ability to reset location warnings. So I'm just going to do that now. And that will set things back to factory defaults just for the next time. All right, so what's going on? Well, what I'm going to do is I'm actually going to launch this in the debugger.

It launches my application. Here's the prompt, and so I'm going to hit "Don't Allow." And I'm back in this unresponsive state. So if I go back to the debugger here, I'm just going to pause.

It launches, and excellent, this time we get a prompt saying nearby parks are unavailable. If you want to view them, you have to authorize the application.

So at this point, we may think, great, this solves the problem. But I think what we've actually done is we may have gone a little too far. Because if I exit the application and then go back in, I get another prompt. In fact, if I lock the device, say I put it in my pocket and I unlock it, I get another prompt. So basically, every time the app is coming to the foreground, I'm constantly telling the user, hey, you need to turn on location services to use this application.

Morgan Grainger And the user may get kind of annoyed and may actually stop using my application if I keep pestering with these alerts over and over again. So what would probably be better would be to essentially localize this alert or move it into a place that is more directly connected to the use of location features. So probably putting something into code that runs just kind of every time the app comes to the foreground or something like that isn't the best idea. So let's get rid of that.

So if I go back to my project here, I think what I'm going to do instead is make it so that when they click on this Find Nearby Parks button, they get that alert instead. Because as you notice right now, just nothing happens. It doesn't work at all.

So I have my Nearby Parks View Controller, which is essentially the class that is driving this view. And I'm going to go down to my table view, didSelectRowAtIndexPath delegate method. So this is a table view controller, and this delegate method gets called whenever a button or basically entering this table view is clicked.

So it's this piece of code here that's most relevant. And essentially, if they tap that button, what I'm doing right now is I'm checking to see if the status is not denied, is not restricted. I'm going to start updating location. So what I'm going to do is I'm actually going to add an else statement into that part.

And what I'm going to do is basically saying, well, if we are denied or we are authorized, then in that case, I'm going to show a dialogue. So it really brings more locality into the alert. It reminds the user at the point when they try and use a feature that they need to enable location services in order to use it.

All right, so I go back. Notice I didn't get a prompt just by virtue of loading the application. But I click Find Nearby Parks, and it's telling me, hey, if you want to use this feature, you need to authorize this application. I click it again. I get the alert again. So essentially, whenever I try and use location services, the user gets reminded at that point in time.

Morgan Grainger One other thing I just wanted to show you quickly is that all of the APIs, so the authorization status API, as well as geocoding, also work in the simulator. So if I go back to Settings and authorize this application, and go back. You can actually see that I'm geocoding the locations as I get them. So there's full geocoding support in the simulator as well.

Before I go back to the slides, I'm just going to reset again so we start with a clean slate. So we took this problem that only appeared when the user denied location services. We were quickly able to test that scenario ourselves without having to load our code onto a device, find the problem using the debugger, and then fix it. And we fixed it in a way that is in tune with how the user probably wants to use location services in the application. At the point when they decide that they want to use it, that's when we present the dialogue and let them know.

So, we're up to three stars. We're getting there. We're on our way. So we have this other one-star review, and it looks like we've got a user from France, and my French isn't what it used to be, but I think what this user is saying is that the application just isn't working for them. And oftentimes when we see things like this is we see applications that were built in one region of the world that are then used in other regions of the world where maybe the developer hadn't really thought about or hadn't really necessarily intended.

So it's important to identify and verify any data coverage limitations that you have. And what I mean by that is that if you're depending on some external service to provide you things like local businesses or, in my case, I had a service that provided me with nearby parks, anything that basically involves location and finding some item of interest in your particular locations, make sure you know where that works and where it doesn't work. If necessary, find additional sources because users will download your application and expect them to work for them. And if it doesn't, to them, you know, it doesn't deliver on its promises.

And if absolutely, you know, if necessary, and you've got just large regions of the country, or sorry, of the world where your application won't work, consider appropriate regions for sale of your application. Now, this is obviously application-specific. If you've got some sort of travel application that's for people traveling to the United States, it may make sense to sell that everywhere, even if you only have data for the U.S., for example. But if your application is really about finding local information, this is something important to keep in mind.

But in my case, I want to figure out why this isn't working for this particular user. And I'm going to use the support in Xcode to do that. And it's really exciting that in iOS 5, the Xcode team has added location support to a variety of components of the IDE. They've added support in schemes, which I'll talk about in a minute. They've added support in the debugger. And they've also added some unit test support as well.

And they allow simulation of a kind of a variety of different types of positions. You can -- they have a variety of pre-populated cities that you can set the location to. And they also allow specifying custom locations through what's called a GPX file. GPX is an XML-based format for, I guess, storing waypoints or lists of locations.

And the great thing is that this works both in the simulator and on the device. So if you need to test on a device because there's some portion of your application that really depends on that environment, you can still simulate locations by using the support available in Xcode.

So what is a scheme? If you've been to some of the sessions earlier this week or you've used Xcode, you're probably pretty familiar. But a scheme is essentially a way that specifies how your application should be built, test, and launched, among other things. And where location mostly comes into play and where I'm going to focus on is in the launch phase. And by using schemes, you can essentially control the location environment that your device sees or the simulator sees when you run the application.

So this is what the scheme, the edit scheme dialogue looks like. And if you'll notice, under the run action, there is an option to specify the location associated with that scheme. And so this is a pop-up menu that allows you to select one of a number of pre-populated locations, popular locations in the world. Or if you have GPX files add to your project-- again, these tracks or series of locations-- you can specify one of those as well. And that allows you to essentially pick any location in the world that you want to test.

So let me give you a demo of that and see how we can use it to solve this user's problem. All right. So, as you can see, we're back in my project here, and I just want to zoom in on the scheme pop-up. So I've got a number of different schemes defined here. I'm going to select the Paris scheme because I want to see what happens when the device is in France. So I'm going to run it with that scheme selected. And I'm going to hit Find Nearby Parks. I'd like to use my location.

And it doesn't look like it's finding them. Let's try that again. Go back. Oh, I stopped. I stopped running it. Let's try that once more. Find nearby parks. And actually, of course, this is what we were expecting. After all, our user was saying that it doesn't work in France.

And that's kind of odd, because if we look at the map here, you can see that from the device's perspective, from the simulator's perspective, we're definitely there in France if we zoom in far enough. So the device says that we're in France, and we think we have data coverage there, but it's just not showing up.

And so I want to try, I'm just going to go into the simulator here. Well, you know, does it work in, say, Tokyo? So it's working now. So it looks like our Tokyo support works fine. You can see that we're over there. So this really just appears to be some problem with Paris.

So why is that? Well, let's first of all set our location back to Paris here. Reload, and it's not coming up. So let's go back to the code here and see exactly how it's determining which parks are nearby. And going back to the same delegate method, which is what happens when the user selects a row, it essentially calls a method that eventually determines where the nearest parks are. So let's just go there. And so when we get a location, I'm stashing it away. And as I mentioned earlier, I'm essentially looking up stuff in this index plist, which then goes in forwards to one of these appropriate ones that contains parks for an appropriate area.

So if we go back here, we're opening the index plist, and then we are enumerating through it. So let me just set a break point here to try and see what's going on when I tap that button. So I click there, and we're stopping. We've stopped here. And I want to see-- let me just zoom in here and make this a little bigger. Let's see. This will be fine.

I just want to see-- What we're seeing in this indexed plist. And so if I zoom in here, sorry, it's a little hard to see. I can see that this plist has three entries, Paris, San Francisco, and Tokyo. The one thing you notice here is it looks like we've got a typo in this plist. So Paris is spelled wrong, and so then tries to look up that plist, and so it's just not working. So what I'm going to do is I'm going to go to my index.plist, just adjust this name here, and rerun my application with that changed.

All right, if we look at the map, we are once again in France. I'm going to say find nearby. Still my break point here. Let's just get rid of that. And you can see that I'm now getting results. So by being able to specify a custom location, I was quickly able to get into the environment of my user. And again, while this seems like a somewhat trivial mistake to make, those sorts of mistakes happen.

And testing is the best way to get past them and figure out exactly what's going on in our user's environment. So we're up to four stars. We're getting closer. We've got one more review to deal with. We've got a user who uses your application in the subway who is just complaining that it can't find them.

And this happens a lot more often than I think we realize. People use iPhones and iPads and iPod Touch devices in all sorts of locations. They use them in rural areas, they use them under open skies, they use them in dense urban environments, which are challenging for GPS.

They use them underground, in underground parking lots, in places that may not have cell coverage, may not have Wi-Fi, or may not have the ability to get GPS. So it's important to remember that not all devices have a GPS receiver, for one. While all of our iPhone devices, since the iPhone 3G, as well as our 3G-enabled iPad devices do, the Wi-Fi-only iPads and our iPod Touch devices do not.

And even for those that do, GPS will not be available. So it's important not to make assumptions about the accuracy of positions that your application is going to receive. And where this manifests itself most often, where we see it, is in applications that are really trying to get the best position possible. And so what they do is they start updating locations, they get a location back, and they just discard locations that they don't think are good enough, and they wait and wait and wait and wait.

The problem is that you could end up waiting forever. So the best applications function with less accurate positions. They do the best they can. And if they really, really need a good, a really accurate location in order to function, you know, think about maybe turn-by-turn navigation apps or fitness apps. They let the user know about the problem, at least, so that they're aware of it.

So in order to kind of see what's going on in this particular example, we're going to use a tool called UI automation. So UI automation is a framework that allows you to create repeatable, automated tests of your application. It's called UI automation, so one of the main things it can do is test your user interface, but it can actually do more than that.

In iOS 5, it can actually simulate changes in the device's location. The great thing about UI automation is that it can do more than just simulate coordinate changes. It allows you control over all aspects of the location that your application receives. The horizontal accuracy, which is essentially how good of a position we think we have. The speed and course attributes, if your application depends on those. The altitude and vertical accuracy, if you depend on altitude information.

How can you use this tool in order to improve the quality of your application? Use it to test a variety of different accuracies that your user is likely to see. Think about use cases both common and uncommon. From there, you can come up with kind of with test cases, and see how your application performs in those environments.

We provide these constants in the Core Location Framework. They're called CL Location Accuracy that are an indication of essentially, you would normally specify them to say how accurate of a position your application desires. But these values are a good start for testing kind of different accuracies of location.

So maybe test one with a 10-meter accuracy, 100-meter accuracy, kilometer, three kilometers. But you know best the environments that your users are likely to be in and what's most appropriate for your use case. And then finally, it's important to test what happens when location isn't available at all. Because it will happen, and it could be confusing if your application doesn't respond to that appropriately.

So I'm going to show you a demo of how we can use UI automation to diagnose this user's issue. So we're back here. So as I said in the slides, you actually access UI automation through instruments. You may be aware of instruments. It's a tool for doing all sorts of performance analysis and profiling on your applications, both for the Mac and for iOS. But on iOS, we have what's called the automation instrument. So I'm going to choose that. And essentially what this allows us to do, it allows us to essentially run repeated automated tests against our application, and then define pass and failure criteria.

Now before I start showing you the location features, in order to just show you how easy it can be to get a basic test script up and running, I'm actually going to show you how you can do recording of the interaction that you make with the application's user interface and then use that as a basis for a test to run. So I'm going to hit this Record button at the bottom here. It's reminding me I need to set a target. So I'm going to choose my simulation demo application. And I'm going to make sure it's launched using the 5.0 SDK.

All right, so I run it. And so I'm just going to, just as an example, click around to a few screens here. And then I'm going to click the Find Nearby Parks button. I'm going to tap a result. I get a map back. And I'm going to click Done.

All right, so going back to instruments here, I'm just going to stop recording. You can see that as I was clicking, it was actually creating a template script to repeat those same actions in a test. So these bubbles here essentially represent suggestions of how I might create a script that does this. So for now, just to show you how this can play back, I'm going to do what's called flattening all the suggestions, which essentially creates a normal script. And now I'm going to run the script.

So, I'm going to show you how to test the new app. So, I'm going to go to the app and see how it plays back. So, it's running, and you can see it's moving between screens just as I did. It taps the nearby parks button, brings up a map, and it hits the done button in exactly the same way that I did before.

So, instead of having to write all this code to try and create the scenario that you want, you can just basically perform the scenario on the device, sorry, or on the simulator, So what I'm also going to do is I have this test that I've created here. I'm just going to use this as an example. So with UI automation, what you can actually do is you can use the set location API in order to set the device's position. And so this is a way of creating that environment that you're looking for.

So just to give you an example of this, I've got a script that is setting the location to be a variety of different positions around the world, having a bit of a delay between them so that we can essentially see on the map as it moves around. And then finally at the end, I'm setting the location to be a-- saying no location, which essentially allows you to say, stop simulating. So this is my script, and let's start running it. And if I go to the map here, you can see I'm in San Francisco. It then moves over to Europe. I'm now, I believe that I'm in Paris. And it's moved over to the UK.

And then, all right, it's moved over to Japan. And then the last thing that it does is it stops simulating locations. So in maps, that's shown by using the gray dot. But so as you can see, as the script actions execute, the position in the simulator and on the device is changing in real time.

So this is pretty powerful stuff. So how can we use this to debug our user's problem, which again was they're in the subway, and they're not getting a location at all. So I'm going to go to a different script that I built here, and I'll go through it step by step.

So the first thing I'm doing is I'm going to simulate, first of all, being in Paris. So I've got set location. But you'll notice that I'm using a different API here, and it's called set location with options. And what this allows you to do is to specify the other properties associated with the location. So in this case, I've got the latitude and the longitude, but I'm also setting the horizontal accuracy to be 1,000 and the altitude to be 20 meters. But all of the properties on CL Location Manager can be set through this API.

What I'm going to do after that is I'm going to tap the Nearby button in the tab bar. I'm going to tap the Find Nearby Parks. I'm going to make sure it's visible, and I'm going to tap it. And then if you look here, what this is going to do is it's going to take a look at the table view that's present and make sure that there is more than one cell in that table view.

Now, if we go back to the application, if we look at this, there's always going to be one cell in that table view, and that's essentially the Find Nearby Parks button. So in order for there to be a result, we just want to make sure that something comes up in this situation.

So if there's less than or equal to one row, then we're going to fail the test with uialogger.fail saying, hey, we didn't find any results. What's up with that? Otherwise, we're going to record this as a pass. So let's see what this can do. I'm going to... Run it.

And just get it starting so it's making sure it's visible. It taps the nearby parks button, but nothing comes up. And if we look here, we can see that this was recorded as a test failure. And if we click on it, you can see where it was. So, one other cool thing is you can see it actually recorded a screenshot of what the screen looked like when the test failed.

Now, but if we go to the map, you can see that, I mean, We're in Europe, we're in Paris, and if we actually zoom in far enough here, you can see the accuracy ring around the position showing that this is in fact a one kilometer accurate position. So something has gone wrong here, because we can see it on Maps, but we cannot see it when we go and tap this button. And now that I'm in this scenario, I can do the same thing, and it's not there.

So, in order to debug this problem, I'm just going to stop my simulation here, my running of a test. I'm going to go back to my view controller and see what's going on. And the best place to start is essentially I'm going to set a breakpoint right in my location manager, did update to location, from location delegate callback. So I want to see what happens there.

and I'm going to -- actually, I don't know if I can set a breakpoint while running it from instruments. One thing you'll notice here is that, that I want to -- that is probably the source of our problems, is that in this delegate method, we are actually checking the horizontal accuracy on the position. And we want to make sure it's at least -- it's a hundred meters or better.

And in most environments, or in environments where you've got a GPS, that's going to work out really well. But the problem is that if the user is in one of these challenging positioning environments, they may never get a hundred meter accurate position. And so your application will just never process that location and won't do anything.

So it's probably not a good idea to just throw out positions unilaterally based on their accuracy. It's probably smarter to do something like, say, set a timer to indicate to the user that, after a certain period of time, that their position could be determined, or wait a certain period of time, and then once that time is up, take the best position, that is available.

But what I'm going to do right now is I'm just going to get rid of that code there. And I'm just going to just build it, make sure it builds an Xcode. And then I'm going to run my script again. So same script. I'm going to run it. It taps the nearby parks. And this time I got results.

And if you look here, you can see that it says successfully found a result, and that was marked as a pass in the script. Now, I mentioned earlier that it's probably not the best idea to throw positions away entirely, but you may want to essentially continue trying for a certain period of time.

So what I'm going to do is in my location manager, did update to location -- sorry, in my callback where I'm starting location, my mistake, Essentially, when the user taps that button, right now I'm just calling start updating location. But what I want to do to make sure that I don't run forever is I'm actually going to set a timer to stop it after a certain period of time.

Now, there are a number of different ways that you can do this. I'm actually going to use what's called a dispatch timer to show you a bit of Grand Central Dispatch. And what this is doing is it's going to basically say, after some period of time, and what this code is saying is 10 seconds from now, so in 10 seconds, execute this block of code on the main queue, so that will execute on the main thread. And so then, if that happens, what I'm going to do is I'm going to stop updating location. And if no location was found at all, then I'm going to pop up an alert to the user.

So what I'm actually going to do here is I'm just going to modify this scheme here for a second so that it doesn't have any location at all. So I select none there. And now let's see what happens with this modified application. We're going to launch it. I'm going to tap Find Nearby Parks. It still found me a park. That's interesting. Well, you'll just have to take my word for it that if I were to-- all right, here we go. It's going to run for 10 seconds. You can see the icon on the status bar indicating that it's still going.

If we let our 10 seconds come up, it then stops. So that's one way that you can basically set a timer when it expires, call stop updating location. So we've addressed this user's concern. Now, even with inaccurate positions, the application works as we would expect. All right, so we're up to five stars. We made it. We've identified three major problems with our application, and we used each one of the new tools in iOS 5 to find the problem and to fix it, all without ever having to get in a car.

Now, there are a few other things that I want to tell you about in the simulator. We've added support for background location services. So if you run an application or you have an application that uses location even while it's in the background, that will now work in the simulator in the same way that it would on the device. So you can move your application to the background and continue to get updates as long as you've got the key in your Info.plist and you've started location updates in the same way that it does on iOS devices.

As well, our two other background location services, our Significant Location Change API, as well as our Region Monitoring API, both also work in the simulator and are testable. And I just want to give you a quick demo of region monitoring to show you that that can work. Like I showed you briefly before, we have, when I tap on one of these results, I have this button that basically says Remind Me. And it's going to remind me when I get close to this particular park.

Now, I'm going to show you a little bit of a demo of what that looks like. This is just kind of a basic example, but there are a lot of different use cases for doing something similar. Maybe not with parks, but maybe with locations that the user is more interested in. So I've got that set. Now, in my code, I've got it set to pop up an alert view whenever I get the region entered callback to say that I'm getting close to that park. So what I'm going to do is I'm actually going to quit the simulator.

And I'm going to use my GoldenGate Park scheme. And if I edit the scheme, you can actually see that I'm using this GoldenGatePark.gpx file. So I specified essentially a custom scenario that I want to use. And if we just take a quick look at this file, it's essentially a list of latitudes and longitudes. So basically it goes through them one after the other. And then that's what -- those are the locations that your API will receive. So I'm going to run this application.

And you'll notice that because I've added essentially a region to be monitored, the location icon is still present in the status bar. And so if we take a look at the map here, We zoom in far enough. You can see my current location. And you can see that the location is actually moving. And it's doing that based on these points that I had defined in that file. So basically it goes through them one after another after another. And so we move closer and closer to the park. It essentially goes in a loop.

And you'll see we got close enough, and my code that triggered an alert on that event came through. So this allows you to define scenarios that allow you to test even all of our background location services, region monitoring significant location change, as well as just the background location API in general.

All right. If you'd like more information on any of what we've talked about, any of these tools, or having trouble getting up and running, I'd highly encourage you to contact Vicki Murley, who is our evangelist, and she'd love to help you with this information. In terms of documentation, we have our regular core location and location awareness documentation, as well as a great UI automation reference collection that's available on the web. And the developer forums are always a good bet. It's Friday, so there aren't too many sessions left, but if you want kind of a broader perspective on what it means to build a really solid application, I'd highly recommend this session, which is coming up at 11:30.

So to sum up, testing is hard. It's not an easy thing to do or we'll be doing more of it, but it pays off. It's worth it. It's worth it because your users will notice and they will tell you if things aren't working. We've added three tools, or added support to three tools, to the iOS simulator, to Xcode, and to UI automation that are complementary to each other and together form a comprehensive way for you to get the test coverage that you need to make sure that your users will be able to use your application. One note, though, always make sure that you do some testing on a real device.

The simulator is great, and with iOS 5, we've made it closer to what a device should be, but it's always important to do the testing on that hardware, even if only to get a sense of the real conditions that your users are likely to see. And if you've done all this, you've used these tools, you've found your issues, you've debugged them, there's only one thing left to do, which is to wait for the reviews to come in. Your users will love your application.