管理人@Yoski

3時間でiPhoneアプリをiPad対応にした

Fri, 20 Aug 2010 14:54:56 +0900

ま、実際には5時間かかったんですけどね。最初だったから。ちなみに審査は実質5日くらい。

これはツイキャス・ビュワーの iPad アプリ。というかユニバーサル・バイナリなのでiPhoneと共通です。

夕方5時からiPad化初めて、10時には完成、2時間で試験パターンまわして深夜0時に申請、という流れです。

自分メモですけど、何かの参考に。
（ちなみに内容的には最低限のiPad対応、かと思いますー）

【準備】

実はこれがすごく大事。iPhone アプリを作るときに以下のことに注意して作ります。

- 画面は左右ぐるぐる回転できるようにしておく
- ぐるぐる回転したときに、frame = CGRect なんて使わなくていいように Interface Builder のアラインパラメータを綺麗に設計する
- なので、画面構成要素は極力コードで動的にじゃなくてXIBで作成する。NavigationControllerくらいは動的作成でも影響ないけど。
- 基本、ステータスバーは表示した方がいい。(iOS4になってからゲーム以外でステータスバー隠すのはNGだと思ってるんだけど）
- 設定メニューなど、一貫したグループのXIBファイルは分けておく（超重要）。

で、iPad化します。手順は簡単で、

1. Targets から Project を選択して「Upgrade Current Target for iPad」を選択
2. Universal アプリを選択して OK

すると、Resources-iPad ってのができるので、中身を確認します。
Main XIB ができてるはず。ただし画面サイズはiPhone サイズ。

で、上記の iPhone 注意点を守ってつくっていれば、これで iPad アプリ、ほぼ完成しているはずです。

なにしろ iPhone 用の XIB がそのまま iPad でも使えるので。
しかもちゃんと設計していれば画面サイズが変更されてても大丈夫。IB万歳！

ただ、やはり個別にちゃんと設計したいよね、ということもあるかと思います、ていうかそうすべきなので IB の File メニューから

- Create iPad Version

を選択します。すると新しい XIB が一つもらえて情報全部コピーされているはずです。
こいつを適当な名前つけて保存して、Info.plist の Main nib file base name (iPad) に新しい XIB のファイル名を指定すればOKです。

あとは Project > Edit Project で Targeted Device Family を iPhone/iPad に変更してください。

コレで完成です。

いや、もっとなんかあるっしょ・・・ということで、詳しくは iPad Human Interface Guideline (日本語) を読んでいただくとして、一番大きいのは

- ナビゲーションで全画面移動じゃなくて PopOver に変更したい！

というものかと思います。上の画面の右側に PopOver してるやつね。

これはドキュメント読んでもらってもいいんですが、めちゃ簡単に使えます。
今まで NavigationController に push してたところを

UINavigationController* nav = [[UINavigationController alloc] initWithRootViewController: 表示したいController];
[nav setToolbarHidden: NO];
[nav setNavigationBarHidden: NO];
// これに初期コントローラーを登録してPopup表示
self.mPopoverController = [[UIPopoverController alloc]initWithContentViewController: nav];
[self.mPopoverController presentPopoverFromBarButtonItem:起動元のButtonItem
permittedArrowDirections:UIPopoverArrowDirectionAny animated:YES];
[nav release];

って変更すればOKです。
なお、mPopoverController を self. で保持している理由ですが、（これは保持してなくてもいいんですが）ユーザーアクションじゃなくてプログラム的にPopOverを消去したいときにポインタ持ってないとPopOver消せないので保持しています。

ツイキャスビュワーの場合、設定メニューとかが PopOver になってるんですが、これ、猛烈に便利な点は横320pxデフォルトなんで、iPhoneのXIBリソースがそのまま使えます。

ツイキャスビュワーだと設定メニューは XIB分けてるので、それをそのまま流用すればおｋ。つまり、XIBもコードも一切いじることなく、テストもほぼ不要で PopOver の設定メニューが完成します。

あ、あとちょっとはまりそうなところというかポイントだけ。

【iPad化にあたり】

- ステータスバーを隠すとか、ナビゲーションバーを隠すというギミックは極力使わない。
(ステータスバーは、画面の回転とアラートの向きがずれる可能性があるし、ナビゲーションバーは再表示したときにうまく機能しないことがある）
- ヒューマンインターフェースGuidelineは、ガイドラインなので、あまり真剣に悩まない。ボタン類とか、画面上部推奨されてるけど明らかに下にあるほうが（親指操作できるし）便利っしょ。
- PopOver使うと、下の画面がみえた状態になるので更新タイミング注意。つまりiPhoneだとViewが消えたり現れたりする時点で画面更新しておけばよかったけど、PopOver使ってる場合、たとえばPopOver内でログアウトしたら元のビューの表示もその時点で「ログアウト状態」に変更する必要がある、など。

あ、あと最後に用意する画像。ちょい増えましたのでね。

【アイコン画像】

29x29 (設定メニュー: オプション)
58x58 (iPhone4 設定メニュー: オプション)
57x57 (iPhone)
50x50 , 72x72 (iPad)
114x114 (iPhone4 - ファイル名に @2xつける)
512x512 (AppStore)

【起動画面】
Default.png = 320x480
Default@2x.png = 640x960
Default-Portrait.png = 768 x 1004
Default-Landscape.png = 1024 x 748 (※微妙に20px少ないのがポイントです）

と、これだけ用意しておけばおｋ。

あとは Info.plist の Supported interface orientations (iPad) をちょろりといじればいい感じかと。詳しくは iOS Application Programming Guide: Build-Time Configuration Detailsにて。

以上、ご参考までに。

あ、よろしければ以前の記事もあわせてどーぞ。
iPhone アプリを iPad 対応にする方法（プログラミング編） : 管理人@Yoski

※ユニバーサルアプリにしたら、審査の開始も承認も早かったような気がします！

フレッシュリーダー終了のお知らせ

Thu, 05 Aug 2010 21:49:53 +0900

お知らせが遅くなってしまったのですが、フレッシュリーダーの開発を終了することにさせていただきました。

- 一部製品・サービス終了のお知らせ - サイドフィード

フレッシュリーダーについては、来年9月末まではサポートを継続しますので、今お使いいただいている方はあと１年間は普通に使っていただけます。
その後は自己責任でお使いいただければと思います（クローラーオプションもその段階で停止します）。

※その他製品・サービスも終了するのですが、フレッシュリーダーの影響が一番大きいかと思いますので代表して。

終了の経緯なのですが、（細かい理由はいくつもありますが）とりまとめていうと事業集中です。

これまで名無しベンチャーがコストをかけずに目立つために様々なサービスを連発してきましたが、そのフェーズも終わり、現状すべてのサービスのクオリティを保つことが難しくなってきました。

フレッシュリーダーについても、みなさまからいただく要望も多くある中、バージョンアップも満足に行えず心苦しい状態が続いていました。

いろいろな選択肢がある中、中途半端に続けるより方針を明確にすることが重要ということで、このタイミングで製品・サービスの終了を案内させていただく次第です。

ということで、これまで支援いただいたユーザーのみなさま、ありがとうございました＆終了にともないご迷惑おかけして申し訳ありません。

なんか一時代の終了ということで寂しい限りですが、個人的には次のステップに上がるための手段ととらえています。これから第二幕頑張っていきたいと思いますので引き続きどうぞよろしくお願いいたします。

----

ちなみに起業したときのテーマは「ブログ・RSS・SEO」だったのですが、今のテーマは「モバイル・ソーシャル・リアルタイム」です。いやぁ、、、まだ終了すべきサービスが残っていますね・・・（続く

iOS4のバックグラウンド処理とiPadの微妙な関係

Thu, 08 Jul 2010 20:04:10 +0900

iOS4 からマルチタスクがサポートされ、これにより現在申請中のツイキャス最新版では、「バックグラウンドでライブ配信」ができるようになります。

こんな感じでライブ配信中もブラウザ見たりできますよ、と。

iOS4なにそれ？美味しいの？って思ってたんですが、バックグラウンドで配信できる便利さは凄いです。
初めて iOS4 バンザイ！って思いましたｗ

で、これを実現するためのメモを残しておきます。ま、大したことないんですけどね。（ていうかちゃんと審査通るかどうかが心配・・・）

あ、ちなみに、iOS4 だとアプリが終了せずにタスクトレイに残るからバッテリーの減りとか大丈夫？という話しもあるんですが、

- ステータスバーが赤くなる（上の画像のような）ケース以外では CPU は使われないから大丈夫
- ただ、メモリは使われる。これは古いものから順に押し出される

ということで、あまり心配する必要はありません。
ただ、アプリが終了せず継続されるということで

- メモリリークしてるようなアプリは大丈夫？

という疑問が残ります。で、メモリリークしてるアプリについては、起動するたびに使うメモリが増えてしまうので最終的には「残念」な結果になります。

メモリリークしてるから使ってはいけないアプリ、的なリストがあればいいんですけどね・・・現時点では開発者を信じるしかありません。

■バックグラウンドでプロセスを残すには

いくつか方法があるのですが、一番多いパターンは「音楽を再生または録音」しているケースです。

この場合は

- Info.plist のマルチタスク記述に App Plays Audio をセットするだけ

で対応が完了します。驚くほど簡単で便利。

で、これによりアプリが切り替わっても（音楽の再生または録音中なら）バックグラウンドで処理を続けます。ただ、カメラなどは落とされるので、ツイキャスでもバックグラウンドで処理している場合は「音声のみ」の配信になります（映像はストップ）。

■音楽はどうやって再生すればいいのか

で、問題はどうやって音楽を再生すればいいのか、です。

WWDCの資料とかでは AVFoundation → AVSession を使うことが推奨されていますが、これを使ってしまうと iPad で動きません (OSが古いから)

で、レガシーな AudioQueue または OpenAL を使うことになります。
ポイントは、AudioQueue や OpenAL を使っても「バックグラウンド動作は有効」になるという点ですね。なーんだ、AVSession 使わなくてもよかったんだ、と。
（デバイスの処理をみてるんですかね）

■iPad の微妙な関係

さて、そこでずぼらな私は「iPad は iPhone シミュレーションモードで動けばいいや」と思うわけです。

そこで、iOS4 でアプリを開発し、Deployment OS を 3.2 と指定します。
これにより iPad では動くけど iOS4 以前の iPhone じゃ動かないからめでたしめでたし！

・・・・と思ったのですが、残念ながら、この設定では Apple がアプリを受け付けてくれません。
iPhone 用のアプリなら、3.1 か 4.0 を Deployment Target に指定しろ、というわけです。
でも 4.0 を指定してしまったら iPad では動きません。

むむむ、、、、ということで仕方なく 3.1 を指定し、OS のバージョンによって処理を振り分けるコードを追加することになります。
まぁ、冷静に考えてみれば iPad の iPhone モードだと OS は 3.1.3 なわけで、3.2 で提出できたとしても iPad では動かないんですけどね(実は純粋な 3.1.3 じゃないんだけど)。

まぁ、iPad で動かしたいなら、ちゃんとユニバーサルバイナリにしなさい、ってことなんでしょうかね。

と、そんな感じで iOS4 結構便利。

ツイキャスも、七夕の日に申請したので、うまくいけば１週間ほどで公開されると思います。

そしたら試してみていただければ、と思います＞iOS4なみなさま。

ツイキャス(ライブ)

ツイキャス(ビューワー) (こっちはまだマルチタスク対応してません)

※バックグラウンドで動作している最中に、他のアプリが音楽の再生や録音を開始するとバックグラウンドで動いているアプリは停止してしまいます。これは iOS4 の仕様ですので、どうしようもありません。なお、ツイキャスではこの状態でも約20 秒以内にアプリに戻ればライブ配信を継続することができるようになっています。

Windows から Mac に乗り換えたときのメモ

Thu, 08 Jul 2010 15:38:17 +0900

先月、ついに Windows から Mac に乗り換えたので、その時のメモ。
もはや既出感満点で意味はないと思うのだけど・・・万一、またやらなければいけないときのために・・・完全に自分メモです。

■もともとの環境

- Windows マシンに VMWare Server いれて CentOS
- Mac は iPhone アプリ開発用。

これらを統合してひとつの Mac にしたい！

■手順

- Macの移行は TimeMachine 使ってたので驚くほど簡単。まずこちらから。
- BOOTCAMP で Windows 用パーティション作成する。
- BOOTCAMP に Windows 入れる
- Mac パーティション分割して CentOS 用のパーティション作る
- CentOS コピーして完了(VMWare Image)

■ポイント箇条書き

- BOOTCAMP いれることで、Windowsのライセンス問題はクリア
- OEM版だと、結局 Microsoft に電話することになるんだけどパッケージ版なら電話不要
- で、Mac で Windows 使うために VMWare じゃなくてフリーの VirtualBox を選択。快適。
- VirtualBox でも BOOTCAMP のWindowsイメージをそのまま Mac 環境で起動させることができる
- ただし、起動時には BOOTCAMP ドライブの eject と chmod 666 /dev/disk0s4 (かな、環境により異なる) が必要になる
- CentOS は、さらに Mac 用のパーティションを分割して、そこに作成。これにより Windows を BOOTCAMP で起動したときにも CentOS 動かせるようになる(Macの領域は Winから参照できない)
- CentOS の領域は FAT で作成し、Windows 側で NTFS に変換するのが便利
- Snow Leopard から NTFS 読み書きできるようになった
- なお、３番目のパーティションは先につくってしまうと BOOTCAMP いれられなくなるので注意。
- ちなみに VirtualBox では VMWare のディスクイメージをそのまま起動できるので、VMWare のファイルコピーするだけでOK
- Windowsはシステム移行ツールでさくさくって移行、ってのは期待薄。結局うまく移行できずに手動で全部手動セットアップ
- Windows のフォントはそのまま Mac に移行できるからドロー系ツールの移行もオッケー

■その他、Tips

- キーボードのバインディングは KeyRemap4Macbook 最強。
- Mac には DEL と BS のキーがない（deleteのみ) なので、DVD の Eject ボタンを DEL に割り当てる。
- Windows 側は AppleKbWin いれておけばキーバインディングなんとかなる。
- Windows と Mac で日本語変換統一したかったので、両方でつかえる Google IME いれる

■移行してから思ったこと

- Windows も使えるからいいや、って思ったけど、移行したら「いかにこれを Windows じゃなくて Mac で処理するか」ってことに思考が傾く。
- メーラーとか、最初は Windows で使ってたけど、不便だからすぐに Mac のメーラーに移行した。
- Virtual Box や VMWare で動かす Windows、単発アプリなら使えるけど、ウィンドウが増えてきたらもう全然重くてダメ。
- いざというときは BOOTCAMP で Windows 起動すればいいや、って思ってたけど、そんな面倒なこと絶対しない。
- Mac はテキスト編集系のいいアプリが「無料」でころがってなくて苦労
- Windows ７意外によくできてるよね？
- でも、Mac のこのスリープから最速で復帰するあたりが最高すぎてWindowsには戻れない

という感じでしょうか。って全然自分メモで何の役にもたたないと思いますが、一応残しておきます。

あ、ちなみに Mac は Mac Book Pro 15" SSD 256GB モデルです。
SSD じゃなかったら Windows 起動すらしなかったかも。

[iPhone][AVFoundation] AVCaptureOutput のメモ

Sat, 03 Jul 2010 20:46:53 +0900

自分専用メモなんで、意味不明かと思いますが是非スルーの方向で。

iOS4 からカメラのフレームバッファをキャプチャすることができるようになったんですが、その取扱がちーと面倒。

で、たまったバッドノウハウ忘れないようにメモ。

- kCVPixelBufferPixelFormatTypeKey

これは基本 kCVPixelFormatType_32BGRA が扱いやすい。iPhone 3G でもOK。あと使うのは YUV ですかね。420v ならモノクロ・フレームバッファも取りやすい。

- (void)captureOutput:(AVCaptureOutput *)captureOutput didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer fromConnection:(AVCaptureConnection *)connection

指定したフレームレートベースでこのdelegateメソッドが呼ばれる。すげー便利。
比較的安定して呼び出し時間を守ってくれるので、あとはパフォーマンスとの戦い。

これは GCD のキューから呼び出される形となるので UIKit と連携するケースなどは別途 MainThread に情報を渡してやる必要がある。
つまり中間バッファが必要。

が、iPhone 4 だと 1280x720 の BGRA とかまでサポートしてるので、ピクセルバッファだけで 3MB を超えてしまう。

で、さて、このピクセルバッファを非同期で処理するためにどっかに格納しようかと思うんだが・・・ここでいろいろ問題発生。

ピクセルバッファは CVPixelBufferRetain で Retain できるので、とりあえず Retain しとけばいいや、と思いきや iPhone 3G さんがそれを許してくれない。
具体的には、Video の PreviewLayer のフレームレートが極端に落ちるなどの影響がでて結構耐えられない状況になる。

あ、ちなみに Retain する前に CVPixelBufferLockBaseAddress でロックも必要です。

じゃぁ、というわけでピックセルバッファをコピーすることになるんだけど、late copy するために vm_copy かけときゃいいや、と思いきや iPhone 3G さんがそれを許してくれない。
具体的には iPhone 3G さんだけ vm_copy 動かない。

まじで！？memcpy すんの？iPhone 3G 捨てるか？という選択に迫られるわけです・・・。

ただ、どの処理にせよ、iPhone 3G のサポートしている 400x304 というピクセルバッファを処理するのに 0.05秒はかかる。10fps 出すにはすべての処理を 0.1 秒以内に収めないといけないので、バッファをごにょごにょ処理するのは避けたいところ・・・

しかも、iPhone 3G だけは BGRA のアルファチャンネルをサポートしてないらしく、カラースキームにアルファチャンネルを指定すると BitmapContext で CGImage に戻せないという問題もあり、うーむ、なんだかなぁ、と。

と、そんなわけで、超ローテクな方法でしか対応はできないので、できるだけこの dispatch_queue の中で処理を完結させるように書かないとね、という結論でした。

あぁ、完全に意味不明だけど、書いとかないと自分で同じ間違い繰り返しそうだったのでメモのこしときます。。。

あ、その他メモ：

- Front カメラと Rear カメラは同時には起動できない
- フレームバッファをキャプチャしながら同時にムービーを録画、もできない
- その回避策として AVWriter があったんだけど iOS4 beta3 で削除されちゃったからもう無理
- H.264エンコーダー、ハードウェアで対応してるはずなんだけど API は公開されてないから使えない
- 別プロセスで音楽を流すのはできるんだけど、マイクを拾い出した瞬間、音楽配信してたプロセスは強制終了される。

それと、超マニアメモ：CVPixelBufferRef に入っている情報。結構いろんな情報が取れる(iPhone4)

< CVPixelBufferRef 0x1e3d60 width=480 height=360 bytesPerRow=1920 pixelFormat=BGRA attributes={type = immutable dict, count = 1,
entries =>
1 : {contents = "PixelFormatDescription"} = {type = immutable dict, count = 7,
entries =>
0 : {contents = "CGBitmapContextCompatibility"} = {value = true}
1 : {contents = "FillExtendedPixelsCallback"} = {length = 12, capacity = 12, bytes = 0x000000004594413300000000}
8 : {contents = "BlackBlock"} = {length = 4, capacity = 4, bytes = 0x000000ff}
9 : {contents = "CGBitmapInfo"} = {value = +8196, type = kCFNumberSInt32Type}
10 : {contents = "CGImageCompatibility"} = {value = true}
11 : {contents = "PixelFormat"} = {value = +1111970369, type = kCFNumberSInt32Type}
12 : {contents = "BitsPerBlock"} = {value = +32, type = kCFNumberSInt32Type}
}

}
propagatedAttachments={type = mutable dict, count = 4,
entries =>
1 : {contents = "MetadataDictionary"} = {type = immutable dict, count = 29,
entries =>
0 : {contents = "ExposureTime"} = {value = +0.08316987826086956470, type = kCFNumberFloat64Type}
1 : {contents = "ISOSpeedRating"} = {value = +419, type = kCFNumberSInt64Type}
3 : {contents = "Fnumber"} = {value = +2.79999999999999982236, type = kCFNumberFloat64Type}
4 : {contents = "sensorDGain"} = {value = +256, type = kCFNumberSInt64Type}
5 : {contents = "AGC"} = {value = +1464, type = kCFNumberSInt64Type}
6 : {contents = "AEAverage"} = {value = +169, type = kCFNumberSInt64Type}
7 : {contents = "AFStable"} = {value = +1, type = kCFNumberSInt32Type}
8 : {contents = "TemporalMotion"} = {value = +237247, type = kCFNumberSInt64Type}
9 : {contents = "ShutterSpeedValue"} = {value = +3.58779506948601589755, type = kCFNumberFloat64Type}
10 : {contents = "FullyExposed"} = {value = +1, type = kCFNumberSInt32Type}
11 : {contents = "ExposureBias"} = {value = +0.0, type = kCFNumberFloat64Type}
12 : {contents = "AWBRGain"} = {value = +133, type = kCFNumberSInt64Type}
13 : {contents = "OverflowOccurred"} = {value = false}
14 : {contents = "FocalLength"} = {value = +3.85000000000000008882, type = kCFNumberFloat64Type}
15 : {contents = "AWBGGain"} = {value = +64, type = kCFNumberSInt64Type}
16 : {contents = "ApertureValue"} = {value = +3.00000000000000000000, type = kCFNumberFloat64Type}
17 : {contents = "SensorID"} = {value = +13904, type = kCFNumberSInt64Type}
18 : {contents = "SNR"} = {value = +35.13407451801569436611, type = kCFNumberFloat64Type}
19 : {contents = "OneFrameAEMode"} = {value = +1, type = kCFNumberSInt32Type}
20 : {contents = "CurrentFocusPosition"} = {value = +186, type = kCFNumberSInt64Type}
22 : {contents = "AEStable"} = {value = +1, type = kCFNumberSInt32Type}
27 : {contents = "ispDGain"} = {value = +256, type = kCFNumberSInt64Type}
28 : {contents = "AWBBGain"} = {value = +198, type = kCFNumberSInt64Type}
30 : {contents = "FocusScoresArray"} = {type = immutable, count = 5, values = (
0 : {value = +4835, type = kCFNumberSInt64Type}
1 : {value = +5044, type = kCFNumberSInt64Type}
2 : {value = +5486, type = kCFNumberSInt64Type}
3 : {value = +5670, type = kCFNumberSInt64Type}
4 : {value = +189347, type = kCFNumberSInt64Type}
)}
33 : {contents = "AFStatus"} = {value = +2, type = kCFNumberSInt32Type}
34 : {contents = "AELimitsReached"} = {value = +0, type = kCFNumberSInt32Type}
37 : {contents = "FocusPeakSumArray"} = {type = immutable, count = 5, values = (
0 : {value = +8103, type = kCFNumberSInt64Type}
1 : {value = +8217, type = kCFNumberSInt64Type}
2 : {value = +8342, type = kCFNumberSInt64Type}
3 : {value = +8461, type = kCFNumberSInt64Type}
4 : {value = +24617, type = kCFNumberSInt64Type}
)}
38 : {contents = "BrightnessValue"} = {value = -0.40476958246484440185, type = kCFNumberFloat64Type}
39 : {contents = "AWBStable"} = {value = +1, type = kCFNumberSInt32Type}
}

4 : {contents = "CVImageBufferChromaSubsampling"} = {contents = "4:2:0"}
5 : {contents = "CVImageBufferChromaLocationTopField"} = {contents = "Center"}
6 : {contents = "CVImageBufferChromaLocationBottomField"} = {contents = "Center"}
}
nonPropagatedAttachments={type = mutable dict, count = 0,
entries =>
}
iosurface=0x0>

WWDC 2010 に参加してきた率直な感想

Mon, 21 Jun 2010 14:56:07 +0900

さて、今月初めのAppleのイベント、WWDCに参加してきたので、そのメモを残しておきます。内容についての記述はほとんどありませんｗ

で、そもそもWWDCに参加する目的なんですが、「一度行ってみるか！」というくらいな感じでした。
もちろん、アプリの審査に不明瞭なことが多すぎるので実際に聞いてみて感じを得ようとか、あわよくばAppleの中の人と仲良くなっていろんな問題を先回りして質問できるパイプを作りたい、という目的もあったのですが、、、そもそもメインの渡米目的別のところ（カリフォルニアの運転免許証を更新したいとかｗ）にあったので、WWDCはついでといえばついででした（日程がドンピシャじゃなかれば行ってなかったかと）。

何しろ初日の Steve Jobs のプレゼンの日も、会場入りする人の列が終わる（最後尾が入るまで待って）から入館した上に、自分が Steve Jobs のいない控え室に通されたことも気づかずに（あふれた人たちは控え室でライブ放送を見る仕様・・・）「Jobsマダー？」とかふざけたことを思っていたくらいですから・・・

で、いきなりまとめですが、私の感想としては

- WWDC は想像以上に内容が盛りだくさんで有意義ではあった
- でももう当面参加することはないと思う

という感じですかね。

内容については、なにしろ iPhone 4 と iOS4 が発表され、OSもハードも新しくなり、しかもそのリリースが3週間後とかまったくもってついて行けない状態からのスタートでしたので、WWDCに出ることで他のデベロッパーに比べて２週間ほど早くいろんな情報を収集できるのは、早く新しいバージョンのアプリをリリースできるという意味においては有利だと思います。

ですが、そもそも実機がないと試せないことも多く、結局 iOS4 対応を iPhone 4 が出るまで見送るという判断をしたので(*注1) 私にとってはそれほど有利になるものではありませんでした。

サブ目的の、Appleエンジニアに実際の問題を相談するというものですが、これは WWDC のセッションと並行して「ラボ」というものが用意されており、このラボに参加することで個別の問題をエンジニアと相談することができるようになっています。

で、私も何時間かエンジニアに相談事リストをぶつけていろいろ聞いたのですが・・・これがまた微妙といえば微妙で、

- エンジニアはたくさんいるけど、正確なアドバイスをくれるのは「エバンジェリスト」と呼ばれるコアな人のみ
- コアな人なかなかつかまらない上に、本当に具体的な問題をピンポイントで聞かないといけない
- で、多くのエバンジェリストな人はDeveloper Forumでも答えてくれたりするので、そちらで用が足りることも多い。
- ていうか、エバンジェリストじゃない人と話すなら Developer Forum で聞いたほうが正確な答えがもらえるぜ

というのが私の感想。まぁ、3G回線特有の問題とか、ライブストリーミング特有の問題とか、実際に「実験」してみないとわからないことが多いので、質問が厳しいといえば厳しいのですが・・・。

そして、セッション。

実際、セッションは大量にあり、面白いものからそうでないものもいろいろありますが（プレゼン自体は全体的にかなりレベル高いです、てかなんでみんなこんなにプレゼンうまいの？）、多くは実際のコードを用いて説明してくれます。

巨大スクリーンに映してくれるのですが、会場もドでかいため、コードが見えないことも多く・・

しかも２週間後には WWDC の全セッションは iPhone デベロッパー全員に Podcast で配信されるというなんてこったい（知らなかったぜ）！みたいなものもあり、正直現地のセッションにでなくても Podcast 見ている方が情報も正確だし必要なとこ以外はスキップできるから良くね？と思いました。（なお、新しい開発環境 XCode4 についてはWWDC出席者にしか情報配布されてません。が、これはまぁ、未完成過ぎるのでどうでも・・・）

ということで、生Jobsを見るために WWDC に参加する！というのもアリかとは思いますが、私にとっては「来年はもういいかな」いうのが私の率直な感想だったりします。

まとめると：

- セッション -> Podcast で十分
- ラボ -> Developer Forum で十分
- Jobs -> 元気そうでよかった

・・・われながらひどいまとめだｗ

＃もちろん、人それぞれ目的があると思うので、個人的な感想ですけどね。。。

あ、それから感じたこと、もうすこしだけ箇条書きで。

- WWDCに参加しているというのに iPhone 4を見ることも許されなかった。これはたまらんｗ
- エンジニア向けのセッションが多いわりには年齢層が高めなのがとても気になった。
- まぁ、これだけのものなら15万円するわなぁ、とも思うけど、だんだんApple信者としてのお布施みたいに感じてきたｗ
- Google なら値段 1/10 でおみやげとして全員に iPhone 4 くれるのにｗ

と、そんなところです。

ま、何かの参考になれば。というか iPhone 4 いつ手にはいるんだろう・・・iPhone 4 ゲットしないとまったく開発できないんだけど・・・。ぐおー

----
(注1)
NDAに抵触しないと思うので書いておくと、iPhoneアプリ、同じソースコードでも新しい iOS4 のコンパイラでコンパイルすると、旧バージョンとの互換性をなくし、新しいバージョンのアプリとして動作します。
つまり、グラフィック系(CoreGraphics や OpenGL)を使っているアプリは適切にコードを書きなおさないとiPhone 4の高精細ディスプレイで正しく表示されなく可能性がでてきます。

iPhone 4の高精細ディスプレイでも正しく表示されることを保証する方法は現時点では３つ。

1. iOS4でコンパイルしない（下位互換性が保たれ iOS4 や iPhone 4でも正しく表示される）
2. iOS4でコンパイルして iPhone 4 の実機でテストする（現時点では無理）
3. 男は度胸（女性でも可）でシミュレーターを信じる（ただしカメラや公認非公開APIを使っていると動作しないから死亡）

ということで、私は iPhone 4 の実機を手にするまで iOS4 版はリリースしないという結論に達しました。iPhone 3GS で動いても iPhone 4 で動かない可能性は大いにあるので。

はやく iPhone4 が欲しい・・・・！

隣席の女性が泥酔して(私が)プレミアシートにアップグレードされた話

Thu, 17 Jun 2010 05:17:31 +0900

ちょｗ、Vaio ⇒ Mac 移行のために整理してたら変なメモでてきたｗ

大した話しじゃないんですが、なんとなく晒しときます。
（一年程前のメモです）

---

サンフランシスコからの帰りの飛行機、最近の傾向らしいのですがビジネスシートはガラガラ、エコノミーシートは満席という状態で、私はエコノミー三人がけの窓側。(いつも窓側がお気に入り)

で、隣席（つまり3人がけの真ん中）にアメリカ人の女性（メガネっ娘風）がやってきたのですが、着席するなりケータイで話しだして（もちろん厳禁）アテンダントに注意されてもなかなか電話を切らないという状態からスタート。

これはちょっと楽しめるかもと思いながら、離陸時は（いつもそうなんすが）私はそのまま寝てしまい、小一時間で起きてみると隣席はすでにワインをぐいぐいやってました。
ちなみにこの時点でまだ機内サービスは始まってませんｗ。

食事までの間、Mac でなにやら作業しはじめたのですが、チラりと目に入ったデスクトップのカオス状態がwktk感を高めてくれます。

そしてドリンクサービスのカートが通るたびにワインのボトルをゲットして、かなりいい感じにできあがってきたようで・・・。
＃ボトル4,5本くらいですかね。ごくごくいってました。

で、寝始めた頃には靴履いたままの足を（私の）前席のシートの上に乗っけるという荒業まで繰り出す状態にw。

個人的にはこのありえない状況を何故か微妙に楽しんでいたのですが、しばらくするとアテンダントが注意しに飛んできました。が、例のごとく聞く耳持たず・・・。

というか、本当に聞こえてないみたいで、「行儀悪いって言ってるよ！」と教えてあげるとすんなり小さく丸まって寝だしました。

が、その後ふらりと立ち上がりどこかに行くこと15分くらい。
・・・アテンダントが「この人、勝手にビジネスクラスで寝てたんですよ！！！」とメガネっ娘を連行してきましたｗ

この時点でさすがにアテンダントが集まりだし、なんやら賑やかになってきました

座席や床もワインでどほどぼに濡れている状態であることが判明し（道理でワイン臭かったわけだw）、隣の人（通路側の人）からも素行の悪さに対する苦情が出ていたようで・・・（足上げ攻撃はもちろん、荷物の領域侵犯とかフリーダムな状況でしたから）。

で結局アテンダントから私たち（私と通路側の方）にプレミアムシートへのアップグレードの申し出がありました。

私はなんか状況を楽しんでいたのと、あと3時間だけだったので、もうこのままでいいかな、と思っていたのですが強く薦められたので申し出を受けることに。

ただ、なんか興味でてきたので、そのときにメガネっ娘にいろいろと聞いてみました。
（あまりの開放的さ加減に、一人で日本に行くなんてありえんと思ったので…）

曰く、日本はストップオーバーで、最終目的地はインドネシアだとのこと。なんでもインドネシアでサーフィンの大会があるらしく、彼氏がその一選手（国際的に有名な人らしい・・知ってる？って聞かれたけど全然わからない…）なのだとか。
なんか話を聞いて破天荒さに妙に納得。

ということで、この状況を説明しながら（なんか私が説明するのおかしくないか？）前方のシートに移動しました。

で、そこからの航空会社の対応がなんとも丁寧で、何人ものアテンダントがお詫びにこられ（ワインをだしすぎてしまったことがまずかったと）、クリーニング代請求の用紙まで用意されて・・・。

実際、私自身はそれほど不快な感じではなかったのと、なんかこのプレミアムシート快適！という感じだったので少々恐縮しつつクリーニングとかは辞退しつつ・・・残りの3時間を快適に過ごして帰りました。

という、まぁ、飛行機いろいろありますわなー、というメモ。サーフィン大会は無事うまくいったのだろうか。そしてワインで濡れた床とかシートとか、あのあとどうしたんだろう・・・

てなことで今週もまたサンフランから帰国するんですが、、、今回もこんな退屈しのぎのイベントがあるといいんですけどねー・・・・などと思いつつ。

/メモ/

シンガポールについてのメモ

Wed, 09 Jun 2010 02:57:39 +0900

すっかり自分の中で過去の出来事になってしまったんですが、公開しないと葬り去りそうなんで、メモ公開しときます。
みんなが注目している（？）シンガポールについて。

■先に感想を

結論書くと、よくわかってないんですけどね。この国のこと。
シンガポールにいってデモしてきた目的は、アジアの世紀(？)を見据えて起業家環境を実感しようと思ったからです。
人とか環境とか。将来住むかもしれないしｗ
まぁ、TechCrunch Japan の中の人に紹介してもらわなければ行ってなかったですけど...。

ということで、だらだらとメモ残しておきます。編集ほとんどしてません。（その上、起業に関する情報一切なしｗ）
ま、ひとつの側面として興味ある人向けに。
あ、主観的な情報もはいってる上に裏付けの調査もしてませんので、一部間違いとかあると思います。
そのあたり流し読みで是非。

■シンガポールの教育について

移民や期間ビザの人が多いんですが、シンガポール人について。興味があったので。
- シンガポールには大学が３つ。
- トップはシンガポール国立大学(NUS)。世界ランク18位。
- 中学を出たら高校（というか大学プリスクール）みたいなところに行く。
- 高校では１年目と３年目に試験があって、この成績によりどこの大学に行けるかが決まる。
- 晴れて行ける大学が決まると、男子には２年間の兵役が待っている。
- 成績優秀でもこの兵役から逃れることはできないので、大学生になった時点で男女には２歳の年齢差ができる。
- 一応兵役中も週に２日は家に帰れるが、カメラ類の持ち込みは禁止されているなど生活にはいろいろ制約がある。
- ちなみ高校まで授業料は $25SGD = 1500円ちょい/月。兵役は給料もでる。大学も安い。
- なお、シンガポール人は英語と中国語の両方を学ぶので中国語話せる。図書館も半分近くは中国語の書籍だった。

■シンガポール政府について

- 政府は国民の選挙によって政党が選ばれ、政党が首相を選ぶ。
- 首相のパワー強大
- 実は特定の政党が強すぎて実質的には選挙になっていない。
- 公務員はとても給料がいい。首相だと数億円。
- 軍隊（主に空軍）も給料が高い。
- だからみんな政府で働きたいと考えているが雇用人数が少ないので競争も激しい。
- この公務員争奪競争は例の大学入学時のグレードとかで決まる（成績至上主義？熾烈だ・・）
- Taxが低い(消費税7%?)ので公務員の給料が高すぎ！って日本みたいに不満に思っている人は少ないらしい
- でも政府により管理されていることに不満をもっている人も話した中にはちょろちょろいたからよくわからん
- ちなみに給料高いといっても初任給で 5000SGD くらい = 35万円弱

■所有権について

- 土地と車は高い。
- 買える土地は場所が制限されている。300平米で５億円とか結構高い。
- アパートは97%が政府所有になっていて、それを買うことができる。（この辺仕組み不明すぎて間違ってるかも）
- 100平米のアパートで3000万円くらい。
- 居住区は決められていて、中心街から離れたところにベッドタウンがあり、みんなそこから通う。
- 車は高い。カローラクラスでも３００万円くらい。あ、５００万円だったけな？まぁ、そのくらい誤差ってことで。
- 品質高いのは日本車と韓国車。高級車といえばBMW。

■生活について

- 国土が狭い上に都市機能が完全に整備されているので遊ぶ場所があまりない。
- 学生はみんな家でパソコンしてるかテレビ見てるよ、とのことでそりゃ君だけだろうかと思ったけど本当にそうでもない感じ。
- ちなみにパソコン=Facebook。Facebook最強。
- 大人の楽しみは食事とショッピング（ステレオタイプ過ぎると思うが・・・）
- ということなんだけど、確かに食事するところとショッピングするところは異常に充実している。
- 熱い、とにかく暑い。３月とか涼しいよっていってたけど、よく聞くと雨が降るからとか、それありえん。
- 暑すぎて自転車に乗ってる人いない。全くいない。
- 食事安すぎ。うますぎ。タクシー安すぎ。
- あちこち工事大杉。どこもかしこも工事。
- そして工事している人をみると、みんな共通の人種だとわかる。シンガポール人ではない。そう、ここは・・・
- 関係ないけどチューインガムの販売が法律で禁止されてる

■その他、雑多なメモ

- インターネット遅い。マジで遅い。ホテルだけかと思ったけど、biopolis という政府の最新鋭設備でも遅かった。
- 3Gでのデータ通信は日本より快適に感じた。
- シンガポールドルは現地で換金鉄則。日本円の現金最強。
- クレジットカードとかより現金の方がはるかにレートがいい
- ちなみに成田で 71円のシンガポールドル、現地で 65円で買えた。クレカの請求レートは70円。
- Pocket WiFi もっていって M1 の定額SIM（3日で1000円ちょと）買えばネットワークには苦労しない。
- シンガポールは SIM フリーなのでケータイ/スマートフォン買うといいと思うけど買うのはいろいろ難しい。
- 店をまわって金額きいて、仕様も3重くらい確認して、それでも最終支払額が違ったり仕様が違ったりする上に店員がしつこいw
- 政府の最新鋭研究施設、biopolis は確かに立派な施設だった。
- 優秀な研究者を熱烈呼び寄せて、研究成果には熾烈なノルマを課すって噂だけど本当かいな
- インドネシア人はどうして全力で握手してくるのか・・・

という感じです。メモの内容が偏ってる上に主観情報まざりすぎちょるｗ

が、何かの参考になれば！

if (a > b) と if (a - b > 0) は違うんです・・・

Fri, 28 May 2010 10:14:25 +0900

あぁ、やっちまったぜ。

ということでたまにはプログラミング系。といっても、ツイキャスのバグを晒してるんですけどね・・・

えっと、

ア. if (a > b)

と

イ. if (a - b > 0)

は違うんですよね、、、やっちまいました。

これは a と b が符号なし整数 (uint) の場合に問題がでます。
符号なし整数の場合、引き算でも負数にはならないのでイのケースは a == b の場合以外常に真となります。

まぁ、符号なし整数を不用意に減算しちゃいけない、ってことですかね・・・

で、この問題がツイキャスに潜んでいて、ある特定条件で電波状態が急に悪くなり映像を5秒間送信できなくなるとこの条件式にひっかかり電波オチすることがあります。

電波状態は基地局のスイッチオーバーなどでも急に変動することがあるので、、す、すいません。。。

この問題、次のバージョンで改修されます。

といっても、次のバージョン、もう一週間前に申請だして、まだ審査すら開始されないんですけどね・・・

最近 Apple の審査、時間かかってるという噂なんですが、これ間にあうんかいな Twitter の認証方式切り替えまでに・・・・

ということで、なんか最近ツイキャス切れる！という方、すいません、バージョンアップまでいましばらくお待ちください。。。

※なお、突然切れるのではなく、配信開始直後から赤い時計が点滅しまくる場合、どうも電波のつかみが弱いことが原因のようです。iPhone を再起動することで改善することがあります。

ツイキャス・ビューワーが承認されるまでの 42 日間

Tue, 11 May 2010 17:18:48 +0900

さて、本日「TwitCasting Viewer」という、ツイキャスのライブ配信を iPhone で閲覧できるアプリが公開されました。

この承認に 42 日間（途中 Reject 3回）かかったので、その記録を残しておきますね。参考までに。

あ、ちなみツイキャス・ビュワー、入れておくといいことありますよ。入れておくだけでいいです。立ち上げる必要ないです。いつか役に立ちます、きっとw。

●序章：ストリーミングプロトコルの指定について

以前のエントリにも書いた通り、Apple の規約変更により「3G回線で映像を配信する場合、HTTP Live Streaming というプロトコルを利用する」ことが必須になりました。

これはすなわち、iPhone 上では Quick Time を利用しないと映像を表示できない、ということです。

で、アプリを投げ込んだのが 3/30、その2日後に審査が開始され 4/6 に「HTTP Live Streaming を使用していない」ことが理由で却下されました（１回目）。

●質問を投げてみる

まぁ、仕方ない、HTTP Live Streaming 使うと遅延は発生するんだけど、Apple は神だから仕方ない、ということで 3G 回線のときには HTTP Live Streaming を使うように変更しました。

で、一言で変更といっても実はそんなに簡単ではなく、 Apple は「64kbps で音声のみ配信するというモードを必ず用意すること」を義務付けています。

つまり、ひとりの映像配信に対して、異なる bps のエンコーディングを並列で行う必要があり、デベロッパ側にはかなりの負担となります。
指定されている H.264 というコーデックも、CPU パワーを食うものなので、ライブ配信するサービスは、結構みんな対応に苦慮しているんじゃないかな・・・。

で、一週間程度で対応を完了し、アプリを再申請すると同時にメールで質問をなげてみました。

内容は

- ブロードキャストじゃなくて 1 to 1 での映像配信にも HTTP Live Streaming を使わなくてはならないのか
- 現在 App Store に並んでいる、HTTP Live Streaming に対応していないアプリはどうなるのか

で、Apple 返ってきた答えは

- 「他に質問は？」

でした。いや、これ全文ですから、マジで。もう目が点になりましたよ・・・。で気を取り直してアプリを投げ込んだのが 4/15 です。

●２度目のリジェクト

で、今度は 4/19 に再度リジェクトがきました。

このときは担当の人から電話がかかってきました。実に丁寧ですね、と思う反面、文章に残るとまずいのか？とか変なことを勘ぐりつつ・・・

実はテスト用に iPhone 一台ずーっと映像配信していて、その HTTP Live Streaming の URL をサンプル URL として渡していたのですが、丁度日本時間の昼間だったので「アメリカ夜だから働いてないだろ」と思って電源切ってたんですね。

そしたら「サンプル URL にアクセスできないんだけど」ということで電話がかかってきた、というわけです。

このとき、丁度いい機会だから「ちょっと質問していいか？」と尋ねたところ、いいよ、ということなのでいろいろ電話で聞きました。
この辺の話しは Twitter 上にも流した気がするんですが、再度書いておきますね。

Yoski: 「HTTP Live Streaming はすべての映像配信で対応しないといけないのか」
Apple: 「そのとおり」
Yoski: 「ブロードキャストならわかるが、1対1の映像配信アプリでも HTTP Live Streaming が必要なのか」
Apple: 「3G で配信する限り、答えは YES となる。WiFi なら問題ない」
Yoski: 「HTTP Live Streaming だと遅延が発生するのでライブアプリには致命的なのだが」
Apple: 「状況はよくわかる。ただ、こちらからはそれなら WiFi で対応してくれとしか言えない」
Yoski: 「現在 AppStore に並んでいるアプリで HTTP Live Streaming を使っていないものも大量にあるが」
Apple: 「大量に存在している点は把握している。それらはアップデートが来たタイミングで順次審査していくことになるだろう」

担当者の方はよい感じの人でしたけどね。

ということで、3G 上の映像配信アプリには厳しい状況が来るようです。Knocking Live Video とか Live Link 3G とかどうすんだ、一体。余計なお世話だけど。

●再度 Apple とやりとり

さて、その後、Apple の人からまた連絡があり、どうも HTTP Live Streaming の Validator でエラーがでるから直してくれ、とのこと。

64kbps の音声ストリームは mpegts というフォーマットを利用せず、 AAC フォーマットで配信していたのですが、コレに対して Validator から PRIV ID3 Tag がないという警告がでているとのこと。

もはやお互い意味不明なのですが、とにかく Apple のデベロッパサイドで「 Validator で警告がでるものは通さない」ということらしく、しぶしぶ ID3 タグをつけて対応。

「Mac OS X で利用できる HTTP Live Streaming Validator を必ず使うように」と言われ、その後もこれを使って検証。ただ、ちょっと嫌な予感が・・・

●3回目のリジェクト

その後、連休明けの 5/6 に入り、再度リジェクトが入ってきました。

曰く、「Validator でやっぱり警告がでている」と。

実は HTTP Live Streaming のプレイリストは .m3u8 という拡張子を使うことが「通例」らしく、ファイル名がこの拡張子になっていないと Validator で「警告」がでるのです。

もちろん、技術者ならファイルの拡張子なんて飾りであって、Content-Type をちゃんと返していれば問題ない（というかそれが本筋）であることは●×△▼！！なのですが、そんな理論は通じません。（こちらは IETFの仕様書みながら作業してるんですけどねー・・・）

仕方なく、プレイリストの拡張子を .php から .m3u8 に変更しました。

●その後、ちょっと放置プレイ

連絡があったときに「言いたいことはわかった。１時間で拡張子変更するからすぐにチェックしてくれ」「了解。明日にはデベロッパ側でチェックする」といわれたものの、当然放置プレイなわけで、しびれをきらしてメールで連絡したら

「今レビューしてるよ！」

という連絡とともに、さくさくっと「Rejected」のステータスが「Ready for Sale」に変わりました。いやー、つついてみるもんですね・・・

●ということで、無事審査通過

めでたしめでたし、、、なんとか、42日間の苦闘が終了しました。ふー。

で、今回、もう一つ懸念していたことがあり、それは「ツイキャス・ビュワーが R18指定を受けるかどうか」でした。

外部コンテンツを表示する多くのアプリは R18指定を受けます。Pixiv とかニコニコ動画とか、そうですよね。

USTREAM Viewer が事前に申請したアプリしか閲覧できないのは、この R18 指定を回避するため、という噂もあります。

で、ツイキャスビュワーをインストールするとわかるのですが、このアプリ、ビューワーといいながら「お薦めライブ」などの表示は一切ありません。

そのかわり、お気に入りの人を登録しておいて、その人がライブを開始すると「プッシュ通知で」お知らせが来るようになっています。

審査にあったっても、「予期せぬコンテンツがユーザーに表示されることを防ぐため、ライブを閲覧するにはまず自分でユーザーをピックアップする必要がある」と伝えています。

で、この仕様が認められて（？）、晴れて R-18 指定をまぬがれたことは、結構大きな成果かな、と思っています。（自主申告で R-12 指定にしました）

ちなみに R-18 指定を受けると、18才未満のダウンロードが「禁止」されます。R-12 指定は 12才以上であることが「望ましい」ということになります。

現状、R-18 フィルタをかけている人は少ないかもしれませんが、iPad の展開などもあり、今後教育機関での展開など、いろいろな要素を考えると、どうしてもこの「R-18」指定は避けたかったのです。

ということで、以上がツイキャス・ビューワーが承認されるまでのプロセスでした。

ふー、ってか、ツイキャスビューワーの説明、全然してないやｗ

よろしければ、ツイキャス・ビューワー、いれてみてください。もう次のバージョンできてるので、矢継ぎ早に申請しますけどねｗ。

- ツイキャス・ビュワー (利用に Twitter アカウント必要ありません）

- ツイットキャスティング

iPhone アプリを iPad 対応にする方法（プログラミング編）

Mon, 19 Apr 2010 15:57:08 +0900

スクリーンショットとりながら丁寧に説明する気はないのだけど、メモ残しとかないと自分でも忘れそうなので・・・

iPad の登場で、iPhone/iPad 両方に共通のバイナリというものが SDK 3.2 で作成できるようになりました。
もちろん、iPhone は iPhone OS 3.1系、iPad は 3.2 系なので、API の変更を吸収する必要はあるのですが、それを差し引いてもシングルバイナリで提供できるというのはメリットが多いわけで・・・

で、その方法。主に Interface Builder を使ってる人向け。

詳しくは Starting Your Project を読んでください。MPMoviePlayer を使っている自分にとっては「どうすんだよ、これ・・・」って感じではあるのですが・・・ま、それはさておき。

※次の手順 1-3 については、XCode の「Upgrade Current Target for iPad」コマンドを使うことが推奨されています。ので、1～3 については基本「Upgrade Current Target for iPad 」コマンドをつかってください。XCode 右ペインの Groups & Files メニューから Target を選択して右クリックすればメニューが表示されるはずです。

1. iPad用の XIB(NIB) を作成する
　これは、File > New File > Empty XIB で、よーくみると iPad が選択できるので、それを選択して作成します。

2. iPhone用のリソースをがーっとコピー
で、作成した XIB に元の iPhone のリソースをがーっとコピペ。
File's Owner のクラス設定だけは忘れずに。

3. Info.plist に iPad 用のリソースを指定
　Add Row で Main nib file base name (iPad) という行を追加。その値を先ほど作った XIB にする。

4. iPhone / iPad ユニバーサルプロジェクトであることを記述
　Project > Edit Project で Targeted Device Family を iPhone/iPad に変更。これで iPhone/iPad に対応したユニバーサルプロジェクトが完成。
　なお、iPhone の場合のOSバージョンは、その下にある iPhone OS Deployment Target で指定されている。iPhone OS 3.1 でOKでしょう。

以上で、iPad ユニバーサルアプリ完成。簡単ですね。
なお、XIB がメインのもの以外にもある場合は、それらの XIB も変換が必要ですのでご注意ください。（そのためにも 1～3の手順は知っておいて損はないかと）。

あとは iPad で画面がでかくなったのでリソースをちょろちょろ編集していきます。てか、iPad 画面でか！

※ 「Upgrade Current Target for iPad」コマンドを使用したときは 4. の処理が行われないようですが、これはちゃんと設定しておいたほうがいいと思います。

で、あと気を付けるとこは・・・

5. Weak Link
　ランタイムでライブラリエラーがでるときは、たぶんリンクが Weak Link になっていないせい。
　そんなときは Project > Edit Active Target > General で、Linked Library の値を Weak にします。
　たぶん、UIKitFramework でしょう。これ Weak にすればたいていいけるんじゃないですかね・・・

6. Default.png
　Default.png は iPad では Default-Portrait.png と Default-Landscape.png を用意します。

7. Interface Orientation
　3.2 からインターフェースの向きも Info.plist で設定するようになっていますので、Supported Interface Orientations (iPad) と Supported Interface Orientation (なにもなしは iPhone) を設定しておきます。
　iPad の場合、Portrait にしても上下どちらでもいけるようにすべきかと。

8. UIDevice の名前
　よく使われる、 sysctlbyname("hw.machine", name, &size, NULL, 0); の値は「iPad1,1」です。
（sys/utsname.h の uname も同じ）
また、[UIDevice currentDevice].model は「iPad」です。

9. iPhone/iPad の判定
　そもそも iPhone/iPad の判定、なんか簡単にできるっしょ！って思って調べてみたのですが、なんか微妙・・・
　プリプロセッサレベルでは
#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 30200
で iPad の判定ができます。（追記: iOS4 が出たので、この判定方法は使えなくなりました）でも、プリプロセッサレベルで振り分けたらシングルバイナリにならんですよね・・・
　ランタイムでの判定は、一応マクロで定義してねってのが推奨されているので、これを使うとよいかと思います。

10. Icon.png
　iPad でアイコンも綺麗になっています。これまでの 57x57 ではなく、もうすこし大きいもので「72 x 72」になっています。
　まぁ、大きいものを Icon.png としておいておけば iPhone では縮小表示されますが、綺麗にするなら Info.plist に CFBundleIconFiles を Array 型で定義して、その中にアイコンファイルを指定していきます。最適な大きさものが適切に選択されます。

と、こんなところでしょうか。

iPad アプリも早速 $0.99 の最低ラインに値下がりしていて、これで　iAd がでれば、無料アプリが氾濫するんじゃないですかね。。

その前に既存の iPhone アプリを是非 iPad 対応にしておきましょう。

※間違いや抜けてるところあれば教えてください。

ツイット・キャスティングのすべてのライブが iPhone/iPad で閲覧できるようになりました

Fri, 16 Apr 2010 16:39:29 +0900

お知らせという名の愚痴エントリですが・・・ま、愚痴はさておき。

ツイットキャスティングで配信するライブ、これまでは iPhone だと「音がでない！」という状態だったのですが、ようやく音声がでるようになりました。

iPhone から見るとうにょうにょ動いている画面の真ん中に「△」の印がでていますので、これをクリックすると Quick Time が立ち上がり、ライブを閲覧できるようになります。

残念ながら全画面表示で Quick Time が立ち上がるのでコメントとかは見れませんが、通常のツイッタークライアント (Echofonとか) からでもライブが閲覧できるので、便利といえば便利かと思います。

また、こっそり iPad にも対応していて

iPad で△をおすと、（ここがiPadのすごいところなんですが） Quick Time がインラインで立ち上がり、そのページにとどまったままでライブが再生されます。

インライン再生便利！

ということで、iPhone / iPad でもすべてのライブで音声でます。ふー。。

ちなみに先週リジェクトされた閲覧アプリについても、失意の谷底から這い上がり、ようやく昨日提出しました。うまくいけば来週公開されると思います。

閲覧アプリを使うとコメントを読み書きできるのはもちろん、ライブのプッシュ通知の機能が搭載されています。

～～～

さて、で、iPhone からライブ閲覧には、かの~~悪名高い~~ HTTP Live Streaming という技術を用いています。

自動的に最適な帯域を選択してネットワークの状態に応じて柔軟に配信できるからデベロッパーは何も考えなくても高クオリティな配信が可能、というのがウリなわけですが、まぁ、全自動でまともに動くなんて期待しては・・・

が、完全に独自のプロトコルというわけではなく、デジタル放送とかにも使われていたりするわけで、それほど否定するものでもありませんね。

で、現在は私の至らぬところからいろんな制約があり、まず 10 秒ほどの遅延があり、映像も少しクオリティが落ち、音質もちょっと微妙なところがあり、でも使用帯域だけは増える、という、もう個人的にもまったく納得いかない状況になっています。

が、~~これを使わない限り・・・~~ Apple 先生が忠誠を見せろというとなので頑張って対応させています。これからも改善していかないとですね。

（配信サーバーを MacOSX にすればいろいろ解決するようなのですが・・・いやぁ必要なツールはオープンソースで配布して欲しいです・・・ MacOSX のバイナリ配布のみって~~ひどすぎる~~それもありかなと思います（棒読み）。）
ま、この続きは閲覧アプリが公開されたときに。。

ということで、iPhone でも閲覧できるようになりました。よ、と。

この3週間、審査のせいで足踏みしてしまいましたが、ようやく次のステップに進めそうでほっとしています。

ということで、引き続き TwitCasting よろしくお願いします＝ー

- TwitCasting

大人な事情により Apple の審査通りませんでした（ツイキャス・ビュワー）

Tue, 06 Apr 2010 15:05:04 +0900

さて、先日 Tokyo2.0 で発表した新アプリ、「TwitCasting Viewer（ツイットキャスティング・ビュワー）なのですが、本日 Apple より正式に「却下！リジェクト！」の連絡が来ました。

リジェクトの理由がシステムの根底に関わる問題のため、ビュワーの提供はまた少し先になります。申し訳ありません。

Apple 側から公開されている（NDAに抵触しない）範囲内でリジェクトの理由を書いておきますので、なにかの参考にしていただければ、と。

さて、ツイットキャスティング・ビューワーでは

　- PUSH によるライブ開始の通知
　- 独自プロトコルによる 64kbps ～ 1Mbps 帯域での柔軟な環境での視聴

を可能にしています。

問題は、この「独自プロトコル」で、Apple 側は今年2月に

　- 10分を超える音声・動画、もしくは (NDA)分間で (NDA)バイトを超える音声・動画を 3G ネットワークで配信する場合、Apple の指定するプロトコルを使用しなければならない
　- その場合、最低 64kbps でも視聴できるように複数の帯域をサポートしなければならない

という制約を追加しました。

指定されたプロトコルは HTTP Live Streaming というものです。

これは事実上 Quick Time での視聴となるため、もろもろ理由はつけているものの、思惑としては今後広まってくるであろう動画コンテンツが Quick Time 上を必ず流れるように管理統制したいのではないか、という裏なども考えずには・・・いや、神ですからね。考えてはいけませんな・・・

ともかく、HTTP Live Streaming に対応しないと iPhone / iPad で動画を閲覧することはできなくなった、ということです。

で、HTTP Live Streaming の何が問題かというと、このプロトコルは構造上、遅延が数十秒発生するため、双方向コミュニケーションをベースとしたライブの配信には不向きなんです。（逆に大きな動画コンテンツを、帯域の不安定なネットワークで閲覧するのには向いています）。

また、iPhone / iPad では Quick Time は全画面表示となるため、USTREAM の iPhone Safari 対応版で見たように、Safari から閲覧したときに、コメントの読み書きが一切できない、という問題があります。（アプリ内閲覧ならちょっと工夫することで可能）

ということで、さて、どうしたものか・・・

実は USTREAM が HTTP Live Streaming に対応していなかったため、まだ猶予期間かな、と思っていたのですが、ツイキャス・ビューワー審査中、狙ったように今週頭にUST Viewer HTTP Live Streaming 対応版を出してきました。

これでツイキャス・ビューワーが却下される大義名分もきっちりできてしまっていたわけです。うーむ。

ただ、HTTP Live Streaming に対応していないアプリもまだたくさんあるので、少し状況を Apple に確認してから、今後の方針を考えたいと思います。

ま、HTTP Live Streaming も、うまくやれば実用的な範囲に遅延を抑えることができるかもしれませんしね。

ということで、最後に幻のツイキャス・ビュワーを紹介しておきます。

3G での視聴を諦めて、WiFi でしか使えないようにすれば審査通るとは思うのですが、それじゃ意味ないですよね・・・？

Skype も 3G 対応版が出ると噂されてから早２ヶ月、結局審査通らないようですしね。。。ま、頑張るしかないか。
この３月の死ぬような苦労は一体なんだったんだ・・・なんだったんだ・・・

■ツイキャス・ビュワー

オススメコンテンツなどはありません。まずお気に入りのユーザーを登録します。すると・・・

ライブが開始されたときに PUSH で通知がきます。もちろんアプリ終了しててもOKです。

映像+音声が、ほぼ遅延なく閲覧できて

もちろんコメントのやりとりもOK

横画面にも対応しています

実はPC版より全然音質いいです。

せっかく作ったから WiFi のみ版として公開しようかと思いつつ、でもそれじゃ期待ハズレなのは間違いないしな、と思いつつ・・・。

ということで、もうちょっとお時間ください＞iPhone からの視聴ー

Tokyo Tyrant 雑多なメモ (Tokyo Cabinet も可)

Fri, 02 Apr 2010 11:19:12 +0900

合宿で Tokyo Tyrant 部分、いろいろチューニングしたのでメモ。細かいのでその手の方以外はスルーの方向で。

対象は便利すぎる Tokyo Tyrant Table。

・インデックス

　addCond()->addCond()->addCond()

で絞り込んでいくとき、hint() で調べると最後に追加した Query から順に Index を使っていることがわかる。(5/3追記)⇒最後ではなく、2番目、一番目、と使う様子。

なので最初は大雑把な絞り込み（カテゴリとか）を行い、最後に詳細な絞り込み（ユーザーID）なんかをかけた方がパフォーマンスがあがる様子（手元のベンチマークでは上がった）。

・数値インデックスに対する NUMGT や NUMGE

日付のタイムスタンプなどで、過去三日以内、というときに

addCond(日付のとこ, 数値が～より大きい, 3日前）

みたいな感じにすると思うけど、この Query かけた時点で候補がたくさん残っているとかなり遅い。
なぜか数値インデックスのこれだけ妙に遅い。ノーパソのVMWare上だけど10万件ソート1秒近くとか。できれば避けたい。（うーん、なんか間違ったのかなぁ・・そうかもしれない）

・プライマリーキーはフィールド指定して検索・ソートできる

特定の id の情報をとってくるのは

->get(id)

とかしてると思うが、これ、実は

query->addCond("", 数値が～に等しい, 検索したいID)

とかでも引っ張ってこれる。空文字はプライマリーキーを表す。
なので、ソートして検索したい場合、最後に追加したものが最新のデータ、という構成であれば、created みたいな日付フィールドつくってインデックスはってソートして、なんてしなくても

query->setOrder("", 数値が大きい順)

などとすればソートできる。これは数値インデックス別途張るよりもちょっと早い。(5/3追記: 速度は変わらないかひょっとすると遅くなっているかも。)

・最近の1万件を検索対象、とかを高速にする方法

追記式のデータの場合、直近の１万件を検索対象にしたい、みたいなケースがある。
この場合、まず

$total = database->num()

で全体の合計数をひぱってきて

query->addCond("", 数値が～より大きい, $total - 1万)

みたいにすると猛烈に高速に直近のデータだけ取り出せる。(5/3追記：これ、たぶん嘘）

なお、 num() で帰ってくる値と、主キー（数値型でオートインクリメントな場合）との値は少し異なる。
そのため、どうしても正確にやりたい場合は、最後の ID をどこかに保存しておくか、ちょっと微妙だけど、どうしてもというときには

database->getUid()

で数値をとってくることもできる、けど主キーがインクリメントされちゃうのでオススメはできない。って誰かいい方法教えて＞最後の数値主キーを高速に取得する方法）

・ソートしないときの検索結果の順序

検索結果に setOrder かけない場合、取り出されるレコードの順序は基本的には不定っぽい。
が、一応、なんか古いものから順に出てくる傾向にはある。
検索対象のレコード数がでかい場合、setOrder かけると遅くなるので、古い順でも、ちょっとくらい不定でもいいや、というときは setOrder をかけずに使いたいところ。

・インデックスの罠

候補が少ないインデックス(たとえば type というフィールドに 0, 1, 2, 3 の４つくらいしかステータスがなくて、一つに数万とかデータ入れちゃってる場合）、このフィールを使った検索で、ある日突然異常にCPUパワーを食うようになるかもです。いや、なるともう、猛烈に食います。
なので、このようなインデックスを使う場合（でかつ、その指定された条件では大量の結果がマッチすることがわかっている場合）は RDBQC_NOIDX かけてインデックスを使わないように設定しないと大やけどします。hint() を見て、RDBQC_NOIDX いれてなくてもインデックス使ってないや、と思っても実際には計算に利用していて、それがまた猛烈にCPUパワーを食います。です。

まぁしかし、便利ですね。テーブル型の key-value ストア。ということでメモ（主に自分用）でした。

Joker Racer サービスの一時休止についての説明

Thu, 25 Mar 2010 11:45:46 +0900

Joker Racer サービスについて、現在運用しているラジコンの運用を一旦停止することになりましたので、その経緯を書いておこうと思います。

なにしろ AMN WISH 2009 で大賞までいただいたサービスですので、いろいろと包み隠さず正直に。

さて、昨年の夏以来、専用のコースも用意して運用を開始した Joker Racer ですが、その後もいろんな方面に展開すべくさまざまな活動を行っていました。
年末には TechCrunch などのイベントにも出るなどしたこともあり、実際海外などからもいろいろと引き合いをいただいていました。

が、諸般の事情によりハードウェア担当のエンジニアが事業に関わっていくことが難しくなったこと等で、年明けあたりから新規の開発ができず、国内・海外からのお話しも断腸の思いですべてお断りせざるを得ないという状況になりました。

サービスとしても、24 時間動かせるタンクを惰性で提供しているだけの状態では再開を待望されているユーザーさまにも申し訳ない、ということで協議した結果、今回運用を一旦とめさせていただくという結論に達しました。

このような形で一旦トーンダウンせざるを得ないということは、ここまで応援して頂いた皆さまに申し訳ない思いでいっぱいです。。
ですが、きちんと決断していく方が最終的には良い形で恩返しができると思っていますので、ただ前向きに進むのみ、と個人的には考えています。

=+=+=

さて今後ですが、Joker Racer はハード側とソフト側（=つまり私）との2人3脚＆小資本の共同出資でやってきましたので、そちらを一旦今後の方向性に即した形にしてからまた新たなスタートを切りたいと考えています。

Joker Racer 自体は、ラジコンをネットで操作する、という具体的なイメージをベースに、ネットからの遠隔操作プラットフォームを提供することを最大の目標にしています。

ということで、もしハードウエアの開発に携わっている、またはこのような活動にご興味があるハードな方はご連絡いただけると嬉しいです（給料とかでるわけではないですが）。

なお、年明けからサイドフィードとして開始している新サービス「モイ！TwitCasting」には Joker Racer の技術を応用しています。
根底のコンセプトには共通のものがありますので、こちらもあわせて猛烈に力を入れていこうと思っています。

ということで、これからもどうぞよろしくお願いいたします。