Dropbox

Appleに提出したアプリケーションが審査の段階でクラッシュした場合 iTunes ConnectのResolution Centerにトラブルの発生状況とともにCrsh Reportが添付されます。

Crash Reportをダウンロードしてダブルクリックするとコンソールが立ち上がり內容を読むことが出来ますが、肝心の自分のアプリケーションのシンボルが関連付けられていません。困ったときのGoogle頼みで調べ見るとxcrun atosをCrash reportとアーカイブから取り出した.dSYMファイルを関連付ける方法が見つかりました。ところが試してみてもうまく行きません。

基本にかえってAppleのガイドに従うことにしました。答えは簡単に見つかりました。先のResolution CenterにリンクがあるTechnical Note TN2151によると単純にXcodeのOrganizer/Devices/LIBRARY/Device LogsにダウンロードしたクラッシュレポートをImportすればOKです。もちろん、これはアプリケーションをBuild/ArchiveしたXcodeで行わないとシンボルとの突き合わせは行われません。

Dropbox APIが新しくなったというニュースを見かけて、とあるアプリケーションに使ってみようと重い腰を上げテストしてみました。

iOS v1.0にはドキュメントが用意されていません。SDKに添付されているサンプル・プロジェクトが動くことを確認した後はtutorialに従って基本的に動作確認です。ところがファイルをアップロードしようとしたらupLoadFileがdeprecatedであると言われてしまいました。

ChagelogやDBRestClient.hを読めば事情は把握できるので良しとしましょう。せっかくのtutorialなので最新のAPIに変更しておいて欲しいものです。

新しいupLoadFileは、

- (void)uploadFile:(NSString *)filename toPath:(NSString *)path withParentRev:(NSString *)parentRev
    fromPath:(NSString *)sourcePath;

という形式です。parentRevと言うパラメータが増えています。ここにnilを指定してアップロードすることも出来ます。その場合、同じファイル名がサーバー上に存在する場合上書きをせずファイル名の後に(1)などと付加されて新しいファイルとして保管されます。現行ファイルを上書きする場合はloadMetadataにて現在のファイルのrevを取得しなければなりません。

ものすごく単純なコード例を書いておきます。
前提としてdocDirはアプリのDocumentフォルダーを指し、そこにファイルtest.txtが存在するものとします。またTutorial通りの手順でrestClientは初期化されているものとします。

- (void)uploadFile1
{
    [[self restClient] loadMetadata:@"/test.txt"];
}

-(void)uploadFile2:(DBMetadata*)meta
{
    NSString *testfile = [docDir stringByAppendingPathComponent:@"test.txt"];
    [[self restClient] uploadFile:@"test.txt" toPath:@"/" withParentRev:meta.rev fromPath:testfile];
}

// DBRestCleintDelegte
- (void)restClient:(DBRestClient*)client loadedMetadata:(DBMetadata*)metadata
{
    [self uploadFile2:metadata];
}

- (void)restClient:(DBRestClient*)client loadMetadataFailedWithError:(NSError*)error
{
    [self uploadFile2:nil];
}

revは元々、古いバージョンのファイルをリストアしたりするためのものと思います。詳しくは考えていませんが(ぉぃ、とりあえず動いてはいるようです。

久しぶりにiOSアプリケーションを更新しサブミットしたらInvalid Binaryになってしまいました。Xcode 4.2のArchiveからValidationは問題なし。Xcode4.2上ではSubmitも問題なしですがiTunes Connectを見るとInvalid Binaryと表示されていました。以前ですと問題があると何かしらエラーの理由が記されたメールが送られてくるのですが、それもありません。

まったく、手がかりの無いところから原因を探らねばなりません。Googolで検索すると、同様の現象について沢山の事例が見つかりました。ひとつひとつ検証した結果Info.plistでのアイコン指定の問題でした。

前提としてはiOS Deployment Targetが3.0なUniversal Applicationです。

最初は、

CFBundleIconFile icon.png
CFBundleIconFiles
  Item 0 icon.png
  Item 1 icon@x2.png
  Item 2 icon-72.png

みたいな感じでした。これで以前は問題なかったと思います。

ここに下のアイテムを追加してInvalid Binaryが解消しました。

CFBundleIconFile~ipad icon-72.png

本来ならXcodeのValidationでエラーを見つけてくれるべきなんでしょうね。試しにCFBundleIconFileにファイル名を消してみるとValidationの際にかなり詳しいエラーメッセージが出ました。

iPhoneアプリケーションの導入時に発生する問題の検証のためテストを行ってみました。特別、公開すべき事柄でもないのですが覚え書きとして残しておきます。

 [ テスト環境 ]
– Mac OS X Leopard上のiTunes v8.0.1からアプリケーションの導入を行った。
– テスト・デバイスは、iPhone 2G v2.0.2とiPod Touch第2世代 v2.1.1で、テスト結果はいずれも同じでした。

 [ 導入に使用したプログラム]
– iTunes上で82MB、iPhone上で展開されると231MBになるプログラム。容量の大半はテキスト・データです。Ad Hoc用にビルドしたものを使用した。

まずは通常のインストールが問題ないことを確認した。その後、残り容量が少ないケースと足りないケースおよびプログラム・バイナリーが壊れているケースをテストした。

[ テストケース 1 – 残り容量が少ない場合 ]
– 全ての導入が終了した時点でiTunes上で確認するiPhoneの残り容量が4MBに調節。
これでも正常にインストールが終了した。これから推測すると82MBの圧縮されたパッケージの展開はiTunes上で行われているのでしょう。

[ テストケース 2 – 残り容量が足りない場合 ]
– 残り容量を100MBほどにする。
インストールを行うとiTunes上にて残り容量が足りない旨のメッセージが現れてインストールが行われなかった。

[ テストケース 3 – プログラムが壊れている場合 ]
– バイナリー・エディターにてiTunes上のプログラム・ファイル(*.ipa)の一部を適当なデータに書き換えた。
– *.ipaファイル(実体はzipファイルです)に対してunzip -tを実行し内部ファイルの一つでCRCエラーが起こっていることを確認。
予想に反してインストールは正常に終了した。ただしアプリケーションを起動すると、すくせに終了してしまった。XCodeにてCrash Logを確認するとEXEC_BAD_ACCESSが発生していた(これも、ちょっと予想外です。壊れていたのはデータファイルだったはず)。
-> 本来はプログラムを展開するときにエラーが分かるはずなので、そこで何かしらメッセージが出るべきでしょう(v2.2で同じ事を試してみて改善されていなければレポートすべきかも <- iTunesの役割かな、、、)。

本当は物書き堂さんの辞書で発生していたようなiPhoneが再起動してしまうケースが発生することを予想していたのですが、まったく普通でした。もしかするとv2.0.2以前のソフトウェアで試すと違った結果が得られるのかもしれません。また、テストケース 3 の場合はデータを破壊する場所によっては違った結果になる事は十分考えられます。

新型のiPod Touchを開発システムに登録して開発中のアプリの実機テストを出来るようにしました。手順通りの設定をすませ、実際にiPod TouchをXcodeが稼働しているMac miniに接続したところ「SDKを入れ直してください」というメッセージが出ました。

iPhone SDK v2.1は導入したばかりでしたので、何か導入時に問題でも有ったのかと再導入してみます。特に怪しいメッセージが出ることなく終了。それでもiPod Touchを接続すると同じメッセージが出て使えません。

Google先生にお伺いをたててみると、ほどなくしてiPhone DevCenterのiPhone OS Pre-Installation Advisoryという文書に正解が書いてあるということが分かりました。内容は/Devleoper/Platform/iPhoneOS.platform/DeviceSupport 下のディレクトリー2.1に2.1.1というシンボリックリンクを張れ(ln -s 2.1 2.1.1)というものでした。

なるほどSDKの方は2.1.1というレベルが出ることを想定しなかったのね。SDKをダウンロードするページに色々と注意書きが書かれているのだけど、これについてはPDFを開かないと分からないって言うのは、ちょっと片手落ちな気もします。

今更ですが新しいiPodシリーズの情報を眺めています。iPod Touchが魅力的なのは当然ですが、現実的にはiPod nanoが良いなぁと思います。今年iPod買ったばかりですし、しばらくはお預けですが、、、

ついでですがWordPressにYouTubeを貼り付けるプラグインの紹介です。いくつか有るようですが、とりあえず私が入れてみたのはNoembededというものです。指示通りに導入してプラグインを有効にします。投稿画面をコードに切り替えてYouTubeのEmbed用のHTMLを貼り付けます。コード画面のままで公開を押してください。

ビジュアル編集画面に戻ると壊れてしまうのが今ひとつ。別のものも試してみようかな。