2

既に作成されたアプリの機能を含むライブラリを作成しようとしています。古いアプリは、複雑な sqlite データベースを使用しています。古いデータベースをコンテンツ プロバイダーのバックエンドとして再利用しようとしていますが、自分がやろうとしていることの "ベスト プラクティス" とは何か、さまざまな例 ( this、this、およびその他)を適応させる方法がわかりません。私は自分の状況に気づきました。

このデータベース構造があるとします

+------+-------------+-------------+-------------+
| Root |   Folder    |    Item     |  Subitem   |
+------+-------------+-------------+-------------+
| _id  | _id         | _id         | _id         |
| uuid | parent_uuid | parent_uuid | parent_uuid |
|      | uuid        | uuid        | uuid        |
|      | name        | name        | name        |
|      | data        | data        | data        |
+------+-------------+-------------+-------------+
Root->Folder->Item->Subitem

以前は、parent_uuid などのパラメーターを受け取る関数呼び出しを提供する DbAdapter クラスを使用し、関数内のすべての SQL クエリを処理し、結果を含むカーソルを返しました。

関数スタブの例:

  • get_items_by_parent_uuid(folder_uuid)
  • get_item_by_uuid(uuid)
  • サブアイテムも同じ

複雑なクエリ

  • get_items_for_root(root_uuid)
    • アイテムの uuid、アイテム名、アイテム データ、フォルダ名を含むカーソルを返します
  • get_items_with_subitem_count(folder_uuid)
    • アイテム uuid、アイテム名、アイテム データ、サブアイテムの数を含むカーソルを返します。subitem.parent_uuid == item.uuid

上記の機能を 1 で提供する最良の方法がわかりませんContentProvider。誰かに大量のコードを書いてもらう必要はありません (ただし、書いていただいても構いません)。上記のリンクされた例を変更してこれらのことを行う方法を誰かに理解してもらいたいだけです。例を理解してください。現在のニーズに翻訳するには不十分です。

TL;DR; - 複数のテーブルを処理し、一意の識別子として _id に依存せず、内部選択/クエリ ( など)ContentProviderを持つ可能性のある選択と共に結合を処理する単一のテーブルを作成するにはどうすればよいですか?select count(*)

4

1 に答える 1

3

複数のテーブルを処理する単一の ContentProvider を作成するにはどうすればよいですか

ステップ #1: スキーマの REST インターフェイスを設計し、データ構造として単純な JSON オブジェクトに制限します (つまり、ネストされた配列やオブジェクトではなく、単純な値へのキーのマップのみ)。

ステップ #2: そのデザインを に変換しContentProvider、http://sooperapp.jp36.com/をcontent://com.jp36.sooperappに置き換え、JSON を および に置き換えますCursors。ContentValues

したがって、たとえば、これらの各タイプの 1 つ以上に関する情報を取得/変更する基礎としてcontent://com.jp36.sooperapp/folderandcontent://com.jp36.sooperapp/itemをサポートすることができます。content://com.jp36.sooperapp/subitem

一意の識別子として _id に依存しない

を使用する予定があり、実際に UUID (通常は文字列) を意味するCursorAdapterと仮定すると、. ただし、を使用する予定がない場合は、特に必要はありません。uuid_idCursorAdapter_id

内部選択/クエリを持つ可能性のある選択とともに結合を処理します（選択カウント（*）など）

それはすべて、REST インターフェース/ContentProvider設計の問題です。content://com.jp36.sooperapp/folder/count舞台裏でそれを求める何かになりたい場合はSELECT COUNT(*) FROM Folder、自分をノックアウトしてください。

（注：文字通り自分をノックアウトしないでください）

プロバイダーへの呼び出しに基づいて 17 を使用する場合は、すぐcontent://com.jp36.sooperapp/omg/omg/omg/this/is/a/long/pathにINSERT行ってItemください。単なるファサードです。意味、意味、パラメーターの意味などを定義するのはあなた次第です。Subitemsinsert()ContentProviderUriContentValuesquery()

個人的には、一歩下がって、なぜContentProvider.

于 2012-04-30T23:20:52.117 に答える