在Android Notes演示中,它接受URI:
sUriMatcher.addURI(NotePad.AUTHORITY, "notes", NOTES);
sUriMatcher.addURI(NotePad.AUTHORITY, "notes/#", NOTE_ID);
注释和注释/#之间的区别在于注释/#返回注释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的设计决策是否有任何特殊原因,而不仅仅是使用选择参数?或者仅仅是品味问题?
谢谢。
答案 0 :(得分:1)
我认为这主要是品味问题。恕我直言,把ID放在Uri中是一个更清洁,因为你可以使id不透明,而不是要求客户端知道它实际上代表一个特定的行id。例如,您可以传递查找键(如在Contacts API中)而不是特定的行ID。
答案 1 :(得分:1)
我认为它可以让您进行更复杂的查找,而不必使您的选择和参数复杂化。例如,在我的项目中,我有多个表,但使用相同的选择和参数。过滤内容。通过使用URI我没有解释查询,我可以只是打开URI。它可能是个人品味的开始。但在更复杂的场景中,您会欣赏URI。您也可以使用*来匹配相同的字符串。您可以使用#。