View Binding

Every screen you build eventually needs to reach into its layout and touch an actual view — set a TextView's text, read an EditText's input, react to a button tap. For years Android developers did this with findViewById(). It works, but it quietly carries two problems that View Binding was built to remove. This lesson walks through both the problem and the fix, using TrailLog's trail list and trail detail screens throughout.

The Problem With findViewById()

Imagine TrailDetailActivity's layout has a TextView for the trail's name, identified by android:id="@+id/trailNameText". The old way to reach it:

val trailNameText = findViewById<TextView>(R.id.trailNameText)
trailNameText.text = trail.name

This looks harmless, but it has two real problems:

On top of that, it's easy to fall into calling findViewById() repeatedly for the same view — once per click listener, once per update — instead of storing the result once. Each call walks the view hierarchy again, which is wasted work for something that never changes for the lifetime of the screen.

Enabling View Binding in Gradle

View Binding is built into the Android Gradle Plugin — you just need to turn it on for the module, in app/build.gradle.kts:

android {
    namespace = "com.codingwithsonu.traillog"
    compileSdk = 34

    defaultConfig {
        applicationId = "com.codingwithsonu.traillog"
        minSdk = 24
        targetSdk = 34
    }

    buildFeatures {
        viewBinding = true
    }
}

That single viewBinding = true flag inside buildFeatures { } is all it takes. After the next Gradle sync, Android Studio starts generating a binding class for every XML layout in the module — no other setup, no extra library dependency to add by hand.

How Android Studio Generates a Binding Class

For a layout file named activity_trail_detail.xml, the build generates a class called ActivityTrailDetailBinding. For a Fragment's layout, fragment_trail_list.xml, you get FragmentTrailListBinding. The naming rule is mechanical: take the file name, convert it to PascalCase, and append Binding.

Inside that generated class is a strongly typed property for every view in the layout that carries an android:id. A view with android:id="@+id/trailNameText" becomes a property named trailNameText, already typed as whatever widget it actually is — no cast needed, and no way to reference an id that doesn't exist, because it simply wouldn't compile.

Using View Binding in an Activity

Here's TrailDetailActivity rewritten with View Binding instead of findViewById():

class TrailDetailActivity : AppCompatActivity() {

    private lateinit var binding: ActivityTrailDetailBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        binding = ActivityTrailDetailBinding.inflate(layoutInflater)
        setContentView(binding.root)

        val trail = loadTrail() // however TrailDetailActivity gets its Trail
        binding.trailNameText.text = trail.name
        binding.trailDistanceText.text = "${trail.distanceKm} km"
        binding.trailNotesText.text = trail.notes
    }
}

Three moving pieces make this work in an Activity:

From there, binding.trailNameText.text = trail.name reads exactly like plain property access, because that's exactly what it is — no lookup, no cast, no possibility of a wrong id.

Using View Binding in a Fragment

A Fragment's view can be destroyed and recreated (for example, when it's placed on Android's back stack) while the Fragment instance itself stays alive longer. If a Fragment kept a permanent, non-nullable reference to its binding, that reference would keep pointing at views that no longer exist after the view is destroyed — a memory leak. The standard fix is a pair of properties: a private, nullable backing property, and a public, non-null one built on top of it.

class TrailListFragment : Fragment() {

    private var _binding: FragmentTrailListBinding? = null
    // only valid between onCreateView() and onDestroyView()
    private val binding get() = _binding!!

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        _binding = FragmentTrailListBinding.inflate(inflater, container, false)
        return binding.root
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        binding.recyclerView.adapter = TrailAdapter(trails)
    }

    override fun onDestroyView() {
        super.onDestroyView()
        _binding = null // release the reference so the views can be garbage collected
    }
}

Why This Specific Pattern Exists

_binding is the nullable field that actually holds (or releases) the binding. binding is a computed property (get()) that force-unwraps _binding with !! — meaning it will only ever be used between onCreateView(), where _binding is assigned, and onDestroyView(), where it's cleared. Clearing it in onDestroyView() is the part that's easy to forget and important not to: without it, the Fragment instance (which can outlive its view) would keep holding a full reference chain down to every view in the layout, preventing them from being garbage collected until the Fragment itself is destroyed — a classic, quiet memory leak in list-heavy screens like TrailLog's trail list.

A Word on Jetpack Compose

If you've heard of Jetpack Compose, it's worth knowing where View Binding fits relative to it: Compose builds UI entirely in Kotlin code, with no XML layout files at all, so there's nothing to generate a binding class from — View Binding simply doesn't apply there. Compose is a separate UI toolkit with its own approach and isn't covered in this track, which focuses on the traditional View system that still powers the large majority of production Android apps today.