QNearFieldManager Class Reference

Detailed Description

The QNearFieldManager class provides access to notifications for NFC events.

NFC Forum devices support two modes of communications. The first mode, peer-to-peer communications, is used to communicate between two NFC Forum devices. The second mode, master/slave communications, is used to communicate between an NFC Forum device and an NFC Forum Tag or Contactless Card. The targetDetected() signal is emitted when a target device enters communications range. Communications can be initiated from the slot connected to this signal.

NFC Forum devices generally operate as the master in master/slave communications. Some devices are also capable of operating as the slave, so called Card Emulation mode. In this mode the local NFC device emulates a NFC Forum Tag or Contactless Card and can be used to perform transactions. The transaction happens entirely within a secure element on the device and only a notification of the transaction is provided. The transactionDetected() signal is emitted whenever a transaction occurs.

NFC Forum Tags can contain one or more messages in a standardized format. These messages are encapsulated by the QNdefMessage class. Use the registerNdefMessageHandler() functions to register message handlers with particular criteria. Handlers can be unregistered with the unregisterNdefMessageHandler() function.

Applications can connect to the targetDetected() and targetLost() signals to get notified when an NFC Forum Device or NFC Forum Tag enters or leaves proximity. Before these signals are emitted target detection must be started with the startTargetDetection() function, which takes a parameter to limit the type of device or tags detected. Target detection can be stopped with the stopTargetDetection() function. Before a detected target can be accessed it is necessary to request access rights. This must be done before the target device is touched. The setTargetAccessModes() function is used to set the types of access the application wants to perform on the detected target. When access is no longer required the target access modes should be set to NoTargetAccess as other applications may be blocked from accessing targets. The current target access modes can be retried with the targetAccessModes() function.

Automatically launching NDEF message handlers

It is possible to pre-register an application to receive NDEF messages matching a given criteria. This is useful to get the system to automatically launch your application when a matching NDEF message is received. This removes the need to have the user manually launch NDEF handling applications, prior to touching a tag, or to have those applications always running and using system resources.

The process of registering the handler is different on each platform. The platform specifics are documented in the sections below. Qt Mobility provides a tool, ndefhandlergen, to generate the platform specific registration files. The output of ndefhandlergen -help is reproduced here for convenience:

 Generate platform specific NFC message handler registration files.
 Usage: nfcxmlgen [options]

     -template TEMPLATE    Template to use.
     -appname APPNAME      Name of the application.
     -apppath APPPATH      Path to installed application binary.
     -datatype DATATYPE    URN of the NDEF message type to match.
     -match MATCHSTRING    Platform specific match string.

 The -datatype and -match options are mutually exclusive.

 Available templates: Meego 1.2 Harmattan, symbian

A typical invocation of the ndefhandlergen tool for Symbian^3 target:

 ndefhandlergen -template symbian -appname myapplication -datatype urn:nfc:ext:com.example:f

and for the Meego 1.2 Harmattan target:

 ndefhandlergen -template harmattan -appname myapplication -apppath /usr/bin/myapplication -datatype urn:nfc:ext:com.example:f

Once the application has been registered as an NDEF message handler, the application only needs to call the registerNdefMessageHandler() function:

 QNearFieldManager *manager = new QNearFieldManager;
 manager->registerNdefMessageHandler(this,
                                     SLOT(handleNdefMessage(QNdefMessage,QNearFieldTarget)));

Symbian^3

On Symbian^3 an xml file needs to be created and installed into a particular directory on the device. The format of the xml is given below.

 <?xml version="1.0" encoding="UTF-8"?>
 <SFW version="1.1">
     <service>
         <name>%APPNAME%</name>
         <ipcaddress>%APPNAME%</ipcaddress>
         <description>NFC NDEF message handler for %APPNAME%</description>
         <interface>
             <name>com.nokia.qtmobility.nfc.NdefMessageHandler</name>
             <version>1.0</version>
             <description>NFC NDEF message handler for %APPNAME%</description>
             <capabilities></capabilities>
             <customproperty key="datatype">%DATATYPE%</customproperty>
         </interface>
     </service>
 </SFW>

The %APPNAME% tags need to be changed to match the name of the application. The description xml tags should be used to describe the application, however these values are not used. The %DATATYPE% tag must be set with the NDEF record type to match For example the following would be used to match NDEF messages that contain a RTD-URI record:

 <customproperty key="datatype">urn:nfc:wkt:U</customproperty>

The following would be used to match NDEF messages that contain a custom type urn:nfc:ext:example.com:f:

 <customproperty key="datatype">urn:nfc:ext:com.example:f</customproperty>

The value of the customproperty xml tag can be set to any valid match string supported by the Symbian^3 platform.

It is recommended to name the xml file after the application package name. For example myapplication.xml. To install the above xml file into the correct location the following should be added to the application .pro file:

and for Meego 1.2 Harmattan target:

 ndefhandlergen -template harmattan -appname myapplication -apppath /usr/bin/myapplication -datatype urn:nfc:ext:com.example:f

 symbian {
     ndefhandler.sources = myapplication.xml
     ndefhandler.path = /private/2002AC7F/import/
     DEPLOYMENT += ndefhandler
 }

Meego 1.2 Harmattan

On Meego 1.2 Harmattan the NDEF message handler notifications are passed over D-Bus. Registration of the NDEF message match criteria is done via a D-Bus call. The application must also ensure that it has registered a D-Bus service name so that the application can be automatically launched when a notification message is sent to the registered service.

To register the D-Bus service the two files need to be created and installed into particular directories on the device. The first file is the D-Bus bus configuration file:

 <busconfig>
     <!-- we trust that no one else is going to squat on our service -->
     <policy context="default">
         <allow own="com.nokia.qtmobility.nfc.%APPNAME%"/>
     </policy>
 </busconfig>

The %APPNAME% tag must be replaced with the name of your application binary.

The second file is a D-Bus service file which is used by the D-Bus daemon to launch your application.

 [D-BUS Service]
 Name=com.nokia.qtmobility.nfc.%APPNAME%
 Exec=%APPPATH%
 User=user

The %APPNAME% tag must be replace with the name of your application binary and the %APPPATH% tag must be replaced with the path to your installed application binary.

It is recommended to name these files after the application package name. For example myapplication.conf and myapplication.service. To install the above files into the correct location the following should be added to the application .pro file:

 contains(MEEGO_EDITION,harmattan) {
     ndefhandler_conf.files = %APPNAME%.conf
     ndefhandler_conf.path = /etc/dbus-1/session.d/

     ndefhandler_service.files = com.nokia.qtmobility.nfc.%APPNAME%.service
     ndefhandler_service.path = /usr/share/dbus-1/services/

     INSTALLS += ndefhandler_conf ndefhandler_service
 }

The NDEF message handler is registered with the following D-Bus command. Applications should ensure that the following command (or similar) is executed once at installation time. For example in the packages post-installation script.

 #!/bin/sh

 dbus-send --system --type=method_call --dest=com.nokia.nfc / \
     com.nokia.nfc.Manager.RegisterNDEFHandler \
         string:session \
         string:com.nokia.qtmobility.nfc.%APPNAME% \
         objpath:/com/nokia/nfc/ndefhandler \
         string:any \
         string:"%DATATYPE%" \
         string:%APPNAME%

The %APPNAME% string must be replaced with the name of the application binary. The %DATATYPE% string must be replaced with the NDEF record type to match. For example the following would be used to match NDEF messages that contain a RTD-URI record:

     string:"'urn:nfc:wkt:U'[1:*];"

The following would be used to match NDEF messages that contain a custom type urn:nfc:ext:example.com:f:

     string:"'urn:nfc:ext:example.com:f'[1:*];"

Note that [1:*] indicates one or more records of the specified type must be in the NDEF message. The value of the datatype string argument can be set to any valid match string supported by the MeeGo 1.2 Harmattan platform.

The NDEF message handler should be unregistered at uninstallation time. For example in the packages pre-removal script.

 #!/bin/sh

 dbus-send --system --type=method_call --dest=com.nokia.nfc / \
     com.nokia.nfc.Manager.UnregisterNDEFHandler \
         string:session \
         string:com.nokia.qtmobility.nfc.%APPNAME% \
         objpath:/com/nokia/nfc/ndefhandler

The %APPNAME% string must be replace with the name of the application binary.