I've always found transportation applications interesting.
Not because I particularly enjoy looking at maps, but because commuting is one of those situations where too much information can be just as bad as too little.
You don't want to study a transportation system.
You just want to get somewhere.
That was the idea behind one of my projects:
Train Track.
It's a native Android application I built around Metro Manila's rail systems.
The Problem
Metro Manila has multiple major railway systems:
- LRT-1
- LRT-2
- MRT-3
For someone who regularly commutes, knowing the stations isn't necessarily the difficult part.
The difficult part is putting everything together.
Where do I start?
Where do I transfer?
How many stations are left?
What's happening on my route?
So instead of thinking:
"I'm going to build a train database."
I started thinking:
"I'm going to build something that helps a commuter understand their trip."
That small change in thinking affected almost everything else.
Building It With Kotlin
I decided to make Train Track a native Android application.
The project uses:
- Kotlin
- Jetpack Compose
- Material 3
- Room
- Kotlin Coroutines
- Flow
I wanted to use the project as an opportunity to go deeper into native Android development.
Compose was particularly interesting because the UI is driven by state.
Instead of thinking:
"Change this UI element."
I could think:
"The state changed, so the UI should represent the new state."
That mental model made more sense for an application dealing with dynamic information.
The UI Problem I Didn't Expect
At first, I thought more information would automatically make the application better.
It doesn't.
Imagine opening a transit app and immediately seeing:
- station information
- train specifications
- alerts
- crowding
- route data
- schedules
- track information
Everything might be useful.
But not necessarily right now.
That's when I started thinking about progressive disclosure.
Show the important information first.
Let the user dig deeper when they need it.
A commuter checking their route shouldn't have to understand the entire system before they can answer:
"Where do I get off?"
That became one of the design principles behind the project.
Offline Matters More Than I Initially Thought
Train Track also uses Room for local persistence.
That allows the application to keep useful information locally, such as favorites, searches, settings and cached information.
This might seem like a normal Android implementation detail.
But I started seeing it differently.
A commuter might be underground.
They might have a weak signal.
They might have no connection.
And that's exactly when they may need the application.
So offline support isn't just a technical feature.
It's part of the user experience.
The Interesting Part: Thinking About the Journey
The biggest shift happened when I stopped thinking about individual features.
Instead, I thought about the entire journey.
Imagine:
Station A
↓
Train
↓
Transfer
↓
Train
↓
Station B
The user doesn't want five different screens explaining each part.
They want the application to help answer:
"What's happening now?"
"What's next?"
"What do I need to do?"
That made me realize something:
An application can contain complicated information while providing a simple experience.
That's a principle I want to carry into future projects.
What I Learned
Train Track taught me that building software isn't just about choosing technologies.
It's about translating complexity.
The transportation network can be complicated.
The application shouldn't make the commuter feel like they're navigating the complexity themselves.
That's probably my favorite lesson from this project.
When I'm building something now, I try to ask:
"What decision is the user actually trying to make?"
rather than:
"What features can I add?"
Those questions lead to very different products.
What's Next?
Train Track is only Part 2 of my project series.
Next, I'm moving from transportation to something completely different:
HackForPinas.
The problem there isn't navigating trains.
It's navigating information.
Hackathons, coding competitions and technology opportunities can be scattered across different websites and communities.
So I started building a platform to bring those opportunities together.
And that's where things get considerably more interesting from an engineering perspective.
Automation.
Scraping.
Validation.
Security.
Admin workflows.
More on that in Part 3.
Top comments (0)