How the system of URIs should be designed?

问题

The ListView should display the content of the rather long code-list of products (say up to 100 thousands, i.e. nothing small). Because of that, effective and interactive searching is important. For the reasons not explained here, the filter value should be the part of URI...

I am using SQLite table, and the LoadManager and CursorLoader approach. Whenever the filter string changes, the cursor loader is reset, and the onCursorLoader is called, in turn. I am using the code like this:

@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;
}

Please, focus on the uri composition. Here the PRODUCTS_CONTENT_FILTER_URI was defined as:

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

The example may look like

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

Where abc is the filter value entered by the user. I feel this URI design may not be correct (being a beginner in the area). For me, the following examples are OK:

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

However, is the suffix like filter/value the good way to go?

Update: I will finally have several interrelated activities. Think in terms customer, product, order head, order list, list of notes. I am new to web-like system of adressing the data (i.e. to how the URI system should be designed). I would like to design the rules for my URIs so that it could be a kind of generalized. I know they are just strings, and I could do it whathever way. But I would like to do it nicely :)

For example: If the list of customers becomes big, the user may want to filter that list. I probably want to express filtering as a part of the URI. The list of products already is big. I would like to use tha same URI structure for the products. Now, the orders put customers and products together.

Say, I would like to display the list of products for the customer and for the order (order head) joined with the information about the ordered quantity of the products including the products with zero quantity (to be able to add them into the order). This way the combined list of products with the quantity is a kind of similar to the plain list of products (at least the same number of items in the list)-- the user may want to filter, change ordering, etc. However, the URI should contain the customer id, and the order id. When filtering is added, it should be also added to the URI. I know I can simply use the path like /customer/123/order/456/filter/apple where apple is the filter value, and the numbers 123 and 456 are the id's for the tables expressed by the previous part of the path...

From another point of view--for the previous example--the customer id, order id, and the filter value may be used as key-value pairs for keys being 'custome', 'order', and 'filter' respectively. Moreover, I do not know what will be added in future.

I would like to start with the system of the applicatios URIs correctly. I guess it had to be done many times by the others. Can you share your experience? I would like to avoid the neccessity to redesign it later.

回答1:

it is a matter of convenience how you structure it. I add "filter" URIs to reduce complexity of queries (e.g. multiple "WHERE" conditions, "JOIN"s)
ListView is reusing child views so it can handle much. Adapter filter is designed to reduce what is already in the adapter. As we are talking about large data I would prefer to not get it loaded in the first place.

来源：https://stackoverflow.com/questions/18121813/how-the-system-of-uris-should-be-designed

标签

android

android-listview