業務アプリはデータ保全が一番大事

業務で使用するアプリの開発は、一般的なアプリと少し違うと思います。少なくとも私は、違うと考えて開発してます。どのような点を重視しているのかというと、入力したデータを可能な限り守ることです。iPadという環境なので大したことはできませんが、できないながらも工夫した点を紹介します。

　

アプリを仕事で使うということは、仕事上のデータを扱うということです。扱うというと抽象的なので、もっと具体的に言うと、仕事上のデータを入力して保存して活用するということです。こうして入力したデータは、会社の財産です。そのため、入力されたデータが失われないことを、業務アプリでは一番重視しています。

データを保存する場所としては、RAMメモリー内よりもフラッシュメモリー内のほうが格段に安全です。RAMメモリー内なら、アプリが異常終了したときに、データが失われてしまいますから。こうした理由から、データを入力した直後に、ファイルへ保存する形で作っています。iPadのファイルはフラッシュメモリー内に保存されるため、機械的なアクセスもなく、ハードディスクよりも安全で高速です。

毎回保存されるのを気にするかもしれませんが、タップ操作でアプリへ入力するデータの量などは、たかが知れています。圧縮などせずにテキストで保存したとしても、データ量が少なく、一瞬で書き出されます。

　

ファイルへ書き出す場合にも注意が必要です。もし書き出し中にエラーが発生したら、そのファイルは正常に読めなくなるかもしれません。もし読めたとしても、途中までのデータしか残っていない可能性があります。

書き出しに失敗した場合を考慮すると、毎回異なるファイル名で書き出し、どんどんと追加する方法もありますが、ファイル数が増え過ぎて現実的ではありません。同じファイル名に書き出しながら、失敗へのリカバリー方法も考慮するという手段が現実的でしょう。

最初に考えたのは、仮のファイル名で書き出し、書き出しが成功したら本来のファイル名に変更する方法でした。でも、先にあったファイル(つまり前回に保存したファイル)を、どう扱えば良いのか悩みました。そして次のような方法を採用しました。

保存するファイル名は毎回同じで、新しく入力したデータを後ろに追加してから保存します。同名の古いファイルは、旧版として過去３世代ほど残しておく方法です。

過去３世代が残っている状態だと、最新ファイルに加えて、old1、old2、old3という３個のファイルが存在することになります。その状態で新しく保存する場合、具体的な実行手順は次のようになります。

３世代を残しながら更新する手順
・old3ファイルを削除する
・old2ファイルをold3に改名する
・old1ファイルをold2に改名する
・最新ファイルをold1に改名する
・新しい最新ファイルを書き出す

oldが存在しない状態(使い始めたときの状態など)もありますから、個々の処理では、改名する前に存在を確認し、存在すれば改名するという形になります。

　

過去３世代のファイルを残しておいても、書き出しが失敗したとき、元に戻す機能がないと無駄です。リカバリー処理の１つとして、過去３世代を１つずつ戻す処理が必要となります。具体的な実行手順は次のとおりです。

旧３世代を１つずつ戻すリカバリー処理
・最新ファイルが存在すれば削除する
・old1ファイルを最新名に改名する
・old2ファイルをold1に改名する
・old3ファイルをold2に改名する

これらでも個々の処理では、改名する前に存在を確認し、存在すれば改名するという形になります。

リカバリー手順は以上で構わないのですが、最新ファイルの書き出しに失敗しているか調べる方法が必要となります。最終的には、人の目で確認するのが一番でしょう。最新ファイルだけでなく、old1〜old3も含めて、中身を見れる機能も用意しました。

通常の作業で、これらのリカバリー処理を使うことはありません。アプリが突然と異常終了したとか、入力後の保存処理で成功メッセージが出なかったときなど、普段と違う表示になったときに利用するものです。調べる手順などをヘルプに書いておき、そのヘルプを読みながら、リカバリー処理を進めるという形にしてあります。

一番長く使われている業務アプリでも、Titanium mobile時代も含めて３年ぐらいしか経過してませんが、異常な状態になったことは一度もありません。そのため、これらリカバリーの処理は何度もテストしましたが、まだ本番では一度も使われたことがないのです。良いことといえば、良いことなのですが。

　

アプリのトラブルは、データ入力時に起こるとは限りません。予想もしないトラブルが、突然と発生することも考えられます。たとえば、iPadの調子が悪くなって、どのアプリも不安定な動きになったとかです。こんな状態だと、いつiPadが起動しなくなるのか不安でしょう。真っ先にすべきことは、iPad内の重要なデータを、他のマシンにコピーすることです。

iOSのアプリでは、Macと接続したとき、iTunesでバックアップが取れるようになっています。その際、アプリ側の設定で、iTunesからアプリの保存ファイルが見えて読めるようにもできます。Info.plistファイルの項目で、「Application supports iTunes file sharing」を追加してYESに設定するだけです。こうしておくと、もし近くにMacがあれば、iPadと接続して全ファイルをコピーできます。

近くにMacが無い場合も考慮し、ファイルを添付して送信できるメール機能も追加しました。ファイル一覧をテーブルビューに表示し、添付したいファイルを選んで、他のマシン宛に送信するだけです。

毎日使われている業務アプリでは、この送信機能を通常業務としても利用しています。iPadで入力した業務データは、１日単位でファイルに保存されています。それをメール機能でMacに送信し、Mac側の表計算アプリに取り込んで、業務分析などに利用しているのです。メール機能を付けたために、iPad側は入力中心になってしまいました。将来的な話ですが、iPadがパソコン的に使えるようになったら、分析業務もiPadでやりたいそうです。その前に、クラウド上の表計算機能が使えるようになって、iPadとクラウドだけで十分になりそうですけど。クラウド側だと、バックアップとしても安心ですし。

ちなみに、業務アプリ開発の相談を受けた場合、最初に提案するのがサーバーを立てて、iPadからはウェブブラウザで使う形です。クライアント側のOSやアプリに依存せず、サーバー側だけでシステム更新が可能だからです。でも、パソコン上の表計算アプリでバリバリとデータ解析するような人は、サーバーを立てずに、iPadで入力専用のカスタムアプリを使いがるようです。主に小さなお店のオーナーですけど。

　

アプリ側のトラブル対処機能だけでは、十分な安定性を確保できません。動作環境であるiPadの使い方も、安定性が増すように注意する必要があります。iPad環境をどのように整えたら良いのか、アプリ内のヘルプとして記述しました。

その内容は、一般的なパソコンの注意点と同じです。余計なアプリを、できるだけインストールおよび起動しないこと。フラッシュの空き容量を十分に確保すること。アプリは何日も連続して使えるように作ってありますが、できれば毎日の業務終了後にアプリも終了し、１日１回は再起動してクリーンな状態で使うこと、といった具合です。こういう大事な点を知らせておくと、余計なトラブルを起こさずに済みます。

iPadのように、部品のほとんどが電子化されている機器の場合は、初期不良を除くと、あまり壊れないのではないでしょうか。機器の故障よりも、落下させたなどの人為的なミスで壊れる可能性が高いでしょう。それも、iPadにカバーを付けることで、大きく壊れることは防げます。機械的な破損の場合は、液晶画面が割れたまま動き続ける可能性もあり、その状態でならデータをコピーできます。そういった面も含め、データを守ることの大切さをユーザーに伝えることも、大事な仕事ではないかと思います。

　

アプリが異常終了してもデータを守る話を書きましたが、そもそもアプリが異常終了しないように作るのが大前提です。アプリが安定して動作するように、トリッキーな作り方を避けるのはもちろん、動作が少し遅くなっても構わないので、安全な作り方を選択するように心がけています。また、iOSアプリの基本ルールである「使い終わった画面は終了してメモリーを開放する」という形で、メインメニュー以外の画面を作っています。

おかげさまで、データを失うようなトラブルは、まだ起こっていません。「手を抜かないで真面目に作っているほど、安定して動く」という、先人の言葉を参考にしながら開発しています。