Android DatabaseでのSQLiteStatementについて

AndroidのDatabaseを使う際に、SQLiteDatabase.compileStatementメソッドでSQLiteStatementを生成する方法がある。これは、実装上Insert,Update,Replace,Deleteのためのものではなく、あくまでそれ以外の呼び出し、Create/Drop Table, View , Indexを呼び出す際に利用するものとJavaDocに記述されている。

SQLiteStatementのオブジェクトはSynchronaizedなので、他のスレッドと共有でつかうことはできない。また内部のBind処理に関して、利用が終了した時点でClearBindArgsを呼ばないとクリアされないので、その動作が関係しているのではないかと推察する。

またSQLiteStatementを利用しなくても、execSQL（String）と等価であるとあるので、CreateTableでは利用しないし、DropTableでもSQLiteStatementはあまり利用しないとおもわれる。Bindする要素がなく、そのSQLを隠蔽したい場合にのみ使うとかんがえられる。そしてViewの場合に利用することが多くなりそうである。ViewのSQLを作成しておいてBindを行い、利用する局面はありうる。

追記
JavaDocには、COUNT(*)などの場合の呼び出しに使う場合が記述してある。

追記
SQLiteStatementのクラスJavaDocコメントを以下に引用する。

A pre-compiled statement against a SQLiteDatabase that can be reused. The statement cannot return multiple rows, but 1x1 result sets are allowed. Don't use SQLiteStatement constructor directly, please use SQLiteDatabase.compileStatement(String) 

SQLiteStatement is NOT internally synchronized so code using a SQLiteStatement from multiple threads should perform its own synchronization when using the SQLiteStatement.

基本的にはViewとしても使えないと考える。MAX、MINやCOUNTなどの特別なProcedureでの利用が主なようだ。

AndroidでのDatabase処理でinsertOrUpdate

Android:Is there a better way to insert and/or update a database entry?

AndroidのSQLiteのSQLiteDatabaseの動作は、insertとupdateが明確に分離している。
これ自体は、必ず新しく追加したい、必ず更新したいという動作をするときに必要になる。しかしながら、項目があれば更新なければ追加という動作を行いたい場合がある。これに関しては上記の質問の回答である。REPLACEを使えばよい。

SQLiteDatabase.replace

もともとSQLiteにはReplaceが特別な動作として定義されている。他のテーブルの場合には、INSERT IF CONFLICT や　INSERT OR UPDATEがあったりしたと思った。

AndroidでのLogCat用のTAGについて

AndroidでLogをLogCatに出力する際に、tag引数に、AndroidのSourceCodeでは大抵決まった書き方をしている。

 public class T {
     private static final String TAG = T.class.getSimpleName();
 }

 Tは任意のクラス名をつける。

このTAGを使えば、クラスに固有のTAGをつけることが可能になる。 EclipceでAndroidの開発を行なっているならばClassGeneratorに記述しておくこともいいのかもしれない。

Android Databaseについての覚書

Androidのandroid.databaseサブパッケージではSQLite向きのクラスは提供されていない。さらにそのサブパッケージである、android.database.sqliteに実装がある。

Classes

---

SQLiteClosable	An object created from a SQLiteDatabase that can be closed.
SQLiteCursor	A Cursor implementation that exposes results from a query on a SQLiteDatabase.
SQLiteDatabase	Exposes methods to manage a SQLite database.
SQLiteOpenHelper	A helper class to manage database creation and version management.
SQLiteProgram	A base class for compiled SQLite programs.
SQLiteQuery	Represents a query that reads the resulting rows into a SQLiteQuery.
SQLiteQueryBuilder	This is a convience class that helps build SQL queries to be sent to SQLiteDatabase objects.
SQLiteStatement	Represents a statement that can be executed against a database.

上記の表はandroid.database.sqliteのパッケージに登録されているClassである。これらのクラスでDatabaseを取り扱うときに利用するのは、SQLiteOpenHelperである。このクラスをサブクラス化して利用する。単純な実装としてはonCreate、onUpdateを利用することが必要とされているされてる。

これに拡張的なメソッド、例えばdeleteに対して、Androidでは_idのフィールドを必ずもつことから

• deleteById(String tableName, long id)

のような実装を追加してやることで削除のためのSQLを書くことが減るだろう。

また、利用する際の注意点としてはinsertメソッドの戻り値は、_idもしくは-1が戻ること。これに対して、delete,updateなどのメソッドでは「変更された列数」もしくは-1が戻る。この違いは注意が必要である。

追記
Androidアプリで使用するSQLiteのテーブル作成時の注意点
こちらのサイトで_idが必要なこととその後のInsertでの利用について説明がされています。

iPhone開発の学習記録は有益なコンテンツになるのか

どうもJudaです。
iPhone開発の学習記録は有益なコンテンツになるのか？
有益なコンテンツというのが、後続の開発者を増やすという意味ならばアリなのかもしれない。

そもそも学習によって得られた経験を凝縮して記録することはどういう文脈で肯定されるのか、また否定されるのか。
否定される文脈は、知識の本質が秘密であることから考えると容易に想像できる。
採集された知識がそのまま力として行使可能な状態としてポテンシャルに置かれることを考えると、同様に知識をもつものが増えるとその価値が下がるというか普遍化してポテンシャルがなくなる。それは優位性を消す行為であるから、否定される。
では肯定される文脈はどうなるか。
採集された知識を他者と共有することで場を形成し、より深い知識を取得する機会を得るようにする。他者に共有される場が広がるほどにそこに再度情報を上げてくる他者が存在すれば、その循環はより深化する。つまり正の循環をもたらすトリガとなる。だから情報を共有する行為は肯定される。

肯定する文脈を採用するとして、如何なる情報が場にとって有益なのか？如何なるコンテンツも有益なのか？後続の開発者にとって有益となる情報が妥当であると考える。その時に有益だと思われるのは、

• 特定の問題を解決するための手段

であると思われる。これに関してはどれぐらいの解決手順という期間ないしは規模を変数としてもつだろう。

1. 単一問題の解決
2. 一定条件下での問題の解決
3. ソリューションの解決

規模のレベルは上記の3種で大別されるだろう。

コンテンツの有益か否かの問題は書籍を凡例に取れば理解しやすい。

Adapter+Observerについて

どうもJudaです。
Androidに関するあれこれについて一部覚書をしておこうと思う。

• Adapterを使う場合にはBaseAdapterやArrayAdapterにしておく
• AdapterViewを継承してCustomWidgetを作る場合にはかなり実装すべき項目が多いので注意が必要。
• AdapterViewの継承クラスで実装すべきはViewの再利用、ViewTypeの考慮、ViewSelectorの扱い、Stateの変更、個別の子要素に対するイベントハンドリング、そしてスクロール処理である。
• AdapterViewで生成するViewに対してViewHolderの役割をもつクラスを用意すると良い。
• またこのクラスをObserverインターフェイスをもつようにすると更新の処理をより細かく制御できる。
• Drawableの継承で使いやすいのはShapeDrawableであり、細かな描画の実装を行うならDrawableにまとめるほうがイイ。

幸せな未来は「ゲーム」が創る 備忘録その１

どうもJudaです。
『REALITY IS BROKEN』の邦訳を読んでいる中で特筆すべき記述があったので、備忘録。

• ひとつは、ゲーマーはきわめて貴重な―そしてほとんど活用されていない―参加容量提供源だということです。（12行 p. 329 2011年11月15日 幸せな未来は「ゲーム」が創る 早川書房）
• ふたつ目は、クラウドソーシングプロジェクトはー本当に意欲的な目標を達成できるだけの参加容量を集められる見込みが多少なりともある場合にはー優れたゲームが与える報酬と同じような内発的報酬を与えられるように、意図的にデザインする必要があるということです。（16行 p. 329 2011年11月15日 幸せな未来は「ゲーム」が創る 早川書房）

如何にしてクラウドソーシングをして、少ない人数では達成できないように思えるプロジェクトを達成するのかということに言及している。第三部はそれまでとは一転して発展的な考察が多いので、面白い。