WWDC2010 Session 115

Transcript

>> Morgan Grainger: 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?
[Applause]
>> Jay Bruins: 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.
[ Applause ]
>> Morgan Grainger: 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.
>> Jay Bruins: Thanks, Morgan.
[ Applause ]
>> Jay Bruins: 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.
>> Morgan Grainger: All right.
Thanks, Jay.
So again.
[ Applause ]
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.