Está en la página 1de 5

Descubrir un tag NFC

En función del contenido de un tag NFC el sistema Android encapsula la información en intents de
acciones diferentes. A cada acción de intención le corresponde, en la aplicación, un filtro de intención
específico.

Las intenciones creadas por el sistema siguen una jerarquía, que va de más a menos especializada.

Nivel 1: si el tag contiene un mensaje con formato NDEF, el sistema lee el primer registro del
mensaje para tratar de extraer un tipo MIME o una URI. Si dicha extracción es correcta, es la
aplicación capaz de trabajar con el tipo MIME, o la aplicación indicada por la URI, la que se
inicia. La intención correspondiente tiene como acción ACTION_NDEF_DISCOVERED.
Nivel 2: si el tag no contiene un mensaje en formato NDEF, o si no se encuentra ninguna
aplicación en la etapa 1, el sistema selecciona la aplicación teniendo en cuenta las tecnologías
de tag que cada aplicación ha declarado como capaz de procesar, a nivel de los filtros de
intención. El sistema crea, en este caso, una intención de
acción AC TION_TECH_DISCOVERED.
Nivel 3: por último, si no se ha podido seleccionar ninguna aplicación en las dos etapas
anteriores, se crea una intención de tipo A CTION_TAG_DISCOVERED, que se provee a la
aplicación que tenga en cuenta esta acción de intención.

Es tarea del desarrollador declarar los filtros de intención que mejor se correspondan con los mensajes
utilizados en su aplicación. En efecto, en el caso de que existan varias aplicaciones disponibles, el
sistema proporciona la lista de aplicaciones candidatas y deja que el usuario seleccione la aplicación
que se iniciará.

Es importante que el desarrollador declare la compatibilidad de los tags NFC en su aplicación.


Resulta, en efecto, fundamental que la aplicación se seleccione lo antes posible en el proceso de
selección por el sistema, en caso contrario corre el riesgo de que alguna otra aplicación se le
adelante y se inicie antes. Por otro lado, si el desarrollador declara la compatibilidad con una
tecnología que no gestiona correctamente puede contrariar al usuario, ¡que desinstalará la
aplicación tras el primer error!

1. Compatibilidad con una intención ACTION_NDEF_DISCOVERED


En el caso de un mensaje con formato NDEF, es el propio mensaje el que se encapsula en la
intención ACTION_NDEF_DISCOVERED.
El sistema lee el primer registro del mensaje NDEF, para determinar la estructura del conjunto del
mensaje.

A continuación se enumeran los formatos compatibles con la intención y los filtros de intención
correspondientes:

TNF_ABSOLUTE_URI
El filtro de intención correspondiente a este formato es el siguiente:

<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:scheme="http"
android:host="www.misitioweb.es"
android:pathPrefix="/inicio.html" />
</intent-filter>

TNF_MIME_MEDIA
Es compatible con todos los tipos MIME: la etiqueta <data android:mimetype>permite
filtrar el o los tipos compatibles.

<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:mimeType="text/plain" />
</intent-filter>

TNF_EXTERNAL_TYPE
Este formato permite definir un tipo de mensaje propietario. El filtro de intención menciona el
dominio, que se corresponde con la organización que declara este tipo propietario, y el tipo
deseado. Esta información se indica en la propiedad p athPrefixde la etiqueta data. La
etiqueta datacontiene también el esquema utilizado, así como la mención al tipo externo.

<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="vnd.android.nfc"
android:host="ext"
android:pathPrefix="/com.midominio:miTipo"/>
</intent-filter>

TNF_WELL_KNOWN
Este formato debe verse como un formato que encapsula varios subtipos, y que provee
convenciones de formato de escritura de datos, de cara a hacer el conjunto más compacto y
eficaz. Los subtipos, prefijados por RTD(Record Type Definition), se corresponden con los que
pueden codificarse en un tag NFC: principalmente, texto (R TD_TEXT), una URI (RTD_URI) o
un smart_poster (RTD_ SMART_POSTER). Por ejemplo, el subtipo RTD_URI permite
almacenar el protocolo en un byte, en lugar de escribirlo completamente, como sería
necesario en un registro de formato T NF_ABSOLUTE_URI.
El filtro de intención compatible con un registro de tipo WELL_KNOWN es el correspondiente a
su subtipo.

Se recomienda almacenar los mensajes en formato TNF_WELL_KNOWN, este formato es más


eficaz que los formatos TNF que encapsula. ¡No hay que olvidar que los tags NFC baratos no
pueden almacenar más de 48 bytes!

TNF_EMPTY, TNF_UNCHANGEDy TNF_UNKNOWN


Estos tipos de registro no son compatibles con un mensaje de tipo NDEF. En su lugar, se
inicia una intención de tipo ACTION_TECH_DISCOVERED.

2. Compatibilidad con una intención ACTION_TECH_DISCOVERED


Si se selecciona la aplicación en la segunda etapa, la intención provista tendrá una
acción ACT ION_TECH_DISCOVERED. La información encapsulada en la intención será la relativa a
las tecnologías del tag y al contenido en formato binario. El paquete android.nfc.techprovee
las clases de encapsulación para cada tecnología, facilitando la explotación del contenido del
mensaje.

Para filtrar correctamente la intención creada por el sistema, el desarrollador debe especificar en
elmanifestla lista de tecnologías con las que es compatible su aplicación.

Esta lista debe declararse en un archivo XML, en forma de enumeración. La raíz de la enumeración es
el tag < tech-list>.
El formato del archivo XML es el siguiente:
<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
<tech-list>
<tech>...</tech>
<tech>...</tech>
</tech-list>
</resources>

El archivo puede contener varias etiquetas < tech>, cada una de las etiquetas especifica una
tecnología. El sistema interpreta esta información considerando la lista como una lista " Y": la
aplicación se inicia si el tag leído es compatible con todas las tecnologías enumeradas.

Es posible especificar varias listas de tecnologías, informando varios tags <tech-list> en el


archivo XML. Cada lista se comporta respecto a las demás como una enumeración " O". Este
mecanismo permite especificar varios subconjuntos de tecnologías.

El siguiente ejemplo presenta un archivo XML que indica que la aplicación es compatible con los tags
de tecnologías NfcA y NDEF o MifareClassic y MifareUltraLight.

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
<tech-list>
<tech>android.nfc.tech.NfcA</tech>
<tech>android.nfc.tech.Ndef</tech>
</tech-list>

<tech-list>
<tech>android.nfc.tech.MifareClassic</tech>
<tech>android.nfc.tech.MifareUltralight</tech>
</tech-list>
</resources>

El archivo XML de las tecnologías compatibles puede llamarse de cualquier forma. Se ubica en la
carpeta /r es/xml, y se incluye una etiqueta XML en el manifestindicando el nombre de archivo
de las te ch-lists.

<activity>
...
<intent-filter>
<action android:name="android.nfc.action.TECH_DISCOVERED"/>
</intent-filter>

<meta-data android:name="android.nfc.action.TECH_DISCOVERED"
android:resource="@xml/mi_lista_tech " />
...
</activity>

Si la aplicación tiene como objetivo escribir tags NFC sobre un soporte, es preciso filtrar este
tipo de intención, teniendo en cuenta que los tags están vacíos en el momento de la selección
de la aplicación por parte del sistema. La elección se realiza, por tanto, de manera natural sobre
las tecnologías soportadas en el tag.

3. Compatibilidad con una intención ACTION_TAG_DISCOVERED


Una intención ACT ION_TAG_DISCOVEREDserá más compleja de gestionar, pues la intención no
encapsula más que el contenido en formato binario. Es tarea del desarrollador parsear correctamente
la tabla binaria para extraer la información.

El filtro de intención que se corresponde con intenciones de tipo ACTION_TAG_DISCOVEREDrefleja


bien el aspecto genérico de este tipo de compatibilidad, no indica ningún contenido para el mensaje,
ni tampoco ninguna tecnología.

<intent-filter>
<action android:name="android.nfc.action.TAG_DISCOVERED"/>
</intent-filter>

4. Android Application Records


Android 4.0 incluye un nuevo tipo de registro en los tags NFC: los Android Application Records (AAR).
Este tipo de registro permite especificar explícitamente el nombre de la aplicación compatible con un
tag NFC.

Para ello, tras descubrir un tag que contiene un mensaje de tipo NDEF, el sistema Android analiza
todos los registros del mensaje con la intención de encontrar un registro AAR. Si este registro existe,
se inicia la aplicación mencionada en el registro. Si la aplicación no estuviera instalada en el
dispositivo del usuario, el sistema propondrá descargarla directamente de Play Store.

A diferencia del mecanismo de descubrimiento por filtro de intención, el inicio de la aplicación


mediante un registro AAR se realiza a nivel de la aplicación, no a nivel de la actividad.

Los sistemas Android de versión anterior a la versión 4.0 no son compatibles con los registros
AAR; el desarrollador que desee incluir una compatibilidad con las versiones 2.x y 3.x deberá
implementar también los filtros de intención.

5. Foreground dispatch
Cuando su aplicación de gestión de tags NFC se ejecuta, puede resultar molesto para el usuario que
presenta un tag que se abra una ventana de notificación que pide seleccionar qué aplicación debe
utilizar el tag: lo deseable, en este caso, sería forzar al sistema a utilizar la aplicación en curso.

Para ello, conviene implementar en la actividad en curso, la misma que debe utilizar el tag, un
mecanismo de sobrecarga, llamado foreground dispatch.

Este mecanismo se declara en el código de la actividad, habitualmente en los


métodos onCreate() y onResume(), con ayuda del
método en ableForegroundDispatch(...)del objeto NfcAdapter.
Los parámetros esperados por el método enableForegroundDispatchson los siguientes:

La actividad que se ejecutará cuando se descubra el tag.

Un objeto de tipo Pen dingIntent, que se rellenará por el sistema y se proveerá a la


actividad. Para no volver a abrir la actividad en curso, el Pending Intentse declarará con el
flag In tent.FLAG_ACTIVITY_SINGLE_TOP.
Una tabla de IntentFilter, que indicará al sistema cuáles son las intenciones compatibles
con la actividad.

Por último, una tabla de dos dimensiones indicando qué tecnologías NFC son compatibles con
la actividad.

Por otro lado, es indispensable que la actividad que invoca al


método enableForegroundDispatch(...) se habilite. Por ello, la llamada se hará en el
método onResume()de la actividad.

Del mismo modo, conviene deshabilitar el mecanismo de foreground dis patch cuando se pone
la actividad en pausa, invocando al método d isableForegroundDispatch() desde el
método o nPause()de la actividad.
Es posible recuperar la intención que se envía a la actividad cuando se descubre el tag mediante el
método on NewIntent(Intent)de la actividad. Para ello, es preciso sobrecargar este método
para procesar la intención y su contenido.

...
NfcAdapter nfcAdapter;

@Override
public void onCreate(Bundle savedState) {
super.onCreate(savedState);
// ...

nfcAdapter = NfcAdapter.getDefaultAdapter(this);

@Override
public void onResume() {
super.onResume();
if(nfcAdapter==null)
return;
nfcAdapter.enableForegroundDispatch(this, getPendingIntent(),
getIntentFilters(), getTechLists());
}

@Override
public void onPause() {
super.onPause();
if(nfcAdapter==null)
return;
nfcAdapter.disableForegroundDispatch(this);
}

@Override
public void onNewIntent(Intent intent) {
Tag tagFromIntent = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
Toast.makeText(this, "Tag descubierto", Toast.LENGTH_LONG).show();
}
...

Tradicionalmente, el mecanismo de foregroundDispatch se utiliza para escribir tags NFC, la


compatibilidad de los tags de lectura se ha declarado en el manifiesto. En este escenario, es
posible imaginar cómo se invoca al método e nableForegroundDispatch en el
método o nClickde un botón de la interfaz, por ejemplo.

El mecanismo de foregroundDispatch es prioritario al mecanismo de Android Application Record.

También podría gustarte