NFC - NDEF Message Handling Behaviors

by Retired ‎01-30-2012 11:09 AM - edited ‎01-30-2012 04:32 PM (5,364 Views)

Introduction

This is a brief article which explains the behaviour of a BlackBerry® NFC-enabled smartphone such as a BlackBerry® Bold™ 9900 or BlackBerry® Curve™ 9360 in the handling of NDEF messages from NFC tags under various conditions.

 

Readers of this article should already know what NFC tags are and what NDEF is. Those that don’t should first read our article on reading and writing NDEF tags and perhaps the NFC Primer for Developer. URLs are at the end of this article.

 

The Authors

 

This article was co-authored by Martin Woolley and John Murray both of whom work in the RIM Developer Relations team. Both Martin and John specialise in NFC applications development (amongst other things).

 

Multiple NDEF Handling Applications

 

Tags contain NDEF formated messages. There are various types, some of which are pre-defined by the NFC Forum. Smart posters are one such type. URI messages are another for example.

 

On a BlackBerry NFC-enabled smartphone, applications may register their interest in NDEF messages of a particular type or types. It’s possible and perfectly acceptable that more than one application might register an interest in the same type of NDEF message. The question then arises, when that NDEF type is encountered on a tag, which application “wins” and gets to handle the message?

 

The table in the next section attempts to set out the various permutations and conditions to clarify this issue.

 

 

NDEF Application Selection

 

The following table enumerates the possibilities that exist when a custom NDEF message handling application (one which implements NDEFMessageListener) has been installed on a BlackBerry device and has registered for a given NDEF type such as “Sp” (Smart Poster) alongside the standard BlackBerry Smart Tags application. The BlackBerry Smart Tags application is being used as a specific example of a second NDEF handler application. The behaviours described apply to any scenario where there is more than one NDEF handling application for a given NDEF type, not just scenarios involving BlackBerry Smart Tags application.

 

Some screen shots follow the table to aid understanding.

 

Condition

Expected Result

Neither application is running and the user has not set a default.

A pop-up is displayed by the system, listing the applications which could be used to handle the message. The user selects the application they wish to be invoked, optionally indicating that this application should be the default for this message type in the future and the application is launched and passed the NDEF message for processing.

The BlackBerry Smart Tags is running in foreground and no default has been set by the user.

The NDEF message is passed to the Smart Tags application for handling with no application selection required by the user.

The custom app is running in foreground and no default has been set by the user.

The NDEF message is passed to the custom application for handling with no application selection required by the user.

The BlackBerry Smart Tags application is running in foreground but the custom application has been set as the default by the user for this NDEF type.

The NDEF message is passed to the Smart Tags application for handling with no application selection required by the user. The application in foreground always wins.

The custom application is running in foreground but the BlackBerry Smart Tags application has been set as the default by the user for this NDEF type.

The NDEF message is passed to the custom application for handling with no application selection required by the user. The application in foreground always wins.

Device reads a tag which contains a type of tag for which no application is registered

You will see a dialogue which indicates that the content is not recognised. See screen shot below.

 

NDEF Messages and CHAPI

CHAPI is the standard Java® Content Handler API and it’s a mechanism which allows content types to be associated with applications such that when content of that type is encountered, it is automatically passed by the system to the appropriate application for handling. Content types can be specified in a number of ways, including via the use of MIME types.

 

As such, using the NDEFMessageListener interface is not the only way to receive an NDEF message. If an NDEF message type is a MIME type as opposed to one of the NFC Forum RTDs for example, then if the system finds that no application has registered an NDEFMessageListener for that MIME type, it will proceed to check the CHAPI registry for an application which has registered as a CHAPI handler for that MIME type.

 

If it does find an application which is registered as the CHAPI handler for that MIME type then the registered application will receive a call to its invocationRequestNotify method which is a method of the RequestListener interface. From within this method, the application may obtain an Invocation object associated with the ContentHandlerServer parameter and from this may obtain the NDEF message payload by calling the getData(...) method. Checking the CHAPI registry is the last resort that the system will use to find an appropriate application to handle an NDEF message.

 

Screen Shots

 

ndef_app_selection.png

Figure 1 - Application Selection Pop-Up

 

ndef_app_selection_setting_default.png

Figure 2 - Selecting an application to be the default for this NDEF type

 

ndef_resetting_defaults1.png

Figure 3 - Resetting the default applications step 1

 

ndef_resetting_defaults2.png

Figure 4 - Resetting the default applications step 2

 

non_standard_ndef.png

Figure 5 - No application registered for the type of tag read

 

Summary

Hopefully this article has clarified the behaviour of BlackBerry NFC-enabled devices in the way in which NDEF messages are handled when multiple candidate applications have been installed.


The APIs are available today so download the latest BlackBerry® JDK® from

http://us.blackberry.com/developers/blackberry7/

 

BlackBerry Java APIs are documented here if you'd like to browse further:

http://www.blackberry.com/developers/docs/7.1.0api/

 

The NFC Forum Home Page can be found here: http://www.nfc-forum.org

 

Other BlackBerry Developer NFC Articles

 

See the NFC Article Index for the list of other articles in this series

 

 

Glossary of NFC Terms

  • APDU - Application Protocol Data Unit. A message type which forms part of a protocol and which may be exchanged between peers as either a request or a response message. Applications on a BlackBerry smartphone may communicate with applets in an SE using the ISO 7816-4 APDUs for example.
  • CLF - Contactless Front-end. Part of the NFC Controller. Communicates via RF with an NFC reader.
  • HCI - Hardware Controller Interface. Amongst other things, this component of the NFC system architecture redirects radio communication to appropriate SE.
  • ISO 7816-4 - the specification which defines the protocol which allows applications to communicate with applets installed in an SE or smart card.
  • NDEF - NFC Data Exchange Format
  • NFC - Near Field Communications
  • PCD – Proximity Coupling Device (also known as “card reader”)
  • PICC – Proximity Integrated Circuit Card
  • SE - Secure Element. A hardware component which can host and act as an execution environment for small software applications known, in this context, as "applets".
  • SIM - Subscriber Identity Module. In 2G modules this used to be synonymous with the SIM *card* i.e. the small smart card inserted in the handset. In 3G networks, the SIM is a software module installed on the UICC.
  • SNEP  - Simple NDEF Exchange Protocol
  • SWP - Single Wire Protocol.
  • UICC - Universal Integrated Circuit Card - the smart card used in mobile terminals in GSM® and UMTS® networks