私はAndroid用のSQLiteデータベースプログラミングを行いましたが、これ以外はContent-Providerについて何も知りません。「AndroidDeveloperページを参照したので、Android SDKは、データの保存と取得に使用される「Content-provider」について説明しました。」
しかしその後、
- 「Content-Provider」と「SQLiteDatabase」の正確な違いは何ですか？
- データを保存するのに最適なのはいつですか？
任意の例または助けます!!
私はAndroid用のSQLiteデータベースプログラミングを行いましたが、これ以外はContent-Providerについて何も知りません。「AndroidDeveloperページを参照したので、Android SDKは、データの保存と取得に使用される「Content-provider」について説明しました。」
しかしその後、
任意の例または助けます!!
回答:
私は次のように1つの大きな違いを見つけました：
データベースにデータを保存することは、データを永続化するための1つの良い方法ですが、Androidには注意が必要です。Androidで作成されたデータベースは、visibleそれらを作成したアプリケーションに対してのみです。つまり、Android上で1つのアプリケーションによって作成されたSQLiteデータベースは、そのアプリケーションでのみ使用でき、他のアプリケーションでは使用できません。
したがって、need to share data between applications, you need to use the content provider model as recommended in Android.この記事では、コンテンツプロバイダーの基本と、コンテンツプロバイダーを実装する方法について説明します。
私はこのリンクでこの記事を見つけました
本当に素晴らしい情報が提供されました。
「Content-Provider」と「SQLiteDatabase」の正確な違いは何ですか？
ContentProviderはファサードです。データベースを他のプロセスに公開するために実装できるAPIです。それはすることができ、データはSQLiteデータベースに格納された方法で実装されるが、それはする必要はありません。
データを保存するのに最適なのはいつですか？
それを抽象的に答えることは不可能です。一般的に言って、何かがあなたに使用を要求しない限りContentProvider、ただデータベースを使用してください。
私は、SQLiteメソッドを使用するだけの数千人のユーザーが使用する多くの優れたアプリを作成しました。しかし、それは少し前のことであり、ContentProviderで簡単に処理できるようになった多くのコードを手動で作成する必要がありました。当時、私はコンテンツプロバイダーの使用に賛成していませんでした。それは、コードが複雑になるだけのようだったからです。
ただし、ここ数年、Androidが進化するにつれて、時間を節約し、より多くのことができるようになるため、ContentProviderに移行しました。今では広く使っています。コンテンツプロバイダークラスを作成すると、作業がはるかに簡単になります。ContentProviderを使用すると、過去にすべてを手動で作成する必要があったカーソルローダー、ローダーコールバック、バルクインサートを簡単に処理できますが、それでも効率的に機能しませんでした。特にリストビューを更新する場合は、notifychange（）メソッドが1つだけで自動的に更新されるようになりました。つまり、自分のリスナーを入力したり、リストビューやアダプターのコンテンツを手動で更新したりする必要がなくなりました。さらに、データベースの開閉について心配したり、メモリリークについて心配したりする必要はありません。それはすべてコンテンツプロバイダーによって処理されます。私が時々直面する唯一の問題は、ContentProvidersでいくつかの複雑なクエリを実行できないことです。この場合でも、生のクエリを使用して、sqliteとの昔ながらの手動操作を使用できます。
以前に独自のDbAdapter、Helper、およびObserverを作成したことがある場合は、すべてをContentProviderに変換するために時間を費やすことなく、それらを新しいアプリに安全に引き継ぐことができます。しかし、私の経験に基づいて、ContentProviderに移行することを強くお勧めします。慣れるまで少し時間がかかりますが、一度経験を積めば、それを使い続けることができます。
UPDATE 2017 私は今、レルムに切り替えました。これは、あらゆるプラットフォームでデータベースを使用するためのはるかに優れた方法です。それを学ぶのに数時間を費やし、アプリ開発のキャリアで数え切れないほどの時間を節約してください。
デフォルトでは、コンテンツプロバイダーはスレッドセーフではありません。コンテンツプロバイダーを使用する複数のスレッドがある場合、スローされるさまざまな例外やその他のデータの不整合を確認できます。これを修正する最も簡単な方法は、コンテンツプロバイダーによって公開されている各パブリックメソッドでsynchronizedキーワードを使用することです。
このようにして、一度に1つのスレッドのみがこれらのメソッドにアクセスできます。
新しいサーバルマップアプリケーションでは、バイナリファイルからアプリケーションが内部で使用するデータベースにデータをインポートする必要があります。これを実行し、アプリケーションの残りの部分とうまく連携するには、次のことを行うのが最善です。
他のスレッド、特にUIの更新を担当するスレッドに悪影響が及ばないように、新しいスレッドを生成してインポートを実行します。各インポートの最後で一時停止して、同期されたメソッドを使用する必要がある他のスレッドにチャンスを与えます。
Androidのコンテンツプロバイダーが機能する方法は、コードの残りの部分と基盤となるデータベースの間に抽象化レイヤーを提供することです。これは主に、私が知る限り、コンテンツプロバイダーがデータベース以外の場所からデータにアクセスできるという事実によるものです。
つまり、基になるデータベースで生のSQLクエリを実行することはできず、クエリメソッドなどのさまざまなメソッドに渡される変数を使用してSQLクエリのさまざまなコンポーネントを指定する必要があります。SQLがコンテンツプロバイダーによって処理される方法に適合しないタスクがある場合、2つのオプションがあります。
クエリについて横方向に考えてください。別のクエリを実行し、カーソルから結果にアクセスすることで、必要なデータを取得できる可能性があります。データに通常どおりアクセスするためのURIと、代替手段がないタスクの特定のクエリに一致する特別なURIを使用します。
私は同じ疑問を探しながらこの答えを読んだので、それを共有することを考えました。それは述べています-
内部での変更を容易にするために、データに対して追加レベルの抽象化を提供することをお勧めします。後で基になるデータベース構造を変更することにした場合はどうなりますか？ContentProviderを使用する場合、その中にすべての構造変更を含めることができますが、使用しない場合と同様に、構造変更の影響を受けるコードのすべての領域を変更する必要があります。さらに、データベースへの低レベルのアクセスでコードを散らかすのではなく、データにアクセスするために同じ標準APIを再利用できるのは素晴らしいことです。
したがって、コンテンツプロバイダーを使用することをお勧めします。
高度なコンテンツ管理システムについて考えてみてください。各オブジェクト（ページ、画像、ニュース記事、イベントアイテムなど）には、コンテンツ、アドレス、ユーザー権限、およびシステムのさまざまな部分からオブジェクトを操作する方法があります。コンテンツプロバイダーはAndroid用にそれを行います。これで、アプリケーションに保存した可能性のあるファイルまたは画像を共有できます。ビジネス連絡先、編集可能なメモなどのカスタム共有可能オブジェクトを作成することもできます。また、他のアプリケーションからオブジェクトを開いたときにそのようなオブジェクトを処理するセキュリティとデフォルトのアプリケーションを指定します。
1つの違いは、コンテンツプロバイダーがコンテンツオブザーバーをプラットフォームでサポートしていることです。SQLiteデータベース用に独自のObservableパターンを実装する必要があります。