Links

Deep Linking

Link from external websites directly into content within your application.
Please note: Deep linking is easy to configure, but if configured incorrectly, can be very difficult to fix. Please wait until you have coordinated publication with App Factory before configuring 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:
  1. 1.
    Amazon is installed on the mobile device.
  2. 2.
    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, you can now achieve the same thing using Rock, and it isn't super complex.

Getting Started

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.

Configuration Necessities

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 contact at Triumph Tech.
Here is a list of all of the data you need in order to configure deep linking:
Name
Platform
Description
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).
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 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.
Example Deep Link Settings
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.
Setting
Description
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.

Passing Parameters

To The Mobile Page

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/b0b2d0b0-248f-4a8a-90a3-310807680ce5, a parameter of GroupGuid=b0b2d0b0-248f-4a8a-90a3-310807680ce5 will be passed along to the page.

To The Fallback

Fallback Page

When you use a Rock page, the parameters from the route are automagically 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.

Fallback URL

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.

Extra Pieces

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.

Stuck In Conflicted Route State

In Rock v14, there is a small bug in which you cannot press save in the 'Mobile Application Detail', or make edits. This has been fixed in v14.1, but there is a fix to it in v14.

The Fix

  1. 1.
    Copy your deep link settings into a notepad somewhere.
  2. 2.
    Disable deep linking, and save.
  3. 3.
    Re-enable deep linking, and put in dummy values (can literally put whatever, it doesn't matter), and save.
  4. 4.
    Disable deep linking, and save.
  5. 5.
    Make any changes you were attempting to make in the mobile application detail.
  6. 6.
    Re-enable deep linking, and put in your real deep linking values, and you should be out of the conflicted route state.