Forem: Abizer

Compose Beginners 2: The Lego Bricks of Android UI

Abizer — Mon, 03 Nov 2025 21:25:16 +0000

In Blog 1 you discovered why Jetpack Compose transformed Android UI development, moving from mutation-heavy XML to a state-driven, declarative paradigm. Now in Blog 2, we’ll step into the how: what exactly is a @Composable, how to think of it as building Lego bricks for your UI, and how to start building your own interactive UI piece (no XML involved).

1. Revisiting the Paradigm Shift

In the first blog you explored how Compose makes UI a function of state rather than a set of mutable views.
Let’s carry that mindset forward:

Instead of “how do I update the view”, we ask “what should the UI look like given this state?”

Instead of XML inflation and findViewById(), we get declarative functions.

Instead of manually tracking UI changes, Compose’s runtime handles recomposition for us.

In short: we’ve already embraced the why. Now we’ll embrace the what and how of the building blocks.

2. Composables = The Lego Bricks

Imagine you’re building a model with Lego bricks. Each brick is simple; you just snap them together. Similarly, a @Composable function is a building-block for your UI.

@Composable
fun Greeting() {
    Text(text = "Hello!")
}

Pretty basic but imagine combining many such composables (bricks) to build your screen. That’s the Compose way.

Why this analogy helps

Reusable: Just like bricks can be used in different models, composables can be reused.
Composable: You stack them or nest them (Column, Row, Box) to build screens.
State-driven: When the underlying state changes, only the bricks depending on it are “re-snapped” (recomposed), not everything collapses.

3. What Makes a Function “Composable”

Let’s define it clearly:

A function annotated with @Composable.
Takes UI inputs (parameters) and draws UI.
Doesn’t return a view — instead it describes part of the UI tree.
Can call other composables.
Works hand-in-hand with Compose runtime for efficient recomposition.

@Composable
fun MyButton(onClick: () -> Unit) {
    Button(onClick = onClick) {
        Text("Tap Me")
    }
}

This is your brick: self-contained, parameterised, reusable.

✅ Fact-Check Note

As of Compose BOM 2025.09.00 (and Kotlin 2.0+), the Compose compiler transforms composables and the runtime handles composition and recomposition.
Always refer to the official docs.

4. Build Your First Interactive Brick (A Counter)

Let’s put all this into action. You don’t need a demo video; you’ll implement and preview with Android Studio’s Preview.

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

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(24.dp),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Text(
            text = "Count: $count",
            style = MaterialTheme.typography.headlineMedium
        )
        Spacer(modifier = Modifier.height(16.dp))
        Button(onClick = { count++ }) {
            Text("Add One")
        }
    }
}

Here’s what you’ll notice:

count is state.

When the button is clicked, state changes → Compose recomposes the part of UI displaying the count.

You didn’t deal with findViewById, Adapter.notifyDataSetChanged(), or manual UI updates.

A small twist to add delight

You may swap the static text with a changing emoji:

val emoji = listOf("🌱", "🌿", "🌳", "🌲")
Text("${emoji[count % emoji.size]}  Count: $count")

See how the UI reflects the state instantly? You’re building with bricks, not manipulating glue.

5. Why This Building Block Matters

Connecting back to Blog 1: you already understand that Compose changed how we think about UI. Now with composables you see how we build UI under that new thinking.

Predictability: UI = f(state). Your bricks visualize exactly that.

Reusability & Modularity: Each composable is a brick you can reuse across screens, which is much easier than large XML layouts with tangled dependencies.

Performance: Since only affected bricks recompute, you get efficient UI updates without manual optimisation.

🧠 Reader Takeaway

You now know what composables are, why they matter, and how to start building UI with them. In the first post you grasped why Compose changed Android. In this post, you’ve begun to grasp how, turning that paradigm into your first bricks.

Compose Beginner 1: Why Jetpack Compose Changed Android Forever

Abizer — Mon, 27 Oct 2025 10:26:37 +0000

From XML mutations to declarative magic. How Jetpack Compose reshaped how we think about Android UI.

Intro

Most of us build with Jetpack Compose today, but few of us pause to ask why it changed everything.

In this post, I’ll share how my own Android journey (from Java + XML projects to modern Compose apps) helped me see what truly makes declarative UI different, and why it quietly reshaped how we design, debug, and think about Android.

👨‍💻 My Journey: From XML Mutations to Compose Mindset

When I started Android development back in October 2021, I started with the roots, my world was all XML and Java.
My first apps LearnHindi and ShortNews were classic View-based projects: findViewById(), adapters, and endless setText() calls.

It was exciting, but also fragile.

Every UI update felt like diffusing a bomb. You change one thing, break three others.

Then I switched to Kotlin, and eventually Jetpack Compose and suddenly, it felt like I was building with Android, not fighting it.

Compose wasn’t just new syntax. It was a new way of thinking.

💡 Compose Didn’t Just Replace XML, it Replaced How We Think About UI

Compose made our UIs faster to build, but its real gift was predictability.

For the first time, the UI became a pure reflection of state, not a pile of mutable views.

“UI is a function of state.”

That’s the line that changed everything.

No more juggling references or wondering if the screen updated correctly.

Now the question was simple: What should this screen look like for the current state?

🧠 Declarative vs Imperative: The Core Idea You Already Use (But Might Not Have Named)

Concept	Imperative (Old View System)	Declarative (Compose)
UI model	Mutable tree of Views	Pure function returning UI
State flow	Push data manually	UI reacts automatically
Ownership	You own updates	Compose owns invalidations
Mental model	“When should I update?”	“What should UI look like now?”

You already write this daily:

@Composable
fun ProfileCard(user: User) {
    Text(text = user.name)
}

You don’t “set” anything, you describe it.
The function’s output is your UI; Compose handles when and how it changes.

⚙️ Why Declarative UIs Scale Better

In XML days:

textView.text = "Online"
progressBar.visibility = View.GONE

You were mutating an object graph while keeping mental tabs on every widget.

In Compose:

if (user.isOnline) Text("Online")
else CircularProgressIndicator()

You simply describe what the UI should be, and Compose ensures the screen stays true to state.
That’s why scaling from simple screens to complex, multi-source UIs is finally sane.

🔬 Under the Hood (2025 Edition)

By 2025, Compose’s runtime has matured into a highly optimized diff engine.
The compiler tracks which values change and triggers recomposition only where needed.

You can see it in:

@Stable / @Immutable annotations guiding recomposition
The new Modifier.Node system improving performance
Recomposition tracing built into Layout Inspector (AGP 8.12+)

No hacks, no boilerplate, just a solid, state-driven UI pipeline.

🧩 The Real Lesson for Compose Developers

If you’re already using Compose, your next level isn’t learning more APIs, it’s learning to think declaratively across your architecture.

That means:

Let state drive everything and no manual “UI updates.”
Keep composables pure: inputs in, visuals out.
Hoist state properly so logic and UI stay predictable.

Once you adopt that mindset you'll see that testing, previews, and animations stop being chores, they just work.

Bad Nesting in Kotlin Coroutines: The Bug That's not a Bug (Until it is)

Abizer — Wed, 30 Jul 2025 08:16:51 +0000

⚠️ IMPORTANT UPDATE:
This article describes behavior from Kotlin coroutines versions prior to 0.27.0 (September 2018).
As pointed out by readers, withContext was changed in version 0.27.0 to "await for all launched tasks,"
effectively fixing the "bad nesting" issue described here.

For historical context and understanding older codebases, the information below remains accurate
for pre-0.27.0 versions. For modern development, this anti-pattern is no longer problematic

thanks to the structured concurrency improvements.

What is “Bad Nesting”?

We all love Kotlin coroutines because they’re clean, powerful, and great for writing async code that almost feels synchronous. But sometimes, coroutines betray us in the most subtle ways.

One such betrayal: bad nesting.

It happens when you put a coroutine builder like launch or async inside a withContext block, expecting it to behave like structured concurrency.

Spoiler alert: it doesn’t.

The Problem in a Nutshell

Bad nesting breaks structured concurrency and leads to:

Orphaned coroutines (they outlive the parent)
Logs that lie to you (“done” isn’t really done)
Concurrency bugs that make you question your sanity

Let’s See It in Action

import kotlinx.coroutines.*

fun main() = runBlocking {
    println("Before withContext")

    withContext(Dispatchers.IO) {
        launch {
            delay(1000)
            println("Inside launch")
        }
        println("withContext block done")
    }

    println("After withContext")
}

Output:

Before withContext  
withContext block done  
After withContext  
Inside launch

Wait... the launch runs after the outer scope thinks everything’s done?
Yes. And here’s why.

What's Really Happening?

Let’s break it down:

runBlocking starts your main coroutine.
withContext(IO) suspends and shifts work to an IO thread.
Inside that block, you call launch. This creates a new coroutine, not tracked by withContext.
withContext runs the block, hits the last line (println) and… finishes.
The program resumes, even though launch is still running.

That launch is now a zombie coroutine, alive and unsupervised.
Remember: Job of withContext() is to switch dispatchers (threads) without starting a new coroutine. It doesn't track and wait for any coroutines launched inside it before returning.

Let Me Paint You a Picture

Imagine you're a team lead. You tell your assistant:

“Go to the warehouse and make sure all boxes are stacked.”

The assistant walks in, but instead of doing the stacking, he calls someone else and immediately walks out.

“Boxes are stacked, boss!”

Meanwhile, the boxes are still lying around, unstacked.

That’s exactly what happens when you launch inside withContext. The block returns, but the actual task isn’t finished.

Why Is This Dangerous?

You might start reading shared data before it’s been updated.
Cleanup might run before a job is complete.
Background tasks might leak or throw unexpected errors.

You think everything is done, but some coroutine is silently working in the background. That's a recipe for race conditions and flaky bugs.

How to Fix It

You’ve got two clean options depending on what you want:

1. Just do the work inside `withContext`

withContext(Dispatchers.IO) {
    delay(1000)
    println("Done properly")
}

No launch. Just let withContext suspend until it’s done.

2. Use `coroutineScope` inside `withContext` if you need multiple launches

withContext(Dispatchers.IO) {
    coroutineScope {
        launch {
            delay(1000)
            println("Task 1 done")
        }
        launch {
            delay(500)
            println("Task 2 done")
        }
    }
}

Output:

Task 2 done  
Task 1 done  
After all tasks

✅ coroutineScope ensures that withContext won’t finish until all its child coroutines have completed.

Bad Nesting in Real Life

1. Orphaned Coroutine Example

withContext(Dispatchers.IO) {
    launch {
        delay(1000)
        println("Still running after withContext ends 😵")
    }
    println("withContext done")
}
println("runBlocking done")

Output:

withContext done  
runBlocking done  
Still running after withContext ends 😵

2. Race Condition Example

withContext(Dispatchers.IO) {
    launch {
        delay(1000)
        println("Updating shared resources")
    }
    println("Assuming updates are done 🤡")
}
println("Reading shared resources 😬")

🧾 Output:

Assuming updates are done 🤡  
Reading shared resources 😬  
Updating shared resources

Yikes.

Final Thoughts

Bad nesting is sneaky because it looks innocent, but it quietly breaks everything structured concurrency stands for.

Next time you're inside a withContext, ask yourself:

“Am I doing the work, or am I delegating it?”

If it's the latter, make sure you're supervising the workers properly using coroutineScope. 😉

✍️ About the Author

Hey! I’m Abizer, an Android developer who’s into finding weird bugs that make for great blog posts.

If this helped you out, follow me here or connect on GitHub / LinkedIn.

Have you been bitten by bad coroutine nesting? Share your bug story in the comments!