Compose and Views Interoperability

Most real Android apps are not purely Compose or purely Views. They are both, and they stay that way for months or years while the team migrates a screen at a time. Google designed Compose for exactly this: you can put Compose inside a View-based screen, put a View inside a Compose screen, and move over gradually without rewriting the whole app.

This lesson covers these items: Compose in Views and Add Compose to a legacy app (Unit 8, Pathway 2 of Android Basics with Compose), and Views in Compose, View Interoperability in Compose, Migrate from the View system and the hands-on migration codelab (Migrating to Jetpack Compose) from Pathway 1 of the Jetpack Compose for Android developers programme. See https://developer.android.com/courses/pathways/android-basics-compose-unit-8-pathway-2 and https://developer.android.com/courses/pathways/jetpack-compose-for-android-developers-1.

By the end you will be able to:

• Add Compose to an existing View-based project (Gradle setup).
• Embed Compose in an XML layout with ComposeView, and in a Fragment correctly with ViewCompositionStrategy.
• Embed a classic View in Compose with AndroidView, and a Fragment with AndroidViewBinding.
• Share state and theming between the two worlds.
• Explain and apply a safe, incremental migration strategy.
• Recognise the common interop bugs: lifecycle, state loss, and theming mismatches.

Big idea: a migration is a series of small, shippable steps, never a big rewrite. At every step the app builds, runs and can be released.

• Views, XML, view binding, Fragments, Navigation component (lesson 42).
• Compose basics, state and recomposition (lessons 15–21 and 37).
• ViewModel and StateFlow (lessons 24–25).
• Material 3 theming (lesson 40).

There are two directions of interop:

Direction A: Compose inside Views             Direction B: Views inside Compose

  Activity / Fragment (XML)                     Activity (setContent { })
   +-- LinearLayout                              +-- Column
        +-- TextView                                  +-- Text (Compose)
        +-- ComposeView  <--- Compose lives here      +-- AndroidView  <--- a View lives here
              Text, Button ...                              MapView / WebView / custom View

Direction A is how most migrations start: leave the Activity and navigation alone, replace one small piece of a screen with Compose, then grow it.

Direction B is how you keep using things that have no Compose version yet or are too costly to rewrite: WebView, MapView, ad banners, video players, a complex custom View.

Under the hood, a ComposeView is just a View (a ViewGroup, in fact) that owns a Composition. A Composition needs a lifecycle, a saved-state registry and a ViewModelStore to work. In an Activity or Fragment these are found automatically from the view tree. That is why correct setup (and the ViewCompositionStrategy) matters.

Start with the ClassRegister project from lesson 42 (or any View-based project). Its app/build.gradle.kts needs four things:

1. The Kotlin Compose compiler plugin (since Kotlin 2.0).
2. buildFeatures { compose = true }.
3. The Compose BOM and the libraries you use.
4. A Compose-ready theme (optional but recommended).

In gradle/libs.versions.toml, add (look up the current stable versions: the Compose BOM and the Kotlin version should match what Android Studio's New Project creates):

[versions]
composeBom = "<latest stable>"
kotlin = "<your Kotlin version>"
[libraries]
androidx-compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "composeBom" }
androidx-compose-material3 = { group = "androidx.compose.material3", name = "material3" }
androidx-compose-ui = { group = "androidx.compose.ui", name = "ui" }
androidx-compose-ui-tooling = { group = "androidx.compose.ui", name = "ui-tooling" }
androidx-compose-ui-tooling-preview = { group = "androidx.compose.ui", name = "ui-tooling-preview" }
androidx-compose-ui-viewbinding = { group = "androidx.compose.ui", name = "ui-viewbinding" }
[plugins]
kotlin-compose = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }

Add the plugin to the root build.gradle.kts (alias(libs.plugins.kotlin.compose) apply false) and to the app module:

plugins {
 alias(libs.plugins.android.application)
 alias(libs.plugins.kotlin.android)
 alias(libs.plugins.kotlin.compose)
}
android {
 // ...
 buildFeatures {
 viewBinding = true
 compose = true
 }
}
dependencies {
 val composeBom = platform(libs.androidx.compose.bom)
 implementation(composeBom)
 implementation(libs.androidx.compose.material3)
 implementation(libs.androidx.compose.ui)
 implementation(libs.androidx.compose.ui.tooling.preview)
 debugImplementation(libs.androidx.compose.ui.tooling)
 implementation(libs.androidx.compose.ui.viewbinding) // for AndroidViewBinding later
 // ...existing dependencies
}

Sync. If Gradle complains about the Kotlin version, remember: the Compose compiler is now shipped with Kotlin and its plugin version must equal your Kotlin version. This is a common first error when adding Compose to an old project that still uses the pre-2.0 composeOptions { kotlinCompilerExtensionVersion } setup; remove that block when switching to the plugin.

Make sure your project's minSdk meets the Compose requirement shown in the official documentation (Compose has a minimum API level; check the current figure in the setup page).

Add a ComposeView to fragment_detail.xml (from the lesson 42 solution). It is an ordinary View tag:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:orientation="vertical"
 android:padding="24dp">
 <TextView
 android:id="@+id/detailName"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:textSize="28sp"
 android:textStyle="bold" />
 <androidx.compose.ui.platform.ComposeView
 android:id="@+id/statusCompose"
 android:layout_width="match_parent"
 android:layout_height="wrap_content" />
</LinearLayout>

Then in the fragment, give it content. A ComposeView has a setContent { } function, exactly like an Activity:

package com.example.classregister
import android.os.Bundle
import android.view.LayoutInflater
import android.view.View
import android.view.ViewGroup
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.padding
import androidx.compose.material3.Card
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.collectAsState
import androidx.compose.ui.Modifier
import androidx.compose.ui.platform.ViewCompositionStrategy
import androidx.compose.ui.unit.dp
import androidx.fragment.app.Fragment
import androidx.fragment.app.activityViewModels
import androidx.lifecycle.compose.collectAsStateWithLifecycle
import com.example.classregister.databinding.FragmentDetailBinding
class DetailFragment : Fragment() {
 private var _binding: FragmentDetailBinding? = null
 private val binding get() = _binding!!
 private val viewModel: StudentViewModel by activityViewModels()
 override fun onCreateView(
 inflater: LayoutInflater,
 container: ViewGroup?,
 savedInstanceState: Bundle?
 ): View {
 _binding = FragmentDetailBinding.inflate(inflater, container, false)
 return binding.root
 }
 override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
 super.onViewCreated(view, savedInstanceState)
 val id = requireArguments().getInt("studentId")
 binding.statusCompose.apply {
 setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
 setContent {
 MaterialTheme {
 val students by viewModel.students.collectAsStateWithLifecycle()
 val student = students.firstOrNull { it.id == id }
 if (student != null) StatusCard(student)
 }
 }
 }
 }
 override fun onDestroyView() {
 super.onDestroyView()
 _binding = null
 }
}
@Composable
private fun StatusCard(student: Student) {
 Card(Modifier.padding(top = 16.dp)) {
 Column(Modifier.padding(16.dp)) {
 Text(student.name, style = MaterialTheme.typography.titleLarge)
 Text(if (student.present) "Present today" else "Absent today")
 }
 }
}

(If you also have the old code that sets detailStatus text, delete it; we replaced that view with Compose.)

The new import you have not seen is androidx.lifecycle.compose.collectAsStateWithLifecycle, which needs the androidx.lifecycle:lifecycle-runtime-compose artifact (lesson 25).

ViewCompositionStrategy: when does the Composition die?

A Composition must be disposed at the right time to avoid leaks, but the right time depends on where the ComposeView lives. This is the single most important rule of interop. ViewCompositionStrategy chooses it:

For a ComposeView inside a Fragment, choose DisposeOnViewTreeLifecycleDestroyed. Fragments detach their views when you navigate away but keep the fragment on the back stack, and the default strategy would drop the Composition and its remembered state. For items in a RecyclerView, the default pool-aware strategy is intended.

When the fragment itself is just Compose

If the whole fragment is Compose, return a ComposeView directly from onCreateView:

import android.os.Bundle
import android.view.LayoutInflater
import android.view.View
import android.view.ViewGroup
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Text
import androidx.compose.ui.platform.ComposeView
import androidx.compose.ui.platform.ViewCompositionStrategy
import androidx.fragment.app.Fragment
class AboutFragment : Fragment() {
 override fun onCreateView(
 inflater: LayoutInflater,
 container: ViewGroup?,
 savedInstanceState: Bundle?
 ): View = ComposeView(requireContext()).apply {
 setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
 setContent {
 MaterialTheme { Text("About Class Register") }
 }
 }
}

This is the standard shape of a Compose screen inside a Navigation-component graph, and it is the best first migration step: keep fragments and navigation, but write each screen's content in Compose.

Compose inside a RecyclerView item

You can migrate one list row at a time. In the view holder, wrap a ComposeView:

import androidx.compose.material3.Text
import androidx.compose.ui.platform.ComposeView
import androidx.compose.ui.platform.ViewCompositionStrategy
import androidx.recyclerview.widget.RecyclerView
class ComposeStudentHolder(private val composeView: ComposeView) : RecyclerView.ViewHolder(composeView) {
 init {
 composeView.setViewCompositionStrategy(
 ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed
 )
 }
 fun bind(student: Student) {
 composeView.setContent {
 Text(student.name)
 }
 }
}

Keep Compose rows light: a RecyclerView creates many holders, and each is its own Composition. This works, but for a whole list it is usually better to migrate the entire list to LazyColumn than to keep the adapter.

Now the reverse direction. AndroidView lets you place any View into a composable. It takes three main parameters:

Example: show a rating bar from the View system (RatingBar, which has no direct Material 3 Compose counterpart in the base library):

import android.widget.RatingBar
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.viewinterop.AndroidView
@Composable
fun StarRating(
 rating: Float,
 onRatingChange: (Float) -> Unit,
 modifier: Modifier = Modifier
) {
 AndroidView(
 modifier = modifier,
 factory = { context ->
 RatingBar(context).apply {
 numStars = 5
 stepSize = 0.5f
 setOnRatingBarChangeListener { _, value, fromUser ->
 if (fromUser) onRatingChange(value)
 }
 }
 },
 update = { bar ->
 if (bar.rating != rating) bar.rating = rating
 }
 )
}

How state flows:

Compose state (rating) --> update { bar.rating = rating }   (state flows DOWN into the View)
View event (user taps) --> listener --> onRatingChange(...) (events flow UP to Compose state)

That is the same state down, events up pattern as everywhere else. The if (bar.rating != rating) check avoids setting a value that is already there, which would trigger the listener and cause a loop.

A common trap: the lambda in factory captures onRatingChange the first time only, because factory runs once. If your callback changes later (a new lambda each recomposition), the View keeps calling the old one. The safe fix is rememberUpdatedState or setting the listener again in update:

update = { bar ->
 bar.setOnRatingBarChangeListener { _, value, fromUser ->
 if (fromUser) onRatingChange(value)
 }
 if (bar.rating != rating) bar.rating = rating
}

A WebView in Compose

WebView is the classic reason to use AndroidView:

import android.webkit.WebView
import android.webkit.WebViewClient
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.viewinterop.AndroidView
@Composable
fun SimpleWebPage(url: String, modifier: Modifier = Modifier) {
 AndroidView(
 modifier = modifier,
 factory = { context ->
 WebView(context).apply {
 webViewClient = WebViewClient()
 settings.javaScriptEnabled = false // enable only if you trust and need it
 }
 },
 update = { webView ->
 if (webView.url != url) webView.loadUrl(url)
 }
 )
}

Remember the INTERNET permission in the manifest (lesson 29), and enable JavaScript only for content you trust. For production-quality web content, also look at the androidx.webkit library for safe-browsing and dark-mode support.

AndroidView and lifecycle-heavy Views

Views such as MapView and PlayerView need lifecycle calls (onResume, onPause, onDestroy). In Compose you forward them with a LifecycleEventObserver inside a DisposableEffect (lesson 54), or use the library's own Compose wrapper if it has one (Maps and media libraries now ship Compose APIs; prefer those).

Fragments and XML layouts inside Compose

If you have a whole XML layout or a fragment container that you do not want to rewrite yet, use AndroidViewBinding (needs ui-viewbinding and view binding enabled):

import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.viewinterop.AndroidViewBinding
import com.example.classregister.databinding.LegacyHeaderBinding
@Composable
fun LegacyHeader(title: String, modifier: Modifier = Modifier) {
 AndroidViewBinding(LegacyHeaderBinding::inflate, modifier) {
 headerTitle.text = title // 'this' is the generated binding
 }
}

The trailing lambda runs on every recomposition with the binding as its receiver, so it is where you bind data. A FragmentContainerView inside such a layout lets you host an old fragment inside a Compose screen.

State

The cleanest bridge is a ViewModel exposing a StateFlow. A Fragment's View code can collect it (lesson 42) and a Compose screen can collectAsStateWithLifecycle(). Both see the same data, so you can move parts of a screen to Compose without changing the data layer at all. Other bridges: LiveData.observeAsState() (needs the androidx.compose.runtime:runtime-livedata artifact) if your old code uses LiveData, and Flow.collectAsState().

Theme

Compose reads its colours and type from MaterialTheme; Views read from the XML theme (Theme.Material3.* in themes.xml). If they differ, your screens look like two different apps. Two strategies:

1. Re-implement the XML theme in Compose by hand (copy the same colours into Color.kt).
2. Use the Material Theme Adapter library (com.google.android.material:compose-theme-adapter, or the M3 variant) that reads your XML theme and creates a Compose MaterialTheme automatically. It is useful during a migration, but treat it as a bridge rather than a long-term solution: check the library's page for its current status, and plan to move to a native Compose theme.

If a Compose screen sits in an Activity with a Material 3 XML theme, also make sure <item name="android:windowBackground"> and status bar colours are consistent with what Compose draws.

Sizes, insets and dark mode

Mixed screens commonly have two bugs: double insets (the XML layout adds padding for the status bar and Compose adds it again) and dark mode mismatch. Decide once which layer owns window insets (modern apps call enableEdgeToEdge() in the Activity and handle insets in the layout system or in Compose, not in both).

The official Migrate from the View system material gives a practical order of work. Here is our own version, in six steps.

STEP 1  Add Compose to the project (Gradle, theme). Ship nothing yet.
STEP 2  Build ONE new, small screen in Compose. Host it in a Fragment (ComposeView).
STEP 3  Migrate "leaf" UI first: buttons, cards, list rows, dialogs, empty states.
STEP 4  Migrate whole screens (one fragment at a time), moving state into ViewModels.
STEP 5  Replace the navigation (Navigation component -> Navigation Compose) once most
        screens are Compose.
STEP 6  Remove XML, view binding, the Adapter classes and the theme bridge.

Guidelines that save pain:

• Start with a screen that has little navigation or state complexity (an About page, a settings list, a detail screen).
• Migrate bottom-up (leaf to root) or top-down by whole screens, but not both at once.
• Move logic to the ViewModel first. A screen whose state already lives in a ViewModel migrates in an afternoon.
• Keep tests green at every step. UI tests with Espresso can still find Views inside a ComposeView; Compose test APIs can find composables inside View screens (lesson 45).
• Do not start by redoing your theme or design system twice. Define Material 3 in Compose from the start.
• Measure. Check start-up time and release-build performance after adding Compose, because Compose adds some library weight (lesson 57).

The hands-on migration codelab

The official Migrating to Jetpack Compose codelab migrates a real app (Sunflower) step by step: a detail screen, the plant name, the description with HtmlText, theming and the "add to garden" button. You can follow it with the links below. The skills it asks for are exactly the ones in this lesson: ComposeView in a fragment, AndroidView for HTML text, the theme adapter and state from a ViewModel.

Mistake #1: Old composeOptions with the new compiler plugin. Symptom: Gradle errors about the compiler extension version. Fix: remove composeOptions, apply the org.jetbrains.kotlin.plugin.compose plugin.

Mistake #2: Default ViewCompositionStrategy in a Fragment. Symptom: state lost when you navigate back. Fix: DisposeOnViewTreeLifecycleDestroyed.

Mistake #3: Forgetting MaterialTheme around Compose content in a ComposeView. Symptom: components use the default baseline theme. Fix: wrap content in your theme.

Mistake #4: Putting a long-lived object creation in update. Symptom: leaks and slowness. Fix: create in factory, update in update.

Mistake #5: Stale callbacks in factory. Symptom: clicks call an old lambda. Fix: set listeners in update, or use rememberUpdatedState.

Mistake #6: Double window insets. Symptom: extra gap under the status bar. Fix: let one layer own insets.

Mistake #7: Two themes that drift apart. Symptom: buttons in two styles. Fix: share the same colours (or a bridge during the migration).

Mistake #8: A ComposeView inside a scrolling parent without a size. Symptom: zero height or measure crash for lazy lists. Fix: give the ComposeView a bounded height or avoid nesting lazy lists in View scrollers.

Mistake #9: Big-bang rewrite. Symptom: months with no release. Fix: migrate screen by screen and ship each time.

Mistake #10: Forgetting ui-tooling for previews. Symptom: @Preview does not show. Fix: add debugImplementation for ui-tooling and implementation for ui-tooling-preview.

Question 1. What does ComposeView do?

Question 2. Which ViewCompositionStrategy should a ComposeView in a fragment use, and why?

Question 3. What is the difference between factory and update in AndroidView?

Question 4. Name two ways to share data between View-based and Compose-based parts of one screen.

Question 5. What is a safe order for migrating an existing app?

Go deeper: official resources

• Android Basics with Compose, Unit 8 Pathway 2
• Jetpack Compose for Android developers, Pathway 1
• Migrating to Jetpack Compose codelab
• Jetpack Compose course page