Compose with existing Views (interop) in Android Kotlin - Deep Dive

Overview - Compose with existing Views (interop)

What is it?

Compose with existing Views (interop) means using Jetpack Compose UI together with traditional Android Views in the same screen. It lets you mix new Compose components with old View-based UI elements. This helps you gradually update apps without rewriting everything at once.

Why it matters

Without interop, developers would have to rewrite entire screens or apps to use Compose, which is costly and risky. Interop solves this by allowing Compose and Views to live side-by-side, making app updates smoother and faster. It helps teams adopt modern UI without breaking existing features.

Where it fits

Before this, you should know basic Android Views and Jetpack Compose fundamentals. After learning interop, you can explore advanced Compose navigation, state management, and full Compose app architecture.

Mental Model

Core Idea

Compose with existing Views interop lets you embed Compose UI inside View layouts and embed Views inside Compose UI, enabling smooth coexistence.

Think of it like...

It's like renovating a house room by room: you keep some old furniture (Views) while adding new stylish pieces (Compose) without tearing down the whole house.

┌───────────────┐      ┌───────────────┐
│   Android     │      │   Jetpack     │
│    Views      │◄─────┤   Compose     │
│ (XML, Widgets)│      │ (Kotlin DSL)  │
└──────┬────────┘      └──────┬────────┘
       │ Embed Compose UI          │ Embed Views
       │ inside View layouts       │ inside Compose UI
       ▼                          ▼

Build-Up - 7 Steps

1

Foundation

Understanding Android Views Basics

Concept: Learn what Android Views are and how they build UI using XML layouts and widgets.

Android Views are the traditional way to build UI. You define layouts in XML files and use widgets like TextView, Button, and RecyclerView. These Views are managed by the Android framework and displayed on screen.

Result

You can create screens with buttons, text, and images using XML and Views.

Knowing Views is essential because Compose interop works by connecting Compose UI with these existing Views.

2

Foundation

Basics of Jetpack Compose UI

Concept: Learn how Compose builds UI with Kotlin code using composable functions.

Jetpack Compose lets you write UI in Kotlin with functions annotated @Composable. Instead of XML, you describe UI elements directly in code. Compose handles UI updates automatically when data changes.

Result

You can create UI components like buttons and text purely in Kotlin code.

Understanding Compose basics is key to knowing how to embed Compose inside Views or vice versa.

3

Intermediate

Embedding Compose in Traditional Views

🤔Before reading on: do you think Compose UI can be added inside an XML layout directly or does it need a special container? Commit to your answer.

Concept: Learn how to add Compose UI inside an existing View layout using ComposeView.

Android provides ComposeView, a special View that can host Compose UI. You add ComposeView in your XML layout or create it in code, then set its content with Compose functions. This lets Compose UI appear inside traditional View hierarchies.

Result

Compose UI components render inside your existing View-based screen seamlessly.

Knowing ComposeView bridges the gap between Views and Compose, enabling gradual migration.

4

Intermediate

Embedding Views inside Compose UI

🤔Before reading on: do you think Compose can directly use old Views, or do you need a wrapper? Commit to your answer.

Concept: Learn how to embed traditional Views inside Compose using AndroidView composable.

Compose offers AndroidView, a composable that lets you add any Android View inside Compose UI. You provide a factory function that creates the View, and Compose manages its lifecycle. This allows reuse of existing View widgets inside Compose screens.

Result

Old Views like MapView or WebView can appear inside Compose UI without rewriting.

Understanding AndroidView lets you combine the best of both worlds and reuse legacy UI components.

5

Intermediate

Handling State and Events Across Boundaries

🤔Before reading on: do you think Compose and Views share state automatically, or do you need to sync manually? Commit to your answer.

Concept: Learn how to manage UI state and events when Compose and Views interact.

Compose and Views have separate lifecycles and state systems. You must manually sync state changes and event listeners between them. For example, update Compose state when a View button is clicked, or update View properties from Compose state.

Result

UI behaves consistently even when mixing Compose and Views.

Knowing state syncing prevents bugs and ensures smooth user experience across interop boundaries.

6

Advanced

Performance Considerations in Interop

🤔Before reading on: do you think mixing Compose and Views always improves performance? Commit to your answer.

Concept: Understand how interop affects rendering performance and how to optimize it.

Interop adds overhead because Compose and Views use different rendering pipelines. Frequent recompositions or View invalidations can cause jank. Use ComposeView and AndroidView carefully, avoid nesting too deeply, and minimize state changes crossing boundaries.

Result

Smooth UI performance even when mixing Compose and Views.

Knowing interop costs helps you design UI that balances modernization and responsiveness.

7

Expert

Advanced Lifecycle and Resource Management

🤔Before reading on: do you think ComposeView and AndroidView manage lifecycles automatically, or do you need to handle cleanup? Commit to your answer.

Concept: Learn how Compose and Views manage lifecycles and resources during interop and how to avoid leaks.

ComposeView and AndroidView integrate with Android lifecycles but some Views require manual cleanup (e.g., MapView). You must override lifecycle callbacks or use DisposableEffect in Compose to release resources properly. Mismanagement can cause memory leaks or crashes.

Result

Stable apps with no resource leaks when mixing Compose and Views.

Understanding lifecycle integration is critical for production-ready interop implementations.

Under the Hood

ComposeView is a subclass of Android View that hosts a Compose UI tree inside the traditional View hierarchy. It creates a Compose runtime environment and renders Compose UI onto a Canvas managed by the View system. AndroidView is a Compose composable that creates and manages a traditional View instance inside the Compose UI tree, embedding it as a native View. Both use bridges to translate events, drawing, and lifecycle between the two UI systems.

Why designed this way?

Jetpack Compose was designed to be interoperable with existing Views to ease migration. Rewriting entire apps at once is impractical, so interop allows gradual adoption. ComposeView and AndroidView provide minimal, well-defined bridges that keep both UI systems independent but connected, preserving performance and lifecycle correctness.

┌───────────────┐       ┌───────────────┐
│ Android Views │       │ Jetpack Compose│
│  (XML, etc.) │       │  (Kotlin DSL)  │
└──────┬────────┘       └──────┬────────┘
       │ ComposeView embeds Compose UI │
       │──────────────────────────────▶│
       │                              │
       │ AndroidView embeds Views ◀────│
       │                              │
       ▼                              ▼
  Android View Hierarchy        Compose UI Tree

Myth Busters - 4 Common Misconceptions

Quick: Can you directly place Compose UI elements inside XML layouts without any special container? Commit to yes or no.

Common Belief: You can just write Compose UI code inside XML layouts like normal Views.

Reality: Compose UI cannot be placed directly in XML; you must use ComposeView as a container to host Compose inside Views.

Why it matters: Trying to put Compose code directly in XML causes build errors and confusion, blocking interop progress.

Quick: Does Compose automatically sync state with embedded Views? Commit to yes or no.

Common Belief: Compose and Views share state automatically when mixed.

Reality: State must be manually synchronized between Compose and Views; they have separate lifecycles and state management.

Why it matters: Assuming automatic sync leads to UI bugs and inconsistent behavior.

Quick: Is interop always free in terms of performance? Commit to yes or no.

Common Belief: Mixing Compose and Views has no performance cost.

Reality: Interop adds overhead due to bridging two rendering systems, which can cause jank if misused.

Why it matters: Ignoring performance costs can degrade user experience in production apps.

Quick: Do ComposeView and AndroidView handle all resource cleanup automatically? Commit to yes or no.

Common Belief: Interop components manage all lifecycle and resource cleanup without developer effort.

Reality: Some Views require manual cleanup when used inside Compose; developers must handle lifecycle events properly.

Why it matters: Neglecting cleanup causes memory leaks and app crashes.

Expert Zone

1

ComposeView creates a separate Compose runtime instance per view, which can affect performance if overused.

2

AndroidView can host complex Views like MapView or WebView, but requires careful lifecycle management to avoid leaks.

3

Interop boundaries can cause subtle bugs in event propagation and focus handling that require deep understanding to debug.

When NOT to use

Avoid interop when building new screens that can be fully implemented in Compose for better performance and simpler code. Use interop mainly for gradual migration or when reusing complex legacy Views that lack Compose equivalents.

Production Patterns

Common patterns include wrapping legacy custom Views inside AndroidView for reuse, embedding ComposeView in XML layouts for new UI parts, and syncing state via ViewModels or shared state holders to keep UI consistent.

Connections

Bridging Patterns in Software Engineering

Interop acts as a bridge pattern connecting two incompatible UI systems.

Understanding interop as a bridge pattern helps grasp why minimal adapters like ComposeView and AndroidView are used instead of rewriting everything.

Incremental Software Migration

Interop enables incremental migration from old to new UI frameworks.

Knowing incremental migration strategies clarifies why interop is designed for coexistence rather than replacement.

Human-Computer Interaction (HCI) Consistency

Interop requires careful state and event syncing to maintain consistent user experience.

Understanding HCI principles helps appreciate why syncing state and events across UI boundaries is critical.

Common Pitfalls

#1 Trying to place Compose UI code directly inside XML layouts without ComposeView.

Wrong approach:

Correct approach:

Root cause:

Misunderstanding that Compose UI is Kotlin code, not XML, and requires a special container View.

#2 Assuming Compose and Views share state automatically and not syncing manually.

Wrong approach:

val count = mutableStateOf(0)
button.setOnClickListener { count.value++ }
Text(text = "Count: $count") // No manual sync

Correct approach:

val count = mutableStateOf(0)
button.setOnClickListener { count.value++ }
Text(text = "Count: ${count.value}") // Sync state manually

Root cause:

Not realizing Compose and Views have separate state systems requiring explicit synchronization.

#3 Embedding many ComposeView or AndroidView instances deeply nested causing performance issues.

Wrong approach:

Nested ComposeView inside AndroidView inside ComposeView repeatedly in UI tree.

Correct approach:

Minimize interop boundaries by grouping Compose UI or Views together before embedding.

Root cause:

Ignoring overhead of crossing UI system boundaries frequently.

Key Takeaways

Compose with existing Views interop allows mixing new Compose UI with traditional Android Views in the same screen.

ComposeView hosts Compose UI inside View hierarchies; AndroidView embeds Views inside Compose UI.

State and event synchronization between Compose and Views must be handled manually to keep UI consistent.

Interop adds some performance overhead and requires careful lifecycle and resource management.

Interop enables gradual migration to Compose, avoiding costly full rewrites and preserving legacy UI.

Practice

1. What is the main purpose of using AndroidView in Jetpack Compose?

easy

A. To create animations in Compose

B. To convert Compose UI elements into XML layouts

C. To replace all Views with Compose components automatically

D. To embed traditional Android Views inside a Compose UI

Solution

1. Step 1: Understand AndroidView role

   AndroidView allows embedding existing Android Views inside Compose UI, enabling reuse of legacy UI parts.

2. Step 2: Compare options

   Creating animations, converting Compose UI elements into XML layouts, and automatically replacing all Views with Compose components do not describe embedding Views inside Compose. Only embedding traditional Android Views inside a Compose UI correctly states the purpose.

3. Final Answer:

   To embed traditional Android Views inside a Compose UI -> Option D

4. Quick Check:

   AndroidView = Embed Views in Compose [OK]

Hint: AndroidView puts Views inside Compose UI [OK]

Common Mistakes:

• Confusing AndroidView with ComposeView
• Thinking AndroidView converts Compose to XML
• Assuming AndroidView replaces Views automatically

2. Which of the following is the correct way to add a Compose UI inside an existing Android View hierarchy?

easy

A. Use AndroidView inside the View XML layout

B. Use ComposeView inside the View hierarchy

C. Replace the View with a Compose function directly

D. Use setContentView with Compose functions

Solution

1. Step 1: Identify ComposeView usage

   ComposeView is a View that hosts Compose UI inside a traditional View hierarchy.

2. Step 2: Eliminate wrong options

   Use AndroidView inside the View XML layout is wrong because AndroidView is for Compose to View embedding, not View XML. Replace the View with a Compose function directly is invalid as Views cannot be replaced directly by Compose functions. Use setContentView with Compose functions is for setting Compose as the whole content, not embedding.

3. Final Answer:

   Use ComposeView inside the View hierarchy -> Option B

4. Quick Check:

   ComposeView = Compose inside Views [OK]

Hint: ComposeView hosts Compose inside Views [OK]

Common Mistakes:

• Using AndroidView to embed Compose in Views
• Trying to replace Views with Compose functions directly
• Confusing setContentView with embedding Compose

3. What will be displayed when the following Compose code runs?

AndroidView(factory = { context ->
    Button(context).apply {
        text = "Click Me"
    }
})

medium

A. An empty space because Button is not a Compose component

B. A Compose Button with text "Click Me"

C. A traditional Android Button with text "Click Me" inside Compose

D. A runtime error because Button cannot be used inside AndroidView

Solution

1. Step 1: Analyze AndroidView factory

   The factory creates a traditional Android Button with text "Click Me" inside Compose UI.

2. Step 2: Understand output

   AndroidView embeds the View, so the Button is shown as a View inside Compose, not a Compose Button.

3. Final Answer:

   A traditional Android Button with text "Click Me" inside Compose -> Option C

4. Quick Check:

   AndroidView shows Views inside Compose [OK]

Hint: AndroidView shows Views, not Compose components [OK]

Common Mistakes:

• Thinking AndroidView creates Compose components
• Expecting runtime error for Button usage
• Confusing Android Button with Compose Button

4. Identify the error in this Compose code embedding a View:

AndroidView(factory = { context ->
    TextView(context).apply {
        setText("Hello")
    }
}) {
    text = "World"
}

medium

A. Cannot set text inside the trailing lambda; it should be inside factory

B. TextView does not exist in Android Views

C. Missing import for AndroidView

D. Factory lambda must return null

Solution

1. Step 1: Check AndroidView usage

   The trailing lambda is for updating the View, but text is not a Compose property; it should be set on the View inside the factory or update block.

2. Step 2: Identify correct usage

   Setting text outside the factory like this causes error because text is not recognized in that scope.

3. Final Answer:

   Cannot set text inside the trailing lambda; it should be inside factory -> Option A

4. Quick Check:

   Set View properties inside factory or update lambda [OK]

Hint: Set View properties inside factory or update lambda [OK]

Common Mistakes:

• Trying to set View properties directly in trailing lambda
• Assuming trailing lambda is Compose scope
• Ignoring factory return value requirements

5. You want to gradually migrate an app from Views to Compose. Which approach correctly mixes Compose and Views for a smooth transition?

hard

A. Use ComposeView to add Compose UI inside existing View layouts and AndroidView to add Views inside Compose screens

B. Rewrite all Views to Compose before running the app

C. Use only AndroidView everywhere to avoid Compose

D. Replace setContentView with Compose functions and remove all Views immediately

Solution

1. Step 1: Understand gradual migration

   Gradual migration means mixing Compose and Views without rewriting everything at once.

2. Step 2: Identify correct interop usage

   ComposeView embeds Compose inside Views; AndroidView embeds Views inside Compose. Using both allows smooth transition.

3. Step 3: Eliminate wrong options

   Rewriting all Views to Compose before running the app, using only AndroidView everywhere to avoid Compose, and replacing setContentView with Compose functions and removing all Views immediately are extreme or incorrect approaches that do not support gradual migration.

4. Final Answer:

   Use ComposeView to add Compose UI inside existing View layouts and AndroidView to add Views inside Compose screens -> Option A

5. Quick Check:

   ComposeView + AndroidView = smooth migration [OK]

Hint: Use ComposeView and AndroidView together for migration [OK]

Common Mistakes:

• Trying to rewrite entire app at once
• Using only AndroidView or only ComposeView
• Removing Views before Compose is ready