DATE : 2007/02/17 (Sat)
（；^ω^）実機で動かすと、やっぱり処理が遅いですね……。
開発したアプレットでは、GPS で取得した現在地から登録されている施設を検索する部分があるのですが、結果が表示されるまでそれなりに時間がかかります。
（；^ω^）シミュレータの場合は、ほぼ一瞬でした。
ただ、この部分は GPS を使っているので、もしかすると位置情報の取得に時間がかかっていて検索そのものは短時間で済んでいるのかもしれません。
（；^ω^）これはちょっと、処理時間を計測してみる必要がありそうです。
(；´Д｀)検索処理そのものを速くしても、実際は位置情報の取得に時間がかかっているようであれば、改良の効果も少ないですしね。
DATE : 2007/02/16 (Fri)
（ ^ω^）ごく一部を修正したら、普通に動作しました。
原因は、GPS 受信機の設定を行う部分でした。
BREW API からは、GPS 受信機の振る舞いをいろいろと設定することができます。例えば、ネットワークを使わずに GPS 受信機のみで現在地の計算を行うようにしたり、精度よりも速度を重視するようにしたりできます。
（；^ω^）ただ、これはあくまでもその設定に携帯電話側の GPS 受信機が対応していればの話で、対応していない場合にはもちろんその設定は使えません。
（；^ω^）ちなみに、BREW シミュレータの場合、標準のデバイスパックではどのような設定にしても動きます。
なので、GPS 受信機の振る舞いを設定するコードを書く場合には、次のような処理になります。
- アプリケーションに適した設定を用意する。
- 設定が使えるかどうかを確認する。
- 第2希望以降の設定がある場合は、1、2を繰り返す。
- 用意した設定が使えない場合は、標準の設定を使う。
しかし、動かなかったコードは最後の部分が抜けていました。
そして、実際に上のコードが組み込まれた場所は、GPS 受信機が使えるかどうかを検証する部分でした。そのため、用意した設定が使えない場合は GPS 受信機が使えないと判断する処理になっていたのです。
（；^ω^）位置情報の取得ができるかどうかをチェックする部分は別にあって、その部分で異常が発生した場合はきちんと「GPS が使えません」というメッセージが出るのですが、上の設定を検証する部分で異常が発生した場合は起動に失敗するような仕組みになっていました。
（；^ω^）ただし、アプリケーションの種類によっては、標準の設定では使えないという判断が必要な場合もあります。
DATE : 2007/02/15 (Thu)
(´・ω・) BREW の企画で、PC での動作確認からいよいよ実機へと舞台を移そうとしたのですが、舞台に上がる階段で転んでしまいました。
携帯電話に BREW アプレットを転送して、ワクワクと起動してみると、画面に出てきたものは……
起動に失敗しました
(´Д⊂ヽ
ただ、完全に起動に失敗したわけでなく、アプリケーション本体が立ち上がらなかったことが分かりました。
今回開発したアプレットは、大まかに次のような手順で立ち上がります。
- アプレットを立ち上げる命令が来る。
- 起動部分が立ち上がる。
- アプリケーション本体が立ち上がる。
アプリケーション本体は C++ なのですが、BREW アプレットの起動部分はCの関数として書かなければなりません。そのため、起動部分がC、C++間の橋渡しを行っているわけです。
BREW ではとにかくエラーが発生する可能性のあるところはチェックするように書かないといけないので、例に漏れずアプリケーション本体の起動も失敗した場合にはエラーメッセージを表示するようにしました。
それで、そのエラーメッセージが上のメッセージな訳なのです。
DATE : 2007/02/13 (Tue)
（前回の記事）
イベントとは
AEE シェルにコールバックを登録することで処理を細かく分けることができました。そのほかに BREW AEE にイベントを送信することで、イベントに関連付けられた処理を呼び出すことができます。
イベントは、AEEEvent 型で定義されています。BREW アプレットの開始や停止、キーが押されたなどのイベントも、AEEEvent （実体は符号なし16ビット整数）で定義されています。新しくイベントを定義する場合には、EVT_USER 定数以上の値にする必要があります。
また、送信するイベントには関連するデータを2種類添付することができます。具体的には、符号なし16ビット整数と符号なし32ビット整数の2つです。例えば、キーが押されたイベント（EVT_KEY_PRESS）の場合は、前者に押されたキーのコードが、後者に修飾キーのビットフラグが設定されます。
イベントを実際に送信するには、以下の関数を使用します。これらの関数を使用するには、送信先アプレットのクラス ID を指定する必要があります（通常は、イベントの送信元のクラス ID となります）。
- ISHELL_SendEvent
- ISHELL_PostEvent
（つづきます）
DATE : 2007/02/09 (Fri)
開発中の BREW アプレットのバグが取れました。
バグの発生元がなかなか分からず苦戦していたのですが、なんとかなりました。
(；´Д｀)とても簡単なミスでしたが……。
開発していたのはファイルを読み込んで処理するアプレットです。レコードが50件ほどのファイルだと快調に動作します。しかし、レコードが10000件程度になると、起動してすぐにメモリの空き領域が急激になくなり、そのままアプレットが強制終了してしまいます。
BREW シミュレータにデバッガをアタッチして調べてみたところ、次の部分でアプレットが強制終了しました。（コードは分かりやすいように改変してあります）
void processData(Data& data) {
...
this->add(data);
if (this->isFull()) {
return;
}
...
this->readData();
}
読み込まれたデータを add メンバ関数で追加するコードです。追加後、データを格納するバッファがいっぱいでなければ、さらにデータの読み込みを求めます（readData メンバ関数は BREW にデータの読み込みを要求するだけで終了します。その後、BREW がデータの読み込みを行う関数を呼び出します。BREW ではできるだけ早く実行環境側に処理を戻さないといけないので、ループは使っていません）。
どうも、バッファが溢れているのが原因のようです。そこで、まず add メンバ関数を調べてみます。
void add(Data& target) {
this->data[this->dataCount] = target;
this->dataCount++;
}
あらかじめ一定数を確保しておいた配列にデータをコピーして、格納した個数を表すカウンタを増やしているだけです。
dataCount の初期値を調べてみましたが、特におかしいところはありません。dataCount の値を出力してみても、初期値は正常でした。ただ、想像したとおり、dataCount の値は配列の要素数を軽く超えていました。
すると、残るは isFull メンバ関数ということになります。しかし、isFull メンバ関数はとても簡単です。ただ単に dataCount が配列の要素数以上であれば true を返すだけです。例えば、配列の要素数が DATA_ARRAY_SIZE だとすると、次のようなコードになるはずです。
bool isFull() const {
return (this->dataCount >= DATA_ARRAY_SIZE);
}
（ ^ω^）普通は間違えません。
しかし念のため、isFull メンバ関数を確かめてみると……。
bool isFull() const {
return false;
}
(ﾟДﾟ)
(；´Д｀)そういえば、前に起きたバクを直すときに、テスト用に isFull 関数の中身を消したことを忘れていました。
