DATE : 2006/12/21 (Thu)
（前回の記事）
コールバックとは
コールバックを使うと、BREW AEE に関数を登録しておくことができます。
コールバックには、大きく分けると次の2種類があります。
- 非同期処理のためのコールバック
- AEE シェルによるコールバック
非同期処理のためのコールバック
ネットワークで通信を行う場合などには、相手の応答を待たなければならないことがあります。このような応答を待たなければならない処理にコールバックが使用されます。相手からの応答があれば、コールバックに登録した関数が実行されます。
このコールバックは非同期処理の必要な API にそれぞれ用意されているので、詳しくは触れません。
なお、ファイルを読み書きするための IFile インタフェースにもファイルを読み込むためのコールバックを登録する関数（IFILE_Readable）があります。しかし、コールバック経由でなくとも直接 IFILE_Read 関数を使ってファイルを読み込むことができるそうです。
（つづきます）
参考文献
DATE : 2006/12/20 (Wed)
BREW シミュレータの「BREW 出力ウィンドウ」に次のようなログが出力された場合、メモリ関係のバグが発生しています。（以下は、「BREW シミュレータ 3.1.2.17」での例です。「?」には、特定の値が入ります）
*OEMOS.c:556 - BPOINT Type ?, Address: ????????
「Address:」の値はメモリ内のバグの発生したアドレスで、実行するプログラムによって変わります。
このログの中の「Type ?」という部分が、バグの内容を表しています。
この「Type」には1～4まであります。それぞれが表す内容は次の通りです。
- Type 1
- MALLOC 関数などで確保したメモリ領域が解放されていないメモリリーク
- Type 2
- 取得した BREW インタフェースが解放されていないメモリリーク
- Type 3
- メモリ領域の二重解放
- Type 4
- 確保・解放されたメモリ領域の情報を管理しているノードの異常
（；^ω^）案外目立たない出力なので、注意が必要ですね。
参考文献
DATE : 2006/12/19 (Tue)
家に帰ると、Wii のディスクスロットが青く光っていました。
Wii 伝言板に届いた任天堂からのメールを開いてみると、「お天気チャンネル」のサービスが始まったとの案内でした。
（ ^ω^）12月20日開始の予定だったのですが、なぜか1日早く始まりました。
さっそく本体を更新して、「お天気チャンネル」を開いてました。
初めに最寄のサービス提供地区を選択する必要があるのですが、一度設定してしまえば、お天気チャンネルそのものを開かなくとも、スタート画面から今日や明日の天気を確認できます。
（ ^ω^）一度チャンネルに入ってしまうと終了時に少々時間がかかるので、これは地味に便利ですね。
チャンネルに入ると、今日・明日の天気だけでなく、洗濯情報や週間天気も見ることができます。
さらに「地球儀」を開くと、地球儀上に日本各地、縮小表示すると世界各地の天気が表示されます。十字ボタンを押すことで、気温などへの表示に切り替えることもできます。
（；^ω^）よく知らない土地や、南極点の天気までありました。
勢いよく回すと、慣性がついてぐるぐると回り続けます。
（ ^ω^）なかなか滑らかで、見ていて面白いです。
ただ、日常に便利なチャンネルゆえに、Wii そのものの起動やチャンネル終了時にかかる時間が少々気になります。
ただ、このあたりの時間はアップデートで解決する予定らしいので、今後に期待したいところです。
DATE : 2006/12/18 (Mon)
（前回の記事）
BREW 全体の処理
BREW 全体は、イベントやコールバックの行列と言えます。
BREW AEE（Application Execution Environment、アプリケーション実行環境）はシングルスレッドですが、複数のアプレットを実行できます。
その実体は、実行する処理を溜め込むための単一のキューにあります。
各アプレットからは、実行したい処理がキューに次々と登録されていきます。そこで BREW AEE はキューから処理をひとつずつ取り出しては実行します。それぞれの処理はごく短いものなので、このような動作を繰り返すことで複数のアプレットを同時に実行しているように見せかけています。
ここでいう「処理」が、コールバックやイベントに当たります。コールバックやイベントを使用すると、キューに実行したい処理を登録することができます。登録された処理は BREW から直接呼び出されることになるので、時間のかかる処理でも細かく分けることができれば、再起動される時間を気にせずに実行できるというわけです。
（つづきます）
参考文献
DATE : 2006/12/16 (Sat)
携帯電話内で動作している全 BREW アプレットは、単一スレッド上で動作します。すると、あるアプレットがフリーズしてしまうと、他のアプレットの実行もできなくなってしまいます。
そのため、一定時間以内に処理が終わらなければ BREW そのものが再起動する場合があります。この「一定時間」というのは、機種によってまちまちですが、大体は1秒程度なのだそうです。
そのため、各アプレットの処理の一つ一つは1秒以内に終わるように開発しなければいけません。
具体的には、イベントやコールバックを使って時間のかかる処理を細分化することになります。
（ ^ω^）しばらくは、このあたりの情報を取り上げてみたいと思います。
（つづきます）
