連載：世界を目指せ！Androidアプリ開発入門｜gihyo.jp … 技術評論社
第8回から。

さあ、SQLiteだ、と思ったのですが、サンプルが提供されているので、ほとんど流すだけでした。
ただ、イマイチわかっていないのが、実行環境のリフレッシュ、と言ったら良いのかなんなのか。
起動するたびに、データが追加されて、こんな感じです。

けど、これも冷静に考えれば、これで良いんですね。DBに登録しているわけだから、逆に覚えてくれていないとおかしいわけですね。

さて、サンプルでは、DBOpenHelper　というものが提供されていて、そこでDB_NAME = “Sample.db” が定義されているのと、テーブル作成、及び排他処理が行われています。
中間には、MainStore　というクラスがあり、TBL_NAME = “Test”という定義がされており、add、update、loadAll　等のメソッドが定義されています。
この構成だとテーブルごとに中間クラスを作成するイメージなので、テーブル作成も中間テーブル側で良いのかな、みたいな感想はありますね。細かいところでは、SQLiteDatabaseのメソッド名は、insert、updateなんだから、わざわざupdateにしなくて良いのでは、とか。
既存のフレームワーク、あるいは開発規約を持っているところは、そのカスタマイズで対応するのでしょうか。

というわけで、ちょっと深堀り。

まずは
Code Style Guidelines for Contributors
コントリビュータのためのAndroidコードスタイルガイドライン 日本語訳
を見るべきでしょうか。まあ、純粋な記述面での規約ですね。

次に、こちらのような命名規約も必要ですね。
android 開発規約 – aksoft – livedoor Wiki（ウィキ）

これの前提で、階層分けの規約も必要でしょう。上では、中間クラスとぼかしましたが、どこのソースで画面コントロールを意識するのか、どこのソースでテーブル・カラムを意識するのか、という階層分けを行った上で、それぞれの命名になるわけです。

さらには、セキュリティ面での規約となると、このようなレベルの話が出てきます。
JPCERT/CC、Javaのセキュアコーディング規約集を公開 Androidアプリ …
初心者が読むのは難しいかもしれません。しかし、どこかのタイミングで気にしておく必要はあります。というか、Androidは初心者でも、Javaは初心者じゃないということがほとんどだとすると、最初に目を通すべきですかね。

で、今回考える契機となった、DB接続規約ですが、イメージしているのは
androidでSQLite周りでハマったことのメモ。-aBatisを使おうとしてみた
みたいな感じです。このへんの王道はあるのかと。これはしばらくウォッチしてみないと分からなそうです。

Powered by ScribeFire.