2011/02/07 F900i のダイアログの仕様

 

iアプリ作成時 F900i で気をつけないといけない事。

 

以下のプログラムコードは、マルチスレッド端末では問題なく動作するはずですが、

F900i ではフリーズします。

 

// スレッド public void run(){      // とある分岐により、下記コードが通る場合     synchronized(object){         Dialog dlg = Dialog( Dialog.DIALOG_INFO, "test" );          dlg.setText( "hoge" );          int ret = dlg.show();          if( ret == Dialog.BUTTON_YES ){         }     } } // 描画イベント. paint() ではオフスクリーンを転送するだけにする public void paint( Graphics g ){       if( m_off!=null ){               synchronized(object){ // オフスクリーンの転送                    g.drawImage( m_off, 0, 0 );               }       } }

 

端末依存の問題点、気づきますでしょうか？

 

上記のプログラムコードは、デットロックを起こします。

 

最新の端末では問題はありませんが、90x シリーズ初期の F900i では

 

・ユーザーがボタンを選択した後 paint が発行される。

 
・paint が終了するまで show は wait 状態

 

という仕様のため、Dialog() をコールする際、 object 変数を synchronized

をしていることが原因で、デッドロックが発生します。

 

paint が完了するまでは Dialog.show() から抜けることはありません。

 

 

やっかいですね。Android、 MIDP 、 Doja、Star 全て関係なく、正しいコードと

信じてても、実際は端末依存の仕様があるため、全ての端末で完璧に動作させる

というのは難しいものです。

 

サウンド関連、マルチスレッド関連は昔から今もあります。描画関連は、昔ほど

端末依存があるというのは少なくなってきました。

 

今はなき D 系端末は、画像を初めて描画するときにメモリを消費、N505 ？は

GPU のおかげで描画命令をだしても、それが描画されてる事が保障がされない

というのがありましたね。

 

 

star のミニアプリは完全なマルチタスク、マルチスレッドなので設計によっては、

同じイベントだけど後からコールされた方が先にコールしたイベントを追い抜く

という現象も起きえます。

 

プリインストールアプリを開発した際、マルチスレッド過ぎる？設計だったので、

中々やっかいでした。※

 

※今ではアプリ提供を行った端末メーカーでの評判は良かったらしく、新端末のファームウェア検証に

利用されているとか、されてないとか耳にしたり。