A student's journey from "just making it work" to writing better Android code
INTRODUCTION
When I first started learning Android development, I thought my work was done when my app ran without crashing. I would write code, click run, and if the app worked, I was happy. But as I built more features in this course, I discovered that making an app work and building an app well are two completely different things.
In this article, I will explain why app architecture matters for Android development. I'll explore the difference between code that just works and code that is well-structured. I'll explain MVVM architecture in my own words and why it's better than putting everything in an Activity. Finally, I'll share my personal experience working on apps in this course and what I would do differently today.
SECTION 1: Code That Works vs Well-Structured Code
When I first started learning Android, I thought if my app runs and doesn't crash, I'm done. That's what I called "code that works." But after working on the BMI Calculator app that was provided in class, I realized there's a big difference between code that just works and code that's actually well-structured.
Code That Works
Code that works just does its job. You click calculate, it shows BMI. You click clear, it clears. The BMI Calculator app did all that. Here's what the calculateBMI() function looked like:
Figure 1: Screenshot of calculateBMI function from the BMI Calculator app
The Problem I Noticed
This code works fine. It does everything it's supposed to. But looking at it now, I realized something - this one function is doing way too much.
Let me list what's happening here:
- Getting values from 4 different input fields
- Checking if user typed valid numbers
- Calculating BMI
- Calculating Body Fat using a formula
- Checking BMI against categories (underweight, normal, etc)
- Deciding which color to use for each category
- Deciding which picture to show
- Figuring out Body Fat category (different for men/women)
- Updating the text on screen
- Changing the text color
- Calling another function for the popup
That's 10+ things in one function.
The whole MainActivity file is around 120 lines. It has:
- The gender spinner setup
- Button click listeners
- All the math calculations
- The popup dialog code
- The clear button with confirmation dialog
- Clearing all the fields
Everything is just everywhere. When I wanted to change how the popup looks, I had to scroll all the way to the bottom. When there was a bug in the BMI formula, I was scrolling up and down trying to find it.
What I Figured Out
So here's the thing I learned - there's a difference between:
| Code that just works | Code that's actually good |
|---|---|
| Runs fine today | Easy to understand tomorrow |
| Does what I need | Easy to find stuff |
| Works for me | Easy to fix when something breaks |
| Everything in one file | Each part has its own place |
The app works. It passes all the requirements. But if I had to add something new, like saving past results or letting users share their BMI, I would probably struggle because everything is tangled together.
What I'd Do Different Next Time
If I worked on this app again, I would:
- Put all the math formulas in a separate file
- Keep the MainActivity just for showing stuff, not for calculating
- Use ViewModel so data doesn't disappear when the phone rotates
Basically organize things better instead of throwing everything into one file.
Figure 2: Comparison between putting all code in one Activity (left) and using MVVM architecture (right)
This diagram shows the difference between putting all code in one Activity and using MVVM architecture. On the left, everything is mixed together - UI code, business logic, and data handling all in one place. On the right, each component has a clear job. The View handles only UI, the ViewModel manages data for the screen, and the Model fetches data. This separation makes the code much easier to work with.
SECTION 2: Understanding MVVM Architecture
What is MVVM?
MVVM stands for Model-View-ViewModel. When I first heard this term, it sounded complicated. But after learning about it, I understand it like this (Google Developers, 2024a):
View – What the user sees and interacts with (Activity, Fragment, XML layouts). The View's only job is to display data and send user actions to the ViewModel. It should NOT contain business logic.
ViewModel – The brain of the screen. It holds all the data the UI needs and prepares it for display. It survives screen rotations, so data isn't lost when the user turns their phone (Google Developers, 2024b). It tells the View what to show, but never directly updates the UI itself.
Model – Where data comes from. This includes databases (like Room), network calls (like Retrofit), or any other data source. The Model doesn't know anything about the UI – it just provides data when asked.
Why Is MVVM Better Than Putting Everything in Activity?
Before MVVM became popular, Android developers put everything in Activities. This created several problems (Phillips, Stewart, & Marsicano, 2022):
Activities became huge – Some Activities have 2000+ lines of code. Finding anything is like searching for a needle in a haystack.
Data disappeared on rotation – When you turn your phone, the Activity recreates. Without ViewModel, all your data would disappear and you'd have to fetch it again.
Testing was difficult – You can't easily test UI code. When business logic is mixed with UI, you can't write simple unit tests.
Code duplication – If two screens needed the same data, you would copy-paste code everywhere.
MVVM solves these problems by separating concerns and letting the ViewModel handle data safely. As noted in the Android developer documentation, this separation of concerns makes code more maintainable and testable (Google Developers, 2024a).
Figure 3: How data flows in MVVM architecture
This diagram shows how data flows through MVVM. When a user clicks a button, the View notifies the ViewModel. The ViewModel asks the Model for data. The Model fetches it from a data source. Then data flows back: Model returns data to ViewModel, ViewModel processes it, and the View updates. When the phone rotates, the ViewModel survives while the View recreates, so no data is lost.
SECTION 3: Problems That Arise in Large Projects With No Clear Architecture
While working on the BMI Calculator app that was provided in class, I got a small taste of what happens when code isn't organized well. The app we worked on is just one file with around 120 lines. But it made me think – what happens when apps get much bigger? Like real apps with 50+ files and thousands of lines of code? According to Android's official documentation, following recommended app architecture helps developers build more robust applications that can scale effectively (Google Developers, 2024a).
Based on what I learned in this course and some research, here are the main problems that show up when there's no clear architecture:
1. Code Becomes Disorganized and Hard to Navigate
In the BMI Calculator app we worked on, everything is in one MainActivity file. I know where things are because I just finished working on it. But if I come back to this project after a few months, I will probably forget where everything is. Now imagine a project with 50 or 100 files, and no clear structure about where different types of code should go.
Without architecture, different developers put similar code in different places. One person might put database code in the Activity, another might put it in a separate file. When a new developer joins the team, they have to guess where to find things. This wastes time and causes confusion.
2. Teamwork Becomes Difficult
In this course, we work individually on assignments. But in real companies, multiple developers work on the same codebase. Without clear architecture, teamwork becomes messy.
For example, if two developers need to work on the same feature, both might end up working in the same Activity. When they try to merge their code, they get conflicts. Someone has to manually fix the conflicts, which takes time and can introduce bugs.
With proper architecture, code is split into separate files with clear responsibilities. Developers can work on different files without stepping on each other's toes.
3. Adding New Features Becomes Slow and Risky
In the BMI Calculator app, if we wanted to add a new feature like saving calculation history, we would have to find a place to put the new code and make sure existing functionality doesn't break. Because everything is tangled together, changing one part can accidentally break another part.
In a well-architected app, adding a feature often means creating new files and classes, not modifying existing ones. This is safer because you're less likely to break something that already works.
4. Testing Becomes Almost Impossible
Testing is important because it helps catch bugs before users find them. But testing requires code to be organized in a certain way. Writing testable code is a key benefit of proper architecture. When business logic is separated from UI components, developers can write unit tests that run quickly and reliably (Kotlin Documentation, 2024).
Think about the BMI Calculator app. How would I write a test to check if the Body Fat formula is correct? I can't easily test just that formula because it's inside a function that also handles UI updates and depends on user input.
In a well-architected app, the calculation logic would be in a separate class. I could write a simple test that runs in seconds without needing the UI at all. Without architecture, this kind of testing is impossible.
5. Bugs Are Harder to Find and Fix
When code is messy, bugs hide everywhere. If the BMI result shows wrong numbers, where do I look? Is the input validation wrong? Is the BMI formula incorrect? Is there a problem with how the result is displayed?
Because everything is mixed together, I have to check everything. In a well-structured app, each bug has a natural home, so finding and fixing it is faster.
6. The App Becomes Hard to Scale
Scaling means making the app bigger – adding more features, more screens, more users. Without architecture, scaling is painful. As noted by Phillips, Stewart, and Marsicano (2022), proper architecture becomes essential as applications grow in complexity.
If the code is just one big MainActivity file, adding features would turn it into thousands of lines. At some point, it becomes impossible to manage. With proper architecture, features can be added as separate modules that don't interfere with each other.
What I Learned From This
The BMI Calculator app we worked on in class is small, so these problems are manageable. But I can see how they would become much worse in larger projects. That's why companies care so much about architecture. It's not about making code look pretty – it's about making development possible when the project gets big (Google Developers, 2024a).
PERSONAL REFLECTION
During this course, while working on the Lifecycle Lab, I ran into an issue that taught me why architecture matters. I had implemented onSaveInstanceState to save data when the phone rotates, but when I tested it, the text still showed "Fresh Start" instead of "RECOVERED". I was confused and messaged my lecturer about it.
After debugging, I realized the problem was a simple mistake – I used different key names for saving and restoring the data. I saved with "saved_bio" but tried to restore with "myText". This small error broke the entire feature.
This experience showed me that when code is messy and everything is in one place, even simple bugs become hard to find. If I had used ViewModel, I wouldn't have needed to write all that extra code, and the data would have survived rotation automatically.
Looking back, I understand that taking time to structure code properly saves time debugging later.
CONCLUSION
In this article, I explored why app architecture matters in Android development. I discussed the difference between code that simply works and code that is well-structured, using the BMI Calculator app as an example. I explained MVVM architecture in my own words and why it's better than putting everything in an Activity. I also looked at the problems that arise in large projects without clear architecture.
From my own experience with the Lifecycle Lab, I learned that even small mistakes can be hard to find when code is disorganized. Moving forward, I plan to consider architecture from the start of my projects rather than just focusing on making things work. Good architecture might take more time upfront, but it saves much more time in the long run.
REFERENCES
Google Developers. (2024a). Guide to app architecture. Android Developers. Retrieved from https://developer.android.com/jetpack/guide
Google Developers. (2024b). ViewModel overview. Android Developers. Retrieved from https://developer.android.com/topic/libraries/architecture/viewmodel
Kotlin Documentation. (2024). Kotlin coroutines guide. Kotlin Lang. Retrieved from https://kotlinlang.org/docs/coroutines-guide.html
Phillips, B., Stewart, C., & Marsicano, K. (2022). Android programming: The Big Nerd Ranch guide (5th ed.). Big Nerd Ranch Guides.
Top comments (0)