ピアソン桐原
売り上げランキング: 53448
ちょっとMacで作りたいツールがあるので、xcodeでobjecteve-cでプログラム組んでみることにした。
もちろん、cocoaを使う。
と言っても、Objective-Cなんてほとんど使ったことない。以前、iPhoneのアプリが作りたくて一枚の画像を表示するだけのアプリを作ったけど、ぶっちゃけわかりづらくてめんどくさい言語だなぁと、その時は思った。
でも、ネットで調べてみるとObjective-Cはなかなか評判が良い。
一度、本でも読んでみるかということで、「Mac OS X Cocoaプログラミング」という本を買って読んでみた。
この本すごくわかりやすい。Javaとかやってないと説明について行けないかもしれないけど、サンプルが絶妙なのか、的確に疑問に思うであろう点を説明するようにしてあるのか、非常におもしろい。
これなら覚えられるかも。
そんなこんなで、Macでアプリ作りたい人は、これ読んでみるといいかもしれない。
Xcodeは無料だし、なかなか高機能だし、慣れると気持ちよくコーディングできる。
Visual Studioも目じゃないかも。
以下は、ほとんど自分用のメモとか気づいたこと列挙。
この本、Xcode3の頃のものなので、最新のXcode4とは少し合ってないところがあるので、そこら辺をメモしていたのを以下に列挙する。
目次
- 1 LionならばXcode4を入れないと動かない
- 2 Xcode4は、ソース管理はsubversionとgitに対応しているらしい
- 3 せっかくだからGitリポジトリを使う(準備をしてみた)
- 4 Lionのフルスクリーンに対応
- 5 main.mが本に書いてるある場所にない
- 6 ボタンとかのパーツが見つからない
- 7 Docウィンドウというのはどこへ?
- 8 クラスを新規作成してClassesに移動しろと本にあるが、そんなフォルダ無い
- 9 クラスを追加する
- 10 メソッド名の修正
- 11 IBOutletはアノテーションの代わり?
- 12 スコープがない?
- 13 行番号表示は設定
- 14 最新のヘルプ入手
- 15 GUIは自動コード生成ではなくシリアライズ
- 16 ヘルプ
- 17 Objective-Cは割とアバウト
LionならばXcode4を入れないと動かない
LionではXcode3を動かすと、デバッグ時に管理者パスワード聞いてきて、それが激重でまともに動かない。Xcode4をApp Storeから落としてくること。
Xcode4は、ソース管理はsubversionとgitに対応しているらしい
gitはxcode4から。
http://sazameki.jp/translations/xcode4/IDEs/Conceptual/Xcode4TransitionGuide/SCM/SCM.html
せっかくだからGitリポジトリを使う(準備をしてみた)
MacにGitインストール
http://weble.org/2011/02/14/git-mac-install
MacPortでインストールしてみよう
http://weble.org/2010/06/17/macports
と思ったら、自分の環境にMacPortは入ってた。
でも、バージョン古かったのでアップデート。
sudo port -v selfupdate
そして、gitもインストール
sudo port install git-core
予想以上に時間かかる。十分以上?
Xcode4でプロジェクト新規作成すると、Gitのローカルリポジトリ作るか聞いてくるみたい。Gitをインストールしたから聞いてくるようになったのか、実は元々入れなくてもよかったのかはわからない。
ここにチェックするとオーガナイザーのリポジトリに追加されているっぽい。
Lionのフルスクリーンに対応
なにげにxcode4はフルスクリーンに対応している。これがなかなか使いやすい。27インチの解像度が役に立つ。
作成するアプリもウィンドウのFull Screenの値をUnsupported以外にするととりあえずフルスクリーンのボタンが出てきてフルスクリーンになるけど、自分でGUIは直さないと、真ん中に画面がちょこんと出るだけで、笑える。
main.mが本に書いてるある場所にない
main.mはSupporting Filesの中に出来ている。
ボタンとかのパーツが見つからない
view – Tools – Show Object Library すると右下に表示される。
最初は File Template Libraryになっているかも。
ドロップダウンの上に並んでいるボタンを押して切り替えてもいい
コントロールのプロパティーはxcodeでは、Attributes Inspectorで設定する。
Docウィンドウというのはどこへ?
Interface Builderの横に表示されているこれみたい。
下のボタンを押して広げるとPlace Holder、Objectと名前付きで表示される。
クラスを新規作成してClassesに移動しろと本にあるが、そんなフォルダ無い
Delegateクラスもプロジェクトの直下にあるようなので、それに習ってそこに置いてみた。特に問題はないみたい。
ちなみに、classを新規作成するときはファイル名だけ入れればいい。自動的にmとhの拡張子のファイルができあがる。
クラスを追加する
Xcodeの特殊な所。
クラスのファイルを作るのはいいが、GUIのボタンを押したときにどうやって、このクラスの処理を実行させるかがC#とかに比べると変わっていてわかりづらい。
クラスを作るところは、まぁ普通。ファイル追加すればいい。
次にオブジェクトをDocウィンドウにドロップしないといけない。
ドロップしたオブジェクトのインスペクタでClassを先ほど新規作成したクラスにする。
補完利きます。
ヘッダの書き方に間違いがなければ、インスペクタでOutletsやActionが出てくる。Outletsがクラス変数。Actionがメソッドという事みたい。
呼び出し会うもの同士を線でつなげる。右クリックしてtextFieldの右の○をウィンドウのコントローラーにドロップ
似たような感じでcontrol押しながらコントローラー(たとえばテキストボックス)をドラッグして、オブジェクトのseedやgenerateにドロップ。こっちは右クリックしないのね。
こうやって、コントロールのイベントとロジックを結びつける。
本では、オブジェクト指向プログラムでは、呼び出し先のインスタンスを呼び出し元のインスタンスに伝えておかなければならないと書いてあったけど、イメージがつかみやすくていい説明。
まさに、この接続する操作はそれをやっている。
Javaのイベントの扱いもリスナーとかレシーバーとかこんな感じだったけな?
C#は見事にこのあたり隠蔽されているので忘れてしまった。
メソッド名の修正
アクション名を間違っていたので、ヘッダファイルを直して保存して、ドラッグし直したらちゃんと訂正できた。
後でわかったんだけど、こんなことしなくても、該当のアクションを右クリックしてリファクターからリネームすれば関係するところ全部書き換えてくれて楽。
IBOutletはアノテーションの代わり?
IBOutletはNothingと評価されるマクロだそうだ。Interface Builderがクラス宣言を見つけるのにつかうとのこと。Javaのアノテーション代わりに使っているってことかな。IBActionはvoid扱い。これも同じ理由らしい。
スコープがない?
スコープ記述はあるけど、基本publicでprotectedが標準で、それで問題ないんじゃないの?とのこと。厳密さに欠けるかもしれないけど、確かに問題ないかも・・。
行番号表示は設定
設定の、text editingのShow: LIne numberをチェック
最新のヘルプ入手
設定のDocumentationで、Check and Install Nowすると最新のドキュメントが落ちてくるみたい。
GUIは自動コード生成ではなくシリアライズ
GUIはシリアライズしたものをデシリアライズしているらしく、Visual StudioみたいにGUIいじると裏でGUI生成するコードが書き換わるというものではないらしい。実体はxmlなのかな。
ヘルプ
option押しながらクラスをクリックすると説明が出る。英語だけど。
とにかくどこでもいいから、画面のよくわからん所を右クリックすると表示されるポップアップに、その部分のヘルプを表示するメニューがある。英語だけど。
Objective-Cは割とアバウト
サンプルはrandomをintに入れているけど、どうやらこいつはlongを返すみたい。コンパイル通らないかと思いきや、warning出ながらも普通にコンパイルできた。割とアバウトなんだなObjective-C。
勝手に出来ているxxxAppDelegateというのはひな形ファイルで、こいつは最初からDocにドロップされてクラス名が指定されている状態になっている。なるほどねぇ。
別の本ではこの最初から出来ているものを使う前提で進んでたから、どうやってGUIとロジックがひもづいているかわからなかったんだよね。
で、また驚いたのが、上記のmとhファイルは使わないからと言うことで消して、でもxlbにはこのクラスを参照しているオブジェクトが残っている状態でコンパイルしたら、普通に通ったということ。
かなりアバウトで、趣味で使うには気楽で気持ちいいかもね。
Warningっぽいのは出てたけど。
とりあえずxlbの残骸オブジェクトはカットして消し去った。
あと、nil、Javaとかでいうnullのオブジェクトを操作しようとしてもエラーにはならないらしい。nullなら無視して進むらしい。
ということは、null pointer exceptionとか絶対起きないのだろうか。
これはこれで柔軟すぎて怖いような気もするけど、無駄にnullだったらあーだこーだという条件分岐を書きまくらなくていいので、シンプルにはなるかもしれないな。
なんか慣れるとcocoaプログラミング楽かもしれない・・・
