0

はListView、製品のかなり長いコード リストの内容を表示する必要があります (最大 10 万、つまり、小さなものはありません)。そのため、効果的でインタラクティブな検索が重要です。ここで説明されていない理由により、フィルター値は URI の一部である必要があります...

私はSQLiteテーブルを使用しており、LoadManagerandCursorLoaderアプローチを使用しています。フィルタ文字列が変更されるたびに、カーソル ローダーがリセットされ、onCursorLoaderが呼び出されます。私は次のようなコードを使用しています：

@Override
public Loader<Cursor> onCreateLoader(int id, Bundle args) {

    // Compose the URI based on whether the content should be filtered or not.
    // mCurFilter contains the filter value.
    Uri uri;
    if (mCurFilter.isEmpty()) {
        uri = DemoContentProvider.PRODUCTS_CONTENT_URI;
    } else {
        uri = Uri.withAppendedPath(DemoContentProvider.PRODUCTS_CONTENT_FILTER_URI,
                                   Uri.encode(mCurFilter));
    }

    String[] projection = { ProductTable.COLUMN_ID,
                            ProductTable.COLUMN_CODE,
                            ProductTable.COLUMN_NAME,
                            ProductTable.COLUMN_STOCK,
                            ProductTable.COLUMN_PRICE };

    CursorLoader cursorLoader = new CursorLoader(this,
            uri, projection,
            null, null,     // no selection and selargs - filter value inside the URI
            orderInfo);     // info for sorting

    return cursorLoader;
}

構成に注目してくださいuri。ここでは次のPRODUCTS_CONTENT_FILTER_URIように定義されました。

public static final Uri PRODUCTS_CONTENT_FILTER_URI =
        Uri.parse("content://" + AUTHORITY
                   + "/" + ProductTable.CONTENT_PATH + "/filter");

例は次のようになります

content://cz.xxx.android.yyydemo.contentprovider/product/filter/abc

abcユーザーが入力したフィルター値はどこにありますか。この URI 設計は正しくない可能性があると感じています (この分野の初心者であるため)。私にとっては、次の例は問題ありません。

content://AUTHORITY/product/     ... to get all products
content://AUTHORITY/product/123  ... to get the product with _id = 123

しかし、接尾辞filter/valueは良い方法ですか？

更新:最終的に、いくつかの相互に関連する活動を行う予定です。顧客、製品、注文ヘッド、注文リスト、メモのリストという用語で考えてください。私は、データをアドレス指定する Web のようなシステム (つまり、URI システムをどのように設計する必要があるか) に慣れていません。一種の一般化できるように、URI のルールを設計したいと考えています。私はそれらが単なる文字列であることを知っており、どのような方法でも実行できます。しかし、私はそれをうまくやりたいです:)

例: 顧客のリストが大きくなると、ユーザーはそのリストをフィルター処理することができます。URIの一部としてフィルタリングを表現したいのでしょう。製品のリストはすでに大きいです。製品に同じ URI 構造を使用したいと考えています。現在、注文は顧客と製品を結び付けています。

たとえば、顧客と注文 (注文ヘッド) の商品のリストを、数量がゼロの商品を含む商品の注文数量に関する情報と結合して表示したいとします (注文に追加できるようにするため)。 . このように、製品と数量を組み合わせたリストは、単純な製品リスト (少なくともリスト内の項目数が同じ) に似ています。ユーザーは、フィルター処理や順序の変更などを行うことができます。ただし、 URI には、顧客 ID と注文 ID が含まれている必要があります。フィルタリングを追加する場合は、URI にも追加する必要があります。/customer/123/order/456/filter/appleどこappleにフィルター値があり、数字123と456パスの前の部分で表されたテーブルの ID のようなパスを単純に使用できることはわかっています...

別の観点からすると、前の例では、顧客 ID、注文 ID、およびフィルター値を、それぞれ'custome'、'order'、および であるキーのキーと値のペアとして使用できます'filter'。また、今後何が追加されるかわかりません。

アプリケーションURIのシステムから正しく始めたいと思います。私はそれが他の人によって何度も行われなければならなかったと思います。あなたの経験を共有できますか？後で再設計する必要は避けたいと思います。

4

1 に答える 1

0

  1. それをどのように構成するかは便宜上の問題です。クエリの複雑さを軽減するために「フィルター」URI を追加します (複数の「WHERE」条件、「JOIN」など)。

  2. ListView は子ビューを再利用しているため、多くの処理が可能です。アダプター フィルターは、アダプターに既に含まれているものを減らすように設計されています。大規模なデータについて話しているので、最初からロードしないことをお勧めします。

于 2013-08-08T09:42:51.547 に答える