Allowing your mobile app to be launched via a link is a necessary first step to making it accessible from the web. This enables promotional efforts (email, social posts, ads, etc.) to lead users directly into your mobile app which is typically a better and more seamless experience for your customers. This document explains the mobile app URI concept and best practices for using URIs in your mobile apps.
If your mobile app is already set up to handle a URI, you are all ready to create SPARQ optimized links that detect if the app is present on a user's device and then takes them to the mobile app content they are looking for! You may additionally want to look into advanced features of URI handling, such as deep-linking and install tracking with SPARQ optimized links.
In short, a URI is really just a link. The most common kind is a web link () which when clicked instructs the browser to render a web page. A mobile app URI is another type of link that allows a user to launch an app—not just a browser—when clicked; for example, will bring up a video in the YouTube app if it is installed. On both iOS and Android, any mobile app can indicate that it handles URIs, and for this reason, URIs are an ideal mechanism by which mobile apps can be launched from the web.
The structure and parts of a URI are set out in Internet Standard STD 66 and RFC 3986, though the Wikipedia article may give a clearer high level overview. In short, a URI contains the following parts:
|sparqme||Scheme Name (Required)|
For a reliable and smooth user experience, it is imperative that you select a URI format that will never be used by a different app. Conflicts can lead to unexpected and undesired behavior.
It is highly recommended that your URI format use a scheme name derived from your product, company, and/or domain name, and that it is sufficiently specific that it is unlikely to be selected by someone else.
For the purposes of simply launching your app, a URI with only a scheme (e.g. deep-linking, using additional URI components such as the authority, path, query, and/or fragment will be required to pass data within the link to your app.) will suffice; as you approach more advanced features such as
The Android URI-handling mechanism for mobile apps is based on its activity application component structure. Any of the activities contained in your app can be declared to be able to handle one or more URI formats via an intent filter. This is done through the AndroidManifest.xml file, where the activities are declared, as follows:
android.intent.action.VIEWintent filter for your main application activity (and/or any others you want launchable via a link).
android.intent.category.DEFAULTcategory to the intent filter. This means that the intent that launches it can be implicit, and not necessarily requesting your particular activity explicitly.
android.intent.category.BROWSABLEcategory to the intent filter. This makes the URI usable from the browser/links, and not just other apps on the device.
Avoid using URIs with the
scheme, as there can be inconsistent behavior between devices, Android versions, and custom browsers.
<activity android:name=".UriLaunchableActivity"> <intent-filter> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <category android:name="android.intent.category.BROWSABLE"/> <data android:scheme="sparqme" android:host="sparq.me" android:path="/app"/> </intent-filter> </activity>
This entry indicates that any URIs of the format
should be forwarded to the
activity in our app. When the activity is started from an intent matching your specified filter, the URI is contained in the intent for that activity, accessible via the
method. You do not need to handle it explicitly, in which case your activity would run normally as if the user had started it, for example.
For more advanced applications—such as
deep-linking—your app may parse details in the URI to extract information about more specific actions, typically in the
callbacks, e.g. to bring up a dialog or invoke a certain feature for the user.
See the Android documentation on intent filters for more details: http://developer.android.com/training/basics/intents/filters.html#AddIntentFilter
URI support is declared on an application-wide level in the app’s Info.plist file.
key (shown as “URL Types” in XCode) contains information on the type(s) of URIs your app can handle and would be launched to display, on a scheme basis.
Example info.plist (XML)
<key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleURLName</key> <string>com.sparqcode.sparqeye</string> <key>CFBundleURLSchemes</key> <array> <string>sparqme</string> </array> </dict> </array>
The same Info.plist entry In XCode editor:
This entry indicates that our app handles URIs with the
scheme. This means that iOS will launch our app any time a link using it is opened, e.g. from Safari, including , , , and .
When the app is invoked from one of these links, the app delegate is called with the exact URI that launched it, via the
method on the app's app delegate.
In most cases, simply returning
and letting your app run as if it were started from the home screen is sufficient; this allows the app to be started from a browser link, basically.
For more advanced applications—such as
deep-linking—your app may parse details in the URI to extract information about more specific actions, e.g. to bring up a screen or invoke a certain feature for the user.
See Apple’s documentation on adding custom URLs to your iOS app for more details: http://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/AdvancedAppTricks/AdvancedAppTricks.html#//apple_ref/doc/uid/TP40007072-CH7-SW50
With some moderate investment in development effort, your mobile app can be prepared with some highly useful advanced features for improving user experience, and enabling of tracking of app and link performance.
Deep-linking is the next step in creating useful mobile app-enabled links. By allowing the URI to include data on what the app is supposed to do, links can now be created to drive the user to a specific function. For example, the Twitter mobile app supports the following deep-linked URIs:
|twitter://user?screen_name=twitterhandle||Brings up the profile/timeline of the specified user|
|twitter://timeline||Brings up the user's timeline|
|twitter://mentions||Brings up the stream of mentions for the user|
|twitter://post?message=Hello%20World||Brings up the compose tweet dialog, pre-populated with the specified message|
|twitter://search?query=%23hashtag||Brings up search results for the specified query|
|twitter://messages||Brings up the user's mailbox|
SPARQ optimized links can be enhanced with advanced tracking of app installations. Integrating with this system provides a variety of services, including the following: