Appendix B. Launching applications with MIDP 2.x PushRegistry

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.x 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.x PushRegistry.

NFC Forum NDEF record push

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 record 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

This URL registers an application to be started when tag containing Smart Poster RTD is discovered.

This registers an application to be started when tag containing an URL is discovered.

Secure element push (card emulation mode)

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:"[<slot_number>]?aid=<aid_string>
<slot_number>	::= Number identifying the smart card slot for the secure element. The number must be as defined in JSR 177 except for slot number 0. For slot number 0 the number must be omitted. This provides compatibility with implementations based on specification version 1.1 that only support one (default) slot for the secure element.
<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.

Implementation notes

Unlike the push connections defined in JSR 118 for MIDP 2.x, 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.