年末のお忙しいところ失礼いたします。トーストを床に落とすと必ずマーマレードを塗った方が下になる、iPhoneアプリ開発担当の七尾です。いつも仕事でObjective-Cばかり書いておりますが、そういえばMac用のアプリもObjective-Cで書けるんだっけ?じゃ、おれでも書ける?という、いつも通り頭の中がお花畑な発想で、ただでさえこの忙しい時期に初Cocoaアプリを作ってみたので、お知らせしたく記事を書いております。 punchdrunker/Opener – GitHub 何を作ろうかな? 幸いにも(?) 以前からずっと困っていた事があったので、その問題を解決するツールを作ることにしました。 その問題がどのくらいの人に関係するのかはハッキリ申し上げて、あんまいないだろうなと正直思うのですが(笑)、それはファイルサーバ上のファイルパスの共有です。 自分はMacをメインの作業端末にしている
MacOSXプログラミング。毎日更新。 話題: Cocoa, Objective-C, Snow Leopard 画像を拡大縮小できるようにしてみる。 ソースコード:sp4-12.zip 拡大縮小はよくある四方に□をつけて行うやつではなく、ウィンドウのように右下だけで行うようにする。 <=このアイコンを画像の右下に表示する。この画像は OSについていた resize.gifを拝借している。 リサイズアイコンは画像が選択された時だけ表示して機能するようにする。こんな感じ。 機能実装のポイントは次のとおり。 (1) リサイズアイコンの表示 (2) リサイズアイコンドラッグ時の処理(拡大縮小) (1) リサイズアイコンの表示 以前、導入した ItemIcon クラスを改良して使うことにする。初期化時に画像の4角(左上、右上、左下、右下)のどこへ表示するか指定し、位置決めの為に以前の setOri
Cocoaプログラミングの話題 ■はじめに ■Cocoaのメモリ管理(1) ■Cocoaのメモリ管理(2) ■Cocoaのメモリ管理(3) ■Cocoaのメモリ管理(4) ■Cocoaの例外処理 フリーウェア、サンプル等 ■MyShelf Cocoa関連ドキュメント ■AppleのCocoa関連ドキュメント ■Foundationリファレンス(Objective-C) ■Foundationリファレンス(Java) ■Application Kitリファレンス(Objective-C) ■Application Kitリファレンス(Java) ■オブジェクト指向プログラミングとObjective-C言語(PDF) ■Stepwise articles Cocoaなページ ■MacOS X/OPENSTEP用IRCクライアント IRCStep(J) kFujiwaraさんのMacOS X/O
なぜ Objective-C は気持ち悪いのか分析してみる企画。前回はコードの見た目について考えましたが、今回はクラスについて考えてみます。 動的な生成のみ Objective-C は、静的なインスタンスを生成することはできず、必ず動的なインスタンスを生成しなければなりません。常にポインタで扱うことになるので、高速な反面、メモリ管理の煩わしさが常につきまといます。通常、インスタンスの生成、破棄は次のようにします。 id object = [[NSObject alloc] init]; [object release]; NSObject に対して alloc メッセージを送り、インスタンスのメモリ領域を生成します。そのあとに、それに init メッセージを適用し、インスタンスを初期化します。ほとんどの場合、alloc, init はペアにして実行します。なぜなら、alloc しても in
iPhone OS 向けのアプリケーション開発で注目を浴びている Objective-C 言語ですが、Objective-C についてあまりいい噂を耳にしないので、なぜそうなってしまうのかという分析をしてみることにしました。記事が長くなりそうだったので、今回は見た目編です。 1. 見た目 プログラミング言語において、見た目というものは重要な要素のひとつです。Objective-C 言語はオブジェクト指向言語でありますが、実際のコードをみてみると、ほかのメジャーな言語とはちょっと違った構文がとられています。 メッセージ式 Objective-C では、メソッド呼び出しをメッセージ式で記述します。以下は、anObject に message というメッセージを送る例です。 [anObject message]; [anObject message:arg1]; [anObject messag
Objective-C のメモリ管理の話をします。Objective-C ではどのようなルールに基づいてコーディングすればよいかを説明します。 alloc, copy, new を送信したオブジェクトは、それによって生成されたオブジェクトを所有します。また、retain を送信したオブジェクトは、その受信側のオブジェクトを所有します。 所有しているオブジェクトが不要になったら、そのオブジェクトに release メッセージを送信して、所有を放棄しなければなりません。 所有してないオブジェクトに release メッセージを送信して、そのオブジェクトを放棄しようとしてはいけません。 補足して、次のようなことも頭に入れておきましょう。 誰もオブジェクトを所有しなくなったとき、そのオブジェクトには dealloc メッセージが送信され、そのあとメモリから解放されます。 あるオブジェクトを複数のオ
Objective-CとCocoaの立場から、デザインパターンを眺めてみるこの取り組みも、いよいよ佳境に入ってきた。残すところ数パターンとなってきた。だが、まだまだクセの強いパターンが残っている。 今回からは、Interpreterパターンを取り上げよう。文法や言語を読み込むために使われるパターンだ。 Interpreterパターンとは Interpreterパターンは、その名の通り、インタプリタと考えてしまえばいいだろう。インタプリタは、計算機の処理系の一種で、プログラミング言語などを読み込みながら処理するものだ。たとえば、BASICインタプリタや、Perlインタプリタなどがある。 このインタプリタのためのパターンが、Interpreterパターンだ。インタプリタそのものをデザインパターンにしてしまうとは、なかなか大胆な発想だ。 Interpreterパターンでは、文法規則の1つ1つをク
Interpreterデザインパターンは、非常にプログラミング言語よりのパターンだ。自分で、新しくて、それでいながら簡易なプログラミング言語をデザインするときに使う事になるだろう。それ以外の場合は、なかなかお目にかかれないパターンだ。 Cocoaにそのようなパターンを使っているクラスがあるのだろうか? 実は、ピッタリのものがある。それは、Core Dataで使われている、オブジェクトを抽出するための文法だ。 Cocoa Predicates Core Dataは、MVCアーキテクチャでいうと、モデルをサポートするものとなる。モデルクラスの作成を強力にバックアプする。クラスのモデリングのための専用ツールを用意し、データの永続性をほぼ完全に実現している。 Core Dataは、その出自にEnterprise Objects Framework (EOF)の技術がある。EOFもCocoaと並んで
クラスの乗っ取り Objective-Cには、ポージングという機能がある。これは、一言でいうと、既存のクラスを「乗っ取る」ことができる機能だ。すでにあるクラスを、強引に自分のクラスで置き換えてしまう。 ポージングは、poseAsClass:というメソッドで行う。このメソッドが呼ばれたクラスは、引数で渡されたクラスのように振る舞うことになる。これは、具体的な例を見てもらうのが早いだろう。 例として、Cocoaでウィンドウを表すクラスであるNSWindowを継承した、TransparentWindowというクラスを作ってみた。クラスがランタイムに読み込まれたときに呼ばれる、loadメソッドの中で、poseAsClass:を呼んでいる。 // TransparentWindowクラスの宣言 @interface TransparentWindow : NSWindow {} @end /
前回は非形式プロトコルの説明をして、デリゲートでよく使われるという話をした。今回は、形式プロトコルと非形式プロトコルの違いを追求してみよう。 非形式プロトコルに対する、形式プロトコルの利点は、次の2つにある。 メソッドの実装をチェックして、コンパイル時に警告を出す conformsToProtocol:を使って、プロトコル準拠を調べることができる デリゲートに、この利点が有効かどうか、説明しよう。 デリゲートの設定はInterface Builderで Objective-Cを利用しているフレームワークであるCocoaでは、とても多くのクラスがデリゲート機能を提供している。特に、モデル・ビュー・コントローラ構造の、ビューにあたるクラスでは、基本的な動作の制御は、すべてデリゲートを通して行われる。フレームワークの設計の指針として、クラスの拡張は、できる限りデリゲートで行い、サブクラス化をなる
前回は、Objective-Cのプロトコルについて説明したが、その利点としてプロセス間通信の抑制という点を挙げた。だが、プロトコルは、もう一つの側面である「オブジェクトの振る舞いを表すメソッドの集合」をするもの、という文脈で語られることが多い。この説明を後回しにしたのは、この機能は「もう1つのプロトコル」で実現されることが多いからだ。今回は、このことを説明しよう。 非形式プロトコル 前回説明したように、プロトコルは「@protocol」という、特別な文法を導入している。だが、メソッドの集合を宣言するだけなれば、わざわざ新しい文法を使う必要はない。カテゴリを使えばよい。ただし、ちょっとコツがいる。Objective-Cのルートクラスである、NSObjectのカテゴリとして宣言するのだ。 実際の例を紹介しよう。Cocoaでは、テーブルビューを表示するために、NSTableViewというクラスが
前回と同様、Objective-Cでのメソッド宣言にまつわる話を続けよう。今回は、メソッドの集合を宣言するプロトコルだ。 プロトコルによるメソッドの集合の宣言 プロトコルは、オブジェクトの振る舞いを表すメソッドの集合を定義するものだ。@protocolという指示子で宣言する。 具体的な例を見てみよう。次のコードは、NSCodingというプロトコルを宣言するものだ。これは、オブジェクトをエンコード、デコードするためのメソッドを定義する。この2つのメソッドで、オブジェクトの保存/読み込み機能を実装する。 @protocol NSCoding - (void)encodeWithCoder:(NSCoder*)coder; - (id)initWithCoder:(NSCoder*)decoder; @end オブジェクトがこのプロトコルを採用することを、プロトコルに適合している、という。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く