DEV Community: Aalaa Fahiem

I Didn't Memorize the Android ViewModel, I Derived It From 8 Problems( Interview Prep)

Aalaa Fahiem — Thu, 16 Jul 2026 12:24:22 +0000

Every ViewModel tutorial I read handed me the finished file: @HiltViewModel, a private MutableStateFlow, a public StateFlow, viewModelScope.launch, a sealed class. It compiled. I copied it. I understood nothing.

The problem with starting from finished code is that it looks arbitrary. Why two properties instead of one? Why init? Why start at Loading?

So I did it backwards. I threw the code away and asked: what problems is this thing actually solving? There are 8. Stack the 8 answers and the file writes itself — nothing in it is a style choice.

Here's the version I wish I had.

The 6-year-old version

Imagine a whiteboard on the wall of a room. Anyone in the room can read the whiteboard, but only you hold the marker. When you change what's written, everyone looking at it instantly sees the new thing — nobody has to keep asking "did it change yet?"

That whiteboard is StateFlow. The rule that only you hold the marker is why there are two properties instead of one. And the whiteboard hangs on the wall (the ViewModel), not on a person — so when someone leaves the room, the writing survives.

Now the real thing.

First: what can a screen actually be doing?

Before the ViewModel, one observation: a list screen is always in exactly one of three situations. It's loading, it succeeded, or it failed. That's it.

sealed interface PokemonListUiState {
    object Loading : PokemonListUiState
    data class Success(val pokemon: List<PokemonResult>) : PokemonListUiState
    data class Error(val message: String) : PokemonListUiState
}

sealed means closed set — "these are the only 3, nothing else can join." The compiler knows the complete list, so when the screen does when (state), it forces you to handle all three. You can't forget the error case.

Why not an enum? Because each case carries different cargo: Success holds a list, Error holds a message, Loading holds nothing. Enums can't do that cleanly. And notice Loading is an object, not a data class — it carries no data, so one shared instance is enough.

Now, the 8 problems.

Problem 1: The screen is fragile

Rotate the phone and Android destroys and rebuilds your screen. If the screen held the data, it's gone — you'd refetch from the network on every rotation. You need something that outlives the screen.

Solution: a ViewModel. That is literally its entire job.

class PokemonListViewModel : ViewModel()

Problem 2: The ViewModel needs a repository — but shouldn't build one

Building one means building Retrofit, which means OkHttp, which means a connection pool… all to ask for a list of Pokémon. We just want to ask for the thing, not assemble it.

Solution: let Hilt hand it over.

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

Note it asks for PokemonRepository — the interface, not the implementation. The ViewModel shouldn't know or care whether that data came from the network or a local database.

Problem 3: The data arrives LATER — how does the screen find out?

The screen already drew itself while the network was still working. Two options: the screen keeps polling ("done yet? done yet?"), or the screen subscribes and gets told.

Solution: hold the state in something watchable.

MutableStateFlow<PokemonListUiState>(...)

Set .value and everyone watching is instantly notified. Push, not poll. That's the whiteboard.

Problem 4: But if the screen can watch it, can it also change it?

That would be a disaster. Any screen could write garbage: viewModel.uiState.value = Success(fakeList). State would mutate from anywhere in the app, and when a bug shows up you'd have to hunt every file that might have written to it.

Solution: expose reading, hide writing.

private val _uiState = MutableStateFlow<PokemonListUiState>(PokemonListUiState.Loading)
val uiState: StateFlow<PokemonListUiState> = _uiState.asStateFlow()

MutableStateFlow has a settable .value. asStateFlow() returns a read-only view of the same data — no setter exposed. Now there is exactly one place in the codebase where state can change: inside this ViewModel. That single source of truth is the real payoff — it's a debuggability feature.

This is the answer to "why two properties instead of one."

Problem 5: When should the fetch start?

The moment the user opens the screen. Not on a button press, not later.

Solution: run it the instant the ViewModel is born.

init { ... }

Problem 6: The repository function is `suspend` — you can't just call it

suspend functions only run inside a coroutine. But which coroutine? Pick a long-lived scope (like GlobalScope) and the coroutine keeps running after the user has left the screen — holding references, updating state for something that no longer exists. That's a memory leak.

Solution: use a scope whose life is tied to the ViewModel's.

viewModelScope.launch { ... }

Two words worth separating: scope = where the coroutine lives (viewModelScope, which Android auto-cancels when the ViewModel dies). builder = what starts it (launch). You don't create the scope; the library hands you one pre-wired to the right lifetime.

Problem 7: The network can fail

No wifi. Server down. Timeout.

Solution: try it, and if it explodes, catch it and show the failure instead of crashing.

try { ... } catch (e: Exception) { ... }

Problem 8: What does the user stare at before the answer arrives?

A blank screen? An empty list?

Solution: start the state at Loading, before anything happens.

MutableStateFlow<PokemonListUiState>(PokemonListUiState.Loading)

The user sees a spinner instantly, and it's the truth: "I'm working on it."

Stack the 8 and the file writes itself

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

    private val _uiState = MutableStateFlow<PokemonListUiState>(PokemonListUiState.Loading)
    val uiState: StateFlow<PokemonListUiState> = _uiState.asStateFlow()

    init {
        viewModelScope.launch {
            _uiState.value = try {
                val response = repository.getPokemonList(limit = 20, offset = 0)
                PokemonListUiState.Success(response.results)
            } catch (e: Exception) {
                PokemonListUiState.Error(e.message ?: "Something went wrong")
            }
        }
    }
}

Read it as a sentence: survive the screen → ask for the repo → hold state watchably → hide the writing → start at Loading → fetch at birth → in a scope that dies with you → handle failure. Not one line is arbitrary.

Gotchas I hit

"MutableStateFlow makes it survive rotation." Nope — I merged two separate jobs. The ViewModel survives (Problem 1). StateFlow notifies (Problem 3). They just happen to live in the same file.
Loading vs Success(emptyList()). I thought Loading existed to prevent a crash. It doesn't — nothing would crash. It's about not lying to the user. Loading means "I'm working." Success(emptyList()) means "I finished and found zero Pokémon." Those are completely different claims, and one of them is false before the network answers.
e.message is nullable. Error(e.message) won't compile against a String. You need a fallback: e.message ?: "Something went wrong".
Exposing the mutable flow "just for now." The moment it's public, state can change from anywhere, and your single source of truth is gone. It never stays "just for now."

Interview-ready takeaways

Q: Why two properties — a private _uiState and a public uiState?
So the screen can read state but never write it. asStateFlow() exposes a read-only view of the same data, keeping the ViewModel the single place state can change. With one public MutableStateFlow, any file could mutate it and bugs become untraceable.

Q: Why viewModelScope.launch and not GlobalScope.launch?
viewModelScope is auto-cancelled when the ViewModel is destroyed. GlobalScope outlives the screen — the coroutine keeps running and holding references for a screen the user already left. That's a memory leak.

Q: Why start at Loading instead of Success(emptyList())?
Because you haven't succeeded yet — you haven't even asked. Success(emptyList()) tells the user "done, found nothing," which is a lie. Loading says "I'm working," which is true, and gives them a spinner instead of a fake-empty screen.

Q: Why a sealed interface for UiState instead of an enum or booleans?
Sealed = closed set, so when is exhaustive and you can't forget a state. Unlike an enum, each case carries its own data (Success → a list, Error → a message). Unlike isLoading/isError booleans, you can't represent impossible combinations like loading and error at once.

TL;DR

A ViewModel isn't a pile of ceremony — it's 8 answers stacked. Survive rotation (ViewModel), get dependencies handed to you (Hilt), make state watchable (StateFlow), keep the marker to yourself (private mutable + public read-only), start honest (Loading), fetch on birth (init), stay in a scope that dies with you (viewModelScope), and expect failure (try/catch).

Memorize the why of each. Look up the syntax — nobody remembers how to spell asStateFlow().

I'm Starting the 100 Days of Cloud Challenge and I Don't Want to Do It Alone

Aalaa Fahiem — Thu, 09 Jul 2026 13:43:06 +0000

Let me be honest with you.
I'm an Android engineer. Kotlin is my home. Jetpack Compose is where I live. The cloud has always felt like someone else's territory — the backend people, the DevOps people, the people who actually know what a VPC is.
But I'm building something that needs a cloud backend. And I applied for something that reminded me: the gap between "I should learn cloud" and "I am learning cloud" is just a decision.
So I made the decision. And now I need a friend.
At First thank you @hemapriya_kanagala that you sharing that useful source i really appreciate your effort for those Articles

What is the 100 Days of Cloud?
It's a free challenge by KodeKloud: 100 hands-on tasks covering real AWS and Azure skills — IAM, storage, networking, compute, serverless, monitoring, and more. Not videos to watch. Actual tasks in real cloud environments, with automated validation.
One task a day. Sequential. You can't skip. You can retry as many times as you need.
By day 100 you have a portfolio of 100 things you actually built, and a verified badge to show for it.
👉 https://kodekloud.com/100-days-of-cloud

Why I'm doing this
I'm building an app addressing real infrastructure in Cairo, and phase two of that project requires cloud. I'm not learning cloud as an abstract future goal. I have a specific deadline in mind.

Why I need a study buddy
Because accountability is the only thing that has ever actually made me follow through on a 100-day anything.
Not pressure. Just: "did you do today's task?" — and knowing someone else is going to ask me the same thing.
If you're an Android dev curious about cloud, a complete beginner who keeps putting this off, or honestly anyone who wants a reason to finally start — I'd love to do this alongside you.
We don't have to be at the same level. We just have to start on the same day.

Drop a comment if you're in. We'll figure out a check-in rhythm together — maybe a weekly thread, maybe just comments on each other's posts. Whatever actually works.
The start date is whenever you reply. I'll wait.

My API Functions Had No Code Inside Them. So Who Was Actually Fetching the Data? (Interview Prep)

Aalaa Fahiem — Tue, 07 Jul 2026 16:27:30 +0000

I wrote the network layer of my Pokedex app, and then I sat there staring at it, genuinely confused.

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

    @GET("pokemon/{name}")
    suspend fun getPokemonDetail(
        @Path("name") name: String
    ): PokemonDetail
}

The functions are empty. There's no code inside them. getPokemonList doesn't open a connection, doesn't send anything, doesn't parse anything. It's just a name and a return type. And yet — this is the thing that fetches every Pokemon in the app.

My first guess was wrong, so let me tell you the wrong version first, because you might be thinking it too. I thought: "maybe the data models fetch the data themselves." Then I looked at a data model:

data class PokemonResult(
    val name: String,
    val url: String
)

There's no networking code in there either. It's two empty slots. A data model can't open the internet — it's a plate, not a cook. It just holds food that someone else made.

So the puzzle stood: the interface has no body, the models can't fetch — who writes the actual networking code?

The answer: Retrofit writes it for you

Here's the mental model that fixed it for me. Think of a restaurant.

Your interface is the menu. It lists what you can order — "list of Pokemon," "one Pokemon's details." A menu doesn't contain recipes and it doesn't cook anything. It just declares what's orderable.

Retrofit is the kitchen. And this one line (which lives in your Hilt module) is where the magic happens:

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

create() reads your menu and generates a hidden class that implements your interface — a real cook. That generated class is where all the actual code lives: build the URL, attach the query parameters, hand it to OkHttp, wait for the response, pass the JSON to Gson. That generated implementation is the "body" that looked missing.

So the full chain is:

Interface — the menu. What you can request. No code.
retrofit.create() — builds the cook. This writes the real networking code, at runtime.
Gson — plates the JSON response onto your data model.
Data model — the plate. Holds the result. Never fetches anything.

You declare what to fetch. Retrofit generates the how. The models only hold the result.

How one function becomes one URL

Your baseUrl (set in Hilt) is:

https://pokeapi.co/api/v2/

Retrofit glues the @GET("...") path onto the end. Three annotations do the work:

@GET("pokemon") — the path stuck onto the base → .../pokemon
@Query("limit") limit: Int — adds ?limit=... to the URL
@Path("name") name: String — fills a {name} blank inside the path

And suspend is there because a network call takes time. suspend lets it run on a coroutine, so it never freezes the screen while it waits.

@path vs @Query — the part everyone mixes up

This confused me for a while, so here's the analogy that finally made it stick: a library.

A @Path is a book's shelf address. Every book sits at a fixed spot. If you know the spot, you walk straight to that one book. Every book has its own unique address.

pokemon/bulbasaur     ← bulbasaur is the address of one exact Pokemon

bulbasaur is baked into the path with a /. It identifies one specific thing.

A @Query is a word you hand to the search desk. There's one search desk. You fill a slip — "topic: headphones" — and the librarian searches. Tomorrow someone hands the same desk a different word. One desk, many words.

pokemon?limit=20&offset=0     ← options handed to the list endpoint

limit and offset come after the ?. They don't change which endpoint — they just tune the same list.

The rule I use now:

Does the value have its own address? → @Path (which exact thing).
Is it a word/option you hand to a shared endpoint, after a ?? → @Query.

Interview questions on the network layer

Q: Why is the Retrofit API an interface and not a class?
Because you only declare what requests exist. You don't implement them. Retrofit generates the implementation at runtime via retrofit.create().

Q: The functions have no body — where does the networking code come from?
Retrofit's create() builds a hidden class that implements the interface. That generated class contains the real code: URL building, OkHttp call, Gson parsing. The interface is just the menu.

Q: Difference between @path and @Query?
@Path fills a {placeholder} inside the URL path — it identifies one specific resource (pokemon/bulbasaur). @Query adds a ?key=value option to the URL — it tunes a request (pokemon?limit=20). Identity vs option.

Q: Why is the function suspend?
A network call is slow. suspend makes it a coroutine-friendly call that runs off the main thread, so the UI doesn't freeze while waiting. Without it, you'd block the main thread (or need a Call<T> and manual callbacks).

Q: You rename @Path("name") to @Path("pokemonName") but leave the path as pokemon/{name}. Compile error or runtime error?
Runtime. The compiler sees valid Kotlin and valid strings — it never checks that the @Path label matches the {name} blank. Retrofit checks that at runtime and throws because it can't find a placeholder named pokemonName.

Q: @GET("Pokemon") with a capital P compiles fine but returns nothing. Why didn't the compiler catch it?
Because the path is a string, and URLs are case-sensitive. The compiler doesn't validate URL strings. Pokemon ≠ pokemon, so the server returns a 404 — but only at runtime.

None of this was about memorizing Retrofit annotations. It was about one shift: you're not writing the networking code — you're writing a description that Retrofit turns into networking code. The interface is a menu. Retrofit is the kitchen. And the compiler is only checking your grammar, not your order.

Gson silent bug that Never Said a Word(Interview Prep)

Aalaa Fahiem — Sun, 05 Jul 2026 15:44:16 +0000

Here's a bug that looks impossible until you understand Gson.

You have this data class in your Pokedex app:

data class PokemonStat(
    @SerializedName("base_stat") val baseStat: Int,
    val stat: StatInfo
)

A teammate cleans up the code and deletes what looks like a redundant line:

data class PokemonStat(
    val baseStat: Int,        // @SerializedName removed
    val stat: StatInfo
)

It compiles. No red errors. He runs the app — and every Pokemon's baseStat is 0. Not the real 45 or 49. Just 0. Everywhere. And Gson never threw an error, never logged a warning, never said a single word.

If you can explain why this happens, you understand Gson better than most juniors. This is also a favorite interview question. Let's break it fully.

What Gson actually does

When the JSON comes back from the server, Gson goes key by key:

Read a key from the JSON — say base_stat.
Look for a Kotlin property with the exact same name.
Found it? Pour the value in.
Not found? Leave that property at its default value and move on.

That's the entire matching game — exact name match, or nothing.

Now look at the "cleaned up" class. The JSON key is base_stat. The Kotlin property is baseStat. Those are not the same string. Gson looks for a property called base_stat, doesn't find one, shrugs, and leaves baseStat at its default.

The default for an Int is 0. That's your bug.

@SerializedName("base_stat") was never redundant. It was the sticky note telling Gson: "this property is called baseStat in Kotlin, but look for base_stat in the JSON." Delete the note, and Gson stops matching.

Two ways to fix it:

Rename the property to base_stat — works, but breaks Kotlin's camelCase convention.
Put @SerializedName("base_stat") back — keeps the clean name and matches. This is the right one.

But why `0`? Why not a crash?

This is the part that surprised me. A missing field feels like it should be an error. It isn't.

Gson treats a missing key as allowed. It builds your object, fills the fields it found, and leaves the rest at their defaults. Think of Gson filling out a paper form: leaving a box blank is fine. It doesn't tear up the form over an empty box.

Here are the defaults you get for a missing key:

Kotlin type	Default when the key is missing
`Int`, `Long`	`0`
`Double`, `Float`	`0.0`
`Boolean`	`false`
`String`, any object, `List`	`null`

So a missing Int silently becomes 0. A missing String silently becomes null. No noise either way.

So when does Gson throw?

It's strict about two things — just not about missing keys:

Malformed JSON — the text itself is broken (a missing }, a stray comma). Like handing in a form that's been torn in half. Gson can't parse it → it throws.
Type clash — the key exists but holds the wrong type, like "base_stat": "hello" (text where an Int belongs). Like writing "banana" in the Age box. Gson tries to convert, fails → it throws.

So the rule to remember: Gson is lenient about missing data and strict about broken or wrong-typed data. A blank box is fine. A torn form or a banana-in-a-number-box is not.

The scary part: Gson vs Kotlin null-safety

Kotlin's biggest promise is null-safety. When you write:

val name: String   // no question mark

Kotlin guarantees this can never be null. The compiler enforces it. You never have to null-check it. That guarantee is the reason Kotlin kills most NullPointerException crashes.

Here's the problem: Gson doesn't respect that guarantee.

Gson doesn't build your object the normal Kotlin way. It sneaks in through reflection and shoves values straight into fields, skipping Kotlin's checks entirely. So if the JSON key is missing, Gson will quietly put null into your non-null String — no error, the "can never be null" label still sitting right there.

Then later, somewhere far away, your code does the obvious thing:

val length = pokemon.name.length   // name was secretly null

💥 NullPointerException — and it crashes nowhere near the JSON parsing that actually caused it. Good luck tracing that at 1 AM.

That's the gotcha: Kotlin promised the field could never be null, and Gson broke the promise behind its back.

This is exactly why fields that come from JSON are safer as nullable:

data class Sprites(
    @SerializedName("front_default") val frontDefault: String?   // honest
)

The ? tells Kotlin the truth — this might actually be null — so the compiler forces you to handle the empty case instead of trusting a promise Gson didn't keep. You defuse the bomb before it's armed.

The interview version

If someone asks you about Gson and Kotlin, here's the whole thing in a few lines:

Q: How does Gson match JSON to Kotlin? Exact property-name match, or @SerializedName to map a different JSON key. No match → default value.
Q: A field comes back as 0 / null and there's no error. Why? The JSON key didn't match the property name. A missing key isn't an error in Gson — the field just keeps its default (0 for Int, null for String).
Q: When does Gson actually throw? Malformed JSON, or a type mismatch — not a missing key.
Q: What's the danger with non-null Kotlin types? Gson bypasses Kotlin null-safety via reflection and can put null into a non-null field, causing a delayed crash. Model JSON fields as nullable when the API might omit them.

None of this is about memorizing Gson. It's about understanding that Gson stays silent exactly where you'd expect it to shout — and that silence is what makes these bugs sneaky.

How to derive data classes for any API

Aalaa Fahiem — Sun, 05 Jul 2026 15:06:42 +0000

Let me be honest about a mistake I made this week.

I was building the data layer of a Pokedex app. I opened the JSON from the API, and I ended up writing two data classes for the list screen — PokemonListResponse and PokemonResult. And in my head, I invented a reason for why there were two.

"One of them," I told myself, "is the data coming from the server. The other one is the data I show in the UI."

It sounded smart. It was completely wrong.

Both classes describe the server's JSON. Neither one is "the UI data." I had looked at two classes and invented a structure that wasn't there — instead of reading the structure that actually was.

That mistake taught me something more useful than the fix: you don't decide how many data classes you need. The JSON decides for you. You just have to learn to read it.

Here's the method I use now for any API.

The one rule everything comes from

Your data classes mirror the shape of the JSON.

That's it. Not "one for server, one for UI." Not a magic number someone told you. The classes are a mould shaped like the data, so Gson can pour the JSON into them. Match the shape — it works. Miss the shape — it breaks.

Everything below is just how to read the shape.

Step 0 — Look at the real JSON first

Never guess. Open the actual endpoint in your browser and stare at the real response. You cannot model a shape you haven't seen.

Here's the Pokedex list endpoint (/api/v2/pokemon?limit=20):

{
  "count": 1302,
  "results": [
    { "name": "bulbasaur", "url": "https://pokeapi.co/api/v2/pokemon/1/" },
    { "name": "ivysaur",   "url": "https://pokeapi.co/api/v2/pokemon/2/" }
  ]
}

Step 1 — Every `{ }` object becomes one data class

A curly-brace block is one mould. Count the distinct { } shapes and you've counted your classes.

In the JSON above there are two distinct shapes:

the outer { count, results }
the little { name, url } that repeats inside the list

Two shapes → two classes.

Step 2 — For each key, ask ONE question: "what's on the right?"

This is the whole skill. For every key inside an object, look at its value:

A primitive — "text", 45, true → a normal field: String, Int, Boolean
Another { } → a field whose type is another data class (a box inside a box)
A [ ] → a field of type List<X> — then look inside the brackets to find what X is

Say it out loud every time: [ ] means a list. { } means a single object. That one sentence saved me from three different bugs this week.

Step 3 — If the same shape repeats, reuse one class

The { name, url } shape shows up for every Pokemon in the list. You don't write a class per Pokemon — you write it once and use List<PokemonResult>.

Step 4 — Only model what you need

The real response also has next and previous keys. I didn't model them. Gson only fills the fields you declare and quietly ignores the rest — so take what your app uses and skip the rest.

Step 5 — Name it, and file it

Name each class after what it holds. Keep tiny helper classes in the same file as their parent; give standalone models their own file. This is only about you finding things later — the compiler doesn't care.

Watch the method build the classes

Applying steps 1–2 to that list JSON:

data class PokemonListResponse(
    val count: Int,                     // primitive → Int
    val results: List<PokemonResult>    // [ ] → List of the inner shape
)

data class PokemonResult(
    val name: String,                   // primitive → String
    val url: String
)

I didn't decide on two classes. I read two { } shapes and the classes fell out.

Now the harder one — the Pokemon detail endpoint (/api/v2/pokemon/bulbasaur), trimmed:

{
  "id": 1,
  "name": "bulbasaur",
  "sprites": { "front_default": "https://.../1.png" },
  "types":  [ { "slot": 1, "type": { "name": "grass" } } ],
  "stats":  [ { "base_stat": 45, "stat": { "name": "hp" } } ]
}

Walk it key by key with the one question:

id → primitive → Int
name → primitive → String
sprites → { } → single object → its own class Sprites
types → [ ] → List<...>, and each item is { slot, type } → a class, and type inside it is { } → another class
stats → [ ] → List<...>, same nesting story

Which produces:

data class PokemonDetail(
    val id: Int,
    val name: String,
    val sprites: Sprites,
    val types: List<PokemonType>,
    val stats: List<PokemonStat>
)

data class Sprites(
    val front_default: String?
)

data class PokemonType(
    val slot: Int,
    val type: TypeInfo        // { } → single object
)
data class TypeInfo(val name: String)

data class PokemonStat(
    val base_stat: Int,
    val stat: StatInfo        // { } → single object
)
data class StatInfo(val name: String)

Notice what happened. The list JSON was shallow, so it gave me flat classes. The detail JSON was nested, so it gave me nested classes. Same rule. Different input. Different-looking output. I used to think those were two different "approaches." They're not — it's one rule meeting two shapes.

The mental shift

The whole thing fits on a sticky note:

For each key, ask: what's on the right?
  primitive → String / Int / Boolean
  { }       → another data class
  [ ]       → List<that class>

Same shape twice? Reuse it.
Don't need it? Skip it.

I stopped asking "how many data classes does this API need?" — because that question has no answer until you look. The JSON has already decided. Your job isn't to invent the structure. It's to read it.

And the next time you catch yourself inventing a reason for why your code looks the way it does — go back and check the data. It'll tell you the truth.

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?

// 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.

// 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:

object 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:

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)
}

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:

object 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:

composable(
    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:

// 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.

DEV Community: Aalaa Fahiem

I Didn't Memorize the Android ViewModel, I Derived It From 8 Problems( Interview Prep)

The 6-year-old version

First: what can a screen actually be doing?

Problem 1: The screen is fragile

Problem 2: The ViewModel needs a repository — but shouldn't build one

Problem 3: The data arrives LATER — how does the screen find out?

Problem 4: But if the screen can watch it, can it also change it?

Problem 5: When should the fetch start?

Problem 6: The repository function is suspend — you can't just call it

Problem 7: The network can fail

Problem 8: What does the user stare at before the answer arrives?

Stack the 8 and the file writes itself

Gotchas I hit

Interview-ready takeaways

TL;DR

I'm Starting the 100 Days of Cloud Challenge and I Don't Want to Do It Alone

My API Functions Had No Code Inside Them. So Who Was Actually Fetching the Data? (Interview Prep)

The answer: Retrofit writes it for you

How one function becomes one URL

@path vs @Query — the part everyone mixes up

Interview questions on the network layer

Gson silent bug that Never Said a Word(Interview Prep)

What Gson actually does

But why 0? Why not a crash?

So when does Gson throw?

The scary part: Gson vs Kotlin null-safety

The interview version

How to derive data classes for any API

The one rule everything comes from

Step 0 — Look at the real JSON first

Step 1 — Every { } object becomes one data class

Step 2 — For each key, ask ONE question: "what's on the right?"

Step 3 — If the same shape repeats, reuse one class

Step 4 — Only model what you need

Step 5 — Name it, and file it

Watch the method build the classes

The mental shift

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

Problem 6: The repository function is `suspend` — you can't just call it

But why `0`? Why not a crash?

Step 1 — Every `{ }` object becomes one data class

The Problem With `suspend` for Live Data

`suspend` — The One Keyword That Changes Everything

Starting a Coroutine — `launch` vs `async`

5. Why `suspend`?