iPhoneアプリ開発グループトップ最新の日記ユーザー登録ヘルプhirogramの日記<前の5日分2010-08-18手書きアプリのためのテストプログラム手描きのアプリは、指の動きに追従してなめらかな線を書くのがなかなかに難しいものです。いろんなアプリが色々工夫していることかと思います。SpeedTextも工夫しています。工夫していると、速くなったんだか遅くなったんだか自分ではよく分からなくなってきます。人間の感覚って難しい。いうわけで、手書き系アプリのための描画速度を測るかんたんなテスト用ビューを作ってみました。アプリの処理を変える前後でテストすると、速くなったかどうか分かりやすいかな、と。実行すると、画像みたいな感じで「2秒間かけて丸を等速で12個描くような」指の動きをシュミレートします。1つの丸に60個の座標、計720個の座標を用意して、1つの座標の描画が終わるたびに、スタートからの経過時間に応じた座標を描画用のビューに渡します。(描画用のビューとは、あなたのアプリのビューです。iPhoneSDKでは、本物のtouchなんとかメソッドを呼べないため、アプリ側に擬似的なtouchなんとかメソッドを用意する必要があります)んで、touchなんとかを呼んだ回数をカウントして最後に表示します。呼べた回数が多いほどいいです。これは大雑把なスコアといえます。touchに対する処理速度が偏っていると、丸が歪な形になります。あと、丸の上部がどれだけ閉じているかは、指のつけ離しに対する追従性を表します。一つの丸から次の丸に移るときにtouchEnd、touchStartを呼びますので、そこで時間がかかると、円の開始を描くのが遅くなり、上の部分が開いてしまいます。この記事の最後に記したTestBaseViewクラスをプロジェクトに追加します。テスト対象となるビューに、以下の3つのメソッドを追加します。locationに描画のための座標が入ってくるものとして、touchesBegan:withEvent等と同じ処理を記述してください。以下のような感じでTestBaseViewを画面に追加します。//このdrawViewを、アプリで使ってる描画用のビューにすること。TestBaseViewソーステスト用なのでソース汚いです。view;}@endVIEW_WIDTH、VIEW_HEIGHTは対象となるビューのサイズです。大きくすると、大きなビューを想定して丸の間隔が広がります。ソースのCOUNT_SECONDは、シュミレートする時間(秒)です。ここを減らすと、もっとシビアな条件を測定できます(実際のSpeedTextのテスト時は1秒にしてます。画像は2秒のもの)このテストプログラムでは、全体的に遅くても安定した速度で処理されると、いい結果になるので、描画自体の厳密な速度は測れないんですけどね。あと、touchが呼ばれる部分をスキップしちゃってるし。安定した速度で書けるかというテストですね。メンバ変数pointFlagsへの代入処理は、不要でした。あっても動きますが、邪魔なら削ってください。|はてなの日記の方に、Evernoteのイベントについてブログ書きました。これって、自動でリンクとかできないのかしら。はてなグループの使い方が未だによく分かりません。Evernoteの海外イベントに出ましたhttp://d.hatena.ne.jp/hirogram/20100226おうちに帰ってブログ書くまでがイベントよね。帰ってませんけれども。inarimftoon.2009-09-23OS2.2.1のデバイスでも動くけどOS3.0なら専用の機能が動くアプリを作る表題の通り、OS2.2.1のデバイスでも動くけどOS3.0なら専用の機能が動くアプリの作り方です。ADCにサンプルコードがあるのでご存じのかたも多いと思いますが、私は最近知ってありがたかったので、まあ報告します。OS3.0特有の機能というとメールに画像が添付できたり、コピペが使えたりとかです。他にもあった気がします。OS3.1も出ちゃってるのでいろいろあることでしょう。やりかたは、ADCのサンプルコード"MailComposer"のReadMe.txtに丁寧に書いてあります。やるのは割と簡単ですが、注意すべき点を先に挙げておいたほうがいいようです。OS2.2.1のデバイスでOS3.0用の処理を通らないように、ソースを分岐する必要があります。分岐しないとアプリが異常終了します。OS3.0の処理をソースに書いている時点でOS2.2.1のビルドはエラーになります。したがって、コンパイラに頼らず自分でチェックする必要があります。同様にOS3.0以降のデバイスでOS2.2.1専用の機能(あったっけ?)を通らないように注意する必要があります。こちらはOS3.0でビルドすればわかるはずなので問題ないかと思います。アプリを申請に出すときに、構成を間違えないように注意する必要があります。デバイス3.0とかでビルドしちゃって、リリースされてから気づくなんてことのないように(書いてて自分が心配になってきた)。このようにソースコードが煩雑になり、ミスも誘発しやすくなりで、開発者にとってはいいことはありません。新しくアプリを作る場合は素直にOS3.1用で作った方がいいです。OS2.2.1でアプリリリースしちゃってて、この後どうしようかという人向けですね。最後に手順を書きます。MailComposerのReadMe.txtも読みましょう。2.2.1"にします。これはすべての構成(Distributionも!)に対して行って、3回くらいチェックしてください。すると、XCodeのウィンドウ左上の構成とかを選ぶドロップボックスに「ベースSDKを使用」というのが現れます。これがどっちでも動くよ版です。メールのようにOS3.0独自のフレームワークを使う場合は、フレームワークをプロジェクトに含めた上で、役割(?)をWeakに変更します。Linkという奴になるようですね。XCodeのフォルダツリーでターゲットを選ぶと右画面で変更できます。MailComposerではOS3.0用のクラスが存在するかどうかで切り分けていますね。私はこんな感じで、問い合わせをするメソッドを用意しました。isOs30;}以上です。MailComposerのReadMe.txtも熟読しましょう。リジェクトされないか気になるところですが、今申請中なので通ったら報告します。サンプルコードがあるくらいなので大丈夫だと思いますが。20:41なるほど、これが正しいやり方なんですね。このサンプルは見ましたが、ReadMe.txtは、あまり読んでませんでした。私の場合は、とりあえず、NSInvocationで動的に3.0のAPIを呼び出す方法で解決しました。http://d.hatena.ne.jp/kimada/20090811/1249970669複雑なことをやる場合には、まったく不向きな方法ですね。ReadMe.txtを読むべきでした。バッテリー残量の取得は、2.xで非公開APIを使ったものが出回っていたこともあり、「それを使ってないよね?」というAppleから確認の電話が来ました。そこで事情を説明したところ、その翌日にリリースされました。2.xでビルドしたアプリから、3.0のAPIを呼び出すこと自体は、問題ないと私は解釈しています。22:02コメントありがとうございます。動的にやる方法もあるんですね。動的にやると、OS2.0でビルドしてもビルドが失敗しない(他の部分のエラーチェックができる)のはメリットですね。iPhoneの場合、どのやり方が正しいというか、リジェクトされなかったものが正しいみたいな感じがありますね。いろいろなやり方で試してみましょう。00:55報告すると言って忘れてました。|SpeedTextが有料トップアプリケーションのNo.1を獲得しました!応援してくださった皆さんありがとうございます。今回ちょっといいことがわかりました。それは、「小さなツールでしかも有料でも、ゲームアプリと勝負できるんだ」ということです。手の込んだ重量級アプリには勝てないとなっちゃうと、アプリ作るのもつまらんですよね。数時間後のWWDC以降、アプリの順位は大きく様変わりし、1位はつかの間のこととなるのは容易に予想がつきます。それでも、ここまでこれたのは、私にとって結構な収穫でした。done!2009-06-07アプリ第2弾リリースとアプリサイズの削減方法アプリ第2弾SpeedTextをリリースしました。|今回は手書きメモアプリです。好評みたいでありがたいです。|今回開発している上で気付いたアプリのサイズの削減方法を2点挙げます。アプリのサイズが大きいと起動時間に影響が出るので、私は結構気にしたりします。常識だったらごめんね。Symbolsのチェックを外すと、実行モジュールのサイズが劇的に削減される。デフォルトではReleaseもチェック付きなので、これを外す。Distributionも。http://iphone-dev.g.hatena.ne.jp/moira/20090228(moiraさんの日記)にあるように、GCCのオプションはアクティブSDKでDeviceを選択しているときしか表示されないみたいなので注意。Objective-Cのモジュール毎のサイズは、buildフォルダ配下の**.buildというフォルダの下をたどって行くと、*.oファイルがあるのでこれでだいたいわかる。ちなみに、メソッド一つにつき(内容がたとえ1行でも).oファイルは3〜4KB大きくなる。メソッドを頑張って削ると実行モジュールのサイズも小さくなる。[link=http://wvjwelqogzq.com]wvjwelqogzq[/link]<前の5。