Android 记事本 Uri 说明
在android Notes演示中，它接受URI：
sUriMatcher.addURI(NotePad.AUTHORITY, "notes", NOTES);
sUriMatcher.addURI(NotePad.AUTHORITY, "notes/#", NOTE_ID);
其中notes和notes/#之间的区别是notes/#返回ID与#匹配的笔记。
但是，用于从内容提供程序获取数据的 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 而不是仅使用选择参数的设计决策是否有任何特殊原因？或者这只是一个品味问题？
谢谢。
In the android Notes demo, it accepts the URI:
sUriMatcher.addURI(NotePad.AUTHORITY, "notes", NOTES);
sUriMatcher.addURI(NotePad.AUTHORITY, "notes/#", NOTE_ID);
Where the difference between notes and notes/# is that notes/# returns the note who's ID matches #.
However, the managedQuery() method that is used to get data from the content provider has the following parameters:
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.
So, is there any particular cause for the design decision of providing a URI for that, rather than just using the selection parameter? Or is it just a matter of taste?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为这样您就可以进行更复杂的查找，而不必使您的选择和参数复杂化。例如，在我的项目中，我有多个表，但使用相同的选择和参数。来过滤内容。通过使用 URI，我无需解释查询，只需打开 URI。一开始可能是个人品味。但在更复杂的场景中，您会欣赏 URI。您还可以使用 * 以与 # 相同的方式匹配字符串。
I thinks its so you can do more complex lookups without having to complicate your selections and arguments. For example in my project I have multiple tables but use the same selection and arguments. To filter content. By using the URI I don't have interpret the query, I can just switch on the URI. It.might be personal taste to begin with. But in more complex scenarios you appreciate the URI. You can also use * to match strings in the same.way you can with#.
我认为这主要是品味问题。恕我直言，将 id 放入 Uri 中会更干净一些，因为您可以使 id 不透明，而不是要求客户端知道它实际上代表特定的行 id。例如，您可以传递查找键（如在联系人 API 中）而不是特定的行 ID。
I think it's mostly a matter of taste. IMHO, putting the id in the Uri is a little cleaner since you can make the id opaque rather than require the client to know that it actually represents a specific row id. For instance, you can pass a lookup key (like in the the Contacts API) rather than a specific row id.