×
Namespaces

Variants
Actions
Revision as of 02:31, 26 July 2013 by hamishwillee (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Como armazenar dados de aplicações em Tags NFC

From Nokia Developer Wiki
Jump to: navigation, search

Este artigo explica o que é a melhor forma de armazenar dados de aplicações personalizadas numa tag NFC, considerando também compatibilidade entre plataformas e a capacidade de lançar sua aplicação.

WP Metro Icon File.png
WP Metro Icon NFC.png
WP Metro Icon Porting.png
WP Metro Icon WP8.png
Article Metadata

Compatibilidade
Plataforma(s):
Windows Phone 8

Artigo
Tradução:
Por cronius
Última alteração feita por hamishwillee em 26 Jul 2013

Contents

Introdução

Se você quiser trabalhar com tags NFC, a decisão mais importante é o tipo de conteúdo para escrever sobre as tags. NFC é uma tecnologia complexa. É fácil escolher um tipo errado ou sub-óptimo, especialmente porque muitos tutoriais na web sugerem a gravação de dados de uma forma que limita a sua compatibilidade em multiplataforma.

Este artigo fornece uma visão geral sobre os diferentes tipos de conteúdo para escrever, usando o Windows (Phone) 8 e suas APIs como base para explicações e exemplos de código. A imagem a seguir destaca as vantagens e desvantagens mais relevantes:

NfcAppDataPT.png

NDEF como camada de base

As Tags NFC podem conter qualquer tipo de conteúdo binário - mas para garantir que cada dispositivo pode ler as tags, é geralmente a melhor escolha para escrever uma mensagem padronizada baseada na NFC Data Format Exchange (NDEF).

NDEF essencialmente adiciona um cabeçalho padronizado para os seus conteúdos - o cabeçalho contém informações sobre o tipo de conteúdo que se esperar como carga útil. O dispositivo de leitura, então sabe como lidar ainda mais com o conteúdo da tag. Portanto, se você gostaria que outros dispositivos possam o conteúdo da seu tag, você precisa seguir o padrão NDEF. Em diversos casos de utilização, isto não é desejável, e os conteúdos das etiquetas não são formatadas de acordo com as normas NDEF - por exemplo, o caso de muitos cartões de acesso ou cartões de crédito, os quais não se destinam a serem lidos por meio de dispositivos móveis para fora da caixa.

Note.pngNote: Apenas Windows 8 e Phone 8 oferecem a possibilidade de trabalhar com dados NDEF - a plataforma actual não permite a leitura ou gravação de dados que não fazem parte de uma mensagem NDEF.

Tipos de conteúdo para armazenar dados de aplicações

Mas, mesmo dentro dos limites de NDEF, vários tipos de conteúdo diferentes existem - cada um com os seus diferentes usos e vantagens. Alguns deles podem ser usados para lançar a sua aplicação, alguns podem não ser reconhecidos por telefones por padrão, e alguns têm problemas com compatibilidade entre plataformas.

O Protocolo Windows - geralmente deve ser sua última opção

Apenas use o protocolo do Windows (Windows:WriteTag) se você realmente sabe o que está a fazer e se você estiver a usar esse tipo de registo de propósito.

Tocar num tag escrita usando Windows:WriteTag não irá desencadear qualquer tipo de ação padrão num telefone - o telefone detecta a mensagem, mas não reage a ela. Portanto, você não pode usar esse tipo de arranque de aplicação, o que é geralmente desejável quando se usam tags NFC. É possível ler estas tags dentro da sua aplicação se ela já está aberta.

Warning.pngWarning: Apenas use o protocolo do Windows (Windows:WriteTag) se você realmente sabe o que está a fazer e se você estiver a usar esse tipo de registo de propósito.

Tocar num tag escrita usando Windows:WriteTag não irá desencadear qualquer tipo de ação padrão num telefone - o telefone detecta a mensagem, mas não reage a ela. Portanto, você não pode usar esse tipo de arranque de aplicação, o que é geralmente desejável quando se usam tags NFC. É possível ler estas tags dentro da sua aplicação se ela já está aberta.

Muitos tutoriais sobre a Proximidade no Windows sugerem gravação de dados em tags usando o formato Windows:WriteTag - também o nome deste tipo sugere que este tipo iria escrever uma tag padrão. Para escrever uma tag, código como o seguinte é geralmente usado em tutoriais e documentação:

var dataWriter = new DataWriter { UnicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.Utf8 };
dataWriter.WriteString("Custom Data");
_device.PublishBinaryMessage("Windows:WriteTag.MyData", dataWriter.DetachBuffer(), MessageWrittenHandler);

O dataWriter contém os conteúdos a serem escritos para a tag, o nome do tipo depois de Windows:WriteTag (neste exemplo MyData) define o subtipo personalizado.

Problemas com o Protocolo do Windows

O método Windows:WriteTag vai escrever uma mensagem NDEF com o nome dotipo de formato 0x03 = URI absoluto para uma tag. As especificações NFC requerem que o próprio nome do tipo (no exemplo MyData acima) é formatado de acordo com o construtor URI-absoluto definido pela RFC 3986.

Os URIs devem identificar um recurso - por nome, localização ou qualquer outra característica. Recomenda-se que o tipo segue os padrões do esquema URI. A definição do RFC 3986 descreve URIs para começar com um nome dum esquema - por exemplo: “http://www.ietf.org/rfc/rfc2396.txt”, “mailto:John.Doe@example.com” ou “tel:+1-816-555-1212”.

Obviamente, o nosso tipo MyData não é um esquema de URI válido.

A documentação do MSDN sugere ainda que os conteúdos do tipo Windows contêm dados binários.

A questão lógica que se coloca é que qualquer dispositivo de leitura apanha um URI absoluto, que não segue as normas e, portanto, não pode ser tratado, além de como a carga (= conteúdo) da mensagem de alguns dados binários arbitrários. Como consequência, normalmente você vai ter problemas se usar o protocolo do Windows para escrever tags -os telemóveis não conseguem lidar com eles, e pode mesmo rejeitar as tags com um tipo que não segue os padrões de URI. Portanto, use apenas o protocolo do Windows, se você realmente sabe o que está a fazer e se você estiver a usar esse tipo de registo de propósito.

Escrevendo dados binários

De acordo com as especificações do Fórum NFC, recomenda-se usar um nome de tipo externo (tipo do nome do formato = 0x04) para armazenar dados personalizados (binários e não o tipo de URI absoluto como utilizado pelo protocolo do Windows, que deve identificar um recurso como acima descrito).

Através deste tipo externo, você pode auto alocar um espaço de nome para ser utilizado para fins próprios. O nome do tipo deve ser formado "levando o nome da entidade emissora de domínio, acrescentando dois pontos, e, em seguida, adicionando o nome do tipo como gerenciado pela organização." (Extraído da especificação).

Um nome de tipo válido portanto seria: my.com:xx.

A carga útil do tipo do registro externo pode ser qualquer coisa, conforme definido pela sua aplicação / organização.

Problemas com o Nome de Tipo Externo

Embora você possa usar nomes de tipo externos com Symbian e MeeGo, e até mesmo associar a sua aplicação com o nome do tipo, esse tipo não é bem suportado pelo Windows (Phone) 8.

Windows Phone vai novamente detectar a tag, mas não reagem com ele. Portanto, você pode ler as mensagens formatadas de acordo com o nome do tipo externo com a aplicação, mas você não pode iniciar automaticamente a aplicação através deste tipo. Além disso, as APIs de proximidade apenas fornecem os meios para escrever dados binários totalmente personalizados para tags, mas não ajudam a envolver os seus dados numa mensagem NDEF formatada de acordo com o nome do tipo externo.

Para isso, seria necessário para implementar as normas do Forum NFC manualmente, e misturar um monte de bits e bytes, a fim de criar cabeçalhos NDEF válidos.

Felizmente, você pode usar a biblioteca NDEF de codigo livre para APIs de proximidade, que vai embrulhar os seus dados binários numa mensagem NDEF correta. Usando a biblioteca, você pode escrever a mensagem para uma tag desta forma:

var externalRecord = new NdefRecord(NdefRecord.TypeNameFormatType.ExternalRtd, new[] { (byte)'m', (byte)'y', (byte)'.', (byte)'c', (byte)'o', (byte)'m', (byte)':', (byte)'x', (byte)'x' });
externalRecord.Payload = new[] {(byte) 'x'};
var ndefMsg = new NdefMessage {externalRecord};
_device.PublishBinaryMessage("NDEF:WriteTag", ndefMsg.ToByteArray().AsBuffer());

Escrevendo URIs que contêm dados

Em geral, o conteúdo da tag NFC mais compatível é um registo URL - um dos tipos conhecidos que cada dispositivo compatível com as normas do Fórum NFC deve entender (para o técnico interessado: o nome do tipo do formato: 0x01, nome do tipo: U). Com um URL, você pode fazer duas coisas:

Hiperligar para o seu website: por exemplo, http://www.nfcinteractor.com/download/
A página contém mais informações sobre a aplicação, links de download, e um link para abrir a aplicação. É recomendado para determinar a plataforma do site, para apresentar o link de download da aplicação para a plataforma certa para o utilizador. O link para iniciar a aplicação será formatado de acordo com o esquema URI personalizado descrito abaixo.
Para inserir dados personalizados da aplicação, envie-o para website como parâmetro, que pode então processá-lo e inseri-lo nos dados do link para iniciar a sua aplicação. Por exemplo: http://www.nfcinteractor.com/download/?mode=compose

Esquema URI personalizado: nfcinteractor:compose
O Windows Phone e o Android vão permitir que a sua aplicação se registe para esquema URI personalizado. Quando o usuário toca a tag, o telefone irá iniciar automaticamente a aplicação registada para aquele esquema. No exemplo acima, o nome do esquema seria nfcinteractor: os dados da aplicação compose.
No caso da aplicação ainda não estar instalada, o utilizador é enviado directamente para a loja, onde ele pode fazer o download da aplicação.
Uma desvantagem do esquema URI personalizado é que também o seu concorrente se pode registar para o mesmo esquema URI. Se o utilizador toca a tag e não tem a aplicação instalada, ele terá a opção de instalar a sua aplicação e do seu concorrente.

Quando usar um site, e quando usar um esquema URI personalizado? Ambas as abordagens têm vantagens exclusivas:

Link do site

  • Melhor acompanhamento de uso: você pode ver quantas pessoas bateram na sua tag e seguiu o link, e recolher estatísticas sobre os sistemas operativos usados.
  • Apresentando mais informações: no seu site, você pode apresentar informações adicionais sobre o porquê de o utilizador dever proceder para fazer o download da aplicação.
  • Opção segura: o URL do site funciona mesmo em telemóveis onde você não tem uma aplicação específica disponível.


Esquema URI personalizado

  • Melhor experiência do utilizador: a tag lança directamente a aplicação, sem a necessidade de ir a um site intermédio (especialmente complicado se a aplicação já estiver instalada).

Que tipo devo escolher?

Não há nenhum vencedor preferido a partir dessas duas opções, mas depende do seu objectivo de uso. Se você está a colocar as suas marcas num lugar público, onde você vai ter um monte de utilizadores pela primeira vez, provavelmente é melhor usar o link normal do website. Se você espera que a maioria dos utilizadores tenham a aplicação instalada, é melhor usar o esquema URI personalizado.

Para escrever um URL para uma tag NFC, use o seguinte código - funciona tanto para o esquema URI personalizado, bem como para as ligações HTTP:

var dataWriter = new Windows.Storage.Streams.DataWriter { UnicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.Utf16LE};
dataWriter.WriteString("nfcinteractor:compose");
var dataBuffer = dataWriter.DetachBuffer();
_device.PublishBinaryMessage("WindowsUri:WriteTag", dataBuffer);

Tags do tipo LaunchApp

Ambos Windows Phone e Android definiram tipos de registos próprios que podem ser directamente ligados para uma aplicação.

Para Android, você normalmente usaria um registo URL como primeiro registo NDEF na mensagem, e como um segundo registo o registo de aplicativos Android (AAR). O primeiro registo de URL garante a compatibilidade entre multiplataformas. Este segundo registo contém exclusivamente o seu nome do pacote, e directamente abre sua aplicação. A aplicação pode, então, analisar a URL e os dados de aplicação personalizadas contidas no link URL ou parâmetros. Para escrever uma tag do tipo multi-registo, você também pode usar a biblioteca NDEF, como Windows Phone não oferece suporte para compor tags do tipo multi-registo para fora.

Para o Windows (Phone), é um pouco mais complicado. A Microsoft definiu o tipo LaunchApp, que pode conter dados de aplicações personalizadas e seu ID da aplicação. No entanto, o registo LaunchApp precisa de estar em primeiro lugar na tag - o que significa que isso irá causar problemas de compatibilidade com a maioria das outras plataformas, que não entendem o registo Microsoft específico e não lidar totalmente com a tag. O artigo Como criar tags NFC do tipo LaunchApp em multiplataformas contém instruções sobre como contornar essa limitação, mas, em muitos casos, você vai melhor usar para fora um registo URL, como descrito acima, e só usar o LaunchApp se você estiver a trabalhar num cenário restrito, onde você sabe que quase todos os seus clientes irão utilizar dispositivos baseados no Windows.

Sumário

Escolher o tipo de conteúdo adequado para o armazenamento de dados de aplicações é uma escolha difícil - especialmente porque normalmente você também quer que o tag seja ser capaz de descobrir / lançar a sua aplicação.

Na maioria dos casos, o Protocolo do Windows não é a escolha certa para o armazenamento de dados de aplicações. O tipo externo foi padronizado para cenários de dados de aplicações personalizadas, mas não é bem suportado na plataforma Windows. O registo LaunchApp do Windows funciona muito bem num ambiente somente para Windows, mas é problemático para usos em multiplataformas.

Isso deixa a opção de armazenar a URL HTTP ou um esquema URI personalizado.

Para mais flexibilidade e uso em multi-plataforma, o link URL HTTP para o seu site é a escolha mais segura. O esquema URI personalizada é um compromisso que funciona bem no Windows e Android e lança diretamente a sua aplicação, mas já reduz a compatibilidade entre plataformas.

Faça a sua escolha de acordo com o quanto você sabe sobre o seu público-alvo. Para tags públicas que você coloca na natureza, geralmente é melhor ligar para o seu site, que, em seguida, lida com mais plataformas e pode iniciar a aplicação. Para cenários onde você sabe que a maioria dos seus utilizadores usam o Windows ou Android, e se você quiser fornecer a melhor experiência de utilizador para iniciar a aplicação, use um esquema URI personalizado.

This page was last modified on 26 July 2013, at 02:31.
144 page views in the last 30 days.