開発 | HMDT Blog

カテゴリー : 開発

歴代iPad/iPhoneデバイスの画素数での大きさ比較


iPad ProやApple TVが相次いで発表されたけど、最近のデバイスはでかい。正確にいうと、画素数が多い。

どのくらい多くなったのか、比べてみた。Xcdoe 7.1ではiPad Proのシミュレータがついてくるので、これを使って歴代のiPadの大きさを画素数ベースで比較してみた。

ipadpro

 

大きくなってるねー。初代サイズ(iPad 2)と比べると、隔世の感がすごい。

ついでに、iPhone系のデバイスも比べてみた。

iphone6splus

 

こちらも大きくなった。何気に、iPhone 6sとiPhone 6s Plusの差がすごい。デバイスサイズはそれほど変わらないけど、画素数で比較するとかなり差がある。

Apple WatchがiPhone 3Gにせまる画素数になっているのも驚きだ。テクノロジーの進歩がわかりやすく実感できる。

さてここで、大きい大きいといってもあまり実感できないかもしれないので、iPad ProをiMac 24インチと比べてみよう。

ipadpro_vs_imac

でかっ! でかいよこれ! 画面に収める気がまったくないだろ。

ついでに、Apple TVも比較してみよう。

appletv_vs_imac

こんなもんだ。十分に収まる。通常のTVにあわせて、1080pだからな。

こうやって比較すると、iOSデバイスの異様な画素密度がよく分かる。遠くに置くデバイスよりも、手元にあるデバイスの方が稠密にする必要があるんだね。

 

 

Swiftについて最初に思ったこと


swift-hero

WWDC 2014において、電撃的に発表された新言語Swift。その瞬間、Twitterの開発者TL上では爆笑が巻き起こった。まったく予想してなかったよ、うひー。

Swiftに関しては早速、言語仕様が公開(iBooks Store)されたりしている。それらはこれからすべてしゃぶりつくすとして、とりあえず基調講演が終わった時点での感想とかを書いてみたい。

Swiftのコンセプトは「Objective-C without the C」。Cベースではないモダンな言語である。その上で、CocoaとObjective-C runtimeを使うので、フレームワークのサポートも問題ない。ここだけ聞けば、夢のような話だよね。

Swiftの特徴として上げられていたのは、Modern、Safe、Interactive、Fast。これらを検証してみよう。

swift0

「Modern」に関しては、文法がモダンになった。これは言語仕様を見てもらえば明らか。昨今のトレンドを十分に取り入れたものになっている。Genericまであっててんこ盛り気味。Objective-Cにない仕様として紹介されたのが、名前空間(笑。聴衆は喝采。いかにObjective-Cが古臭かったかという例だな。

swift2

「Safe」は、変数が初期化される、配列のインデックスがチェックされる、ARCによってメモリが管理される、ポインタがない、と言ったとこだろう。初心者にとってはありがたいところだ。熟練者は、ほぼオートマティックにこれらは対処しているので、あぁ言語仕様レベルでサポートされるのね、というもの。

swift3

「Interactive」は、Playgroundと呼ばれる新しい実行環境を指す。基調講演のデモでも印象的だった、グラフを表示したり、アニメーションを動かしたりしていたものだ。確かにデモとしては見栄えがいい。でも、開発ワークフローを考えると、使うシチュエーションがあるかどうかは疑問だ。

swift5

で「Fast」なんだけど、これが悩ましい。普通に考えれば、C言語ベースからスクリプトになったら、実行速度は遅くなる。でもSwiftは、PythonやObjective-Cより速くなったと主張している。

swift1

まず考えられるのは、Swiftは純然たるスクリプトというよりは、コンパイルする言語であること。ビルド時か実行時か知らないが、ネイティブコードに変換する。これでPythonなんぞよりはバカっ速になる。

しかし、Objective-Cより速いとはどういうことか?基調講演では、ソート処理がObjective-Cより速いと主張していた。ソートはアルゴリズムが固まっているので、純然たる実行速度の差だ。Objective-Cのボトルネックとしてまず考えられるのは、メソッド呼び出し。objc_msgSendだ。Swiftはこれを使わないで、もっと効率的なメソッド呼び出しをやっているのでは?たとえば動的束縛をやめたとか?そうだったら、Objective-CではなくSwiftを使う積極的な理由が出てくる。

ソートのグラフでは、「Complex object sort」とある。つまり、複雑なオブジェクトで、比較するときにメソッドをいくつか呼び出す必要があるのかもしれない。だからObjective-Cでは遅くなってSwiftでは速くなるんだよ…というシナリオなら、納得できる。(Complexが複素数ってことはないよな?)

あと、既存のObjective-Cコードと混在もできるらしい。こちらで詳しく解説されている。これは朗報。

 

swift4

つまり、モダンな言語で、いまあるフレームワークをサポートできて、過去の資産も引き継げる。結論としては、乗り換えを検討する価値はある。もしかすると、絶対に乗り換えるべきかもしれない。では調査に入ります〜。

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を使い続けてみようと思います。

 

WWDC基調講演からiOS 7開発を読み解く


今年のWWDC基調講演も終了。ここ数年の開発者的見所と言えば、プレゼンの最後の方にチラ見させられる、追加された新機能の一覧。ここに、iOS 7でアプリが使える機能が書かれており、この情報を求めるためにWWDCに参加する。

これだけではどんなものなのか分からないけど、分からないなりに推測してみよう。

Push updates
バックグラウンドでアプリのアップデートが行われる事かな?

AirDrop from Activity sheet
AriDropはアクティビティシートからも使えるらしい。

Add to Reading List
Safariのリーディングリストに、アプリからブックマークを追加できるんだと思う。

Ranking-style leaderboards
ランキングスタイルのリーダーボード。いまもそうじゃね?

Background asset downloads
バックグラウンドでダウンロードが行えるらしい。現状、Store Kitでできるけど、それ以外もってことか?

Secure game scores
セキュアなゲームスコア?

3D map view
アプリでも3Dマップビューが使えるようだ。いままで使えなかった。

UI Dynamics
謎。これはいったい何?

MFi game controllers
MFiのゲームコントローラ。標準APIが提供される?

Inter-app audio
アプリ間オーディオ。いったい何?

Map snapshots
マップのスナップショットが撮れる?いままでは著作権関係でダメと言われていた。

Expanded Bluetooth LE profile support
BluetoothのLEプロファイルサポート。

Dynamic type size
ダイナミックタイプサイズ。これ何?タイプってことは、フォント周りってこと?

Guided Access API
アクセシビリティ関係のAPI?

Sprite Kit
謎。スプライトってことは、ゲーム関係?cocos2dみたいなものか?

Peer-to-peer connectivity
ピア・トゥ・ピアの接続。現状はBonjourでつないでいるけど、それ以外の手法も提供される? 追記:AirDropのことか!

Directions API
ルート案内のAPIか?

60-fps video capture
60 fpsでビデオキャプチャできるって。

Custom video compositors
カスタムのビデオ合成を作成できる?

New turn-based game modes
ターンベースゲームモード?謎。自分と相手が順々に実行する、ターンがあるゲームってこと?

iBeacons
謎。なにこれ?

New multitasking APIs
全アプリマルチタスク対応だが、新しいAPIも追加されるらしい。

Authenticated Game Center players
認証されたゲームセンターのプレイヤー?新しいフレンドリスト?

Barcode scanning
バーコードスキャン。おぉ。ついにこの機能が標準で搭載。

Geodesic polylines
測地線のサポート。Map Kitの機能だね。

Automatic configuration
自動的な設定。どの設定?

Improved map overlays
マップにオーバーレイさせるものの改善。アノテーションとか多角形とか。

Data proecttion by default
自身によるデータ保護。謎。

と、いったところ。こうやって見ると、ゲームとマップ関係の機能追加が多い事が分かる。マップは汚名返上すべくがんばっているのかね。

CGRectGetMinXと、rect.origin.x


きょうのはまりポイント

矩形であるCGRectの座標を取得するために、CGRectGetMinXっていう関数がある。CGRectの左端座標を取得するもの。これは、rect.origin.xを直接取得するのとは違うのか?

答え:違う。CGRectGetMinXは、CGRectの幅が負のときも考慮される。

rect = {{0, 0}, {100, 100}}の場合、
CGRectGetMinXは、0。rect.origin.xも、0。

それに対して、rect = {{0, 0}, {-100, 100}}の場合、
CGRectGetMinXは、-100。rect.origin.xは、0。

はまったのは、rect.size.widthを初期化していないCGRectに対して、CGRectGetMinXを呼んでいたとき。rectの幅を決定するのに、左端の座標を使っていた。これを、CGRectGetMinXで取得すると、rectが不定だったので、意図しない値が返ってくるときがあった。避けるには、widthを初期化するか、rect.origin.xを直接取得する。

はまったー。Analyzeかけると警告が出るから、変だなとは思ってたんだよ。まさか、負の幅もちゃんと考慮してくれているとは。っていうことは、CGRectGetMinXを使うと、rect.origin.xの直接参照より、ちょびっとだけパフォーマンスは落ちるんだな。

conferenceWithDevelopersで講演


conferenceWithDevelopersっていうカンファレンスが、今度の土曜日、2/23にあるんだけど。Webページによると、「conferenceWithDevelopersはiOS開発に携わる、すべての開発者に向けたカンファレンスイベントです。」ってことらしい。ちょっと漠然としてるよな。それはさておき、そこで1つセッションを担当します。

お題は『Dynamic Objective-C 2013』。Objective-Cをメインに話します。昔やってた連載『ダイナミックObjective-C』のノリでやろうかと。近年のObjective-Cに関する話題で、ランタイムよりの、比較的ディープな話をします。

23日の10:00スタート。場所は、六本木のGREEで。GREE行くの初めてだな。参加申し込みは、こちらから。まだ空席あるね。基本無料です。いや、課金もないと思うけど。

関係ないけど誰かがTwitterで、「タイトルの後ろにコロンがない」って言ってた。あぁなるほど、conferenceWithDevelopers:ってことね。引数は開発者の配列か。なら、completionブロックも付けたれ。ブロックの中身は懇親会ね。

PDFでの、文字の位置取得


独自のPDFライブラリ実装は、テキストの抽出は、ほぼ完了。

最後まで残っていたのが、XObjectからのテキスト取り出し。PDFにはXObjectってのがあって、そこに別のPDFストリームを入れる事ができる。CGPDFでXObjectにアクセスすると、CGPDFStream型で取得できる。でも、こっからテキストを抽出するには、スキャンする必要があって、それにはCGPDFContentStream型が必要。どうすりゃ変換できるんだー、とうんうんうなった結果、CGPDFContentStreamWithStreamという関数があることを発見。これで万事解決。

ここまできてやっと、縦書きだろうが、ToUnicodeマップがあろうがなかろうが、テキスト取り出せるようになった。

次。次はテキストの位置。これが分かれば、検索してハイライトさせることができる。

ってことで、テキストの位置を上書きさせたのが上の図。文字毎に矩形で囲んでみた。なんとなくはできているな。後は、細かい問題を詰めていけばいい。

PDFの縦書き部分からテキスト抽出


最近続けているPDFの読み込み処理。縦書きPDFのテキスト抽出ができるようになってきた。

スクリーンショットは、縦書き表示があるPDFを読み込んで、PDF Kitと独自処理実装でテキスト抽出したもの。PDF Kitでは文字はとれるものの文章の体をなしていなけど、独自実装ではちゃんと文章になっている。

まだ問題はあるけど、まあ目処がついてきたかな。実装は、OS XとiOSに対応。

Map KitにPOI検索のためのMKLocalSearchが追加


Appleが、Map Kitを拡張してPOI (Point of Interest)を検索できるようにした、と発表。POIってのは、駅とか、飲食店とか、学校とかいった、地図上にある地形情報じゃないタイプのデータのこと。

APIが拡張されて、MKLocalSearch、MKLocalSearchRequest、MKLocalSearchResponseといったクラスが追加された。これを使うと、位置の領域や文字列を指定して、それに対応するMKMapItemを取得できるようだ。いままでも、CLGeocoderを使って似たような事ができていたけど、もっときちんとサポートされたらしい。iOS 6.1から使用可能。

この機能は、日本とロシアでは非サポートらしい。そりゃそうだよなー。マップのデータは、地形データはともかく、POIデータの無茶苦茶っぷりは酷すぎるからな。ものすごくAppleに好意的に考えれば、現在日本のPOIデータは絶賛改修中なのでもう少し待ってね、というメッセージ。普通に考えれば、日本のPOIデータもうどうにもならなかいから非サポート、放置する、というメッセージ。

iOS 6の地図の酷さについては、先日ちょっと検証をしてみた。日系ソフトウェアっていう雑誌があって、いまそこで連載をしているんだけど、それの次号(4月号)の記事にまとめるために。酷い酷いと言われていたけど、改めて調べてみたら、まぁーやっぱり酷かったね。興味のある方は、そちらを読んでみてください。