Titanium SDK 2.0.1でImageViewのバグが解消した様子

Titanium Studioも2.0.1にバージョンアップし、Titanium SDKも2.0.1.GA2のアップデートが来たので、ImageViewのバグがどのように変化しているのか、さっそく試してみました。ついでに、Xcodeも4.3.2を入れての組み合わせです。開発中のiPhoneアプリは、ソースコードなどを全く直さず、Titanium SDKとして、1.8.2を2.0.1.GA2に変更しただけです。

　

まずは、シミュレータでの動作確認。ここは前から問題なしだったので、そのまま通ると予想しました。確かに、動作としては問題なく表示されていました。ただし、コンソールにはワーニングがいくつも出ました。Titanium SDKが仕様変更されていて、直さなければならない箇所があるようです。あとで詳しく調べて、きっちり修正しましょう。

続いて、実機での確認です。ここもXcodeが4.3.2に変わっただけで、設定などは以前と同じです。Ad-Hocでアーカイブを作成し、iTunesでiPhoneに転送しました。ドキドキの動作確認ですが、まったく問題ありませんでした。今までだと、画面を何度も回転させると、ImageViewは何とか正常に表示されたのですが、一緒に表示するLabelの位置が変になっていました。以前はすぐに症状が出ましたが、かなり操作しても出ませんでした。どうやら直っているようです。

LabelもImageViewと同じ対策をすれば、前のSDKでも解決できたかも知れません。しかし、症状が出ている状態で、Titanium SDK 2.0.1.GA2での動作を確認したかったのです。直っていることを期待して、作成中のアプリで確かめたかったというわけです。

Titanium SDK 2.0では、描画関係に大きなメスが入れられたようで、根本的に改良されたのでしょう。それによって、一連のバグが直ったと思われます。今まで頑張って見付けた対策も、もしかしたら必要ないかも知れません。その辺も、あとで調べる必要があります。とりあえず、症状が消えたことで、安心しました。もっと本格的なテストは必要ですが、たぶん大丈夫でしょう。Titanium Mobileを避ける大きな理由が消えて、凄く嬉しいです。

　

Xcodeのみでの開発も、少しずつ勉強を進めています。Objective-Cでの開発も覚えておいて損はないでしょうから、このまま続けます。Titanium Mobileで作成中の３つめのアプリを、同じ形で作ろうと進行中です。まあ、保険という意味も少しはあります。もう必要なさそうですけどね。とりあえず、最初のWindowを表示しTableViewを動かす部分までは作りました。

Objective-Cを使って気付いたのは、Titanium Mobileでの作りやすさです。あらためて実感しました。まだObjective-Cに慣れてないという点もありますが、それを差し引いても、JavaScriptで気軽にさくさく作れる点は大きな魅力です。私自身、JavaScriptはブラウザ用に数行程度しか使ったことがなく、Titanium Mobileで本格的に勉強を始めました。ほとんど知識がなかったのですが、意外に早く作れるようになりました。やはりスクリプト言語の威力は凄いです。それに比べるとObjective-Cは、JavaやCを使ったときのような注意深さが必要です。

　

簡単なテストだけでしたが、Titanium SDK 2.0.1.GA2ではImageViewおよびアニメーション関連のバグが解消したようで、大きな懸念が取り払われました。2.0.1がどんどん使われ、安定した状態になるのを大いに期待してます。次のアプリも、Titanium Mobileで開発することになるでしょう。めでたし、めでたし。

Objective-Cも併用することに決めました

Titanium Mobileでアプリ開発を始め、さくさくと作れる点は非常に気に入っているのですが、バグとの格闘に疲れ気味です。また、最新iOSや純正の開発環境に追いつかず、少し前のバージョンで使う状況にも、少し残念な面があります。そこで、Objective-Cも勉強し、Xcodeのみでの開発もマスターすることにしました（ちなみに、Titanium Mobileによる開発でもXcodeが一部で使われてます）。

簡単にまとめると、Titanium Mobileでのアプリ開発と、Xcodeのみのアプリ開発を併用すると言うことです。使い分けの基準は、Titanium Mobileでバグに当りそうなときはXcodeのみ、それ以外はTitanium Mobileという感じでしょうか。同じ画面内でImageViewを複数使うようなアプリでは、Titanium Mobileを使わないようにします。

　

Xcodeのみの開発に必要が勉強は、昨日から始めました。まずObjective-Cの勉強で、友人から良い資料を教えてもらい、それを読み終わりました。約５時間ぐらいで、全体像が把握できました。記憶に頼ると忘れるので、特徴をメモしながらの勉強です。そのメモを見直すことで、いつでも素早く使えるようにしてます。Objective-Cは、もう大丈夫です。

続いて、アプリ開発の全体像と、フレームワークの理解です。簡単なアプリを作り始めていて、少しずつ理解していく感じでしょうか。少し悩んだのですが、Interface Builderを使わない開発を選択しました。現在進行中の、Titanium Mobileでのアプリ開発と似た形になりますね。２週間ぐらいで、だいたい把握できれば良いのですが。

　

Titanium Mobileでのアプリ開発の現状も、少しだけ。前の投稿で、画面回転したときに位置が変になるのは、ImageViewだけだと書きました。もっと違う条件でテストしていたら、Labelも位置が変になる症状を見付けました。もちろん、Labelだけなら問題ないでしょう。複数のImageViewと一緒に回転させるから、症状が出たのだと思います。これもImageViewのように、同じサイズのViewで囲むと直るのか、後でテストする予定です。

こんな風に格闘している間に、Titanium Mobile 2.0.1GAと同2が来ました。もしかして、今まで遭遇した症状が直っているのでしょうか。まあ、それ以外の部分でのバグ取りがまだでしょうから、さっそく使うわけにもいきませんね。Titanium Mobileは非常に開発しやすいだけに、今までの症状が2.0で消えることを、強く願っています。

画面回転で画像だけ変な位置に

Titanium Mobileを使った２つめのアプリも、必要な機能はすべて作り終わりました。画像をじっくり見せるアプリなので、あとは中身の画像を用意するだけです。これは別途に作業するため、開発は一旦終了。このアプリはiPad専用なのですが、ミニ版としてiPhoneに移植することになりました。iPad版は横長での使用に限定しましたが、iPhone版は縦長でも使用するという話に。というわけで、画面回転に対応させる必要が生じました。そこで新たな問題と遭遇。その顛末、解決までの道のりを書きます。

　

画面の回転に対応させるのは、とても簡単でした。「orientationchange」イベントの処理を追加して、そこでWindow内のUI部品のレイアウトを変更します。複数のWindowがあり、それぞれにレイアウト変更の処理を加えました。メモリー消費を考慮して、ウィンドウは閉じたらメモリー解放する形にしています。画面回転のイベント処理もクリアーする必要から、addEventListenerで追加した処理を、removeEventListenerで削除しなければなりません。削除しやすいように、イベント処理は名前付きの関数を利用します。次のような形で。

// 画面回転の処理
function changeOrientF() {
    var orient = Ti.Gesture.orientation; // 関数で引数eを使わないように、このプロパティで縦横を判断
    if (orient == Ti.UI.PORTRAIT || orient == Ti.UI.UPSIDE_PORTRAIT) {
        view1.top = 100;
        view1.left = 0;
        ...
    } else if (orient == Ti.UI.LANDSCAPE_LEFT || orient == Ti.UI.LANDSCAPE_RIGHT) {
        view1.top = 0;
        view1.left = 200;
        ...
    }
}

考え方としては、UI部品をグループ分けして、それぞれ別なViewに貼り付けます。画面の縦横回転の際に、View単位で位置を調整してレイアウトを変更するようにしました。この考え方で、まったく問題ないはずでした。

　

いろいろなWindowで縦横回転を試すと、画像を入れたImageViewだけが、回転後に変な位置に表示されます。設定する値が間違ってるのかと思い、画面上にデバッグ用ボタンを追加し、回転アニメーションが終わってから、ImageViewのtopとleftの値を表示させました。すると、両方の値は正常に設定されていて、それとは関係ない位置にImageViewが表示されているのです。当然、明らかなバグです。しかし、どこのバグでしょうか。iOSか、Titanium Mobileか。

解決しなければならないので、症状を調べてみました。何十回と回転させると、表示させる位置にはパターンがあるようです。iPhoneの回転位置は４つあり、それぞれで決まった位置にImageViewが表示されました。また、何十回も続けて回転させると、ImageViewに表示される画像が少しずつ劣化していきます。縦位置と横位置ではImageViewの大きさが違い、一旦小さくなってから大きくなるとき、小さくなった画像を拡大して表示している様子でした。つまり、もとの画像ファイルを毎回読み込んでいるのではなくて、画面上に表示した画像を再利用して、回転したり拡大縮小しているというわけです。これらはすべて、アニメーション機能が動いていて、画質重視ではなく効率重視で設計されているのでしょう。

　

いろいろなWindowで観察していたら、ImageViewを１つしか使っていないと、正常な位置に表示されると分かりました。しかし、複数使っているWindowでも、１つ以外は下に隠れていて、画面上には表示されていません。そんな使い方のWindowでも、ImageViewが複数あると、すべてのImageViewが変な位置に表示されます。下に隠れているはずのImageViewまで、一部が表示されてしまうのです。そう、とんでもない症状です。

そこで、次のように考えました。回転し始めたときは、一番手前のImageViewだけ大きさと位置を変更し、他の下に隠れているImageViewは、時間差攻撃で大きさと位置を変更したら良いかも知れないと。JavaScriptは、次のようにしました。

// １つだけ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;
        ...
    }
}

この0.2秒という時間差は、回転アニメーションの時間を見て決めました。最初は0.3秒にしたのですが、少し余裕がありそうに見え、0.2秒に変更して問題なかったので0.2秒に落ち着きました。実際のアニメーション時間より、少し短いかも知れません。結果は、見事に成功でした。ImageViewが正常な位置に表示されます。

しかし、ここで安心してはいけません。あくまで、シミュレータ上での成功だけです。実機に転送して、最終確認をしなければ。さっそく転送した試したところ、見事に失敗でした。最初にシミュレータ上で乱れた位置とは、また別な位置にImageViewが表示されます。振り出しに戻りました。この時点で、少し凹みましたね。いったん成功したと思ったわけですから。

　

こんなときは、上手い珈琲でも飲んで一休みです。珈琲を飲みながら、別な対処方法を思い浮かべます。ImageViewだけ乱れるなら、ImageViewとまったく同じ大きさのViewを用意して、ImageViewを囲むようにして使ったらどうだろうか。さっそく、次のようなJavaScriptを作って試しました。

// ImageViewを定義する部分
var view1i = bbb.createViewF(view1, 240, 320, 120, 0); // 入れ物のView
var imgView1 = bbb.createImgViewF(view1i, strPhotoName, 240, 320, 0, 0);

// １つだけImageViewを変更する、画面回転の処理
function changeOrientF() {
    var orient = Ti.Gesture.orientation;
    if (orient == Ti.UI.PORTRAIT || orient == Ti.UI.UPSIDE_PORTRAIT) {
        view1i.height = 240;   // 入れ物のViewを変更
        view1i.width = 320;
        view1i.top = 120;
        view1i.left = 0;
        imgView1.height = 240; // ImageViewは、大きさだけ変更
        imgView1.width = 320;
        ...
    } else if (orient == Ti.UI.LANDSCAPE_LEFT || orient == Ti.UI.LANDSCAPE_RIGHT) {
        view1i.height = 320;   // 入れ物のViewを変更
        view1i.width = 427;
        view1i.top = 0;
        view1i.left = 53;
        imgView1.height = 320; // ImageViewは、大きさだけ変更
        imgView1.width = 427;
        ...
    }
    setTimeout(changeOrient2F, 200); // 0.2秒後に動かす
}

入れ物のViewと、入れるImageViewは、まったく同じ大きさにします。同じ大きさなので、ImageViewのtopとleftはゼロのまま固定。表示位置の変更は、入れ物となるViewのtopとleftの値で設定するわけです。

さて結果ですが、まずはシミュレータ上で試すと成功。ここで安心してはいけません。次に、実機へ転送して動作確認。やりました。大成功です。変な位置に表示される症状が出なくなり、本来の位置に表示されました。とりあえず、良かったです。

　

Titanium Mobileで開発を始めて、まだ３つめのアプリですが、いろいろと問題に遭遇しました。これからも遭遇しそうです。最初に作ったアプリでは、WebViewで苦労させられました。最近は、ImageViewで苦労しています。ここで以前に書いた、変更前の状態が一瞬だけ表示される症状も、ボタンやラベルで発生することはなく、WebViewとImageViewではほぼ確実に発生します。WebViewも、HTMLの評価結果を画像として表示していると捉えられ、画像を表示するViewが、Titanium Mobileの鬼門かも知れません。

開発効率を重視してTitanium Mobile/Desktopを選びましたが、意外に苦労が多くて困惑気味です。前からJavaやCを使っているので、Objective-Cでも苦労しないと思います。Xcodeに移行したら、今回のような問題が発生しないのであれば、移行する価値はありますね。というわけで、ちょっと悩み中です。

　

追記：表示する位置が変になる症状は、ImageViewだけではありませんでした。Labelでも発生することを発見しました。同じ対策が有効かどうか、あとで確認する予定です。

Viewはshowしたときに描き直されるもの？（続き）

何回か前に、「Viewはshowしたときに描き直されるもの？」のタイトルで投稿した内容に関して、実験しながら少し調べてみました。その辺の話をまとめて書きます。

　

そもそもの始まりは、ウィンドウ内のレイアウトを何種類かに変更する目的で、ImageViewやLabelの表示位置を変更したときの動きでした。ViewをhideしてからUI部品の表示位置や中身を変更すると、Viewをshowしたときに、変更前の状態が一瞬表示されてしまう問題です。それを回避しようと、Viewを限りなく透明にしたり、不透明へ戻すときに時間を遅らせて対応しました。

じゃあ、View上のUI部品の位置を変えなかったら、前の状態が一瞬表示される問題は発生しないのか。そんな疑問が残ったので、調べるために実際に動くサンプルを作って実験しました。まず、複数の固定レイアウトViewを用意して、UI部品の位置を変えない方法です。これでも、UI部品の中に表示するテキストや画像は変えますから、Viewをshowしたときの内容は、前に表示した内容と異なります。試した結果ですが、やはり変更前の内容が一瞬だけ表示されました。必ず表示されるわけではなくて、表示されることもあるという感じです。どの程度の割合で発生するかは、動作している環境によって変わりそうですが、意外に多いなと思いました。

次に試したのは、Viewの代わりにWindowを使う方法です。Viewの影響が生じないようにと、UI部品はWindowに直接addしました。Windowなので、showとhideではなくopenとcloseで、表示と非表示を切り替えます。この実験でも、UI部品の内容を変更して再表示し、古い内容を一瞬でも表示されるかを確かめます。気になる結果ですが、やはり同じでした。変更前の内容が、一瞬表示される症状が発生します。これも必ずではなく、たまに発生するという感じでした。

このような結果は十分に予測できました。UI部品を表示している部分のアルゴリズムが同じであれば、UI部品をaddする対象を変えたとしても、同じような動きになって当然です。やっぱり同じだったと確認できたのですが、本当は違ってほしかったところです。もし違えば、回避策の１つとして利用できたのですけど。

　

今回は複数の方法で同じ症状が発生しましたが、解決策がないわけではありません。UI部品に前の状態を作らなければ良いのです。表示する前に毎回、古いUI部品を削除して、新しいUI部品を生成する方法です。これなら前の状態が存在しないため、一瞬でも表示される症状は起こりえません。ただし、別な注意点が生まれます。再表示する度に、古いUI部品を捨てていくため、きっちりとメモリーを解放する必要があります。この辺の注意は、慣れている人なら問題ないでしょう。

個人的にですが、本来は必要ないのに、UI部品を次々に生成する方法は嫌いです。OS、開発ツール、自分のプログラムのどこかのバグに当りそうで、メモリーリークの危険度が増します。採用する気がないので、実験での確認はしませんでした。最初に対策した方法で、問題なく動いてますからね。

遅い処理での小さな心遣い

今回は、Titanium Mobileを使って開発しているアプリでの、ちょっとした心遣いのお話です。前回の投稿で、UI部品が100個以上にもなるViewの話が登場しました。実機でテストしていると、表示されるまでの遅さが気になります。たった2秒弱なのですが、表示されるまでの間に「あれ、動いてないのかな」と感じてしまいます。おそらく、人によっては画面をタップしてしまうでしょう。何か対策を打つのが、良い選択ではないかと考えました。

実際に処理中ですから、ActivityIndicatorを表示させるのが適切な選択でしょう。ActivityIndicatorが回っているのを見せれば、「処理してますから、少し待ってくださいね」と伝わります。ActivityIndicator自体は白いので、四角いグレーのViewを用意し、その中央で回ってもらいましょう。これも、いつものように生成関数を用意して、処理する側では1行で生成しました。JavaScriptは、次のようになります。

// 処理中を伝えるView表示
var view9 = bbb.createViewF(win, 256, 256, 220, 220);
view9.backgroundColor = '#ccc';
var activityIndicator = bbb.createActIndcF(view9, 110, 110);
activityIndicator.show(); 
// 本来のViewを生成（Viewをhideして多数のUI部品を追加）
var view1 = bbb.createViewF(win, 768, 768, 0, 0);
view1.hide();
var lblTitle1 = bbb.createLblF(view1, 'Viewタイトル', 24, 'left', 24, 'auto', 20,20);
...
// 処理中Viewを消す（削除する）
win.remove(view9);
// 本来のViewを表示
view1.show();

本来のview1を生成する前に、処理中だと伝えるview9を真っ先に生成して、そこにActivityIndicatorを追加してshowします。これで処理中の表示が始まりました。続いて、本来のview1とUI部品を生成します。ここが、一番時間のかかる処理ですね。生成が終わったら、処理中表示のview9をウィンドウから削除して、本来のview1をshowします。

上記のJavaScript全体は関数として呼び出す形なので、view1を生成すると終了します。処理中表示のview9は、ウィンドウから削除していますし、関数内の変数も関数の終了で消えてますから、view9で使ったメモリーは解放されるというわけです。本来のview1だけが画面に表示され、動き続けます。

実際に初代iPadで動かしてみると、受ける印象が全く違います。256x256サイズの四角いグレーの中に、ActivityIndicatorが回っているだけですが、待たされているという感じはぜんぜんありません。ActivityIndicatorが動いていて、それを眺めてしまうのが原因でしょうか。待っている際のイライラ感が完全に消えてしまいました。とりあえず、大成功のようです。

UI部品数が多いView表示の高速化

Titanium Mobileに限らず、iOS用のアプリ開発では、シミュレータで動作確認した後、実機に転送して確かめます。実機での動作で問題となるのが、シミュレータよりも遅い点です。開発に使っているのはMacBook Airの13インチ（Intel Core i5, dual 1.7GHz）で、Macとしては遅いほうに分類されます。そんなマシン上のエミュレータでさえ、iPadの実機よりも高速なのです。実機上のテストで遅いと、なんとか改良しなければなりません。

　

アプリでは複数のWindowやViewを扱いますが、UI部品が増えるほど描画が遅くなります。その限界は意外に少なく、View上に数十点のUI部品を付けると、気付く程度には遅くなります。今回は理由があって、あるViewだけは100個以上のUI部品を用いました。そのViewだけは、明らかに遅いです。

今回のアプリで描画が遅いのには、少し別な理由もあります。メモリーを節約しようと、描画が終わったらViewを破棄して、再度表示するときでも新しく生成し直しているのです。つまり、Viewを表示するたびに、UI部品まで含めて生成しています。このようなViewを、１つのWindow上で複数切り替えながら、使い分けています。Window上の一部だけ切り替えるため、Viewを切り替える方法がベストなのです。

生成するのがViewでなくWindowならば、openやcloseのタイミングで表示内容を描きます。しかしViewの場合は、openやcloseが用意されてなくて、別な方法で似たような機能を実現しなければなりません。それをせずに毎回生成すると、UI部品を１つずつ足しながら描いていくため、どうしても表示が遅くなってしまいます。

Viewでのopenやcloseの代わりは、showとhideでしょう。windowなら、最初からcloseした状態で生成されますが、Viewはshowした状態で生成されます。これを防ぐために、Viewを生成した直後にhideするか、hideした状態で生成します。試してみましたが、直後にhideする方法でも問題ないようです。通常は、Viewをshowした状態で生成するような関数を使ってますから、直後にhideする方法で問題ないなら、生成関数が１つで済むため都合がよいのです。具体的なJavaScriptは、次のようになります。

// view1を生成直後にhideする
var view1 = bbb.createViewF(win, 768, 768, 0, 0);
view1.hide();
// UI部品を加える
var label1 = bbb.createLblF(view1, 'ラベル', 14, 'right', 20, 100, 10, 580);
var Button1 = bbb.createBtnF(view1, 'ボタン', 24, 40, 200, 180, 150);
// UI部品を加え終わったら、view1を表示させる
view1.show();

この方法を初代iPadで試したところ、UI部品が数十個のViewでは、違いが分かるほど高速化できました。しかし、UI部品が100個以上あるViewでは、高速化にも限界がありました。Viewが現れるまで２秒弱ほど待たされます。それでも、hideせずに描くよりは充分に高速化されています。この状態で我慢してもらうしかないのでしょうね。

初代iPadはRAM容量が少ないため、メモリーを節約するような作り方をしないと不安です。画面表示が少しは高速化できたので、この方法で最後まで進めたいと思います。

Viewはshowしたときに描き直されるもの？

Titanimu Mobileを使って、新しいアプリを開発中です。いろいろと試しながらの開発なので、実際に作る工程よりも、どんな動きをするのか細かな部分の解析に時間を取られています。使い始めて２つめのアプリなので、仕方ないでしょうね。

　

今回は、Viewの描画で困ったことが起こりました。普通にViewを作成して、普通に表示しているだけなら、とくに問題はありません。でも、少し凝った機能が必要になって、ViewにaddしたUI部品のレイアウトを途中で何度も変更する機能を実装しました。UI部品のtopやleftを途中で変更し、１つのViewのままで、複数のレイアウトを実現する機能です。メモリー効率も良さそうですし。

さすがに、表示したままレイアウトを変更するわけにはいきません。Viewをいったんhideして、hideした状態でUI部品のレイアウトを変更し、変更が終わってからViewをshowしたら問題ないだろう考えました。他の工夫（viewをhideしても問題が生じない工夫）と組み合わせる必要はありますが、Viewに関するJavaScriptは、次のようになります。

view1.hide();      // view1を非表示にします
label1.top = 40;   // view1上のUI部品のプロパティを変更して、画面上のレイアウトを変えます
label1.left = 30;
imgView.top = 120;
...
view1.show();      // view1を再表示します

これが期待した動きになりませんでした。UI部品のレイアウトを変えてから、Viewをshowした場合は、ほんの一瞬だけ変更前のレイアウトが表示され、直後に新しいレイアウトを描いて安定します。フラッシュバックで一瞬だけ古い画像が表示されたような感じです。バグでしょうか、仕様なのでしょうか。こんな使い方をしている人がいないためか、検索しても情報は見付かりませんでした。普通に考えると、表示する内容を内部で作り終わってから、画面に描画するように作るのではと思います。でも、動きから推測するに、そうなってはいないようです。

真剣に困りました。この方法が使えないと、複数のレイアウトのViewを用意しておき、それぞれに値を設定し直してから切り替える必要があります。レイアウトを増やす場合も、新しいViewを追加しなければなりません。美しくないですね。何とか回避できないかと、かなり悩みました。

悩んだ結果、１つ思い付きました。透明度を変えるopacityを使えないかと。opacityの値で限りなく透明にした状態でViewを描かせ、直後に不透明状態に戻せば、フラッシュバックが消えるのではないかと。完全に透明にしてしまうと、描く処理が開始しないと思い、限りなく透明な値として0.001を選んでいます。さっそく、次のようなJavaScriptで試しました。

view1.hide();          // view1を非表示にします
view1.opacity = 0.001; // view1を限りなく透明にします
label1.top = 40;       // view1上のUI部品のプロパティを変更して、画面上のレイアウトを変えます
label1.left = 30;
imgView.top = 120;
...
view1.show();          // view1を再表示します

結果は、惨敗でした。何も変わらず、フラッシュバックが再現されました。まだ、あきらめません。限りなく透明にする位置が悪いのではないかと考えました。hideしてから限りなく透明にしても、その状態を描いていません。限りなく透明にするのを、hideする前に行えば、表示されている時間内に限りなく透明で描いたことになり、有効だと考えました。試したJavaScriptは、次のような形です。

view1.opacity = 0.001; // view1を限りなく透明にします
view1.hide();          // view1を非表示にします
label1.top = 40;       // view1上のUI部品のプロパティを変更して、画面上のレイアウトを変えます
label1.left = 30;
imgView.top = 120;
...
view1.show();          // view1を再表示します

またまた惨敗しました。ここでいったん敗北宣言です。こんなときこそ、美味しい珈琲を飲んで休息です。時間を置いてから、再び考えました。もしかしたら、時間差攻撃が有効かもと。Viewをshowした直後にopacityを戻しているからダメなので、少し時間を経過してからなら大丈夫ではないかと。限りなく透明に設定する処理をhideの後ろに戻し、次のJavaScriptで試しました。

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;
}

今度は、大成功でした。フラッシュバックがまったく出ません。勘で決めた50msですが、時間差攻撃が成功です。最近の高速コンピュータにとっては、50msでも長い時間なのでしょう。もっと短くなるかも知れませんが、不安が増すので今のところ50msで固定です。

以上は、シミュレータでの動きでした。実機ではフラッシュバックが出ないかも知れませんし、この解決方法で実機も大丈夫という保障もありません。ただし、show後に描き直しているという動きから考えて、非常に有効な解決方法です。

開発の基本としては、実機でもシミュレータでも正常に動作することが大事です。実機で動いたからといって、その実機だけかも知れません。機種もOSバージョンも違う環境が、何種類も存在します。すべての環境でテストすることは無理なので、実機でもシミュレータでも動くことを、最低条件とするわけです。また、問題の解決にあたっては、たまたま直ったのではなく、こういう現象だからこうすれば直るはずと、理論的な裏付けのある解決方法が大事です。

今回の問題は苦労しましたが、何とか解決できて良かったです。まだ実機でのテストが残っていますが、最悪の場合でも、時間差の数値を変更するだけで大丈夫でしょう。複数レイアウトのViewを用意することだけは、ぜったいにやりたくないですからね。

　

Titanimu Mobileの経験が浅いので、もしかしたら、別な解決方法があるかも知れません。ご存じのことがいたら、ぜひ教えてください。一応、viewのプロパティなども本家のAPIページで全部見ましたが、それらしいものは見付かりませんでした。唯一使えそうだったのが、opacityというわけです。