Deep Linking
Link from external websites directly into content within your application.
Last updated
Link from external websites directly into content within your application.
Last updated
Deep linking is easy to configure, but if configured incorrectly, can be difficult to fix. Please wait until you have coordinated publication with App Factory before setting up this feature.
What is deep linking? You have encountered it without even knowing it. Using Amazon as an example, let's give the following process:
Amazon is installed on the mobile device.
You are sent a link to an Amazon product via message.
When the link is clicked, the product is opened directly in the app, not the browser.
The great news is that you can now achieve the same thing using Rock, and it isn't super complex.
First things first, we need to enable the deep linking HTTP module. This module catches all related deep-linking requests and handles them accordingly and efficiently.
To enable this module, navigate to Admin Tools > CMS Configuration > HTTP Modules > Deep Links, and set Active to Yes.
This will require a Rock restart to take effect.
There are a few pieces of information you're going to need handy in order to configure deep linking. If you are unsure or unable to get any of the following information, please reach out to your App Factory contact.
Here is a list of all of the data you need in order to configure deep linking:
Team Id
iOS
The Team Id used in relationship with your apple developer profile. (Here, and then into your specific app)
Bundle Id
iOS
The Bundle Id used in relationship with your apple developer profile. (Here, and then into your specific app)
Package Name
Android
The package name used in relationship with your Google developer account. (Here, into your specific app, and then into App Integrity on the left-hand side, then into App Signing and scroll down to Dgital Asset Links).
Certificate Fingerprint
Android
The package name used in relationship with your Google developer account. (Here, into your specific app, and then into App Integrity on the left-hand side, then into App Signing). This is referred to as the "SHA-256 certificate fingerprint" in the play console.
Deep Link Path Prefix
Both
The prefix you want to correspond to your deep linking.
All of these are given to you, with the exception of one piece of data to think about, your Deep Link Path Prefix. This is the prefix of all the routes that you plan to re-route to your mobile app. A common one is 'm' (for mobile). When you set your prefix, every deep link will be structured as such: example.com/<DeepLinkPrefix>/<DeepLinkRoute>.
Once you have all of these things, they go into the deep linking configuration directly.
Once this is saved, let's go ahead and test to make sure our server is processing deep link requests. Navigate to <yourdomain>.com/.well-known/apple-app-site-association and <yourdomain>.com/.well-known/assetlinks.json, you should see an output of a blank screen with just some text on it. As long as no errors are displayed on the page, and you put in the right configuration values, it is safe to assume that everything is good to go.
Use of a deep link will bypass all Homepage Routing Logic. Be sure to apply any necessary routing logic on pages that could be navigated to via a deep link.
Now that we've configured deep links, it's time to actually add some. In our mobile application detail, we should now see a new Deep Links tab. Sweet!
From here on, it should be easy to configure. Let's go ahead and add a deep link by pressing the add button in the bottom right-hand corner of the tab.
Here is an example of a deep link configured - when example.com/m/christmas is navigated to, it will open directly to the Christmas page in the mobile application. Let's go through and break down all of these settings.
Route
The web route that we are linking to our mobile application.
Mobile Page
The mobile page that we are linking to from our route.
Fallback Method
So what do you do if someone doesn't have the mobile application installed and clicks a deep link? Crawl into a corner and weep? No! That's why you get to decide whether or not you want to redirect them to a Rock page or an external URL.
You should take a look at passing parameters to the fallback.
Fallback Page
The page to fall back to if someone does not have the application installed, and clicks the deep link.
Fallback URL
The URL to fall back to if someone does not have the application installed, and clicks the deep link.
Linking directly to content is cool and all. But what if I need that to be personalized content, or have the content rendered based on something dynamic? Well we know that we can do that with routes, by introducing our curly brackets ({ key }) to the route. We can also do that here!
Let's say on my Christmas page, a piece of content is dependent on a GroupGuid. I need some way to pass that from the deep link to the mobile application, so why don't we go ahead and reconfigure that route a little bit?
Now, if someone were to click a link to example.com/m/christmas/b0b2d0b0-248f-4a8a-90a3-310807680ce5, a parameter of GroupGuid=b0b2d0b0-248f-4a8a-90a3-310807680ce5 would be passed along to the page.
When you use a Rock page, the parameters from the route are "auto-magically" passed along. If the page you're directing to has a route with the same route parameter key, the value is injected there. So from the example directly above, the fallback page would also have access to a page parameter of GroupGuid.
The fallback URL replaces any dynamic content in the original route with the same value. So for instance, if the route was:
And the fallback URL was:
The original route will set the GroupGuid in the fallback URL, if hit.
Before configuring deep linking, please make sure you have coordinated the publishing process already. This is a piece that needs to be wired up in a few different places and included in your app at compile time. If you fail to communicate that you wish to include/activate deep linking then this setting will not apply or work.
With everything configured, it's time to test. On iOS, deep links can be tested against the TestFlight build before the update goes live. Unfortunately, the update must go live on Android before it can be tested.
Deep linking is implemented uniquely in the shell for each platform's requirements, so be sure to test both when you can. It may work for one and not the other, so if there are any issues, let the App Factory team know which platform is affected.
Typing a deep link URL into your browser app will not open the Rock Mobile app. You can use a Notes app or something with text entry to add the URL, then tap on it. This emulates the more common use case of someone tapping a deep link from their email or an SMS communication.
