Android での SQLite データベース処理の下位互換性、複雑さ、およびベスト プラクティスを最適化するのに苦労しています。SQLite データベースとカーソルを管理する非推奨ではない方法を 2 つ見つけました。
- 直接通して
android.database.sqlite
ContentProvider
、CursorLoader
およびLoaderManager
私は、データベース実装の将来の証明を設計しようとしています。これは、Google が推奨するベスト プラクティスを実装したいと考えていることを意味します。との実装に関するチュートリアルを見つけました。ContentProvider
LoaderManager
Lars Vogels の提案に従うと、私のコードは重複と不必要な複雑さで吹き飛ばされてしまいます。私のデータベースのいくつかのテーブルでは意味があります。ただし、これを 3 つのフィールドを持つマッピング テーブルに実装しても意味がありません (たとえば)。さらにActionbarSherlock
、Callback Interface に問題がありLoaderManager
ます (解決策はありますが、データ処理クラスが 2 倍になります)。
を介してデータベースとカーソルを直接処理android.database.sqlite
すると、リソース管理の問題が発生し (カーソルを閉じてください!)、タスク処理の責任を負うことになります。
私の質問:
Android で SQLite データベースをどのように処理していますか?
さらに一歩進んで実装するのはContentProvider
いつLoaderManager
ですか?
下位互換性をどのように維持していますか?
私の現在のアプローチ:
データベース I/O (経由android.database.sqlite
) をアクティビティから分離するクラスを作成しました。すべてのメソッドは、実行中に (アクティビティの外で) 使用するカーソルを開閉し、必要に応じて (カーソルの代わりに) オブジェクトまたはデータを返します。I/O 操作は で実行されAsyncTasks
ます。このアプローチは非常に非推奨のようです。