Common Mistakes Developers Make with Jetpack Compose

5 min readDec 16, 2024

Jetpack Compose brings a revolutionary approach to Android development with its declarative UI paradigm. However, transitioning from imperative programming can lead to common pitfalls. This blog highlights these mistakes, explains why they occur, and offers practical solutions, complete with examples.

1. Treating Compose as Imperative UI

The Mistake: Developers accustomed to XML-based layouts and imperative programming may attempt to control UI updates manually rather than relying on state-driven updates. This often stems from habits formed in traditional development, where updating UI required explicitly modifying views through code, such as calling findViewById or using binding, and updating properties imperatively.

@Composable
fun Counter() {
    var count = 0 // Incorrect state management

    Button(onClick = { count++ }) { // Won't work as expected
        Text("Count: $count")
    }
}

Why It’s Wrong: Compose relies on state to manage UI changes. Manually updating variables without state will not trigger recomposition, resulting in static or broken UIs. This misunderstanding can lead to frustration, as developers expect changes to reflect immediately without comprehending the declarative nature of Compose.

The Solution: Use remember to create a reactive state:

@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }

    Button(onClick = { count++ }) {
        Text("Count: $count")
    }
}

2. Ignoring State Hoisting

The Mistake: Keeping state within composables rather than lifting it up makes components tightly coupled and hard to reuse.

@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }

    Column {
        Text("Count: $count")
        Button(onClick = { count++ }) {
            Text("Increment")
        }
    }
}

This Counter cannot share its state with other composables.

Why It’s Wrong: State hoisting is essential for reusability and testability. By lifting state, multiple composables can share and modify it. This is particularly beneficial in larger applications where different components need to synchronize their states. For example, a Counter component may need to interact with a Logger or Analytics module, and keeping the state within the Counter would make such integrations cumbersome.

Additionally, lifting state helps in adhering to the single source of truth principle, ensuring all dependent components have a consistent view of the data.

The Solution: Hoist the state to the parent composable:

@Composable
fun CounterScreen() {
    var count by remember { mutableStateOf(0) }
    Counter(count = count, onIncrement = { count++ })
}

@Composable
fun Counter(count: Int, onIncrement: () -> Unit) {
    Column {
        Text("Count: $count")
        Button(onClick = onIncrement) {
            Text("Increment")
        }
    }
}

By adopting this pattern, the state becomes accessible and modifiable by other composables, making the UI more modular and easier to maintain.

3. Recreating State Unnecessarily

The Mistake: State variables are initialized inside a composable without remember, leading to resets during recomposition.

@Composable
fun Counter() {
    var count = 0 // State resets with every recomposition

    Button(onClick = { count++ }) {
        Text("Count: $count")
    }
}

Why It’s Wrong: Compose recomposes the UI frequently, and without proper state handling, the UI will reset to its initial state.

The Solution: Use remember to persist state:

@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }

    Button(onClick = { count++ }) {
        Text("Count: $count")
    }
}

4. Overusing Mutable States

The Mistake: Developers may wrap every piece of data in mutableStateOf, even for data that doesn't change frequently.

@Composable
fun UserProfile() {
    val name = mutableStateOf("John Doe") // Overkill for immutable data

    Text("Name: ${name.value}")
}

Why It’s Wrong: Unnecessary use of mutableStateOf can clutter code and degrade performance.

The Solution: Use val for immutable data:

@Composable
fun UserProfile() {
    val name = "John Doe" // No need for mutable state

    Text("Name: $name")
}

5. Ignoring Performance Optimizations

The Mistake: Failing to optimize list rendering or unnecessarily nesting composables can lead to performance issues.

LazyColumn {
    items(dataList) { item ->
        Text(item.name)
    }
}

This works but may recompose unnecessarily if the list updates.

Why It’s Wrong: Without specifying a key, Compose can’t efficiently reuse views, leading to redundant recompositions.

The Solution: Use a key for efficient rendering:

LazyColumn {
    items(items = dataList, key = { it.id }) { item ->
        Text(item.name)
    }
}

6. Not Leveraging Compose Previews

The Mistake: Developers skip using @Preview, relying solely on deploying the app to test UI changes.

@Composable
fun Greeting(name: String) {
    Text("Hello, $name!")
}

Without a preview, testing requires full app deployment.

Why It’s Wrong: Skipping previews slows down iteration and makes testing tedious. This habit often leads to wasted time during the development process, especially when small visual tweaks are needed. Furthermore, it increases the risk of introducing bugs or inconsistencies, as developers might miss issues that could have been spotted earlier using previews.

The Solution: Add @Preview annotations to visualize UI changes instantly. Previews provide a quick and interactive way to refine your UI without needing to launch the entire application.

@Preview(showBackground = true)
@Composable
fun GreetingPreview() {
    Greeting("Compose")
}

Using previews can dramatically speed up development, allowing developers to iterate on designs, test various layouts, and ensure components behave as expected before integration into the broader application. In larger teams, it also facilitates easier UI reviews and collaboration.

7. Mixing UI and Business Logic

The Mistake: Composables contain business logic instead of focusing solely on rendering UI.

@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }

    Button(onClick = { count++ }) {
        Text("Count: $count")
    }
}

Why It’s Wrong: Mixing logic makes the codebase less modular and harder to maintain.

The Solution: Use ViewModels to manage business logic and pass state to composables:

class CounterViewModel : ViewModel() {
    private val _count = mutableStateOf(0)
    val count: State<Int> get() = _count

    fun increment() {
        _count.value++
    }
}

@Composable
fun CounterScreen(viewModel: CounterViewModel) {
    Counter(count = viewModel.count.value, onIncrement = { viewModel.increment() })
}

Conclusion

Jetpack Compose introduces a modern and efficient way of building UI for Android, but it also requires developers to rethink how they manage state, structure components, and optimize performance. By avoiding these common mistakes, such as treating Compose imperatively, ignoring state hoisting, or mixing business logic with UI, you can fully leverage Compose’s declarative approach to create modular, reusable, and performant applications.

Adopting best practices like proper state management with remember, using previews for faster iteration, and separating UI from business logic ensures a cleaner and more maintainable codebase. As you embrace Compose, remember that its strength lies in its simplicity and reactivity. A thoughtful approach will save time, reduce frustration, and result in better user experiences.

I hope this article has provided valuable insights and assistance for your Android journey. Your support means a lot to me, so if you found this content helpful, please start following me and don’t hesitate to show some love with a hearty round of applause!👏

Your feedback fuels my passion for creating quality content. For any Android queries or just to connect, reach out on LinkedIn and Twitter.

Thanks for reading — looking forward to staying in touch!

Happy Composing!!