2014/08/31

[android]Log.d()はそのまま出る仕様なんだ!

いやあ、知らないって事は恐ろしいですな。

AndroidManifest.xmlに、確かdebaggableとかいう設定があったと思う。
だから私は「これをfalseにすれば、デバッグ出力のLog.d()は出力されないんだろう」と何の根拠もなく思い込んでいた。

偶然、「ログをリリース時にオフにする方法」みたいな記事があったので見てみると、全然そんな仕様じゃないことがわかった。
debaggableじゃなくて他の設定だろうと思って調べたけど、どうもそうではない模様。
つまり、Log.d()はそのまま出るんだ!


Javaのところは、ここ。
最後はprintln_native()が呼ばれている。
https://android.googlesource.com/platform/frameworks/base/+/android-4.3_r2.1/core/java/android/util/Log.java

 

Nativeは、これでよいのかな。
https://github.com/android/platform_frameworks_base/blob/master/core/jni/android_util_Log.cpp

__android_log_buf_write()が呼ばれるようだ。
もう、誰にも止められない・・・

JNIなんだな、ログって。
けっこう重たい動きになるんだ。


なんか、一括して、しかもバイナリレベルで呼び出されないくらいのことをしてくれんかと思って探すと、ProGuardで消すというのが一番多かった。

proguard-rules.proに、

-assumenosideeffects class android.util.Log {
    public static int v(...);
    public static int d(...);
    public static int i(...);
    public static int w(...);
    public static int e(...);
    public static int wtf(...);
}

みたいなのを書いて、build.gradleに、

buildTypes {
    release {
        runProguard true
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
}

みたいな変更をして、Signed APKを作るようだ。 

[android]Android Studio初心者 (2)

"@string/foobar"みたいな記述をしている箇所を、自動的に該当する文言で表示してくれる。
便利と言えば便利なのだが、Android勉強中の私からすると「あれ、strings.xmlにまだ入れてなかったっけ」と思って、カーソルを当ててbackspaceで削除し始めてしまうことがしばしば。
慣れるまでは、入力したものをそのまま表示してほしい。

Settingsの、IDE Settingsの、Editor > Code Foldingの中に「Android String References」があるのでチェックを外すとよい。
できれば、動的に変更できるとよいのだが・・・。


昨日、ArrayAdapterのextendsか何かを書いていたときだったと思うけど、表示が「<~>」みたいになってた。
書き間違えたんかねー、とカーソルを当ててbackspaceで削除し始めて、それが省略表記だったことに気付く、ということがしばしば。
今の私は、自動的に省略してくれることのありがたみが、まだわかる段階に来ていないのだよ・・・。

たぶんこれも、上記のCode Foldingのところにあるんじゃなかろうか。
でも、どれかよくわからないので、Importのとこだけチェックして、残りは外してしまった。
いつの日か、このチェックをデフォルトに戻せる日が来ることを信じて・・・。

[android]Android Studio初心者 (1)

プロジェクトを作るとき、こんな画面が出てくる。

image

いつもの感覚で、パッケージ名を入力していたのだが・・・。
そう、画面を見るとわかるように、ここで入力するのは「Company Domain」で、パッケージ名はその下に表示されている。
つまり、順番が逆なのだ。

前使ってるプロジェクトからファイルを持ってきて、初めて気付いた。
ちっ。

javaフォルダで右クリックしてパッケージを作り、そっちにファイル移動する、というやり方をまねした。
http://stackoverflow.com/questions/16804093/android-studio-rename-package


NdefMessageクラスを使おうとしたら、APIのバージョンが14なので使えません、と言われた。
AndroidManifest.xmlを編集すると、それはビルドするときにスクリプトが上書きするので無視されます、と言われた。。
ちっ。

build.gradleというファイルがあるので、それに追加するとよさそうだ。
なお、uses-permissionは直接書き換えるようだ。

2014/08/30

[android]ListViewに渡したいデータがString[]じゃないときは、ArrayAdapterをextendsする

前回の続き。

しか先生のコメントをいただき、toString()をOverrideするのはJava仕様としてよろしくない、という理解ができた私。
ArrayAdapterをextendsするのがよいとのことなので、やってみよう。


まずどうでもよいことから先に書くと、ListViewのレイアウトをandroid.R.layout.simple_expandable_list_item_1からsimple_list_item_1に変更した。
理由は、expandable、というのが開いたり閉じたりできるタイプだったので、そんな用途もないのでシンプルにしておきたいという理由だけだ。
XMLの中身としてはどっちも同じようなものだったと思う。

ArrayAdapterを拡張する例をネットで調べると、凝ったことをしたい人が多かった。
私のように、単にタイトルの文字列を指定したいだけ、というのがあんまりなさそうだった。
以下は、自分でListView用のXMLを作りたくない人向けになる。

    class MenuAdapter extends ArrayAdapter<ListData> {
        public MenuAdapter(Context context, int resource, ListData[] objects) {
            super(context, resource, objects);
        }
        @Override
        public View getView(int position, View convertView, ViewGroup parent) {
            TextView view = (TextView)super.getView(position, convertView, parent);
            ListData item = getItem(position);
            if ((view != null) && (item != null)) {
                view.setText(item.title);
            }
            return view;
        }
    }

ListData、というのが、自分で作ったclass。
前回はStringとintだったけど、今回はStringとStringになった。

    class ListData {
        public String title;
        public String actname;
        public ListData(String title, String value) {
            this.title = title;
            this.actname = value;
        }
    }

やってることは・・・単にTextViewにListDataのtitle文字列を設定しているだけだ。
getView()の引数convertViewがTextViewなのは、きっとandroid.R.layout.simple_list_item_1がTextViewを1つしか持っていないからだろう。

最初は、コンストラクタのresourceを保持して、他のArrayAdapterのカスタマイズ記事を見ながらInfraterなどやってたんだけど、うまく行かなかった(今思えば、Infrater後にfindViewByIdでTextViewを探そうとしたところが間違ってたかも)。
convertViewは、非nullなら再描画で使い、nullならInfraterで自作するようだから、じゃあsuperでやってくれるだろう、ということで今の形に落ち着いている。

呼び出し方は前と同じで、こう。

        String[] titles = getResources().getStringArray(R.array.main_list_label);
        String[] actnames = getResources().getStringArray(R.array.main_list_actname);
        ListData[] list_data = new ListData[titles.length];
        for (int i = 0; i < titles.length; i++) {
            list_data[i] = new ListData(titles[i], actnames[i]);
        }
        ListView lv = (ListView) findViewById(R.id.listView);
        MenuAdapter adapter = new MenuAdapter(this, android.R.layout.simple_list_item_1, list_data);
        lv.setAdapter(adapter);

 

私としてはこれでよいと思ってるんだけど、どうかな?

[android]ListViewに、文字と値のセットを持たせたい

Androidアプリで、ListViewを表示させようと思った。
と一言書かないといけないくらい、Androidのアプリはわかっていない。

今回表示させたいのは、メニュー画面と思ってもらおう。
タップしたら、別の画面に遷移するという、よくあるやつだ。
AdapterView.OnItemClickListenerをimprementsするなりnewするなりしてonItemClick()を呼んでもらえるようにすると、タップした要素が取ってこれる、というのはわかった。
気になっているのは、そこからどうやって期待する画面に遷移させるか、だ。

タップしたところの文字列が取れるけど、それを比較するのは、なんか嫌だ。
文字列の比較って、最初から最後まで一致することを比較することになると思うので、文字数分のコストがかかってしまう。
それに、何らかの理由で同じ文字列が複数あったら、もうだめだ。

じゃあ、タップしたインデックス値ならどうか。
それだと、値は一意で決まるから、同じ文字列があっても問題はない。
比較するのも1回分のコストで済む。
ただ・・・表示する文字列は<string-array>でやろうと思っているので、書くのはXMLになる。
もし気分が変わってメニューの項目順を変えてしまったら、実装の方も変更しないといかん。
うーん、それは気が進まない・・・。

そこで思ったのが、文字列と値をセットにしたものをListViewに持たせられないか?というもの。
調べてみると、どこかのサイトに、toString()で返す値が表示されるだけだよ、とあった。

    class ListData {
        public String title;
        public int value;
        public ListData(String title, int value) {
            this.title = title;
            this.value = value;
        }
        @Override
        public String toString() {
            return title;
        }
    }

こういうのでよいみたい。

    <string-array name="main_list_label">
        <item>Read</item>
        <item>Write</item>
        <item>Format</item>
    </string-array>
    <integer-array name="main_list_label_num">
        <item>1</item>
        <item>2</item>
        <item>3</item>
    </integer-array>

こんなarrayたちを作って、

        String[] titles = getResources().getStringArray(R.array.main_list_label);
        int[] title_nums = getResources().getIntArray(R.array.main_list_label_num);
        ListData[] list_data = new ListData[labels.length];
        for (int i=0; i<labels.length; i++) {
            list_data[i] = new ListData(labels[i], title_nums[i]);
        }
        ListView lv = (ListView)findViewById(R.id.listView);
        ArrayAdapter<ListData> adapter = new ArrayAdapter<ListData>(this, android.R.layout.simple_expandable_list_item_1, list_data);
        lv.setAdapter(adapter);

こうやってやると、

    @Override
    public void onItemClick(AdapterView<?> parent, View view, int position, long id) {
        ListView listView = (ListView)parent;
        ListData item = (ListData)listView.getItemAtPosition(position);
        Log.d("TEST", item.title + " : " + item.value);
    }

こんな感じで取得できた。

できれば、順番的な値じゃなくて、直接起動するActivity名みたいなものを持たせたいと思っている。
まあ、そういうのができるか調べんといかんが、Javaはクラス名なんかもバイナリで持ってるし、AndroidManifest.xmlにもActivity名を書くくらいだから、できるんじゃないのか?
Activity名だったら見た目もわかりやすいし、もしソースと名前が一致してなかったらエラーになってくれるだろうし。


私としては満足だったんだけど、Stack Overflowに同じようなことをしたい人がいた。
http://stackoverflow.com/questions/2265661/how-to-use-arrayadaptermyclass

これがいいんじゃないか、という回答が多かったのは、ArrayAdapterをextendsする方法だった。
toString()を追加するタイプは2番目で、しかもコメントで「だめだだめだー」みたいに書かれてあった。

私にとってはtoString()を追加する方がわかりやすい(し、楽だし)のだが、何か理由があるんだろうか?
また、ArrayAdapterをカスタマイズする方が優れていたとしても、toString()の方がダメっていう理由がよくわかっていない。

そもそも、ListViewから画面遷移をするときにこういう方法はとらないのか?
いろいろと疑問が出てきてしまう。。。

へるぷみー。


最近、あれやったり、これやったりに見えてしまうが、実はそうでもない。
Vuforiaにせよ、FeliCa Lite-Sにせよ、動かす環境でアプリを作ることができないと、魅力は半減だ。
一応うちには、Android端末(Nexus7)とiOS端末(iPad mini old)がある。
Vuforiaだったら、どっちもありなのだが、NFCとなるとAndroidになる。

だから、Androidアプリにもう少し力を入れよう、と思い至ったのだ。

2014/08/29

[android]Gradle? IntelliJ?

今までAndroidアプリのビルドにはEclipseベースのADTを使っていたが、最近はAndroidStudioを始めたようだ。
だいたいこういう場合、後から出てきた方が残るよなあ、というわけで、どうせADTでの経験も少ないということでAndroid Studioを使うようにしようと思った(思っただけ)。

それはよいとして、ADTがEclipseベースだったように、AndroidStudioも何かがベースなんじゃなかろうか?
そう思ってキーワードを見ていくと、Gradle、とか、IntelliJ、とかが出てくる。
うーん、どれも知らない・・・。

 

http://www.gradle.org/
Gradle。
「新しいAndroidビルドシステムはGradleだぜ」という記事もあった。
http://www.gradleware.com/android/gradle-the-new-android-build-system/

ということは、ビルドするためのツールということだろう。
確か、Eclipseのときはantだったと思う。
そういえば、maven(まーべん? めーべん?)というのも、その一種だったかと。
何ができるかはわかってないが、とにかく、そういうツールなのだろう。

 

http://www.jetbrains.com/idea/
IntelliJ IDEA、が正しい名前らしい。
これは、Java IDEとあるから、Javaの統合開発環境なんだろう。
Eclipseも、最初は「Java用か-」と思ってたけど、あれこれ追加できるので、私はGDBのGUIとして使うことが多くなっている。
そんな八方美人さよりも、もっとJava Javaして専用でやった方がよい、ということなのかな。


はい、今日はこんなところで。

改行コードのデフォルトを変更したかったのでshemaを作ってみたら、そっちがプロジェクト作成時のデフォルトになったので、なんだかよくわかってないことを改めて認識した次第でした。

2014/08/25

[felica]FeliCa Link調査 (2) - Plugとけっこう違う

FeliCa Linkが発表されたとき、私が思った印象は「FeliCa Plug + NFC-DEF + R/W」だった。
なので、今回の調査も「動かして、Android Beamできましたー」くらいで終わろうと思っていたし、R/WがRC-S730で使えないことを知ってショックを受けていたのだ。

しかし、スターターマニュアルを読んでいる段階だが、そんなのんきなことを行っている場合じゃない気配が漂っている。


まず、メモリを持っていること。もちろん、不揮発だ。
Plugのときに毎回行っていた初期化シーケンスが不要になる。
もちろん、通常のタグのようなアクセスもできる。

モードも、多い。
R/Wモードも含めて5つ。うちにあるS730でも4モードある。
Lite-S、Lite-S HT、Plugの3つは似てるんだけど、まあちょっと違う。
これにNFC-DEPが加わり、4モード。

Lite-Sのメモリとモードがあるので、一筋縄ではいかなさそうだ。
仕事で「この機能を使います」であればよかったんだけど、私みたいに「とりあえず使ってみました」の人にとっては悩ましい状況だ。

 

それに、NFCも数年前に比べるとずいぶんと有名になってきた。
ネットで「NFC」検索しても、スポーツより先に出てくるくらいだ(日本だからか?)。
なんか、私ががんばって記事にしなくても・・・という気分になってしまう。

いかんいかん、歳を取ってきて気弱になってきたのか。
10月からフリーランスでやってみようと思い立ってはみたものの、今までは何とかなってきたものが、そろそろそれではやっていけないのかもしれない、という心配に置き換わりつつある。
その気弱さかもしれない。

まあともかく、日々学ぶことだけは忘れないようにしないとですな。
今回の学びは、「FeliCa Link、あなどるべからず」でありました。

2014/08/24

もごもご

iPhoneの新作が出るとき、いつもこの噂が出てくる。
「次はNFC搭載!」
http://iphone-mania.jp/news-40306/
Apple好きなわけでもなく、そもそも携帯電話自体どうでもよいのだが、NFCの搭載機種が増えるのはうれしい。
しかし、今まで実現はしていないがね。
噂はまだよいとして、適当な情報はよろしくないと思っている。
http://news.livedoor.com/article/detail/9154643/
私は情報源がないので、話の内容が正しい・正しくないは判断できない。
でも、「PN65でおサイフケータイできる」といわれると、いやいや、ちょっと待ちましょうよ、と思う。
以下、私の記憶を中心に書くため、今は古い可能性が高い。
しかも、その記憶は2010年くらいのものだから、さらに・・・。
なので、「最初はそうだったんだよ」というくらいのとらえ方にしてほしい。
あと、「あんた古いよ・・・」の情報は教えていただきたいです。



あんまり厳密な話をしてげんなりされるのも嫌なのだけど、「おサイフケータイ」は、基本的にはドコモのFeliCaを使った決済の登録商標だ。
ただ、ドコモだけでそういうシステムを運用しても意味ないよねー、ってことで、ドコモが「おサイフケータイって名前をはやらせようよ! 自由に使ってよいから!」というわけで、ソフトバンクやauも「おサイフケータイ」という名前を使っている。
どこからどこまでが登録商標かわからないけど、今のところ「FeliCaを使う」というところは含んでいたと思う。
なので、MIFAREで同じことができたとしても、厳密には「おサイフケータイ」ではない。
そして今のところ、FeliCa決済はハードウェアのセキュアエレメントのみだ。
どういうことかというと、SIMベースのセキュアエレメントではない、ということだ。
私の情報が古いかも知れんが、2013年や2014年はその過渡期にあるはず。
セキュアエレメントというのは、セキュアなエレメントで、NFC関係でいうと決済などの重要な情報を隠し持っていて、他からアクセスできないハードウェア情報みたいなものだ。
モバイルFeliCaは、これを専用ハードウェアで持っていて、モバイルFeliCaチップ経由でないとアクセスできなくなっている。
専用ハードウェアなので、それを使いたいなら以下の条件を満たさないといけない。
  • モバイルFeliCaチップが搭載されている
  • モバイルFeliCaチップとセキュアエレメントがハードウェアレベルで搭載されている
だから、海外端末ではFeliCaでのセキュアエレメント決済、すなわち「おサイフケータイ」が使えないのだ。

他の国はどうかというと、SIMにセキュアエレメント情報を置いているそうだ。
これは、実際にやったことがないため情報から読み取っただけになるが、電話番号のような個人の情報を濃く持っているSIMにセキュアエレメント情報を持たせ、NFCチップが直接SIMと通信するらしい。
なぜ「NFCチップが直接」かというと、メインCPUがNFCチップとSIMの間を取り持つと、その間に情報が読み取られたり改ざんされたりする可能性があるからだ。
自分で銀行のATMでお金を下ろすのと、他の人にATMでお金を下ろしてきてもらうことの違い、と思えばよいか。
基本的に信用できるけど、何かあったら真っ先に疑われる。
疑惑を持たれた企業・・・その先にあるのは、死だ。

だから、そんな業界は流行らんだろうと思っていたのだが、そうでもない。
HCEだ。
これは、さっきの「直接SIMと通信」をやらず、メインCPUが間に入る。
つまり、その間に改ざんしようと思えば、ソフトでの改ざんができることになる。
うひゃっほう。
でも、ね。
ネットでの買い物もそうやん。
httpsで、SSLでやってるから大丈夫よ、と。
信頼されたところで認証を得てますよ、ということで保証してもらうしくみができあがっている。
そう見てしまえば、別にSIMがやらなくても大丈夫そうな気がする。

今のおサイフケータイは、この辺の真っ盛りじゃないかと思っている。
つまり、
  • SIMにセキュアエレメントを載せるようにして、既存機種でも使えるようにしたい
  • HCEに対応して、SIMがなくても使えるようにしたい
最近のFeliCa展示会か何かで"HCE-F"という構想が出てきたというニュースがあったので、そう思った次第だ。
数年前にそういう結論が出せると私も格好がよかったのだが、まあ、そういう器じゃないな。

話を戻そう。
iPhone6とNFC。
とりあえず、iOS8にはNFCのAPIは追加されていない。
だから、ユーザレベルでのアクセスはできないだろう。
私の中では、ここで終了。
どうやら、SIPで一部キャリア向けに機能提供していたことがあるらしい。
iOS8 preの情報を探しているときに読んだ気がする。
だから、キャリア向けには提供される可能性はあるのかもしれない。
開発する人からすると、
  • 私が開発することに関係ないなら、一切隠してくれ
  • 開発に関係するなら、すべて提供してくれ
だ。
iOSの関係するプロジェクトに関わって2期目だけど、7~9月が一番気が重たい。。。

ともあれ。
iPhone6が出たとしても、それにPN65が搭載されていたとしても、影響がない。
現状だと、PN65が搭載されてるモデルと搭載されてないモデルが出るんじゃないのか?
まあ、買うわけじゃないのでどうでもよいのだが、期待をあおるのであればもう少し現実味があるようにやってほしいものだ。

[felica]FeliCa Lite-S

なんでか知らんが、FeliCa Lite-Sのスライドを作った。

 

せっかく作ってるんだから、こういうのを収入の一部にする努力をした方がよいのではないか。。。

2014/08/23

[felica]FeliCa Link調査 (1) - この子、メモリ持ってる

もうこんな時間なので、今日はFeliCa Linkはやらない(お酒の時間)。
酒のつまみに、仕様書でも読むことにしよう。

FeliCa Linkにはスターターマニュアルがあり、イメージをつかみやすくなっている。
ユーザに優しくなってきているので、この方向でどんどんやっていっていただきたい。
(RC-S390の、NFC Forum準拠のアクセスだけでも公開してくれないかな-)

スターターマニュアルに使用例があるので、それを見てイメージを膨らませるとよいだろう。


最初の例が、Bluetoothハンドオーバー。
FeliCa LinkにBluetooth機能があるわけではないので、ハンドオーバーする情報だけ持たせて、あとはHostとBluetoothユニットなどで実現することになる。

ふーん、まあ、そういう使い方もあるよねー。
なんかちょっともったいない気もするが、使い方は人の自由だ。
まあ、私が同じしくみを製品でやらんといかんかったら、アナログの人を探して、RC-S701でやると思うがね。

が、スルーしそうになった情報があった。
「FeliCa Lite-Sブロックへのアクセスだけだったら、VDDが不要」と。
えっっ、この子、メモリ持ってるの??

FeliCa Plugの弱点というか、割り切った点は、メモリを一切持っていないことだった。
しかし、FeliCa LinkはVDD無しで、つまり電源無しでアクセスできるという。
つまり、PanasonicのMN63Yみたいなことになるのか??

試すのは簡単だ。
買ってきたFeliCa Linkを、R/Wの上に置いて、NFC-Fでアクセスするだけ。

image

おおおおお、できおった!
SystemCode 88B4で、IDmも取れた。
Read w/o Encryptionもいけるし、Write w/o Encryptionもいける。
いけるんだ。


FeliCa Plugの置き換えになるという話だったので、FeliCa Plug+αくらいと思っていた。
しかし、実際はFeliCa Lite-S + FeliCa Plug +α、というところだ。
まあ、Lite-SがLiteの置き換えになるのであれば、そうなっていくのか。

[felica]FeliCa Link来たる

スイッチサイエンスさんに注文していたFeliCa Linkが届いた。

image

右から、FeliCa Plug(S802)、FeliCa Link(S730)、LED。
LEDは、単なるサイズの比較用だ。
基板の大きさはアンテナになっているためで、本体のICは非常に小さい。
そして、これは使っている基板の違いだけかもしれないが、薄い。
FeliCa Plug基板の半分くらいの厚さだ。
なんか、折ってしまいそうで怖いわ。

さて、FeliCa LinkはI2C接続となる。
ということは、プルアップせんといかんということだな。
抵抗値とかを心配せんといかんのは面倒だが、特殊なI/FじゃないのでソフトとしてはI2Cライブラリが揃っているなら使い勝手がよさそうだ。

いつもこういう部品が来たときは、最後に使っているマイコンで動かすことにしている。
よって今回は、Cortex-M0というか、nRF51822になるな。
なんか、まだBLEとしてほとんど機能を使ってない気がするが、気のせいだろう。

 

しかし、さんざん悩んで送料無料になる付近まで買ったつもりだったが、まさか変換コネクタを2つ買っていたとは・・・。
注意散漫ですわ。

[vuforia]Unityも使ってみる

そういえば、VuforiaのインストールガイドにはNDKもインストールするよう書かれていた。
一応インストールはしたものの、サンプルにはjniがないし、ndk-buildしてもビルドされるわけでも無い。

staticライブラリをコピーするくらいだから、「こちらにビルドしたものをご用意しました」という状態なのだろう。


で、だ。
ネットで見ていると、NDKでビルドするという話がしばしば出てくる。
iOSの記事だからかもしれないが、Unityというのでデータを生成するとCのヘッダができるようなことも書かれていた。
うーん、NDKはやっぱりいるのか?
わからんので、Unityでのサンプルも試しておこう。
なお、Unityってのも知らないので、ごにょごにょ長くなるだろうが許してくれ。

 

https://developer.vuforia.com/resources/dev-guide/step-1-installing-extension
まず、Vuforiaのunitypackageをダウンロードして、C:\Program Files (x86)\Unity\Editor\Standard Packagesにコピー。

https://developer.vuforia.com/resources/dev-guide/step-2-compiling-simple-project
Unityを起動して、プロジェクトの作成でvuforiaなんとかにチェックを入れて、create。
しばらく待つと、3Dの平面にカメラっぽいものが見える画面が出てきた。

左下にあるフォルダツリーで、Assets > Qualcomm Augmented Reality > Prefabsを開く。
(はっ、「プレハブ」って、Prefabなのか? 何かの略かと思ってたのだが・・・)
左上のHierarchyからMain Cameraを削除し、代わりにPrefabsの中にあるARCameraをドラッグして持っていく。

ドラッグしたARCameraをクリックすると、右側のInspectorにずらずら出てきた。
説明では、StreamingAssets/QCARが有効になるとか何とか(今気付いたが、QCARはQualComm ARの略か)。
QCARフォルダの中にはテキストファイルが1つだけあり、ダブルクリックするとMono Developというツールが起動してしまった。CSharpって書いてあったので、今回は関係なさそうだ。

今度は、TargetImageをドラッグして左上にドラッグアンドドロップ。
Inspectorに、またずらずら出てくる。
ここの「Image TargetBehavior」は必須らしい。
"Press here"と書いてあるのでクリックすると、ブラウザでVuforiaのサイトにあるTarget Managerというサイトがひらいた。
このサイトでデータを作るようだ。

適当にTargetを作って、Unity Editor用をダウンロードすると、Unityアイコンがついたファイルが取って来れた。
これを組み込めんばいいらしい。
メニューの Assets > Import Package > Custom Packageでダイアログが開くので、さっきダウンロードしたファイルを選択。
そうすると、これらをインポートします、みたいな画面が出てくるので、そのままImport。

Importすると、InspectorのImage TargetBehaviorにいくつか追加されている。
Targetを1つだけ作っていたためか、Data Setでは1つだけ選択できた。
それを選ぶと、真ん中のSceneウィンドウに絵が出てきた。
なんじゃこりゃー。

image

ImageTargetというのは、どうやら目印になる画像のようだ。
サンプルでいうところの、砂利の画像みたいなやつだ。
てっきり、ここで作った画像が3Dで見えるやつになるかと思っていたのだが、やはり3Dは甘くないな。
(pngファイルから自動的に3Dにするなんてすごい!と思いこんでいたのは秘密だ。)

 

ここから、ようやく3Dオブジェクトの話になる。
説明ではあっさりと「シンプルなCubeオブジェクトを作る(GameObject > Create Other > Cube)と書いてあるが・・・はて。
ああ、メニューから作るのか。
Hierarchyの一番下にCubeができるが、これをドラッグしてImageTargetの配下にする。
Directional Lightも追加できるよ、とあるので追加してみたが、ライトが当たったように見えるのかよくわからん。

TrackableEventHandlerがどうのこうのあるが、デフォルトがあるようなので、そのまま使っておこう。

これで、とりあえず準備はできたようだ。
メニューから、File > Build Settingsを選ぶと、ダイアログが出てくる。
設定は特にせずとも、Androidを選んでビルドすると、よさそうだ。
"Scenes In Build"には、Add Currentすれば現在のが追加されるようだ。
追加して、保存してからBuild and Run、なのかな。

そうすると、Nexus7に転送されて立ち上がるのだが・・・画像を見せても何も出ない。
のっぺりした画像だったからダメなのかと思い、ImageTargetを白黒のにしてみたけど、だめ。

まず1つ見つかったのは、ImageTargetの設定だ。
説明ページには言及が無いが、Inspectorの画像を見るとData Set Load Behaviourの設定で「Load Data Set xxx」と、その下の「Active」にチェックが入っているのだ。
これは、デフォルトではチェックされていない。
書いておいてくれよ・・・。

でも、これをやっても変わらない。
うーむ。。。

image

ん??

image

image

ああ!
ゴミみたいなのが、追従して動いてる!!
小さいだけか・・・。

Cubeの"Transform"にあるScaleを、全部0.2にした。
どうやら、ImageTargetを1.0としたときの比率になるようだ。
これでビルドすると、出てきた!
黒い四角が出てきた!!
よかったんだけど、絵としてわかりづらいので、四角の表面に何か貼り付けてみたい。

どうやら「テクスチャ」というものらしい。
左下のAsserts > Qualcomm Augmented Reality > TexturesのUserDefinedTarget.pngを、左上のCubeの中にD&D。
そうすると、CubeのInspectorに追加された。
もっといい方法があるのかもしれんが、よくわからん・・・。
Base(RGB)もよくわからんが、Selectをクリックすると画像があったので、適当に選ぶと貼り付けられた。
Shaderが「Unlit/Texture」だと貼り付けられるみたいだ。

image

わーい。

Cubeを作ったときは「Default-Diffuse」というのがあるんだけど、これが編集も何もできないのでこういう手順を踏んだが、Unityの使い方から学ばねばならんのかな。
3Dにそこまで思い入れがあるわけじゃないけど、「ああUnityね、使ったことなくもないよ」くらいは言えるようになりたいじゃ無いか。

[lib]vuforiaサンプルのビルドが通らんのでバッチに変更

まだVuforiaのAndroidサンプルでビルドできていない。

前回のClasspathは、エラーが出ていたけど、何度も出たり入ったりしているうちに、なぜか表示された。
なんじゃそりゃ・・・。
なんかわからんが、設定できたからよしとしよう。
この設定ができなかった場合、プロジェクトファイルがQCAR_SDK_ROOTを見るようになっているところが動かなくなるだろう。

そうすると、自動ビルドまでは通るようになった。
よしよし、と実機に焼こうとしたら、エラーが出た。
AntBuilderLaunchConfigurationTypeが無いとか何とか。
うーむ。

antがないってことらしいが、調べていくとEclipseにantは統合されているらしい。
pluginの一覧を見ても、apache antが出てくるので、入っているのだろう。
エラーは「"org.eclipse.ant.AntBuilderLaunchConfigurationType"が無い」なので、antがないってより、期待したプラグインが無いということなのか・・・。

プロジェクトのプロパティから「Builders」を見ると、CopyVuforiaFilesにアイコンが表示されていない。
Editしようとしても同じエラーが出るので、これがよろしくないのだろう。
ファイルの中身を見ると、vuforiaのstaticライブラリをコピーするだけのようなので、これを削除して手動でコピーすれば良いと言えばよいはず。

が、忘れそうな気もするので、とりあえずWindowsのバッチファイルを作って、Buildersに登録した。

mkdir libs\armeabi-v7a
copy ..\..\build\lib\armeabi-v7a\* libs\armeabi-v7a

antで書くとプラットフォーム依存が無くなってよいのだろうけど、めんどくさかった。
まあ、シンプルな方がわかりやすいしね。

2014/08/22

[eclipse]ADT23ではClasspath Variablesがエラーになった

小ネタで。

VuforiaのAndroidサンプルをビルドしてみようとした。
海に入る前のように、徐々に体を動かしていくのだ。

Vuforiaの設定ガイドに従ってADTの設定をしようとしていたのだが、推奨っぽい設定をやろうとしてつまずいた。
https://developer.vuforia.com/resources/dev-guide/step-2-installing-vuforia-sdk
ここの真ん中くらいに、QCAR環境変数を追加することが書かれている。
Java->Build Path->Classpath Variablesからやれ、と書いてあるのだが、ここを開こうとするとNull Pointer Exceptionが発生するのだ。
環境は、Java7 + ADT23 + Windows7 64bit。
ADTを落として解凍しただけのeclipseでも同様。

もう寝ようと思ったが、試しにWindows8 32bit環境も同じようにしていたので、表示させてみると、Null Pointer Exceptionの画面は出たものの、中の設定は見ることができた。
うーん、なんだろう。。。

そしてそこに書いてあったのは、このページはdeprecatedってことになってる。
じゃあ、そもそもこのページ自体が不要になったということ?
気になるが、もう寝ることにした。

2014/08/21

[lib]Vuforiaのサンプルを動かした

ARってのがある。
カメラで撮影した画像の上にキャラクターが出てくる、くらいのイメージしか無かったのだが、とにかく楽しそうだったのでやってみたいと思いつつ、早数年。
今は私もNexus7を持っているので、カメラがある。
じゃあ、そろそろやってみようか。

 

調べてすぐ出てきたのが、QualcommのVuforiaだった。
そう、あのQualcommだ。
なんであそこが?という気がしなくも無いが、ともかく自由に使えるものを提供していただけるのはありがたい。

今回の分類はAndroidにしたけど、べつにプラットフォームはAndroidだけではなく、iOSにも対応している。
そして、Unityというやつとも連携している。
3Dのゲームエンジンらしい。
そういえば、ゲームを始めるときに出てきてたなあ。

 

それはともかく、Vuforia(びゅふぉりあ?)のサンプルを動かしてみた。
https://developer.vuforia.com/resources/sample-apps/features
ここにapkファイルがあるので、インストールしてサンプルを動かしてみた。

「Image Targets」は、砂利や木のチップだけがA4くらいのPDF1ページずつに入っているファイルが提供されていて、それをカメラで見ると、その上にヤカンが3Dで表示される。
ただそれだけといえばそれだけなのだが、普通に表示されるのが非常に面白い。

私は液晶モニタに表示させた画面をNexus7で見たんだけど、スマホってこんなに性能がいいんだね。
久しぶりに会った親戚の子供が大学生くらいになっていた気分だ。

また、Vuforiaがすごいと思ったのは、その追従性だ。
下の画像は木のチップで、その中央に紫のヤカンが表示されるようになっている。
スクロールしたらどうなるんだろう?と思って動かしていくと、追従していくのだな。
そして、こんな画像がほとんど見えなくなっていても、ここら辺に中心がある、と認識しているのか、そこら辺に画像を出している。

image

 

こういうのを見ると、昔は自分にそういう技術が無くて悔しく、「もう使わない」みたいなことを思ったんだけど、私も歳を取って丸くなったのか、素直に「すごいものは使わせてもらおう」と思えるようになってきた。
なんでもできる(はず)という可能性の限界に気付いただけかもしれないが、肩の力が抜けてきた、と思うことにしよう。


いつもはNFCくらいしかやらないから、「NFCでなにしよー」みたいな煮詰まった考え方をしてしまうし、NFCでわからないことがあって検索しても、なんか自分の「わからん」記事しか出てこなくて、世の中でNFCをやってるのは自分だけなんじゃ無かろうか、みたいな怖い考えになってしまうことが良くある("NFC"で検索しても、私の記事は出てこないが。。)。

その点、ARとかVuforiaだといろんな人が扱ってるし、サンプルも多い。
つまり、仲間が多い。
そうなると、雪だるま式に仲間も増えやすくなり、使い勝手がよくなったり、「これも無償なの?」というライブラリが出てきたりする。
うらやましい限りだ。

と書いてはみたが、もしNFCがARと同じくらい人気だったら私が手を出したかというと・・・やらなかっただろう。
まあ、そういう性格なのだから、仕方が無い。
世の中にはいろいろな人がいて成り立つんだな、と思う瞬間であった。

2014/08/17

[nfc]HCEが求めるのは、NDEFではなく

夏休みの宿題パート2と言うことで、ISO/IEC 7816-4を眺めている。
宿題の提出には間に合わないなー、ということで、感想文提出だけにしておこう。

 

以前、AndroidのHCEで、NDEFを返すようなアプリを作ったことがある。
中身はあまり理解していないが、NDEFを読み取る場合はだいたいこういうアクセスのされ方をする、という手順があるので、それを想定してレスポンスを返すだけの作りだ。
簡単と言えば、簡単。

しかし、HCEに皆が求めているのはNDEFではなく、セキュアなカード独自のやり方だろう。
そうなると、NFC Forumのドキュメントだけでは足りないので、ISO/IEC 7816-4を読んで対応していくことになるだろう。
コマンドに当たるINSが39個あるが全部対応するのか?とか、一般的なやり方はあるのか?みたいなことは、ドキュメントよりもノウハウになるんじゃなかろうか。

いろいろ考えていくと、面倒ですな。
でも、自分がR/W側も含めて全部やるし、HCEのみでカードの提供はしないとかであれば、ごくごく限定のアクセスだけにしてしまえるので簡単かもしれない(セキュリティ的なところは置いておくとして)。
まあ、HCEの期待の仲には、既存のカード決済をスマホなどに移動させるというのもあるんだろうが、そういうのはそういう人に任せて。。。

そんなわけで、HCEやる、というのは、システム含めてやらないと意味が無いなと思いました。

[android]Emulatorが立ち上がらんときは、Use Host GPUをチェックするとよいかもしれん

久しぶりに、Androidのエミュレータを使うことになった。
というのも、AndroidアプリをGoogle Playにアップするためにはスクリーンショットが必要なんだけど、「電話」っていうサイズのスクリーンショットがあるからだ。
うちにはNexus7しかないため、これはきっとエミュレータで実行して撮れ、ってことなのだろうと解釈している。

 

まず最初につまずいたのは、選択するAPIバージョン。
バージョンが上の方なら何でもいいじゃろう、と思い、4.4Wを選択。
今ならわかるのだけど、Wは"Wear"のW。
立ち上がったのはいいけど、ホーム画面は出てこないしアイコンは出てこないし、なんじゃこりゃ、と思って調べてわかった次第だ。

 

その次につまずいたのが、表題。
4.4.2で作ったのだけど、立ち上げても"android"のアニメーションが始まらない。
うちのマシンは遅いから、と放置していたが、さすがに5分も動かんのはおかしい。
logcatを見ると、SurfaceFlingerが「フレームバッファがない」みたいなことを言っている。
これはうちのPCが貧弱なせいか?

そう思って調べると、Stackoverflowにあった。
http://stackoverflow.com/questions/21845358/android-emulator-cant-be-started
"Use Host GPU"にチェックを入れたら?とあったので、設定を変更しなおすと、アニメーションが出た。
そういうことなんですか。。。

 

さて、最後かどうかわからないが、まだつまずいている。
またしてもNFCを使うアプリなんだけど、onCreate()でNFCを使用できるかどうかチェックしているので、エミュレータだとまったく起動できない・・・。
チェックを外せばいいんだけど、それってスクリーンショットの偽造になるのでは?

そしてもう1つ・・・。
4.4.2でGPUを使う設定にしているとDDMSでスクリーンショットが撮れないらしい。
https://code.google.com/p/android/issues/detail?id=62284

まあ、単なるスクリーンショットだから画面キャプチャでいいんだけどね。


そんなこんなして、Google Playにアプリ置きました。
https://play.google.com/store/apps/details?id=com.blogpost.hiro99ma.flfmt

Formatと書いているが、やってるのはQuick Formatみたいなものだ。
とりあえず、MIFARE Ultralight系だったら40ブロックまでは0x00で埋めようとしているし、FeliCa Lite系だったら13ブロックまでは0x00で埋めようとしている。

それはよいのだが、アプリをインストールするときに「特に権限不要」と出てきた。
いやいや、NFCの権限はいるんですけど・・・。
アプリ情報を見ると、ちゃんと「許可」欄には出てきている。
うーん、そんなものなのか?

[nfc]ISO/IEC 7816-4とJIS X6320-4

AndroidのHCE(Host-based Card Emulation)は、アプリケーションからするとISO/IEC 7816-4という分類になっている。
勉強不足なところを言いたくはないが、ISO/IEC 14443とか7816とかのことは、かなり不勉強なことを自覚している。
正直なところ、よくわかってない、といっても過言ではなかろう。

反省して、ISO/IEC 7816の和訳でもしてみようかと思ったが・・・そもそも、無料で手に入りそうな気配がない。
ネットで検索して、それっぽい感じがするサイトのHTMLを保存して実家で翻訳していた。
・・・・なぜ保存してかと言うと、実家ではブロードバンドが通らない地域だからだ。WiMAXも山を越えると入らないので、そろそろ手数料がかかっても解約を考えているくらいだし、光はおろかADSLも届かず。
携帯電話は一応入るけど、私がテザリングできる契約にないし。
ぐちぐちぐちぐち・・・・

ともかく、ISO/IEC 7816-4っぽいサイトをダウンロードして実家で訳していたのだが、最初の方で挫折した。
英和辞典がないのだ。
もうちょっと訳せると思ったんだけどね-。

その途中でふっと思い出したのだが、JIS規格は国際標準規格を取り込んでいるものも多い。
まあ、日本工業規格なんだから、当たり前といえば当たり前なんだろうが。
7816も取り込まれているんじゃなかろうか、というよりも、取り込まれているはず!

検索できる環境に戻ってきて調べると、JIS X6320-4がそれっぽい。
それがわかったので少し読んでみたが・・・難解だ。
いや、難解なのはまだ良いとしても、私が「っぽいサイト」といっていたところの内容と違う・・・。
内容が違うというか、構成が異なるため、たぶんこれが原本に近いだろうとは思うものの確信を得ることができない。
JISを疑いたくはないのだが、この職業はすべてを疑うのが定め。

 

2014/08/10

[ios]iBeaconとMFi

かなり、いまさら、の話になってしまうが、AppleのiBeaconがMFiライセンスみたいな感じになるらしい。

私は全然MacとかiOSに詳しくないので、衝撃的なのかどうかすらよくわからない。
とりあえず、iBeacon端末と名乗るならばAppleの認証が必要になった、ということだと認識している。
NFC Forumに適合しないとNマークが付けられないとか、そんな感じ。

しかし、iBeaconのデータは、BLEのAdvertisingデータなので、それだけであれば誰でも流せるし、符号化されているわけでもないから読むことだってできる。
そもそも、iOS以外でも使えるものだ。
制限するのにも限度があるが、だからこそライセンス的にしようとしたのだろうか。


まあ、そういう政治的な話はあまり興味が無い。
気にしているのは、何か開発するだけの人にとって制限されることがあるのか?ということ。
特にお金的な面で・・・。
ほら、ただでさえiOS開発には毎年の更新料が必要になるじゃないか。
シミュレータ使えばいいんだろうけど、手元にiPad miniがあるのに開発に使えないというのは腹立たしい。
アプリをリリースするときだけ金がかかるのならいいんだけど、そうじゃないしねぇ。
せめて、BLE開発は追加なしでやりたいところだ。

[ios]iBeaconを受けるアプリを作ろうとした

以前、BVMCN5102(nRF51822搭載)で、NFC R/WからUUIDを指定してAdvertisingするしくみを作った。
送信するのは確認できたので、やはり受けるアプリも作りたい。
そんなわけで、久々にXcodeを使うことにした。

ネットを見ながら、CLLocationManagerDelegateだけを持つViewControllerを作った。
が、startMonitoringForRegionしてdidStartMonitoringForRegionがコールバックされるのは確認できたのだけど、startRangingBeaconsInRegionしてもdidRangeBeaconsが呼ばれないし、そもそもdidDetermineStateすら呼ばれない・・・。
あれこれ見たけど、別に悪そうなところはない。
うーむ。

一番疑わしいのが、Xcode6 beta版か、SDK8.0。
Xcode 5.1.1にして、SDK7.1にすると・・・アプリ起動時に「位置情報を使うか?」みたいなダイアログが表示されて、許可すると呼ばれるようになった。
なんだよー。
SDK8.0が怪しいのか、仕様変更なのか・・・。


送信しているProximity UUIDと、APIで指定するProximity UUIDはエンディアンがどうなるんだろう、と思っていたのだが、同じ順番で良かった。
つまり、送信側が「00112233445566778899AABBCCDDEEFF」を使っているのであれば、iOS側は「00112233-4455-6677-8899-AABBCCDDEEFF」でよいということだ。
同じにするのは当たり前やん、と思われそうだけど、Bluetoothって全体的にリトルエンディアンなので、文字列で指定するiOSの方とは逆になるんじゃなかろうかと考えていたのだ。


2014/08/09

[felica]FeliCa Lite-Sの相互認証が通った!!

まだ・・・FeliCa Lite-SのMAC_A(W)が計算できていないのだ・・・。

基本的な注意点は、以下。

  • 内部認証時のMAC計算や、読み込み時のMAC_A(R)計算とは異なる。
    • SK2→SK1→SK2の順で3DESする
    • 初期IVはRC1(エンディアン反転)で、初期値はWCNTとブロック番号

まず、前回疑問だった、発行していないのにできるのか?については、「できる」だと考えている。
その根拠は、WCNTレジスタの説明に、1次発行作業中でもMACつき書込が正常で終わると書かれているからだ。「WCNTの動作」という表があり、WCNT==0xFFFFFFになってなければ正常に書き込めるらしい。
今は0xFFFE58とかだから、まだ大丈夫そうだ。

 

では、考えられるのはMAC不一致か、WCNT不一致か。
WCNTは、読み込んだ値をそのまま使うだけなので、考えにくい。
となると、MACが不一致、ということになる。

ここで、スターターマニュアルを読んで気付いたことがある。
カード側に必要条件があるようなのだ。

  • CKブロックにカード鍵が書いてあること
  • STATEブロックがMACつき書込に設定されていること

STATEに? MAC付き書込設定?
MCレジスタを確認すると、MC_STATE_W_MAC_Aという設定があった。
全然気にしていなかったのだが、なんか重要そうだ。


MC_STATE_W_MAC_Aに0x01を書き込むと、STATEブロック書込にMAC必要となるらしい。
つまり、今まで、外部認証の処理だと考えていたシーケンスは、実は「STATEブロックにMAC付き書込を行う」という動作をしているだけだったのだ!
はらはら(目から鱗が落ちる音)。

もし私のMAC_A(W)計算が正しかったのならば、Write without Encryptionレスポンスのステータスフラグ2が0xB2である要因として、「MAC付き書込不要なブロックに対してMAC付き書込を行った」もあるということになる。

では、実証実験を。
・・・・・・・・・・

image

きたーーーーーー!!
Write without EncryptionまでOKで通った!!


では、外部認証へのまとめを。

  1. MC_STATE_W_MAC_Aには0x01を書き込んでおくこと
  2. STATEブロックへ書き込むときのEXT_AUTHは0x01
  3. MAC_A(W)を計算するときのEXT_AUTHは0x01

3番については?と思われるかもしれないが、FeliCa Lite-Sのユーザーズマニュアルには外部認証でのMAC(W)生成の説明に、

  • WCNT値とブロック番号とブロックデータからMAC(W)を生成
  • STATE[0]に01hを、MAC_AブロックにWとWCNT値を書き込む
  • の順で書かれているので、「じゃあMAC(W)を計算するときのSTATE[0]は、現在値なのか書き込む予定の値なのか?」で迷いが生じたのだ。
    しかし、ここまで確認した過程でわかったように、外部認証というのは「STATEレジスタへのMAC付き書込」を指しているので、計算するときは当然書き込む予定の値で行うことになる。

    あー、夏休みの宿題が終わった!

    2014/08/04

    [nfc]NFPも同じ問題点があるのか

    HCEサンプルの動作確認をWindowsでやろうとして、うまくいったんだかいかなかったんだかという状況だ。
    とりあえず、RC-S370 + SDK for NFC Starter Kitであれば、NDEFタグとして読んでくれた。
    RC-S380 + SDK for NFC Starter Kitは、タグとしてのアクセスについてはサポートされていないと見て良かろう。

    じゃあ、RC-S380 + NFP、つまりWindows8でだったら認識してくれるか?というと、だめだった。
    例のタグ近づいた音はするものの、それっきりだ。
    Androidで動いているLLCPを見つけてしまうため、お互いがそれ以上の関係になれないのだと思う。

    それならAndroid同士だって同じではないか、ということになるが、ある意味では正しい。
    しかし、Androidでは回避策を用意している。
    内容は、こちらのブログが詳しい。
    http://brightechno.com/blog/archives/179

    つまり、Android 4.4からはReaderWriter Modeという状態を用意し、何をやってるかは知らないけれど、LLCPしようとしないようにしているのだろう。
    NFPにそういうインターフェースがあるかはわからないが、そういうモードがないとHCEをWindows8で受けるということができないんだと思う。LLCPはドライバでやるようなことが書かれているから、メーカー依存になるんだろうか・・・。

    2014/08/03

    [felica]PaSoRiの対応

    PaSoRiと、OSと、機能の対応表を見比べていたのだが、結局こういうことか?

    image

    もう、公開されている資料からこれ以上読み取るのは私では無理!!
    間違っていたら修正するので、よろしく。

    2014/08/02

    [nfc]RC-S380かそれ以外かをSDK for NFCで見分ける

    結局のところ、こういう実装になるのだろう。

    • RC-S380以降ならば、PC/SCなど(非SDK for NFC)を使う
    • RC-S370以前ならば、SDK for NFCを使う

    おそらくだが、ACSのようなR/Wであれば、PC/SCでアクセスできるんじゃなかろうか。
    そういう視点で行くならば、こうなるか。

  • PC/SCでやってみる
  • だめだったら、SDK for NFCでやってみる
  • つまり、SDK for NFCがレガシーデバイス用になるという見方だ。
    そちらの方が今後としては正しいのかもしれん。

    公式発表があるとありがたいのだが、業務用R/Wはサポート期間が長いことも考えると、今までの傾向からすると発表などはないだろうと思う。
    せめて、ラッパーとか用意してもらえれば・・・。

    でも、今だったらRC-S370環境のみで整備するか、RC-S380環境のみにして書き直すかのどちらかを選択するな。
    取りあえず、felicalib_nfc_open()のエラー値で判断せよ、ということになる。

    [nfc]RC-S380 + SDK for NFC Starter KitはおそらくFALP以外は使えない

    前ブログに書いたType4Aのサンプルだが、RC-S370で動かしている。
    ちょうどPCに挿さっていたのがS370だっただけなのだが、同じソフトをRC-S380で動かすとエラーになった。

    以前作っていたSDK for NFC Starter Kitのアプリを動かしてみたが、同じだ。
    エラーコードを確認するとドライバのエラーで、「APIの発行シーケンスが正しくありません」らしい。
    ???

    S370だと動くので、アプリの問題ではなくドライバに原因があるのだろう・・・
    と検索してみたら、自分のブログが引っかかった。
    正確には、ブログへのコメントだ。

    http://hiro99ma.blogspot.com/2012/12/win8ndef-writernfp.html

    「felica_nfc_library.dllは、新型RC-S380からはサポートされない」とのこと。
    このDLLは「NFCアクセスライブラリ」という。
    付属ドキュメントM575_NFCAccessLibraryFunctionOverview_1.21j.pdfのp.10には「NFCライブラリは、NFC Port-100およびFeliCaポート1.0では動作しません」とある。
    これが、コメントでいただいた内容のことだ。
    でもね。
    同じく付属のソースサンプルには「NFCPort100」というフォルダがあるのよね。
    使えないのであれば、サンプルソースも削ってほしいのだが、どうなんだろう。

     

    数年FeliCa関係のドキュメントを読んでいたので言わせてもらうと、ドキュメントが他社に比べてものすごくわかりづらい。
    わかりづらい、ではなく、ものすごくわかりづらい、だ。
    こんだけブログの記事にさせておいて申し訳ないが、私が部品を発注する立場だったらSonyのチップは選ばないだろう、というくらいの出来だ。
    英語で書いてあっても、NXPのドキュメントの方がわかりやすい。
    Sony嫌いという人もいるが、そういうところが透けて見えてるからなんじゃないかなー、とか思ってしまう。

    [nfc]HCEがキーワードらしい (2)

    NFCフォーラム自身もアプリ開発を支援、注目はHCE

    ほほぅ。
    まあ、NFCが一般的かって言われると、そうじゃないと思う。
    だいたい、技術が先行するとあんまりはやらない気がする。
    冷蔵庫ってどうやって冷やしてるの?と聞かれても私にはよくわからんのだが(わからんのかい)、冷蔵庫は便利だ。
    そんなもんだと思う。

    が、冷蔵庫が出てきた時代とも違うし、比較してもしょうが無かろう。
    それに、このサイトを見ているとわかるかもしれんが、私は応用よりも技術の基礎的なところを知る方が好きなようだ。
    なので、技術が先行しても特に気にしない。


    ならば、私も長いものに巻かれて、HCEをもう少し真面目にやってみようと思い、以前作ったサンプルを立ち上げた。
    が・・・動かない・・・・・・・。

    今回、なぜか急に私がAndroid SDK(eclipse)から、AndroidStudioに変更してみようと思った。
    HCE Sampleをビルドする前に、Wizardで新規作成したプロジェクトをビルドさせてNexus7に焼こうとしたけど、まずそこが失敗。
    理由は、[INSTALL_PARSE_FAILED_MANIFEST_MALFORMED]。
    これは別にAndroid Studioのせいではなく、package名に大文字が入っていたせいだった。
    http://stackoverflow.com/questions/12396351/how-to-fix-install-parse-failed-manifest-malformed-in-my-android-application

    これでStudioで焼けることがわかったので、HCE Sampleをインポートしてビルド。
    そしてここでもつまずく。
    どうも、Nexus7にAndroid Lを入れていたためのようだ。
    build.gradleを編集して対応できた。
    http://stackoverflow.com/questions/24437950/build-failed-after-updating-tools-for-android-l

     

    ようやくNexus7に焼くことができたけど、はて、前回はどうやって動作確認したのだか。
    Windows7 + NDEF Writerで、Type4のREADを試したけど、どうもうまくいかない。
    搬送波が出なかったり、エラーになったり。
    Windows8で試したけど、SNEPの方が反応してしまうためか、同じくだめ(Android Beamしなくても、裏ではLLCPが動き続けているログが出てる)。

    じゃあ自分で作るか・・・と思ったが、めんどくさい。
    幸い、SDK for NFC Starter Kitにコマンドライン版ではあるがType4Aを読むサンプルがあったので実行する。
    が・・・なんか「The tag is not a supported Type4 Tag」と出てくる。
    しょうが無いのでVisual Studioでデバッグすると、SmartPosterを読み込む部分がかなり決め決めで実装されていた。

    • SmartPoster内のNDEF Recordは、Shortで3つ。
    • 3つの順番は、TEXT, URI, Action

    URIとTEXTだけやっていたので、はじかれていたのだった。
    SmartPosterRecord::setPayloadData()を変更して、ようやく動いた。
    私のHCE Sampleは間違ってなかったんだ!


    とはいえ、HCEの目的からすると、端末がNDEFタグを吐き出すことではないだろう。
    なにかしら、セキュアなデータをやりとりするような、そんな緊迫した使い方がメインになるはず。
    そういうサンプルを作ってみたいけど、これはR/W側も同時に実装しないといけないのよね・・・。
    それには、メモリとしてのNFCタグではなく、Type4Aが持つデータ構造とかアクセス手段とかも知っておかないといかんような気がする。

    まあ、Android側もR/W側も自由に扱えると言うほどに熟練してないので、まずはお勉強からですかね。