uListeningのDeveloper’s Voiceを公開


HMDTで開発した製品の秘話を語る「Developer’s Voice」。今回新たに、「uListening」のDeveloper’s Voiceを公開。

uListeningは、英会話教材の第一人者アルクさんと一緒にやらせてもらっているアプリ。リスニング機能をメインに、iPhoneでの英会話学習をサポートするよ。

Developer’s Voiceでは、担当開発者がこだわりの機能の数々を語っております。ぜひ、ご一読を。

iOS 5 beta 7登場


iOS 5 beta 7登場。着々とバージョンアップを積み重ねているねぇ。GM到達も近いかな。

ここ数年のAppleの新OSリリースに関するスケジュールの遵守ぶりは素晴らしい。はっきりいって、本当に素晴らしいと思う。入れる、といった新機能がちゃんと入って、この辺りに出す、といった日付にちゃんと出しているから。

なんでだろうなと考えると、まず思いつくのはOSが成熟していること。OS XおよびiOSは同じカーネルを基盤として、その上に積み重ね続けている。すぐに新OSをホイホイ作りたがるどっかのマイクロソフトとは違う。ずっと使っていれば、成熟してバグも出にくくなる。

あと、これが重要だと思うんだけど、Appleは出来ないことを言わなくなった。出来たことだけを言うようになった。つまり、未来に対するホラを吹かない。その代わり、出来上がったものの発表を効果的にする。

Appleって、ビジョナリーの会社だと思われがちだけど、実はあんまり未来を語らない。メディアを使って、こんな素敵な近未来が来るよ、って喧伝することをしない。もちろん、考えていないわけではなくて、それを外にはなかなか見せない。みんなが知るのは、そのビジョンを実現した製品を発表するときだ。だから、吹いてしまったホラを実現するために四苦八苦することがない。出さなければいいだけのことだからね。

OSの新機能追加についても、ベータリリースという名目で世に出したときは、既にその実装は完了している、または目処がついている。あとは製品レベルまで仕上げるのと、開発者に使ってもらうための時間を確保するだけだ。だから大きな遅れがなくなったんだと思う。

この辺がやっぱりジョブズの考え方なんだろうなぁ。

iOS 4でUIPageViewControllerみたいなものを


iOS 5から、UIPageViewControllerというビューコントローラのクラスが追加される。一言で言うと、iBooksみたいなページめくりを実現してくれるクラスだ。これを使えば、誰でも簡単に書籍みたいなページめくりができる。

便利なんだけど、これを使っちゃうとiOS 4はどうするよ?って問題が出てくる。iOS 5専用にしちゃうという手もあるが、一世代前のOSくらいまではサポートしたいよな。

うーむ、と悩んだ結果、無いものは作れ!といういつもの結論に到達。ということで、iOS 4でも動くUIPageViewControllerの代替クラスを作った。APIはいっしょ。滑らかにページめくりしてくれる。

いまのところ、とりあえず動いている段階だけど、ソースコードが整理できたらどこかで公開するかも。

「iMandalArt – Developer’s Voice」を公開


HMDT Webページにて、「iMandalArt – Developer’s Voice」を公開しました。

HMDTのWebページは先週リニューアルして、うちで開発したプロダクトの紹介をするページを設けた。でも、ただ紹介するだけじゃつまんないよね、ということで、開発者による座談会を企画。どういったことを考えながらこのプロダクトを開発したのか?という生の声を届けたいと思ってます。

iMandalArtのDeveloper’s Voiceでは、マンダラート初期のHyperCard版やNewton版の画像なども公開。また、アプリの仕様やユーザインタフェースを、どうやって決めていくかというプロセスについても語ってるよ。iMandalArtに興味のある方だけでなく、アプリ開発のプロセスに関心のある方もぜひ。

ジョブズCEO退任


ジョブズがCEO退任の手紙を、Apple取締役と社員に送る

ついに来るべきものが来たという感じが。覚悟していたより早かったけど。

うちの会社、というよりも私個人の活動は、学生のときに初めてMacを触ってからずっとそれに支配されてきた訳で。いまの仕事をやれているのは、ジョブズのおかげといっても全然言い過ぎではない。

とりあえず思いつく言葉は、お疲れさまでした。かな。

MacでARMでUniversal Binaryの悪夢再び?


マイコミジャーナルより、『加速する「MacでARM採用」の噂、議論の存在をIntelが認める』。

マジすかー。PowerPCとIntelのUniversal Binary対応が終わったと思ったら、次はIntelとARMのUniversal Binaryすか。3つ同時にサポートすることは、共通して動くOS Xのバージョンがないから、考えなくてもいいな。

しかし、PowerPCからARMだったら、基本のエンディアンが同じだからまだ楽だったろうに。間にIntel挟むから面倒。ま、上位の方しか作らないアプリ開発屋は、あんまりエンディアンの影響受けないけどね。

iPhoneアプリでUDIDを使いたいケースその2


追記による注意:この記事は、はなはだしい勘違いに基づいていて、内容が破綻しています。修正しようにも、最も大事なところが勘違いしているためほぼ全部書き換えになってしまうので、しょうがないのでそのままにしておきます。最後に何が問題だったか書いておくので、そちらを参照して下さい。ということで、そのままの中身を信じないで下さい。

前回に続いて、iPhoneアプリでUDIDを使いたくなるケーススタディ。

あるiOSアプリがあったとして、自宅ではiPadの広い画面でゆうゆうと使いたい。通勤中はiPhoneで使いたい。それぞれのデバイスで、作業を別々に進めていく。どこかで同期を行う必要がある。こういった状況を考えよう。

まず大前提として、iOSのモデルは1アカウントに対して複数デバイスを運用する。これらのデバイスは、iTunesを通じてアプリおよび書類を同期できる。逆に言うと、複数デバイスで異なるデータを保持し続けることを想定していない。

もちろん、ほとんどの状況において、データの同期は善だ。iPhoneとiPadとで違うデータがたまり続けたら目もあてられない。そのためにiTunesを使ったり、同期のための独自サーバを立てたりする。iOS 5からはiCloudも提供される。

でも実際にアプリを使っていると、同期したくないデータも出てくる。たとえば、ブックビューワみたいなアプリを考える。iPhoneでもiPadでも同じ本棚を共有して本が読めるとする。このとき、iPhoneで呼んだ続きをそのままiPadで読みたい、という要求があるだろう。それと同時に、iPhoneで読んだ本はiPhoneで読み続けて、iPadではiPadのものを読み続けたい、という要求も発生するだろう。

現在の同期モデルだと、前者しかできない。すべての書類が同期されてしまうので、「前回読んだ本」を表すデータもただ一つしか存在できないからだ。となると、そのデータをデバイス毎にひも付けた形で保存しておきたいことになる。、、、UDIDさんの出番ですよー。

UDIDが使えれば、それをキーとしてデータを保存しておけばいい。生のデータを使うのが嫌であれば、ハッシュ値でも何でもとればいい。UDIDが使えないとなると、デバイスを識別する方法がなくなっちゃう。仮に自前のUUID作ったとしても、それがデバイス間で同期されたら意味ないし。

デバイスのモデル名を使うという方法があるかもしれない。UIDeviceクラスからは、@”iPhone”や@”iPad”という現在使っているデバイスのモデル名が取得できる。なるほど、これならiPhoneとiPadは識別できるな。、、、一人でiPad二台使ってたらどうすんの?

というわけで、やっぱりUDIDは欲しい。ま、これに関してはMACアドレスで代用は可能だけど。ネットにつながない「閉じた」アプリケーションであっても、複数デバイスを運用する限り、どのデバイス上で動いているか識別したい要求は存在する。

追記による注意:はい、どこが勘違いしていたでしょうか?「iTunesの同期によって、デバイス間の書類も同期される」というところです。実際は、同期されません。したがってUDIDを取得する必要もありませんでした。

もともとこの記事は、UDIDが必要になるケースって何があるかな?と考えて、複数デバイスを使い回しているときにUDIDを意識することがあるかも、というところから書いていきました。その結果、都合のいい勘違いを自分の中で作ってしまったようです。ということで、迷惑をかけた人がいたら、申し訳ありませんでした。

UIDeviceのuniqueIdentifierがdeprecatedに


iOS 5 beta 6で、UIDeviceクラスのuniqueIdentifierプロパティが非推奨(deprecated)になった。将来なくなるってこと。んな、beta 6まで進んだこのタイミングで言われても、という気はする。

uniqueIdentifierプロパティは、デバイス個体のID(UUID)を取得するためのメソッド。これを使うと個体を識別できる。値自体は特に秘密ではなくて、iPhoneをMacにつないで、iTunesを使って確認できる。個体識別番号っていうと、ちょっとでもIT系のニュースを聞きかじっている人なら、即セキュリティやプライバシーの問題を思い浮かべるよね。実際、UUIDを許可無しに流出させるアプリがあるってニュースもあったし、穴はふさいどけ、ってことなんでしょう。

開発側からすると、別にプライバシーを暴くためでもなんでもなくて、UUIDを使いたいっていうケースは存在する。それは実行環境の識別を行いたいから。もっと細かく言うと、デバイスの個体識別と、ユーザ識別がある。

デバイスの個体識別は、ユーザがアプリを複数のデバイス(たとえばiPhoneとiPad)で使っているとき、いまどっちのデバイスで動いているの?というのを知りたいとき。これをやるには、デバイスのUUIDが不可欠なんだよね。これが取れないとなると、MACアドレスを使うか、そもそも個体識別が必要ないように仕様を変えるしかない。

ユーザ識別は、いま使っているユーザを他のユーザと区別したいとき。これをやるにはUUIDは完全ではないんだけど、手軽なソリューションだった。

ユーザ識別をしたいときってのはIn App Purchaseが絡むときが多いので、そのAPIを使うこともできる。でも、あれを使うとユーザにApple IDの入力を頼むことになるんで、警戒されるんだよね。

まぁ、どっちにしろUUID以外のきちんとしたソリューションは考えておかなくちゃいけなかった訳で。今回は先延ばしにしていたものに対して、尻を叩かれたかって感じだ。 the domain shops

iPhoneアプリでUDIDを使いたいケースその1


iOS 5からUDID取得APIがdeprecatedになるぞ、ってのを受けて、どんなときにUDIDを使いたくて、その代替策はどうなるかというケーススタディ。

まずは、機能を制限解除型で購入するアプリ。あるアプリをダウンロードして、一部の機能に制限がかかっている。In App Purchaseで購入することで、その制限を解除することができる。これをどうやってアプリで管理する?または、悪意あるユーザのクラックからどうやって守る?

いちばん簡単なのは、NSUserDefaultsにフラグを設定すること。

[[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"purchased"];

って感じでね。簡単だけど、初期設定のplistを書き換えることで、簡単に破られてしまう。

じゃあってんで、何らかの固定文字列のハッシュ値を書き込むようにしたらどうだ?これなら、もとの固定文字列がばれない限り破られない。これは、一度だけ誰かが購入して、そのplistをコピーすれば破られてしまう。CFUUIDでUUID作っても、同じ。そのもとのUUIDをどこに保存するの?ってことになる。

そこで、UDID登場。UDID + 固定文字列のハッシュ値を使うようにする。これならこの値が流出しても、同じUDIDを持つデバイスでしか使えない。少しまともになった。

この手法の問題点は、機種変更すると使えなくなってしまうこと。フューチャーフォンとは違い、iPhoneでは機種変更したら前のアプリが使えなくなってしまう、というふざけたことは許されない。これは、In App Purchaseを使っているときは、リストアすることで対応できる。

別の手法を検討してみる。キーチェーンを使う方法。キーチェーンの中に、購入済みフラグを設定する。いまのところ、これは使える。

問題点は、キーチェーンの中に保存した情報は、アプリを削除しても残ること。制限解除キーが永遠に残るのは気持ち悪い。あと、キーチェーンって基本的には、ネットワークサービスのパスワードのように、ユーザが何度も入力するのが面倒な情報を保存しておくものだ。つまり、ユーザがすでに知っている情報が保存されているっていうのが前提。制限解除キーみたいに、ユーザから隠したい情報を入れておくのってどうなのよ、という気はする。もしかすると、将来AppleがiPhone版のキーチェーンアクセスみたいなものを出してきて、キーチェーンの中の情報を自由に見れるようにするかもしれない。そうなると、お手上げ。

また別の方法を。今回はIn App Purchaseで購入するというのが前提なので、購入したかどうかの判断をStore Kitを使って行うことができる。iTunesのサーバにアクセスして、購入履歴をリストアすることで判断する。

これの問題点は、ネットワークアクセスが必要になることと、毎回ユーザにApple IDの入力を求めることになること。これはめんどくさい。また、Store Kitへのアクセスをユーザの操作無しに行うと、アプリ申請時にリジェクトされる恐れがある。Store Kitのアクセスは、アプリを削除して新規インストールした、バックアップもなくしちゃいました、というときに留めておくのが無難。

ということで制限解除の許可には、ユーザを識別できて、かつ書き換え不可能なIDが必要なわけで、それにはUDIDは手軽な手段だったんだよね。そういったIDは、他にはApple IDがあるけど、これアプリからは全うな手段では取得できないし。ユーザからアクセス不可な領域ってことでキーチェーンを使うってことになるんだろうけど、なんか不安があるんだよな。

iOS SDK 5 beta 6登場と、新OSへ対応することについて


iOS SDK 5 beta 6が出たという事で、絶賛インストール中。iOS 5もbeta 6まで到達したという事で、対応を行うアプリ開発側も本格化してくる頃でしょう。

新しいバージョンのOSが出ると、アプリ側の対応は大きく分けて2つある。一つは、新しいOSの新機能を採用する対応。やっぱり新機能はいち早く取り入れたいよね。この手の対応は、beta 1が出たらすぐ検討に入る。イケルかも?と思ったら、開発開始。beta 1から正式版リリースまでは、だいたいいつも二ヶ月くらいなので、それに間に合わせるのが必須。

もう一つは、既存アプリの動作検証。新しいOS上で、前のバージョンとまったく同じように動いてくれるかどうか、確認する。この対応は、新OSのベータ番号が上がってくれないと進めらんないんだよね。ベータバージョンが浅いうちは、Appleの問題なのか、こっちの問題なのか、よく分からない事があるから。ある程度こなれてきてから、一気に行う事になる。

新OSが出たら、昔のアプリは動かなくなるものなのか?動かなくなるのは、Appleのバグなのか?まー、これが何とも言えない。Appleのせいとも、開発者のせいとも、言い切れない事もある。

新OS対応で厄介なのは、既存のAPIの挙動が変わっている事があること。ドキュメントにも書かれずに。これ、たまにある。もちろん、追加された新規APIや、既存のAPIの引き数が変化したりしたものは、ドキュメントに書かれている。開発者側もすごく気をつけて、チェックを行う。

でもたまに、APIは変化しないくせに、中身の挙動が変わっている事があるんだよね。推測では、APIは変更せずに、実装のソースコードだけ変えたんじゃないか、って考えられるもの。これがくせもの。API変更してないから問題ないだろう、と思っていたら、なんかしらないけど動かなくなっている。がんばって調べてみると、微妙に挙動が変わっていて、それが影響したりする。

これ、一概にAppleが悪いとは言い切れないんだよね。APIドキュメントに書いてある通りには動いているから。ただ、ドキュメントに書いていない範囲の動作が、前のOSと変わっている。だから、別に嘘はついていない。素直にAPIを使っているアプリでは問題ないんだけど、ギリギリといろんな機能を追加していると、問題が出やすい。そこんところの見極めは、いつも難しいね。

あと、もう一つ厄介なのが、後方互換性の確保。iOS 5対応するには、iOS 5 SDKでビルドしないといけない。そのバイナリが、iOS 4以前でちゃんと動くか?ってのを確認しなきゃいけない。基本的には、iOS 5の新APIを使っていなければ問題ないんだけど、これもたまに落とし穴があったりする。

iOS 5対応で遭遇した問題は、まだNDAの範疇にあるはずだから書かないけど、そのうち改めて書くかも。

そうそう。Undocumented APIを使っているってのは、論外だよ。そんなことして、OSのバージョン上がるたんびにいちいち時間取られるのはバカバカしい。App Storeで配信するアプリでUndocumented APIを使うのは、リスクは高いし労力も多いから割に合わない。 nimbus cloud . Ivseiranrini .