1

大規模なデータベースを使用する場合、私の場合、約 20 の DataSource 定義 (DS ごとに 2 ～ 5 個のテーブルが同じ SQLiteDatabase に格納されています) で、ほとんど問題は発生しません。

例えば：

アプリケーションのデータを他のサービス/アプリケーション ( 1、2 ) に公開しない場合は ContentProviders を使用する必要がないことはわかっていますが、上記の問題のほとんどを解決し、ブロードキャストや使用法などの興味深い機能の実装を許可/プッシュすると思いますデータにアクセスするためのカーソル。

それはContentProviderパターンの単なる誤解ですか、それとも言及されているだけでなく、可能性のある問題に対する本当に複雑な解決策ですか?

4

2 に答える 2

1

startmanagingcursorの最近の非推奨と、ドキュメントやいくつかの本 (reto meyer の本を含む) から読むことができるものを考えると、 contentprovider は、リストしている問題を含む多くの問題を克服するための推奨されるアプローチのようです。

公式ドキュメントに、データを他のアプリケーションと共有するつもりがない場合は、独自のプロバイダーを開発する必要はないと記載されている場合でも、ローダー ベースのアプローチが強く宣伝されており、問題について心配する必要がなくなることは明らかです。データが変更されるたびにローダーに自動的に通知できることは言うまでもありません。

また、コンテンツ プロバイダーを外の世界に隠すことができることにも注意してください。

android:exported="false"

sqllite 呼び出しはスレッドセーフであるため (私が覚えている限り)、スレッドの同期はどのような場合でも心配する必要はありません。

また、コンテンツ プロバイダーの作成には多くのボイラープレート コードが含まれることにも同意します。そのため、それを作成するためのスクリプトを作成しました :-) . 興味がある場合は、ここで確認できますが、Google で「コンテンツ プロバイダー ジェネレーター」を検索すると、より良い代替手段ではないにしても、まともなものが返されることも考慮してください。

于 2013-01-02T22:00:19.093 に答える