RC-S710というFeliCa Liteがある。
とある経路から入手したまま、早２年。
と書くと密売品っぽくなってしまうが、ちゃんとFeliCa Liteのページにもあるようなものだ。
RC-S710には端子が出ていて、搬送波が検知できる。
正確には搬送波じゃないんだろうけど、私が出せるのは搬送波くらいしかない。
それが、RC-S710の上にある端子で見えるのだろう。
見るなら、まあ、オシロとかマルチメータとかしかなさそうだ。
私は、テスターを使った。
マルチメーターってほど高級じゃないしね。
こういうのは、びくんびくんと動くのを見る方が楽しいので、アナログテスターにした。
まあ、デジタルだとどう見えるのかわからんしね。
Nexus7の背面で、ひたすらRC-S710の端子にプローブを当てたテスターを撮影しただけの動画だ。
ときどき、RC-S710の位置を動かしたくらいで、山場も何もあったもんじゃない。
とにかく、FeliCa Plugでなくても、そういうことはできるんだな、ということだ。
ただ、私はアナログに弱いので、これをどう料理したらいいのかがわからない・・・。
しばらくネットを見てない間に、NFC Forumの仕様書が更新されていたようだ。
仕様書の状況が更新された、というべきか。
更新日が一番下に書いてあるのだが、7/16になっている。
PHDC(Personal Health Device Communication)の仕様書がダウンロードできるようになっている。
あとは、まだ私ではダウンロードできなさそうだが、Connection HandoverとSignatureのが更新されたらしい。
さも巡回して気付いたかのように書いているが、NFC Worldの記事に書いてあって気付いただけだ。
NFC Forum adds healthcare, handover and security standards
あー、読む暇がないなぁ。
すごくいらいらしているので、更新する(自分にいらいら)。
昨日、iPad miniでも使えるiOS7 beta2がリリースされたので、インストールした。
初めてなのでいろいろわからんかったが、
などなど。
うちのMac miniは、XcodeとChromeくらいしか入ってないので、iTunesとかあるなんて知らなかった。
音楽の再生ソフトとばかり思ってたけど、そうじゃないんだねぇ。
検索してiOS7をインストールした人の手順を見ながら、やると、特に迷わずできた。
うーん、アイコン、平べったい。
でも、なんかゆらゆらして見える。
「今日は疲れているのか・・・」と思ったら、壁紙がiPad miniの角度によって微妙に動くようだ。
「動く壁紙なのか？」と思ったら、そうではない。
でも、動く壁紙というのも増えてた。
これは、傾けると重力でボールみたいなのが動いた。
静止画のやつも、傾けると微妙に動いた。
個人的には、目にきついのでやめてほしいのだが、浮き上がってみせるための効果なのかねぇ。
そう思って時間表示を見ると、タイムゾーンの設定がうまく行っていないのか、時間がずれてた。
では、と設定画面から「日付と時刻」を選択し、時間帯を設定すると・・・固まった。
ここで慌てて再起動方法を調べ、「ホームボタンと電源ボタンの長押し」という技を覚えた。
そしてだな・・・それからうちのiPad miniは起動しなくなった。
いや、正確にはそうじゃない。
ホームボタンをトリプルクリックすると白黒反転するんだけど、そうすると真っ白になった。
つまり、起動するけど、何も表示されないままになってしまったのだ。
あれこれやったが、iTunesでiOS6に戻した。
そしてiOS7をもう一度焼いたが・・・だめ。
またiOS6に戻し、設定画面から初期化っぽい動作をさせ、もう一度iOS7を焼く。
ようやく起動するようになった。
そんな感じで、なんとなく使えるようになってきた。
まあ、まだよく基本アプリが固まるけどね、設定アプリとか。
壁紙が動くことさえ目をつぶれば、あまり気にならないかもしれない。
@propertyは自動的にセッター(setter)/ゲッター(getter)を作ってくれるそうだ。
入門書だけ読んでたら、あやうくスルーするところだった。
基本的には、こうらしい。
プロパティ宣言した名前とゲッターが同じになるけれど、メンバ変数は違うんだ。
だから、selfをつけないとうまくアクセスできなかったのだ。
それはいいとして、気になっているのは@synthesizeだ。
ネットでなんとなく読んでいる限りでは、@synthesizeしないとセッターやゲッターを作ってくれない、という風に読んでいたのだ。
しかしAppleのドキュメントを読むと、@synthesizeを使うのは、
に使うものだそうだ。
あー、今日は時間切れ。
おやすみなさい。
ちょっと説明を読んだだけなのだが、@protocolはC++でいうところのpure virtualなメンバ関数みたいなものじゃなかろうか、と思った。
「継承したらこいつらは必ず実装しろよー」というやつだ。
//[0.h]#import <Foundation/Foundation.h>@protocol AddrBook- (NSString *)name;- (NSInteger)age;@end--------------------//[1.h]#import "0.h"@interface HellBook : NSObject <AddrBook>@end--------------------//[1.m]#import <stdio.h>#import "1.h"@interface HellBook() {NSString *myName;NSInteger myAge;}@end@implementation HellBook- (id)init{myName = @"Black Dog";myAge = 3000;return self;}- (NSString *)name{return myName;}- (NSInteger)age{return myAge;}@end------------------------//[main.m]#import <Foundation/Foundation.h>#import "1.h"int main(void){HellBook *hb = [[HellBook alloc] init];NSLog(@"%@ - %ld\n", [hb name], [hb age]);return 0;}
$ clang -o tst 1.m main.m -lobjc -framework Cocoa
$ ./tst
2013-06-16 17:40:09.364 tst[395:707] Black Dog - 3000
うーん・・・。
なんだかよくわからない・・・。
pure virtualなclassは、しょせんclassなので実装も書くことができる。
インスタンスは作れないけど、ポインタ変数としては使うことができる。
それに対して、@protocolはポインタ変数も作ることができない。
AddrBook *hb;
こういうことをしたいなら、こうやる。
id<AddrBook> hb;
と思ったのだが・・・、これはこれでうまくいくけど、<AddrBook>がなくてもうまくいく。
しかも、id型じゃなくてid*型にしてもうまくいってしまった(warning多数だが)。
<AddrBook>みたいなのを付けるメリットとしては、id型だと何でも受け入れてしまうけど、id<プロトコル>とすることで、該当するプロトコルを持ったインスタンスしか代入できなくなる、というところか。
間違えの防止に役立つんですかね。
でも、id型の変数を代入する処理にしたが、これは怒られない。
ってことは、動的エラーになる可能性があると言うことか(NSInvalidArgumentException例外が発生するみたい)。
void func(id val)
{
id<AddrBook> hb = val;
}
うーん、なんか本質をつかんでないなあ。
もう少し資料を読まねばならぬようだ。
Appleの「ProgrammingWithObjectiveC.pdf」を読んでいると、後ろの方にこんな記述があった。
Objective-Cにはさまざまなメモリ管理規則があり、コンパイラはこれをもとに、必要な間はオブジェクトが確実に生きているようにしています。通常はそれほど意識しなくても構いませんが、コンパイラは生成メソッドの名前に基づいて、従うべき規則を判別します。
なんですってー！
コンパイラが名前を意識してるんだ。。。
本に書かれていたのは、ここを指していたのですな。
逆らうつもりも特になかったのだけど、根拠が見つかって安心した。
さて、allocなんかも使ってみたことだし、噂の参照カウント値を見てみよう。
#import <Foundation/Foundation.h>#import "1.h"int main(void){Hell *hell = [[Hell alloc] init];NSLog(@"count = %ld\n", [hell retainCount]);[hell print];NSLog(@"count = %ld\n", [hell retainCount]);[hell release];NSLog(@"count = %ld\n", [hell retainCount]);return 0;}
printfでもいいけど、そろそろNSLogってのにも慣れておかねば。
$ clang -o tst 1.m main.m -lobjc -framework Cocoa
$ ./tst
+[Hell initialize]
hell init!
2013-06-16 13:30:40.503 tst[791:707] count = 1
hell print : 10
2013-06-16 13:30:40.505 tst[791:707] count = 1
2013-06-16 13:30:40.505 tst[791:707] count = 1
うーん・・・。
releaseしようとすまいと、1だな。。。
gccでもそうだったのでclangにしてみたのだが、それでも同じだ。
(-framework Cocoa、がついたのは、NSLogがリンクエラーになるため。)
ratainすると2になり、次にreleaseすると1になる。
でも、今みたいにretainしなくても、releaseしたら1のままだ。
続けてreleaseすると、落ちる。
うーむ・・・・・・・。
そもそも、デフォルトの場合はARCが有効なのだろうか？ 無効なのだろうか？
コンパイルオプションに「-fobjc-arc」をつけるとARC有効、「-fno-objc-arc」をつけるとARC無効。
まずは-fno-objc-arcをつけてみる。。。変化無し。
では、-fobjc-arcをつけると・・・コンパイルエラーだ！
つまり、デフォルトではARC無効でコンパイルされるようだ。
エラーの内容は「ARCが有効だとretainCountは参照できんよ」というもの。
あと、retainとreleaseもだめだって。
では、ちょっとソースを変えて試していこう。
//[1.h]#import <Foundation/Foundation.h>@interface Hell : NSObject- (void)print;@end--------------------//[1.m]#import <stdio.h>#import "1.h"static int gValue;@implementation Hell//+ (void)initialize{printf("%s\n", __FUNCTION__);if (self == [Hell class]) {printf("hell init!\n");gValue = 10;}}- (id)init{printf("%s\n", __FUNCTION__);return self;}- (void)dealloc{printf("%s\n", __FUNCTION__);}//- (void)print{printf("hell print : %d\n", gValue++);}@end--------------------//[main.m]#import <Foundation/Foundation.h>#import "1.h"void func(Hell *hell){[hell print];NSLog(@"%s end\n", __FUNCTION__);}int main(void){Hell *hell = [[Hell alloc] init];func(hell);NSLog(@"%s end\n", __FUNCTION__);return 0;}
$ clang -o tst 1.m main.m -lobjc -framework Cocoa -fobjc-arc
$ ./tst
+[Hell initialize]
hell init!
-[Hell init]
hell print : 10
2013-06-16 14:00:20.938 tst[858:707] func end
2013-06-16 14:00:20.940 tst[858:707] main end
-[Hell dealloc]
mainで確保したhellが解放されるのは、mainを抜けたときだ。
では、ちょっと差し替えよう。
//[main.m]#import <Foundation/Foundation.h>#import "1.h"void func(void){Hell *hell = [[Hell alloc] init];[hell print];NSLog(@"%s end\n", __FUNCTION__);}int main(void){func();NSLog(@"%s end\n", __FUNCTION__);return 0;}
$ clang -o tst 1.m main.m -lobjc -framework Cocoa -fobjc-arc
$ ./tst
+[Hell initialize]
hell init!
-[Hell init]
hell print : 10
2013-06-16 14:03:34.217 tst[864:707] func end
-[Hell dealloc]
2013-06-16 14:03:34.218 tst[864:707] main end
funcで確保したhellは、funcを抜けた後で解放される。
じゃあ、これならどうだ？
#import <Foundation/Foundation.h>#import "1.h"static Hell *hell;void func(void){hell = [[Hell alloc] init];[hell print];NSLog(@"%s end\n", __FUNCTION__);}int main(void){func();NSLog(@"%s end\n", __FUNCTION__);return 0;}
$ clang -o tst 1.m main.m -lobjc -framework Cocoa -fobjc-arc
$ ./tst
+[Hell initialize]
hell init!
-[Hell init]
hell print : 10
2013-06-16 14:05:07.479 tst[872:707] func end
2013-06-16 14:05:07.480 tst[872:707] main end
確保はfunc()でやってるけど、変数スコープがグローバルなので解放するタイミングがない。
まあ、これはmain抜けたらプロセスごと終わるからいいんだろうけど、強制的に解放したいときがあるかもしれない。
#import <Foundation/Foundation.h>#import "1.h"static Hell *hell;void func(void){hell = [[Hell alloc] init];[hell print];NSLog(@"%s end\n", __FUNCTION__);}int main(void){func();NSLog(@"%s end\n", __FUNCTION__);hell = nil;return 0;}
$ clang -o tst 1.m main.m -lobjc -framework Cocoa -fobjc-arc
$ ./tst
+[Hell initialize]
hell init!
-[Hell init]
hell print : 10
2013-06-16 14:07:28.059 tst[880:707] func end
2013-06-16 14:07:28.060 tst[880:707] main end
-[Hell dealloc]
hellにnilを突っ込むことで結合が切れ、mainを抜けたタイミングで解放される処理が呼ばれた、というところか？
いや、そうではないようだ。
nilを代入する時点で解放が呼び出されていた。
mainのNSLog()前で代入すればそこでdeallocが呼ばれたし、func()で代入すればそこで呼ばれた。
そうなっているんだ、というくらいしか言えることはありませんな。
あとは、プロパティとかプロトコルみたいな基本を押さえて、今日は終わりにしますかな。
クラスにひっついている変数を、クラスオブジェクト、と呼ぶそうだ。
今私が読んでいるところでは、クラスオブジェクトといいつつも、クラスの中に入っているわけではない。
staticにした変数は同じファイルの中でしか扱えないから、それを使おう、というしくみみたい。
調べればクラス内に定義した変数でも同じことができるのかもしれんが、まあ後のお楽しみだ。
クラス変数は、+initializeというメソッドで初期化しましょう、ともある。
面倒だから試さないが、きっとこのinitializeもNSObjectを継承しないと使えないのだろう。
では、試しに書いてみる。
//[1.h]#import <Foundation/Foundation.h>@interface Hell : NSObject+ (void)hello;- (void)print;@end------------------------------------------//[1.m]#import <stdio.h>#import "1.h"static int gValue;@implementation Hell//+ (void)initialize{printf("%s\n", __FUNCTION__);if (self == [Hell class]) {printf("hell init!\n");gValue = 10;}}//+ (void)hello{printf("hell hello : %d\n", gValue++);}//- (void)print{printf("hell print : %d\n", gValue++);}@end------------------------------------------//[main.m]#import <Foundation/Foundation.h>#import "1.h"int main(void){[Hell hello];Hell *hell = [[Hell alloc] init];[hell print];return 0;}
今回から、ヘッダファイルも追加したし、mainも別にした。
そうせんとわからんからね。
yebisu:objc hirokuma$ gcc -o tst 1.m main.m -lobjc
yebisu:objc hirokuma$ ./tst
+[Hell initialize]
hell init!
hell hello : 10
hell print : 11
mainではインスタンス生成前に+helloを呼び出しているのだが、それより前に+initializeが呼び出されていることがわかる。
+initializeだが、継承しても呼ばれるとか何とかで、自分のクラスかどうかを判定せにゃならんらしい。
では、まず+initializeが1回しか呼ばれないことを確認しよう。
#import <Foundation/Foundation.h>#import "1.h"int main(void){[Hell hello];Hell *hell = [[Hell alloc] init];Hell *hell2 = [[Hell alloc] init];[hell print];[hell2 print];return 0;}
yebisu:objc hirokuma$ ./tst
+[Hell initialize]
hell init!
hell hello : 10
hell print : 11
hell print : 12
ふむ、よかろう。
では、継承させてみよう。
//[2.h]#import "1.h"@interface Hell2 : Hell+ (void)hello;- (void)print;@end--------------------------------------//[2.m]#import <stdio.h>#import "2.h"static int gValue;@implementation Hell2//+ (void)initialize{printf("%s\n", __FUNCTION__);if (self == [Hell2 class]) {printf("hell init!\n");gValue = 20;}}//+ (void)hello{printf("hell hello : %d\n", gValue++);}//- (void)print{printf("hell print : %d\n", gValue++);}@end----------------------------//[main.m]#import <Foundation/Foundation.h>#import "1.h"#import "2.h"int main(void){[Hell2 hello];[Hell hello];Hell *hell = [[Hell alloc] init];Hell2 *hell2 = [[Hell2 alloc] init];[hell print];[hell2 print];return 0;}
Hellを継承したHell2を作り、あとは全部オーバーライド。
$ gcc -o tst 1.m 2.m main.m -lobjc
$ ./tst
+[Hell initialize]
hell init!
+[Hell2 initialize]
hell init!
hell hello : 20
hell hello : 10
hell print : 11
hell print : 21
+initializeの呼出順は、ベースから順番なのかな？
最初、2.mの+initializeのif文をそのままにしていたので、gValueが初期化されなかった。
この部分の書き換えは忘れやすそうだから、自動的に「今のクラス」を取ってきてくれないものだろうか。
いや、その前に、+initializeが2回呼ばれる、というふうになってない。
どうもそれは、継承先で+initializeをオーバーライドしてないときのようだ。
2.mの+initializeをまるまるコメントアウトすると、こうなった。
$ gcc -o tst 1.m 2.m main.m -lobjc
$ ./tst
+[Hell initialize]
hell init!
+[Hell initialize]
hell hello : 0
hell hello : 10
hell print : 11
hell print : 1
Hell2のときもHell::initializeが呼ばれるけど、そのときはクラス名が違うからif文の中には流れ込まない、と。
となると、やはり書き方をパターン化してしまいたいなあ。
ネットで見ると、初期化済みstatic変数を用意しているところもあったけど、最初の1回だけのためにメモリは使いたくないし・・・。
やりたいことは、@implementationに書いたクラス名を使いたい、ということだ。
そうなると、プリプロセスの段階か。
#defineでクラス名をつけてしまえばいいけど、それはそれでいやだなぁ。
まあ、+initializeを書くことはそう多くないだろうから、注意すればいいか。
Objective-Cで、引数２つのメソッドを定義したとしよう。
- (void)methodName:(int)x yPos:(int)y
{
・・・
}
呼ぶときは、こうなる。
[obj methodName:20 yPos:30];
メソッド名はクラス内で別の名前を付けたいから、凝った名前というか、重複しないようわかりやすくつける。
でも、引数はメソッド名と直接関係があるとは限らない。
２つ以上あるんだったら、１つ目はこれ、２つ目はこれ、と意味が変わってくるだろう。
いや、言語仕様にたてついても仕方ないとわかってはいるのだ。
いるんだけど、一言言わずにはおれなかったのだ、すまん。
さて、明日は@interface、@implementation、それとプロトコルってやつまでは調べておきたいな。