SPEAKER: So in our last video,
we did all the setup work in our Xcode project
and Firebase console required to receive a
dynamic link within our app. And then we created a
real Firebase Dynamic Link for testing purposes. In this video, we're
going to finally do the work necessary to
take this incoming link and turn it into
something meaningful. Are you excited? I sure am. Let's go. [MUSIC PLAYING] So the process for
interpreting dynamic links is pretty straightforward. Your app is going to be
receiving these dynamic links as a URL, either through a
universal link or a custom URL scheme. Your app will then pass in
these URLs to the DynamicLinks library, which will convert
them into a Firebase dynamicLink object if the URL is
a proper dynamic link, or a null object if it isn't. And then from there,
you'll be able to extract the original, deep link
URL parameter which contains the data you're
actually interested in. So let's start doing that. Now first off, I'll
need to make sure that I have the DynamicLinks
library installed, so I'll add
Firebase/DynamicLinks to my pod file and save it. And then run pod install. We can wait a few moments. Do, do, dee, do. And OK, now we're done. Now, remember that incoming URLs
can reach our app in two ways, and they're handled in
two different methods. For universal links, we handle
those in our AppDelegates application continue
userActivity restoration handler method, so we'll
implement that first. First off, I'll check and see
if I have an incoming URL here by checking if
userActivity.webpageURL really exists. If so, let's print it out. That always makes
debugging easier. And then if it does exist, I'll
want to call dynamicLinks().h andleUniversalLink
on the incoming URL. This is what's going to parse
this incoming dynamic link URL and turn it into a
dynamicLink object. Note that it returns
a Boolean right away if it believes this is
parsable, but then gives me the object in a callback. And that's because we need to
make a network call to convert our short dynamic link
into the full one with all the parameters and everything. So in this callback, I'm first
going to do just a little error checking. Then I will see if this
dynamicLink object exists. OK. If it does, I'm going to
pass this object along to a custom
handleIncomingDynamicLink method that I'll go ahead
and write in a moment. OK. Let's finish up this method. Xcode keeps nagging me to return
a Boolean, so we'll do that. I could say return
linkHandled here, although keep in
mind that if you are using universal links
for other things in your app, don't do this. Right? You might want to do like a if
linkHandled, return true, else do some other stuff here. If your app is receiving
universal links from other sources, you'll
need to handle those, too, somewhere in this method. And then here at the
end, I'll return false since I've got
nothing else that can handle this incoming activity. By the way, do I need
a weak self here? I'm going to say no in
this particular case because I'm pretty sure I can
never get into a situation where this callback
is still running and my AppDelegate is nil. But still, if you want to add
it because you feel weird not putting it in, go ahead. Be my guest. OK. Now let's write this
handleIncomingDynamicLink method. So let's see. I'm just going to
start by checking to see if our
dynamicLink actually contains a URL parameter. This is that deep link URL value
that I set in the last video, and it contains the actual
data that my app will need to properly handle this link. If it does exist, I guess
we can just print it out. And actually, that's all
I'm going to do for now. Let's give this a try. So I'll run my app. Then I will switch over to
Notes, and click on the link. And I don't know about
you, but it sometimes takes me a few tries
to successfully click on a URL in Notes. Maybe it's just
me and my fingers, but eventually this does
take us back into my app. And we can see in my Xcode log
here that it has successfully received my dynamic link
and properly extracted my URL parameter from it. Nice. But like I said, there are two
ways of getting a dynamic link. Even if you're running
a modern version of iOS, you'll still need to
handle dynamic links sent through custom URL
schemes, typically for when a user first
installs your app. So let's add the
code to support this, and then I can show
you how to test it. Now in my app, I'm going to
capture any incoming custom URL schemes by using the application
open url options method. But keep in mind that if you
are still kicking it old-school and supporting iOS 8 or earlier,
you should also use application open URL
sourceApplication:annotation. OK. Next, I'm going to pass
my incoming URL link to the dynamicLinks().d
ynamicLink(fromCustomSchemeURL) method. And this works very much like
the handleUniversalLink method, but it's instant, so
there's no callback, and it returns the
dynamicLink object right away. And then, just like before,
I can send that object on to my app's custom
handleIncomingDynamicLink method, and then
I can return true. Now if this method doesn't
return a dynamicLink object, that probably means
this is some other URL, maybe like a URL that I get
from Facebook or Google sign-in, so I'll probably
want to pass this off to other parts of my code
that could handle it. Oh, and you know,
while I'm here, I'm also going to print
out a little debug info so that I know that
I've received a link through a custom URL scheme. All right. Now to test this,
I'm going to simulate the process of
clicking on the link and installing my app
for the first time. So first, I'm going to go to
my device and uninstall my app. All right, that's done. Next, I'm going to go back to
Notes and click on the link. Since I no longer have
the app installed, it's going to take me
to an interstitial page. Now we put this page up for a
number of different reasons. First, having a preview page,
particularly if you customize the title, description, and
image like we talked about in the last video,
you can prepare the user a whole lot better
for going to the App Store than just by like
immediately tossing up a, hey, we're going to send you to
the App Store kind of dialogue. Second, by redirecting to
a secondary page like this, it just tends to
work a whole lot better if your dynamic
link is embedded inside of some popular
social networking apps, or other apps that
might be trying to use their own embedded WebViews. It tends to avoid
some technical issues. And third, this
little check box here? This gives us a
chance to ask the user if we can copy this link
so we can use it later. Now if they say yes, we copy
the dynamic link directly to the iOS pasteboard,
and this gives us the most accurate method
of saving the dynamic link from the user, so
that we can recover it after they install our app. Now it turns out that
my custom page has a couple of problems with it. For starters, I probably
don't want to be labeling it as project-772400 whatever. Also, it looks like the URL
I supplied for the preview image is broken. Now luckily, both of
these are easy to fix. To fix this top label, I'm going
to go to my project settings in the Firebase console, and
change the public-facing name of my project to Recipe Rally. Should've done that in
the first place, I guess. And then to fix this
image, I'm going to go back to the
Firebase console and click Edit link from
the dropdown menu here. Now since Firebase
Dynamic Links makes a network call to go from a
short URL to a longer one, we can generally change a
bunch of these parameters after the fact, and
it will retroactively apply to all of these links. So in my case, I'm going
to go down here and add an image URL that isn't broken. And then we can
go back to my app. We'll click on my
link one more time, and well, OK,
that's a lot better. Although, I still might want to
tweak that image a little bit. Anyway, I'm going to continue
here and say, why, yes. I would like to install
your app from the App Store. This will then take me
to the App Store listing for Google Photos,
which as you recall, is the App Store ID I entered
in the Firebase console. Now, of course, this is
the totally wrong app. But for testing
purposes, that's OK. As far as Dynamic
Links is concerned, it saved my link
to the pasteboard, and sent me to the app store so
I can now continue like normal. So now, I can
simulate my actual app getting installed and
opened for the first time by reinstalling
my app from Xcode. And you'll see that when I
open up the app for the, quote unquote, "first time," it once
again finds my dynamic link information. And we can see by this
line in the console here that it did so through
the custom URL scheme. Now if we hadn't used
that interstitial page, there's still a chance we can
get that original dynamic link, but we'd primarily be doing
it through some light device fingerprinting, which tends
to be a little less accurate. Now, as far as actually
processing the link URL parameter, that's
really up to your app. You saw that in
both of these cases, I'm passing the
dynamicLink object into this separate
function here. So the important
thing to note here is the URL property
of the dynamicLink object, which remember, is
the value of the deep link URL property you set in
the Firebase console. And that's probably what
you want to be working with. So I might parse
the URL like so, and then do something
interesting with the arguments, but really, that's up to my
app and its own custom logic. Finally, there's one last
thing I should call out. You'll notice that every
dynamicLink has this parameter called match confidence. This lets you know how
confident the library is that you've retrieved
the dynamic link that your user clicked on. Now this thing basically
has four levels. There's unique,
which means, yep, we're sure this is the dynamic
link the user clicked on. You'll typically get
this result either when you open up a dynamic
link using universal links or with the pasteboard,
which means you end up getting it most of the time. And that's good. But then you have
default, which means we're pretty sure this is
the link the user clicked on, but we're not 100% confident. Then there's weak,
which means we're guessing this might be the
link the user clicked on. But in this crazy
mixed-up world of ours, who really knows for sure? And then there's
none, which means we didn't find a match
at all, and the contents of this URL property
will be blank. So why do you care about this? Because if you're using your
dynamic links for sharing personal information, like maybe
your users are sharing pictures of themselves, or showing their
names, or that sort of thing, you really want to
make sure this link is unique before you display
any of that information. If this ends up being
default or weak, well, you probably
want to remove any personal data
associated with the link, or ignore the link entirely. You kind of need to think
about what kind of data you might be sending
here, and make the right call for your app. So there you go, kids. Everything you need
to get started using Dynamic Links in your own apps. Now there's certainly
more we could get into, like debugging these
things or building our own from within the app, but
these are topics probably best left for other videos. In the meantime, go
ahead and check out the documentation for
more helpful info, and start linking away. [MUSIC PLAYING] Hey, did you enjoy this video? Well, maybe you want to
check out a few others from the Firebase
channel, like this one here, or this one here. They're both fantastic. I don't have a favorite. It's like picking
my favorite child. Secretly, I like one
better than the other. I'm just not going to tell you.
