Java

iｱﾌﾟﾘ開発のﾂﾎﾞ

ここでは私がiｱﾌﾟﾘを作ったときに気付いたことを書いていきます｡

ｸﾗｽをできるだけ少なくする

iｱﾌﾟﾘ全体のｻｲｽﾞは 10Kbyte に制限されています｡ｻｲｽﾞを減らすための色々な方法が雑誌などでも紹介されていますが､私の結論は､

ｸﾗｽの数を減らすのが一番効く

という事です｡具体的な方法としては､

• ｲﾝﾀｰﾌｪｰｽを実現するためだけのｸﾗｽ､内部ｸﾗｽなどを作らないようにしましょう｡
  
  GUI ｺﾝﾎﾟｰﾈﾝﾄを使う場合は Panel を継承したｸﾗｽに全ての必要なｲﾝﾀｰﾌｪｰｽも実装するようにしましょう｡
  
  
• 抽象的なｸﾗｽは作らない｡
  
  ﾃﾞｰﾀを格納するだけの何も継承しないｸﾗｽを作ることはｵﾌﾞｼﾞｪｸﾄ指向ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ的には正しい事ですが､iｱﾌﾟﾘの場合は違います｡例えば単語帳ではｻｰﾊﾞｰ設定ﾊﾟﾈﾙのｸﾗｽがｻｰﾊﾞｰのﾃﾞｰﾀそのものも格納しています｡
  
  
• ｲﾝｽﾀﾝｽの無いｸﾗｽは作らない｡
  
  例えば2つのｸﾗｽに共通の機能が必要な場合､一般的な Java ｱﾌﾟﾘでは共通部分を1つのｸﾗｽとして定義し､そのｸﾗｽを継承して2種類のｸﾗｽを作ります｡しかしｸﾗｽﾌｧｲﾙの全体のｻｲｽﾞを考えると2つのｸﾗｽに別々に同じﾃﾞｰﾀやﾒｿｯﾄﾞを定義したほうが良い場合があります｡

ｸﾗｽ､ﾃﾞｰﾀ､ﾒｿｯﾄﾞの名前を短くしたりしてもほとんど効果はありませんが､ｸﾗｽを1つ減らすと 100Kbyte 単位でｻｲｽﾞを減らすことができます｡

GIF画像の圧縮

まあこれは色を16色に減色してﾉﾝ･ｲﾝﾀﾚｰｽにするだけです｡

ｻｲｽﾞ減らしの細かい技

• 変数を配列にする(例: int x, y, z; -> int p[3] )
• 変数･関数名を短くする

これらの技は使うとｺｰﾄﾞが見辛くなってしまうので､開発の最終段階まではやらないほうが無難です｡

GUI部品の動的な変更

iｱﾌﾟﾘの GUI ｺﾝﾎﾟｰﾈﾝﾄでは AWT や Swing と同様に動的にﾗﾍﾞﾙやﾘｽﾄの内容を変更することができます｡単語帳では ListBox や Label の内容をﾕｰｻﾞの操作に応じて変更しています｡例えば単語帳の｢ﾘｽﾄをﾛｰﾄﾞ｣ﾎﾞﾀﾝを押すとｻｰﾊﾞｰから単語帳のﾘｽﾄがﾀﾞｳﾝﾛｰﾄﾞされて単語帳ﾘｽﾄに単語帳が追加されます｡

こういった場合に問題になるのが､GUI 部品のﾚｲｱｳﾄを決定しているﾚｲｱｳﾄﾏﾈｰｼﾞｬの選択肢が標準のもの1つしかないことと､その標準のﾚｲｱｳﾄﾏﾈｰｼﾞｬの挙動を制御する事ができない事です｡

そんな場合､以下の様な方法で標準のﾚｲｱｳﾄﾏﾈｰｼﾞｬの挙動をある程度制御できます｡

• ﾊﾟﾈﾙの再ﾚｲｱｳﾄが必要な場合には､Display.setCurrent() を呼ぶ｡
  
  ListBox に項目を追加した場合など､部品のｻｲｽﾞが自動的に変化します｡その場合､ﾊﾟﾈﾙ全体のﾚｲｱｳﾄを再調整しないと部品同士が重なって表示されたりしますが､これは自動的には行われません｡明示的に再ﾚｲｱｳﾄを行うには Display.setCurrent() を呼びます｡
  
  
• Label や Button を1行1件にするためにはｻｲｽﾞをﾊﾟﾈﾙの幅と一致させる｡
  
  特にﾗﾍﾞﾙの場合､文字列が短いと複数のﾗﾍﾞﾙが1行にまとめられてしまいます｡単語帳のように常に1行1件でﾘｽﾄしたい場合には､ﾗﾍﾞﾙの文字列を変更する度に Label.setWidth() でﾗﾍﾞﾙの幅をﾊﾟﾈﾙの幅(Panel.getWidth() の値)と同じにします｡
  
  

端末によって動作が違う!!

実は私はiｱﾌﾟﾘ端末をもっていません｡そこで会社の先輩や同期の友人に頼んでﾃｽﾄしてもらったのですが(ﾊﾟｹｯﾄ料返せという意見もありますが)､そこで端末によってJavaの動作が違うことが発覚しました｡例えば､

Panel と GUI ｺﾝﾎﾟｰﾈﾝﾄを使っている場合､Panel に対する KeyListener で､

N503i

上下左右のｷｰｲﾍﾞﾝﾄ(KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT)を扱えない

F503i

ｷｰｲﾍﾞﾝﾄを扱える

この場合は操作を別のｷｰに割り振ることで問題を回避しました｡

個人での開発ではﾃｽﾄはどうしてもｴﾐｭﾚｰﾀ頼りで実機のﾃｽﾄは少なくなりがちなので発表してから問題が発生してしまう可能性があります｡

また端末によっては .jam ﾌｧｲﾙに書かれているﾊﾟﾗﾒｰﾀの順番が期待通りでないとﾀﾞｳﾝﾛｰﾄﾞに失敗する場合があるようです｡

ShortTimer と resume()

iｱﾌﾟﾘは電話の着信があると一度停止状態になり､通話が終わると resume されます｡その時以下のいずれかのｲﾍﾞﾝﾄ処理でｱﾌﾟﾘの resume を行う必要があります｡

• IApplication.resume()
• Canvas.processEvent() -> Display.RESUME_VM_EVENT ｲﾍﾞﾝﾄ

その時問題になるのがﾘｱﾙﾀｲﾑ処理に用いる ShortTimer の扱いです｡停止されたときのﾀｲﾏｰの状態が分からないので､start(), stop() のどちらを呼べばよいのかが分からないためです｡この場合まずは dispose() を呼んでﾀｲﾏｰを破棄して新規に getShortTimer() でﾀｲﾏｰを生成すれば問題ありませんでした｡