Palm OS Programmer’s Companion Volume I/1-2 - project-enigma

Palm OS Programmer’s Companion Volume I/1-2

>> Site top >> Misc >> In my palm >> Palm開発ドキュメントの和訳 >> Palm OS Programmer’s Companion Volume I >> Palm OS Programmer’s Companion Volume I/1-2

最終更新日付:2014/01/01 00:00:00

← 1 節に戻る ↑1 章トップへ 3 節に進む →

1-2 Palm OS プログラミングのコンセプト

 

Palm OS アプリケーションは通常、単一スレッドのイベント駆動型プログラムであり、同時に実行されるプログラムは1つだけです。Palm OS アプリケーションを作成するためには、システムがどのように組織化され、またアプリケーションがどのように組織化されるのかを理解する必要があります。

IMPORTANT

ANSI C ライブラリは Palm 開発プラットフォームの一部に含まれていません。多くの場合、ANSI C の関数と同等の Palm OS API を利用することができます。例えば、Palm OS は ANSI C プログラムで使えるような文字列処理の多くを備えたストリングマネージャを提供しています。C 標準ライブラリの関数を使ってしまうと、その関数のコードがアプリケーションにリンクされ、結果として実行可能ファイルが大きくなってしまいます。

 

API の命名に関する慣習

Palm OS API には、一貫して以下の慣習が適用されます。

enum formObjects {
    frmFieldObj,
    frmControlObj,
    frmListObj,
    frmTableObj,
    frmBitmapObj,
    frmLineObj,
    frmFrameObj,
    frmRectangleObj,
    frmLabelObj,
    frmTitleObj,
    frmPopupObj,
    frmGraffitiStateObj,
    frmGadgetObj
};
typedef enum formObjects FormObjectKind;

 

 

プログラムのPalm OS 環境との協調

ユーザーは Palm OS アプリケーションを使用している時、他のアプリケーションに切り替えたり、Graffiti や Graffiti 2 といった強力な入力ソフト、あるいはオンスクリーンキーボードを使ったり、グローバル検索で情報を検索したり、アラームを受けたりできることを期待します。

このセクションのガイドラインに従えば、アプリケーションをうまく他と協調させることができます。以下の要領でシステムソフトウェアと協調させます。

事実上全ての Palm OS アプリケーションが使用している通常のイベントループは、システムがメッセージをポストして必要なイベントを処理するのに十分な時間的余裕を持っています。必要なのは、長時間に及ぶ処理に特に注意することだけです。例えば、20,000 レコードを越えるような大きなデータベースを持つアプリケーションがそのレコード全体を対象として検索するような場合、そのループ中でシステムイベントをチェックした方が良いでしょう。

さらに、以下のルールも守りましょう。

 

頑丈なコードを書くこと

プログラムをより頑丈に、そして将来の Palm OS デバイスと互換性を向上させるために、以下のガイドラインと実践に従うことを強く推奨します。

仮定条件のチェック

所々に ErrNonFatalDisplayIf 関数の呼出を追加することで、守りの堅いコードを書くことができます。これによって、デバッグビルドにおいて仮定条件のチェックを行うことができます。多くのバグはこの方法で捕捉でき、しかも出荷するコードには負担をかけません。リリースビルドでも重要なチェックを残したければ、ErrFatalDisplayIf 関数を使うことができます。

継続的なポーリングを避ける

バッテリを節約するため、継続的なポーリングを避ける必要があります。アプリケーションがウェイトループをしているなら、代わりに短いインターバルのポーリング(例えば1秒に10回とか)に切り替えます。Palm OS SDK に付属の Hardball サンプルアプリケーションのイベントループは、これを実現する方法を示しています。

NULL(あるいは low memory )に対する読込み・書込みを避ける

メモリを確保する関数(MemSet, MemMove や同様の関数)をコールする場合、それらの関数が返したポインタが NULL でないことを確認してください(もっと厳密な妥当性確認ができるならそれに越したことはありません)。構造体やその他の関数から取得したポインタについても NULL でないことをチェックすべきです。また、デバッグビルドにおいて MemMove(や同様の関数)を #define で上書きし、渡されたパラメータを検証することを検討して下さい。

訳注

「メモリを確保する関数」としか冒頭部分は訳しようがないと判断しましたが、MemSetや MemMove はメモリを確保しません。「メモリを操作する関数」とすることも考えましたが、そうすると後ろの文章との関係がおかしくなります。

ダイナミックヒープを節約する

本当にそうする必要性がない限り、Palm OS 2.0 以上で利用できるダイナミックヒープ領域を使わないことは重要です。ヒープの無駄使いは、アプリケーションを最新のハンドヘルドでしか使えないものにしてしまいます。その場合、すでに市場に出回っているたくさんのデバイスで使えないということになってしまうでしょう。

IrDA スタックや検索ウィンドウなど、システムサービスによってはアプリケーションが動作中でもメモリを確保するものがあることに注意してください。例えば、赤外線やその他の外部入力からの受信が始まると、システムは入力されてくるデータのために新たなヒープ領域を必要とします。そこにあるからというだけの理由で全てのダイナミックメモリを使ったりせず、大量の一時データにはストレージヒープを使用することを検討して下さい。

メモリアロケート時には復帰値をチェックする

将来のハンドヘルドのメモリが増えるのか減るのかは分かりませんから、メモリをアロケートした時に注意深く復帰値をチェックするのは良いことです。大きなデータを扱う際にストレージヒープ(と可能ならばファイルストリーム)を使うのも良い習慣です。

ゼロバイト幅のアロケートを避ける

ゼロバイト幅のバッファを確保すること、およびバッファをゼロバイトにリサイズすることはできません。Palm OS 2.0 以前ではこれは問題ありませんでしたが、それ以降のバージョンのOSではゼロバイト幅のオブジェクトは許可されません。

画面に関する仮定を避ける

スクリーンバッファの配置やサイズ、ピクセルあたりのビット数は石碑に刻まれたように固定されているわけではありません。それは変化するものです。ウィンドウや描画に関連したAPIをハックしないで下さい。もしAPIを迂回するためにハードウェアをハックするのであれば、状態を保存しておき、終わった後で元に戻して下さい。

大域やハードウェアに直接アクセスしない

大域のデータやその配置は変わり得るものです。災難を避けるために、ドキュメントされたAPIを使い、テストしたバージョンのOS以外では動作を抑止しましょう。将来のハンドヘルドは、現在のものとは異なるプロセッサ上で動作するかもしれません。

同様の理由で、カードへの参照もハードコードしてはいけません。現在のPalm OS デバイスが1つのカードスロットしか備えていないからといって、それがいつでも正しいとは限りません。ですから、カードを操作するデータマネージャやファイルストリーミングのような関数をコールする時は、ハードコードされたカード番号0を渡すかわりに対象のカードを参照する変数を渡すようにして下さい。

標準アプリケーションは変更されうる

標準アプリケーションのプリファレンス(やデータ)は変更されうるものです。防衛的なコードを書きましょう。そして、テストしていないバージョンのOS上では動作を抑止することを検討して下さい。

 

 

 

← 1 節に戻る ↑1 章トップへ 3 節に進む →

 

 


Copyright(C) 2005-2017 project-enigma.
Generated by CL-PREFAB.