Sql Android记事本Uri解释

在android Notes演示中，它接受URI：

    sUriMatcher.addURI(NotePad.AUTHORITY, "notes", NOTES);
    sUriMatcher.addURI(NotePad.AUTHORITY, "notes/#", NOTE_ID);

notes和notes/#的区别在于notes/#返回的是ID匹配的note

但是，用于从内容提供程序获取数据的managedQuery（）方法具有以下参数：

Parameters
uri The URI of the content provider to query.
projection  List of columns to return.
selection   SQL WHERE clause.
selectionArgs   The arguments to selection, if any ?s are pesent
sortOrder   SQL ORDER BY clause.

那么，设计决定提供URI而不仅仅使用选择参数有什么特殊原因吗？还是只是口味的问题

---

谢谢。

我想这主要是口味的问题。IMHO，将id放在Uri中有点干净，因为您可以使id不透明，而不是要求客户机知道它实际上代表一个特定的行id。例如，您可以传递一个查找键（如Contacts API中的）而不是一个特定的行id。

我认为是这样，您可以进行更复杂的查找，而不必使选择和参数复杂化。例如，在我的项目中，我有多个表，但使用相同的选择和参数。过滤内容。通过使用我没有解释查询的URI，我可以打开URI。这可能是个人的品味。但在更复杂的场景中，您会欣赏URI。您还可以使用*以与#相同的方式匹配字符串

你能链接到演示吗？我从来没有见过它。给你：，它在notepadproviderclass中（在src目录中，后面是一堆子目录）。我想到了这一点，我同意这会更干净一些，但要让用户理解他们要返回的光标，他们需要知道一点（又名，有哪些列）关于底层结构。