Forem: Aalaa Fahiem

My MainActivity Was 700 Lines Long. That's When I Finally Learned MVVM.

Aalaa Fahiem — Sun, 05 Apr 2026 15:00:59 +0000

I'm not even exaggerating with that number. 700 lines. One file. One class. Every single thing my app did — API calls, click listeners, UI updates, data formatting — all crammed into MainActivity.kt like a suitcase someone sat on to close.

It worked. Until it didn't.

The day it fell apart was when I tried to add a simple line of Code. I ended up breaking the list, the error message, and somehow the back button. I spent four hours fixing something that should've taken ten minutes.

That's when I finally stopped avoiding the word I'd been scared of since I started: architecture.

Why I Ignored It For So Long

Honestly? The word itself put me off.

Architecture. It sounds like something senior engineers debate in long meetings. Not something a beginner building their first to-do app needs to worry about.

So I kept ignoring it. Kept piling more code into my Activity. Kept telling myself I'd "refactor later."

Later never came. The code just got worse.

If you're in that same place right now — I get it. But let me tell you what nobody told me: MVVM isn't complicated. It's actually just a way of answering one question —

Who is responsible for what?

That's it. Seriously.

The Analogy That Made It Click For Me

Forget code for a second. Think about a restaurant.

When you go out to eat, there are three people involved in getting food to your table:

🍽️ The waiter takes your order and brings your food. They don't cook anything. They don't decide what's on the menu. They just deal with you.
👨‍🍳 The chef does all the actual work. Takes the order from the waiter, figures out how to prepare it, sends it back out. Never comes to your table.
📦 The stockroom has all the ingredients. The chef goes there to get what they need. You never see it. The waiter definitely doesn't go back there.

Three people. Three jobs. Nobody steps on anyone else's toes.

MVVM is exactly this:

Your View (Activity, Fragment, Composable) = the waiter. Shows things to the user. Reacts to what the user does. That's all.
Your ViewModel = the chef. Holds the logic. Decides what data to use and when. Never touches the UI directly.
Your Model (Repository, database, API) = the stockroom. Just holds and provides data. Doesn't care who's asking or why.

When I understood this, everything else fell into place.

What My Code Looked Like Before (Please Don't Judge Me)

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // calling the API straight from the Activity 💀
        CoroutineScope(Dispatchers.IO).launch {
            val users = RetrofitClient.api.getUsers()
            withContext(Dispatchers.Main) {
                adapter.submitList(users)
            }
        }
    }
}

This looks innocent. It's not.

Rotate the phone → Activity gets destroyed → coroutine gets cancelled
→ the API gets called again from scratch. Every. Single. Rotation.

Also, try writing a test for this. You can't. The networking is baked directly into the UI layer. There's no way to test the logic without spinning up the whole Activity.

I didn't even know this was a problem until it bit me.

What It Looks Like After

Here's the same feature split across three layers the right way:

The Model — just fetches data, nothing else

class UserRepository(private val api: ApiService) {
    suspend fun getUsers(): List<User> = api.getUsers()
}

The ViewModel — holds the logic and the state

class UserViewModel(private val repository: UserRepository) : ViewModel() {

    private val _users = MutableStateFlow<List<User>>(emptyList())
    val users: StateFlow<List<User>> = _users

    init { loadUsers() }

    private fun loadUsers() {
        viewModelScope.launch {
            _users.value = repository.getUsers()
        }
    }
}

The View — just watches and reacts

class MainActivity : AppCompatActivity() {

    private val viewModel: UserViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        lifecycleScope.launch {
            viewModel.users.collect { users ->
                adapter.submitList(users)
            }
        }
    }
}

Three files. Each one does one thing. The Activity has no idea how users are fetched. The ViewModel has no idea how they're displayed. And if I rotate the phone? The ViewModel is still alive — data doesn't reload, nothing breaks.

The One Thing I Wish Someone Had Told Me

The ViewModel isn't just an organizational trick. It has an actual superpower that nothing else gives you:

It survives configuration changes.

When you rotate your phone, Android destroys and recreates your Activity. This is just how Android works — it's not a bug. But if your data lives inside the Activity, it dies with it.

A ViewModel doesn't. It stays alive across rotations, theme changes, keyboard toggles — anything that would normally kill your Activity. When the Activity comes back, it reconnects to the same ViewModel that was already there, with all its data intact.

That alone is worth learning MVVM for.

The Honest Truth About Getting Started

You're not going to write perfect MVVM on your first try. I didn't. My first "MVVM" app still had logic leaking into the Activity in places. I used LiveData wrong. My Repository was doing things it shouldn't.

That's fine.

The goal isn't perfection. The goal is to stop putting everything in one place. Even a messy, imperfect separation of concerns is infinitely better than a 700-line Activity.

Start on your next project. Even a small one. Just ask yourself before writing anything: does this belong in the View, the ViewModel, or the Model?

That question alone will change how you write code.

5 Things I Wish I Knew Before Writing My First Android App

Aalaa Fahiem — Fri, 03 Apr 2026 14:06:48 +0000

This article is for beginners building their first Android app using Kotlin and Jetpack Compose.

So I decided to build an Android app. How hard could it be, right?

Turns out — pretty hard. Not impossible, but full of surprises that nobody warns you about. I'm still learning, but I've already collected a solid list of "why didn't anyone tell me this?" moments. Here are the five biggest ones.

1. Architecture Isn't Just for Big Projects

When I started, I threw everything into one file. Logic, UI, data fetching — all living together in one giant MainActivity.kt. It worked… until it didn't.

The moment I needed to change something, I'd break something else. I had no idea what MVVM (Model-View-ViewModel) was, and honestly the name scared me off.

Here's what I wish someone had told me earlier:

Architecture isn't about being fancy. It's about not hating your own code two weeks later.

Even for a small app, separating your UI (the View) from your logic (the ViewModel) makes everything easier to read, test, and fix. Start with MVVM from day one. Android Jetpack's ViewModel and StateFlow are built for this — don't ignore them.

Takeaway: Before writing a single line of UI code, ask yourself: where will the logic for this live?

2. Android Will Destroy and Recreate Your Activity — Deal With It

This one got me bad.

I had a form where users filled in their details. When I rotated the phone, everything disappeared. I panicked. I thought I had a bug. I didn't — that's just Android doing its thing.

Android destroys and recreates your Activity on configuration changes (like rotation, language change, or dark mode toggle). If you don't handle this, your app loses all its state every time.

The fix? Use a ViewModel — it survives configuration changes. Or use rememberSaveable if you're on Jetpack Compose. Either way, don't store important state directly in your Activity or Fragment and expect it to stick around.

@Composable
fun ExampleScreen(viewModel: MyViewModel = viewModel()) {
    val state by viewModel.uiState.collectAsState()

    Text(text = state.username)
}

Takeaway: The Android lifecycle is not your enemy, but it will punish you if you ignore it.

3. Android Studio and Gradle Will Humble You

I expected a smooth coding experience. What I got instead was:

Gradle syncing for 4 minutes
Mysterious build errors with no helpful message
"Invalidate Caches and Restart" becoming my most-used button

Android Studio is powerful, but it's heavy. Here's what actually helped me:

Keep Gradle and your dependencies updated, but not blindly — always check the changelog before upgrading.
Learn the difference between implementation, api, and testImplementation in your build.gradle. It matters.
When something breaks and you don't know why: clean the project (Build → Clean Project), then rebuild. Fixes more than it should.
The Logcat panel is your best friend. Filter by your app's package name and read the errors carefully — they're usually telling you exactly what's wrong.

Takeaway: Gradle is not magic. Learn the basics of how it works and you'll save yourself hours of frustration.

4. AI Agents Are Powerful — But They Can Quietly Mislead You

When I got stuck, I started asking AI assistants (like ChatGPT or Claude) for help. And honestly? They're incredible. They explain errors in plain English, suggest fixes instantly, and can write boilerplate code in seconds.

But there's a trap I fell into: trusting AI output without questioning it.

AI agents don't always know the latest Android APIs. They can confidently suggest a method that was deprecated two versions ago, or generate code that compiles fine but behaves incorrectly at runtime. The code looks right — that's what makes it dangerous for beginners.

Here's how I learned to use AI tools better:

Always ask it to explain the code, not just give it to you. If it can't explain a line clearly, that's a red flag.
Cross-check with the official Android docs. AI is a great starting point, not the final word.
Tell it your context — your API level, whether you're using Compose or XML, Kotlin or Java. Vague questions get vague answers.
If something feels off about the generated code, trust that feeling and dig deeper.

AI is like a very fast, very confident pair programmer who sometimes hallucinates. Use it, but stay in the driver's seat.

Takeaway: AI agents can save you hours — but only if you understand what they're giving you.

5. Performance Problems Are Invisible Until They're Not

My first app felt fine on my phone. Then I tested it on an older device and it was sluggish. Scrolling lists stuttered. The UI froze when loading data.

Two things caused most of my problems:

. Doing heavy work on the main thread. Network calls, database reads, file operations — none of these belong on the UI thread. Use coroutines (viewModelScope.launch { })
to move work to the background. It's easier than it sounds.

You don't need to be a performance expert from day one. But knowing that these issues exist means you can avoid the worst of them early.

Takeaway: Run your app on a low-end device or emulator occasionally. It'll reveal problems your flagship phone hides.

Android development has a steep learning curve, and that's okay. Every confusing error message, every configuration change crash, every Gradle failure — it's all part of learning how the platform works.

If you're just starting out: focus on fundamentals, not features.

Build small. Break things. Learn why they broke.

That’s how you actually improve.

Still learning. Still building. Let me know in the comments if any of these hit close to home — or if there's something you wish you'd known sooner!