WWDC2017 Session 237

Transcript

[ Crowd Sounds ]
>> Good morning, everyone.
And welcome to session 237 this
early Friday morning.
My name is Fredrik Olsson and
I'm an engineer on the MapKit
team.
And today I'm here to talk about
what's new in MapKit.
The generic map, the standard
map that has been with us for a
couple of iterations all the
time, is a good map.
It has a road network for easy
navigation.
You have your points of interest
for reference.
But sometimes your application
has a little bit more specific
kind of data that you want to
stand out.
Like we had in AppleMaps when we
added the transit mode when we
want the transit line to stand
up and the map to take a little
bit of a step back, mute down
and let the data pop so the user
can see what is important at the
moment.
In new iOS 11, we give you muted
standard map type but do the
same for your applications so
that your data can stand out on
your map and your applications.
The map is not only the map.
There are also a couple of
system controls that we provide
for free on top of the map.
You have up in the left corner
here you can see the scale view.
You have the complex view up in
the right corner.
And down in the bottom right you
have a friend that has been
available as API for your use,
the user tracking bar bottom
item.
Now, it is a bar bottom item
which means that you can only
use it within the context of a
bar, such as navigation bars or
tool bars.
And if you want to display it
anywhere else, you have to
unfortunately roll your own.
And in iOS 11 we fixed that and
we give you a proper user
tracking button that is the
UIView subclass so that you can
use it wherever and whenever it,
well is good for the context of
your application.
When we give you the user
tracking button, we thought why
not give you more?
So, yes we will now also give
you the compass button.
The compass button is by
standard app in the upper right
corner.
By having it as a UIView button
you can position it wherever you
want.
You can even put it in one of
the navigation bars if you want
to.
The compass button has one more
property than the user tracking
button do.
It's the compass visibility.
It's on purpose that the compass
visibility is not just
repurposing the hidden property
or some equal simple bool yes
show it or don't show it.
We already could show the
compass on the map view by using
the shows compass on the map
view itself.
Which is a Boolean yes no.
But it's a bit limited and
doesn't encompass all the
features that we want to expose.
So, feature visibility is a new
enum.
It has three states.
The adaptive mode which is the
default, hidden and visible.
And if you look at them, hidden
is obvious.
It does what it says.
Visible also does what it says,
so no reason to talk much more
about it.
But the adaptive default mode do
require a little bit of
explanation.
What the adaptive mode do is
that if the user has rotated the
map a little bit away from pure
north, we display it.
And if the user rotates back to
pure north, we fade it away.
And being a button, if you tap
on it we will rotate back to
pure north and fade it away as
well.
It is tapable in all the
different visibility states, so
you can always tap it.
It will always be a button.
But it's a nice catch.
And if the user rotates away
from pure north past the little
threshold, we fade it in again.
And that is the compass button.
The last sibling, the scale
view.
Also have the visibility
property which is the same three
states in enumeration.
Hidden, self-explanatory.
Visible, also self-explanatory.
And adaptive is a new behavior
where when your user is zooming
in and out, then we display the
scale view.
Otherwise, we hide it.
The scale view has also been
available on map view previously
with the show scale property on
map view.
The default behavior for show
scale and show compass has
unfortunately been a little bit
different.
So, where the default for
showing the compass has been the
adaptive mode where we hide it,
the default for scale has been
to always show it.
And now with the scale view
being exposed to you, you have
all three options available to
use as it fits in your
applications.
There is one more property on
the scale view.
The legend alignment.
The legend alignment is related
to the also new and improved
localization support for map
view.
Previously, the compass has
always been in the upper right.
The scale has always been in the
upper left.
These are the defaults you get.
But new in iOS 11, if you
recompile against iOS 11 SDK, we
will instead fix the compass
against the trailing edge and
the scale view against the
leading edge to get that natural
look and feel for our
right-to-left users.
This, however, has one little
complication that leads us into
legend alignment property and
why we need it.
The default is leading, which
means that we will fit the
serial point of the legend to
the edge, the leading edge.
And the upper bound of the
legend is flexible and will move
as the users zoom in and out.
And the leading edge for in this
example British English would be
the left-hand side.
And for Arabic in this example
is always the right-hand side.
If you instead want to align
your scale view to the opposite
side of the screen, you need to
set the legend alignment
property to trailing and we will
flip the zero point that is
fixed and to dynamically adapt
to the localization that is
currently being used.
This makes a little bit more
sense if we look at it as the
user actually interacts with the
map.
The zero point, the zero points
are fixed but as the user starts
zooming and this animates, the
upper edge is moving.
And if that upper edge is the
closer edge to the screen, it
looks kind of silly as the zero
point in the middle of the
screen is fixed but the other
one is moving.
So, you need to change it if you
align the scale view to another
page.
In using this simple APIs, the
muted standard map and exposed
map controls, we can take this
fictional bike sharing
application that we look at
today.
It is an application that allows
us to share unicycles and
tricycles in the San Francisco
area.
We can take this application
that is a little bit dated and
making it slightly more modern.
Now, let's look at that one more
time.
It was a little bit small of a
difference maybe.
We can take the slightly dated
application and bring it to the
future.
As we see here, the big
difference might not necessarily
have been the map mode and the
controls.
The important part on your maps
in your application is your
data, your annotations,
overlays, etc. And this is what
we are going to focus on next.
The standard way to display our
annotations has been the pin
annotation view since I was two
days.
The pin annotation view comes in
two different states.
We have the normal state when we
show it on a map and it's a pin.
And the user can tap on it or we
can programmatically select it
and it becomes the selected
state with a callout and show
the title and subtitle.
There is a little drawback here
and that is we only display the
title and subtitle if the pin is
selected.
So, as a user, you have to tap
on everything to see what they
actually are, which is a little
bit cumbersome.
So, as you saw in Maps app from
iOS 10, we use something that
looks a little bit like this
instead.
And with iOS 11, it's available
also to you.
We call it the
MarkerAnnotationView.
It is a AnnotationView subclass,
so it's a sibling to the pin
annotation view.
And we think you're going to
like it so much that it's the
new default for iOS and tvOS.
So, if you don't implement the
delegate callbacks for creating
them yourself, we will give you
a MarkerAnnotationView as
default if you recompile against
iOS 11.
The MarkerAnnotationView also
have two states.
We have the normal state which
will try to display the title as
well below the marker if there
is room on the map.
We have the selected state.
And in the selected state, we
also show the subtitle if there
is room for it.
And that way the user will at
the glance at the map, see what
are all of these data points
without having to tap on them
one at a time.
Now, there is one more thing.
We have to go back to the pin
one more time.
If we look at this pin and the
callout, there is one small
little thing in the callout.
You can add accessory views to
them.
You can add detail views to
them.
You can configure them.
And MarkerAnnotationView is an
annotation view.
So, all the API from annotation
views are supported for
MarkerAnnotationViews as well.
And if you add a in this case a
right accessory view to the
callout, then there is no
natural location within the big
marker where you can display
that data.
And it's even more obvious if we
think about the detail view
where you can put endless amount
of data, a lot of data, a full
placecard of your item if you
want.
So, what do we do in that case?
We have to use a third state of
the MarkerAnnotationView.
So, in practice, your
MarkerAnnotationViews have three
states.
We have the normal state when
it's unselected.
We have the selected state.
And the selected with callout
state which we will use if you
configure the marker annotation
with views that cannot be
displayed in the marker alone.
And with that, let's look at the
code.
This is the
MarkerAnnotationView.
The MarkerAnnotationView first
and foremost you have the titles
and you can configure the titles
that are displayed below it.
And notice that we yet again see
this three-state enumeration,
the feature visibility.
Because you can configure it in
many different ways, not only
visible and hidden.
The hidden obvious.
We don't show it.
The visible is also obvious.
We will always try to display
the title and the subtitle if
you configure them to be
visible.
Do note, I say we will try.
If the map is dense with data,
we will opt to hide the titles
to unclutter the map and display
more information as needed.
So, we will display them most of
the time but they can be hidden.
And in the last visibility we
have is the adaptive mode.
The adaptive mode is also the
default mode which gives you
that for free option for the
subtitle, especially where we
will hide it when it's in normal
state and display it when you're
in selected state.
So, that is the title below the
marker.
Next up we have the markers
themselves that you can also
configure.
First with the color.
So, there's the marker tint
color and the glyph tint color.
The marker color is the color of
the marker itself.
It is a normal UI color.
The default value is a nil value
which will pick a system
default, which is currently a
slightly reddish color.
You can set it to any other
color you want, for example why
not orange.
Do note that we call it marker
tint color, not just color.
And that is because the color
you provide might not be the
color, the exact color that we
use in the end.
We may apply some visual effects
on the color to make it look
nicer.
So, it's a tint that you're
applying.
And you can even use the new in
iOS asset catalog name colors of
course.
And the same thing for the glyph
tint color which is instead the
color of the glyph within the
marker which is defaulting to
white pin in this case.
Speaking of the glyph.
You want to configure also what
is inside of the marker, the
little glyph in it.
And the easiest way to do it is
by using the glyph text
property.
It's a simple string.
We see a pattern here.
It defaults to nil.
And when it defaults to nil, we
pick a system default which is a
pin.
It's a pin in a balloon.
It might be dangerous, but it
works.
And you can set it to any text
you want.
You might want to grade your
annotations.
You can even use the characters
or the Unicode standard to get
vector graphics for free.
Now, glyph text is a string.
So, you can set it to any text
you want.
If you want, you can put the old
iliad into it and we will try to
render it.
But it will look silly.
We will try to shrink down the
text as much as possible but the
user will not really be able to
read what is on screen.
So, as a rule of thumb, please
try to limit yourself to around
two to three characters.
And not everything though his
representable by characters or
text.
Not even with the full Unicode
standard being expanded every
year.
So, you might want to use your
own image graphics.
And for that we have glyph image
and the selected glyph image
properties.
The glyph image property is the
only property that you probably
will want to use most of the
time.
And you just give it an image
that is 40 x 40 points.
And when, which is used in the
selected state.
And then for the normal state,
we will shrink it down to 20 x
20.
Which works most of the time,
unless the graphics you have is
quite detailed, since then you
can get graphical scaling
artifacts as we scale it down.
And if that is the case, you
need to use both of the
properties.
So, for the small glyph image,
you can provide the smaller 20 x
20.
And for the larger one you give
it the bigger 40 x 40.
We will cross fade between the
two and you get that crispiness,
both in the normal and selective
states.
And using that, we can get this
much, much more modern-looking
application.
Now, this application though is,
if I have to say so, a little
bit cluttered.
You might want to clean it up
and have it easier to look at
and find what you actually want.
You want it to look a little bit
more like this.
And there is one single property
that we add in iOS 11 to do
this.
We call it the display priority
where we can tell annotation
views what priority are you in
order to display on the screen.
The feature display priority is
modeled after the layout
constraint priorities from UIKit
and MapKit.
Which means it's a floating
point range between a 0 and 1000
where 1000 is the required
value.
And if we look at what they do,
required means opt out.
Do not occlude or hide anything
as the annotation views overlap.
Do nothing.
But if you set the display
priority property to anything
else, like the provider
defaults.
Default high which is 750 and
default low 250, yes, that's the
layout constraints.
Then, you get these annotations
hiding.
And you can get from the, oops.
That is not what I meant.
So, being a floating point value
from 0 to 1000 means that you
can use it for nice things.
If you for example map your
display priority to the
popularity of your items.
So, you have a high, a very
popular item get the high
display priority and a less
popular item get a lower display
priority, that would mean as the
user is zoomed out on a high
level and looking at the whole
city, the most popular items are
the one that is remaining on
screen and visible.
And as the user zooms in, you
see also all the other data.
Which allows you to go from this
very cluttered map to something
that is a lot cleaner.
Now, if you do the popularity
thing and hide all the data,
then yes all the data is hidden.
So, the user will have to zoom
in a bit to actually find it and
then zoom out again to see the
rest of it.
And there is a better way to do
it.
What we could do is just cluster
the annotations and say that
yes, here we have 11 more and
here is 8 more.
You don't have to zoom in.
Well show you.
And the API for this is just as
simple as the API for display
priority.
We call it a clustering
identifier.
It is a string, so you can set
it to anything you want.
It is modeled after the reuse
identifier.
Both annotations views, your
table view cells and collection
view cells.
So, that you can have groups.
In the case of our application,
the bike sharing application, it
might be that we want to cluster
unicycles with unicycles and
tricycles with tricycles, but we
don't want to mix them together.
And if you can achieve that but
give them those annotation views
different but distinct
clustering identifiers.
So, as you use it, the default
tis nil.
If you set it to nil, you opt
out and nothing happens.
And if you set it to any other
string, all annotations sharing
the same annotation view are
illegible for being clustered
into a group as they overlap.
This is a very powerful and
beautiful feature but a little
bit hard to explain.
So, let me switch over to the
demo machine and show it to you
instead.
There is the demo machine.
So, in this little sample app, I
have four annotations.
I have a unicycle and a second
unicycle that share one
clustering identifier.
And I have another tricycle and
a tricycle sharing a second
identifier.
If I move them together, we'll
see their cluster.
And if I drag them apart, they
decluster again.
Now, all four of these have the
same display priority.
So, all four have the same
display priority.
When I group them together, the
cluster will get the display
priority of the highest display
priority within the group.
So, in practice, this means that
in this example, both of them
still have the same display
priority.
And when I move them even
further together, they collide
and they hide each other.
Move them out again and they
hide each other.
Now, if two annotation views
have the same display priority,
which one should we hide?
And there is logic to it.
If we rotate the map a little
bit and move them together, we
see we are still hiding the
green one.
If we rotate 180 degrees and
move them together, we notice
the orange one is the one
getting hidden.
So, the logic here is if they
have the same display priority,
we hide the one that is closest
to the top of the screen.
Which is good for developers and
users because you can see,
expect what is going to happen
next.
But one of the many reasons this
was done, I have to say if we
tilt the map into 3D mode, it
looks kind of cool as you rotate
in the annotation behind the
other one.
Now, let's zoom out a bit and
drop another annotation on the
map.
Being in annotation view, you
inherit all the APIs from
annotation view including
dragging.
So, I can pick it up and drop it
down again.
I can pick it up, drag it around
and drop it down again.
[ Applause ]
Did you notice something
happening there as I dropped it
down close to beach street?
So, look closely as I pick it up
and drop it down on Dollar
Rent-A-Car.
It gets hidden.
If you set the display priority
on annotation views, you will
also, we will also try to
collide out items and labels on
the base map for you to keep the
map even more uncluttered.
So, I can pick it up and why not
drag it down, drop it down on
another annotation and they
merge in one smooth animation.
All of these are actually
draggable.
So, I can pick them up and pick
them up, which is not true.
Because the cluster itself is
not draggable.
In order to be a draggable
annotation, you need to have a
coordinate.
And a cluster doesn't have a
coordinate on its own.
The geographical coordinate for
the cluster is the average of
all the member annotations that
is currently encompassing.
And that is why you can't drag
it.
But back to the slides.
It's a simple and powerful API
that allows you to go from this
cluttered mess to something a
little bit more clutter
cleanliness.
And this is good, since now we
see there are 11 annotations up
there and we have two more up
there.
And, but we don't really see
what kind of annotations are
there.
So, being unicycles and
tricycles, I really don't want
to go to a location where there
is only unicycles.
Because I haven't bothered to
learn to ride one yet so I want
to make sure I go to a place
with tricycles only.
So, we want to have the clusters
display at the glance what kind
of data do they contain at this
location.
And that we can do by doing our
own custom annotation views.
So, we can display it as a
little pie chart.
And I can see, yeah, there are
at least two tricycles there.
It's safe, I can go there.
How do we do this?
We have to go to our good old
friend the map view for
annotation delegate callback.
This delegate callbacks has
always provided a system
annotation for you.
The user location annotation
which is the representation of
where is the user currently in
the world.
And you can either return nil
value and you get the default
pack.
Or you could return your own
custom annotation and display
the user location in a
completely different way that
fits your application needs.
And for everything else you DQ
create your annotation view and
return it.
If you return nil, you get the
system default which, in iOS 11,
is the MarkerAnnotationView.
Now, in iOS 11, you will also
get one more different kind of
annotation, system annotation in
your callbacks.
You might get this
ClusterAnnotation.
So, if you opt into clustering
and they collide, there is not a
new delegate callback.
We reuse the existing callback,
give you a ClusterAnnotation
that represents the cluster, and
you can return the
AnnotationView that you want.
The ClusterAnnotation is a
simple concrete class of the
annotation protocol.
It provides you an array of all
the member annotations.
It's a flat array, so we
guarantee that there will be no
clusters within clusters within
clusters.
It's a flat array of all the
annotations that is currently
representing and only those.
We order it so the one with the
highest display priority is
first.
So, if you, as I said
previously, using display
priority and mapping it with
popularity, you will get the
most popular one at the start.
The MarkerAnnotationView placed
well with the ClusterAnnotation.
So, we will display the count
there as the glyph.
So, you can see at a glance how
many there are.
We will also, for the title and
subtitle, provide good default.
So, the title will be the title
of the most popular one or the
first member annotation.
And the subtitle is a localized
plus X number or more how many
annotations you want to have.
Both of these properties are
mutable, so you can change them
anytime you want and provide
something else.
We might want to change it and
have, say, three unicycles and
two tricycles and then you can
see at the subtitle what it is
without doing a custom
AnnotationView.
But you might want to do that
custom AnnotationView.
So, custom AnnotationViews.
Let's look at this little pie
chart.
A AnnotationVview is a view.
A view has a frame.
And the underlying thing that
drives both display priority to
hiding things and clustering is
that annotations must be able to
detect if they are overlapping.
And since we are views and we
have a frame, we can just use
that frame and detect a
collision.
Now this doesn't look good.
I mean, they're circles, yes.
The frames are colliding but
visually they are not really
colliding yet.
So, this is not quite what we
want.
So, we add one more property on
AnnotationView.
We call it collisionMode.
The default value is rectangle.
So, we have to use the frame.
The other option we have is
circle.
Where we use the inscribed
circle of the frame for the
annotation.
And now when we move them
together, they collide and
detect a collision when they are
visually colliding.
Now, not all AnnotationViews are
perfect boxes.
Some of them are actually
rectangles.
And for collisionMode rectangle,
yes, the collision is with the
rectangle.
But if you change it to the
circle, it is a circle.
So, we use the inscribed circle
in the rectangle, not the
inscribed ellipses.
It's important to take a little
bit of note there.
So, not everything is rectangles
or circles either.
We might have something a little
bit more fancy, like
nice-looking 3D rendered golf
clubs for our golf application
that is displayed in flyover.
And as we tilt the map in 3D and
we move them together, we want
them to actually overlap a
little bit because it looks
cool.
It looks really nice, actually.
So, if we use just the
rectangles, they are way past
when we want them to detect
collision.
If we use the circles, no.
it doesn't really fit either.
I mean, what we really want is
something a little bit more
close to this which would be the
circle in the bottom with the
five-point outset option that we
did not give you [laughter].
You don't have that option,
sorry.
Instead, we went back to all the
way when outer layout was
introduced to both iOS and macOS
in the year before.
And you have the alignment
rectangle insets which are the
options that say that you can
configure if two views re to be
aligned next to each other, what
kind of insets would they use to
look visually pleasing?
Which is just what we're doing
here with the AnnotationViews,
right?
What is the visually pleasing
collision rectangle.
So, all you need to do.
Override it and you provide
offset.
So, for the top we can set it to
50 points and we move the
collision area down.
The left edge, 0, we don't need
to change it at all.
The bottom edge we move out by
negative 5, because we want an
outset, not an inset.
And then we do the right edge as
well.
And what we have is that little
circle in the bottom left outset
by 5 points, just as we wanted.
And when we now collide them, it
looks very visually pleasing.
Let's look at the code to
configure our custom
AnnotationViews.
And a few tips and tricks to
make our code base a little bit
more modern and nice.
There we go.
So, let's run the application
first so we see that it works.
Build succeeded.
Compiling.
It is running.
And we have the collision when
we move them together.
They collide out.
So, it works.
Now, looking at the code, we
have our mapView, viewFor
annotation.
The first thing we do is we
check if that is one of our own
annotations.
And if it is, we configure it a
lot to set it up.
And otherwise we check if it's
the system-provided
ClusterAnnotation.
And if it is, we configure it
differently.
And for the else case, we just
return nil to get the system
default.
Currently that would be called
for all the user locations, but
it might be that we add more
system annotations in the
future.
So, good take.
Don't check for user location by
default.
Do the else case, return nil,
and let the system do the right
thing for all the other cases.
Now, this is a lot of code, in
our view controller nonetheless,
and it doesn't really have
anything to do with how it's
going to be displayed or rather
it is all how it's going to be
displayed.
So, I don't think this should be
in the view controller.
So, if I grab here and drag in a
couple of views to my project, I
think that first of all I know I
need to add these files to the
target or it won't compile.
There we go.
Another good tip is in your
AnnotationViews, you can
override the set annotation
method and do the configuration
there.
So, here I have the same thing.
I know I will get a bike.
And if I get a bike, I configure
it, set it up, and be done with
it.
The, this will allow me to go
back here and delete all of
this.
No, actually, not that one.
And delete all of this, because
it's really not fitting there in
the view controller.
It gets a lot, lot smaller.
Another thing that might annoy
SWF developers is that this view
here is an optional.
We really don't want optionals.
So, we want it to be normal
required variable.
Now, the DQ reusable annotation
with view do return an optional.
But we fixed that and give you a
sibling.
The DQ reusable annotation with
identifier for annotation.
It is modeled after the DQ
methods on UITableView and
UICollectionView.
So, it will always return an
instance.
Let's give it a, oops.
Yeah. That's how you type.
And the annotation.
You might notice I did not have
US keyboard here.
And by doing that, we no longer
have to do the if check for did
we actually do it and create it
instead.
We don't have to set the
annotation, because we give it
to the initializer.
And we can just delete this.
Actually, let's go one further.
We can delete all of this.
We don't need that.
Because we can register our
AnnotationViews to use for reuse
identifiers.
So, just as with the TableViews
and CollectionViews, we have
tell the map view here, I want
to register.
And use the bike view class for
any view with the reuse
identifier that could be of your
choosing or one of the two
constants that we provide for
you.
The default annotation view
which we use for any single
annotation view created by the
system and the default
ClusterAnnotation view that we
use for any system annotation
view.
And now when we run it, it
compiles.
It runs. It launches.
And as we move them together
with no code, they merge.
And when we group them, we get
the nice little pie chart.
And that is a few tips and
tricks for how to make
AnnotationViews a lot easier.
Let's go back to the slides.
[ Applause ]
So, thank you for being here.
Today we covered a lot of
things.
First we have the new map type,
the muted standard, that allows
your data to stand out on your
map in your application.
We give you all of the map
controls as proper views so you
can configure in to display them
where and when it makes sense
with the context of your
applications.
We have the new
MarkerAnnotationView that
displays a lot more information
about your data at a glance
without having to dig in and out
of the data all the time.
And the MarkerAnnotationView
works beautiful with the new
APIs for display priority and
clustering to get your data a
lot more nicer looking and less
cluttered map.
For more information, go to this
website.
There is also the sample code
for the application I've been
showing you today.
Please play around with it and
see what great things can be
done.
I'm very excited to see what you
will do with this.
Also, go back and watch the
videos for What's New in
Location Technologies from
yesterday.
And What's New in MapKit from
2015.
Thank you very much.
[ Applause ]