Essentially, you have four main possibilities to launch your app on the
Windows 8 Platform with NFC:
Registering for a specific file type to launch your app is also possible with
NFC, but most likely not as relevant as the other possibilities. After all, NFC
tags usually don’t have enough writable space to store a whole file – they
usually contain very efficient and standardized NDEF messages (see the article
content via NFC). Of course, your app can share a specific file type with
another user via Proximity; but in most cases, you will use other means if you
want to launch your app via NFC.
Registering for a custom URI scheme is one of the most powerful methods to
launch your app in a wide variety of situations.
What is a custom URI scheme? Common examples are links on the web to make a
call on Skype (skype:mopius?call) or to trigger a search on Spotify
(spotify:search:17th%20boulevard). Also see the article about how to store geo coordinates on an NFC tag, which also contains examples on how to launch the maps application through a custom URL scheme.
Essentially, a custom URI scheme needs to
contain your protocol / scheme name, followed by a colon character (“:”). The
remainder of the URI is the scheme-specific part, whose format is mostly up to
your specific app. See Wikipedia for more details,
for example with regards to constraints like reserved characters.
An example for a custom URI for your own app could be
“nfcinteractor:compose”, which would launch your app and could then directly switch to the
compose page, bypassing the standard start page. By adding more data to the scheme-specific part, you could
also prefill the forms on the compose page, for example to be specific to the
place where the URL was found.
That leaves the question: how can your app be launched via a protocol? If you
register your app, the registration is system-wide. So it is even valid for a
link on the web, discovered via the browser.
Relevant for NFC: URI messages received from a peer device via Proximity APIs
article for details on sending and receiving Uri messages), as well as URIs
stored on NFC tags and discovered by tapping the tag.
In all those scenarios,
your app would launch as soon as the device encounters the URI, or in case the
app has not yet been installed, it will ask the user to visit the marketplace to find
an appropriate app. In case this is a custom URI, this should in most cases be
your app only (unless someone else chooses to use the same URI scheme).
MSDN contains an article that explains how to register
for custom URI protocols in the Windows 8 platform.
In case you don’t need a custom protocol and just want to launch your app
when the user touches an NFC tag, there is a more direct way: creating a tag of
the LaunchApp type. This also has the advantage that you can uniquely link to
your app ID, without the potential danger of someone else putting an app into
the store that implements the same protocol.
Unfortunately, this important use case hasn’t yet been standardized by the
NFC Forum. Therefore, Microsoft has defined its own extensible format, which can
launch an app on any number of platforms. The format is quite easy, as seen on
First, you specify the launch parameters – they are similar for all
platforms, and are only specified once (tag space is very limited and therefore
precious). This could for example be “view=compose”. Afterwards, you specify one
or more platforms names and the respective ID of your app on that platform. The
Proximity APIs expect the input to be separated by tab characters. MSDN contains
a short code
sample that shows how to write such a LaunchApp tag for Windows 8 apps.
The resulting message that is written to the tag is an NDEF record of type
absolute-URI, and the type name format is “windows.com/LaunchApp”. The Proximity
APIs will automatically reformat the tab-separated string that you pass to them,
e.g., adding the string length in front of all the platform names, app ids, etc.
You don’t need to worry about those details, though; they all happen in the
For peer-to-peer scenarios, you have two different options to launch your app
on the second device.
In case you only need a quick data exchange, you’d typically publish a
message to the other phone, which should ideally use a custom URI scheme to also
launch your app in case it’s not running yet. In case you know that the other
device also has your app running, you can send and listen to pretty much any
kind of message (except a few reserved protocols, which can always be handled by
the operating system). See this
article for details on how to publish and subscribe messages between two
devices with NFC.
The other scenario is to establish a longer-term multi-user session. In this
case, NFC can only be used for establishing a permanent other communication
channel. NFC itself is a very short-range technology, which works (depending on
the antenna size) only up to 10 cm; in most real-life use cases, only up to 1
cm, given very small antenna sizes on mobile devices. Therefore, you’d actually
tap the devices to exchange data. As soon as the users remove the devices again,
the NFC link will be broken, and no data can be sent between the devices
can automatically establish communication between two devices, and triggering
the connection works either by tapping (via NFC) or by browsing for other peers.
In case the other peer doesn’t have the app opened / installed yet, the system
will automatically offer the possibility to launch or install it. More details
about this use case will be published in a separate article.
This article is based on the corresponding presentation by Andreas Jakl and
provides background explanations that you wouldn’t get when only browsing
through the slides. The slides can be viewed and downloaded here: http://slidesha.re/UJAefK
To find out more about Proximity APIs, check out the API documentation.
For some cases also helpful is the specification for Proximity driver
implementers – you should not need to know it, but it might help with some
background knowledge if you want to go to lower levels or need details about
encodings or limitations.
No possibility to dispatch by MIME type, or an external RTD URN, both of which are standard NDEF ways of identifying NFC application payloads?
Public usage of custom URI schemes has lo