カテゴリー : HMDT

『たのしいアプリプログラミング 〜 Swiftで始めよう!』公開から2週間の状況


icon512 icon512

『たのしいアプリプログラミング 〜 Swiftで始めよう![有料版][無料版]』は、公開から2週間ほど経ちました。ダウンロードしていただいた方、ありがとうございます。

で、現在の状況なんですが、まぁ気になるのはダウンロード数ですよね。紙の本が発売された後の書籍のアプリ化ということで、セールス的には厳しいだろうな、と思っていましたが。

で、蓋を開けてみたら、現時点で購読者数(有料版ダウンロード数+無料版完全版購入者数+紙の書籍を買った方向けのライセンスコード発行数)が、700を超えました! 最初の目標を1,000に置いていたので、悪くないかな、と。

紙の方は初版3,000部がほぼはけたらしいので、その1/5か1/4程度は出たということですね。まぁ、長く売れるコンテンツだと思っているので、この後数ヶ月かけて伸ばしていきます。

アプリの方は、着実に機能向上中。検索機能は実装済み。コメント機能は、7割方できたってとこかな。でも、iTunes Connectがクリスマス休暇中だから、申請できません。再開したら、バージョンアップかけますね。

『最新iOSプログラミング徹底解説』の見本をいただいた


技術評論社様から、『最新iOSプログラミング徹底解説』の見本をもらいました。ありがとうございました。Xcode 6とiOS 8に対応した、初心者の次のステップをターゲットにしたらしい、解説書です。12/24あたりに発売らしいですね。

著者は、新居雅行さん。新居さんといえば、私のMacプログラミングの先生で、この方の著書に出会ったのが最初のきっかけでした。もう20年くらい前の話かー。

昔話はさておき、この本はiOS 8とXcodeでプログラミングする際に、有用で実践的な情報がちりばめられています。サンプルコードも多いし、動作説明も微に入って細ってます。ただ、唐突に話が始まって、いきなり話題が飛んだりするので、最初から順に読んでいくというよりは、実際にアプリ作りながら、どうすればいいか困ったときに読むといいんじゃないかな。

基本的にObjective-Cです。Swiftも触れられてはいますが、ちょっとだけですね。全部Swiftにしてもよかったんじゃないかな。

いい本ですし、役に立ちますが、こういう本こそ『たのスイ』のアプリ版みたいに、電子版またはアプリ版になってくれればいいのになー。アプリにして、Objective-C editionとSwift editionの2つがあったりしたら面白いのに。

 

『たのスイ』revision 1.1公開。説明の追加や誤植の修正など


公開から一週間が過ぎました、アプリ版『たのしいアプリプログラミング 〜 Swiftで始めよう!』。おかげさまで、たくさんダウンロードしていいただいています。

で、誤植や、説明が不足しているという指摘が出てきましたので、さっそくコンテンツの更新を行いました。revision 1.1です。これ、ややこしいですが、アプリのバージョンとは別です。テキストの内容は、別途更新していきます。

更新の仕方は簡単で、『たのスイ』アプリを起動してください。新しい版が見つかった旨を表すアラートが表示されるので、「更新」ボタンを押せば完了です。もし、このアラートが一瞬で消えてしまったら、設定画面の「コンテンツの更新を確認」からもう一度表示することができます。(この不具合は、アプリバージョン1.0.1で修正されます)

revision 1.1での更新内容は、以下の通り。

  • 1-4-1 誤植の修正
  • 1-4-1 昔のMacの話をちょっと追記。昔ってのは、Mac OS 6とか7のころね
  • 3-6-2 誤植の修正
  • 3-6-3 辞書の文法を修正。Dictionaryのジェネリックを使うものではなく、「[:]」を使うものに変更。
  • 7-5-3 Webビューの自動レイアウトについての説明と図版を追加

今後も、誤植が見つかったり、ここ分かりにくいよ、っていう指摘があったら、随時更新しますので。

『たのスイ』アプリ版、リジェクトくらう


審査に提出していた『たのスイ』アプリ版、ようやく動きがあったと思ったら、リジェクトくらいました。泣けます。

リジェクト理由は主に2つ。まず、「製品のタイトルにAppleの商標が入っている」。「Swift」のことですね。iBooks Storeの方にSwiftの名前が付いた本が色々と上がっていたので大丈夫か、と思っていたら、App Storeではダメでした。

しばらく悩んだ後、『たのしいアプリプログラミング 〜 Swiftで始めよう!』に変更しました。ということで、いきなりですが、アプリの名前が変わりました! 『たのしいアプリプログラミング』です! でも、略称は『たのスイ』のままで。

もう1つのリジェクト理由は、「ただの本はiBooks Storeで販売しろ」。単純に本をアプリ化したものは、App StoreじゃなくてiBooks Storeでやれ、ということですね。

もちろんiBooksは検討したんだけど、サンプルアプリを内部で動作させるとか、ストリーミングムービーを見ながら読めるとか、iBooksでは実現できない機能を実装したからアプリにした、ということを説明。この説明が受け入れられるだろうか。

という説明書きを加えて、再提出へ。バイナリは変更しないで済みました。

これで通るかなー。もし通らなかったら、Kindleで販売するか、それか書棚アプリへ転換するか、ってとこかな。

『たのスイ』アプリ版、ひたすら審査待ち


『たのスイ』のアプリ版ですが、11月も終わりそうなので経過報告ですが、2週間ほど前に審査に出して、ひたすら審査待ちの状態です。In Reviewのまま動きません。通過すれば、公開となります。これより後に出したアプリは審査通過しているんですけどね。基準がまったくわかりません。

アプリは有料版と無料版の2つを申請しています。無料版は、1章を読むことができて、残りはアプリ内課金で購入することになります。

紙の本を購入していただいた方には、今回は、無料で読めるようになります。無料版のアプリをダウンロードしていただいて、ライセンスコードの発行依頼を送ってもらうことになります。詳細は、公開されてから説明します。

レビューのタイムラグは、何遍やってももどかしいです。

『たのしいSwiftプログラミング』アプリ版もうすぐ申請


『たのしいSwiftプログラミング』ですが、紙の書籍はおかげ様で好調で、重版が決まりました。もうすぐ入校するらしいです。重版は、Xcode 6.1およびiOS 8.1に対応すべく全部ソースコードを見直しました。

同時に、お問い合わせが多いのが、電子版について。思ったより作業量が多くて手こずっていますが、もうすぐ完成します。なので、その内容のご紹介。

『たのスイ(略した)』の電子版は、まずアプリとして出ます! つまり、アプリ版です! App Storeで売ります。なぜ、iBooksやKindleではなくアプリなのか? それは、プログラミングの電子書籍として、どうしてもやりたいことがあったからです。

まず、電子書籍としての表示方法は、リフロー型で縦スクロール型。縦にスクロールしながスイスイ読めるぜ! 節毎にページが分かれていて、スワイプで前後の節に移動する形だ。

happyswift

つまりページネーション(画面のサイズを1ページとして分割して、めくりながら読むやつ)は、やらない、と。なぜか? それは、プログラミングの本だから、ソースコードを読ませたいから。紙の本だと、どうしてもソースコードがページの途中で分割しちゃうでしょ。あれが嫌だ。電子版ならそれが回避できるぜ!

さらにリフロー型なんで、iPhoneであっても画面を横にすれば、きれいな形でソースコードを見ることができるよ。

happyswift_code

さらに!『たのスイ』ではXcodeを操作する手順をビデオとして公開している。これも埋め込んだ。解説動画を見ながら、本文のテキストを読むことができるんだ。

happyswift_video

 

画面上部に表示されているのがビデオ。その下にあるのがテキストね。ビデオ再生しながら、テキストをスクロールして読めるよ。

まだある! プログラミング解説書には、サンプルのアプリがつきものだ。その動作って、手っ取り早く試してみたいよね。でも、ビルド環境が整っていないと、なかなか動かせなくていらつくこともある。

そこで! 電子書籍だから、その場でサンプルアプリを動かせるようにした。テキスト中に、こんな感じでアプリアイコンがある。

happyswift_sample1

これをタップすると、その場でサンプルアプリが立ち上がるぞ! モーダルビューとして表示してるんだね。

happyswift_sample2

 

という訳で、プログラミングの本らしくこういったことをやりたかったので、iBooksやKindleではなく、アプリ版にしました。あと本文の内容としては、Xcode 6.1およびiOS 8.1に完全対応したし! Yosemiteにも完全対応したし(スクリーンショット全部撮り直した)! 本文の分かりにくかったところを修正、および追記もしたし! 実質改訂1.1版ってとこだね。

アプリはiPhone版とiPad版で登場。もちろん、iPhone 6およびPlusに対応。有料版と無料版(立ち読み用)で登場予定。後日Mac版も登場予定。紙の本を買っていただいた方には、何らかの方法で読めるようにする予定。iOS版かMac版のどちらかを買えば、もう片方も読めるようになる予定。

値段は、まだ公表できないですが、紙よりは安くなります。

あと、将来の話ですが、コメント機能をぜひ追加したいです。『たのスイ』の内容に関する問い合わせは、メールやブログのコメントではなく、集約できる場所が欲しいので。Cloud Kit使えば簡単に作れると思うんだ。

『たのしいSwiftプログラミング』正誤表


『たのしいSwiftプログラミング』ですが、正誤表準備できました。

正誤表/サポート:たのしいSwiftプログラミング[iOS 8&Xcode 6対応]

普通の誤植やミスと、Xcode 6.1というかiOS 8.1への対応を記述してあります。iOS 8.1になったとき、多くのCocoa APIのオプショナル型が変更されたため、こういった事態になってしまっています。

ビルド時にエラーが出た場合は、こちらを参照してください。

たのしいSwiftプログラミング発売、さっそく正誤表や電子版のことなど


久しぶりに新しい本を書きました。『たのしいSwiftプログラミング』です。昨日、10/26に発売になりました。

『たのしいCocoaプログラミング』(略称たのココ)に続く、たのしいシリーズです。新言語Swiftを使ったプログラミング入門書になっています。ターゲットとなる読者は、いままでまったくプログラミングの経験がない人。プログラムって何? というゼロの状態から、最初のアプリを組み上げるまでを説明します。

たのしいシリーズの特徴は、独特な語りかけるような文体で書かれていること。技術書らしからぬ読み口で、挫折せずに、最後まで一気に読ませます。

で、出したのですが、本に載っているサンプルが動かない、という状況が発生しています。これがですね、本の内容はiOS 8の正式版が出た時点ですべて検証したんですよ。校正して校了したのが10/8くらい。ふー、やれやれ、終わったー、と思っていたら、10/20にiOS 8.1が登場しました。まぁ、0.1のアップデートだからマイナーなバグ修正だよね、と思ってたら、何を考えたのかSwiftのAPIを変えてきやがりました。んな、アホな!

8.0から8.1のアップデートで、いままでコンパイルが通っていたSwiftのコードが通らなくなりました。APIの変更といっても微細なことで、オプショナル型が一部変わったんですね。あの、「!」とか「?」ってやつね。小さな変更でも、一箇所でもコンパイル通らなくなれば惨事になっちゃうよな。ベータのときもしょっちゅうオプショナル型変えていたから、嫌な予感はあったんだけども。

ということで、10/27に発売となったこの本は、登場した時点でコンパイルに失敗するコードが掲載されることになってしまいました。新しい言語なので仕様が固まっていないのはよくあることなんですけど、8.0から8.1で変更かけてくるのは納得いかないなあ。APIリファレンスの変更も追いついていないし。正直、憤りのあまり、銀座のApple StoreにいってiPhone 6 Plusを全部曲げてこようかと思いました。

サンプルや正誤表の方は、いま出版社さんとやり取りして準備してもらっています。少しお待ちください。明日中くらいにはなんとか。(追記:正誤表準備できました。http://www.bnn.co.jp/errata/7173/

このままってのもよろしくないので、電子版を準備しています。まずは、融通が利くアプリ型で。電子版は、iOS 8.1への対応、Yosemiteへの対応、いくつかの記述の追加などを加えた、rev.1.1的なものになります。

そうすると、紙の本を買っていただいた方に不利益が生じるので、特別価格か無料で提供できるよう、調整しています。問題になるのは、紙の本を買ったということを、どうやって判断するかですね。特に仕込みをしてなかったからなぁ。本の写真を撮ってTwitterにアップしてもらおうかな。

ちょっとしばらくバタつきそうですが、最新環境のキャッチアップして、継続的に更新できる環境を整えたいので、少しお待ちください。

Eclipseに対する不満のいくつかの解消


昨日の記事「Xcode使いがEclipseにぶちまける10の不満」に対して、コメントやTwitterなどで色々教えていただきました。また、hd 4.0さんはエントリも書いていただきました。ありがとうございました。これで、いくつかの不満は解消されました。

「1. メソッドの一覧表示および絞り込み検索」について

MacではCmd + Oでポップアップが表示される、と。これだよ!これが使いたかったんだよ!

eclipse_popup

テキストフィールドに入力する事で絞り込みもできる。これは前方一致のみなのかな。部分一致だったらもっと好みだったんだけど。

「2. 補完入力」について

Ctrl + Spaceでいつでも補完入力できるよ、と。これはさすがに、検索したらいろいろでてきました。Mac環境では、Spotlightのショートカットとぶつかるので、気をつけろと。

「4. シミュレータ」について

スナップショットを活用しろ、またはGenymotionを使え、と。まだ試してないですが、やってみようと思います。やっぱりみんな、純正のものは遅いと思ってたんですよね。あー、よかった。

「5. Subversionとの統合」について

Subversiveプラグインをインストールしろ、と。これもまだ試していないですが、やってみようと思います。

「6. エディタの2画面表示」について

エディタのタブをドラッグすることで分割表示ができる、と。なるほど。

eclipse_divide

単純にエディタを並べるだけで、特に連携とかはしないってことですね。まぁ、並べるだけでも使い手はあります。

Android Studioを使え

もうEclipseは古くて今後はAndroid Studioになるからそっちを使え、と。そうなんですね。developer.android.comに行って、Developer ToolsのDownloadでいちばん目立つものをクリックしていったら、Android Developer ToolsとEclipseがインストールされたので、これかと思ってました。次のプロジェクト作るときは、Android Studioを使ってみようと思います。またいくつかの不満が解消されますように。

7、8、9は?

「7. インスペクタ」「8. 操作をアニメーションで確認する」「9. スタックトレースを見やすく表示する」に関しては、反応がなかったですね。そもそも、これらは不満に思っていない、ってことなんですかね?

なんとなく、どう言われるかは予想できるんですよ。インスペクタに関しては、layoutファイルなんかは直接XMLを編集するから、別に凝ったプロパティ画面はいらない。操作のアニメーションでの確認は、一度動きを理解できれば必要ない。スタックトレースは、見れているんだから問題ない。

ただね。私が個人的に、Eclipseに対してどうしても我慢できないのは、この点なんですよ。色々挙げた不満のうち、メソッドの絞り込み検索や、補完入力などに関しては、機能としてないわきゃないんですよ。単に私の調べ方が悪いだけで、あるに決まってんですよ、機能は。

「機能(Feature)」と「見た目(Appearance)」

何が言いたいかっていうと、ソースコードを編集するエディタとしての「機能(Feature)」は十分にある。機能の数だけ数えたら、XcodeよりEclipseの方が上でしょう。でも、編集内容や結果の「見せ方(Appearance)」に関しては、ぜんぜんなっちゃいない。というか、より良い見せ方を考える事を放棄しようとしているんじゃないかと。むしろ、そんなこと考えるのは恥である、とすら考えているのではないかと。開発環境なんだから、素早くコードを編集できればそれでいいじゃないかと。

それに対してXcodeは、バージョンアップするたびに派手なユーザインタフェースを導入して、おいおい開発環境のくせにここまで凝っていいのかよ、って思わせるんですよ。でも、それが「使い物」になるんですよ。Inteface Builderでのレイアウト、Core Dataモデリング、Subversionのdiff表示、XcodeではないですがInstrumentsのプロファイリングなんかを使ってプログラミングすると、冗談抜きで素のテキストエディタのみでやるよりも50倍くらい速いんですよ。

Eclipseはほぼテキストエディタのみだし、レイアウトのGraphical Layout編集は、まぁ正直に言ってお粗末なものです。コマンドラインアプリ作るならいいけど、スマートフォンアプリをこれで作るのかぁ、と思うとげんなりします。8割くらいユーザインタフェース関連のコーディングでしょ。Android Studioだとましになっているのかな。

完成品とガレージキット

Twitterであった反応の中で、

これは今の私の気持ちにピッタリくる、と思ったのはこのつぶやきでした。

Xcodeは塗装完成品で、Eclipseはガレージキットである、と。つまり、Eclipseはそのまま使うものではなく、プラグインをどんどん導入して自分なりの環境を構築していくところに価値がある、ということなんでしょう。これはLinuxの文化ですよね。Android開発も、その気質を受け継ぐところがあるかな?

私の個人的な気持ちは、プラグイン拡張を前提とした場合、足りない機能をその都度補えるのは確かに良い面と言えるでしょう。だけど、ほとんどの場合、それは一貫性、使いやすさ、美しさを損なうものです。それが、構造的に宿命的に、いらつかせるのです。

良い悪いではなく、好き嫌いで言えば、モノリシックな美しさの方が好きだよ、私は。

Xcode使いがEclipseにぶちまける10の不満


最近Android開発をやらされてます。「やらされている」というのは、特定の案件のためというより、時流としてもういい加減無視できないので会社の方針としてやることにした、でも非常に嫌々な気分満載、というニュアンスを含んでいます。

私も大人になりましたし、仕事ですから、Android端末を手にとっても、それを7階のオフィスから投げ捨てるようなことはなくなりました。ニッコリ笑って操作しますが、左上に戻るボタンが見つからない瞬間に、床に叩き付けてしまいます。ハードウェアボタンかよ、くそっ。あーもう正直にいいますが、嫌いっすよAndroid。iPhoneラブですよ。

当方生粋のMacユーザなので、ものの見方にバイアスがかかっていることは自覚しています。いまのAppleからは想像もできませんが、Macを昔から使っている人は虐げられていた期間が長いので、ひねくれてねじまがっているんですよ。その世界観では、悪の帝国Googleに立ち向かうジェダイの騎士Appleです。iPhoneを携えてAndroidを駆逐しなくては!という義憤にかられます。ですが、最近のAppleのビッグプレイヤーぶりを見ると、隔世の感というか、自分がジジイの繰り言になっているのがよく分かります。Appleはもう俺たちなんか必要としていないんだ。しゃーねーなー、Android開発もやるか。ちなみに、Microsoftはすでに滅んだ過去の帝国です。

で、Android開発をやると、最初に立ちはだかる壁がEclipseですよ。開発環境。当方OS XおよびiOS開発を生業としていますので、開発環境はXcodeこれ一本。前身であるProject Builderから使い続けていますよ。毎日12時間は使い続けているXcodeは、もう自分にとって体の一部です。

そんな私がEclipseを使いました。もうね、言っちゃいますけどね、ホントの気持ち言っちゃいますけどね、最悪ですよこれ。起動からクラッシュするまで、最悪の気分ですよ。まずアイコン、ださっ。起動、遅っ。画面表示、無駄っ。ツールバー、汚っ。エディタ、重っ。プロジェクト管理、訳分からん。ガベージコレクションの最中にクラッシュ、バカじゃねーの。

いや、知ってます。知っているんです。Eclipseを使い続けてきた人がXcodeを使ったら、これとまったく同じ感想を抱くことを。EmacsやVisual Studioを使っている人がXcodeに抱く感想も、同じことを。みんな、自分が慣れ親しんでいる環境が一番なんです。「使いやすさ」に対する絶対的な尺度はないんです。「慣れ」が最も大事なんです。開発者が、他の環境にあわせるのは、並大抵のことではないんです。

あれですね。開発環境を移すということは、ある意味海外に移住することに似ていますね。言葉が違う。習慣が違う。文化が違う。何をやるにもストレスフルです。でもそれは、別の視点を獲得することでもあります。違いを認め、新たな考え方を習得することで、より豊かな生活を送れるようになります。

よーし。Eclipseを使うという事は、異文化への挑戦である。ここはひとつ、腹を据えて触ってやろうじゃないか!………(触っている)………(触っている)………(触っている)。分からーーーん!ぜんぜん思い通りに動かないーーー!海外で迷子になったけど、看板も読めないし、誰にも話しかけられない気分だーーー!

なぜこんなにイライラするのか?それは「この操作はXcodeだったらこうするのに、Eclipseだとやり方が分かんない、または結果が期待と違う」からです。だから、やり方が分かればいいんだけど、マニュアルもドキュメントも量だけ膨大で、そのくせ大したこと書いていなくて、もう何をどう探せばいいのか分からんちんです。

そこで!Eclipseの操作で何が分からないのか、または気に食わないのか、まとめてみました。Xcodeをずっと使っていた人が、Eclipseのここでつまずいているよ、というのをまとめてみました。でもこれって、とても基本的な操作ばっかりなので、たぶんEclipseでもできると思います。ってか、できてくれよ。なので、これを読んで解決方法が分かる人がいたら、「こうすればいいんだよ、愚か者め」と教えてください。

1. メソッドの一覧表示および絞り込み検索

エディタでソースコードを編集するとき、そのクラスに含まれるメソッドの一覧を素早く表示、かつ絞り込み検索もしたい。

Xcode

エディタの上部にあるポップアップメニューをクリックすることで表示できます。

xcode_popup1

表示順は、ソースコードに書かれた順です。ポップアップを表示した状態でキーボードから文字を入力すると、絞り込み検索ができます。

xcode_popup2

絞り込みは、前方一致ではなく部分一致です。だから、メソッドの名前の一部を覚えていればオッケー。つまり「あのメソッドの編集したいな、えーっと名前なんだっけ、viewが含まれていたっけ」といううろ覚えな感じでも、素早く検索および移動ができます。

また、#pragma markを使う事で、メニューの中に区切り線や特別な文字を追加できます。上の図における”View Life cycle”とかですね。これにより、自前でメソッドをカテゴリに分けて管理できます。

Eclipse

Eclipseでのメソッド一覧表示は、これかな?Outlineの表示。

eclipse_outline0

一覧表示はありました。メソッドだけじゃなくて、スタティック変数なんかも出てくるところはXcodeより機能は上ですね。絞り込み検索を行うのは、Filtersでしょうか?

eclipse_filters

Fitersの画面で、キャラクターマッチングが行えます。でもこれ、「パターンにマッチした名前を隠す」なのね。なんで?マッチしたものを表示するなら分かるけど、なんで隠すの?どんなシチュエーションでこれ有用なの?結局、絞り込み検索はできないの?

2. 補完入力

クラス名、メソッド名やキーワードを補完入力したい。私は、補完入力肯定派です。

Xcode

あるメソッドの中で、次のコードを入力してみます。

self = [super initWithNibName:nibName bundle:nil];

まず、’s’を入力しまう。すると、’self’を補完するための候補がポップアップで表示されます。selfが出てこないときは’se’まで入力します。

xcode_comp5

そこでselfを選択して、タブキー(またはエンター)をヒット。文字列が補完されるので、続いて’ = [su’までを入力します。すると’super’を補完するための候補が表示されます。

xcode_comp1

タブキーをヒット。文字列が補完されます。続いて、’ i’を入力。iで始まるメソッドの候補が表示さます。

xcode_comp2

‘in’まで入力すると、絞り込まれる。ここでわざと、’initWithCoder:’を選択。タブキーを押します。

間違えたので、’initWith’まで削除してエスケープキーを押します。または、’initWit’まで削除して’h’を入力します。すると再び、候補が表示されます。

xcode_comp3

今度はinitWithNibName:bundle:を選択。最後に引数を入力して完了。このときローカル変数であるnibNameや、defineであるnilも補完されます。

まとめると、selfやsuperといったキーワードが補完されます。メソッド名が補完されます。一度削除して、再度入力するときも補完されます。あと、インスタンス変数やローカル変数も補完されます。

Eclipse

あるメソッドの中で、次のコードを入力してみます。

super.onCreate(savedInstanceState);

まず、’s’を入力します。何も補完されません。なんで?キーワードは補完されないの?どっかで設定する必要があるの?しょうがないので、’super’まで入力します。そして’.’を入力します。メソッド名を補完するための候補がポップアップで表示されます。

eclipse_comp

ここで’onCreate()を選択してエンターを押します。すると、’onCreate(savedInstanceState);’まで入力されます。これで終わり。ふむ、素晴らしい。

でも、ちょっと変更したいと思って、メソッド名を’onCrea’まで削除します。このとき、どうやっても補完ポップアップが表示されません。なんで?エスケープキーを押すとかして、この状態から候補を表示できないの?しょうがないからメソッド名を全部削除して、再び’.’を入力すると候補が表示されます。つまり、一度間違えると全部消さないといけないのか。

また、引数の’savedInstanceState’は自動入力されましたが、これも一度削除して、もう一度’s’と入力しても補完候補は表示されません。なんで?ローカル変数は補完の候補にならないの?

まとめると、superというキーワードが補完されません。クラスの後にドットを入力すると補完候補が表示されますが、候補を一度決定すると途中から補完させる事はできません(もう一度ドットの入力からやりなおす)。インスタンス変数やローカル変数は補完されません。

Xcodeは、クラス名、メソッド名、インスタンス変数名は、宣言のときにただ一度書くだけで、あとはフルに入力する事は無いです。だって補完されるから。したがって、Xcodeではシンタックスエラーはありえない。だって補完されるから。一度入力したメソッドを変更したいときも、一部を削除するだけで、またすぐ補完候補が表示されます。

Eclipseも補完はされるんだけど、一度間違えると修正するには全部消してもう一度ドットの入力からやり直さないといけない。これがとってもストレス。

3. APIドキュメント

各種フレームワークのAPIドキュメントを表示したい。そして、クラス名やメソッド名で検索したい。

Xcode

Helpメニューから「Documentation and API Reference」を選択します。専用のツールが表示されます。検索バーにクラス名、メソッド名、変数名などを入力します。インクリメンタルサーチされます。

xcode_apiref

選択すればその項目が表示されます。こんだけ。疑問の余地無く単純です。

Eclipse

Eclipseにはドキュメントをブラウズするためのツールが、、、ない!?ないの?ないこたないと思うんだけど、見つからないよ。

しょうがないので、Webブラウザを使います。Webブラウザを起動して、http://developer.android.com/reference/を開きます。パッケージ一覧が出てきます。右上の検索フィールドから、クラス名が検索できます。インクリメートサーチできます。

eclipse_apiref

クラス名は検索できるんだけど、メソッド名は?メソッド名での検索の仕方が分からない。できないの!?そんなバカな。ないわけないよね?そんなオブジェクト指向開発環境あるはずがない。きっと秘密の方法があるんだよね!?

4. シミュレータ

テストのために、Mac上で動作させたい。シミュレータまたはエミュレータを使いたい。

Xcode

動作するスキームとして、iOSシミュレータを選択します。

xcode_scheme

ビルドして実行します。シミュレータが起動して実行されます。以上、おしまい。

Eclipse

Android Virtual Device Managerから、Android Virtual Deviceを作成します。選択して実行します。エミュレータ起動画面が表示されるので待ちます。

eclipse_emu

待ちます。待ちます。待ちます。5分待っても画面が変わらないので、強制終了します。以上、おしまい。

なんかネットで検索すると、Intel製?のエミュレータがあるらしくそれを使えという事らしいけど、純正でこんなにも使い物にならないってのは、どうよ。ダメすぎじゃん。

iOSはシミュレータ。Androidはエミュレータ。つまり、iOSはOSおよびアプリをx86にネイティブコンパイルしたものを使います。だから速い。AndroidはARMチップをx86上でエミュレートして走らせます。そりゃ遅いに決まってます。純正でまともな速度で動作するエミュレータ(もしくはシミュレータ)作ってよ。

5. Subversionとの統合

開発環境と、各種SCMを連携させたい。うちの会社はSubversion使っているんで、Subversionが動けばいいです。

Xcode

新規プロジェクトを作成して、Subversionに入れる。その状態でプロジェクトを開く。これだけで連携します。リポジトリアドレスの入力などは必要なし。プロジェクトにファイルを追加すると、Subversionにaddされますし、削除するとdeleteされます。編集したら、commitします。

Eclipse

EclipseでのSubversion統合は、できるんだよね、きっと?ちゃんと調べれば、どこかにやり方が書いてあるんだよね?ただXcodeみたいに設定なしでできるというわけではないのかな?

6. エディタの2画面表示

Xcode

Xcodeでは、エディタを2つ並べて連携させる事ができます。このとき、右側のエディタはアシスタントと呼ばれます。

xcode_assistant

アシスタントにはざまざまな表示が可能ですが、カウンターパートと呼ばれるものがあります。これを使うと、左側に.mを表示するとき、右側に自動的に.hを表示させることができます。その逆で、.hを選択したときに.mを表示する事も可能。

また、左側で.xibや.storyboardを表示して、右側に対応するコントローラクラスを表示する事も可能。インタフェースをデザインしながら、対応するソースコードを実装できます。

Eclipse

Javaはヘッダファイルがないから、この機能への要求が低いのは分かります。でも、layoutを編集しながらActivityのコードをいじれたら、便利だと思うんだけどな。

7. インスペクタ

Xcode

Xcodeの、ユーザインタフェース編集のためのインスペクタ画面です。

xcode_inspector

Eclipse

Eclipseの、ユーザインタフェース編集のためのプロパティ画面です。

eclipse_property

なめとんのか。手抜きだ手抜き。

8. 操作をアニメーションで確認する

XcodeもEclipseも、基本的に一画面をタイル分割して各種情報を表示しています。そのタイルを隠したり表示したりできるんだけど、Xcodeはそのときにアニメーションが伴います。Eclipseは伴わない。正直Eclipseだと、何がどこに移動したのか分かりません。操作をした直後は完全に動揺し、そのまま30秒画面を凝視した後で、何がどこに動いたのかが理解できます。これがアニメーションがあれば、その瞬間に分かるものです。

アニメーションはただの派手な演出ではありません。ユーザを導くガイドラインです。Eclipseは、それがまったくないです。

9. スタックトレースを見やすく表示する

Xcode

Xcodeのスタックトレースです。

xcode_stack_trace

Eclipseのスタックトレースです。

eclipse_stack_trace

ぐは。ログかよ!

これは悪意のある比較で、Eclipseにもちゃんとリストで表示するスタックトレースは見つけました。

eclipse_stack_trace1

でも、ログで吐くスタックトレース(しかも改行されてリストで表示)は、衝撃だったな。これしかなかったらどうしよう、と思った。

10. ワークスペースを複数開く

Xcodeでは、開発は「プロジェクト」が基本。プロジェクトを複数まとめた「ワークスペース」も作成できます。ワークスペースは複数作成し、同時に開く事ができます。

Eclipseでは、開発は「ワークスペース」が基本。ワークスペースで複数の「プロジェクト」をまとめます。ワークスペースは複数作成できますが、同時に開くことはできません。なんでじゃ!しかもワークスペースを切り替えるときに、一度Eclipseが終了します。なんでじゃ!

これたぶん、LinuxやWindowsでは別プロセスとしてEclipseがもう一つ立ち上がるんだと予想。OS Xだと、同一アプリを複数プロセスで起動することができないので、こうなってしまっているんじゃないかな。

道具は思考を規定する

こうやって不満に思ったところを書き出してみましたが、これで分かったのは、私の考え方は完全にXcodeに支配されているということです。もうちょっと穏当な言い方をすれば、開発スタイルがXcodeに合わせて最適化されている、ってことでしょうか。もし始めからEclipseだけを使っていれば、それに合わせた思考体系になっていて、ここで挙がった不満は生じない、そもそもそういう欲求が起きないのでしょう。

そしてそれは、その道具を使って開発されるアプリにも影響を及ぼさないはずがないです。つまり、Xcodeの思考体系に慣れたプログラマと、Eclipseの思考体系に慣れたプログラマは、どうしたってそのスタイルに引きずられながらアプリを開発します。これは、ボタンのちょっとした挙動や、設定画面に必要な項目などで、ちょっとした、ほんとにちょっとした差として表れるでしょう。

それらが積み上がっていった結果、どちらがより良いアプリになるか?その辺りを意識しながら、Eclipseを使い続けてみようと思います。