AsynQueryHandler。
別スレッド上でSQL発行。
終了通知はUIスレッド。
SQL絡みのエラーも通知できるように記述できる。メモリーカードいっぱいですよとか。
AsyncTaskLoader。
別スレッドを起こして、その中でSQLを発行。発行の仕方は生SQLでもServiceでもおk。
通知はUI上にくるけど、loader.destroyLoaderが走ればUI上にはこれない。
色々楽なのはServiceでSQLを投げること。
データ周りのアップデートは今後も続きそうだ。
serviceで投げた場合のトランザクションってどうなってるんだろう。
もうちょっとお勉強。
追記
トランザクションは特にないように見えた。
もともとSQLite自体がキャッシュした自身を公開してそれに対してアクセスする形だからなのかな。
contentResolverでエラーが発生するとプロセスKillされる。
つまり落ちる。
これはデータが常に静的に一意に使用可能なメモリが存在すること想定した動きと思われる。
つまり、エラーが起こった場合はandroidシステム上続行不可能なエラーとして扱うことを意味している。マウント解除とかありえねーという状況だと思う。
一方、AsynQueryHandlerの場合だとエラーでは落ちない。
これはContentResolverでのエラーをWorkerThread上でのエラーとしているからかな。
エラーであることを伝える実装が必要だが、メソッドが用意されている。
ついでにシンクロナイズドでスレッドを開始するので順次発行という形になっている。
public AsyncQueryHandler(ContentResolver cr) {
super();
mResolver = new WeakReference<ContentResolver>(cr);
synchronized (AsyncQueryHandler.class) {
if (sLooper == null) {
HandlerThread thread = new HandlerThread("AsyncQueryWorker");
thread.start();
sLooper = thread.getLooper();
}
}
mWorkerThreadHandler = createHandler(sLooper);
}
生SQLを実行するなら色々工夫すればおk。だけどすんごい手間。
0 件のコメント:
コメントを投稿