とりあえず、リファクタリングしてみた。エンジンを別クラスにしてみたのだ。描画速度の改善としてアプリの起動時にコンタクトを読み込んでおき、描画時には名前の抽出だけにしてみた。（ソートは起動時に行い、ソート済みのデータを保持するようにした→ソートをView起動ごとに行わない。）
結果…
全然、変わらない…。何で…？ボトルネックになっているのは、名前の抽出のようだ。こうなったら、予め全ての名前を抽出しておいて、Viewの切り替え時には描画のみを行うようにしないとだめそうだ…。
もう少し、考えてみる…。
RSD60 のプログラムを見直している。表示が遅い理由は前回のBLOGでも述べたが、Viewの切り替えごとにコンタクトデータベースを読み直してソーティングしているからだ。以前に失敗したリファクタリングに再挑戦、しようと考えている。基本的には AppUI で ContactReadEngine を派生させ、その時点でコンタクトデータベースを読み込み、ソーティングも済ませておく。タブの切り替えで発生する View の再描画の時には描画に徹することが出来るはずなので、かなり改善すると思われる。
*.mbm ファイルがうまく読み出せないなどの、障害をなんとか乗り越えながら、実機に持っていってみた…。コンタクトから読み出すのが遅すぎる！！Viewを切り替えて２秒程してからやっとその文字の先頭が出てくる始末…。
これじゃ、遅すぎて話にならない…。理由は毎回、全部のデータを並べ替えしているからだ。Viewに対応したところ（つまり、当該データ）だけ、並べ替えするようにすれば確実に早くなると思われるが、一部領域だけをどの様に指定するかがちょっと、わからないので調べてみることにする。
もうひとつの問題は電話番号が出たり、出なかったりすることだ。これは痛すぎるっ！！これも早目に対策を打たないと…。
まだまだあるぞ。ダイアリングエンジンの具体的な実装だ。コンタクトから氏名を読み出し、電話番号も読み出せるようになった。これをダイアリングエンジンに渡して、ダイアリングすれば一応、ダイアラーとしての体裁は整うことになる。
けっこう、思っていたよりボリュームがあるな…。
気合を入れねば…。
コンタクトを読み出す部分はエンジンとして括り出そうと思ったけど、コンテナクラスと密接に結びついて、うまく切り出せない…。仕様が無いのでそのまま実装を続けることにする。「あ」〜「わ」でのタブの設定はうまく出来るようになった。後は細かいビットマップの手直しやダイアルエンジンの実装だな。結局、コンテナは一個で、Viewを「あ」〜「わ」に対応させていくことにした。コンタクトから名前を読み出してそれに対応する部分は共通で使えるのでコンテナは一個ですむわけだ。一方、名前に対応したタブをもつ必要があるのでViewはその数だけ実装した。
言い訳になるけど、最近は時間が無くて RSD60 を弄くれない。ちょっと、フラストレーション溜り気味。ちょっと、ネックになりそうなのがCContactReadEngine だ。この部分で’あ’、’か’、’さ’…を分けてコンタクトから読み出すわけだ。しばらくはデバッガのお世話になりそうだ。（普段の開発ではほとんど使わないけど…。）あとは CRegionSenseEngine …この部分はほとんどプログラムのサンプルがないのでトライ＆エラーになりそうな予感。うまく MCC をゲットできても、その後に国番号に変換するデータベース（ハッシュテーブル）を作らないといけない。最初はとりあえず、普通のダイアラーでも作ってみようと思う。
今日はちょっと、忙しくて RSD60 に手を入れる余裕が無かった。Series60 の GUI はある程度、自動で生成されるが、アプリケーションの本体部分いわゆるエンジンの部分は自分で設計して実装しなければならない。これをGUIとつなげて初めてアプリが完成するのだ。
今回のアプリのエンジンは以下のような感じになる…
エンジン同士が直接、呼び出しあうことは無い。基本的には Container あたりが交通整理をする。頭の中では大体、動きは固まっているのでひとつずつ、実装・テストしていこうと思う。
RSD60 はしばらく、放置プレイだったけど NextTrain60 で鍛えられたおかげで、今までわからなかった所がわかるようになってきた。ほんの少しの前進だけど、意図したとおりに一発で動くのは気持ち良い。実装はなるべく細分化して少しずつ、進めて行こうと思う。協力してくれる方はメールください。
並べ替えの部分は出来たので、電話番号の抽出を実装中。電話番号は複数、保持していることがあるのでそれをどのようにハンドリングするかが問題になる。大体、目処は付いたので後は複数ある場合はポップアップリストで表示してそこから番号を選ぶような感じになるのかな？後はその番号を ETEL のサーバーにつなげてダイアリング…と。ちょっと、先が長いね…。
コンタクトの中身も表示できるようになったが、無理やり表示させているのでこの先が心配だ。並び替えは読みを使うが、読みへのアクセスと電話番号をどの様に抽出するかだな。この手のフレームワークの宿命として、Container がでかくなってきた。早目にエンジンとして切り出すほうが良さそうだ。サンプルもこの辺を考えて作ってくれると他のに転用が利きやすいのになぁー。
リストをうまくビューにはめ込むことが出来るようになった。ダイナミックリストにしたので、コンタクトから読み込んでそれをリストに展開するのが次のテーマになる。やったことないので何とも言えないが、ちょっと苦労しそうな感じ。名前が展開できたらそれに付随する電話番号の抽出だ。ゆっくりやることにしよう。
とりあえず、View を「あ」〜「わ」まで作るとそれに伴う container とかも一緒に作らなければいけない。そうすると、リストをインプリした時に全部、書き換えになるのでやめにした。とりあえず View は今のままでリストのインプリがある程度終わった後に View を増やすことにする。リストに関しては色々と調べた。今回はコンタクトのデータベースから数が決まるのでダイナミックリストを使うのがよさそうだ。
詳しくはこちらを見てもらうとして、このブログでは開発過程について書いていこうと思う。UI としては国内のケータイと同じような感じで、横方向キーであ〜abc, 縦方向キーでそれぞれの名前を選ぶイメージ。で、このアプリを作るうえでの必要な要素を検討してみる。
これはアプリのWizardを使えば簡単に作成できる。フレームワークで作成できるビューの数は２個なので、これを適宜拡張していけば良い。「あ」〜「わ」、「abc」を作れば良いと思う。日本語は loc ファイルに CHARACTER_SET UTF8 を入れておく。後はユニコード(UTF8)を取り扱えるエディターで日本語の文字列を記述していく。