自分の考えたAndroidアプリのアーキテクチャ。Unix like File And Syncの頭文字をとってUFASアーキテクチャと呼びたい。 ユーファスと読む。
概ね以下のようなアーキテクチャ
以下この二つの要素を説明していく。
まずアプリのストレージとしてデータベースやdata下をなるべく使わずに、プレーンなファイルとディレクトリをなるべく使う。 テキストならプレーンテキスト、画像ならpngなど、なるべく普通のファイルを使う。
プレーンテキストもjsonなどでは無く、行指向のデータだけを素直にもったもの。 ファイルの中にメタ情報はなるべく入れずに、メタ情報はファイル名やディレクトリ構造になるべく反映させる。
保存はStorage Access Frameworkを使って特別な権限は無しでユーザーにコントロールさせる。
Unix的なプレーンファイルをローカルに保存してフォルダsyncでPCと共有する、これが基本的なUFASアーキテクチャの考えとなる。 このおかげで、アプリ自体はネットワークのコードが必要無い。
このように作る事で最初からオフライン機能が自然と提供でき、セキュアでアプリのメンテナンスも容易で、 バックアップなどの管理も容易になり、新しいデバイスに乗り換える時にも個々のアプリのアカウントの設定などが不要になる。
UFASアーキテクチャには数々のメリットがある。すでにここまでの解説でも幾つか触れたが、以下にまとめてみたい。 なお、いくつかの項目はお互いに関連しているので重複した説明も入ってしまっている。
Androidのアプリはメンテナンスが大変である。Androidのバージョンが変わるごとに多くの変更が必要になって、 何もしてなくてもちゃんと動く事を保証するだけでかなりの労力が必要となる。
その多くはネットワークのコードに起因する。 ネットワークはセキュリティ的にも問題が起きやすい所なので、Androidのバージョンが上がる都度多くの変更がある。 それらに追随してセキュアに保ち続けるのはなかなか大変である。
Storage Access Frameworkは最近はかなり安定してきたので、あまり変更も多くなくなってきた。 だからAndroidのバージョンをあげてもあまり変更が必要にならない。
UFASアーキテクチャならアプリ自体にはネットワークのコードを含まないのでこうしたメンテナンスのコストが無い。 これはAndroidのアプリというメンテナンスが大変な分野において、重要なメリットとなる。
フォルダsyncはやる事が単純であるが故に非常に堅牢に作りやすく、また実際に多くのフォルダsyncアプリは堅牢に出来ていると思う。 ネットワークをこのネットワークを専門にしたアプリに任せる、というのは、セキュアなシステムになりやすい。
フォルダsyncはグローバルなインターネットに出る必要が無いようにも設定できるので、 この場合は秘匿したいプライベートなデータをインターネットを通らなく出来、流出のリスクが下がる。 サーバーも不要なため、サーバーをexploitされるリスクも無い。
Storage Access Frameworkもバージョンを重ねた枯れたシステムなのでセキュリティ的にも信頼出来る。
Unix的なファイルというものは、スクリプトでの操作が容易だ。だから最初の段階ではとりあえずアプリで保存だけ作ってしまえば、 加工的な事はPCで行う、という分業がやりやすい。
こうした小さなスクリプト群にわかれたシステムが開発やメンテナンスのしやすさに優れて堅牢に作りやすいのは、 クラウドなどの仕事をしている人には広く知られている事と思う。
最初にサーバー側を用意しないで始められるのもUFASアーキテクチャの特徴に思う。 これも最低限動くものを作って、コンセプトの正しさを確認していく事を容易にしていると思う。
Androidのアプリはとりあえず使える所までの敷居が高いと思う。 そこをなるべく低くするのは小さく始めるというソフトウェア開発の原則においてとても重要な事で、 UFASアーキテクチャは最も小さくアプリの開発を始める方法を追及したものと言える。
アプリの数を増やす時に、アカウントの設定というのは大きな手間だ。 スマホなどは定期的に端末を乗り換える、という事が起こるし新たなデバイスが追加される事も多い。
こうした時にアプリごとにアカウントの設定が必要になると、多くのアプリを使うのが面倒になる。
UFASアーキテクチャならSyncthingなどの設定を一回行えれば、個々のアプリはフォルダを指定するだけで、面倒がない。
そのおかげで小さなアプリをたくさん使うのが容易になるので、アプリを小さく作りやすい。 小さいアプリはメンテナンスも容易になるので、先に述べたメンテナンスの容易さにも寄与することになる。
Unix的な哲学にしたがってシンプルに設計したデータフォーマットは、あまり変更の余地が無いくらい単純に出来る事が多い。 そうしたフォーマットは最初に決めたら、割とそのまま変更の必要が無い事も多い。 アプリ自体がどんどん変更されていても、データ自体のフォーマットはそのままになる。
これは元々Unix的な哲学に則ってフォーマットを設計すると、出来る事にかなり制約があるせいでもある。 こうした形に上手く表現出来ない機能はなるべく無くす、という設計圧力がUFASアーキテクチャにはある。
もちろんテキストファイルにjsonを保存するようにするなど、部分的に逸脱すればこれらの制約は回避できる。 その結果としてここで挙げているようなメリットの一部を失う事にもなるが、そうしたトレードオフを意図的に選択出来る、 というのがメリットと言える。
また、プレーンテキストやpngファイルなど自体はかなり安定したフォーマットなので、それが専用のツールが無くとも長期間使えるものである事は期待できる。
ツールの開発を終えてもデータはそのまま使える事が期待できる。
Unix的なファイルというのは他のツールからも操作しやすい。 同じデータを扱うPC用のElectronのアプリを作るのは多くの場合容易だし、実際自分も良く作っている。 エディタの拡張などで扱う事もしやすい。
こうしたヘテロジーニアスな環境のそれぞれで共通のデータを扱いやすいというのも大きな強みと言える。
またデータ自体が他のアプリに開かれている結果、アプリ自体の開発が終わったり寿命がきても、データはその後も使い続ける事が出来る。
また、当然ながらサーバーやサービスへのロックインというのも必要最小限で済む。
例えば今フォルダsyncにはSyncthingを使っているが、機能が単純なのでいつでも他のシステムに乗り換える事が出来る。
また、公開にはスクリプトでデータを加工してGithubPagesで公開しているものが多いが、 これもスクリプトを変更すれば他のサービスに乗り換える事はいつでも出来る。 データ自体はこれらに依存していないので、これらのサービスの寿命よりも長く生きる事が期待出来る。
バックアップはそのままUSBハードディスクにコピーすれば良いしgitで管理したりgithubに公開したりGoogle Driveに置いたり、 柔軟な運用が可能。
また、プレーンなファイルはアプリを必要とせずに閲覧、編集が出来るので、PC上でちょっとした変更などを後から行うことも出来るし、 適当な書き捨てスクリプトで操作する事も出来る。 これはアプリやシステム（Androidなど）の寿命が尽きた後でもメンテナンスが行える事が期待できる。