So as you might know by now, you can
use Google Cloud Messaging to send notifications
to iOS devices through APNs.
Now in a previous video, we shed a little light
on how the APNs half of this combo works.
Let's see if we can do the same thing for GCM
on this episode of "Route 85."
[MUSIC PLAYING]
So before we go any further, I'd recommend
watching this video on understanding APNs
if you haven't yet.
If you have, here's a real quick review.
When you send a notification through APNs,
it requires two important pieces of information.
First is the device token, which is basically
an alias for the device you want to talk to.
Remember, that's like the secret fake name
rock stars leave at the hotel register
so that their real friends can find them.
Second is the APNs certificate, which basically
contains a public key that you can
use to communicate with APNs.
Oh yeah, and there's the notification itself.
So I guess that's three pieces of information.
Now, sending notifications through GCM
is similar, but not quite the same.
Let's look at the two pieces of information
you need to send a notification through GCM.
First is the registration token.
Like the APNs device token, it's the address
of the device you want to talk to.
Or I guess more accurately, it's the fake rock star alias
for the device you want to talk to.
Now, GCM has its own token that it uses,
but it turns out there are other services-- not just
Cloud Messaging-- that could theoretically
use this token, as well.
So while you'll often hear it referred to
as a GCM registration token, its real name
is an instance ID token.
And when it gets down to implementing
this thing for reals, you're going
to see that you'll be using a library called the Instance ID
Library to get one of these.
Now second is the API key.
You don't need a certificate with its own private/public key
combination to communicate with GCM servers
the way you do with APNs.
Instead, you send across an API key
that is unique to your application with every request
that you make.
This API key is generated by the console when you first
set up your project, and is what GCM
uses to confirm that, yes, you really are communicating
on behalf of your application, which means this is something
you want to treat with the same kind of sensitivity
as, say, a password.
Don't make it easy for people to discover.
Don't put it in a public file on a server somewhere.
And for crying out loud, don't ever put this on your client.
So if we were using GCM to make a request to an Android device,
it would look pretty similar to the APNs flow.
Our server would talk to GCM using the API key as proof
that, yes, we're really who we say we are.
Then, we'd use the registration token
to both find the right device to talk to, as well as prove that,
yes, we really have the right to talk to this user
because they gave us their rock star alias.
Add on the rest of our data, and our notification gets sent.
Yay.
But we're dealing with the iOS world, where
things are slightly different.
GCM still needs to route all of its requests
through APNs if we want to bring up any kind of notification
in the background or anything.
So before you ask GCM to create a registration token for you
on iOS, you first need an APNs device token.
Then, you tell Google servers, hey, here's
an APNs device token.
Can you create a GCM registration
token associated with this APNs token, and then send me a copy.
This is probably inaccurate, but I
like to think that, when you're done, there's a database table
out there somewhere that now has your GCM registration
token, your APNs device token, and your sender ID
all in a row.
Now, also remember that GCM, like any other server,
needs an APNs certificate to communicate with the APNs
service.
Yes, I know that's still redundant.
Shut up.
So at around the same time you register your application
with GCM and you create your API key,
you're also going to upload your APNs certificate to Google
servers to tell it that this is the APNs certificate that it
should associate with its GCM key.
Again, probably inaccurate, but I
like to think that, in another database table
somewhere, there's a row that's got your GCM API key, your APNs
certificate, and your app sender ID all in a row.
With me so far?
OK, cool.
So let's review the higher end-to-end process
of sending a notification to APNs through GCM, starting
with the set-up process.
And yes, I did spend Google's money purchasing a stock photo
image of an enchilada.
So let's take a moment to admire it, shall we?
Mm.
All right.
I'm getting hungry.
So at some point when you're first building your app,
you register with the APNs servers using iTunes Connect.
You tell it about your app, your bundle ID,
and you generate your APNs certificate.
Then, you go ahead and register that same app
with GCM using the console.
Now at this point, you're going to get back
an API key, which you'll use to identify your app to GCM when
you talk with it.
Now at some point, quite possibly the same time
you're creating this API key in the first place,
you're also going to upload your APNs certificate
to GCM servers.
GCM then associates that certificate
with the app that is identified by that API key
that it just gave you.
So now let's move on to the worlds of the client,
and what happens when it asks to receive some notifications.
First off, your client will tell iOS, hey,
I want to receive notifications.
iOS will ask the user if that's OK.
Now, if the user says yes, iOS registers your app
with its servers and gets back an APNs device
token-- remember, that's the fake rock star
alias-- that it shares with your app.
Your app then needs to ping the instance ID service which,
for simplicity and because I'm running out of room here,
we'll pretend is a part of GCM for its registration token.
And as part of the request, it passes along the device token
that it just got from APNs.
The instance ID service then returns a registration token,
and that is the token you're going
to use if you want to send a message to this target device.
OK, so registration is done.
Let's see what happens when we now
want to go ahead and send a notification.
Now in our scenario, let's assume
you want to ping this individual device
and you have a little bit of code on your server to do it.
For that to work, the user's client
will now need to send back this registration token
to your server.
How you do that is kind of up to you.
So when you want to send a notification to this device,
your servers are going to send off a notification request
to the GCM servers.
Now it's going to pass along the API key and the GCM
token for this device along with that notification.
GCM servers are going to verify that the API
key and the registration token both exist on its servers,
and it's going to make sure that they both correctly map
to the same app.
Assuming all that's good, it will then notice, hey,
this registration token contains an entry for an APNs device
token.
That's its cue that our target device is actually
an iOS device.
So it'll grab that, along with the APNs certificate
associated with the API key, and use
those two bits to communicate to Apple servers.
It will then take your notification request,
alter it a bit to fit Apple's notification format,
and then send that notification request
to APNs along with the device token that it found earlier.
Apple will receive this information,
confirm that everything looks correct on this end,
and then send the notification along to the user's device.
Hooray.
All right, well that was an awful lot of work
just to send one little notification, right?
But don't worry too much-- a lot of this work
is setup stuff that you're only going
to need to do once per app, and a lot of the other work really
just gets taken care of automatically
for you behind the scenes.
Now granted, I haven't talked yet
about things like upstream messaging--
which is a whole other kettle of fish-- or topic
messaging or some other edge cases,
but I think, for the purposes of getting
started with GCM on iOS, this is probably everything you need.
See?
Our giant black rectangle is now a lightish gray rectangle.
So with this information under your belt,
I suggest you now go and tackle the documentation,
if you haven't yet.
It'll probably be a little easier to digest now
that you have some background information.
And be on the lookout for future episodes of "Route 85."
I'll see if I can tackle some of the nuts
and bolts of this process in a screencast or two.
Wouldn't that be nice?
Yes, it would.
But you're going to have to wait until after I-- I'm busy.
[MUSIC PLAYING]