Kotlin新手关于RecyclerView与ViewBinding的技术疑问

Hey there! No need to apologize for your English—your questions are super clear, and they’re all really common (and smart!) ones when you’re getting started with these tools. Let’s break them down one by one:

1. Why pass binding.root to RecyclerView.ViewHolder instead of the binding object directly? #

a) Wait, why can’t I just pass the binding itself? #

Great question! Here’s the key difference:

• RecyclerView.ViewHolder’s constructor requires a View as its parameter—it needs the root view of your list item to manage the item’s layout and views.
• The RecyclerRowBinding object you create isn’t a View at all. It’s a generated helper class that holds references to all the views in your recycler_row.xml layout (like text views, image views, etc.), plus a reference to the layout’s root view via binding.root.

Think of the binding class as a "container" for your layout’s views—it makes it easy to access them without findViewById, but it’s not the actual view hierarchy itself. So you have to pass the root view (binding.root) to the ViewHolder, since that’s what the ViewHolder needs to work with.

2. What exactly is being inflated when using RecyclerRowBinding.inflate()? #

You’re right that the old way required passing R.layout.xxx, but the new ViewBinding approach simplifies this:

• The RecyclerRowBinding class is automatically generated to be tied directly to your recycler_row.xml file. When you call RecyclerRowBinding.inflate(), the system already knows which XML layout to inflate—no need to pass it explicitly, because the binding class name matches your layout file name (converted to camel case: recycler_row → RecyclerRowBinding).
• The parent parameter you pass tells the inflater what layout parameters (like width/height) the item should use (it inherits from the parent RecyclerView’s layout rules). Setting attachToParent = false is important because RecyclerView handles adding the item view to itself later—if you set this to true, you’d end up with duplicate views or layout errors.

So in short, you’re still inflating the recycler_row.xml layout—ViewBinding just hides the R.layout reference because it’s already linked to the generated class.

3. Is parent referring to my RecyclerView? #

Yep, exactly! The parent parameter in onCreateViewHolder is the instance of your RecyclerView that’s hosting the list items. It’s used to ensure the item layout uses the correct layout parameters from the RecyclerView.

4. How does holder.itemView exist if I didn’t define it in LandmarkHolder? #

Ah, this is about inheritance! Your LandmarkHolder class extends RecyclerView.ViewHolder, right? The RecyclerView.ViewHolder superclass already has a public itemView property—it’s the exact View you passed to the ViewHolder’s constructor (which is binding.root in your case).

• itemView is indeed a View subclass, and all View objects have access to a Context via itemView.context—that’s why you can use it to get the context you need.
• Since your LandmarkHolder inherits from RecyclerView.ViewHolder, it automatically gets access to all the superclass’s properties, including itemView.

5. Where is onCreateViewHolder called, and why isn’t binding a View? #

• Who calls onCreateViewHolder? This method is called directly by the RecyclerView itself. RecyclerView manages its own view recycling: when it needs a new list item (e.g., when you scroll to a position that doesn’t have a reusable ViewHolder already), it triggers onCreateViewHolder to create a new one. You don’t need to call it manually from your Activity, Adapter, or XML.
• Why isn’t binding a View? As I mentioned earlier, the binding class is a generated helper class, not a subclass of View. Its job is to give you direct, type-safe access to every view in your layout (so you don’t have to use findViewById). It holds a reference to the root view (binding.root), but it’s not a view itself—it’s just a wrapper that makes working with your layout easier.

内容的提问来源于stack exchange，提问作者selman uyanık