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.