2010年11月15日月曜日

プロパティに関するコーディングルール

Google Objective-c スタイルガイド 日本語訳 の、プロパティについて以下を参考にする。

文字列には copy を使うこと
NSStringプロパティには、必ず copy 属性を宣言するべきです。

これは論理的には、NSString のセッタには必ず、retain の代わりに copy を使わなければならない、というルールに従ったものです。

アトミック性
プロパティにはオーバーヘッドがあることを認識しておいてください。デフォルトでは、同期のセッタとゲッタはすべてアトミックになります。そのため、セットとゲットの呼び出しには同期オーバーヘッドがかなりあります。アトミック性が必要ないなら、プロパティを nonatomic と宣言しておいてください。

Delegate パターンについても以下を参考にする。
Delegate パターン
Delegate オブジェクトを retain するべきではない。

<-- 追記 -->
命名規則
プロパティに対応するインスタンス変数名は、アンダースコア(_)で終わらなければなりません。プロパティ名は、対応するインスタンス変数名から最後のアンダースコア(_)を取り除いたものにするべきです。

@interface MyClass : NSObject {
@private
NSString *name_;
}
@property(copy, nonatomic) NSString *name;
@end

@implementation MyClass
@synthesize name = name_; // インスタンス名を隠蔽できる。
@end
// ------------------------------------
NSLog("%@", self.name);

-(void) dealloc{
self.name = nil;
[super dealloc];
}

参考
Google Objective-c スタイルガイド 日本語訳

2010年11月13日土曜日

プロパティ

目的*1
■ プロパティ宣言により、アクセサメソッドの動作方法の明瞭で明示的な仕様を指定できます。
■ コンパイラは、宣言で指定された仕様に従ってアクセサメソッドを合成できます。これは、コードの記述と保守が少量で済むことを意味します。
■ プロパティは構文上は識別子として表現され、範囲付きであるため、コンパイラは宣言されていないプロパティの使用を検出できます。
■ あるクラスによって宣言されたプロパティの実行時のイントロスペクション。
-----------------------------------

イントロスペクション(リフレクション)*2
通常、プログラムのソースコードがコンパイルされると、プログラムの構造などの情報は低レベルコード(アセンブリ言語など)に変換される過程で失われてしまう。リフレクションをサポートする場合、そのような情報は生成されるコードの中にメタデータとして保存される。

宣言属性
iPhone 開発で主に使用される属性をまとめた。
プロパティ属性 説明
assign setterで単純代入を使用することを指定する
retain 代入時にオブジェクトに対してretain を呼び出す必要があることを指定する
copy 代入にオブジェクトのコピーを使用することを指定する
nonatomic 合成されるアクセサが非アトミックになるように指定する

retain*3
クライアントオブジェクト側において、プログラム上の有効範囲を超えた後も受け取ったオブジェクトを保持する必要がある場合は、受け取ったオブジェクトを保持できます。それには、retainメッセージを送信します。

nonatomic*4
nonatomic属性の影響は環境によって異なります。デフォルトでは、合成されるアクセサはすべてアトミックです。マネージドメモリ環境では、アトミックな動作を保証するにはロックを使用する必要があります。また、返されるオブジェクトは保持され自動解放されます。このようなアクセサが頻繁に呼び出されると、アトミックな動作はパフォーマンスに重大な影響をもたらすことがあります。ガベージコレクトされる環境では、ほとんどの合成メソッドはこうしたオーバーヘッドなし
でアトミックになります。
アトミックな実装の目的は堅牢なアクセサを提供することであり、コードの正確性を保証することではないことを理解することが重要です。「アトミック」とは、プロパティへのアクセスがスレッドセーフであるという意味ですが、単にクラス内のすべてのプロパティをアトミックにするだけでそのクラス(一般にはオブジェクトグラフ)が「スレッドセーフ」になるということではありません。スレッドの安全性を個々のアクセサメソッドのレベルで表現することはできません。

参照

*1
Objective-C 2.0 プログラミング言語

*2
イントロスペクション(リフレクション)

*3
Cocoa Fundamentals Guide / cocoaオブジェクトのライフサイクル

*4
objective-c 2.0 プログラミング言語 / パフォーマンスとスレッド

2010年11月12日金曜日

参照カウンタ

objective-c のメモリ管理方法。
基本原則
「alloc」または「new」で始まる名前のメソッドや、「copy」を含む名前のメソッド(たとえば、alloc、newObject、mutableCopy)を使用してオブジェクトを作成した場合、またはオブジェクトにretainメッセージを送信した場合は、そのオブジェクトの所有権を取得できます。
その場合は、releaseまたはautoreleaseを使用してオブジェクトの所有権を放棄する責任が
あります。それ以外の方法でオブジェクトを受け取った場合は、そのオブジェクトを解放してはなりません。

メッセージ 保持カウント
alloc 1にする
copy 1にする
new 1にする
retain 1つ増える
release 1つ減る
autorelease 1つ減る(ただし、任意のタイミング)


参考
Cocoaメモリ管理プログラミングガイド

2010年11月10日水曜日

戻る/進む(unDo/reDo)

戻る/進む を行うショートカット

戻る
⌘ + option + ←

進む
⌘ + option + →

2010年11月9日火曜日

Dropbox に gitレポジトリを作成する

1.
Dropbox フォルダ内に gitレポジトリ用のフォルダを作成する。
cd ~/Dropbox
mkdir repository

2.
上記フォルダ内に、[プロジェクト名].git というフォルダを作成して init する。
cd repository
mkdir ProjectName.git
cd ProjectName.git
git --bare init

--bare
Create a bare repository. If GIT_DIR environment is not set, it is set to the current working directory. *1

裸のリポジトリ(bare repository)
裸のリポジトリとは、通常 .git の拡張子を持つ ディレクトリ で、 リビジョン管理下にあるチェックアウトしたファイルをローカルに持たないディレクトリです。 通常 .git サブディレクトリ に隠れている git の管理ファイル全てが repository.git ディレクトリに直接存在し、 他のファイルは存在せず、チェックアウトもされていません。 通常、公開リポジトリを出版する人は、裸のリポジトリを作成します。*2

3.
既存のソースを追加するためには、そのプロジェクト上で以下のコマンドを実行する。
cd ~/develop/OldProject
git init
git add . // 全てのファイルを追加する
git commit -m "(コメント入力)"
git push ~/Dropbox/repository/ProjectName.git master
git remote add origin ~/Dropbox/repository/ProjectName.git

4.
ファイルを更新した後、以下のように更新したファイルの addとcommitを行い、さらに ローカルレポジトリ(既存プロジェクト)をリモートレポジトリ(Dropbox に作成したレポジトリ)へ push する。
git add ~/develop/OldProject/oldfile.h // 変更を全て含む場合、git add --a
git commit -m "(コメント入力)"
git push ~/Dropbox/repository/ProjectName.git master //git push origin master でも可

参考:
*1
git-init(1) Manual Page

*2
Chapter11. GIT用語集 裸のレポジトリ

2010年11月6日土曜日

iPhone で Picasa クライアントを作成する準備

Google Date API
http://code.google.com/intl/ja/apis/gdata/index.html

Google Date API にアクセスして、Picasa データを取得する。
iPhone で利用するためには、gdata-objectivec-client を静的ライブラリとして組み込む。

参考資料
BuildingTheLibrary の、Linking to the iPhone Static Library の内容に(ほぼ)従う。
http://code.google.com/p/gdata-objectivec-client/wiki/BuildingTheLibrary

ライブラリの準備
下記場所からダウンロードできるが、ビルドエラーが出る。
ライブラリ名:gdata-objective-client-1.10.0.zip
http://code.google.com/p/gdata-objectivec-client/downloads/list

なので、svn から直接ダウンロードして、iPhone プロジェクトのディレクトリに入れる。
http://code.google.com/p/gdata-objectivec-client/source/checkout
svn checkout http://gdata-objectivec-client.googlecode.com/svn/trunk/ gdataClient
mv  gdataClient samplePicasa


gdata-objectivec-client をビルドするための準備
1.
gdataClient -> Source -> GData.xcodeproj を開く。
2.
ビルドターゲットを GDataTouchStaticLib に変更する。
 今回作成する静的ライブラリはコレなので、他はターゲットから外す。
3-1.
ターゲット -> GDataTouchStaticLib -> 情報を見る -> ビルドタブ 構成:release を表示する。
設定 -> ベースSDK を、iPhoneデバイス4.0 に変更する。
設定 -> アーキテクチャ を、Standard に変更する。

3-2.
その他のCフラグに以下を追加する。
-DGDATA_INCLUDE_PHOTOS_SERVICE=1
 picasa を利用する場合の設定はこのようになる。それ以外のgdataを利用する場合は、参考 *2 を参照する。



4.
Simulator, Device それぞれReleaseビルドを実行する。
5.
出力されたライブラリを lipo コマンドを使用して統合する。
cd samplePicasa/gdataClient/Source/build
lipo -create Release-iphoneos/libGDataTouchStaticLib.a Release-iphonesimulator/libGDataTouchStaticLib.a -output libGDataTouchStaticLib.a


iPhoneプロジェクトにライブラリを追加する
6.
libGDataTouchStaticLib.a を iPhoneプロジェクトに、追加 > 既存のファイル で追加する。
 今回のiphoneプロジェクト名は samplePicasa とする。




7-1.
samplePicasa -> 情報を見る -> ビルド 全ての構成 を表示する。
他のリンカフラグに、-ObjC -lxml2 を追加する。




7-2.
ヘッダ検索パスに、次の2つのパスを追加する。
/usr/include/libxml2 → 再帰的にチェックする。
$(SRCROOT)/gdataClient/Source/build/Release-$(PLATFORM_NAME)/Headers



8.
適当なファイルに #import "GData.h" を追加してビルドが通れば完了。


参考
*1
iPhone開発ガイド 第3章アプリケーションの実行 ビルド環境の設定
*2
Removing Unneeded Code