Titanium Desktopを使った業務アプリの開発で、設計方針を決める話の続きです。

どのAPIを採用するか考えます。将来の互換性や移植性を考慮すると、できる限りHTML5を重視すべきでしょう。しかし、困った問題があります。ローカルファイルの読み書きを実現するFile APIが、まだまだサポートされていないのです。メジャーなブラウザでさえ、サポートしていても読むだけとか限定的なサポートがほとんど。調べてみると、全部をサポートいるのが、GoogleのChromeだけというお寒い状況のようです。

仕方がないので、ローカルファイルの読み書きだけは、Titanium DesktopのAPI、Titanium.Filesystemを使うことにしました。これで作っておき、あとでFile APIに書き換えるという形で進めます。

続いて、保存するファイルのフォーマットです。文字コードはUTF-8で決まりとして、XMLやJSONを採用するかです。

今回の業務システムは、データ量はそれほど多くありません。ただし、入力したデータを表計算アプリに持って行き、友人が経営分析に使う必要があります。タブ区切りテキストとして出力して欲しいとの強い要望がありました。

いろいろと考えたら、XMLではなく、全部をタブ区切りテキストでも構わないと判断しました。ファイルの読み書きでは、1ラインごとに処理できるAPIが用意されていて、それへの適合性もばっちりです。テキストエディタでの編集も容易で、状況調査もリカバリーも簡単にできます。業務上の各種データだけでなく、アプリの設定値などもタブ区切りで作ることにしました。

タブ区切りテキストから読み込みながら、JavaScriptの配列へ入れます。逆に、配列からタブ区切りテキストとして書き出します。これらの処理なら、短く簡潔に作れますので。

画面ごとに処理を独立させる方針なので、タブ区切りテキスト・ファイルの読み込み、逆の書き出し、読み込んだデータを入れる配列変数を、すべて共通処理のJavaScriptに入れます。すべての画面のHTMLで読み込み、画面ごとに必要な処理だけ呼び出して使います。

画面ごとの処理では、配列からの読み出し、配列への書き出しを行います。つまり、ファイルと配列の間は共通処理、配列と画面間の処理は画面ごとの処理という分け方です。当然ながら、ファイル名などのファイル関連情報や、データを入れる配列変数は、共通処理の中に含めます。

さらに異なる画面でも、同じデータを扱う項目が考えられます。画面上のテキストフィールドやラベルを、異なる画面でもidを同じに設定すれば、共通のJavaScriptで出し入れできるはずです。これも共通処理に入れて、スクリプトの重複を減らすことにしましょう。当然ですが、共通のidも共通処理に含めます。加えて、配列の中身を調べたり、一部を抜き出したり、複数画面で使えそうな処理も共通処理に入れますね。

アプリの設定に関しても、設定値へアクセスする関数を共通処理側に用意します。このような形だと、設定の配列構造に依存せず、変更しやすくなります。また呼び出す側でも、読みやすいプログラムになるでしょう。

続いて画面設計の方針ですが、これは次回に。