QNearFieldManager Class ReferenceThe QNearFieldManager class provides access to notifications for NFC events. More... #include <QNearFieldManager> Inherits: QObject. This class was introduced in Qt Mobility 1.2. Public Types
Public Functions
Signals
Additional Inherited Members
Detailed DescriptionThe 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 handlersIt 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^3On 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: symbian { ndefhandler.sources = %APPNAME%.xml ndefhandler.path = c:/private/2002AC7F/import/ DEPLOYMENT += ndefhandler } The %APPNAME% tag need to be changed to match the name of the application. Meego 1.2 HarmattanOn 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 NFC auto-start handler on Meego 1.2 Harmattan requires that the applications .desktop file has the same name as the application. This may not be the case as the .desktop files created by Qt Creator is named %APPNAME%_harmattan.desktop by default. The application developer should ensure that the %APPNAME%.desktop file is installed to the appropriate place. A .pro file snippet similar to the following may be used: contains(MEEGO_EDITION,harmattan) { harmattandesktopfile.files = %APPNAME%.desktop harmattandesktopfile.path = /usr/share/applications INSTALLS += harmattandesktopfile } 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. Member Type Documentation
flags QNearFieldManager::TargetAccessModes |
Constant | Value | Description |
---|---|---|
QNearFieldManager::NoTargetAccess | 0x00 | The application cannot access NFC capabilities. |
QNearFieldManager::NdefReadTargetAccess | 0x01 | The application can read NDEF messages from targets by calling QNearFieldTarget::readNdefMessages(). |
QNearFieldManager::NdefWriteTargetAccess | 0x02 | The application can write NDEF messages to targets by calling QNearFieldTarget::writeNdefMessages(). |
QNearFieldManager::TagTypeSpecificTargetAccess | 0x04 | The application can access targets using raw commands by calling QNearFieldTarget::sendCommand(). |
The TargetAccessModes type is a typedef for QFlags<TargetAccessMode>. It stores an OR combination of TargetAccessMode values.
Constructs a new near field manager with parent.
Destroys the near field manager.
Returns true if NFC functionality is available; otherwise returns false.
Registers object to receive notifications on method when a tag has been detected and has an NDEF message that matches a pre-registered message format. The method on object should have the prototype 'void targetDetected(const QNdefMessage &message, QNearFieldTarget *target)'.
Returns an identifier, which can be used to unregister the handler, on success; otherwise returns -1.
This function is used to register a QNearFieldManager instance to receive notifications when a NDEF message matching a pre-registered message format is received. See the section on Automatically launching NDEF message handlers.
Note: The target parameter of method may not be available on all platforms, in which case target will be 0.
Registers object to receive notifications on method when a tag has been detected and has an NDEF record that matches typeNameFormat and type. The method on object should have the prototype 'void targetDetected(const QNdefMessage &message, QNearFieldTarget *target)'.
Returns an identifier, which can be used to unregister the handler, on success; otherwise returns -1.
Note: The target parameter of method may not be available on all platforms, in which case target will be 0.
Registers object to receive notifications on method when a tag has been detected and has an NDEF message that matches filter is detected. The method on object should have the prototype 'void targetDetected(const QNdefMessage &message, QNearFieldTarget *target)'.
Returns an identifier, which can be used to unregister the handler, on success; otherwise returns -1.
Note: The target parameter of method may not be available on all platforms, in which case target will be 0.
Sets the requested target access modes to accessModes.
See also targetAccessModes().
Starts detecting targets of type targetTypes. Returns true if target detection is successfully started; otherwise returns false. The application can start to get notifications when the target detection is successfully started and NFC is switched on.
The targetDetected() signal is emitted when a target with the type in targetTypes is within proximity. If targetTypes is empty targets of all types will be detected.
Note: In a MeeGo 1.2 Harmattan device the method returns true regardless of the device�s NFC state (on or off). In Symbian devices the method returns false if NFC is switched off; otherwise returns true.
See also stopTargetDetection().
This is an overloaded function.
Starts detecting targets of type targetType. Returns true if target detection is successfully started; otherwise returns false. Causes the targetDetected() signal to be emitted when a target with the type targetType is within proximity.
Stops detecting targets. The targetDetected() signal will no longer be emitted until another call to startTargetDetection() is made.
Returns current requested target access modes.
See also setTargetAccessModes().
This signal is emitted whenever a target is detected. The target parameter represents the detected target.
This signal will be emitted for all detected targets.
QNearFieldManager maintains ownership of target, however, it will not be destroyed until the QNearFieldManager destructor is called. Ownership may be transferred by calling setParent().
Do not delete target from the slot connected to this signal, instead call deleteLater().
Note: that if target is deleted before it moves out of proximity the targetLost() signal will not be emitted.
See also targetLost().
This signal is emitted whenever a target moves out of proximity. The target parameter represents the lost target.
Do not delete target from the slot connected to this signal, instead use deleteLater().
See also QNearFieldTarget::disconnected().
This signal is emitted when ever a transaction is performed with the application identified by applicationIdentifier.
The applicationIdentifier is a byte array of up to 16 bytes as defined by ISO 7816-4 and uniquely identifies the application and application vendor that was involved in the transaction.
Unregisters the target detect handler identified by handlerId.
Returns true on success; otherwise returns false.
Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. | Qt qtmobility-1.2 | |
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD. | ||
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP ! |
Copyright © 2000-2012 - www.developpez.com