Android ListView 适配器中 item-id 的用途是什么?
(不是特定于 ListView,而是特定于 Adapter)。
当我子类化 BaseAdapter 时,我继续实现这个:
@Override
public long getItemId(int position) {
return position;
}
因为必须实现它。我没有看到它有任何用处,我只需要 getItem(position),而不是 getItemId(position)。
我想知道它是否有任何意义(对于Android SDK或其他东西)?
(Not specific to ListView, but to Adapter).
I keep implementing this when I subclass BaseAdapter:
@Override
public long getItemId(int position) {
return position;
}
Because have to implement that. I don't see any use of it, I need getItem(position) only, not getItemId(position).
I wonder if it has any significance (to Android SDK or something else)?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
想象一下这样的结构:
您有数据库表 Notes,其中包含 3 条记录:
并且您实现了一个适配器来提供这些数据。
现在让我们看看在这种情况下位置和项目 id 是什么
位置 - 是加载数据集中记录位置的序数。例如,如果您使用
ORDER BY ID ASC
加载该表,则itemId - 是记录的“主键”,您的实现可以返回
中的位置和 itemId
在 Android 标准适配器ArrayAdapter / SimpleAdapter
在 ArrayAdapter 和 SimpleAdapter 中位置和 itemId 是同一件事:
SimpleCursorAdapter (以及从 CursorAdapter 继承的所有类型)
在 SimpleCursorAdapter 和 CursorAdapter 的所有后代中 itemId 是来自的值_id 列:
Imagine this structure:
You have db table Notes with such 3 records:
and you implement an adapter to serve this data.
Now let's see what position and item id are in such a case
position - is an ordinal number of record position in the loaded dataset. For example if you load that table with
ORDER BY ID ASC
, thenitemId - is a "primary key" of a record, and your implementation can return such values
position and itemId in Android standard adapters
ArrayAdapter / SimpleAdapter
In
ArrayAdapter
andSimpleAdapter
position and itemId is the same thing:SimpleCursorAdapter (and all types that inherit from CursorAdapter)
In the SimpleCursorAdapter and all descendants of CursorAdapter itemId is a value from _id column:
拥有稳定项目 ID 的原因可能有很多。无法给出默认实现,因为它取决于存储在适配器中的对象类型。
Android 有一项检查,以确保项目 ID 仅在稳定时才使用,即子类已正确重写
getItemId
; BaseAdapter.hasStableIds 必须重写才能返回 true 。我遇到的几个原因:
AdapterView.OnItemClickListener的方法
onItemClick(AdapterViewparent, View view, int position, long id)
还发送long id
getCheckedItemIds 方法
仅当选择模式尚未设置为 CHOICE_MODE_NONE 并且适配器具有稳定 ID 时,结果才有效。
回复“因为必须实现这一点”:您不必必须 如果您不使用这些功能,则无需。但如果您这样做,也不要忘记覆盖
boolean hasStableIds()
。There are probably many reasons to have stable item IDs. A default implementation cannot be given since it depends on the type of Object being stored in the Adapter.
Android has a check to make sure that item IDs are used only when they are stabled, i.e. the subclass has properly overridden
getItemId
; BaseAdapter.hasStableIds must be overriden to return true.Few reasons I have come across:
AdapterView.OnItemClickListener's method
onItemClick(AdapterView<?> parent, View view, int position, long id)
also sendslong id
the getCheckedItemIds method
The result is only valid if the choice mode has not been set to CHOICE_MODE_NONE and the adapter has stable IDs.
Reply to "Because have to implement that": you don't have to If you don't use the features, there's no need. But if you do, don't forget to override
boolean hasStableIds()
as well.正如@Reno 所写,它允许您将视图中的行映射到数据集元素。
这样做的目的之一是允许 ListViews 跟踪选择了哪个项目,即使列表中的位置发生更改或基础数据更新也是如此。
As @Reno writes, it allows you to map rows in the view to data-set elements.
One of the purposes of this is to allow ListViews to keep track of which item is selected, even if the positions in the list are changed or the underlying data is updated.
如果您将 ArrayAdapter 子类化,则可能不必实现该方法。
大多数情况下,我发现该方法可用于确定 onClick 事件期间单击了哪一行,并使用该 ID 作为传递到下一个活动的 Intent extra 的一部分。
If you subclass ArrayAdapter instead, you may not have to implement that method.
Mostly I find that method useful to determine what row was clicked during onClick events, and use that ID as part of the Intent extras passed to the next activity.
是的,它是一个抽象函数,称为通过 android 将适配器数据集行 id 映射到您的列表位置。
欢迎您深入挖掘
Yes it is an abstract function which is called by android to map the adapter data-set row id to your list position.
You are welcome to dig deeper