本書では、新しい Windows Mobile 5 継続保管が Ultra Light アプリケーション開発者に及ぼす影響について説明します。
また、Windows Mobile 5 メモリの簡単な概要と、アプリケーション・パフォーマンスに対する悪影響を最小限に抑えながら、その保管によって提供される持続性を利用できるようにするためのヒントを示します。



Windows Mobile 5 の継続保管

Windows Mobile 5 では、Windows Mobile デバイスでのデータ格納方法に大きな変更が加えられています。
旧バージョンの Microsoft Windows Mobile および Microsoft Pocket PC に基づいたデバイスには、RAM の形式でのみメモリが付属していました。
デバイス・ユーザは、[設定] - [システム]- [メモリ] のスライダを使用して、利用可能なRAM をストレージ用の領域とプログラム実行用の領域に分割することができました。
RAM はハイ・パフォーマンスですが、デバイスのバッテリが切れると全データが失われるという問題があります。
継続保管を実現して、バッテリが切れてもデータが失われないように、ユーザは外部カード (フラッシュ・メモリ・カードなど) を購入する必要がありました。
Windows Mobile 5 デバイスは少なくとも 2 種類の内蔵メモリを備えており、それらの基本アーキテクチャは PC に非常によく似ています。
RAM はプログラム実行用に提供され、ファイル・システムは、それよりもかなり遅いフラッシュベースの継続保管で保持されます。
フラッシュ・メモリにはNAND フラッシュとNOR フラッシュという 2 つの形式があります。
通常、Windows Mobile 5 の継続保管は NAND フラッシュです。
一部のデバイスには、上記の 2 つ以外の保管タイプも含まれています。
たとえば、Symbol MC70デバイスには、RAM ベースのキャッシュ・ディスクと、NOR フラッシュである独立したファイル・システム領域が含まれています。
ただし、これらの拡張によってアプリケーション開発者の基本的な状況が大きく変わることはないため、本書ではこれらの拡張について扱っていません。



アプリケーション開発への影響

Windows Mobile 5 継続保管の導入は、主に以下の 2 つの影響をアプリケーション開発者に及ぼします。

・バッテリが切れても失われない保管の可用性により、Windows Mobile 5 デバイスの信頼性は向上します。そのため、Windows Mobile 5 デバイスは、旧バージョンの Windows　Mobile に基づいたデバイスよりも、数多くの種類のアプリケーションにとって便利になっています。

・RAM と比べて低速なパフォーマンスの保管は、アプリケーションのパフォーマンスに悪影響を及ぼす場合があります。旧バージョンの Windows Mobile では完璧に機能していたアプリケーション設計の側面のいくつかは、Windows Mobile 5 では深刻なボトルネックになる可能性があります。

・頻繁なコミットを避けるオートコミット・モードでの動作は、パフォーマンスの低下につながります。
また、一部のアプリケーションは、フォーム間の移動時などに変更を頻繁にコミットします。
ユーザは、不要なコミットについてアプリケーションを検査し、それらのコミットを排除する必要があります。
たとえば、アプリケーションの状態を保存する場合、実際には変更をコミットする必要性がないことがよくあります。

・接続のクローズと再オープンを避けるUltra Light アプリケーションの場合、データベースへの接続が存在しないときには必ずデータベース・キャッシュが空になります。
一部の Ultra Light アプリケーションは、フォームごとに接続を開閉するか、またはデータベース操作ごとに接続を開き、操作の終了後にその接続を閉じます。
そのような設計は、旧バージョンの Windows Mobile では適切に機能しましたが、Windows Mobile 5 では、キャッシュからデータが読み取られるのではなく、キャッシュよりもずっと低速な継続保管からデータがフェッチされるため、低速パフォーマンスにつながります。

・十分に大きなキャッシュを割り当てるUltra Light キャッシュは、接続パラメータとして設定されます。
頻繁にアクセスされるデータを保持するのに十分なキャッシュを割り当てることは、旧バージョンの Windows Mobile よりも Windows Mobile 5 において、より重要になっています。
ユーザは、主なボトルネックについてアプリケーションを検査し、より大きなキャッシュの割り当てが、この領域におけるパフォーマンス問題の対処に役立つかどうかを確認する必要があります。

・高価なクエリの為のインデックスを定義する大きなテーブルのスキャンを伴うクエリは、大量のデータベース・ページをデータベースから読み取らなければならないことがあります。
適切なインデックスは、そのような不経済なスキャンを、はるかに少ない数のインデックス・ルックアップに変えることができます。
それにより、デバイス I/O は最小限に抑えられます。