Hello, and welcome back "Route 85"
and part 4 on our little series on opening a link in Chrome
on iOS.
Now if you've been following along up until this point,
we've basically finished our main goal
of opening up a link in Chrome, adding a Back button that
reopens our app, and using our open source
library to help you do it all quickly and easily.
So you can think of today's episode
as a little bit of extra credit.
See, as long as we're exploring the idea of URL schemes
and callback URLs, let's take a closer look
at this x-success callback URL that we are defining.
Right now it's just sent to my app's custom scheme
and that's it.
But we could actually embed any information
we want in this URL.
Let's say, for instance, we wanted
to tell the user how happy we are that they clicked
on that Back button when they came back to our app.
Well, we could modify our callback URL to be something
like comgooglemyexamp le://welcomeback/.
If we URL encode this thing, and make
it part of our x-callback URL, this
will get passed along to Chrome as the URL
to open when the user clicks the Back button to go back
to our app.
So when Chrome intends to open this URL,
iOS will open up our application--
because we've claimed ownership to the comgooglemyexample
custom URL scheme-- and then we will pass this full URL along
to our application's app delegate.
But then how do we read in this URL
that gets sent back to our app?
By implementing the application openURL sourceApplication
annotation method, in our app delegate.
This takes in the full URL that opened up
our app in the first place, along with a few other bits
of information.
So maybe this is better demonstrated in code,
so let's give it a try in our sample app.
So here we are back in my fancy opening Chrome example
application.
And I'm going to do two things here.
The first thing I'm going to do is change my callback URL from
just this comgoogleopeninchromeexample:
to comgoogleopenexa mple://welcomebackfrombutton/.
And then the next thing I'm going to do,
is jump into my AppDelegate.m file.
And let's say up here at the top,
I'm going to add this application open URL source
application annotation method that I alluded to earlier.
So this is application-- here it is.
Open URL, source application, annotation.
And I guess maybe the first thing I will do here
is, let's just log the URL that we get back.
So nslog.
I have received the URL.
And then we'll pass in URL absolutestring.
But spoiler alert, it's just going
to be the callback URL that we specified
in our viewcontroller.m file.
And we can return Yes for now, just
to say yes, I can handle this URL-- even though I actually
don't know what it is yet.
And so now, when we run this-- so click on the button,
go into Chrome, jump back.
Let's stop this.
And we could see that in the logs, yes,
the URL we've received is, in fact,
this comgoogleopening chromeexample://
welcomebackfrombutton.
Man, I need shorter URLs.
But now we can analyze that.
So I'm going to add a little if URL host is equal to string,
and this is welcomebackfrombutton--
so if this is the case, then we know that the user has gotten
into our application from clicking on that Back
button in Chrome, and not from, say,
another x-callback URL we were to create in the future.
And so then, why don't we add a little alert box or something
to welcome the user back.
Something like this-- UIAlert view alloc initWithTitle@
Welcome Back!
Message-- We Missed You!
Our delegate here can be nil.
Cancel button can be Awww.
And other button titles, there aren't any.
And Show.
There we go.
Oops.
Yes, I need the little at sign.
There we go.
And then, I am returning yes here,
at the end of this method, to signal
that, yes, we have properly handled the URL.
I'm not actually sure what effect this has on the app,
since I can return no here, and I still get to open the URL.
My suspicion is that you want to return the correct value here
in case you have a subclass app delegate.
And your subclass delegate, you need
to know whether or not you have a URL that
hasn't been handled yet by your Super.
But that's just a guess.
I don't really know for sure.
Anyway, let's run this.
So I tap my button, it goes into Chrome.
Tap the Back button.
Ah, and look at that.
It's the "Welcome Back!" dialogue.
Aw, I feel so loved.
For a more realistic example, we could
imagine that we had an app that contained a bunch of news story
headlines, and a user could click on one of those headlines
to read the full story in Chrome.
So we could pass along, within our URL arguments,
the internal ID of whatever story or news post contained
this external link in the first place.
Then when the user returns to our app,
we can use this information to, for example,
make sure the user continues browsing
from where they left off.
Or we could prop them with some follow-up options.
Or we can mark this story as read.
You kind of get the idea.
Anyway, hopefully this tutorial gives you
a better understanding of what URL schemes are,
how to use them to open up a web page in the user's
favorite browser-- whatever that might be--
and how to take advantage of that nice little Back
button in Chrome to send the user back to your app.
So, thanks so much for watching.
Hey, this was my first set of screen caps in a while.
What'd you think?
Was this too fast, too slow?
Is there something else you want me to cover?
Are you like, let's do all swift all the time?
Let me know down here in the comments,
and I will be sure to read them.
Thanks again, and I'll talk to you soon.
[MUSIC PLAYING]