角丸ボタン in Xcode 6.1.1 その２

疑問：

角丸ボタンってそもそもそういうクラスでいいんじゃないの？と思ったりなんかして、UIButtonからUIRoundButtonを作ってみたが、そしてそれはinitに書くことで同じことは出来たのだが、プレビューできないじゃん。

自分で作ったクラスをプレビューさせるにはどうすればいいのでしょう？


UIButtonでUser Defined Tuntime Attributesを書いてもプレビューはできない（ま、Runtimeっていうぐらいだからね）し、そもそも２つ以上の角丸ボタンを使うときに、毎回それ手で設定するのは馬鹿だよね。。何かまともな方法があるんだろうか？

結論：

自分はOopsオンチなのでクラス化の王道は知らないが、イメージ通りに書くのが基本的なスタイル。自分が物事をどう捉え、プログラム的なイメージに変換しているか、ということ。

だから「角丸ボタン」は「ボタンの角を丸くする」のではなく、「初めから角が丸いボタン」なので、プレビュー出来る出来ないとか、クラスであるべきないべきとかは置いておいて（問題先送り）、UIRoundButtonにしてしまって問題ない。

先送りした問題が解決すれば自動的に何かが変わる（変える）だろう。

角丸ボタン in Xcode 6.1.1

以前の（Xcode4? もう自分本位なことしかやってないのでXcodeのバージョンはどうでもいい感じで過ごしてきた）バージョンではround rect button とかいう角丸のボタンがオブジェクトライブラリの中にあったのだが、Xcode6には入っていない。

以下、stackoverflowのポストより。

1. XcodeのIdentity InspectorのUser Defined Runtime Attributesに追加する

2. コードで書く
roundButtonという名前で viewDidLoadで初期化的に実行。

ViewController.h:
@property (weak, nonatomic) IBOutlet UIButton *roundButton;

ViewController.m:

- (void)viewDidLoad {

    [super viewDidLoad];

    CALayer *btnLayer = [roundedButton layer];

    [btnLayer setMasksToBounds:YES];

    [btnLayer setCornerRadius:10];

}

コードはstackoverflowのポストからの丸パクリで、半径を10に変えただけ。リンクだけだと元原稿が消えることがままあるので。

これを見ろ！

的な画像。



恐れ入った。

出来過ぎたバグ。

iOSのとろける地図*1というバグらしいが、ある種の超漸進的突然変異のよう。普通は大き過ぎる変化は疎まれる結果しか生まないが、稀にこういうエクセレントなことが起こる。100%ないということが"ない"証。

それにしてもすごいよねこれ。

参考記事：WIRED NEWS (US) / WIRED日本版（日本版にはこの画像は掲載されていない）

*1 自分が勝手に言っているだけ。念のため。

iOSのスレッド

iOS Developer Library : MIDI Services Reference より引用

  "readProc will be called on a separate high-priority thread owned by CoreMIDI."

 high-priority thread。

常々スレッドがどうなっているのか、よく分からないまま後回しにしているがなるほど。WindowsにしろUnixにしろ今まで使う度に適当にいなしてきたが、久々に裸で割り込みレベルに合わせて作り込んで来た日々をちょっと思い出す。

後で真面目に調べよう。iOSのスレッド。

関数の構文が分け分かんない件

例えば、MidiSend関数は次のように宣言されているのだが、

extern OSStatus

MIDISend( MIDIPortRef port, 

MIDIEndpointRef dest, 

const MIDIPacketList * pktlist ) __OSX_AVAILABLE_STARTING(__MAC_10_0, __IPHONE_4_2);

え？この構文（関数パラメータの括弧とじと文末のセミコロンの間）って何？ということで探しまわること数時間。その言わんとしている意味は何となく分かるのだが、書き方が許せないをモチベーションに、重い腰を上げてStackoverflowで検索してみると、

http://stackoverflow.com/questions/4924285/how-to-deprecate-a-method-in-xcode

にその答えが。

そのものズバリの話ではないが、この回答欄にある、deprecated用のgccの構文というところが答え。このケースでは、これを呼ぶんだとき、deprecated条件に一致すると、warningが出力される。

llvmじゃないの？と思ったが、歴史の古さからはgccだろう。

それはいいとして、そもそも例えば、

__AVAILABILITY_INTERNAL__IPHONE_6_1

のような定義がどこに定義されているのか、見つからない。__OSX_AVAILABLE_STARTINGが定義されている、"Availability.h"を見ても特に何も#includeされてないようだし。。と思ったが、よく見ると、先頭ではなく、中途半端なところに、"AvailabilityInternal.h"が#includeされていて、その中に__AVAILABILITY_INTERNAL__IPHONE_6_1などがずらずらと定義されており、

__attribute__((availability(ios,introduced=4.1,deprecated=6.1)))

のように書いてあった。

まあそれにしても、勝手にこういう構文が追加になって人が持ってたK＆R読んだことがある自分にメールの１つもよこさないってどういうこと？

UIApplicationMainのパラメータ

"Empty Application"でプロジェクトを新規作成した場合、main()のUIApplicaitonMainのパラメータでクラス名を渡す際、直接 @"AppDelegate"とせずに、NSStringFromClassを使っている。

UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]))

これは、XcodeでRefactor->Renameしたとき、ここもきちんと変わってくれるようにするためではないだろうか。

@synthesizeを省略する

windowが、というか、xcode（ver 4.5.2）でempty applicationを新規作成すると、作成されるスケルトンの中で、そう例えば application:didFinishLaunchingWithOptions:の中で、

    [self.window makeKeyAndVisible];

みたいにプロパティが使われている。
これを直接インスタンス変数に変えてみようとすると、あれ？ _windowがない。というか、windowの@syznthesizeがない。かといって

    [window makeKeyAndVisible];

だとエラーになる。まさか、

    [_window makeKeyAndVisible];

だと通るの？

通るんですよお客さん。

がしかし、全部のプロパティが@synthesizeが無いわけでもない。試しに1個消してみると、undefinedになる。えーまさかのwindowだけ？　なわけないよないくらなんでも。論理が通らない。

何だろう？と暫し悩み、ググるも、色よい答えが見つからず、xodeの4.4辺りから@synthesizeが省略できる、という話は見かけるものの、そこまで。

でよーくコードを見ると、window以外のプロパティには readonly が付いている。

「これ？」

はい、それです。readonlyを取ると、他のプロパティも@synthesizeなしでOK。もちろんインスタンス変数名は「_プロパティ名」となる。

readonlyを付けると、自分の見間違えで、設定するところだけエラーになるのかと思ったが、間違いなく参照個所すべてが"undecleared"になる。

変なの。

convenience method を簡易メソッドと訳すのはどうかと思う

要するにパラメータありのコンストラクタ的なクラスメソッドをconvenience method、もしくは人によってconvenience constructorと呼ぶよう。何れにしても機能的には、alloc してinitするのをいっぺんに済ませるためにconvenienceと言っているわけなので、簡易ではなく、便利とか、便利とか、便利とか、の意味になるだろう。簡易はあくまでかりそめのとか、本物、本格的になものに対してとりあえずの、とか、お手軽な、という意味で、それ自体が簡易であるということになり、書き方が簡単、という意味には成り得ない。

こうしたことも自分の電子*なら簡単にパッチを当てられるのだが。

ついでに言えば、そもそも、NSStringのstringWithFormat:は、createWithFormat:みたいに、それ自身がインスタンスをアロケートしていることを示唆するメッセージセレクタでなければならないんじゃないだろうか（createAnInstanceWithFormat とか、allocAndInitWithFormat:でもいいが、ネイティブの英語感が分からないのでその辺は何とも言えないところ）。ただポリモーフィズムがないとかあるとか言われるObjective-Cだが、さすがにセレクタに思いっきりstringは無いよなあ。この命名規則だとクラス毎に（nantokaClassNameWithFormat:みたいな）全部違うセレクタになってしまう。

*電子ブックのこと。自分は電子ブックを電子と略したい派。

2012/12/12 追記
どうやらallocとかnewが付くと、メモリ管理上呼び元が所有者になる、というルールがあるみたいだ。一方convenience method（コンビニエスメソッド）の返すインスタンスは、autorelesase付きで返す、とかなんとか。ARC化された今となっては過去の遺物か。

メモリ管理

素人目だが、どうも第３章メモリ管理は間違ってるように見える。

p69 中程のコード

[p release]

これが

Possession *p = [Possession alloc] init];

だったらどうするのか？
他の例に習えばreleaseするはず。

「自分の所有しないオブジェクトを解放しない」というのが、何か例外を発生させるような問題なのか、それとも作法の問題なのか、今ひとつ明確に答えていない。

ここでは結局autoreleaseを使うということで決着しているが、そうしないと例外が起きるのかどうかは書いていない。

それにautoreleaseが送信されるとNSAutoReleasePoolのインスタンスに追加される場合、保持カウントは1になっている記述があるが、P71では「配列が保持して保持カウントが1になります」とあり、カウントされていないような記述になっている。無茶苦茶だ。

この本はここまでいい調子で来ただけに、この章の出だしの例えが酷過ぎる辺りからして、著者はイマイチ自信がないんだと思う。勝手な推測だが。

実は3rd edition（英語版）をkindle本で買ったのだが、この部分はすっかりARC対応になっていて、すべて書き変わっているので、今更かもしれない。

まあメモリ管理は重要だけど、根本的なことなので、飛ばしても最後に分かれば問題ないと思う。最後に分かれば、だよ。