DEV Community: Aalaa Fahiem

I Thought Coroutines Were Enough. (Flow, StateFlow, MutableStateFlow)

Aalaa Fahiem — Tue, 23 Jun 2026 12:56:05 +0000

I had coroutines working. The data loaded. The screen showed something. I felt like I finally understood async in Android.

Then I added a search bar that should filter results as you type.

I called my suspend function on every keystroke. Every single character triggered a fresh network call. The results flickered. Old responses arrived after newer ones. The UI was a mess.

That's when I realized — coroutines give you one value, once. But some data doesn't work that way. Some data is alive. It changes. It flows.

That's when I learned Flow. And then StateFlow. And the way data actually moves through an Android app finally made sense.

The Problem With `suspend` for Live Data

A suspend function is like ordering food. You place the order, you wait, you get your food. Done. One request, one result.

But what if you're tracking a live score? What if you want to react every time the database changes? What if the user is typing and you want to filter results in real time?

You don't want one answer. You want a stream of answers over time.

// One value, one time — then silence
suspend fun getPokemon(): Pokemon

// A new value every time something changes
fun getPokemonUpdates(): Flow<Pokemon>

That's the difference. suspend is a bottle of water. Flow is a pipe.

What Is a Flow?

A Flow is a stream of values that arrive over time. You create it, you collect it, and every time a new value is emitted — your code runs.

fun countDown(): Flow<Int> = flow {
    emit(3)
    delay(1000)
    emit(2)
    delay(1000)
    emit(1)
}

emit() is how you push a value into the stream. Each emit is one item. The collector receives them one by one.

And here's the important part — a Flow does nothing until someone collects it. It's lazy. It just sits there, waiting.

viewModelScope.launch {
    countDown().collect { value ->
        println(value) // 3... 2... 1...
    }
}

The moment you call collect, the flow starts running.

Flow Operators — Where It Gets Useful

This is the part I wish I'd paid attention to earlier.

You don't have to collect raw values. You can transform the stream before it ever reaches your UI — filter it, map it, reshape it.

repository.getPokemonList()
    .filter { it.type == "fire" }
    .map { it.name.uppercase() }
    .collect { name ->
        textView.text = name
    }

Reads like a sentence. Each operator takes the stream, does something to it, and passes it along.

The ones you'll use most:

Operator	What it does
`map`	Transform each value into something else
`filter`	Only let values through that match a condition
`onEach`	Do something with each value without changing it
`take(n)`	Stop after n values

The Problem With Regular Flow in the UI

Here's something I did wrong for longer than I'd like to admit.

// In ViewModel
fun getPokemon(): Flow<Pokemon> = repository.getPokemon()

// In Activity
lifecycleScope.launch {
    viewModel.getPokemon().collect { pokemon ->
        textView.text = pokemon.name
    }
}

Looks fine. It's not.

Every time the Activity collects this flow — a new one starts from scratch. New network call. New everything. And when the phone rotates? The collection stops, the flow restarts, and the last value is gone. The screen flashes.

You need something that holds the current value and gives it immediately to anyone who starts watching — even if they started watching late.

That's StateFlow.

StateFlow — Flow That Remembers

StateFlow is a flow with one extra superpower: it always holds the latest value in memory.

Think of a scoreboard at a football match. Whether you look at it the moment a goal is scored or ten minutes later — you see the current score. You don't wait for the next goal to know what's happening.

That's StateFlow. It always knows what the current value is, and it tells you immediately.

class PokemonViewModel : ViewModel() {

    private val _pokemon = MutableStateFlow<Pokemon?>(null)
    val pokemon: StateFlow<Pokemon?> = _pokemon

    fun loadPokemon(name: String) {
        viewModelScope.launch(Dispatchers.IO) {
            val result = repository.getPokemon(name)
            _pokemon.value = result
        }
    }
}

Notice — no emit(). StateFlow uses .value = to update. And it lives in the ViewModel, so it survives rotation.

The Private/Public Pattern (Please Don't Skip This)

You'll see this in every professional Android project:

private val _pokemon = MutableStateFlow<Pokemon?>(null)  // you write to this
val pokemon: StateFlow<Pokemon?> = _pokemon              // UI reads from this

The underscore one is private and mutable — only the ViewModel can change it. The public one is read-only — the UI can observe it but never modify it directly.

This isn't just style. It's a rule. The UI should never control the state. It just reacts to it.

Collecting StateFlow in the UI

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.pokemon.collect { pokemon ->
            pokemon?.let { textView.text = it.name }
        }
    }
}

repeatOnLifecycle(STARTED) is the piece most tutorials skip. It automatically pauses collection when the app goes to background and resumes when it comes back. Without it, your flow keeps running even when the user can't see the screen — wasting battery, risking crashes.

Always use it when collecting in an Activity or Fragment.

Flow vs StateFlow — The Simple Version

	Flow	StateFlow
Holds last value?	No	Yes
Starts automatically?	No — needs a collector	Yes — always running
Where it lives	Repository	ViewModel
Use it for	DB queries, data streams	UI state

The rule I follow: data comes from the repository as Flow. Data goes to the UI as StateFlow.

// Repository — emits a stream
fun getPokemonList(): Flow<List<Pokemon>>

// ViewModel — holds the current state for the UI
private val _list = MutableStateFlow<List<Pokemon>>(emptyList())
val list: StateFlow<List<Pokemon>> = _list

init {
    viewModelScope.launch {
        repository.getPokemonList().collect { result ->
            _list.value = result
        }
    }
}

The Full Picture

Repository
   └── Flow<T>               ← stream from data source, lazy

ViewModel
   └── MutableStateFlow<T>   ← holds current value, survives rotation
   └── StateFlow<T>          ← read-only, exposed to UI

UI
   └── collect { }           ← reacts to every change

Once I drew this out, everything clicked. The data flows in one direction — from the source, through the ViewModel, to the screen. Each layer has one job.

What I Wish I Knew Earlier

Flow and StateFlow aren't two separate tools that compete. They're two parts of the same pipeline.

Flow is for the journey. StateFlow is for the destination.

Once you think of it that way — your Repository emitting changes, your ViewModel holding the latest version of truth, your UI just reacting — the code writes itself.

And that flickering search bar I mentioned at the start? Fixed. One Flow, debounced, collected properly. No more race conditions. No more flashing.

My App Froze Every Time It Loaded Data. That's When I Finally Understood Coroutines.

Aalaa Fahiem — Mon, 22 Jun 2026 09:56:15 +0000

I didn't know my app was broken.

It worked. The data showed up. The UI updated. I thought I was doing great.

Then someone ran it on a slow connection and sent me a screen recording. The app was completely frozen for 3 seconds. Nothing moved. The button didn't respond. It looked dead.

I was doing network calls on the Main Thread. I had no idea that was even a thing I could do wrong.

That's when I started actually learning coroutines — not copy-pasting them, learning them.

First, Why Does the Main Thread Even Matter?

Your Android app runs on one main thread. That thread does everything you see — drawing buttons, responding to taps, updating text. It's the only thread that can touch the UI.

If you give it slow work to do — like waiting for an API response — it can't do anything else. It just stands there. Waiting. While your users stare at a frozen screen.

Think of it like a waiter who goes to the kitchen, stands there until the food is ready, and refuses to take any other orders in the meantime. The whole restaurant stops.

Main Thread: [waiting for network response.........] [show result]
                    ☠️ App is completely frozen here

That's the problem coroutines solve.

So What Even Is a Coroutine?

A coroutine is a piece of work that can pause itself without blocking the thread.

The waiter analogy again — but this time, the waiter puts in the order, goes back to serving other tables, and comes back when the food is ready. The restaurant keeps running. Nobody is waiting.

Coroutine:    [start] → [pause: waiting for network] → [resume] → [done]
Main Thread:                  ↑ free to handle UI here ↑

The keyword that makes this possible is suspend.

`suspend` — The One Keyword That Changes Everything

A suspend function is a function that can pause and resume. That's the whole thing.

suspend fun getPokemon(): Pokemon {
    return api.fetchPokemon("pikachu") // pauses here, frees the thread
}

It looks exactly like a normal function. It returns a value like a normal function. The difference is what happens underneath — instead of blocking the thread, it pauses and lets the thread go do other things.

Two rules to remember:

You can only call a suspend function from another suspend function, or from inside a coroutine.
That's it. That's the rule.

Starting a Coroutine — `launch` vs `async`

You can't just call a suspend function from anywhere. You need to launch a coroutine first. Think of it as opening a room where suspend functions are allowed to live.

launch — when you don't need a result back

viewModelScope.launch {
    val pokemon = getPokemon() // suspend call — pauses here
    _uiState.value = pokemon   // resumes here when done
}

async — when you need a result

viewModelScope.launch {
    val pokemonDeferred = async { getPokemon() }
    val pokemon = pokemonDeferred.await() // wait for the result
}

Most of the time you'll use launch. Use async when you want to run two things at the same time and wait for both.

Dispatchers — Who Does the Work?

Just because you're in a coroutine doesn't mean the slow work goes to the right thread automatically. You have to tell it where to run. That's what Dispatchers are for.

Dispatcher	Use it for
`Dispatchers.Main`	UI updates — text, buttons, anything visible
`Dispatchers.IO`	Network calls, database reads, file access
`Dispatchers.Default`	Heavy CPU work — sorting, parsing large data

viewModelScope.launch(Dispatchers.IO) { // network work on IO
    val pokemon = api.fetchPokemon("pikachu")

    withContext(Dispatchers.Main) {      // switch to Main for UI
        textView.text = pokemon.name
    }
}

withContext is how you switch dispatchers mid-coroutine. It's clean. It's readable. You'll use it constantly.

Scopes — The Lifetime of a Coroutine

Every coroutine lives inside a scope. When the scope dies, all its coroutines die too. This is how Android prevents memory leaks automatically.

Scope	Dies when
`viewModelScope`	The ViewModel is cleared
`lifecycleScope`	The Activity or Fragment is destroyed
`GlobalScope`	Never — avoid this one

As a junior dev, you'll mostly use viewModelScope. It's the safe default.

class PokemonViewModel : ViewModel() {
    fun loadPokemon(name: String) {
        viewModelScope.launch {  // auto-cancelled when ViewModel dies
            val pokemon = repository.getPokemon(name)
            _pokemon.value = pokemon
        }
    }
}

You didn't write any cleanup code. You didn't manage any threads manually. The scope handled all of it.

Error Handling

One more thing before you go build something — handle your errors.

viewModelScope.launch {
    try {
        val pokemon = api.fetchPokemon(name)
        _uiState.value = UiState.Success(pokemon)
    } catch (e: Exception) {
        _uiState.value = UiState.Error("Something went wrong")
    }
}

Network calls fail. Always wrap them.

The Mental Model

This is the whole thing in one picture:

viewModelScope.launch(Dispatchers.IO) {
│
├── call suspend fun  →  coroutine PAUSES, thread goes free
│
├── response arrives  →  coroutine RESUMES
│
└── withContext(Dispatchers.Main) { update the UI }
}

Scope controls the lifetime.
Dispatcher controls the thread.
suspend controls the pause.

What I Wish I Knew Earlier

Coroutines aren't magic. They're a structured way to write async code that looks synchronous. No callbacks. No nested hell. Just top-to-bottom code that knows when to pause and when to come back.

Once that clicked for me, a lot of the "why does this feel wrong" in my code started making sense.

If your app ever froze and you didn't know why — now you do.

As a Junior Android Dev Should I Memorize All Retrofit Code or Just Ask AI?(Interview Questions)

Aalaa Fahiem — Wed, 17 Jun 2026 09:24:34 +0000

I was learning Retrofit and staring at a wall of boilerplate code thinking:
"Am I supposed to have all of this memorized?"

So I asked — and the honest answer surprised me. Most juniors are afraid to raise this question. Here's what I found out.

Should You Write It All From Memory?

No. And yes. It depends on what part.

Think of it like learning to drive:

You don't need to know how to build a car engine from scratch
But you do need to know how to drive, and what to do when something breaks There are 3 zones — and once you understand them, the whole learning process feels way less overwhelming.

Zone 1 — Let AI Write It

Boilerplate. Nobody memorizes this.

// This setup in AppModule.kt? AI writes it. Every time.
val okHttpClient = OkHttpClient.Builder()
    .connectionSpecs(listOf(spec, ConnectionSpec.CLEARTEXT))
    .protocols(listOf(Protocol.HTTP_1_1))
    .dns(object : Dns {
        override fun lookup(hostname: String): List<InetAddress> {
            return Dns.SYSTEM.lookup(hostname).filter { it is Inet4Address }
                .ifEmpty { Dns.SYSTEM.lookup(hostname) }
        }
    })
    .connectTimeout(30, TimeUnit.SECONDS)
    ...

Nobody writes this from memory. Senior devs copy-paste it from their last project. Use AI or docs — zero shame.

Zone 2 — You MUST Know This Cold
This will be tested in interviews. Learn it by heart.

1. Writing the API interface yourself

    interface PokeApi {
    @GET("pokemon")
    suspend fun getPokemonList(
        @Query("limit") limit: Int,
        @Query("offset") offset: Int,
    ): PokemonList

    @GET("pokemon/{name}")
    suspend fun getPokemonInfo(@Path("name") name: String): Pokemon
}

It's only ~10 lines, and it's the heart of Retrofit. Write it without help.

2. The basic Retrofit builder

Retrofit.Builder()
    .baseUrl("https://pokeapi.co/api/v2/")
    .addConverterFactory(GsonConverterFactory.create())
    .build()
    .create(PokeApi::class.java)

4 lines. Know these by heart.

3. The data flow in your head

Be able to explain this out loud without hesitation:

UI → ViewModel → Repository → API interface → Retrofit builds URL → OkHttp sends it → Gson parses response → back up the chain

4. What the annotations do

-@GET — Sends a GET request to the given endpoint
-@POST — Sends a POST request
-@Query — Adds ?key=value to the end of the URL
-@Path — Fills a {slot} inside the URL
-@Body — Sends an object as the request body (JSON)

5. Why `suspend`?

"Network calls block the thread. suspend runs them in a coroutine so the UI doesn't freeze."

Key points to remember:

suspend means the function can pause while waiting (for network, DB, etc.) and resume later without blocking the app
It does not create a new thread — it just allows pausing and resuming
You call it from a coroutine scope like viewModelScope.launch { }
Retrofit API calls are suspend because network requests take time

Zone 3 — Understand It, Don't Memorize It


// Resource wrapper — understand WHY it exists
sealed class Resource<T> {
    class Success<T>(data: T)
    class Error<T>(message: String)
    class Loading<T>()
}

You should be able to explain:

"It wraps the result so the ViewModel can handle success, error, and loading states cleanly."

You don't need to write it from memory — but if an interviewer shows it to you, you need to explain it confidently.

The mental model:

suspend              → gets data safely from slow operations
Resource             → tells the app what happened with the data
ViewModel + StateFlow → sends the new state to the UI

The Real Interview Questions

🟢 Easy — Answer instantly

"What is Retrofit?"
A type-safe HTTP client that turns your interface methods into network calls.

"What is @GET?"
Annotation that makes the function send a GET request to that endpoint.

"Difference between @Query and @Path?"
@Path fills a {slot} in the URL, @Query adds ?key=value at the end.

"What is Gson converter?"
Converts JSON from the server into Kotlin/Java objects automatically.

"Why suspend?"
Network calls are slow — suspend runs them off the main thread so the UI doesn't freeze.

🟡 Medium — Think 5 seconds, then answer

"What is OkHttp and how does it relate to Retrofit?"

Retrofit sits on top of OkHttp. Retrofit handles the interface, annotations, and conversion. OkHttp is the actual engine that opens the socket and sends/receives bytes. You can customize OkHttp (timeouts, interceptors, headers) and plug it into Retrofit.

"What is an Interceptor?"

A piece of code that runs on every request before it's sent (or every response before it arrives). Used for adding auth headers, logging, modifying requests.

"What is the Repository pattern and why use it?"

A middle layer between the ViewModel and the data source (API/database). The ViewModel doesn't care whether data comes from the internet or a local DB — it just asks the Repository. Makes testing easier and keeps code clean.

"What does @SerializedName do?"

Tells Gson to map a specific JSON key to a Kotlin field, even if the names are different. Example: JSON has "base_experience" but Kotlin uses baseExperience.

🔴 Hard — Bonus points if you nail these

"What happens if you don't add suspend to a Retrofit function?"

Before Retrofit 2.6, you used Call<T>. With suspend, Retrofit uses coroutines natively and runs on a background thread automatically. Without suspend in a coroutine-based project, you'd get a crash or have to handle Call<T> manually.

"How would you add an auth token to every request?"

Add an OkHttp Interceptor:


.addInterceptor { chain ->
    val request = chain.request().newBuilder()
        .header("Authorization", "Bearer $token")
        .build()
    chain.proceed(request)
}

"What is @singleton in Hilt and why does Retrofit need it?"

Creating a Retrofit instance is expensive — it sets up connection pools, parsers, and configuration. @singleton tells Hilt to create it once and reuse the same instance everywhere.

Key points:

Without @singleton, Hilt may create multiple Retrofit objects — wasteful and slow

In Android apps, we keep one Retrofit instance for the whole app and inject it wherever needed

TL;DR
Zone 1 — Boilerplate → Let AI write it. Always.
Zone 2 — Core concepts → Memorize it. Interviews will ask.
Zone 3 — Patterns → Understand the why, not the exact syntax.
The goal isn't to be a human compiler. It's to understand the system well enough to drive it, debug it, and explain it — even when you don't know every line by heart.

Still learning Kotlin and Android as a junior dev — writing about it as I go. If this helped, I'd love to hear what you're building! 👇

The Complete Retrofit Lifecycle in a Real Android App

Aalaa Fahiem — Tue, 16 Jun 2026 15:34:39 +0000

Most Retrofit tutorials show you isolated code snippets. This article traces the entire lifecycle of a Retrofit call — from app startup to data appearing on screen — using real code from a Pokedex app built with Kotlin, Hilt, Coroutines, and Jetpack Compose.

By the end, you'll understand every link in the chain!

What Is Retrofit?

Retrofit is a type-safe HTTP client for Android and Java. Instead of writing raw HTTP requests, you describe your API as a Kotlin interface, and Retrofit generates the networking code for you behind the scenes.

interface PokeApi {
    @GET("pokemon")
    suspend fun getPokemonList(
        @Query("limit") limit: Int,
        @Query("offset") offset: Int,
    ): PokemonList

    @GET("pokemon/{name}")
    suspend fun getPokemonInfo(
        @Path("name") name: String,
    ): Pokemon
}

That's it. No manual HttpURLConnection, no manual JSON parsing. Retrofit handles building the request and Gson (or Moshi) handles converting the JSON response into your Kotlin objects.

The 3 Building Blocks

Every Retrofit setup needs exactly three things:

The Interface — what requests can be made
The Builder — where to send them and how to parse responses
The Response model — what shape the data comes back in

val retrofit = Retrofit.Builder()
    .baseUrl("https://pokeapi.co/api/v2/")
    .addConverterFactory(GsonConverterFactory.create())
    .build()

val api = retrofit.create(PokeApi::class.java)

The Full Lifecycle, Step by Step

Here's the entire request lifecycle traced through a real app architecture: Compose UI → ViewModel → Repository → Retrofit → OkHttp → Server → Gson → back up the chain.

Step 1 — App Starts, Hilt Wakes Up

@HiltAndroidApp
class PokedexApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        Timber.plant(Timber.DebugTree())
    }
}

@HiltAndroidApp tells Hilt to start managing dependency injection across the app.

Step 2 — Hilt Builds Retrofit Once (Singleton)

@Module
@InstallIn(SingletonComponent::class)
object AppModule {

    @Singleton
    @Provides
    fun providePokeApi(): PokeApi {
        val okHttpClient = OkHttpClient.Builder()
            .connectTimeout(30, TimeUnit.SECONDS)
            .readTimeout(30, TimeUnit.SECONDS)
            .retryOnConnectionFailure(true)
            .addInterceptor { chain ->
                val request = chain.request().newBuilder()
                    .header("User-Agent", "Mozilla/5.0 ...")
                    .header("Accept", "application/json")
                    .build()
                chain.proceed(request)
            }
            .build()

        return Retrofit.Builder()
            .baseUrl(Constants.BASE_URL)
            .client(okHttpClient)
            .addConverterFactory(GsonConverterFactory.create())
            .build()
            .create(PokeApi::class.java)
    }

    @Singleton
    @Provides
    fun providePokemonRepository(api: PokeApi) = PokemonRepository(api)
}

Building a Retrofit instance is expensive — connection pools, thread pools, parsers. @Singleton ensures it's built once and reused everywhere, instead of recreated per screen.

Step 3 — ViewModel Is Created, Requests Data Immediately

@HiltViewModel
class PokemonListViewModel @Inject constructor(
    private val repository: PokemonRepository,
) : ViewModel() {

    var pokemonList = mutableStateOf<List<PokedexListEntry>>(listOf())
    var isLoading = mutableStateOf(false)

    init {
        loadPokemonPaginated()
    }

    fun loadPokemonPaginated() {
        viewModelScope.launch {
            isLoading.value = true
            val result = repository.getPokemonList(PAGE_SIZE, curPage * PAGE_SIZE)
            // handle result below
        }
    }
}

Hilt injects the PokemonRepository automatically — no manual instantiation needed. viewModelScope.launch starts a coroutine so the network call doesn't block the main thread.

Step 4 — Repository Calls the API and Handles Failure

@Singleton
class PokemonRepository @Inject constructor(
    private val api: PokeApi,
) {
    suspend fun getPokemonList(limit: Int, offset: Int): Resource<PokemonList> {
        val response = try {
            api.getPokemonList(limit, offset)
        } catch (e: Exception) {
            return Resource.Error("Couldn't load Pokemon")
        }
        return Resource.Success(response)
    }
}

The Repository pattern decouples the ViewModel from the data source. The ViewModel doesn't know — or care — whether data comes from a network call, a cache, or a database.

Step 5 — Retrofit Builds the URL and OkHttp Sends It

Given:

@GET("pokemon")
suspend fun getPokemonList(
    @Query("limit") limit: Int,
    @Query("offset") offset: Int,
): PokemonList

Calling getPokemonList(20, 0) produces:

https://pokeapi.co/api/v2/pokemon?limit=20&offset=0

OkHttp (the engine underneath Retrofit) opens the connection, attaches any interceptor headers, and sends the request over the wire.

Step 6 — Server Responds With JSON

{
  "count": 1302,
  "next": "https://pokeapi.co/api/v2/pokemon?offset=20&limit=20",
  "previous": null,
  "results": [
    { "name": "bulbasaur", "url": "https://pokeapi.co/api/v2/pokemon/1/" }
  ]
}

Step 7 — Gson Converts JSON Into Kotlin Objects

data class PokemonList(
    @SerializedName("count") val count: Int,
    @SerializedName("next") val next: String,
    @SerializedName("previous") val previous: Any,
    @SerializedName("results") val results: List<Result>,
)

@SerializedName maps a JSON key to a Kotlin property — essential when the server uses snake_case and your code uses camelCase.

Step 8 — Result Flows Back Up, Wrapped in a Sealed Class

sealed class Resource<T>(val data: T? = null, val message: String? = null) {
    class Success<T>(data: T) : Resource<T>(data)
    class Error<T>(message: String, data: T? = null) : Resource<T>(data, message)
    class Loading<T>(data: T? = null) : Resource<T>(data)
}

This wrapper lets the ViewModel handle success, error, and loading as explicit states rather than nullable guesswork.

Step 9 — ViewModel Updates State, Compose Redraws

when (result) {
    is Resource.Success -> {
        pokemonList.value += result.data!!.results.map { /* map to UI model */ }
        isLoading.value = false
    }
    is Resource.Error -> {
        loadError.value = result.message!!
        isLoading.value = false
    }
    else -> {}
}

Because pokemonList is a Compose mutableStateOf, the moment it changes, any composable reading it recomposes automatically. No manual UI refresh needed.

The Full Chain, Visualized

App starts → Hilt builds Retrofit + Repository (once)
    ↓
ViewModel created → Repository injected → init{} fires
    ↓
viewModelScope.launch → repository.getPokemonList()
    ↓
api.getPokemonList() → Retrofit builds the URL
    ↓
OkHttp attaches headers, sends the HTTP request
    ↓
Server responds with JSON
    ↓
Gson converts JSON → Kotlin data class
    ↓
Repository wraps it in Resource.Success / Resource.Error
    ↓
ViewModel updates mutableStateOf
    ↓
Compose recomposes → user sees the data

Jetpack Compose Navigation(Interview Prep)

Aalaa Fahiem — Wed, 10 Jun 2026 17:58:39 +0000

About this article: This is based on hands-on review of a real project. The goal is understanding over memorization — because interviewers can always tell the difference.

Screen.Details.route vs Screen.Details.createRoute(name) — What's the Difference? This trips up a lot of people because both look like they're "the route." They're not. Screen.Details.route is a template — it contains a placeholder: "details/{pokemonName}" You use this when registering the destination inside NavHost, so the navigation system knows the shape of the route and which argument to extract. Screen.Details.createRoute(name) produces a real URL like: "details/Pikachu" You use this when navigating — navController.navigate(...) needs an actual address with real data embedded.

⚠️ What breaks if you use .route in both places?
NavHost would still match the route, but the extracted argument would be the literal string "{pokemonName}" instead of the actual Pokémon name. No crash — just silent wrong data.

Key Rule → Template for registration. Real URL for navigation.

Defining a Route in NavConstants Doesn't Register It If NavConstants.kt defines Search and Settings but they never appear in AppNavigation, what happens when you call navController.navigate(Screen.Search.route)? The app crashes at runtime: IllegalArgumentException: "navigation destination 'search' is unknown to this NavController" Here's why this confuses people:

NavConstants.kt is just a dictionary of strings — defining a route there costs nothing and guarantees nothing.
AppNavigation.kt is where destinations actually exist — a route only becomes real when it has a matching composable() registered inside NavHost.

NavConstants protects you from typos. It cannot protect you from forgetting to register the destination. Both mistakes crash the app.
Key Rule → You need both — the string AND the composable() registration.

nullable = false and if (name != null) Are Not Contradicting Each Other
You might see navArgument("pokemonName") { nullable = false } declared, and then right below it, the code still does ?. and if (name != null). That looks contradictory. It's not.
They operate at completely different layers:
nullable = falseif (name != null)LayerNavigation systemKotlin type systemWhen it actsRuntime navigationCompile timeWhat it doesCrashes if arg is missingSatisfies the compiler
Bundle.getString() always returns String? regardless of your navigation contract — the Kotlin compiler has no idea about navArgument rules. The null check is there to satisfy the compiler, not because you genuinely expect null at runtime.
Key Rule → Navigation contract and Kotlin types are separate systems that don't talk to each other.
popBackStack() vs navigate(Home) — Never Substitute One for the Other
Both can result in the user seeing the Home screen. But what they do to the back stack is completely different.
popBackStack() removes the current screen and reveals what was beneath it:
Before: [Home, Details]
After: [Home] ← Details removed, Home revealed
navigate(Screen.Home.route) pushes a new Home screen on top:
Before: [Home, Details]
After: [Home, Details, Home] ← new Home added

⚠️ Why it matters: After navigate(), pressing Back lands the user on Details — a screen they thought they left. Press again, they're on the original Home. The back stack grows silently and creates a broken experience.

Key Rule → Use popBackStack() to go back. Use navigate() to go forward. Never substitute.

When Do You Actually Need backStackEntry?
Inside NavHost, the lambda for composable() can optionally name its parameter backStackEntry. Some composables do, some don't. Why?
backStackEntry gives access to arguments embedded in the route. Screens with static routes like "home" or "profile" have no arguments — there's nothing to extract, so backStackEntry is ignored and not named.
Details has {pokemonName} in its route. When navController.navigate("details/Pikachu") was called, the navigation system stored "Pikachu" in the backStackEntry's argument bundle. backStackEntry.arguments?.getString("pokemonName") pulls it back out.
Key Rule → You only need backStackEntry when the route carries arguments.
The Three Layers of Compose Navigation
Understanding these three layers separately makes everything else click.
🔵 Navigation System Layer

Rules enforced at runtime by NavHost/NavController
Every route navigated to must be registered with composable() — otherwise crash
nullable = false is a contract here — violate it, it throws
Doesn't know Kotlin types

🟣 Kotlin Type System Layer

Rules enforced at compile time by the compiler
Bundle.getString() returns String? — compiler forces null handling
Has no awareness of navigation contracts or navArgument rules
Doesn't know your back stack state

🟢 Back Stack Layer

Runtime state — the history of where the user has been
navigate() always pushes a new destination
popBackStack() always removes the top destination
System Back button also pops it
Keeps growing until something pops it

A quick comparison between the two that are most often confused:
Kotlin Type SystemBack StackNatureCompile-time rulesRuntime stateCares aboutNullability, typesNavigation historyExamplegetString() returns String?[Home, Details] grows with navigate()

Navigation Hoisting — Screens Get Lambdas, Not NavController Navigation hoisting means screen composables receive navigation actions as lambda parameters instead of having direct access to navController. kotlin// AppNavigation owns navController, passes actions as lambdas HomeScreen( onNavigateToProfile = { navController.navigate(Screen.Profile.route) }, onPokemonClick = { name -> navController.navigate(Screen.Details.createRoute(name)) } )

// HomeScreen knows nothing about navController
@Composable
fun HomeScreen(
onNavigateToProfile: () -> Unit,
onPokemonClick: (String) -> Unit
)
Why this pattern exists:

Separates UI logic from navigation logic
HomeScreen becomes testable without a real NavController
Screens stay reusable — they don't care how navigation is implemented

Notice the subtle difference between the two lambdas above:

onNavigateToProfile: () -> Unit — no data needed; Profile renders itself without input
onPokemonClick: (String) -> Unit — carries the Pokémon name; Details needs it to know what to show

Key Rule → Screens get lambdas, not navController.

Quick Reference Card
ConceptRule.route vs createRoute()Template to register, real URL to navigateUnregistered routeCrashes at runtime with IllegalArgumentExceptionnullable = falseNavigation contract — not Kotlin null safetypopBackStack() vs navigate()Go back vs go forward — never substitutebackStackEntryOnly needed when the route carries argumentsNavigation hoistingScreens get lambdas, not navControllerNavConstantsPrevents typos, not missing registrations

Found this useful? These notes came from reviewing a real Compose project end-to-end — the kind of hands-on work that makes interview answers actually stick.

I Thought Passing Data Between Screens Would Be Easy. It Was Not.

Aalaa Fahiem — Tue, 09 Jun 2026 18:10:50 +0000

Let me tell you exactly how my week went.
Day one: I tried to pass a full Product object through navigation instead of just the ID.
The app compiled fine. Then it crashed the moment I tapped a product. No helpful message. Just gone.
Day two: I passed the ID correctly this time — I'd learned from the last article — but after navigating to the detail screen, I had this weird feeling: where is the data actually living right now? I couldn't explain it. I just trusted that backStackEntry.arguments would have it, and sometimes it did, and sometimes I got null, and I had no idea why.
Day three: I figured out how to send data forward fine. But then I needed to send data back — back to the previous screen after the user made a selection. And I stared at the screen for a very long time because nothing in what I'd learned prepared me for that direction.
All three of these happened to me within the same week on the same project. And they all came from the same root problem: I was guessing at how navigation handles data instead of actually understanding it.
This article is me stopping the guessing — for both of us.
We're continuing with the e-commerce app from the last article: Product List → Product Detail → Cart. If you haven't read that one, the short version is: we have a sealed class for routes, a NavHost, and a NavController. That setup stays exactly the same. What we're doing today is understanding everything that happens when data moves between those screens.

Why You Can't Just Pass a Full Object
This is where most people start — and where most people hit their first wall.
You have a Product. The detail screen needs a Product. Why not just... pass it?
kotlin// This feels logical. Don't do it.
navController.navigate(Screen.ProductDetail.createRoute(product))
Here's why it doesn't work.
Navigation routes are strings. That's the core of the system. When you call navController.navigate(...), you're navigating to a string address — like a URL. "product_detail/1" is a valid address. "product_detail/Product(id=1, name=Air Max 90, price=120.0)" is not.
The system wasn't built to serialize and deserialize objects through a URL. And even if you found a workaround — JSON encoding, for example — you'd be fighting the architecture instead of using it.
There's also a deeper reason. Screens in a navigation stack can be recreated from their route alone. If Android kills your process and the user comes back, it needs to be able to rebuild the back stack. A string ID can do that. A full object floating in memory cannot.
So the rule is simple: pass the minimum. Pass the ID.
kotlin// This is the right mental model.
// The ID is just an address. The screen goes and fetches the full data.
navController.navigate(Screen.ProductDetail.createRoute(product.id))

Primitives: What's Actually Happening
In the last article, we passed a productId: Int and moved on. Let's slow down and actually read what's happening, because this is where the null mystery comes from.
Here's the route definition:
kotlinobject ProductDetail : Screen("product_detail/{productId}") {
fun createRoute(productId: Int) = "product_detail/$productId"
}
The {productId} in the route template is a placeholder. It's saying: "when this screen is registered, expect something called productId to be embedded in the URL."
When you navigate with "product_detail/1", the system parses the URL, matches the pattern, and extracts 1 as the value of productId. It holds onto it in a Bundle called arguments.
That Bundle lives inside the NavBackStackEntry — the entry for this specific screen in the back stack. It's tied to that entry's lifecycle. As long as the screen is in the back stack, the arguments are there.
Here's the NavHost registration:
kotlincomposable(
route = Screen.ProductDetail.route,
arguments = listOf(
navArgument("productId") { type = NavType.IntType }
)
) { backStackEntry ->
val productId = backStackEntry.arguments?.getInt("productId") ?: 0
ProductDetailScreen(productId = productId, navController = navController)
}
The navArgument block isn't just decoration. It tells the system the type of the argument. This matters because the URL is a string — "product_detail/1" — and the system needs to know to convert "1" into an Int, not leave it as "1".
If you forget the arguments list, or name the argument differently here than in the route template, the system can't match them. The value doesn't get extracted. backStackEntry.arguments?.getInt("productId") returns null. That's the mystery.
The ?: 0 at the end is a fallback — if for any reason the argument is missing, we default to 0 instead of crashing. In a real app, you'd probably show an error state instead, but the pattern is the same.

Optional Arguments and Default Values
Here's something the documentation doesn't make obvious: arguments can be optional.
By default, a {placeholder} in a route is required. If it's not there, navigation fails. But sometimes you have a screen that works fine without certain data — a search screen that can open with or without an initial query, for example.
In our e-commerce app, let's say the Cart screen can optionally receive a couponCode that pre-fills a discount field:
kotlinobject Cart : Screen("cart?couponCode={couponCode}") {
fun createRoute(couponCode: String? = null): String {
return if (couponCode != null) "cart?couponCode=$couponCode"
else "cart"
}
}
Two things changed here. First, the syntax: optional arguments use query parameter format — ?key={value} — instead of path format — /{value}. This is how the system knows an argument is optional.
Second, createRoute() now has two forms: one with a coupon code, one without. Both navigate to "the cart screen" — just with different context.
The NavHost registration:
kotlincomposable(
route = Screen.Cart.route,
arguments = listOf(
navArgument("couponCode") {
type = NavType.StringType
nullable = true
defaultValue = null
}
)
) { backStackEntry ->
val couponCode = backStackEntry.arguments?.getString("couponCode")
CartScreen(couponCode = couponCode, navController = navController)
}
The nullable = true and defaultValue = null are what make this argument optional. Without them, the system would require the argument to be present.
Now you can navigate to the cart two ways:
kotlin// From ProductDetail — no coupon
navController.navigate(Screen.Cart.createRoute())

// From a promotional banner — with a coupon pre-filled
navController.navigate(Screen.Cart.createRoute(couponCode = "SAVE20"))
Both work. The cart screen handles both cases based on whether couponCode is null or not.

The Junior Dev Who Never Had to Google Anything — Is That a Superpower or a Problem?

Aalaa Fahiem — Tue, 09 Jun 2026 17:54:30 +0000

Let me tell you four things that happened to me.

One. I sat in a mock interview. The question was basic — embarrassingly basic for someone who'd been coding for months. And I went completely blank. Not because I didn't know the concept. I did. I'd used it dozens of times. But every single time I'd used it, I'd asked AI first. I never had to hold the answer in my own head. So when someone asked me to pull it out of my head on the spot, there was nothing there.

Two. I looked at a file in my own project — code I wrote, in a project I built — and I couldn't explain what one of the functions was doing. I remembered asking AI for it. I remembered copying it. I remembered it working. But the understanding? I never actually got it. I just got the output.

Three. A friend of mine — also a junior — lost internet access for two hours during a coding session. He sent me a message that I still think about: "I don't know how to do anything without it." He wasn't joking. He sat there until the connection came back.

Four. And me. All three of those stories are me.

I want to be honest with you about something that nobody in the dev community is saying loudly enough:

AI tools are making some of us faster. And quietly making others of us hollow.

And the terrifying part is — you can't always tell which one you are until it's too late.

The Superpower Feeling Is Real

I'm not going to pretend it isn't.

The first time I used AI to help me with code, it felt like cheating in the best possible way. I described a problem in plain English. It gave me working code in seconds. I integrated it, it worked, I moved on.

That speed is real. That efficiency is real. If you're a junior dev and you're not using AI tools at all, you're probably moving slower than you need to.

But here's the thing about superpowers in movies — they always come with a cost the hero doesn't notice until a critical moment. And for a lot of junior devs right now, that cost is silently compounding in the background.

What's Actually Happening When You Over-Rely on AI

When you ask AI to write your code, explain your error, and structure your logic — every single time, without stopping to struggle first — you're skipping something that has no shortcut.

You're skipping the part where your brain builds the map.

Learning to code isn't just about collecting solutions. It's about building a mental model of how things connect. Why this pattern exists. What breaks when you do it differently. Why the error says what it says.

That mental model only gets built through friction. Through sitting with a problem long enough that your brain has to construct a path. Through being wrong, running it, seeing it fail, and figuring out why.

When AI removes all the friction, it also removes all the map-building.

You end up with a project full of code that works. And a brain full of gaps that don't show up until someone asks you to think without a safety net.

The Test That Reveals Everything

There's a simple test I think every junior dev should run on themselves right now.

Close the AI. Close Stack Overflow. Open a blank file.

Now build the simplest thing you built last week. From memory. Without help.

Can you do it?

If the answer is yes — great. You're using AI as a tool and you're still the one doing the thinking.

If the answer is "I don't even know where to start" — that's not a skill level problem. That's a dependency problem. And it's worth taking seriously.

I ran this test on myself after that interview. The results were uncomfortable. I could describe what the code should do. I couldn't write it without reaching for help every three minutes.

That's not a junior dev using AI well. That's a junior dev who learned to prompt AI well. Those are not the same thing.

Why Nobody Talks About This

Part of why this conversation doesn't happen enough is that the output looks identical.

Your code works. Your project runs. Your GitHub is active. From the outside — and honestly, from the inside too — everything looks fine.

The gap only becomes visible in high-pressure moments. An interview. A pair programming session. A production bug at 2am when the AI gives you three different conflicting answers and you need to actually understand what's happening to fix it.

That's when you find out what you actually know versus what you only knew how to ask for.

I'm Not Saying Stop Using AI

That would be a ridiculous take and I won't make it.

AI is here. It's useful. The developers who learn to work with it effectively will have a real edge. That's just true.

But there's a version of using AI that makes you better — and a version that quietly replaces your thinking without you noticing.

The version that makes you better looks like this:

You try first. You sit with the problem for at least fifteen minutes. You form a hypothesis. You write something, even if it's wrong. Then you ask AI — not for the answer, but to check your reasoning, fill a specific gap, or explain why your approach broke.

The version that hollows you out looks like this:

You see the problem. You open AI. You paste the output. You move on.

One of those builds a developer. The other builds someone who can only code when the internet is on.

The Uncomfortable Question

If you're a junior dev reading this — and I'm talking to the version of you that's being honest right now, not the version that's performing confidence online — ask yourself this:

When was the last time you solved something hard completely on your own?

Not with AI. Not with Stack Overflow. Not with a YouTube tutorial open in the background.

Just you, the problem, and enough patience to sit with the discomfort until something clicked.

If you can remember that moment clearly, you're probably okay.

If you're struggling to remember the last time it happened — that's the answer.

The junior dev who never has to Google anything isn't a 10x developer.

They might just be someone who got very good at delegating their thinking.

And that's worth examining — before an interview, a job, or a real production problem does it for you.

Drop your honest answer in the comments. When was the last time you solved something without AI? I'm genuinely asking — not to judge, because I had to think hard about my own answer too.

AI Is the GPS That Made Me Forget How to Read a Map" — you can still get anywhere, but you couldn't explain how

Aalaa Fahiem — Tue, 02 Jun 2026 17:53:24 +0000

AI Is the GPS That Made Me Forget How to Read a Map

There's a moment I keep having.

I open a problem. A bug, a blank component, a feature I need to figure out. And before I've even read it fully — before my brain has had five seconds to actually think — my hand is already moving.

Tab. New chat. Paste.

And the worst part? I don't even notice I'm doing it anymore.

It happened again last week. I was staring at a layout bug. Nothing serious. The kind of thing I've fixed a hundred times. But something felt uncomfortable about just... sitting with it. About not knowing the answer immediately. So I opened the prompt box. Typed the problem. Got the fix.

It worked. I moved on.

But later, I kept thinking: did I just solve that? Or did I just collect the solution?

Because those two things used to feel the same. Now I'm not sure they are.

The GPS Thing

I want to talk about GPS for a second. Because I think it's the most honest comparison I've found for what's happening to us.

Before GPS, getting somewhere new was an experience. You looked at a map. You planned a route. You made a wrong turn, figured out where you went wrong, corrected it. By the time you arrived, you knew how you got there. You could describe it. You could do it again without help.

Now? I can get to almost any address in my city. But if you took my phone away and asked me to explain the route, I genuinely couldn't. I know the destination. I have no idea about the journey.

GPS didn't make me a worse driver. I'm probably a faster one. But it quietly outsourced the part of navigation that builds spatial memory. And I didn't notice it happening until the moment I needed that memory and it wasn't there.

AI did the same thing to my thinking. And I let it.

When Did the Discomfort Start Feeling Wrong?

Here's what I've been sitting with.

There used to be a feeling at the start of a hard problem. A kind of productive discomfort. Not panic — just that low hum of I don't know yet, but I'm going to figure this out. That feeling was the start of actual thinking. Of following a thread. Of making mistakes and learning something real from them.

I don't feel that as often anymore.

Now the discomfort arrives and almost immediately I'm looking for somewhere to put it. Somewhere that will take it away fast. And the prompt box is always right there. Patient. Instant. Never annoyed that I asked again.

The problem isn't that I use AI. The problem is that I've started treating uncertainty like a bug to be fixed instead of a process to be experienced.

And that shift happened so slowly I didn't see it until I was already on the other side of it.

The Part That Actually Scared Me

A few months ago, a friend asked me to explain how something worked. Not to build it. Just to explain it.

Something I'd used in three projects. Something I'd shipped to production. Something I thought I understood.

And I opened my mouth, and... the explanation wasn't there. I knew it worked. I'd seen it work. But I'd never actually built the understanding. I'd just collected outputs and moved on.

I went home and asked AI to explain it to me. It did. Clearly. In about forty seconds.

And I thought: I've been using this thing for months, and this is the first time I've actually understood it.

That was uncomfortable in a different way. Not the productive kind.

Are We Using AI, or Just Renting Thinking?

This is the question I keep coming back to.

Because there are two very different things you can do with AI.

You can use it as a tool. Something you reach for after you've thought, when you're stuck, when you need a second opinion, when you want to move faster on something you already understand. That version of AI is genuinely powerful. It amplifies what you already have.

Or you can use it as a shortcut past the thinking entirely. Skip the discomfort. Go straight to the answer. Never sit with not-knowing long enough for anything to stick.

That version is seductive because it works. You still ship. You still get the answer. The output is the same.

But something is different on the inside. And over time, that difference adds up.

The GPS gets you to the destination either way. But only one version of the journey leaves you knowing where you are.

The Anxiety Nobody Talks About

Here's the thing I haven't seen many people admit.

There's a specific anxiety that comes with not having the prompt box open. A restlessness. A sense of exposure. Like you're working without a safety net and something could go wrong at any moment.

That feeling is new. I didn't have it three years ago. Back then, not knowing something immediately just meant you didn't know it yet. It was a normal part of thinking.

Now not-knowing feels like a problem to be solved in seconds. And the seconds are ticking.

I think that anxiety is worth paying attention to. Not because AI is bad. But because that feeling is information. It's telling you something about what you've quietly outsourced — and whether you're okay with that.

I'm still figuring out my own answer.

The Question Worth Asking Yourself

Not "should I use AI less?" That's not a useful question. AI isn't going anywhere and neither is its usefulness.

The better question is:

When you close the prompt box and sit with a problem alone — how long before the discomfort becomes unbearable?

Ten minutes? Two? Thirty seconds?

Because that window — the time between opening a problem and reaching for AI — that's where your actual thinking lives. That's where you build the spatial memory. That's where the understanding that sticks gets made.

If that window is shrinking, it's worth noticing.

That's all. Just noticing.

Two Things I'm Trying (Not Advice, Just Honest)

I set a "think first" timer. Ten minutes. Problem open. No AI. Just me and the discomfort. Sometimes I solve it. Sometimes I don't. But every time, I show up to the AI with a much better question — and I actually understand the answer when it comes.

I ask AI to explain, not just solve. Instead of "fix this," I've started asking "explain why this is broken." It takes longer. The answer is less clean. But something actually transfers.

Neither of these is a cure. I still reach for the prompt box too fast sometimes. Probably today.

But at least now I notice when I do it.

So here's the open question I'll leave you with:

Are you using AI to go further than you could alone? Or are you using it to avoid the part of the journey where the real learning happens?

Both are honest answers. Neither is comfortable.

Drop yours in the comments. I'm genuinely curious which one you'll admit to. 👇

That Weird `{ }` After Button? I Had No Idea What I Was Actually Writing{Lambda function}

Aalaa Fahiem — Tue, 19 May 2026 13:31:43 +0000

I remember the first time I looked at a Button in Jetpack Compose.

Button(onClick = { doSomething() }) {
    Text("Click me")
}

I typed it. It worked. I moved on.

But I had a question I was too embarrassed to ask out loud: why are there two sets of curly braces here? What is that second block doing floating there after the closing parenthesis? Is that even valid Kotlin?

I copy-pasted it from the docs, trusted it, and kept going.

Then one day I tried to write my own composable that accepted a click listener. I wrote it like this:

@Composable
fun MyButton(label: String, onClick: () -> Unit) {
    Button(onClick = onClick) {
        Text(label)
    }
}

And I called it like this:

MyButton(label = "Submit", onClick = { handleSubmit() })

It worked. But then a teammate showed me I could also call it like this:

MyButton(label = "Submit") { handleSubmit() }

I stared at that for a long time. Where did onClick = go? Why did the lambda just... float outside? Was this some kind of shortcut? Was I missing something?

That was the day I stopped ignoring lambdas and actually learned them.

First, What Even Is a Lambda?

Before Compose, before callbacks — let's go back to basics.

A lambda is simply a function that has no name. That's it. Instead of declaring a full function with fun, you write the logic inline, right where you need it.

Here's a normal function:

fun greet(name: String): String {
    return "Hello, $name"
}

Here's the exact same thing as a lambda:

val greet = { name: String -> "Hello, $name" }

Same logic. No name declaration. No return keyword — the last expression is returned automatically. You store it in a variable, or you pass it directly somewhere else.

That's a lambda.

Function Types: What You're Actually Passing Around

When you write () -> Unit, you're not writing magic. You're writing a type.

Just like String is a type, or Int is a type — () -> Unit is the type of a function that takes no parameters and returns nothing.

Let's break the pattern down:

(parameters) -> ReturnType

So:

() -> Unit — takes nothing, returns nothing
(String) -> Unit — takes a String, returns nothing
(Int) -> Boolean — takes an Int, returns a Boolean
(String, Int) -> String — takes a String and an Int, returns a String

In Compose, you'll see () -> Unit constantly. Every onClick, every onDismiss, every onNavigate — they all have this type because they just do something when triggered, they don't return a value.

The Trailing Lambda — The Thing That Confused Me

Here's the rule that explains everything:

In Kotlin, if the last parameter of a function is a lambda, you can move it outside the parentheses.

That's it. That's the whole thing.

So this:

Button(onClick = { doSomething() }, content = { Text("Click me") })

Can be written as this:

Button(onClick = { doSomething() }) {
    Text("Click me")
}

Because content is the last parameter, Kotlin lets you pull it outside. And if there's only one lambda parameter and it's the last one, you can even drop the parentheses entirely:

Column(modifier = Modifier.fillMaxSize()) {
    Text("Hello")
}

This is called a trailing lambda. It's not a different feature — it's just syntax sugar that Kotlin gives you for cleaner-looking code. And once you know it exists, you'll see it absolutely everywhere in Compose.

Lambdas as Event Callbacks: Starting Simple

Now let's see this in a real Compose context.

The simplest example is Button:

@Composable
fun MyScreen() {
    Button(onClick = { Log.d("TAG", "Button clicked!") }) {
        Text("Click me")
    }
}

The onClick parameter has the type () -> Unit. You're passing a lambda — an anonymous function — directly inline. When the button is tapped, Compose calls your lambda.

Now what if you want to do something more meaningful when the button is clicked — like navigate or update state? You lift the logic out:

@Composable
fun MyScreen(onNavigate: () -> Unit) {
    Button(onClick = onNavigate) {
        Text("Go to next screen")
    }
}

Now the screen doesn't decide what happens on click. It just says "when clicked, call whatever you gave me." The caller decides the behavior. That's the entire power of passing functions as parameters.

Leveling Up: Custom Composables with Callbacks

This is where it gets interesting.

Imagine you're building a list of items. Each item has a name, and when the user taps one, you want to do something with it. Here's how that composable might look:

@Composable
fun PokemonItem(
    name: String,
    onItemClick: (String) -> Unit
) {
    Card(
        modifier = Modifier
            .fillMaxWidth()
            .clickable { onItemClick(name) }
            .padding(8.dp)
    ) {
        Text(
            text = name,
            modifier = Modifier.padding(16.dp)
        )
    }
}

Notice onItemClick: (String) -> Unit. This lambda takes a String and returns nothing. When the card is tapped, it calls the lambda with the Pokémon's name.

Now the screen that uses this composable decides what to do with that name:

@Composable
fun PokemonListScreen(onNavigateToDetail: (String) -> Unit) {
    val pokemonList = listOf("Pikachu", "Charizard", "Bulbasaur")

    LazyColumn {
        items(pokemonList) { pokemon ->
            PokemonItem(
                name = pokemon,
                onItemClick = { selectedName ->
                    onNavigateToDetail(selectedName)
                }
            )
        }
    }
}

Or using trailing lambda syntax, even shorter:

PokemonItem(name = pokemon) { selectedName ->
    onNavigateToDetail(selectedName)
}

Same result. The PokemonItem composable knows nothing about navigation. It just knows it should call onItemClick when tapped. What happens next is someone else's responsibility.

That separation is not just clean — it makes your composables reusable anywhere.

One More Thing: Lambdas and Recomposition

Here's something most beginner articles skip — and it actually matters.

Every time Compose recomposes a screen, it re-executes the composable function. That means every lambda you write inline gets recreated on every recomposition.

For most cases, this is totally fine. But once you start passing lambdas deep into a component tree, or using them inside performance-sensitive composables, this can cause unnecessary recompositions in child components.

The solution Compose gives you is remember with lambdas:

val onClickAction = remember {
    { /* do something */ }
}

Or for lambdas that depend on state:

val onItemClick: (String) -> Unit = remember(viewModel) {
    { name -> viewModel.onPokemonSelected(name) }
}

This tells Compose: "don't recreate this lambda unless viewModel changes."

You don't need to do this everywhere from day one. But knowing it exists means when you eventually run into a recomposition issue, you'll know where to look.

The Mental Model That Tied It All Together

When I finally understood lambdas in Compose, I stopped seeing them as confusing syntax and started seeing them as the language of events.

Every tap, every input change, every navigation action — they're all just functions being passed around. Your composables don't handle what happens. They just say: "when this occurs, call whatever you gave me."

That's the real reason Compose is designed this way. It keeps each composable focused on one job: rendering. The rest is handled by whoever calls it.

Summary

Concept	What It Means
Lambda	A function with no name, written inline
`() -> Unit`	A function type: takes nothing, returns nothing
`(String) -> Unit`	A function type: takes a String, returns nothing
Trailing lambda	When the last param is a lambda, move it outside `()`
Callback pattern	Passing lambdas down so composables can report events up
`remember { lambda }`	Prevents unnecessary recomposition from lambda recreation

If any part of this clicked for you, or if you've been silently confused about the same thing — drop a comment. I'm still learning too, and honestly, the best thing about writing these articles is finding out I wasn't the only one who didn't get it at first.

I Had No Idea How My Screens Were Talking to Each Other. Then I Learned Compose Navigation.

Aalaa Fahiem — Mon, 18 May 2026 14:49:52 +0000

Let me be honest with you.

The first time I tried to navigate between two screens in Jetpack Compose, I copy-pasted code from Claude, it worked, and I moved on. I had zero idea what NavHost, NavController, or BackStack actually meant.

Then my app had 5 screens. Then 8. Then I needed to pass data between them. Then everything broke, and I finally had to sit down and actually learn this.

This article is what I wish someone had explained to me back then.

We're building a simple e-commerce app — Product List → Product Detail → Cart — and we're going to understand every single line of navigation code we write. No copy-pasting in the dark this time.

First, What Does "Navigation" Even Mean?

Before we write a single line of code, let's make sure we actually understand what's happening.

Imagine your phone screen is a stack of physical cards on a table:

You open the app → the first card (Product List) is placed on the table.
You tap a product → a new card (Product Detail) is placed on top of the first one.
You press back → that top card is removed, and you see the Product List again.

That pile of cards? That's your Back Stack.

Android manages this stack automatically. Your job is just to tell it: "add this screen" or "remove the top one." That's navigation.

Simple. Let's build it.

🔧 Setup

Add this dependency to your build.gradle.kts (app level):

dependencies {
    implementation("androidx.navigation:navigation-compose:2.9.0")
}

Sync and you're ready.

Meet the 3 Players

Compose Navigation has three key pieces. Think of them like a team with very specific roles:

Who	What They Do
`NavController`	The pilot — decides where you go
`NavHost`	The airport — the container that holds all destinations
`composable()`	The gate — registers each screen as a destination

Let's see them in action.

`rememberNavController()`

This creates your NavController and keeps it alive across recompositions:

val navController = rememberNavController()

Think of this as creating the remote control for your whole app's navigation.

`NavHost` + `composable()`

This is where you declare every screen your app has:

NavHost(
    navController = navController,
    startDestination = "product_list"
) {
    composable("product_list") { ProductListScreen() }
    composable("product_detail") { ProductDetailScreen() }
    composable("cart") { CartScreen() }
}

startDestination is just the screen that shows up first when the app launches. Everything else gets added when the user navigates there.

That's the whole system. Now let's make it production-quality.

Stop Hardcoding Strings — Use a Sealed Class

Right now, our routes are raw strings like "product_list".

Here's the problem: you'll use that string in multiple places — the NavHost, the navigate call, the popBackStack call... One typo anywhere? App crashes at runtime with zero help from the compiler.

The fix is a sealed class that acts as a single source of truth for all your routes:

sealed class Screen(val route: String) {

    object ProductList : Screen("product_list")
    object Cart : Screen("cart")

    // Screens with arguments get their own createRoute() function
    object ProductDetail : Screen("product_detail/{productId}") {
        fun createRoute(productId: Int) = "product_detail/$productId"
    }
}

Now if you ever rename a screen, you change it in one place and every reference updates automatically. The compiler is your safety net.

Setting Up the Full NavHost

With the sealed class in place, your NavHost becomes clean and readable:

@Composable
fun AppNavigation() {
    val navController = rememberNavController()

    NavHost(
        navController = navController,
        startDestination = Screen.ProductList.route
    ) {

        composable(Screen.ProductList.route) {
            ProductListScreen(navController)
        }

        composable(
            route = Screen.ProductDetail.route,
            arguments = listOf(
                navArgument("productId") { type = NavType.IntType }
            )
        ) { backStackEntry ->
            val productId = backStackEntry.arguments?.getInt("productId") ?: 0
            ProductDetailScreen(productId = productId, navController = navController)
        }

        composable(Screen.Cart.route) {
            CartScreen(navController)
        }
    }
}

Notice how ProductDetail declares an arguments list — that's how you tell the NavHost "hey, this screen expects some data to arrive with it."

Navigating to a Screen

Now let's make the user actually go somewhere. When a product is tapped in the list, we navigate to its detail screen:

@Composable
fun ProductListScreen(navController: NavController) {

    val products = listOf(
        Product(id = 1, name = "Air Max 90", price = 120.0),
        Product(id = 2, name = "Jordan 1 Retro", price = 180.0),
        Product(id = 3, name = "New Balance 550", price = 95.0)
    )

    LazyColumn {
        items(products) { product ->
            ProductItem(
                product = product,
                onClick = {
                    // 👇 This is all navigation is — "go here"
                    navController.navigate(Screen.ProductDetail.createRoute(product.id))
                }
            )
        }
    }
}

createRoute(product.id) produces "product_detail/1" — it fills in the argument in the route template. Clean, no string manipulation in your UI code.

Passing Data: The Simple Way (ID)

The golden rule of navigation: pass the minimum data needed.

Usually that's just an ID. The receiving screen fetches the full data using that ID (from a ViewModel, a repository, wherever). This is the officially recommended approach.

@Composable
fun ProductDetailScreen(
    productId: Int,
    navController: NavController,
    viewModel: ProductViewModel = hiltViewModel()
) {
    // Fetch the full product using the ID
    val product by viewModel.getProduct(productId).collectAsState()

    Column(modifier = Modifier.padding(16.dp)) {
        Text(
            text = product?.name ?: "Loading...",
            style = MaterialTheme.typography.headlineMedium
        )
        Text(text = "$${product?.price}")

        Spacer(modifier = Modifier.height(16.dp))

        Button(
            onClick = { navController.navigate(Screen.Cart.route) }
        ) {
            Text("Add to Cart 🛒")
        }
    }
}

ID goes in → ViewModel fetches the product → UI shows it. Simple and predictable.

Going Back

Three flavors of going back, depending on what you need:

// 1. Go back one screen — the most common case
navController.popBackStack()

// 2. Go back to a specific screen (keeps it in the stack)
navController.popBackStack(
    route = Screen.ProductList.route,
    inclusive = false  // false = keep ProductList on the stack, land on it
)

// 3. Go back and clear everything including the destination
navController.popBackStack(
    route = Screen.ProductList.route,
    inclusive = true  // true = remove ProductList too (useful for login → home flows)
)

The inclusive flag is the one that trips everyone up. A simple way to remember it:

inclusive = false → "go back TO this screen"
inclusive = true → "go back PAST this screen"

🧩 The Complete Picture

Let's look at everything together. Here's your final AppNavigation.kt:

@Composable
fun AppNavigation() {
    val navController = rememberNavController()

    NavHost(
        navController = navController,
        startDestination = Screen.ProductList.route
    ) {

        composable(Screen.ProductList.route) {
            ProductListScreen(navController)
        }

        composable(
            route = Screen.ProductDetail.route,
            arguments = listOf(
                navArgument("productId") { type = NavType.IntType }
            )
        ) { backStackEntry ->
            val productId = backStackEntry.arguments?.getInt("productId") ?: 0
            ProductDetailScreen(
                productId = productId,
                navController = navController
            )
        }

        composable(Screen.Cart.route) {
            CartScreen(navController)
        }
    }
}

And your sealed class:

sealed class Screen(val route: String) {
    object ProductList : Screen("product_list")
    object Cart : Screen("cart")
    object ProductDetail : Screen("product_detail/{productId}") {
        fun createRoute(productId: Int) = "product_detail/$productId"
    }
}

That's a complete, production-ready navigation setup. No magic. No mystery.

The next time someone mentions the Back Stack, NavHost, or sealed class routes — you'll know exactly what they mean and why it's set up that way.

What are you building with Compose Navigation? Drop it in the comments 👇

And if this saved you from a Claude rabbit hole, share it with the Android dev who needs it right now. 🙌

How Sealed Classes Make Navigation Safer in Jetpack Compose

Aalaa Fahiem — Tue, 12 May 2026 15:44:45 +0000

I spent forty minutes debugging a screen that refused to open.

The app compiled fine. No red errors anywhere. I'd tap the button, nothing would happen — no crash, no error, just silence. I checked the click listener. I checked the composable. I checked the NavHost. Everything looked right.

Then I found it.

// Where I registered the screen
composable("pokemonDetails") { ... }

// Where I was navigating to
navController.navigate("pokemondetails")

One lowercase letter. Details vs details. Forty minutes.

And the worst part? The compiler had no idea. It saw two strings and had nothing to say about it. From Kotlin's perspective, both lines were perfectly valid code.

That was the day I stopped trusting navigation strings — and started learning about sealed classes.

The Way Everyone Starts: Raw Strings

When you first build navigation in Jetpack Compose, this feels completely natural:

NavHost(navController, startDestination = "home") {
    composable("home") { HomeScreen() }
    composable("profile") { ProfileScreen() }
    composable("settings") { SettingsScreen() }
}

And navigating around:

navController.navigate("profile")
navController.navigate("settings")

It works. For a small app with three screens, it's fine. You can see all the strings at a glance, they're short, and refactoring is easy enough.

But this approach has a silent flaw built into it from day one: Kotlin has no idea what "profile" means. To the compiler, it's just a String. It could be anything. A typo, a different capitalization, a slightly different spelling — the code still compiles and the screen just silently fails to open.

You won't find out until runtime. Sometimes not until a user reports it.

The First Improvement: At Least Use Constants

The first instinct most developers have is to pull the strings into constants. It's the right instinct.

object Routes {
    const val HOME = "home"
    const val PROFILE = "profile"
    const val SETTINGS = "settings"
}

Now the NavHost looks like this:

NavHost(navController, startDestination = Routes.HOME) {
    composable(Routes.HOME) { HomeScreen() }
    composable(Routes.PROFILE) { ProfileScreen() }
    composable(Routes.SETTINGS) { SettingsScreen() }
}

And navigation:

navController.navigate(Routes.PROFILE)

This is already better. Typos in the string value only need to be fixed in one place. Autocomplete helps. Renaming a route is a single change instead of a search-and-replace across the whole project.

But this still has a real limitation — one that only shows up once your app starts to grow.

Where Constants Start Falling Apart: Arguments

Everything feels manageable until screens need to pass data to each other.

Say you're building a Pokédex app. You have a list screen and a detail screen. The detail screen needs to know which Pokémon to show. In Compose Navigation, that means route arguments:

composable("details/{pokemonName}") { backStackEntry ->
    val name = backStackEntry.arguments?.getString("pokemonName")
    PokemonDetailScreen(name)
}

And navigating to it:

navController.navigate("details/pikachu")
navController.navigate("details/charizard")
navController.navigate("details/$selectedPokemon")

Now imagine this pattern across ten screens. Profile with a userId. Post with a postId. Settings with a section parameter. You're manually building strings everywhere:

navController.navigate("profile/$userId")
navController.navigate("post/$postId")
navController.navigate("settings/$section")

Every one of these is a hand-rolled string. Every one of them can be wrong in ways the compiler will never catch. Forget the slash, get the argument name slightly wrong, pass the wrong variable — silent failure every time.

This is the moment where raw strings, even organized into constants, start genuinely hurting you.

The Shift in Thinking: Screens Are a Known, Finite Set

Here's the idea that made sealed classes click for me.

Your app has a specific, known list of screens. It's not infinite. It's not dynamic. At any point in time, the compiler could know every valid destination — if you gave it a way to represent them.

That's exactly what a sealed class does.

A sealed class says: "only these specific types can exist." No others. The compiler enforces it.

Instead of navigation being a world of arbitrary strings where anything goes, it becomes a closed, controlled system where every valid destination is explicitly defined in one place.

That's the whole idea. Not syntax. Not Kotlin trivia. A navigation architecture that makes invalid destinations impossible to express.

Building the Screen Hierarchy

Here's what that looks like in code:

sealed class Screen(val route: String) {
    data object Home : Screen("home")
    data object Profile : Screen("profile")
    data object Settings : Screen("settings")
    data class Details(val pokemonName: String) : Screen("details/{pokemonName}") {
        fun createRoute() = "details/$pokemonName"
    }
}

Let's slow down and read this carefully, because every word is doing something.

sealed class Screen(val route: String)
This is the parent. Every screen in your app is a Screen. The route property is what gets registered with the NavHost. Because it's a sealed class, nothing outside this file can create a new subtype — the set of screens is locked.

data object Home : Screen("home")
Home is a screen. It inherits from Screen, which means it automatically has a route property — and its value is "home". data object means it's a singleton. There's only ever one Home. It doesn't need arguments — it's just a destination.

data class Details(...) : Screen("details/{pokemonName}")
Details is also a screen, but it needs data. It takes a pokemonName and defines a createRoute() function that builds the actual navigation string safely — in one place, with the correct format, every time.

The visual hierarchy looks like this:

Screen
 ├── Home          (no arguments — just a destination)
 ├── Profile       (no arguments)
 ├── Settings      (no arguments)
 └── Details       (needs a pokemonName)

All of them belong to the same family. All of them have a route. None of them can be misspelled into existence.

Using It in a Real Compose NavHost

Here's the NavHost with sealed classes:

@Composable
fun AppNavigation() {
    val navController = rememberNavController()

    NavHost(
        navController = navController,
        startDestination = Screen.Home.route
    ) {
        composable(Screen.Home.route) {
            HomeScreen(
                onPokemonClick = { name ->
                    navController.navigate(Screen.Details(name).createRoute())
                }
            )
        }

        composable(Screen.Profile.route) {
            ProfileScreen()
        }

        composable(Screen.Settings.route) {
            SettingsScreen()
        }

        composable(
            route = Screen.Details("").route, // "details/{pokemonName}"
            arguments = listOf(navArgument("pokemonName") { type = NavType.StringType })
        ) { backStackEntry ->
            val name = backStackEntry.arguments?.getString("pokemonName") ?: ""
            PokemonDetailScreen(pokemonName = name)
        }
    }
}

Look at what's changed. There's not a single hardcoded string anywhere in this navigation setup. Every route comes from a Screen object. And when navigating to the detail screen:

// Before — fragile, easy to get wrong
navController.navigate("details/pikachu")

// After — safe, readable, impossible to misspell
navController.navigate(Screen.Details("pikachu").createRoute())

If you rename the screen, you change it in one place — the sealed class. Everywhere that uses Screen.Details just works.

Why `createRoute()` Is More Important Than It Looks

It's easy to look at createRoute() and think it's a tiny convenience method. It's not.

data class Details(val pokemonName: String) : Screen("details/{pokemonName}") {
    fun createRoute() = "details/$pokemonName"
}

Before this existed, every screen that navigated to Details was responsible for building the string correctly. Every single one:

// In HomeScreen
navController.navigate("details/$pokemonName")

// In SearchScreen
navController.navigate("details/$selectedPokemon")

// In FavoritesScreen
navController.navigate("details/$favoriteName")

That's three places that need to agree on the exact format of the route. Change the argument name, or add a second argument, and you're hunting through every screen that navigates to Details to update them all.

With createRoute(), there's exactly one place where the route for Details is built. Every screen calls the same function. Change the format once, it's fixed everywhere. That's encapsulation — and it's the real reason sealed classes start feeling powerful instead of just "more organized."

The Final Clean Setup (Copy-Friendly)

Here's everything together — sealed classes, NavHost, and a full navigation example using the latest versions:

// build.gradle.kts
dependencies {
    val composeBom = platform("androidx.compose:compose-bom:2026.04.01")
    implementation(composeBom)
    implementation("androidx.compose.material3:material3")
    implementation("androidx.navigation:navigation-compose:2.9.8")
}

// Screen.kt
sealed class Screen(val route: String) {
    data object Home : Screen("home")
    data object Profile : Screen("profile")
    data object Settings : Screen("settings")
    data class Details(val pokemonName: String) : Screen("details/{pokemonName}") {
        fun createRoute() = "details/$pokemonName"
    }
}

// NavGraph.kt
@Composable
fun AppNavigation() {
    val navController = rememberNavController()

    NavHost(
        navController = navController,
        startDestination = Screen.Home.route
    ) {
        composable(Screen.Home.route) {
            HomeScreen(
                onNavigateToProfile = { navController.navigate(Screen.Profile.route) },
                onPokemonClick = { name ->
                    navController.navigate(Screen.Details(name).createRoute())
                }
            )
        }
        composable(Screen.Profile.route) { ProfileScreen() }
        composable(Screen.Settings.route) { SettingsScreen() }
        composable(
            route = Screen.Details("").route,
            arguments = listOf(navArgument("pokemonName") { type = NavType.StringType })
        ) { backStackEntry ->
            val name = backStackEntry.arguments?.getString("pokemonName") ?: ""
            PokemonDetailScreen(pokemonName = name)
        }
    }
}

Plugins

Aalaa Fahiem — Sat, 25 Apr 2026 07:00:00 +0000

Every Android project I've ever opened starts the same way. Right at the top of build.gradle, before any dependencies, before any SDK versions, before anything useful — there's this:

plugins {
    id("com.android.application")
    kotlin("android")
}

I copy-pasted those two lines into every project I created for months. I never touched them. I didn't know what they did. I was honestly scared that if I looked at them too hard something would break.

And then one day I created a new project and only saw one of them:

plugins {
    id("com.android.application")
}

The kotlin("android") line was gone. Just... missing. I panicked. Googled it. Added it back. The build failed. Removed it. The build worked again.

That was the moment I realized I had absolutely no idea what a Gradle plugin even was.

If you're in the same spot — let's fix that right now.

So What Is a Gradle Plugin, Actually?

Here's the simplest mental model I could come up with:

Gradle, on its own, knows how to do general build stuff. Compile files. Run tasks. Manage dependencies. It's a general-purpose build tool.

But Gradle has no idea what an Android app is. It doesn't know what an APK is. It doesn't know about AndroidManifest, or resources, or how to sign an app for the Play Store. Out of the box, it just doesn't speak Android.

A plugin is what teaches Gradle a new language.

When you apply com.android.application, you're saying: "hey Gradle, load the Android plugin — the one that knows how to build Android apps." Suddenly Gradle understands android { } blocks, knows how to produce an APK, understands build variants, knows what a manifest is.

Without the plugin, the android { } block in your Gradle file would be gibberish. Gradle would throw an error because it has no idea what that block means.

Think of it like this: Gradle is a blank canvas. Plugins are the brushes. You can't paint without picking up a brush first.

The Two Plugins Every Android App Uses (Or Used To)

`com.android.application` — The Android Brush

id("com.android.application")

This is the core Android plugin. It's what makes your module an app rather than just a bunch of Kotlin files. It adds:

The ability to produce an APK or App Bundle
The android { } configuration block
Build types (debug / release)
Support for Android resources, manifest merging, signing
Every Android-specific Gradle task you've ever seen in the Build menu

This one is non-negotiable. Every Android app module has it. Without it, Gradle doesn't know it's building an Android app at all.

There's also a close cousin: com.android.library. Same idea, but for modules that produce a .aar library instead of an installable app. If you ever split your project into multiple modules, you'll meet it.

`kotlin("android")` — The Kotlin Brush (That You Might Not Need Anymore)

kotlin("android")
// this is shorthand for:
id("org.jetbrains.kotlin.android")

This one used to teach Gradle how to compile Kotlin code for Android. Without it, Gradle only understood Java. Add it, and suddenly .kt files become valid source code it knows how to build.

Here's the twist — and why I panicked when I saw it missing:

As of Android Gradle Plugin 9.0 (released January 2026), Kotlin support is now built directly into AGP itself. You no longer need to apply kotlin("android") separately. AGP already speaks Kotlin fluently.

So if you're starting a new project today on AGP 9.1.1 (the current latest), your plugins block looks like this:

plugins {
    id("com.android.application")
    // that's it. kotlin support is already included.
}

That's not a mistake. That's not a missing line. That's just how it works now.

But — and this is important — if you open an older project or follow an older tutorial, you'll still see kotlin("android") there. It still works. AGP 9.x accepts it for backwards compatibility. It just isn't required anymore.

Before vs After: What This Actually Looks Like

❌ The old way — AGP 8.x and older tutorials

// build.gradle.kts (Project level)
plugins {
    id("com.android.application") version "8.2.0" apply false
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false
}

// build.gradle.kts (Module: app)
plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android") // you had to add this yourself
}

android {
    compileSdk = 34
    ...
    kotlinOptions {
        jvmTarget = "11"
    }
}

Two plugins. Two separate version declarations at the project level. Both needed.

✅ The new way — AGP 9.x (2026)

// build.gradle.kts (Project level)
plugins {
    id("com.android.application") version "9.1.1" apply false
    // no kotlin plugin needed here anymore
}

// build.gradle.kts (Module: app)
plugins {
    id("com.android.application") // kotlin support is built in
}

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 24
        targetSdk = 35
        versionCode = 1
        versionName = "1.0"
    }

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_11
        targetCompatibility = JavaVersion.VERSION_11
    }

    // kotlinOptions block is also optional now in AGP 9.x
}

dependencies {
    val composeBom = platform("androidx.compose:compose-bom:2026.03.00")
    implementation(composeBom)
    implementation("androidx.compose.ui:ui")
    implementation("androidx.compose.material3:material3")
    implementation("androidx.activity:activity-compose:1.10.1")
    implementation("androidx.core:core-ktx:1.16.0")
}

Cleaner. Fewer moving parts. Less to break.

The Part Nobody Explains: `apply false`

You've probably noticed this in the project-level build.gradle and wondered what it means:

// Project-level
plugins {
    id("com.android.application") version "9.1.1" apply false
}

That apply false looks backwards. Why declare a plugin and then say "don't apply it"?

Here's the reason: the project-level file is a declaration hub, not an activation point. It's saying: "this plugin exists at version 9.1.1 — I'm registering it for the whole project." But it's not turning it on yet.

The actual activation happens in the module-level file:

// Module: app
plugins {
    id("com.android.application") // no version here 
}

This way, every module in your project that needs the plugin pulls the same version — the one declared at the top. No version drift. No conflicts. One source of truth.

The flow is:

Project-level → "Here are the available plugins and their versions"
Module-level → "I want to activate this one"

The Question That Unlocks Everything

Whenever you see a plugin you don't recognize, ask one question:

What does this teach Gradle to do?

com.android.application → teaches Gradle to build an Android app com.android.library → teaches Gradle to build an Android library module kotlin("android") → used to teach Gradle to compile Kotlin (now built into AGP) com.google.devtools.ksp → teaches Gradle to run KSP (Kotlin Symbol Processing) for annotation processing com.google.dagger.hilt.android → teaches Gradle about Hilt's code generation

Every plugin has a job. It extends what Gradle can do. Once you ask that one question about any plugin you encounter, it stops being magic and starts being a tool.

Closing Thought

Plugins are just extensions. They're not magic, they're not scary, and they're not lines you paste in and pretend don't exist.

com.android.application is the single most important line in your entire project. Without it, Gradle doesn't know it's building an Android app. Everything else in your build.gradle — the SDK versions, the dependencies, the build types — only makes sense because that plugin was applied first.

Now when you see that plugins { } block at the top of a file, you won't just scroll past it. You'll know exactly what each line is doing there.

DEV Community: Aalaa Fahiem

I Thought Coroutines Were Enough. (Flow, StateFlow, MutableStateFlow)

The Problem With suspend for Live Data

What Is a Flow?

Flow Operators — Where It Gets Useful

The Problem With Regular Flow in the UI

StateFlow — Flow That Remembers

The Private/Public Pattern (Please Don't Skip This)

Collecting StateFlow in the UI

Flow vs StateFlow — The Simple Version

The Full Picture

What I Wish I Knew Earlier

My App Froze Every Time It Loaded Data. That's When I Finally Understood Coroutines.

First, Why Does the Main Thread Even Matter?

So What Even Is a Coroutine?

suspend — The One Keyword That Changes Everything

Starting a Coroutine — launch vs async

Dispatchers — Who Does the Work?

Scopes — The Lifetime of a Coroutine

Error Handling

The Mental Model

What I Wish I Knew Earlier

As a Junior Android Dev Should I Memorize All Retrofit Code or Just Ask AI?(Interview Questions)

So I asked — and the honest answer surprised me. Most juniors are afraid to raise this question. Here's what I found out.

Should You Write It All From Memory?

Zone 1 — Let AI Write It

1. Writing the API interface yourself

2. The basic Retrofit builder

3. The data flow in your head

4. What the annotations do

5. Why suspend?

Zone 3 — Understand It, Don't Memorize It

The Real Interview Questions

🟢 Easy — Answer instantly

🟡 Medium — Think 5 seconds, then answer

🔴 Hard — Bonus points if you nail these

In Android apps, we keep one Retrofit instance for the whole app and inject it wherever needed

The Complete Retrofit Lifecycle in a Real Android App

By the end, you'll understand every link in the chain!

What Is Retrofit?

The 3 Building Blocks

The Full Lifecycle, Step by Step

Step 1 — App Starts, Hilt Wakes Up

Step 2 — Hilt Builds Retrofit Once (Singleton)

Step 3 — ViewModel Is Created, Requests Data Immediately

Step 4 — Repository Calls the API and Handles Failure

Step 5 — Retrofit Builds the URL and OkHttp Sends It

Step 6 — Server Responds With JSON

Step 7 — Gson Converts JSON Into Kotlin Objects

Step 8 — Result Flows Back Up, Wrapped in a Sealed Class

Step 9 — ViewModel Updates State, Compose Redraws

The Full Chain, Visualized

Jetpack Compose Navigation(Interview Prep)

I Thought Passing Data Between Screens Would Be Easy. It Was Not.

The Junior Dev Who Never Had to Google Anything — Is That a Superpower or a Problem?

The Superpower Feeling Is Real

What's Actually Happening When You Over-Rely on AI

The Test That Reveals Everything

Why Nobody Talks About This

I'm Not Saying Stop Using AI

The Uncomfortable Question

AI Is the GPS That Made Me Forget How to Read a Map" — you can still get anywhere, but you couldn't explain how

AI Is the GPS That Made Me Forget How to Read a Map

The GPS Thing

When Did the Discomfort Start Feeling Wrong?

The Part That Actually Scared Me

Are We Using AI, or Just Renting Thinking?

The Anxiety Nobody Talks About

The Question Worth Asking Yourself

Two Things I'm Trying (Not Advice, Just Honest)

That Weird `{ }` After Button? I Had No Idea What I Was Actually Writing{Lambda function}

First, What Even Is a Lambda?

Function Types: What You're Actually Passing Around

The Trailing Lambda — The Thing That Confused Me

Lambdas as Event Callbacks: Starting Simple

Leveling Up: Custom Composables with Callbacks

One More Thing: Lambdas and Recomposition

The Mental Model That Tied It All Together

Summary

I Had No Idea How My Screens Were Talking to Each Other. Then I Learned Compose Navigation.

The Problem With `suspend` for Live Data

`suspend` — The One Keyword That Changes Everything

Starting a Coroutine — `launch` vs `async`

5. Why `suspend`?

`rememberNavController()`

`NavHost` + `composable()`

Why `createRoute()` Is More Important Than It Looks

`com.android.application` — The Android Brush

`kotlin("android")` — The Kotlin Brush (That You Might Not Need Anymore)

The Part Nobody Explains: `apply false`