Inhalt. 4 Einführung in NDEF NDEF-Struktur Datensatz-Layout... 54

Transkript

1

2 Inhalt 1 Einleitung... 1 Für wen dieses Buch gedacht ist... 2 Literaturempfehlungen... 2 Um was es in diesem Buch geht... 3 Was Sie benötigen... 4 In diesem Buch genutzte Konventionen... 8 Danksagungen NFC und RFID Was ist RFID? Was ist NFC? Wie RFID arbeitet Wie NFC funktioniert Die Architektur von NFC Passende Devices und Tag-Typen Was Sie mit NFC machen können Zusammenfassung Einstieg mit PhoneGap und der PhoneGap-NFC-Bibliothek Warum Android? Hallo Welt! Ihre erste PhoneGap-App Eine einfache Locator-App PhoneGap trifft NFC: NFC-Leser Zusammenfassung Einführung in NDEF NDEF-Struktur Datensatz-Layout V

3 NDEF in der Praxis Eine Tag-Writer-Anwendung: Foursquare Check-In Zusammenfassung Auf NDEF-Nachrichten lauschen Event-Listener des PhoneGap-NFC-Plugins Eine NDEF-Reader-Anwendung Das Tag Dispatch System von Android Zusammenfassung Eine NFC-Anwendung in der Praxis Die Benutzerinteraktion Lernen Sie Hue kennen Die Android-Shell Die PhoneGap Media-API Die Benutzeroberfläche Der Anwendungscode Zusammenfassung Einführung in Arduino und NFC Digital trifft real: Der Arduino Der Hardware-Kern von NFC Die Entwicklungsumgebung für den Arduino Die Arduino NDEF-Bibliothek Eine Mikrocontroller-NFC-Anwendung: Hotel-Schlüsselkarten Eine Browser-Oberfläche für das Arduino NDEF Writer Device Zusammenfassung Peer-to-Peer-Kommunikation Peer-to-Peer-Nachrichten mit PhoneGap übertragen Peer-to-Peer-Nachrichten mit PhoneGap empfangen Handover Handover-Nachrichten mit PhoneGap übertragen Peer-to-Peer mit dem Arduino Karten-Emulation Zusammenfassung NFC auf Embedded Systems Einführung in Embedded Linux Devices und Paketmanager NFC auf Embedded Linux: Überblick VI Inhalt

4 Vor der Installation Die NFC-Tools installieren Befehlszeilen-Tools von Libnfc und Libfreefare Lesen und Schreiben von NDEF in Node.js Web-Oberfläche für den Tag-Writer Interaktion mit Tags und der realen Welt Zusammenfassung Anhang: NFC-Spezifikations-Codes Index Inhalt VII

5 KAPITEL 4 Einführung in NDEF Um NFC zu verstehen, müssen Sie das NFC Data Exchange Format (NDEF) kennen die Lingua Franca für NFC-Devices und Tags. In diesem Kapitel werden Sie die Struktur von NDEF und die darin enthaltenen Datensätze kennenlernen. Zudem werden Sie ein paar Apps schreiben, die NDEF-formatierte Nachrichten lesen und schreiben. NDEF-Struktur NDEF ist ein Binärformat, das in Nachrichten (Messages) aufgebaut ist, von denen jede aus mehreren Datensätzen (Records) besteht (siehe Abbildung 4-1). Jeder Datensatz besteht aus einem Header mit Metadaten zum Datensatz zum Beispiel Datensatztyp und -Länge und der Payload (Nutzlast) mit dem Inhalt der Nachricht. Stellen Sie sich eine NDEF-Nachricht wie einen Absatz vor und die Datensätze wie Sätze in diesem Absatz. Ein wohlgeformter Absatz besteht aus Sätzen zu einem bestimmten Thema. Genauso soll auch eine NDEF-Nachricht mittels einer Reihe von Datensätzen ein Objekt beschreiben zum Beispiel einen Adressbucheintrag. NFC-Transaktionen sind im Allgemeinen kurz. Jeder Austausch besteht meist aus nur einer Nachricht und jedes Tag enthält auch nur eine Nachricht. Denken Sie an die physikalischen Gegebenheiten bei einer NFC-Transaktion: Sie tippen mit Ihrem Gerät an ein anderes Gerät oder ein Tag und der gesamte Austausch findet statt, während Sie sich in Kontakt mit dem Gegenüber befinden. Sie möchten mit einer Transaktion keinen ganzen Roman übermitteln, daher gehen Sie bei der Länge einer NDEF-Nachricht auch wieder eher von einem Absatzes als von einem Buch aus. Für das Übertragen größerer Dateien werden Sie noch eine Alternative in einem der letzten Kapitel dieses Buches kennenlernen, aber an dieser Stelle gehen wir von einem NFC-Austausch als einer NDEF-Nachricht und einer NDEF- Nachricht als Sammlung mehrerer kurzer Datensätze aus. 49

6 NDEF-Nachricht (variable Länge) NDEF-Datensatz NDEF-Datensatz NDEF-Datensatz NDEF-Datensätze (variable Länge) Datensatz- Header Datensatz- Payload Datensatz- Header Datensatz- Payload Datensatz- Header Datensatz- Payload Datensatz 1: Kontaktname Datensatz 2: Kontakttelefonnummer Datensatz 3: Kontaktadresse Abbildung 4-1: Die Struktur einer NDEF-Nachricht, die aus mehreren Datensätzen besteht. Dies ist ein typisches Beispiel ein Adressbuch-Eintrag mit drei Datensätzen (Name, Telefonnummer, Adresse) Ein NDEF-Datensatz besteht aus einer Payload mit den Daten und aus Metadaten, die beschreiben, wie die Payload zu interpretieren ist. Die Payload jedes Datensatzes kann aus einem von vielen verschiedenen Datentypen bestehen. Der Header jedes Datensatzes enthält die Metadaten, die den Datensatz und seine Position in der Nachricht beschreiben, gefolgt vom Typ und der ID. Nach dem Header folgt dann die Payload. Abbildung 4-2 zeigt im Detail, wie ein NDEF-Datensatz aufgebaut ist. NDEF-Nachricht (variable Länge) NDEF-Datensatz NDEF-Datensatz NDEF-Datensatz NDEF-Datensätze (Variabel) Datensatz-Header Variabel Datensatz-Payload Variabel Datensatz- Header (6-9 Byte lang) TNF + Flags Typ- Länge Payload- Länge Payload- Länge Payload- Länge Payload- Länge ID-Länge Payload-Typ Payload-ID 1 Byte 1 Byte 1 Byte 1 Byte 1 Byte 1 Byte 1 Byte Variabel Variable Nachrichten- Flags (1 Byte lang) Message Begin Message End Chunk Flag Short Record ID Length 1 Bit 1 Bit 1 Bit 1 Bit 1 Bit (boolean) Type Name Format 3 Bits Abbildung 4-2: Struktur einer NDEF-Nachricht mit den Details zu den Header-Bytes Wie Sie anhand von Abbildung 4-2 sehen können, besteht ein NDEF-Datensatz aus einem Type Name Format (TNF), einem Payload-Typ, einer Payload-Kennung und der Payload an sich. Die Payload ist der wichtigste Teil eines NDEF-Datensatzes sie ist der Inhalt, den Sie übermitteln möchten. Das TNF beschreibt, wie Sie den Payload-Typ zu interpretieren haben. Dieser ist ein NFC-spezifischer Typ MIME-Media-Typ oder eine URI, über die Sie erfahren, wie die Payload aufgebaut ist. Man kann es sich auch so vorstellen: Das TNF enthält die Metadaten des Payload-Typs und der Payload-Typ die Metadaten der Payload. Die Payload-Kennung ist optional und ermöglicht, Payloads aufeinander verweisen zu lassen. 50 Kapitel 4: Einführung in NDEF

7 Type Name Format NDEF-Datensätze beginnen mit einem Type Name Format. Das TNF beschreibt die Struktur des Wertes im Typ-Feld und Sie erfahren damit, wie dieser zu interpretieren ist. Es gibt acht mögliche TNF-Werte: 0 Empty Ein leerer Datensatz ohne Typ oder Payload 1 Well-Known Einer von sieben vordefinierten Typen, die in der RTD-Spezifikation des NFC Forum definiert sind 2 MIME Media-Type Ein Internet Media-Typ, wie er im RFC 2046 definiert ist 3 Absolute URI Ein URI, wie ihn RFC 3986 definiert 4 External Ein benutzerdefinierter Wert, basierend auf den Regeln aus der Record Type Definition-Spezifikation des NFC Forum 5 Unknown Der Typ ist unbekannt. Die Typlänge muss 0 sein 6 Unchanged Nur für mittlere und abschließende Datensätze bei einer aufgeteilten Payload. Die Typlänge muss 0 sein 7 Reserved Vom NFC Forum für zukünftige Anwendungen reserviert Bei vielen Anwendungen werden Sie vermutlich TNF 01 (Well-Known) oder TNF 02 (MIME Media-Type) für die diversen Medienformate aus dem Internet einsetzen. Auch TNF 04 (External) wird gerne genutzt, da Android den External-Typ»Android Application Record«verwendet, um Apps zu öffnen. Payload-Typ Der Payload-Typ, auch als Datensatz-Typ (Record Type) bekannt, beschreibt den Inhalt der Payload etwas genauer. Das TNF definiert nur das Format des Payload-Typs. Beim Typ kann es sich um einen NDEF-Typ, einen MIME-Typ, eine URI oder einen externen Typ handeln. Die Spezifikation für die NDEF Record Type Definition (RTD) beschreibt die Datensatz-Typen der Kategorie Well-Known und definiert die Regeln für das Erstellen externer Typen. Der MIME-RFC und der URI-RFC legen die Regeln für die anderen Typ fest. So kann zum Beispiel ein Datensatz der Art TNF 01 (Well-Known) einen Datensatz-Typ»T«für eine Textnachricht,»U«für eine URI-Nachricht oder»sp«für ein Smart Poster NDEF-Struktur 51

8 enthalten. Ein Datensatz der Art TNF 02 (MIME Media-Type) ist eventuell einer der vielen verschiedenen Datensatz-Typen wie»text/html«,»text/json«oder»image/gif«. Ein Datensatz der Art TNF 03 (Absolute URI) würde eine URI als Typ enthalten, zum Beispiel Für Datensätze der Art TNF 04 (External) gibt es ebenfalls viele verschiedene Datensatz-Typen, von denen der in diesem Buch am häufigsten genannte»android.com:pkg«lautet. Mehr Details finden Sie in der NDEF Specification zu Formaten für NFC Forum Record Type-Definitionen ( In Tabelle A-3 gibt es ebenfalls eine Liste mit gebräuchlichen NFC-RTD-Spezifikationen. NDEF-Nachrichten können mehrere Payload-Typen enthalten, aber es ist Konvention, dass der Typ des ersten Datensatzes festlegt, wie die gesamte Nachricht verarbeitet wird. So wird zum Beispiel beim Android-Filter für NDEF-Nachrichten nur der erste Datensatz beachtet. URIs in NDEF-Nachrichten Die Begriffe URI, URL und URN werden Ihnen in diesem Buch häufiger gegegnen. Ein URI (Uniform Resource Identifier) ist eine Zeichenkette, die eine Webressource identifiziert. Ein URN (Uniform Resource Name) benennt den URI, und eine URL (Uniform Resource Locator) enthält auch noch das erforderliche Transportprotokoll, um an die Ressource zu gelangen. Wenn es sich bei der URN um Ihren Namen handelt, findet sich im URI Ihre Adresse und die URL gibt an, mit welchem Bus man zu Ihnen gelangt. In Webbegriffen: URN myspecialapp URI net.tigoe.myspecialapp (im Reverse Domain Format) URL Das Type Name Format»Absolute URI«ist ein wenig missverständlich. Das TNF gibt an, dass der Datensatz-Typ ein URI ist, nicht aber die Payload. Der URI im Typ-Feld beschreibt die Payload so wie ein MIME-Typ die Payload für TNF 02 festlegt. So nutzen zum Beispiel Windows und Windows Phone TNF 03 (Absolute URI) für LaunchApp- Datensätze mit dem Wert»windows.com/LaunchApp«. LaunchApp-Datensätze fordern den Benutzer auf, eine App zu starten so wie Android die Android Application Records zum Starten von Apps einsetzt. Wenn die App nicht installiert ist, wird der Benutzer gebeten, sie aus dem Store herunterzuladen. Android umgeht die NDEF-Spezifikation mit Absolute URI-Datensätzen ein wenig. Auch wenn die NDEF-Spezifikation besagt, dass der Typ die Payload beschreibt, verarbeitet Android Datensätze der Art TNF 03 (Absolute URI), indem es den Browser mit der URI aus dem Typ-Feld öffnet damit interpretiert es diese URI so, als ob es sich um die Pay- 52 Kapitel 4: Einführung in NDEF

9 load handelt würde. BlackBerry und Windows Phone öffnen den Browser nicht, wenn ein Absolute URI-Tag gescannt wird. Wenn Sie ein URI oder eine URL als Payload verschicken möchten, sollten Sie nicht TNF 03 (Absolute URI) verwenden, sondern sie als TNF 01 (Well-Known) mit der NFC RTD»U«(URI) kodieren. Die NDEF-Spezifikation enthält eine URI Record Type Definition mit URI Identifier Codes für ein effizienteres Kodieren von URIs. So ist zum Beispiel 0x01 der Code für und 0x02 der für In»Verschiedene Datensatz- Typen schreiben«auf Seite 66 werden Sie ein Beispiel kennenlernen, in dem Sie eine URL zu einer Payload hinzufügen und dabei mit einem einzelnen Byte mit dem Wert 0x01 den Abschnitt beschreiben. Das werden Sie genauer in der folgenden Anwendung sehen, auch ein Blick in Tabelle A-3 kann hier helfen. Sie können URIs auch als TNF 01 (Well-Known) mit dem NFC RTD»Sp«(Smart Poster) verpacken. Bei Smart Poster-Datensätzen kann der URI von Zusatzinformationen begleitet werden, zum Beispiel textuellen Beschreibungen in mehreren Sprachen, Symbolen und weiteren Verarbeitungsanweisungen. Payload-Kennung Die Payload-Kennung, ein optionales Feld, sollte ein gültiger URI sein. Er kann relativ sein, daher ist selbst»foo«korrekt. Die Kennung wird genutzt, damit Ihre Anwendungen die Payload im Datensatz über die ID identifizieren können oder damit andere Payloads auf diese verweisen können. Es liegt an Ihnen, sich für eine Payload-ID zu entscheiden. Sie können sie aber auch weglassen. Payload Die Payload ist Ihr Inhalt. Sie kann alles enthalten, was sich in einem Bytestream verpacken lässt. Eine sauber gebaute NDEF-Bibliothek kümmert sich nicht darum, was sich in der Payload befindet, sondern leitet sie einfach weiter. Sie können die Payload verschlüsseln, reinen Text versenden, einen Binärblob übergeben oder sonstiges dort unterbringen. Die versendende Anwendung und die empfangende Anwendung müssen sich darüber einig werden, was die Payload zu bedeuten hat und wie sie formatiert ist. Abbildung 4-2 enthält weitere Informationen über das Binärformat des ersten Bytes des Datensatz-Headers. Sie werden diese Information hoffentlich niemals benötigen, da sich jede ordentlich geschriebene NDEF-Bibliothek selbst darum kümmert. Wenn Sie die in diesem Buch vorgestellten Software-Bibliotheken nutzen, ist das der Fall. Die genaueren Details der Binärformatierung werden Ihnen abgenommen und Sie können direkt zu»ndef in der Praxis«auf Seite 56 weiterblättern. Wenn Sie aber die Struktur von Nachrichten und Datensätzen genauer verstehen möchten, lesen Sie weiter. NDEF-Struktur 53

10 Datensatz-Layout Die ersten fünf Bytes des NDEF-Datensatzes sind Flags, mit denen angegeben wird, wie der Datensatz zu verarbeiten ist und welche Position er in der Nachricht hat. Die Bit-Flags im ersten Byte des Datensatz-Headers sind folgende: MB (Message Begin) True, wenn dies der erste Datensatz in einer Nachricht ist. ME (Message End) True, wenn dies der letzte Datensatz in einer Nachricht ist. CF (Chunk Flag) True, wenn dieser Datensatz aufgeteilt ist. SR (Short Record) True, wenn das Short Record Format für die Länge der Payload verwendet wird. IL (ID Length is Present) True, wenn das Feld ID Length vorhanden ist. Beachten Sie, dass das IL-Bit nicht die Länge des ID-Felds enthält, sondern nur angibt, ob letzteres vorhanden ist. Ist das IL-Bit 0, dann gibt es kein ID Length-Feld und auch kein ID-Feld. Die Bit-Flags Message Begin und Message End werden zum Verarbeiten des Datensatzes in einer Nachricht verwendet. Da eine NDEF-Nachricht nur ein Verbund von einem oder mehreren NDEF-Datensätzen ist, gibt es kein Binärformat für eine NDEF-Nachricht. Die Flags MB und ME ermöglichen Ihnen zu erkennen, wann die Nachricht beginnt und wann sie endet. Der erste Datensatz in einer Nachricht hat sein MB-Flag auf True gesetzt. Bei den»mittleren«datensätzen sind beide Flags False und beim letzten Datensatz einer Nachricht ist das Flag ME auf True gesetzt. Bei einer Nachricht mit nur einem Datensatz sind sowohl Message Begin als auch Message End auf True gesetzt. Da es nur acht mögliche Type Name Formats gibt, werden auch nur 3 Bits zum Ablegen benötigt. Das TNF ist daher in den letzten drei Bits des Message Flags Byte untergebracht. Datensatz-Header NDEF-Datensätze haben Datenstrukturen mit variabler Länge. Der Datensatz-Header enthält die Informationen, die nötig sind, um die Daten auslesen zu können. Ein NDEF-Datensatz beginnt mit dem TNF-Byte, zu dem auch die Bit-Flags gehören. Nach dem TNF folgt die Typ-Länge. Diese ist ein Byte lang und definiert die Länge des Payload-Typs in Bytes. Sie muss vorhanden sein, ihr Wert kann aber 0 betragen. Die Payload-Länge folgt als Nächstes. Das Short Record (SR)-Bit-Flag im ersten Byte des Datensatz-Headers bestimmt die Länge des Payload-Datensatzes. Wenn SR den Wert 54 Kapitel 4: Einführung in NDEF

11 True hat, ist die Payload-Länge ein Byte lang, ansonsten vier Bytes. Die Payload-Länge muss vorhanden sein, kann aber den Wert 0 haben. Wenn das ID Length-Feld vorhanden ist und das IL-Flag den Wert True hat, enthält das nächste Byte im Header die ID-Länge. Das Feld mit dem Datensatz-Typ hat eine variable Länge und folgt nach dem ID Length- Feld (oder nach dem Feld mit der Payload-Länge, wenn das IL-Flag False ist). Das Feld mit der Typ-Länge bestimmt, wie viele Bytes gelesen werden müssen. Wenn es eine Datensatz-ID gibt, folgt diese nach dem Typ. Die Länge dieses Feldes wird durch das ID Length-Byte bestimmt. Damit ist der Header abgeschlossen und als Nächstes folgt die Payload. Wie groß kann eine NDEF-Nachricht sein? Die Payload eines NDEF-Datensatzes kann höchstens Byte lang sein, denn das Feld für die Payload-Länge ist nur vier Bytes (oder 2 32 Bits) groß. Aber es können ja in einer Nachricht mehrere Datensätze zusammengefügt werden, um eine längere Payload zu ermöglichen. Theoretisch gibt es keine Obergrenze für die Länge einer NDEF-Nachricht. In der Praxis sind aber durch die Möglichkeiten Ihrer Geräte und Tags entsprechende Grenzen gesetzt. Wenn Sie Peer-to-Peer-Nachrichten zwischen Geräten austauschen und Tags nicht daran beteiligt sind, sind Ihre NDEF-Nachrichten nur durch die Rechenkapazitäten Ihrer Geräte und die Geduld desjenigen begrenzt, der die Geräte aneinanderhält. Wenn die Kommunikation zwischen Tag und Gerät erfolgt, sind Ihre Nachrichten vor allem durch die Speichergröße des Tags begrenzt. Wenn Sie NFC-Tags verwenden, liegt die Grenze für Ihre Datensätze weit unter den Byte. NFC-Tag-Typen basieren auf einigen wenigen RFID-Tag-Standards. Die meisten NFC-Tag-Typen nutzen den ISO-14443A-Standard. Dieser beginnt bei 96 Byte und reicht abhängig vom Tag-Typ bis 4K. Die Familie der Philips/NXP Mifare-Tags ist kompatibel mit NFC, ebenso die Tags vom Typ Mifare Ultralights, Mifare Classic 1K und 4K sowie Classic Mini. Es gibt einen Typ NFC-Tags, der auf dem Japanese Industrial Standard (JIS) X beruht. Dieser besitzt bis zu 1 MB Speicher. Sony FeliCa-Tags haben im Allgemeinen diesen Typ. Mehr Details zur Tag-Spezifikation finden Sie im entsprechenden Abschnitt auf der Website des NFC Forum. Im Allgemeinen werden per NFC nur wenig Daten ausgetauscht. Eine Person hält ihr Gerät an ein Tag oder ein anderes Gerät, es gibt einen kurzen Austausch und die Person geht weiter. Das Protokoll ist nicht für größere Datentransfers gedacht, da die Devices direkt aneinander gehalten werden müssen. Wenn Sie große Nachrichten übertragen, muss der Anwender das Gerät so lange an der entsprechenden Stelle halten, bis die Nachricht übermittelt ist. Das kann langweilig werden, daher verwenden die Nutzer NFC in solchen Fällen eher dafür, eine andere Kommunikationsmöglichkeit auszuhandeln und dann zu dieser sei es WLAN oder Bluetooth zu wechseln, um Daten oder Mediendaten auszutauschen. Datensatz-Layout 55

12 Hier ein typisches Beispiel für die Kooperation von NFC und WLAN: Stellen Sie sich vor, Sie haben einen NFC-fähigen Musikabspieler, der Musikstücke mit Ihrem Smartphone oder Tablet per WLAN von einem zentralen Medienserver bei Ihnen im Keller synchronisieren kann. Sie hören ein Album auf der Stereoanlage, müssen jetzt aber zur Arbeit fahren. Sie tippen mit Ihrem Smartphone an die Stereoanlage und diese teilt dem Telefon per NFC mit, welches Stück gerade läuft und wie weit es schon abgespielt ist. Ihr Telefon prüft dann, ob es das Lied in seiner Playlist findet. Ist das nicht der Fall, lädt es die Musik per WLAN oder Mobilfunk herunter. Sie verlassen das Haus und wenn Sie Ihre Kopfhörer aufsetzen, können Sie mit dem Album an der Stelle fortfahren, an der Sie es auf der Stereoanlage unterbrochen haben. Datensätze aufteilen Wenn Sie Daten übertragen müssen, die über die Grenze von Byte hinausgehen, können Sie eine Payload in Pakete (Chunks) unterteilen und in mehreren Datensätzen übertragen. Dann setzen Sie das Chunk Flag (eines der TNF-Flag-Bits) für den ersten und alle folgenden Datensätze auf 1 nur beim letzten nicht. Daten lassen sich allerdings nicht auf mehrere NDEF-Nachrichten aufteilen. Das TNF wird im ersten aufgeteilten Datensatz gesetzt. Nachfolgende Chunks müssen TNF 06 (Unchanged) verwenden. Die mittleren Chunks und der abschließende Chunk müssen eine Typ-Länge von 0 aufweisen. Die Länge der Payload eines jeden Datensatzes ist nur die der Daten in diesem Chunk. Nachrichten über 500 MB (das sind 2 32 Bits) dürften eher unwahrscheinlich sein, deshalb werden Sie Datensätze nur selten aufteilen. Aber das Chunking kann auch für dynamisch erzeugte Inhalte verwendet werden, insbesondere wenn die Länge der Payload vorab nicht bekannt ist. Chunking wird recht selten eingesetzt. Bei keiner der in diesem Buch genutzten Bibliotheken ist Chunking implementiert. Der Parser von Android liest hingegen aufgeteilte Nachrichten und kombiniert sie zu logischen NDEF-Datensätzen. Weitere Informationen Mehr Informationen zur Struktur von NDEF (einschließlich einer praktischen Sammlung von Tests für das Schreiben Ihrer eigenen Parsing-Engine) finden Sie auf den Spezifikations-Seiten des NFC Forum ( NDEF in der Praxis Um NDEF in der Praxis zu erleben, kann man sich vorhandene Anwendungen anschauen. In diesem Abschnitt werden Sie einige vorhandene Apps auf Ihr Device herunterladen, so dass Sie Tags schreiben und deren Einsatz testen können. 56 Kapitel 4: Einführung in NDEF

13 Eine der beliebtesten Aktivitäten bei den bekannten Tag-Writer-Apps ist das Check-In bei Foursquare. Wenn Sie ein entsprechend formatiertes Tag antippen, verbindet sich Ihr Device automatisch mit der Social Media App Foursquare und checkt Sie an diesem Ort ein. Allerdings geht jede App hier ein wenig anders vor und die Unterschiede zeigen sich dann auch in den Ergebnissen. Für dieses Projekt benötigen Sie Folgendes: ein NFC-fähiges Android-Smartphone fünf NFC-Tags die im Folgenden aufgeführten Apps (Sie können Sie auf Ihrem Device direkt aus Google Play installieren.) Wir gehen zudem davon aus, dass Sie Kapitel 3 durchgelesen und die Software, die zum Umsetzen der Beispiele in dem Kapitel erforderlich ist, vollständig installiert haben. Die besten Ergebnisse für verschiedene Geräte erhalten Sie mit den Tag- Typen des NFC Forum. Mifare Classic Tags lassen sich von vielen neueren Geräten nicht mehr lesen. In»Passende Devices und Tag-Typen«auf Seite 19 erfahren Sie mehr über die Zusammenarbeit von Tags und Geräten. Vermeiden Sie auch Tags vom Typ 2 (Mifare Ultralight), da diese nicht über ausreichend Speicher für dieses Projekt verfügen. Zum Vergleichen haben wir die folgenden Apps verwendet: Trigger ( von TagStand NFC TagWriter ( von NXP NFC Writer ( ebenfalls von TagStand TecTiles ( von Samsung (funktioniert nur in den USA und in Kanada) App Lancher NFC Tag Writer ( [sic] von vvakame Sie benötigen zudem noch NXP TagInfo ( um die Tags wieder auszulesen, Foursquare für Android ( und einen Foursquare- Account ( Melden Sie sich an der Foursquare-App an, bevor Sie mit den Tests fortfahren. Wenn Probleme auftreten (zum Beispiel ein Flackern und Verschwinden der App), melden Sie sich wieder an. Dies ist ein gutes Beispiel für die Art von Problemen, die außerhalb Ihrer Kontrolle liegen. Nachdem die Payload an Android übergeben wurde, ist eine App (wie Foursquare) für die weitere Verarbeitung zuständig. Wenn diese App dann ins Stolpern gerät, können Sie im Allgemeinen nicht viel tun. Machen Sie sich keine Gedanken, wenn Sie sich nicht an dem Ort befinden, an dem Sie einchecken wollen. Jede App muss um Erlaubnis fragen, wenn sie Foursquare nutzen möchte, und Sie können die Check-Ins später auch auf der Foursquare-Website wieder NDEF in der Praxis 57

14 löschen. Ihre Freunde müssen sich also nicht wundern, wo Sie sich herumtreiben, während Sie NFC testen! Das Schreiben der Tags ist für diese Apps recht einfach außer bei TagWriter. Dies sind die grundlegenden Schritte: NFC Task Launcher Öffnen Sie die App und klicken Sie oben auf das +, um einen neuen Task zu erstellen. Wählen Sie aus der Kategorie-Liste»NFC«. Geben Sie Ihrem Task einen Namen und tippen Sie dann auf den +-Button. Wählen Sie aus der Liste»Social Media«und anschließend»foursquare Check-in at a venue«. Wählen Sie ein Venue aus, indem Sie einen Namen eingeben, oder tippen Sie auf die Lupe, damit die App nach Venues in der Nähe sucht. Tippen Sie auf»ok«und anschließend auf»add to Task«. Tippen Sie auf den Pfeil nach rechts, um auf das Tag zu schreiben. Wenn Sie Ihr Telefon auf das Tag legen, wird die App den Schreibvorgang starten. TagStand Writer Öffnen Sie die App, tippen Sie auf»foursquare Venue«und wählen Sie ein Venue aus. Wenn der Bildschirm zum Schreib-Bildschirm wechselt, tippen Sie auf den Venue-Namen, um den Inhalt des Tags anzuzeigen. Schreiben Sie die URL wie in Abbildung 4-3 auf, denn Sie benötigen sie für den NXP TagWriter. Wenn Sie das Telefon über dem Tag platzieren, wird dieses beschrieben werden. Abbildung 4-3: Wenn Sie sich auf dem Tag-Schreib-Bildschirm von TagStand Writer befinden, können Sie auf den Venue-Namen tippen, um die vollständige URL des Venues zu erhalten 58 Kapitel 4: Einführung in NDEF

15 NFC TagWriter Öffnen Sie die App und wählen Sie»Create, Write, and Store«. Tippen Sie nun auf»new«und wählen Sie im angezeigten Menü»URI«aus. Geben Sie im Beschreibungsfeld»Foursquare Check-in«ein. Für diese Übung ist eine Beschreibung erforderlich, damit ein Smart Poster-Datensatz auf das Tag geschrieben wird. Geben Sie das Foursquare Venue wie folgt ein: wobei venueid ein langer, hexadezimaler String ist. Übernehmen Sie ihn von der URL, die Sie aus dem TagStand Writer abgeschrieben haben. Vergessen Sie dabei nicht das Tippen Sie auf»next«. Wenn Sie das Smartphone über das Tag halten, werden die Daten übertragen. Samsung TecTiles Achten Sie darauf, dass Foursquare schon installiert ist. Öffnen Sie die TecTiles-App und klicken Sie auf»new Task«. Geben Sie ihm einen Namen und tippen Sie auf»ok«. Tippen Sie nun auf»add«, um einen neuen Task anzulegen, und dann auf»application«. Wählen Sie in der Liste der Apps «Foursquare«aus. Tippen Sie auf»write to Tag«. Wenn Sie das Smartphone über das Tag halten, wird der Schreibvorgang gestartet. AppLauncher NFC Öffnen Sie die App und wählen Sie»Foursquare«aus. Wenn Sie das Telefon über das Tag halten, wird der Schreibvorgang gestartet. Wenn Sie fünf Tags beschrieben und beschriftet haben, probieren Sie sie aus. Schließen Sie alle Apps und halten Sie das Telefon über das Tag. Die Reaktionen sollten wie in Tabelle 4-1 ausfallen. Als Nächstes öffnen Sie NXP TagInfo. Wenn Sie das Telefon über das Tag halten, wird es von der App ausgelesen. Wenn Sie NDEF wählen, werden die NDEF-Details des Tags angezeigt (siehe Tabelle 4-1). Tabelle 4-1: Die Ausgabe jeder App App Datensatz TNF Datensatz-Typ Payload Aktion NFC Task Launcher 1 MIME x/nfctl enz:foursquare;c: 4a917563f964a520401a20e3 2 External android.com:pkg com.jwsoft.nfcactionlauncher Versucht, Task Launcher App zu starten; bei Erfolg wird die URL an die Foursquare App übergeben. Tagstand Writer: 1 Well-Known U 4a917563f964a520401a20e3 Startet die Foursquare App und navigiert zum Venue-Check-In. NDEF in der Praxis 59

16 Tabelle 4-1: Die Ausgabe jeder App (Fortsetzung) App Datensatz TNF Datensatz-Typ Payload Aktion NXP TagWriter 1 Well-Known Sp Startet die Foursquare App und navigiert zum Venue-Check-In. 1.1 U 4a917563f964a520401a20e3 1.2 T Foursquare check-in Samsung TecTiles 1 Well-Known U tectile://www/samsung.com/tectiles Versucht, die Tec- Tiles-App zu starten. 2 Well-Known T entaskfoursquarecom. joelapenna\u 1 App Launcher NFC 1 External android.com:pkg com.joelapenna.foursquared Startet nur die Launches Foursquare App. Wie Sie sehen, erledigt jede App ihre Aufgabe unterschiedlich. Es gibt aber prinzipiell vier verschiedene Vorgehensweisen: Die Foursquare App wird gestartet und der Benutzer muss sich um den Rest kümmern (App Launcher NFC). Es wird eine URI übermittelt und das Betriebssystem kümmert sich um den Rest (Tagstand Writer). Es wird die Original-App gestartet, die wiederum die Foursquare App startet (NFC Task Launcher, Samsung TecTiles). Es wird ein Smart Poster übermittelt (NXP TagWriter). Bei der erste Methode wird nur einen NDEF-Datensatz genutzt, dessen TNF auf»external«steht. Der Datensatz-Typ ist dann der Android Application Record für die zu startende Anwendung und der Inhalt ist der eigentliche Name der App. Hier ein Beispiel: TNF: External Record type: android.com:pkg com.joelapenna.foursquared Mit dieser ersten Methode informieren Sie Android lediglich darüber, welche App zu starten ist. 1 Die Samsung TecTiles-Nachricht enthält nicht ausdruckbare Zeichen. Sie sind aber nicht wichtig und wurden hier durch Punkte ersetzt. Die Zeile wurde zudem in Form von drei Punkte abgekürzt. Den vollständigen Byte-Stream erhalten Sie, indem Sie ein Tag mit TecTiles schreiben und mit NXP TagInfo auslesen. 60 Kapitel 4: Einführung in NDEF

17 Bei der zweite Methode wird auch nur ein NDEF-Datensatz genutzt, bei dem das TNF auf»well-known«steht und der Datensatz-Typ ein»u«für URI enthält. Auch in diesem Fall ist der Inhalt die eigentliche Adresse. Hier wieder ein Beispiel: TNF: Well-Known Record Type: U Mit der zweiten Methode teilen Sie Android die URI des Objekts mit, das Sie öffnen möchten, und lassen das Betriebssystem entscheiden, welche Anwendung dafür die beste Wahl ist. Das ist ein wenig so wie unter Windows, wo das Betriebssystem entscheidet, welche Anwendung eine Datei mit einer bestimmten Erweiterung öffnet. Wäre Foursquare nicht auf Ihrem Device vorhanden, hätte sich Google Play um diese URLs gekümmert. Bei der dritten Methode wird eine NDEF-Nachricht genutzt, die aus zwei NDEF-Datensätzen besteht. Sowohl beim NFC Task Launcher als auch bei den Samsung TecTiles kümmert sich die eigentliche App um das Lesen des Tags und das Starten von Foursquare. NFC Task Launcher nutzt einen MIME-Type-Datensatz, der die Foursquare Venue-Information sowie einen External AAR-Datensatz enthält, mit dem sichergestellt wird, dass die Anwendung installiert ist. TecTiles verfolgt einen ähnlichen Ansatz mit einer anderen Implementierung. Hier wird ein URI-Datensatz mit einer speziellen tectile://-url verwendet, um die Anwendung zu starten. Die Foursquare-Information wird dabei in einem zweiten Text-Datensatz verpackt. Leider startet TecTiles nur die Anwendung, ohne die Venue-Information mitzugeben. Bei beiden Applikationen kommen Intent-Filter zum Einsatz, falls sie gestartet werden sollen, wenn ihr Tag gescannt wird. NFC Task Launcher registriert sich auf den MIME-Typ x/nfctl, TecTiles auf ihre spezielle tectile://-uri. Mehr zu Intent-Filtern erfahren Sie in»das Tag Dispatch System von Android«auf Seite 88. Bei der vierte Methode kommt ein Smart Poster-Datensatz zum Einsatz. Dabei handelt es sich um einen komplexeren NDEF-Datensatz, bei dem die Payload letztendlich wieder eine weitere NDEF-Nachricht ist. Die in die Smart Poster Payload eingebettete Nachricht besteht aus zwei NDEF-Datensätzen einer URI und einem Text-Datensatz. Da Smart Poster-Datensätze mehrere Datensätze enthalten, können sie weitere Informationen zur URI enthalten zum Beispiel einen Titel, ein Symbol oder Aktions-Vorschläge. Manche der Anwendungen, wie zum Beispiel TecTiles und NFC Task Launcher, schreiben Android Application Records, um statt Foursquare ihre eigene App zu starten, die dann wiederum Foursquare startet. Damit können sie vermutlich protokollieren, wann ihre App im Einsatz ist, selbst wenn im Endeffekt eine andere App gestartet wird. Das ist komplizierter, ermöglicht aber das Erstellen von Statistiken für den Einsatz Ihrer App. Eine Tag-Writer-Anwendung: Foursquare Check-In In diesem Abschnitt werden Sie Ihre eigene Tag-Writer-App schreiben, um ein besseres Verständnis bezüglich des Vorgangs zu erhalten. Diese App ist sehr einfach sie sucht Eine Tag-Writer-Anwendung: Foursquare Check-In 61

18 nach einem Tag, das sie als NDEF-Tag formatieren kann. Wenn sie ein solches Tag findet, schreibt sie eine NDEF-Nachricht auf das Tag. Für dieses Projekt benötigen Sie Folgendes: ein NFC-fähiges Android-Smartphone fünf RFID-Tags Foursquare für Android ( und einen Foursquare ( Legen Sie als erstes ein neues Projekt an (siehe Kapitel 3). Verwenden Sie Cordova zum Erstellen eines Projekts, fügen Sie die Android-Plattform hinzu und installieren Sie das Plugin: $ cordova create ~/FoursquareCheckin com.example.checkin FoursquareCheckin 1 $ cd ~/FoursquareCheckin 2 $ cordova platform add android $ cordova plugin add 1 Windows-Anwender sollten statt ~/FoursquareCheckin das Verzeichnis %userprofile%\foursquarecheckin nutzen. 2 Windows-Anwender sollten statt ~/FoursquareCheckin den Wert /d %userprofile%\foursquarecheckin nutzen. Jetzt können Sie Ihre App schreiben, indem Sie die HTML- und JavaScript-Dateien bearbeiten. Die Datei index.html findet sich im Verzeichnis www des App-Ordners, während index.js in www/js abgelegt ist. Öffnen Sie beide und löschen Sie sämtlichen Inhalt, um Ihre eigene App von Grund auf selbst zu schreiben. Beginnen Sie mit index.html und tragen Sie Folgendes ein: <!DOCTYPE html> <html> <head> <title>foursquare Check-In Tag Writer</title> <style>body { margin: 20px }</style> </head> <body> <p>foursquare Check-In Tag Writer</p> <div class="app"> <div id="messagediv">kein Tag gefunden</div> </div> <script type="text/javascript" src="cordova.js"></script> <script type="text/javascript" src="js/index.js"></script> <script type="text/javascript"> app.initialize(); </script> </body> </html> 62 Kapitel 4: Einführung in NDEF

19 Einen NDEF-Datensatz auf ein Tag schreiben Als Nächstes werden Sie die Datei index.js bearbeiten, um einen NDEF-Datensatz zu erstellen und eine NDEF-Nachricht auf das vorgefundene Tag zu schreiben. Wir wollen es uns einfach machen und werden daher die meisten Parameter fest vorgeben. Sie haben nun schon viele Methoden kennengelernt, um einen Foursquare Check-In auszulösen. Für den Anfang werden wir es schlicht halten - wir starten die Foursquare-App über einen Android Application Record. Beginnen Sie mit einer Variablen, die geschrieben werden soll, wenn ein Tag gefunden wird: var app = { messagetowrite: [], // Nachricht, die beim nächsten NFC-Event geschrieben wird Als Nächstes folgt eine Funktion initialize(), um alles einzurichten, und eine Funktion bindevents(), um einen Event-Listener zu erstellen, der erkennt, wenn das Device bereit ist: // Anwendungs-Konstruktor initialize: function() { this.bindevents(); console.log("foursquare Checkin App wird gestartet"); }, /* Events beim Starten an Listener binden: */ bindevents: function() { document.addeventlistener('deviceready', this.ondeviceready, false); }, Nun folgt ein Handler, der den Bildschirm leert und einen Event-Listener hinzufügt, um auf gefundene Tags zu reagieren: /* Wird ausgeführt, wenn das Gerät zur Benutzerinteraktion bereit ist: */ ondeviceready: function() { app.clear(); nfc.addtagdiscoveredlistener( app.onnfc, // Tag erfolgreich gescannt function (status) { // Listener erfolgreich initialisiert app.makemessage(); app.display("tippen Sie ein NFC-Tag an, um Daten zu schreiben"); }, function (error) { // Listener ließ sich nicht initialisieren app.display("nfc-writer konnte nicht initialisiert werden " + JSON.stringify(error)); } ) }, Eine Tag-Writer-Anwendung: Foursquare Check-In 63

20 Der NFC-Event-Handler onnfc() schreibt auf das Tag: /* Aufruf, wenn ein NFC-Tag gefunden wird: */ onnfc: function(nfcevent) { app.writetag(app.messagetowrite); }, Als Nächstes folgen die Funktionen display() und clear(), die Sie schon aus»phonegap trifft NFC: NFC-Leser«auf Seite 41 kennen: an das messagediv anfügen: */ display: function(message) { var label = document.createtextnode(message), linebreak = document.createelement("br"); messagediv.appendchild(linebreak); // Zeilenumbruch... messagediv.appendchild(label); //... und Text hinzufügen }, /* messagediv leeren: */ clear: function() { messagediv.innerhtml = ""; }, Die Methoden makemessage() und writetag() nutzen die Funktionen zweier Objekte, die durch das NFC-Plugin definiert werden. Es gibt das NFC-Objekt, mit dem Sie Zugriff auf den NFC-Leser Ihres Geräts erhalten, und das NDEF-Objekt, das NDEF-Datensätze und -Nachrichten definiert und formatiert. makemessage: function() { // Die Elemente der NDEF-Nachricht zusammenbauen: var tnf = ndef.tnf_external_type, // NDEF Type Name Format recordtype = "android.com:pkg", // NDEF Datensatz-Typ payload = "com.joelapenna.foursquared", // Inhalt des Datensatzes record, // NDEF-Datensatz-Objekt message = []; // NDEF-Nachricht, die an writetag() übergeben wird // den NDEF-Datensatz erzeugen: record = ndef.record(tnf, recordtype, [], payload); // den Datensatz in das message-array einfügen: message.push(record); app.messagetowrite = message; }, writetag: function(message) { // den Datensatz auf das Tag schreiben: nfc.write( message, // den Datensatz selbst schreiben function () { // nach erfolgreichem Abschluss diese Callback-Funktion aus- // führen: app.display("daten auf Tag geschrieben."); // in messagediv schreiben }, 64 Kapitel 4: Einführung in NDEF