「AARとかどうですか？」というコメントをいただいた(ここじゃないどこかで)。
うーむ、Androidのみか・・・。
とはいえ、現在の人口に膾炙された開発環境の中で一番自由にNFCを扱うことができるのはAndroidだと思っている。
そりゃ、Arduino + NFC Shield、なんてのもあるのだろうが、OSというかプラットフォームがサポートしている方が「標準」って感じがする。
そんなわけで、AARを知っておいても問題はなかろう、と勝手に判断し、調べることにした。
Android Application Record、の略で、特にNFCとかいう言葉はついていない。
なので、私の知らないところでNFC以外のAARがあるかもしれないし、将来的に取ってあるのかもしれない。
とりあえず、AARはNFCのもの、という前提で話を進めよう。
あ、AARの「Record」は、NDEF Recordのことかもしれない。
なぜなら、AARを作るためのAPIはandroid.nfc.NdefRecordが持っているからだ。
Android Developersによると「AARは、NFCタグを読んだときにアプリを起動させるしくみ」らしい。
ということは、普通のアプリはAARのNDEFを読むことができないんじゃなかろうか？
追ってみよう。
タグの処理は、external/libnfc-xxxでやっているはず。
追うのが面倒なので省略すると、次はpackages/apps/NfcにあるNfcDispatcher.javaだ。
dispatchTag()は、たぶんlibnfcからjavaに処理が渡される最初の方だったと思う。
あまり内容を読まずに判断するなら、こういう順で判定しているようだ。
- オーバーライドできるか(知らん。。)
- Bluetooth Handoverかどうか
- NDEFかどうか
- ふさわしいTechnologyかどうか
- アクティビティを開始できるか
- マッチしなかった
AARかどうかは、3番で判定している。
処理の最初でNDEF Record Layoutの、
- TNFはexternal type(0x04)か？
- TYPEは"android.com:pkg"か？
を見て、両方trueだったらペイロードをUS_ASCIIでデコードしてパッケージ名としてリストに詰める。
詰められたパッケージ名は、先頭から順にdispatch.intent.setPackage(パッケージ名)とされる。
Android Developerに「AARのみのNDEF Messageじゃないなら、AARは先頭に置いたらいかんよ」といっているのは、こういうわけだ。先頭がAARだったら、後のレコードがどうなっていてもAARとして扱ってしまうからだろう。
AARの実装を斜め読みしたが、なんとなくわかっていただけただろうか？
私の期待としては「AARにはアプリ起動以外になにかできることが隠されているのでは・・・」なのだが、ぱっと見たところそういうのはなさそうだった。
しかし、なにか面白い使い道があるかもしれんので、もう一度どこかで見直すことにしよう。
あ、最初に書いた「普通のアプリはAARのNDEFを読むことができないんじゃなかろうか？」は、インテントフィルタなどを書けばできる、みたいなことを書いてあった。
まあ、あまりそういうのは興味がないので、いいや。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。