バージョン3.2.1以降で、なぜか実機でのみエラー発生

久しぶりに書きます。その前に、少し謝罪します。１年以上前にコメントによる質問をいただいたようですが、まったくアクセスしてなくて、しかもコメントが来た知らせをメール等で教えてくれないようで、回答せずに過ぎてしまいました。もう見てないと思いますが、ごめんなさい。知らせてくれる設定があるかどうか、あとで調べてみます。

　

さて本題です。以前に開発したiPad向け業務アプリですが、機能追加の依頼があり、久しぶりに手を入れることになりました。せっかくなので、Titaniumu MobileもXcodeも最新版に入れ替えておこうと、それぞれバージョンアップして開発を始めました。開発は順調に進み、エミュレータでのテストもクリアーしました。でも、実機に転送して動かしてみたら、ある機能だけが動きません。今回の機能追加とはまったく関係のない部分なので、何が起きたのか分かりませんでした。

とりあえず、エラーの内容を調べました。手順も含めて、少し詳しめに書いてみますね。iPadをMacに接続し、XcodeでiPadのコンソールログを見ます。開発したアプリ名で、しっかりエラーが発生していました。しかし、このままでは、エラーの箇所が特定できません。iOS用バッケージを作るときに、JavaScriptのminificationを設定しているので、エラー箇所がline 1になってしまってます。minificationをオフしてバッケージを生成し、実機に転送してエラー箇所を特定する必要があります。

エラーの内容は「'undefined' is not an object」でした。これは参照した変数にオブジェクトが入ってないときなどに発生するエラーです。エラーが発生したJavaScriptは以下のとおりです。

xxx = fileMix.read().text; // xxxは実際の名前ではない

このままでは、メソッド「read()」で発生しているのか、プロパティ「text」への参照で発生しているのか判断できません。そこで以下のように分割しました。

DebugX01 = fileMix.read();
xxx = DebugX01.text; // xxxは実際の名前ではない

ここで追加した変数「DebugX01」は、デバッグ用の変数であるため「Debug」という文字列で始めています。削除し忘れたりしても後から明確に分かります。また病気で突然倒れて開発を中断したとしても、この部分はデバッグのために追加したことが後から明確に思い出せます。こういう工夫は意外に大事ですね。

本題に戻りましょう。分割して実機で実行したら、「text」プロパティへの参照でエラーが発生していました。エミュレータではエラーが発生しないのに、実機だけで発生するというのも奇妙です。また、この部分は今回の修正範囲ではなく、以前は正常に動いていた箇所です。JavaScriptのコードが原因とは考えられません。別な原因で、何か問題が発生したと推測できます。たとえば、Titanium Mobileの仕様が変わって、以前のコードが動かなくなったとかです。

バージョン2.xでは正常に動いていたので、エラーが出る最新バージョンから順番に戻ってみることにしました。iOS用バッケージを生成し、実機に転送してテストするので、けっこう大変です。3.0、3.1、3.2などと大きな区切りで試し、変化したバージョンを特定するのが一番効率的です。そうして調べた結果、バージョン3.2.0では正常に動作し、3.2.1からエラーが発生していました。つまり、3.2.0から3.2.1への変更内容を調べれば、何か原因が分かりそうです。リリースノートを調べたのですが、関係しそうな機能が見付かりませんでした。

エラーが発生した箇所の機能を説明していませんでしたね。UI部品のWebViewを使って、グラフを表示する機能です。使いたいグラフ機能がJQueryを前提としているので、HTMLと組み合わせてWebViewで表示したというわけです。HTMLやJavaScriptやグラフ用データをテキストとして合体させ、WebViewのtextプロパティに設定して表示しています。変数fileMixには、Ti.Filesystem.Fileオブジェクトを入れ、readメソッドでファイルを読み込みます。読み込まれた内容はTitanium.Blobオブジェクトとなり、textプロパティで内容を参照できます。

エラーの意味ですが、DebugX01変数のtextプロパティを参照したら「DebugX01変数にはオブジェクトが入ってない」と怒られたという感じでしょうか。エラー発生箇所の一連の処理では、HTMLやJavaScriptなど何種類かのフィアルを呼んでいます。これら全部でエラーが発生してるわけではありませんでした。よく調べたら、JavaScriptを読み込むコードだけでエラーが発生していました。これが何かのヒントになりそうです。

試しに、JavaScriptのファイル名を変更してみました。ファイル名「xxx.js」を「xxx.js.txt」に変えただけです。そうして実機で実行してみると、な、な、何と、エラーが発生しないではありませんか。原因は、何なのでしょう。エミュレータでは動いて、実機ではエラーになるというのも不可解です。同じiOS7上で動作させ、Titanium Mobileのバージョン3.2.0以前では正常に動き、3.2.1以降ではエラーになります。いったい何が原因なのでしょうか。分かりません。原因は不明ですが、対処方法は見つけました。

少しだけ、原因につながりそうな考察をしましょうか。3.2.1以降のTitanium Mobileでアプリを作った場合、Ti.Filesystem.Fileオブジェクトで「.js」拡張子のJavaScriptテキストを読み込んだとき、それはTitanium.Blobオブジェクトにはならず、オブジェクトではない何かになってしまうということ。しかも、エミュレータではオブジェクトになり、実機ではオブジェクトにならないという奇妙な現象。また、同じファイルを「.txt」拡張子に変更すると、実機でもオブジェクトになってくれます。おそらく特定の条件を満たしたときだけ、JavaScriptテキストがコードとして解釈されて、オブジェクトではなくなるのでしょうね。その現象が、3.2.1以降のTitanium Mobileで、しかも実機だけで発生するという。

まあ、原因は不明ですが、対処方法が見付かって良かったです。同じ現象にあたった人がいたら、今回の事例を参考にしてください。そういう思いで、久しぶりに書きました。でも、また冬眠します。

iPadでは大きな画像のリサイズが遅い

やることが多くて忙しかったので、久しぶりの投稿です。コンテンツ待ちで保留中の、Titanium Mobileを使ったiPadアプリですが、少しずつ動き出しました。新しいiPadを入手して、レチナ・ディスプレイでもテストしたら、思いがけない発見がありました。

　

レチナではない普通のディスプレイでは普通に動いていたアプリですが、レチナ・ディスプレイで動かしたら、処理が極端に遅い部分を発見しました。普通のディスプレイだと1秒ぐらいで終わる処理が、数秒間も余計に待たされるのです。あきらかに遅く、このままでは公開できないほどでした。

遅い原因が分からないので、どの部分が遅いのか、まずは調べることにしました。メッセージを表示するためのラベルを追加して、処理の区切りごとに英字を表示させます。こうすると、どの部分で遅いのか簡単に特定できますから。実際に試してみると、予想もしない部分で遅くなっていました。この投稿のタイトルに書いたとおり、大きな画像のリサイズです。

　

このアプリは、コンテンツである画像の表示がメインとなります。用意した画像を画面いっぱいに表示したり、レイアウトの一部として画像を含め、縮小して表示したりします。画像の大きさは、普通のディスプレイ用の1024×768ピクセルと、レチナ・ディスプレイ対応版の2048×1536ピクセルの両方を用意しています。そのためレチナ・ディスプレイでは、2048×1536ピクセルの画像をリサイズして表示することになります。GPUを使わずCPUで処理しているためでしょうか、明らかに時間がかかっています。

本当にリサイズが重くて遅くなっているのか、リサイズした画像を追加して、リサイズ処理をなくしてみました。すると予想どおり、数秒間の待ちが完全に消えました。やはり大きな画像のリサイズが重かったのでした。パソコン用のCPUではなく、携帯電話用のCPUですから負荷が大きいのでしょう。

　

レチナ・ディスプレイに対応するため画像サイズが大きくなり、さらに画像の数が多いので、できるだけ容量を増やさないようにと考慮し、画像をリサイズして使う設計にしました。しかし、そんな方法が裏目に出てしまいました。処理が遅くないように作らないとイライラして使えません。容量が増えてしまいますが、リサイズした画像を追加で全部用意することにしました。

パソコンと違って、まだまだ考慮すべき点があるのですね。勉強になりました。

SDK 2.0.1でも描画問題への対処は必要(3)

Titanium SDK 2.0.1GA2で、描画関係のバグが解消されているか調べる話の続きです。iPhone用アプリの開発で経験した、画面を回転させたとき、ImageViewやLabelが変な位置に描画される問題を取り上げます。前の投稿で直っていると書きましたが、対処方法を実施しても消えなかったバグが出なくなっただけで、対処方法を不要するレベルで直っているかは不明でした。そこを調べたので報告します。

　

まずはバグの内容を。画面を回転させたときにアニメーションで表示されますが、縦横表示で同じViewを使い、View上のUI部品の位置を回転時に変更すると、設定したtopやleftの値とは全然違う位置に表示される問題です。発生する条件ですが、複数のImageViewの位置を変更させると起こるようです。単に位置が変になるだけではなく、本来なら下に隠れているImgeViewの一部も表示されてしまいます。対処方法は、次のような形でした。見えているUI部品だけの位置を変更し、下に隠れているUI部品はsetTimeoutで遅延させて変更する方法です。この対処方法でほとんど解消したのですが、たまに実機でのみ、一部のLabelが変な位置に表示されます。

以上にような状態のまま2.0.1GA2で再ビルドすると、実機でも変な位置の表示が解消されました。その点では、問題が解消されたといえます。しかし、本来なら特別な対処方法（一部の設定を遅延させる）を使わなくても、プロパティで指定した位置に表示すべきものです。それが直っているかどうか、シミュレータと実機の両方で確認してみました。

　

まず、対処方法を加えたコードです。画面が回転したときに呼び出される関数として作ってあります。表示中のUI部品だけは位置プロパティを変更し、残りのプロパティ変更は遅延した別関数として作りました。このような形で作ると、シミュレータ上ではバグが完全に消えました。ただし実機でのみ、少しバグが出ます。

// １つだけImageViewを変更する
function changeOrientF() {
    var orient = Ti.Gesture.orientation;
    if (orient == Ti.UI.PORTRAIT || orient == Ti.UI.UPSIDE_PORTRAIT) {
        imgView1.height = 240;
        imgView1.width = 320;
        ...
    } else if (orient == Ti.UI.LANDSCAPE_LEFT || orient == Ti.UI.LANDSCAPE_RIGHT) {
        imgView1.height = 320;
        imgView1.width = 427;
        ...
    }
    setTimeout(changeOrient2F, 200); // 0.2秒後に動かす
}
// 残りのImageViewを、時間差を付けて変更する
function changeOrient2F() {
    var orient = Ti.Gesture.orientation;
    if (orient == Ti.UI.PORTRAIT || orient == Ti.UI.UPSIDE_PORTRAIT) {
        imgView2.height = 240;
        imgView2.width = 320;
        ...
    } else if (orient == Ti.UI.LANDSCAPE_LEFT || orient == Ti.UI.LANDSCAPE_RIGHT) {
        imgView2.height = 320;
        imgView2.width = 427;
        ...
    }
} 

このコードを、本来の形に戻します。遅延する関数として２つに分けるのではなく、すべてのプロパティ変更を一緒にして、１つの関数として作ります。具体的なコードは、次のようになります。

// すべての変更を１つにまとめる
function changeOrientF() {
    var orient = Ti.Gesture.orientation;
    if (orient == Ti.UI.PORTRAIT || orient == Ti.UI.UPSIDE_PORTRAIT) {
        imgView1.height = 240;
        imgView1.width = 320;
        ...
        imgView2.height = 240;
        imgView2.width = 320;
        ...
    } else if (orient == Ti.UI.LANDSCAPE_LEFT || orient == Ti.UI.LANDSCAPE_RIGHT) {
        imgView1.height = 320;
        imgView1.width = 427;
        ...
        imgView2.height = 320;
        imgView2.width = 427;
        ...
    }
}

ご覧のように、難しい変更ではありません。バグが解消していれば、一部のプロパティ変更を遅延させなくても、正常な位置に表示されるはずです。

　

さて実際に動かした結果ですが、シミュレータでも実機でも、変な位置に表示されるバグは出ませんでした。ImageViewもLabelも、プロパティで設定した位置に表示されます。動作中のいろいろなタイミングでiPhoneを回転しましたが、途中の状態はさておいて、最後には正常な位置で表示しました。アプリのアニメーション中に回転アニメーションが加わっても、いつも正常な位置に収まります。2.0.1GA2では、バグが解消されているようです。

画面回転での表示バグは、いろいろな対処方法を試しましたが、どうしても解決しなかったものでした。SDKのバージョンアップで解消され、本当に良かったです。バグが消えたことで、特別な対処方法を用いる必要がなくなりました。

　

ここまで３回の投稿を整理すると、2.0.1GA2で対処が必要な描画問題は、フラッシュバック症状だけになりました。これは前から対処方法を見付けていますから、ぜんぜん大丈夫です。2.0.1GA2では対処方法をpostlayoutイベント処理で実現しますが、非常に簡単な変更でした。この１つだけで大丈夫になったということは、Titanium SDKのレベルアップではないでしょうか。まさに意味のあるバージョンアップですね。

2.0.1が安定したバージョンになれば、もう安心して公開できます。画像がメインのアプリなので、あとは画像とテキストの制作待ちですが、SDKの安定バージョンが出る頃には、制作も終わっているでしょう。めでたし、めでたし。

SDK 2.0.1でも描画問題への対処は必要(2)

Titanium SDK 2.0.1GA2を使って、描画関係の問題が解消しているか調べる話の続きです。その問題とは、hide中のViewで、ViewにaddしたUI部品の位置や内容を変更してから、Viewをshowしたとき、変更前の状態が一瞬表示されることです。フラッシュバック症状と呼んでいます。前回は、UI部品の変更を箇所を何も変えず、setTimeoutで処理していた箇所を、postlayoutイベント処理に変更した話でした。この簡単な変更だけでも、問題なく動きました。

　

いよいよ今回は、UI部品を変更する箇所の改良です。Titanium SDK 2.0.1に追加された、UI部品の複数プロパティ変更を、１つの変更のように扱う処理を利用します。単独で使うupdateLayout関数と、ペアで使うstartLayout関数とfinishLayout関数の、2種類が用意されています。どちらも、ViewまたはUI部品で使う関数なので、単独のViewまたは単独のUI部品が対象となります。

今回のアプリでは、View上の複数部品を一緒に変更するため、すべての変更が終わってから、変更が完了したと知らせる必要があります。ペアで使う関数しか役に立ちません。実際のコードは次のようにしました。

// 変更の開始を知らせる
imgView.startLayout();
label1.startLayout();
label2.startLayout();
view.startLayout();

// 各UI部品を変更
imgView.top = 120;
imgView.left = 200;
imgView.image = photoName[i];
...

// 変更の終了を知らせる
imgView.finishLayout();
label1.finishLayout();
label2.finishLayout();
view.finishLayout);

// viewを表示
view.show();

シミュレータ上で動かしてみると、まったく変わりません。変更前から正常に動いているため、当然でしょう。フラッシュバック症状が出るかどうか確認するために、postlayoutイベント処理をsetTimeout処理に戻し、遅延時間を１ミリ秒に設定して動かしました。しっかりとフラッシュバック症状が出ます。症状を消すためには、はやりpostlayoutイベント処理が必要でした。

この後、viewをshowする処理の位置などを変更しながら動きを観察していて、大事なことに気付きました。Viewをhideしている状態ですから、描画機能は動いてません。その状態でView上のUI部品を変更しても、プロパティの値が変更されるだけです。そしてViewがshowされたときに、設定されたプロパティで描画内容を生成します。そのshowの最初に、フラッシュバック症状が発生するというわけです。変更前のフラッシュバック症状がshowしたときに出るということこそ、showした時点から描き始めている証拠です。

整理すると、startLayout関数とfinishLayout関数は、showされてる状態で有効なのであって、hideされているときに使っても意味がないのです。もちろん、ここで試さなかったupdateLayout関数も同様です。今回のアプリのようにhide中の変更では、単に無駄に処理を加えているだけとなります。意味なしです。というわけで、startLayout関数とfinishLayout関数を削除しました。

　

新しい関数の使用条件を理解していなかったので、予想外の結果となりました。結局、フラッシュバック症状への対応は、前回の投稿と同じまま、setTimeout処理をpostlayoutイベント処理に変更するだけで完了です。回り道をしましたが、startLayout関数とfinishLayout関数などの役割を理解できたので、良しとしましょう。この結果を知っていたら、前の投稿と一緒に書いて構わなかったですね。まあ、こんなこともあります。

SDK 2.0.1でも描画問題への対処は必要(1)

このブログでは、Titanium Mobileを使った際の画面表示の問題と格闘してきました。少し前の投稿では、リリースされたSDK 2.0.1GA2を使うことで、最大の問題だったImageViewやLabelが変な位置に表示される症状が、直ったとの速報を書きました。あれから使い続けていますが、症状は１回も発生していません。直っているのは確実なようです。

描画関係では他にも問題があり、その１つ１つが直っているのか、直っていないなら同じ対処方法で大丈夫なのか、１つずつ見直したいと思います。まずは、Viewのレイアウト変更への対処を取り上げます。

　

以前の投稿「Viewはshowしたときに描き直されるもの？」で、レイアウトを変更したときの対処方法を書きました。おさらいすると、問題は、hideしていたView上にあるImageViewやLabelの画像やテキストや位置を変えた後、showすると変更前の状態が一瞬だけ表示されることでした。フラッシュバック症状と呼んでいます。対処方法は、Viewの透明度を限りなく透明に設定してからshowし、setTimeoutで遅れて透明度を不透明に戻す方法でした。

まず調べたのは、SDK 2.0.1GA2でも、UI部品を変更する前の状態が一瞬表示されるフラッシュバック症状が出るかどうかです。setTimeoutの遅延時間を極端に短い1に設定して、シミュレータ上の動作を見てみました。結果は、前と同じです。SDK 2.0.1GA2でも、同様のフラッシュバック症状が出ました。つまり、この部分の動きは変わっていないということです。

ただし、何も対処していないわけではありません。SDK 2.0からは、プログラムの作り方で対応するように、新しい機能が追加されています。the UI Layout Systemが更新され、UI部品の大きさに関するデフォルト値が変わりました。同時に、描画での作業終了を考慮した機能が追加されています。それぞれのUI部品ごとに、複数プロパティを変更するときの処理を１つとして扱い、全部が終ったら描画する形も可能になりました。具体的な方法が２つ用意されていて、まずupdateLayout関数では、複数のプロパティを一度に指定できます。もう１つのstartLayout関数とfinishLayout関数はペアで使い、この間にプロパティの変更処理を入れます。

さらに、描画内容を生成し終わるまでの待つ機能が加わっています。それがpostlayoutイベントで、変更するViewやUI部品にイベント処理を加えれば、setTimeoutで処理を遅らせる必要はありません。setTimeoutで遅らせる方法では、少し余裕を持った待ち時間を設定するため、全体として処理が遅くなります。ところがpostlayoutイベントで知らせる方法だと、描画内容を生成し終わったら始められますから、無駄な待ち時間は生じないはずです。

SDK 2.0.1での変更点は、Appceleratorの開発者向けドキュメントに記述してあります。興味のある方は「Transitioning to the New UI Layout System」を読んでみてください。

　

開発中のアプリで、SDK 2.0.1GA2での改良を反映させてみました。フラッシュバック症状は前と同様に出ますから、時間を遅らせて表示させる処理は必要のままです。ただし、実現方法としては、setTimeoutで遅延させる方式から、postlayoutイベントで処理を開始する方式へと切り替えます。これで無駄な待ちが少しは減るでしょう。まずは、これまで実施していたsetTimeoutによるコードです。

// 修正前（setTimeoutを使用）
view1.hide();          // view1を非表示にします
view1.opacity = 0.001; // view1を限りなく透明にします
label1.top = 40;       // view1上のUI部品のプロパティを変更して、画面上のレイアウトを変えます
label1.left = 30;
imgView.top = 120;
...
view1.show();                  // view1を再表示します
setTimeout(resetOpacityF, 50); // 50ms後に、不透明に戻すfunctionを起動させます
// この関数は、ここで終了

function resetOpacityF(){      // 時間差攻撃で、view1を不透明に戻します
    view1.opacity = 1;
}

これを、処理内容は同じまま、postlayoutイベントで処理するコードに切り替えます。具体的には、次のように作ります。

// 修正後（postlayoutイベントを使用）
view1.hide();          // view1を非表示にします
view1.opacity = 0.001; // view1を限りなく透明にします
label1.top = 40;       // view1上のUI部品のプロパティを変更して、画面上のレイアウトを変えます
label1.left = 30;
imgView.top = 120;
...
view1.show();                  // view1を再表示します
view1.addEventListener('postlayout', resetOpacityF); // イベント処理を設定します
// この関数は、ここで終了

function resetOpacityF(){      // postlayoutイベントで、view1を不透明に戻します
    view1.removeEventListener('postlayout', resetOpacityF); // イベント処理をクリアします
    view1.opacity = 1;
} 

setTimeoutの代わりとして、postlayoutイベント処理関数をaddEventListenerでViewに加えています。これで描画内容の生成終了待ちとなります。postlayoutイベントが発生すると、設定したイベント処理関数の実行が始まり、まず最初にremoveEventListenerでイベント処理関数を削除し、本来の処理を開始します。以上のように、ほとんど前と同じままで、変更が完了してしまいました。

　

view1をshowした直後にpostlayoutイベント処理を追加し、そのまま待ちます。本来ならshowする前にイベント処理を追加すべきなのですが、描くのに時間がかかるためでしょう、これでも問題なく動きました。さらには、UI部品の変更を１つにまとめる変更もしなければならないのですが、それをする前に試しに動かしたら、正常に動いてしまいました。すぐにremoveEventListenerを実行しているためでしょうね。アプリの動作としては、フラッシュバック症状が発生せず、とくに副作用もありません。こんなに簡単に動いて良いのでしょうか、と疑問に思うぐらい簡単に動きました。

本来であれば、UI部品の箇所も一緒に変更して公開すべきでしょう。でも、簡単な変更でも正常に動いたので、これも面白い情報だと思って公開しました。完全ではない変更でどのように動くかも、意外に貴重な情報となるからです。期待どおりに動かなかったケースで、こういう完全でない変更での動きが、解決方法を見付けるヒントになったりしますので。

　

動いたのを確認しただけでは、ちょっと満足感が不足です。postlayoutイベントが発生するまでの時間はどの程度なのか、やはり気になりますよね。そこで、イベント発生までの時間を計測してみました。addEventListenerの直前に時刻を計り、removeEventListenerの直後にも時刻を計って、差を求めるだけです。イベント処理の追加と削除を含めたのは、これらの処理も含めた経過時間を知りたかったからです。計算した時間差を表示する機能を加えて、実際に実行してみました。

描画内容を生成する時間は、UI部品の種類や数や変更内容によって左右されます。計測結果は、あくまで今回のアプリの場合です。postlayoutイベントを使った箇所は２つで、両方とも測定しました。１番目の箇所は、変更するUI部品の数が６つで、４つがLabel、２つがImageViewです。６つとも位置を変更し、それぞれの値であるテキストと画像も毎回変更します。たまにですが、一部のUI部品で位置だけ変更しない場合もあります。こうした条件のアプリをシミュレータ上で計測したところ、最低では0、最高で41の値となりました。数値の単位はミリ秒で、マシンは現行の13インチMacBook Air（Core i5 1.7GHz Dual）です。発生頻度が一番高いのは0で、全体の３割ぐらいを占めていました。0を含めた一桁台が全体の半分程度ありました。数値が極端に大きいときは、画像をメモリーに読み込んでいるとか、ガベージコレクタが動いているとか、特別な条件なのでしょうか。原因は不明です。

２番目の箇所は、変更するUI部品が半分の３つで、２つがLabel、１つがImageViewです。これらへの変更内容は１番目と同じですが、透明度を変更する処理が加わっています。上記のサンプル・コードは、この２番目の箇所のものでした。計測すると、50〜52と値はほぼ一定でした。このようにバラツキがほとんどないのが普通だと思います。１番目の箇所でバラツキが生じた理由が分かりません。

同じ計測を、実機でも試してみました。初代iPadで実行すると、１箇所目は最低が6で、最高が62でした。全体的に値が大きくなっています。頻度としては小さな値の比率が大きく、とくに一桁が半分程度を占めるという変な結果となりました。バラツキの傾向も非常に似ていて、シミュレータが正常に機能していることを証明した感じです。まあ、当たり前の結果でしょう。２番目の箇所もシミュレータと似ていて、値は56〜67とバラツキは小さいです。１番目の箇所と同様に、シミュレータよりも少し遅くなっています。

余談ですが、setTimeoutでは50に設定していたので、最高が67という結果では、修正前の50という値が小さすぎたのかも知れません。しかし、実機でかなり使いましたが、描画の問題は出ませんでした。postlayoutイベントが発生するタイミングに多少の余裕があるのか、描画内容としてギリギリだと目立たないのか、その辺は分かりません。修正前の50という値は、単なる偶然ですが、一番遅い初代iPadによる実機での動作としては絶妙な値だったのでしょう。

　

計測結果では、片方の描画は非常に短い時間が多くなりましたが、実機を触っている限り体感できません。もともと短い時間なので、少しぐらい減っても体感できないのでしょう。今回の修正により、固定した時間だけ遅らせるのではなく、実際の描画内容生成が終わるまで待つ形になりました。処理としては、より良い形になっています。あまりにも簡単な修正でしたが、最適化された形となりました。今後も、似たような状況では、postlayoutイベント処理を使うでしょう。

UI部品の変更は、次の投稿で書きます。また別な症状の確認も残っていますから、それは後でということで。

間接参照は利用側の目的指向で作成する

じっくりとテストする時間が取れないので、今日は少し、ソフトウェアを作るときのコツというか考え方について少し書きましょう。取り上げるのは、基本中の基本といえる間接参照です。

　

ソフトウェアの中で、幅広く利用されている作り方に間接参照があります。データ自体を直接参照する代わりに、間に１つ以上の参照を挿入し、何段階かの参照を組み合わせる方法です。ハードウェアに近い部分からアプリケーションまで、幅広く使われています。

たとえば、OSのメモリー管理を間接参照にすることで、使っているメモリー部分を集めるために、メモリー上のデータをOSが移動しても、アプリでは問題なくメモリー上のデータが使えるのは、間接参照のおかげです。オブジェクト指向の仕組みも、間接参照の凝った使い方です。ソフトウェアの柔軟性を増すための基礎的な仕組みが間接参照なのです。

もちろん、欠点もあります。参照回数が増えることで、そのための処理が必要となり、処理速度は低下します。しかし、CPUパワーが向上した現在では、あまり気にならなくなりました。それ以上に、ソフトウェア変更での柔軟性を増す価値のほうが格段に大きくなっています。

　

このブログの最初のほうで、UI部品を生成するための関数を紹介しました。最終版は次のようなコードでした。

// ボタンの生成（base.js）
exports.createBtnF = function(_title, _fontSize, _height, _width, _top, _left){
    return Ti.UI.createButton({
        title:_title,
        font:{fontSize:_fontSize},
        height:_height,
        width:_width,
        top:_top,
        left:_left
    });
}

// 上記の関数を利用する（main.js）
bbb = require("base"); // レベル1を使えるようにする
(function() {
    bb.win = bbb.createWinF('prod_edit');
    var btnOpenPe = bbb.createBtnF(bb.win, '商品編集', 24, 40, 200, 100, 32);
    btnOpenPe.addEventListener('click', openPeWinF);
    ...
})();

これも間接参照です。UI部品の生成コードを直接書く代わりに、生成関数を呼び出す形にします。メリットとしては、生成する部分のコードが１行で済むことです。加えて、生成するボタンのデフォルト設定を自由に変えられます。また、デフォルトを変更して使うボタンでは、生成直後に変更する部分（主にプロパティ）の変更コードを追加するので、どこを変えたのか一目瞭然となります。間接参照ならではのメリットです。

このような使い方を、間接参照の利用方法として捉えると、設定の挿入と見ることができます。参照を間に１つ挿入しながら、挿入した部分でデフォルト設定を持てるようにしてるわけです。デフォルト設定を持つことで、デフォルト設定を変更するときの柔軟性を確保するとともに、利用する側での記述も減らしています。

　

他の例では、プログラム内で使う定数宣言も間接参照です。C言語の時代から普通に行なわれていました。JavaScriptにも同様の構文があり、constを付けて宣言します。JavaScriptに限りませんが、定数宣言の作り方には少し注意点があります。例で説明したほうが分かりやすいでしょうね。アプリで表示するメッセージの色を定義する場合を考えてみましょう。エラーなら赤、注意なら青、処理が成功した報告では緑、その他は黒と決めました。そのまま、次のように作ることも可能です。

// メッセージの色を定数宣言（色で名前を付ける）
const COLOR_RED = '#f00';    //色：赤
const COLOR_BLUE = '#00f';   //色：青
const COLOR_GREEN = '#0a0';  //色：緑
const COLOR_BLACK = '#000';  //色：黒

このように作れば、色を細かく変える場合に変更は一箇所で済みます。しかし、処理成功を青、注意をオレンジに変更したくなったらどうでしょう。もちろんCOLOR_GREENを青色の00fに変更すれば可能ですが、GREENと定義してあるのに色が青では混乱の原因になります。それを避けようとして、COLOR_GREENと記述してある箇所を、すべてCOLOR_BLUEに置き換えることになるでしょう。

同じ内容を、もっと違った視点で作ると、より変更に強い作り方になります。色の名前で定義するのではなく、各色の利用目的の名前で定義するのです。具体的には、次のように作ります。

// メッセージの色を定数宣言（色の利用目的で名前を付ける）
const COLOR_ERROR = '#f00';  //色：赤
const COLOR_ALERT = '#00f';  //色：青
const COLOR_OK = '#0a0';     //色：緑
const COLOR_STD = '#000';    //色：黒

色の利用目的で名前を作り、何色なのかはコメントで示しています。このような形だと、宣言した名前が「エラーの色」となっているため、エラーの色は何色でも大丈夫になります。エラーの色は、エラー表示の箇所でしか使いませんから、余計な置き換えも生じません。色の変更も、色の値とコメントだけで済みます。毎回、たった１行の変更で済むでしょう。

　

実は、上の例こそ、間接参照を上手に使う鍵なのです。間接参照を作るときに間に入れるもの（上の例ではconstによる定数宣言）は、それを「使う側の利用目的ごとに別々に用意する」のが基本なのです。逆に、色の名前で作ったものは、利用目的ではなく、値そのものの名前で作ったと捉えることができます。値そのもので名前作ったわけですから、値の変更に名前が影響されます。その名前は参照に使う名前なので、利用する側の変更も生じさせ、変更への柔軟性が低下するわけです。間接参照を名前で参照する以上、「参照で使う名前を変えなくて済むように作る」というのが大事なのです。

「別々に用意する」の意味が分かりやすいように、同じ色定義の例を利用しながら、もう少し別な状況を考えてみましょう。メッセージの色に加えて、枠線の色も何種類か使う状況だとします。この場合も、色の名前で定数宣言すると、前にも増して大変なことになります。メッセージの赤と枠線の赤が一緒に宣言してありますから、片方だけ変えたいときに、色の値を変更すると、もう片方の色も一緒に変わってしまいます。両者を区別するためには、二つの宣言に途中で分けなければなりません。具体的な作業としては、COLOR_REDを使っている箇所を全部調べて、片方を別の名前に変更する必要があります。考えただけでも大変そうです。直し忘れが生じていて、公開してから気付いたなんて状況も起こりそうで怖いです。

では、どのように作るべきなのでしょうか。鍵は「使う側の利用目的ごとに別々に用意する」ですから、メッセージの色と枠線の色では利用目的が異なります。たとえ同じ色であっても、別々に定義するのが基本です。次のような形になるでしょう。

// メッセージの色を定数宣言
const COLOR_MSG_ERROR = '#f00';  //色：赤
const COLOR_MSG_ALERT = '#00f';  //色：青
const COLOR_MSG_OK = '#0a0';     //色：緑
const COLOR_MSG_STD = '#000';    //色：黒
// 枠線の色を定数宣言
const COLOR_BORDER_EDIT = '#f00';   //色：赤
const COLOR_BORDER_BROWSE = '#00f'; //色：青
const COLOR_BORDER_CHECK = '#0a0';  //色：緑
const COLOR_BORDER_ETC = '#000';    //色：黒

色の定数宣言だと示す言葉COLORに続いて、利用目的の分類または対象となる言葉のMSGかBORDERを付けます。最後に、分類または対象ごとの、具体的な目的を示す言葉を加えれば完成です。今回の例では、最初の定数宣言をMSG入りに変更しました。同じことが、開発の途中で起こりえます。そうなると利用する側の変更が生じるでしょう。ですから、メッセージの色しか作らない場合でも、最初からMSGを入れて定数宣言するのが、より良い作り方といえます。

上記の定数宣言は、まったく同じ色を宣言していますが、利用する目的が異なるから別々に作ったわけです。定数宣言の重複だと考える必要はありません。この作り方のほうが、変更への柔軟性は格段に上です。

　

ここまででも、予想外に長くなってしまいました。続きは、気が向いたらというか、別な機会に書くということで。

Titanium StudioでのXcode選択を4.2から4.3へ変更

前回の投稿で、Titanium Studioを2.0.1にアップデートし、Xcode 4.3.2を使ってテストした話を書きました。その際に少しだけ面倒な手順を踏んだので、その話を書きましょう。

　

アップデートの順番が関係しているため、行なった順に説明します。最初はTitanium Mobile SDK 2.0.1.GAの通知が来て、それをインストールしました。続いて同GA2の通知が来て、それもインストールしました。この時点で、2.0.1はまったく使っていません。そのまま1.8.2を使い続けていると、Titanium Studio 2.0.1のアップデート通知が届きました。すぐにインストールして、少し使ってみます。問題なく使えました。

Titanium Studio 2.0.1は、Xcode 4.3に対応していたことを思い出し、Xcode 4.3をインストールすることにしました。アップルの開発者向けサイトにアクセスすると、最新版のXcode 4.3.2は、Mac App Storeからダウンロードする形になっていました。App Storeアプリを使ってアクセスしたら、ダウンロードのページが開きます。使用者の感想が書いてあって、Xcode 4.3からはボリューム直下の「Developer」フォルダがなくなり、アプリ内に移動したことへの文句などがありました。おかげで、そのことを知ることができました。

余談を少しだけ。文句を言ってる人もいましたが、「Developer」フォルダをアプリ内に持つことは良い改良だと思います。ボリューム直下の「Developer」フォルダだと、マシン上には、Xcodeアプリを１つだけしかインストールできません。インストールはできるのですが、細かな互換性の問題などで１つしか正常に動かないでしょう。反対にアプリ内に持つ形だと、バージョンの異なるXcodeアプリを何個でも併用できます。「Developer」フォルダが別々な場所にあることで、互いに影響を受けないからです。もちろん、別々のフォルダになっているため、追加するファイルを両方に入れなければならない欠点も生まれます。しかし、その欠点も、入れる入れないを別々に決められる利点と背中合わせなので、一概に欠点とは言えないでしょう。Xcodeに付属するアプリに関しても、別々に持つ形になりますが、これもバージョンの異なるアプリを混在できるというか、それぞれ別々に持てる点でメリットが大きいと言えます。

話を戻しましょう。Xcode 4.3.2のインストールです。Mac App Storeからダウンロードを選ぶと、ダウンロードからインストールまで自動で行なわれます。気付いたときには、「アプリケーション」フォルダ内にXcode 4.3.2がインストールされていました。

　

さて、ここからが本題です。Titanium Studio 2.0.1を先にインストールしたためか、Titanium Studioからシミュレータなどを起動させると、古いXcode 4.2が使われてしまいます。まあ当然の結果でしょう。試しに、古いXcode 4.2が入っている「Developer」フォルダをゴミ箱に入れてからTitanium Studioを動かしても、エラーが出るだけで、Xcode 4.3.2に切り替わってはくれません。これは少し残念だけど、当然でしょうね。

ビルドしたアプリを、とりあえずXcode 4.3.2動かそうと思い、古いXcode 4.2の「Developer」フォルダに入っているTitanium Mobile関係のファイルを、Xcode 4.3.2側にコピーしてみました。Xcode 4.3.2側というのは、Xcode 4.3.2アプリの中に含まれている同様の位置関係のフォルダです。その後、ビルドで生成されたアプリのXcodeプロジェクトファイルをXcode 4.3.2で開き、再ビルドしてシミュレータを起動できました。

　

こんな形で動かすのはダメですから、普通にXcode 4.3.2が使えるように設定しなければなりませんね。Titanium Studioの環境設定を探すと、それらしい設定がありました。環境設定で「Aptana Studio」の「Titanium」を開いて、上から２番目に「iOS SDK Home」の設定があります。設定中のパスの文字列から、ここが指定箇所だと判断できました。古いXcode 4.2のフォルダを指しています。ここをXcode 4.3.2のフォルダに変更すれば、Xcode 4.3.2のシミュレータなどが普通に呼び出されるはずです。

この部分の設定方法が少し変わっていて、普通には設定できません。xcode-selectコマンドを打つようにとの記述があります。「More Details」のリンクがあるので表示させると、詳しい説明ページがウェブブラウザで開きました。説明どおりに実行するために、ターミナルを動かします。最初はTitanium Studioに含まれているターミナルのウィンドウを使おうとしましたが、コピーした文字列をペーストできません。仕方がないので、Mac OS Xのターミナルを起動し、xcode-selectコマンドとオプション、Xcode 4.3.2のパスをペーストして実行しました。最後に、Titanium Studioの環境設定に戻り、「iOS SDK Home」設定の「Refresh」ボタンをクリックして切り替えが完了です。正しく切り替えられたか確認するために、プロジェクトをクリアーしてからビルドして、シミュレータを動かしました。Xcode 4.3.2に付属のシミュレータ5.1が起動して、正常動作が確認できました。ちなみにシミュレータ5.1は、新しいiPadのRetinaディスプレイに対応しています。

おそらくターミナルで実行したコマンドか「Refresh」ボタンが、必要なファイルをコピーしてくれるのでしょう。でも私の場合は、先に手作業でコピーしてしまったため、コピーしてくれるか確認ができませんでした。正しい方法で行なわないと、正常な動きを知ることができないという駄目の典型ですね。消して再実行すれば確認できないことはないのですが、面倒なので行ないません。興味のある方は試してみてください。

Xcode 4.3.2を先にインストールしてから、。Titanium Studioを2.0.1にアップデートすると、Xcode 4.3.2に切り替えてくれるのでしょうか。少し興味がありますけど、古いTitanium Studioを再インストールしないと調べられないので試しません。これも、興味のある方は試してみてください。試すというより、Xcode 4.3.2を先にインストールしてから、Titanium Studioをアップデートしたほうが良いでしょうね。

今回はXcode 4.2から4.3へ変更しましたが、同じ操作方法で逆の変更も可能です。試しに変更してみても、簡単に戻せるから安心でしょう。ただし、切り替え方法が少し面倒なので、もう少し簡単になると嬉しいのですが。

　

以上のように、もうXcode 4.3.2に切り替えて使っています。まだXcode 4.2.1を残してありますが、4.3.2で問題なく使えると判断した時点で削除する予定です。