石川洋資さんから、彼と西山勇世さんと共著の Swift 入門書を頂いたので、その見所などを綴ってみました。 基本と実践が良いバランスで織り交ぜられていて、言語仕様だけに止まらない内容が印象的、充実感を味わえる読みやすい本な印象でした。
Swift のプロトコルでは、付属型に既定の型を指定できるようになっています。それとプロトコル拡張とを組み合わせると、プロトコルの表現力がぐっと高まるので、今回はそれについて紹介します。 付属型には既定の型を指定できます。指定方法は簡単で、付属型を定義するときに = を使って既定の型を記載します。 protocol MyProtocol { associatedtype Some = Int func method(value: Some) -> Any } 例えばこのようにしてあげると、付属型 Some は、既定では Int が想定されていることが記載できます。 ここまでだと、適用は今まで通り このようにプロトコルを定義した時、これを例えば MyStructA という型に適用する時は、プロトコルで規定されている必須の実装を定義することになります。これについては既定の型使わないときと同じで
そんな中、利用させて頂いている仮想サーバー ConoHa に ConoHa API なる Web API があることを知りました。 ドキュメントを読む限り、請求データの取得とか、VM の操作とか、いろいろできるらしくて面白そう。これは ConoHa API を学んでみるにも、気になっていた Himotoki を学んでみるにも、良い機会そうに思えてきました。 そんな気持ちを後押しするもうひとつに、@_ishkawaさん の APIKit というライブラリがありました。 このライブラリは、単純ながらも何かと手間がかかりがちな Web API へのアクセス周りをシンプルかつ的確に記述できるライブラリです。しかもこちらも「型安全」を特徴にしていて、さらには Himotoki と相性が良いとのことで、Himotoki に興味を惹かれるにつられて、興味が湧いていたのでした。 せっかくなので、ConoH
CFSocket を使用して UDP ポートの待ち受けを行う場合には、次のような流れになります。 ここでは、クラス "MyClass" に、UDP による待ち受けを実装しているものとして、話を進めて行くことにします。 MyClass.h 内での定義 // 必要なヘッダーは次のような感じです。 #import <Foundation/Foundation.h> #import <netinet/in.h> #import <sys/socket.h> #import <arpa/inet.h> @interface MyClass : NSObject // パケットを受信したときに呼び出されるコールバック関数を定義します。(C 形式) static void MyClassSocketReceivedCallback(CFSocketRef socket, CFSocketCallBack
Xcode の Interface Builder では、IBOutletCollection を使うことで、複数のコントロールをひとつの配列変数に関連付けて管理できます。 コードでの定義方法は、IBOutlet の代わりに IBOutletCollection(ControlType) を使用して、変数の型は NSArray 型で宣言します。 @property (nonatomic,readwrite,strong) IBOutletCollection(UILabel*) NSArray* labels; 例えばこのようにすることで、UILabel 型のコントロールを関連付けるための配列 labels が定義できました。 これで、この変数に Interface Builder から複数のコントロールに対して、関連付けの線を引っ張って行くことが可能です。 型として UILabel クラ
Objective-C は、Mac OS X 標準の開発言語であり、iPhone アプリの開発にも、この Objective-C 言語が利用されます。 C 言語にオブジェクト指向の考えを実装したプログラム言語で、そういった趣旨の言語としては他に C++ もありますが、C++ と Objective-C とではコードの雰囲気にずいぶんと違いがあります。 Objective-C 言語は、コンパイル時には厳密な型チェックやメソッドの存在確認が行われません。 柔軟な記載ができる反面、実行時に思わぬ動作不良を起こすことにもなるので注意が必要ですが、この辺りは Xcode 4 の LLVM コンパイラを使うことで、丁寧な構文チェックが行われたり "Static Analyzer" を使ってリアルタイムにコード解析ができるため、ほとんど気にならなくなりました。 コンパイラによって柔軟さ故のミスが発見でき
ARC (Automatic Reference Counting) では、変数宣言の際に、その変数の制御レベルを指定できるようになっています。 これによって、retain, release, assign, autorelease を直接制御できなくても、それぞれに似たような制御をコンパイラにしてもらうことができるようになっていました。 ARC で指定できる制御レベルには、次の 4 つがあるそうです。 1. __strong 普通に宣言された変数は、この制御レベルになるようです。 この変数に値を代入する際は、まず左辺値が retain されて変数に格納された後、その変数に格納されていた以前の値が release される流れになるようです。 この操作は atomic になっていないらしく、マルチスレッド環境では @synthesize 等で適切に制御する必要があるとのことでした。 この制御
メソッドに従来のような命名規則、getMethod や newMethod という名前を付けるとどうなるのでしょう。 このような名前で NS_RETURNS_RETAINED といった制御を付けずに動作を試してみたところ、getMethod の方は autorelease 的な動きを見せたのに対し、newMethod の方は retain 的な動きを見せました。 どちらとも、関数内では alloc & init したものを戻り値としてあったのですけど、ARC ではメソッド名(メソッドファミリ)によって、戻り値の状態を自動的に整えてくれる感じのようです。 ARC でメソッドファミリとして認識するキーワードとしては "alloc", "copy", "mutableCopy", "new", "init" があるようです。 これらの名前で始まるメソッドは、自動的に "NS_RETURNS_RE
autorelease な値を返すメソッド ARC でのメソッドの戻り値は、通常は autoreleasing された状態で呼び出し元に戻される感じでしょうか。 関数を通さずに alloc & init で生成したオブジェクトを __strong 変数に格納すると、それに nil を代入した時点で直ちに解放されましたけど、alloc & init で生成したオブジェクトを返すメソッドを呼び出して __strong 変数に格納すると、それに nil を代入しても、オートリリースプールを抜けるまでは、解放されない感じでした。 // 通常のメソッド定義です。 - (NSString*)aMethod:(NSString*)anArg; // 上記メソッドの実装の一例です。 // ARC 環境では、このように alloc & init しても、呼び出し先で autorelease として扱われるよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く