In order to minimize memory consumption in the device and to improve usability of the RF applications, this specifications provides means for starting applications based on events on RFID hardware. This means that when a target of requested type or target containing the requested NDEF record appears in the proximity of the device, applications registered for this event are started.
There are several ways to provide this functionality.
PushRegistry defined in the MIDP 2.0 specification is the most
suitable way and it is well known in the developer community. The nature
of RFID based communication has to be taken into account when using
PushRegistry. Even though application is started based on
discovered contactless target, the target may
not be available anymore when the application tries to open a connection
to it. In this case, the Connector.open method throws an
IOException. Following chapters describe how
the application startup based on RFID events is done using MIDP 2.0
PushRegistry.
This specification provides application startup based on targets that have NFC Forum NDEF records. Registration for startup is based on the record type name and format of the NDEF record. There can be one application for each record type name and format pair registered for startup at a time. If data on the target contains more than one NDEF record, the startup is based on the record type name and format of the first matching record in the data.
When a target is discovered, the application management software checks the
PushRegistry entries. If there is an entry for the NDEF
record type name and format in the target, the application having that entry is
started. If there is no PushRegistry entry, notification
about discovered NDEF record is sent to the registered application that has set the
NDEFRecordListener for that NDEF records type.
Table B.1. NDEF record push URL in BNF format
<ndef url> |
::= "ndef:"<record_type_format>?name=<record_type_string> |
<record_type_format> |
::= "rtd" | "external_rtd" | "mime" | "uri" |
<record_type_string> |
::= String of US_ASCII characters,
the fully qualified name of the record type |
Below are two examples of possible URLs for NDEF record push.
ndef:rtd?name=urn:nfc:wkt:Sp
This URL registers an application to be started when tag containing Smart Poster RTD is discovered.
ndef:mime?name=text/x-uri
This registers an application to be started when tag containing an URL is discovered.
Application startup through PushRegistry is also provided
for smart card target. In card emulation mode the smart card contains valuables, such as
bus ticket that are read from an external contactless reader. An application
can request startup when a transaction with the external secure element is completed.
Table B.2. Secure element push URL in BNF format
<secure element url> |
::= "secure-element:"?aid=<aid_string> |
<aid_string> |
::= String of numerical characters. Identifier is the aid
defined in ISO7816-5 specification. Masks can be used. |
There might be several applications interested in implementing the
TransactionListener interface to receive
externalTransactionDetected notifications. When transaction has
actually happened and there is a PushRegistry entry for that
particular smart card application identifier, the application having the
PushRegistry entry will be started and it receives the
externalTransactionDetected notification. Notification will
also be sent to all other applications that have registered the
TransactionListener with the
DiscoveryManager methods.
Unlike the push connections defined in JSR 118 for MIDP 2.0, the protocol defined in this specification includes a mechanism where the notification about discovered targets is held until it is processed by the started application.
When the application is started in response to a Push message, the
application should immediately register
NDEFRecordListener to receive notifications about
discovered NDEF record. This guarantees that the application will receive
the ndefRecordDetected notifications right away. If an
application fails to register the listeners when started, the platform
implementation may delete notifications
that have been stored, if it becomes necessary to do so.