コンテンツプロバイダーを使用する場合

コンテンツプロバイダーは、アプリケーション間でデータを公に共有できるように作られていることを理解しています。ただし、コンテンツプロバイダーを自分のアプリ内でのみ使用することを考えている人がいるかどうかは疑問です。これを行うことには利点がありますか？欠点はありますか？

以前は、データベースのデータにアクセスするためにSQliteOpenHelperを実装したばかりですが、コンテンツプロバイダーの作成を検討しています。データを要求するためのURIアプローチは明確で簡潔なように感じます。一方、私のアプリケーションだけにコンテンツプロバイダーを使用すると冗長になります（その中にはSQliteOpenHelperクラスが含まれるため）、必要以上の作業が発生しますか？

データを共有する予定がない場合は、コンテンツプロバイダーについて考えないでください。これらは強力ですが、書くのが難しく、内部で使用する場合、実装するのはばかげたことになります。

ただし、コンテンツプロバイダーを自分のアプリ内でのみ使用することを考えている人がいるかどうかは疑問です。

もちろん...たとえば、私が書いた古いTODOリストアプリの場合、他のアプリがタスクの状態を取得してアクセスできるようにコンテンツプロバイダーを作成する必要がありました。それは要件の一部でしたが、それ以上にそれは理にかなっていてアプリをより良くしました。

ContentProviderあなたがそれを公開するつもりがなくても、それを使用することは間違いなく良い考えだと私は主張します。

内部での変更を簡単にするために、データをさらに抽象化することをお勧めします。後で基礎となるデータベース構造を変更する場合はどうなりますか？を使用するContentProvider場合、その中にすべての構造変更を含めることができます。1つを使用しない場合と同様に、構造変更の影響を受けるコードのすべての領域を変更する必要があります。さらに、データベースへの低レベルのアクセスでコードを散らかすのではなく、データにアクセスするために同じ標準APIを再利用できるのは素晴らしいことです。

また、将来的にデータを公開する可能性が常にあります。事前に使用しないContentProviderと、後日改造するのがはるかに難しくなります。

次に、ContentProviderを使用するSyncAdapter場合や、データアクセスなどを含むアプリウィジェットが必要な場合など、が必須/推奨されるAndroidの他の部分があります。

要約すると、ContentProvider（とにかく良いアイデアであるAPIを学習した後の）事前の書き込みに伴うオーバーヘッドはほとんどないため、プライベートデータの場合でもそうすることは理にかなっています。

MOTODEV Studio for Eclipseを見てください。Eclipseを拡張した開発環境です。彼らには、データベースのコンテンツプロバイダーを自動的に生成できるツールがあります。コンテンツプロバイダーによってデータへのアクセスが容易になり、パフォーマンスに大きな影響がない場合は、先に進んで使用してください。ほとんどのシナリオでこれが当てはまります。

つまり、データを効果的Content Providersに管理するのに役立ちます。以下の理由でそれらを使用することをお勧めします。

• UIとデータベース間の抽象化レイヤーとして機能します。ContentProvidersにデータ検証を実装して、ユーザーが入力したデータを検証できます。また、構造を変更することもできます、UIやその他の部分に触れることなく、データベース。
• 彼らは他とうまく一緒に遊ぶのAndroidフレームワークのクラスのように SyncAdapter。たとえば、データベースの値がContentProvidersを使用して変更されたときに、リストを自動的に更新できます。CursorLoader。ContentProvidersがないと、これらのような多くの機能を自分で実装する必要があります。
• 個人データを他のアプリに安全に公開できます。ContentProvidersを使用すると、データを他のアプリと簡単かつ安全に共有できます。

したがって、これらの機能が必要なくなったとしても、将来的に必要になる可能性があるため、すぐに実装してすぐに実装できます。

ContentProvidersを理解するのは少し難しいと思いますが、自分のアプリで内部的に使用する場合でも、確実に役立ちます。これの最も良い点は、コンテンツプロバイダーを適切なURIに合わせてカスタマイズできることです。

データベースに5つのテーブルがあり、それらを使用する前にいくつかのテーブルを特定の順序で結合する必要があるシナリオを次に示します。そして、これらの各結合のコンテンツURIを作成します。次に、これらのURIをそれぞれテーブルとして使用できます:)

コンテンツプロバイダーを先に進めることをお勧めします。コンテンツプロバイダーがいかに強力であるかに驚くことでしょう。

私の考えでは、コンテンツプロバイダーには、他のアプリとデータを共有するだけで十分なメリットがたくさんあります。Sync-Adapterを使用してサーバーと同期する必要がある場合は、Googleクラウドメッセージングを使用し、ローダーを使用してDBの基になるデータが変更されたときにUIを自動更新し、検索を実装し、ウィジェットを使用します。コンテンツプロバイダーが最適です。

コンテンツプロバイダーに付属する上記の機能のいくつかを実装する必要がある場合があるため、ガイドラインに従うことをお勧めします

ちなみに、コンテンツプロバイダージェネレーターを使用すると、データベースとCPを5分未満ですばやく構築できます

ドキュメントで述べたように： コンテンツプロバイダーの作成

完全に独自のアプリケーション内で使用する場合、SQLiteデータベースを使用するためにプロバイダーは必要ありません。

では、なぜこのオーバーヘッドを開発する必要があるのでしょうか。より簡単で迅速な開発が必要ですよね？したがって、抽象化の1つの層（SQLiteOpenHelperの子孫）で十分です。

OccamのRazorを参照してください 。非常に正当な理由がない限りエンティティを作成しないでください。

他のアプリとデータを共有したくない場合は、コンテンツプロバイダーを使用しないでください。シンプルなsqlitedatabaseを使用して、データベース操作を実行します。機密情報は他のアプリからアクセスされる可能性があるため、機密データの保存にコンテンツプロバイダーを使用するときは注意してください

コンテンツプロバイダーを使用すると、抽象化のレベルが向上します。独自のアプリケーション内にコンテンツプロバイダーを配置すると、プロジェクトの開発時間が大幅に増加します。ただし、複数のアプリケーション間でデータ、アプリケーション設定または構成を共有するためにそれを使用している場合は、コンテンツプロバイダーを選択します。

セキュリティレベルに注意してください。コンテンツプロバイダーがSQLiteに書き込んでいる場合は、SQLcipherを使用してリセット時データ（DAR）を暗号化することをお勧めします。（私はいくつかのソリューションでコンテンツプロバイダーを使用しており、デバッグとテストのために運用値のライブ「スナップショット」を撮る機能を提供しました。）