Transcript
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
>> Good morning.
My name is Jon Lee.
I am a manager on the
Safari and WebKit team.
This is Session 614 and
you are here to learn
about Implementing OS X Push
Notifications for Websites.
You know, since iOS 3 and
OS X Lion, you've been able
to integrate push notifications
into your native apps.
And boy, do users love them.
Apple has sent over 7.4 trillion
push notifications to users.
So, clearly, users love
getting push notifications
on their devices.
So why is that?
Well, I love push notifications
because push notifications
gives me the information
that I really want to know
about and the app tells me
that information at
the best time it is
for me get it which
is immediately.
I don't have to open
up the app every time
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that I want to see an update.
So, like for example I was
doing a dress rehearsal
for this session last week
and I was having some trouble
finding the conference room
that I needed to be at, and so I
was trying to go through my mail
to find those directions to
get to the conference room.
And a friend of mine actually
texted me, telling me exactly
where I needed to go and that
was great because I didn't have
to be in the messages app in
that conversation in order
to be able to know where
to go and for me to get
to my dress rehearsal on time.
Push notifications are fantastic
because even if I'm asleep
or my phone's on silent, or
it's just not a good time for me
to attend to my phone,
I know that all those
notification are going
to be grouped to in
Notifications Center
and that place is
super easy to access.
Anywhere on iOS, I can
just swipe down on my phone
and I will see that
push notifications
that were most recently posted
per app grouped together
in Notifications Center.
And this is great, not
just because I know exactly
where to go to get
my notifications,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
but because seeing
the collection
of those notifications
per app kind of gives me--
it tells me a story, it
gives me some context
about what the app
is trying to tell me.
And if one of those
notifications are of interest
to me, I can just swipe on
that notification or tap on it
and iOS will take me
right back to the app
and show me more details
about that notification.
Finally, I love push
notifications because I get
to fully control when
and how I receive them.
So, like I want to install
a new app and I launch it,
I don't automatically
get subscribed
to that app's push
notifications, I get asked.
And if I accept the invitation
to get those push notifications
and the app ends up
sending me too many of them,
I have so many different
choices.
The app might provide me
some granularity over like
when I want to receive
those push notifications.
I could turn those
notifications off completely.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
If it's just that
the time isn't right,
I can turn on "do not disturb"
or as a last resort
I could delete
or uninstall the
app on my phone.
So, those are the reasons that I
love push notifications for all
of the native apps
that you write.
But I bet for many of you,
not only do you have
amazing native apps,
but you also have
amazing websites.
So, new in Safari 7 on OS X
Mavericks, I'm really excited
to announce that your website
can now send push notifications
to your Mac users.
This is great because just
like push notifications
on native apps, your users
can fully control when
and how they receive
their push notifications.
And push notifications are just
the thing to put in your website
to get users to return
to your website.
And for those of you with
websites that are ad supported,
that means real revenue.
So, in this morning
session, I like to go
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
through the four things.
The first is to get some
background about notifications.
The second is to learn how
it works behind the scenes.
And third is to see how
to implement push
notifications for your website.
And the fourth is to talk
about some best practices.
So, let's get started.
One thing you may
not already know is
that you actually can
send notifications
to your websites on-- can send
notifications to your users
on their desktop in
Safari 6 on Mountain Lion.
They're called "Local Web
Notifications" and it's based
on the specification by the W3C
Web Notification Working Group.
Local Web Notifications and
Push Notifications are websites
that are actually
quite different
from like assistance
perspective.
So when the user goes
to your web page,
your web page will
contain some JavaScript
that actually tell Safari
to send those notifications
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to the user's Notification
Center.
Whereas with push notifications,
it's actually your server,
which we call a Push Server
that send those notifications
to a service that Apple controls
called Apple Push Notification
Service or APNS.
And APNS knows how to directly
connect to your user's Mac
to send that push notification.
But more than just from
like assistance perspective,
local notifications
and push notifications
on websites are actually
managed very differently for--
on the user's Macs.
For example, a web page can only
send a notification while the
user is open to your website.
Whereas with push notifications,
they can be send at any time.
The user doesn't have
to be on your website.
The user doesn't even
have to have Safari open.
And likewise, if the user
exits out of your website
or quit Safari, all
the local notifications
that you posted actually
disappear.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Whereas with push notifications,
it doesn't matter,
they're always are right for
them for your users to see.
Next, the notifications
that get shown
on the desktop are a little--
are presented a little
bit differently.
For local notifications, because
it's Safari that's sending those
notifications that actually
gets the Safari icon,
and to give some more
detail about like
where that notification
came from, we kind of put
in the subtitle of the
notification, your domain name.
A contrast that would
push notifications
which actually use your website
icons, so there's no need
to have kind of add this extra
information, they know exactly
where that push notification
came from.
Next, local notifications end
up all being group underneath
the section for Safari,
which means that like if the
user has a lot of websites open
that are using local
notifications, they all end
up getting kind of
shuffled together
and your notification
might get lost in the mix.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Contrast that with
push notifications,
your website actually gets
its own dedicated center
in Notification Center.
So, you website is actually
treated just the same
as your apps.
Finally, when you click
on a notification,
for local notifications,
it actually takes the user
to the tab that actually
sent that notification
that makes it front most
on the user's desktop.
With push notifications,
since Safari might not have--
be actually be open, clicking
on that notification is exactly
like clicking on a link.
And so, it just opens it up
to your website to a web page
that provides more detail
about that notification.
All right, so we just
talked about the differences
between push notification--
local notifications and push
notifications for websites.
What about the difference
between push notifications
for your native apps and push
notifications for websites?
Well, you don't even
have to worry
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
about memorizing this table
because they're actually
the same.
We've done everything we
can from your point of view
as a developer to make
push notifications
between your native app and your
website the exact same thing.
So, just to go through it
quickly, for native apps
and websites, your push
notifications can be delivered
at any time, the Apple website
does not have to be open.
The notification gets labeled
with your app or websites' icon.
They get grouped together
based on their app or website
to their own dedicated section
and Notification Center,
and clicking on them opens up
the app or the website to take--
to give them more detail
about that notification.
So, my last thing
about background,
I just kind of wanted to talk
about how the operating system,
make sure that nobody else is
trying to forge anything you do
and talking about basically
verifying your identity.
And the best way to talk
about this with respect
to push notifications
for website is
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to see how it works in apps.
So, in order for user to
have push notifications
for your apps, there are two
things that you need, right?
You need your app that you've
submitted to the App Store
and then you need your
server, your push server
that actually sends
those push notifications
to the user's devices.
So how does Apple
know that the app
and the server actually
both come from you?
Well, Apple does this through
the use of certificates.
With the private key of a
certificate that you get
from the developer portal, you
can create a digital signature
that only you can create and
that Apple verifies in order
to make sure that you
are who you say you are.
And when it's time to actually
send a push notification
to APNS, your push server uses
a second certificate but also
from the developer portal to
that-- to connect to APNS.
And when those notifications
are sent, APNS knows that--
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
from that certificate that you--
that the push notifications
are coming from you.
So together, Apple knows that it
is you that's controlling your
user's experience with your
app and its push notifications.
So now, what about
website identity?
You don't bundle your
website together, right?
Like anybody can
create a website
and you don't submit
your website
to a Apple Website Store.
So how does Apple
know that it is you
and that you are authorized
to actually send
push notifications?
Well, what we do is we ask your
web server to create an identity
that represents your website and
we call that a "push package".
And it's that push package
that you sign using something
that we call a website
Push Certificate
and you create your digital
signature and this signature
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and the push package
gets sent to Safari
and Safari will actually
do that check to make sure
that you are authorized to
send push notifications.
And then when it's time to send
those notifications to APNS,
you use that exact
same certificate
to connect to the service.
So it's actually easier to
implement push notifications
on websites because you only
have to manage one cert whereas
with apps, you have
to manage two.
All right, so that's a
little about the background.
Let's talk about how it works.
I'm going to take your through
two important things I need
to happen.
If you understand
these two things,
you understand the feature.
The first is how users subscribe
to your website's
push notifications.
So, once you've adopted the
feature, websites that go
to your website-- users that
go to your website on Safari 7,
on Mavericks, will see an
invitation to subscribe
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to your website's
push notification.
If they accept that invitation,
Safari will then
contact your server
for your service credentials.
And you're going to return
those credentials in the form
of that push package that
I talked about earlier.
Safari will then validate
the data in your push package
and verify your identity.
And if that succeeds, then
it's going to prompt the user
to confirm their subscription.
When the user confirms that
they want to subscribe,
then Safari will send
something called a device token
to your server and
tells your server
to register that device token.
And this device token is just a
string that Apple uses in order
to target that users Mac.
By the way, if the user wants to
change their and then they want
to unsubscribe from
your push notifications,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
they can go Safari preferences
and they click a
little radio button
that says they deny
permission, meaning they want
to unsubscribe, and then Safari
will make that exact same call
of the device token except
this time it'll tell you
to un-register and we
expect you to delete
that device token
from your server.
OK. So that's the first.
The second thing was-- is
about delivering those
push notifications.
So, now that your server
has the device token
and the notification
itself called the
"Message Payload"
we combine them
and create what we call
notification packet
and you're going to
deliver that to APNS
over a secure protocol using
that website push certificate.
APNS looks at the device token
and knows exactly how to connect
to the users Mac and that
notification gets displayed
in the user's Notification
Center.
If the user decides to
click on that notification,
it's just like clicking on
a link, so it takes them
to a web page in Safari or the
user's default web browser.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
OK. So we talked about
these two things,
let's see how they
work in action.
So I'd like to bring
up Brian Weinstein,
the engineer on the Safari team.
>> Thanks Jon.
Now, I am Brian Weinstein, an
engineer of the Safari team
and I'm going to show you what--
how interacting with push
notifications will work
for your users.
So, we've made up
a website to show
of this feature,
bayairlines.com.
And I have a flight to Boston
later tonight and I would
like to be updated about
information about my flight.
So, as you can see we have
a visual affordance to sign
up for push notifications
and when you click the
Subscribe button, we show--
Safari shows an alert asking
me whether or not I would
like to subscribe for
push notifications.
And it is branded
with the websites icon
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and the website's name.
When I choose Allow, you can see
that the user interface
has automatically updated
to give me some preferences
for what kind
of notifications I
would like to listen to.
So, let's say I'm at the
airport, I'm having some food
and I would just like to
know when my gate changes
so I can find out if I need
to head somewhere else.
What I can do is I can
subscribe for notifications
when my boarding gate is changed
and then I can just quit Safari.
And what's so powerful about
these push notifications is
that they can be delivered
even when Safari isn't running.
And you can see that I
was given a gate change
and it gives me the new gate.
And if I want to find a little
more about that notification,
I can open up Notification
Center, select the Notification
and it will launch Safari
and give me even
more information
about my gate change.
And some other things that are
great about push notifications
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
for websites is that they
are first class citizens
in the rest of Mavericks UI.
So, if I open the
notifications preference pane,
you can see that Bay Airlines
is listed right alongside all
of the other apps with
your website icon.
And this is where you can change
how you can configure how your
alerts are delivered either
in better form or alert form,
and you can also look at--
you can also adjust how
many notifications you see
in Notification Center.
And if you want to change
your notification preferences
altogether in terms of
unsubscribing or subscribing,
you do that through
Safari's preferences
where every website
you signed up for--
I've signed up for
push notifications
for are listed here
and I can either Allow
or Deny push notifications
through there.
And so, that is what
push notifications
for websites looks like.
And now we're going to
learn a little bit more
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
about how to implement it.
And now, I'd like to
hand it back to Jon.
[applause]
>> So we've learned a little bit
about how it works behind
the scenes, let's figure
out how to implement it.
There are two things
that you need to do.
The first is actually
to get a certificate
from the developer portal.
And don't worry, I will
take you through every step
to get those-- that certificate.
And the second thing is you need
to add notification
support to your server.
And what do I mean by that?
Well, the server actually kind
of serves three different roles
and you need to implement
support for each of those roles.
The first is you need to ask
the user on your website,
you need to invite
them to subscribe
to your push notifications.
You need to write a web
service back end and then
when it's time you need to
send them push notifications.
But a better way to kind of
think about these three tasks is
that the first is how
your website communicates
to your users that you've
got this great feature,
the second is how
Safari communicates
with your web server, and the
third is how your web server
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
communicates with APNS to
deliver those notifications.
So first, let's talk about
getting that Push certificate.
Getting a push certificate,
super simple, it's
just two steps.
One, you have to
Register a put--
website Push ID and
the second it
to create a certificate
based on that push ID.
So, in the developer portal,
you go to the certificate's
identifiers and profiles page
and on the left hand side
you will see a new item
that allows you to
register a website push ID,
just click on that Plus button
in the upper right hand corner
and you'll be taken to a
form where you need to put
in two pieces of information.
Both of these pieces of
information are just names.
It's just for different
audiences.
So the first one is just
human readable description
and this description
is just for you.
It'll be used throughout
the developer portal
but Safari won't see it,
your users won't see it,
your server won't see it.
The second is how your--
how the code actually knows
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
about your website or can
identify your website.
And we recommend the use
a reverse domain string.
The developer portal will
make sure that it's got
that web prefix, and that's it.
We just registered the push ID.
Now, let's create
the certificate.
So, you're going
to go into settings
and you see these
detailed instructions
of creating a certificate
signing request.
And the certificates I knew in
quest will create a private key
that you will use to sign
your push package as well
as the certificate itself you'll
be creating to connect to APNS.
So, it's going to create a file,
you're to upload that file,
and you've got your certificate.
But the certificate is in
a format that actually--
that's actually not
what we need in order
to actually sign
our push package.
So for that, install
the certificate
in a keychain access.
Right click on it and you want
to export that certificate
to a P12 file, and that--
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
it's that representation of your
certificate that you will use
in order to sign
your push package.
OK. So now we got
the certificate.
Next, it's time to
do the fun stuff.
It's time to do some coding.
So, the first thing is to
invite your users to subscribe
to push notifications
on your website.
So we've created two
new JavaScript APIs
that you use on your webpage.
The first is to see if the user
has been asked before already
and if not, you use the second
API which is to ask them.
So, let's take a look
at the first one.
You're going to call
window.safari.
pushNotification.permission
and you're going to pass
in the website push ID which
is that push ID that you used
in order to create you website
push certificate, right?
It's a synchronous
call and it's going
to return a JavaScript object
that has a permission property
and that property can have
three different values.
The first is default which means
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that the user has never
been asked before.
The second is denied, where
the user has been asked before
but they said they did
not want to subscribe.
It's when in that modal
dialog you said, "don't allow"
so the user clicked on Don't
Allow, and the third is
when they click Allow and they
confirmed their subscription
and in that case you'll see that
the permission has been granted.
And if the permission
is granted,
they'll be a second property
which contains the
user's device token.
And you can use this
device token in order
to change your website UI
to give your users some more
granularity over the kinds
of push notifications
that they receive.
So, in the demo that
we just saw,
it's like seeing the
different kinds of reminders
that Brian wanted
to get notified of.
Now let's say that the user
has never been asked before.
So the permission will be
default, that first one, right?
So, next we have to
actually request permission.
And for that, you call
window.safari.push
Notification.requestPermission,
it's an asynchronous call
and you're going to call--
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you're going to pass
in four parameters.
The first is the URL to your web
service, so it's that second--
the second thing that
you have to implement.
It must be-- it must
support HTTPS
and this represents the base URL
to your web service and I'll get
into how to implement
that web service later.
The second is the push ID
which you've seen before.
The third is something
that we added for you guys
and we're calling it userInfo
which should sound familiar
for those of you
who use Cocoa APIs.
It's just simply a way
for your website to talk
to your web service
because you recognize
that you might have those
two roles implemented
on separate hardware.
It's basically just a
simple dictionary of strings
and you can put anything
in there
to help you identify the user
that's logged in to your website
or maybe some preferences
that they want in terms
of the notifications they
receive or even the language
in which they want to
receive those notifications.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Finally, you're going to
pass a callback function
that will get invoked when
the user has finally made
a decision.
Like when the modal dropped
down, a dialogue appears
and they decide one
way or the other.
We will invoke this callback and
pass in that permissions object
that you saw for the
first JavaScript API.
In the case that the user
confirms, you're going
to see the granted permission
and that device token.
In the case that they said
"no" you're just going
to see the denied permission
cause you don't need the device
token in that case.
All right, so we've asked users
on your website to subscribe.
Now, it's time to write
that web service back end.
So, let's review
how users subscribe
to your push notifications,
so bring up that diagram.
So any arrow that you
see going from Safari
to the server represents an
endpoint that you're going
to have to implement in order--
that you're going to have to
implement in your web service.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So the first is when Safari
contacts your web service
in order to get that
push package,
when that push package
has returned
and Safari will do a validation
and if anything went wrong
during that validation,
it will then contact your--
the second endpoint and
tell your what went wrong.
But if everything succeeds
and the user confirms their
subscription then it will
contact the third endpoint
where we register the device
token to your web service.
There is a fourth endpoint
that's not in this diagram
and that's when the
user changes her mind
and decides to unsubscribe.
We make a very similar call
except instead of saying
where register device token
we say un-register this
device token.
So let's talk about
that first line
about getting that push package.
You can think of this as being
Safari just calling a function,
except the function is in the
format of an HTTP request.
And this function contains
two different parameters.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
The first is the websitePushID
and the second is that userInfo
from the request permission call
but serialized as
a query string.
.So for many of you that
only have one website,
you can basically ignore
the first one 'cause the
websitePushID will
always be the same.
But the second one, you
might want to pay attention
to in order to be able to
tailor the push package
that you return.
So, just to review, here's
that requestPermission call,
that third parameter, userInfo.
Here's an example
of what I could--
we could pass in for
the Bay Airlines site.
We pass in the log in
of the user as well
as their frequentFlyerID
and that will get converted
by Safari to this string,
it looks like a query string
and that will be
in the HTTP body
in the requester
your web service.
So, when this endpoint is
called, we expect your server
to create that push package
and what does that look like?
Well, if push package is nothing
more than a zipped archive
of a whole bunch
of files formatted
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and structured in
a specific way.
And for those of you who have
some familiarity with Passbook,
you might recognize that
this actually follows the way
that passes are constructed.
So the first set of files are
just the icons representing
your website.
This will be used
throughout the UI
and you'll see how
they map later.
The second is a file
that we call website.json
and it's a dictionary with
information about your website.
Let's drill down a
little bit into it.
The first two you've
seen already.
It's the URL to your web service
and the second is
your websitePushID.
The third is your websiteName
and this will be used in the UI
when we ask the user to
confirm their subscription
or in Notification Center.
The fourth is what we
called allowedDomains
and it's just a list of
domains that are allowed
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to request permission from
your users to subscribe
to your website's
push notifications.
So why would we add
something like this here?
Well, it's to prevent somebody
trying to spoof your website
from being able to get
those device tokens
and sent push notifications
on your behalf.
So, one way that a spoofer could
try to pretend to be you is
to take this push package
that you would normally serve
and serve that to users instead.
But what will happen is during
the verification algorithm,
Safari will take a
look at the domain
that was making the request
for the permission and compare
that against this list.
And so, in the case of
the spoofing website,
that website won't be here
so therefore Safari won't--
Safari will fail and
you'll be notified of that.
So really, this-- having this
list here is a way for you
to protect yourself against
people who are going to try to--
or going to try to forge
your notifications.
Next is what we call
an authenticationToken
and it's similar in its
purpose to userInfo.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Remember that with userInfo,
we were saying it's just a way
for your website to talk
to your web service.
This is a way for your web
service to talk back to itself
because the web service,
we don't expect
to maintain any sort of state.
So, when the user changes their
mind about their subscription
to push notifications, you need
a way to identify that user
and so you can use this
authenticationToken to do that.
Finally, we include
urlFormatString
and the reason why we
included this here is because,
like I said, like when you
click on that notification it's
like clicking on a link.
Well, so the notification
is going to have that URL.
But for many websites,
that URL is really long
and because notifications
payloads can only have a limited
size, those URLs might actually
take up all the space available,
and so you won't have any
room for your notifications.
So, we have this here as
a way for you to be able
to reduce the amount of
space that your URL needs
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in the notification
and you'll see
that it's formatted very
similar to strings in Cocoa.
OK. So we just talked
about the things that kind
of describe your website.
The next two pieces are
how Safari can validate
your identify.
So the first thing is a
manifest.json, it's a dictionary
of all of the files
we just talked
about that contains
references to all the files
that we just talked about
and the SHA1 checksums.
And this is kind of
what that looks like.
As you see it, the keys are all
relative passed to those files
and then the values
are the checksums
and I've truncated them
here for readability.
So why would we do
something like this?
Well, if a spoofer try to change
your icon or change the name
of your website, when Safari
does its validation algorithm,
it's going to find
that the checksums
for those files are not going to
match what you have here, right?
So that's how we-- that's the
reason why we have this file.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And then finally,
you're going to sign
that manifest using
the private key
of your website push
certificate.
And we do this because when
the push package gets sent
to Safari, it will check the
signature against the manifest
and if they don't match,
that means that some other
developers try to sign it
with an invalid certificate.
OK. So now, that's the push
package, you zip that up
and you send that
back to Safari.
Safari will then validate kind
of checking all the
things that I talked about.
And if anything went wrong
like a file is malformed
or there is a typo
in the website.json,
we will then contact
a logging endpoint
and that's the second endpoint
to report what went wrong.
And super simple, it's what--
this is what it looks like,
and you'll notice that
the body is just formatted
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
like a JSON object
that contains list
of the human readable
strengths explaining
like what exactly went wrong.
But hopefully, you have a
major push package correctly
and so we prompt and confirm.
And at this point, that we
can actually see how elements
in the push package
map to the UI.
So just briefly, here's
that dialogue that Brian saw
when he clicked on that
Subscribed Button and you'll see
that the icon comes from the
icons in the push package
and the websiteName and
the website.json map
into the text asking
the user to subscribe.
OK. So now, the user
says I want your--
I want Bay Airlines push
notifications so now it's time
for Safari to send that device
token over to your web service.
And this is what
that call looks like.
There are three pieces
of information.
The first is the
deviceToken itself
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and that's what you're going to
want to store in your databases.
The second is the websitePushID
which again for those of you
with just one website,
you can just ignore that.
And the third is the
authenticationToken that you put
in that push package and
that's how your web server,
your web service knows who to
associate the device token with.
If the user changes their
mind because they don't want
to subscribe to your push
notifications anymore,
we actually make a request
to the exact same endpoint
except instead we use the HTTP
Delete Method so just
look for the method
and you'll know whether
to add that device token
to your databases or remove it.
And that's it.
That's all you need
to do in order
to implement your web service.
Now, it's time to send
those push notifications.
So those of you who had
experienced implementing push
notifications for Native
Apps, we'll be happy to learn
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that it works exactly the
same way for websites.
For those of you who are not
familiar, this is the format
that you send to APNS.
It looks like it's
JSON formatted,
and in that notification
you include the elements
that will be in the notification
so that includes the
title and the body.
And for those users who decide
to see your notifications
as alerts instead of banners,
then this action value
will override the title
in the Action button
in the notification.
And instead of having
custom data which you can do
with Native App Push
Notifications, we--
or you have the URL and that
URL can provide all the context
that you need in order to get--
in order to take your
users to the right detail.
So, here we've decided to
express it in terms of URL args
and the reason for that is
because we don't want you
to necessarily include the
entire URL 'cause it might be
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
too long and you
have a limited size
in your notification payload.
In fact, that payload
is limited to 256 bytes.
So be sure to take advantage
of that URL format string
in the push package.
And when you send
that notification,
make sure that you
always send it
to the APNS's Production
Environment.
There is no support for
pushing your notifications
to the Sandbox.
So now that we got the payload
and we have the push package
from earlier, we know now
how to construct everything.
So, in the notification
itself, the icons come
from your push package
and the title
and body come from the payload.
And for users who are
seeing your notification
as an alert will see your
Action button title override
that button.
The notification in Notification
Center will appear as such.
The header gets its
icon and website name
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
from your push package and the
actual notification itself comes
from the payload.
And when the user clicks
on that notification,
we combine the URL format
string from your push package
and the URL args from your
payload, combine them together
to make the final URL that takes
the user to see more details.
So, I'd like to bring Brian back
up to show you how these
all works behind the scenes.
>> Thanks, Jon.
So now we are going to look
at what happens when I use--
when I sign up for
push notifications
from the website's
point of view--
from the web server's
point of view.
So as you can see, we have a
terminal window open with some--
with the web service log
output from bayairlines.com
and we also-- as a little bonus,
we'll get to see what happens
if you happened to
make a mistake
in generating your push package.
So when I want to sign up
for push notifications,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
I will click the
Subscribe button and some--
and there is an issue with
the web server's push package.
As you can see, Safari sends
a request to V1 push packages
and then the website
identifier and we--
and then the web server
will log some user info
and send back a push package.
But as we can see, the push
package Safari did not validate
the push package
correctly and there was a--
and we send an issue
back to V1 log saying,
"Refer URL bayairlines.com
is not
in the list of allowed domains".
So, as Jon described
from earlier in the talk,
allowed domains are-- is in the
website.json file so let's open
that up and see what's in there.
And as you can see, we have
allowed domains it's just listed
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
as bayairline.com.
So, we very-- we just have
a simple typo, we just need
to add an S to make it
bayairlines.com, save it,
and what the Bay Airlines web
server will do is when you--
when we try and sign up
for push notifications,
the server will automatically
generate a push package based
on the files that are-- based
on the files on the file system.
So, we don't need to
generate a new push package,
it will be done automatically.
We can just reload the
web page and try again.
And that time it works
correctly and we were given--
we were told that we
were asked for permission
to sign up for notifications.
We click Allow and you
can-- and then when we--
when the user finished signing
up for push notifications,
we sent the device token to
the Bay Airlines web server
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and in the HTTP Authorize Header
we have the userInfo specified
in the push package.
Now, let's open up System
Preferences again because I want
to change my type
of alert and I want
to make it an alert
instead of a banner.
So now, let's say there's
Wi-Fi on the plane and I want
to be updated with the
weather for when I land.
So when I get notified of
weather, I want to be notified
of weather conditions
on the day of flight.
And as you can see, our
web server connected
to APNS using the
Production Environment
and deliver this message payload
giving me some more information
about the weather and it shows
up in Notification Center right
over here with-- and then
we can either just close the
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
notification or see more.
Now, if the user
decides to unsubscribe
from push notifications like
Bay Airlines lost their baggage
and they're never going to
fly them again, they can open
up Safari's Preferences and
switch over from Allow to Deny.
And as you can see, we
sent a delete request--
Safari sent a delete request
to the web server saying to--
telling the web server to
unsubscribe this device token
and not to send any
more push notifications
to this device token.
And if they happen to have
a great deal and you decide
to fly them again, you
can just click Allow
and we will send
back that same--
we will send back your
device token via that same--
we will send it to the web
server via that same endpoint.
So that is what your web
server will see when users sign
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
up for Push Notifications
or unsubscribe from them.
Now, let's hand it back to Jon.
[applause]
>> So, you now know
how to implement
and let's talk a little
bit about best practices.
So when it comes to
your notifications,
think about what
notifications can be most useful
to your users.
So all of you that like raise
your hands, you know what it's
like to get annoying
notifications.
Make sure that everything
that you're doing
to send notifications
to users informs them.
Remember that the push
notification service is the best
effort which means we're going
to do our best to deliver them
but there's not necessary
guaranteed
that they'll be delivered.
So think of these
push notifications
as an additional rather than a
primary means of communicating.
Next, remember to take advantage
of that URL format string.
Here is an example of
what we could have done
where the URL format string
in the push package was
something very generic
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and we put the entire URL
inside the notification payload.
Well, all that-- you know,
there's a pretty long URL
and so it's taking up space
that we could be using
to actually have in
the notification.
So, taking out what's common
among all of your URLs
and putting that inside
the URL format string means
that you save some space.
In this case, well, remember
to strip the white space
base from JSON payload.
So like in that slide before
with the notification payload
that I showed you, just taking
out that white space saved
like 40 bytes or
something like that which is
like half a sentence, right?
So, remember to do that.
Next to our best practices
for your web server,
remember that when users decide
to unsubscribe and we give--
and we touched that
unsubscribe endpoint,
just remove those tokens
from your web service.
We don't want you to be
wasting your precious resources
delivering push notifications
that will never get displayed.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Remember to take advantage of
the userInfo in the JavaScript
as well as the
authenticationToken
in push package in order for you
to be able to identify the user
that wants to register for
your push notifications.
And finally, the best
practices for your website.
So, think about the kind
of service that you want
to provide your users.
If your website is the kind
that just broadcast a common
notification to all the users,
then all you need
really is a like a file
or just a single database table
nothing but device tokens.
But if you want to
provide an experience
where users can really
tailor the way
that they use push notifications
on your website, you're going
to want to communicate the
User Log in on your website
and associate that
with the device token.
Remember that this is a
feature on Safari 7 on Mavericks
so you want to check for
API ability as an example
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of what that looks like.
And remember to ask users to
subscribe at the right time.
You don't know necessarily
how users have landed
on your website and
it's probably your--
and probably they're not going
to want to be asked immediately.
We recommend providing some
kind of switch that allows user
to like physically turn the--
physically turn on push
notifications on your website.
And in the Bay Airlines demo,
we did that through
a Subscribe button.
And finally, think about giving
your users some granularity.
It gives them the opportunity
to really tailor their
experience with your website.
In the Bay Airlines site,
there's multiple types
of notifications that Brian
could have subscribed to.
So for more information,
you can contact Jon Geleynse
and Paul Marcos, our
evangelists online.
There is the Local
and Push Notifications
for Developers page which
contains links to lot
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of different references
that give you more details
about notifications in general.
And for those of you
which should be all of you
that have access to the preview
of the developer publications,
there is a guide called
Notifications Programming Guide
for Websites that gives
much more detail about how
to implement push
notifications for your website.
And of course, there's
always the Safari Developer
for all of us.
So, push notifications
for websites is just one
of many awesome new
features in Safari.
I recommend listening to
Tuesday's video on What's New
in Safari WebKit
for Web Developers.
And as I mentioned before that,
push package is very similar
to the way that passes are made
and I would recommend you
listening to Wednesday's talk
on Integrating Passbook
into Your Ecosystem.
It's a really interesting
to talk
about how Apple Online
Store adopted passbook
and they have some
interesting uses
for that authenticationToken.
So just in summary, I'm really
please to announce that Safari 7
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
on Mavericks now
allows your website
to send push notifications
to your users.
And we've done everything we
can to make push notifications
for your website and those for
your apps the exact same thing.
Safari knows that it is
you that is that wants
to send push notifications
to your users
because we asked your server
to create something we
called a push package
that signed using a
website push certificate.
I love push notifications
because they tell me the
information that I want to know
at the best time it is for me to
know them and I'm really excited
to see how you integrate push
notifications into your website.
Not only this is
going to be great
because your Mac users will
be able to take advantage
of this great feature when
they visit your website,
but I really believe you're
going to see increased traffic
when people return to
your website as a result
of using these push
notifications.
All right, thanks for listening.
Enjoy the rest of the WWDC
and I'll see you at the lab.
[ Applause ]
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000