関連リンク：Titanium Mobileでアプリ開発
Titanium Desktopを使うことに ― 2012/02/21
iPhone向けのアプリ開発用として、Titanium Studioをインストールしました。それから何週間か経過したとき、以前からの知り合いと飲む機会がありました。私が昔に開発したアプリを未だに使い続けているけど、そろそろ新しい環境で動く版が欲しいなと。
彼も私も、古くからのMacユーザーです。昔に作ったアプリも、Mac上の古いマシンで動いています。彼の要望としては、とりあえずは新しいMac上で動かし、将来的にはiPadで動かしたいと。
彼は小さな会社を営んでいて、アプリは業務で毎日使っています。ジャンル的には業務アプリで、きっちり作らなければなりません。雇っている人（つまりパソコンが苦手な人）も使うため、使いやすさも重要です。意外に気を使って設計しなければならないアプリなのです。
とりあえず開発ツールを調べてみました。すると、Titanium Studioに含まれているTitanium Desktopが良いと感じました。HTMLとスクリプト言語で開発できるため、将来の移植性も高いでしょう。その先のiPad上での実現方法は少し悩みますが、Mac版アプリはTitanium Desktopで作ることに決めました。
実は、JavaScriptはほとんど使ったことがありませんでした。最近10年ほどは開発から遠ざかっていて、Javaまでしか知りません。JavaScriptは、ホームページを作るのに少し使ったぐらいで、知識はゼロに近かったのです。調べてみたら簡単に使えそうなので決めました。自由に使えるライブラリが豊富なのも魅力です。
これから何回かに分けて、開発中に気付いた点などを書き留めたいと思います。過去にいくつものシステム開発に参加した経験を生かしながら、他のブログとは少し違う視点で書きたいですね。
Titanium Desktopアプリの設計方針(1) ― 2012/02/21
どんなシステム開発でも、設計方針を決めずに進めると、開発の質が低下しがちです。設計方針は、使うプログラミング言語などに依存し、適した方針を決めなければなりません。
Titanium Desktopによる開発では、HTML、JavaScript、ブラウザが基本となります。また、これらを含めた形の独立動作アプリとしてもビルドできます。今回は、ターゲット環境がMac限定なので、Mac用の独立動作アプリとしてビルドすることに決めました。ブラウザのバージョンアップに依存しないほうが、システムとして安定するだろうとの判断です。
続いて、システム全体の構成を考えます。将来的にはブラウザで動作させる可能性もありますから、ブラウザ上で動かすことも考慮します。ブラウザで一番心配なのは、動作の安定性です。途中で異常終了したために、せっかく入力したデータを失ったら、業務が大変な状態に陥ります。
そこで最大の設計方針は、「途中で異常終了しても、できるだけデータを失わない構造にすること」としました。具体的には、入力したデータは、すぐにファイルへ書き込むこと。ただし、書き込む途中で異常終了すると、ファイルごと失う可能性もあります。ファイルへの追加書き込みはせず、前のファイルをコピーしてから、新しいデータを追加する方式とします。せっかくなので、前のファイルも数世代ほど保存することにしましょう。
このような方法で設計すると、新しいデータの書き込み中に異常終了しても、新しいデータ１件を失うだけで、過去に入力したデータは失いません。異常終了により、データが正しく入力されていないことは分かりますから、そのデータを再入力するという判断も容易でしょう。
システムで使用する画面は、入力画面だけではありません。入力したデータをグラフ表示したり、入力データを後で変更したり、業務システム固有の設定をしたり、何個もの画面を行き来します。これらの移動で、データを受け渡しする方法も考えなければなりません。
どうせなら、画面ごとに完全に独立して動く方式が一番良いと思いました。画面ごとに独立するとは、必要なデータを画面ごとに読み込み、JavaScriptも独立させるということです。JavaScriptの共通部分はひとまとめにして、全画面で読み込めばよいでしょう。画面を独立させることで、画面間の受け渡しデータが不要になり、自由に行き来できる形に仕上がります。
こうした方法だと、画面を切り替える度に同じファイルを読み込むことになります。しかし実際は、HDDから毎回読み込まれるわけではありません。Mac OS Xの場合は、RAMの空きに読んだファイルを残しておいて、再度読み込むときに利用しています。そのため頻繁に画面を切り替えても、HDDアクセスは生じず、短い時間で切り替わることになります。
設計方針の検討は、まだ続きます。採用API、ファイルのフォーマット、画面レイアウトの標準化などです。続きは、次回に。
Titanium Desktopアプリの設計方針(2) ― 2012/02/22
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も共通処理に含めます。加えて、配列の中身を調べたり、一部を抜き出したり、複数画面で使えそうな処理も共通処理に入れますね。
アプリの設定に関しても、設定値へアクセスする関数を共通処理側に用意します。このような形だと、設定の配列構造に依存せず、変更しやすくなります。また呼び出す側でも、読みやすいプログラムになるでしょう。
続いて画面設計の方針ですが、これは次回に。
Titanium Desktopアプリの設計方針(3) ― 2012/02/23
Titanium Desktopを使った業務アプリの開発で、設計方針を決める話の第３話です。
今回は、画面設計の方針を決めます。実現する技術に関してではなく、画面内に入れる情報レイアウトなどの標準化ですね。とくに目新しいことはなく、非常に一般的な方針を「おさらい」する感じです。
画面を上中下の３層に分けて、上部層がタイトル、下部層には画面移動などの、画面内容と関係の薄い操作系ボタンを入れます。下部層のボタンは左側と右側に分けて、画面切り替えボタンを左側に、その他のボタンを右側に並べましょう。
画面の中央層には、各画面の中心となる情報表示、情報操作のフィールドやボタンなどを並べます。ボタンについては、個別の情報に関係するものは情報表示の隣に、「登録」などの情報全体に関わるものは下側に並べます。
上中下の３層の区切りが明確になるように、区切り部分にBRタグを入れて境界を目立たせます。業務アプリですから、見栄えよりも分かりやすさを重視しているわけです。全体としての下部層にボタンが並び、中央層の下部にもボタンが並びますから、その区切りを伝える意味もあります。
続いて操作性に関してです。以前のシステムを設計したときから、マウスだけで（つまりキーボードを使わずに）操作できるようにとの強い要望が依頼主ありました。もちろん全部の操作が対象ではなく、日常業務で操作する画面に関してだけです。値の増減は、できる限り「＋」や「−」ボタンなどで行い、キーボードなしで使えるように配慮します。
エラーなどのメッセージを出す場所も決めます。下部層では、左右両端のボタンの間に、メッセージ用のラベルを用意します。中央層でも、一番下に付けた左右両端ボタンの間に、メッセージ用のラベルを作ります。
２つメッセージ用ラベルの使い分けは、非常に簡単です。個々の画面の内容に関するメッセージは、中央層のラベルに表示します。システム全体に関わるエラーなどは、下部層のラベルに表示するという具合です。たとえば、アプリの環境設定ファイルが読めない場合、システム全体でのエラーですから、下部層のエラーに表示することになります。ほとんどの機能はボタンで開始しますから、ボタンが付いている側のラベルを使うことになり、迷うことはありません。
画面に出すエラーメッセージも重要度で色分けします。重大なエラーは赤色で、注意点なら青色で、処理が成功したのを知らせるなら緑色などです。この辺の簡単な実現方法は、また別の機会に取り上げましょう。
残りはHTMLとCSSについてですが、これは次回に。
最近のコメント