XML View System: Layouts, ConstraintLayout & RecyclerView

Real-world analogy

What is it?

The XML View system is Android's original UI framework — still the foundation of the vast majority of production apps. Views are inflated from XML, arranged by LayoutManagers, and bound to data via Adapters. ConstraintLayout enables complex flat layouts with chaining and barrier constraints. RecyclerView with ListAdapter + DiffUtil is the standard for displaying dynamic lists efficiently with smooth animations. View Binding provides type-safe, null-safe access to XML-defined Views.

Real-world relevance

In a field operations app, a WorkOrderListFragment uses RecyclerView with ListAdapter to display hundreds of work orders synced from the server. DiffUtil computes the minimal diff when orders are updated (status changes, new assignments) and animates only the changed items. Each item uses a ConstraintLayout with chains for the title/status/assignee layout. View Binding eliminates all findViewByIds. A ConcatAdapter adds a header showing active filter chips and a footer with 'Load more' pagination. The entire list updates without a full redraw when a single order's status changes.

Key points

• View hierarchy and inflation — XML layouts are parsed and inflated into View objects at runtime. LayoutInflater.inflate() reads XML and creates the View tree. Deep hierarchies (View inside View inside View...) cause nested measure/layout passes — each extra level multiplies work. Flat hierarchies with ConstraintLayout perform better than deeply nested LinearLayouts.
• ConstraintLayout basics — Every View must have horizontal AND vertical constraints — or it collapses to (0,0). Constraints connect to: parent edges, other Views' edges, guidelines (invisible lines at fixed percent), barriers (dynamic boundary based on multiple views). 0dp width/height means 'match constraint' — fill available constrained space.
• ConstraintLayout chains — A chain is a bidirectional constraint between two or more Views. Chain styles: spread (equal space), spread_inside (space between, none at edges), packed (grouped together). Use chains instead of LinearLayout for groups of horizontally/vertically arranged Views within ConstraintLayout.
• View Binding vs findViewById — View Binding generates a binding class per layout XML — type-safe, null-safe references to all Views with IDs. No more NullPointerException from wrong IDs. No reflection overhead. Enable in build.gradle: viewBinding { enabled = true }. Data Binding extends this further with layout expressions but adds compilation complexity.
• RecyclerView architecture — RecyclerView has three main components: Adapter (provides ViewHolders and binds data), LayoutManager (arranges ViewHolders: linear, grid, staggered), ItemDecoration (adds dividers, spacing). RecyclerView recycles ViewHolder instances — onCreateViewHolder is expensive (inflate XML, create binding), onBindViewHolder is cheap (set data into existing views).
• ListAdapter and DiffUtil — ListAdapter extends Adapter with built-in DiffUtil support. Override DiffUtil.ItemCallback with areItemsTheSame (same entity? compare IDs) and areContentsTheSame (same display data? compare fields). submitList() triggers async diffing on a background thread, then applies minimal animations. Never use notifyDataSetChanged() — it forces full rebind with no animation.
• ViewHolder pattern — ViewHolder caches View references. Without it, every onBindViewHolder would call findViewById repeatedly — expensive because it traverses the view tree. With View Binding in ViewHolder: class OrderViewHolder(private val binding: ItemOrderBinding) : RecyclerView.ViewHolder(binding.root). binding.orderTitle.text = ... is O(1) — no traversal.
• RecyclerView click handling — RecyclerView.Adapter has no built-in click listener. Best pattern: pass a lambda to the Adapter — class OrderAdapter(private val onOrderClick: (Order) -> Unit). In onBindViewHolder: binding.root.setOnClickListener { onOrderClick(order) }. Avoid setting click listeners in onCreateViewHolder (ViewHolder might be rebound to different data).
• ConcatAdapter — Combines multiple Adapters into one RecyclerView. Use for header+list+footer without hacking a single Adapter. Each sub-Adapter manages its own data. Useful for: static header, paginated content list, loading footer. Available in recyclerview:1.2.0+.
• RecyclerView performance — setHasFixedSize(true) — if adapter content changes don't affect RecyclerView size, avoids full requestLayout. setItemViewCacheSize() — extra offscreen views kept before recycling. Use DiffUtil always. Avoid onBindViewHolder triggering layout inflation. Pre-compute item sizes in a background thread if complex.
• ConstraintLayout MotionLayout — MotionLayout extends ConstraintLayout to add animated transitions between two constraint sets. Define start and end ConstraintSets, MotionLayout interpolates. Used for: toolbar collapse on scroll, drag-to-expand cards, animated onboarding. No code needed for most animations — purely XML-driven.
• include and merge tags — reuses layout files — extracts repeated UI into a shared file. eliminates redundant root ViewGroups when including — if the include target is already the right ViewGroup, merge prevents adding an extra layer. Reduces hierarchy depth and improves performance.

Code example

// ListAdapter with DiffUtil — production pattern
class WorkOrderAdapter(
    private val onOrderClick: (WorkOrder) -> Unit,
    private val onStatusChange: (WorkOrder, WorkOrderStatus) -> Unit
) : ListAdapter<WorkOrder, WorkOrderAdapter.WorkOrderViewHolder>(WorkOrderDiffCallback()) {

    // DiffUtil — called on background thread
    class WorkOrderDiffCallback : DiffUtil.ItemCallback<WorkOrder>() {
        override fun areItemsTheSame(old: WorkOrder, new: WorkOrder): Boolean =
            old.id == new.id  // Same entity?

        override fun areContentsTheSame(old: WorkOrder, new: WorkOrder): Boolean =
            old == new  // Same display data? (data class equals checks all fields)
    }

    // ViewHolder with View Binding — inflated ONCE, reused
    class WorkOrderViewHolder(
        private val binding: ItemWorkOrderBinding
    ) : RecyclerView.ViewHolder(binding.root) {

        fun bind(order: WorkOrder, onClick: (WorkOrder) -> Unit, onStatus: (WorkOrder, WorkOrderStatus) -> Unit) {
            binding.orderTitle.text = order.title
            binding.assigneeChip.text = order.assignedTo?.name ?: "Unassigned"
            binding.statusBadge.text = order.status.label
            binding.statusBadge.setChipBackgroundColorResource(order.status.colorRes)
            binding.root.setOnClickListener { onClick(order) }
            binding.statusSpinner.setOnItemSelectedListener { _, _, position, _ ->
                onStatus(order, WorkOrderStatus.entries[position])
            }
        }
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): WorkOrderViewHolder {
        // Inflate ONCE — this is the expensive operation
        val binding = ItemWorkOrderBinding.inflate(
            LayoutInflater.from(parent.context), parent, false
        )
        return WorkOrderViewHolder(binding)
    }

    override fun onBindViewHolder(holder: WorkOrderViewHolder, position: Int) {
        // Bind OFTEN — this must be cheap
        holder.bind(getItem(position), onOrderClick, onStatusChange)
    }
}

// Fragment setup
class WorkOrderListFragment : Fragment(R.layout.fragment_work_order_list) {

    private var _binding: FragmentWorkOrderListBinding? = null
    private val binding get() = _binding!!
    private val viewModel: WorkOrderViewModel by activityViewModels()

    private val adapter = WorkOrderAdapter(
        onOrderClick = { order -> viewModel.selectOrder(order.id) },
        onStatusChange = { order, status -> viewModel.updateStatus(order, status) }
    )

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        _binding = FragmentWorkOrderListBinding.bind(view)

        binding.recyclerView.apply {
            this.adapter = this@WorkOrderListFragment.adapter
            layoutManager = LinearLayoutManager(requireContext())
            setHasFixedSize(true)
            addItemDecoration(DividerItemDecoration(context, DividerItemDecoration.VERTICAL))
        }

        viewLifecycleOwner.lifecycleScope.launch {
            viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.workOrders.collect { orders ->
                    adapter.submitList(orders)  // DiffUtil computes diff async
                }
            }
        }
    }

    override fun onDestroyView() {
        super.onDestroyView()
        binding.recyclerView.adapter = null  // Prevent adapter leak
        _binding = null
    }
}

Line-by-line walkthrough

1. 1. WorkOrderAdapter extends ListAdapter(WorkOrderDiffCallback()) — the DiffCallback is passed to super so ListAdapter handles all diffing internally.
2. 2. areItemsTheSame compares old.id == new.id — this tells DiffUtil 'is this the same work order?' even if its fields changed. areContentsTheSame uses data class equals which auto-compares all fields — 'has anything displayed changed?'
3. 3. WorkOrderViewHolder holds ItemWorkOrderBinding — inflated once in onCreateViewHolder. bind() is called repeatedly on the same ViewHolder instance as it is recycled for different orders.
4. 4. onCreateViewHolder inflates the XML via View Binding — this is the expensive step (XML parsing, view tree construction). RecyclerView calls this only when no cached ViewHolder is available.
5. 5. onBindViewHolder calls holder.bind(getItem(position), ...) — getItem() is provided by ListAdapter and returns the correct item accounting for DiffUtil's async updates.
6. 6. adapter.submitList(orders) in the Fragment triggers DiffUtil comparison on a background thread, then posts AnimatedStateListDrawable updates to the RecyclerView on the main thread.
7. 7. binding.recyclerView.adapter = null in onDestroyView is critical — RecyclerView holds a reference to the Adapter which holds lambdas that may close over Fragment/ViewModel references. Nulling prevents a retention chain.
8. 8. setHasFixedSize(true) is safe here because the RecyclerView fills the screen — submitting a new list doesn't change its dimensions, so Android skips the expensive parent re-measure cycle.

Spot the bug

class StudentAdapter : RecyclerView.Adapter<StudentAdapter.StudentViewHolder>() {

    private val students = mutableListOf<Student>()

    fun updateStudents(newStudents: List<Student>) {
        students.clear()
        students.addAll(newStudents)
        notifyDataSetChanged()  // Bug 1
    }

    inner class StudentViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) {  // Bug 2
        val nameText: TextView = itemView.findViewById(R.id.student_name)
        val gradeText: TextView = itemView.findViewById(R.id.student_grade)

        init {
            // Bug 3
            itemView.setOnClickListener {
                val student = students[adapterPosition]
                onStudentClick(student)
            }
        }
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): StudentViewHolder {
        val view = LayoutInflater.from(parent.context)
            .inflate(R.layout.item_student, parent, false)
        return StudentViewHolder(view)
    }

    override fun onBindViewHolder(holder: StudentViewHolder, position: Int) {
        val student = students[position]
        holder.nameText.text = student.name
        holder.gradeText.text = student.grade
        // Bug 4
        val bitmap = BitmapFactory.decodeResource(
            holder.itemView.resources, student.avatarResId
        )
        holder.avatarImage.setImageBitmap(bitmap)
    }
}

Explain like I'm 5

Fun fact

Hands-on challenge

More resources

• RecyclerView — Android Developers (Android Developers)
• ListAdapter and DiffUtil (Android Developers)
• ConstraintLayout — Android Developers (Android Developers)
• View Binding — Android Developers (Android Developers)
• RecyclerView best practices — Google Developers (Medium / Android Developers)