Passing through subway stations, I kept noticing spaces most people overlooked. Galleries, rest corners, performance stages. Spaces walked past daily but rarely known. The Korea Railroad Industry Information Center was running a hackathon — “Public Data Utilization for Station Convenience Information.” Three weeks, public-data based. I joined as team lead with two teammates.

Service

Hidden Rest Areas is an Android app that surfaces the lesser-known rest spaces inside subway stations.

The app held four features: per-station rest spaces with photo, location, and rating; performances held inside stations with their schedules; per-station open chat rooms; and general facility information — restrooms, nursing rooms, cultural spaces.

The last one organized material already in the public dataset into a single view. The first three were our own content. Hidden rest area entries accepted user ratings, which fed the recommendation flow naturally.

Architecture

Three weeks meant going with a proven stack. The design stayed simple: Android app + single API server + RDB.

flowchart TD
    App["Android App\n(Java)"] --> API["API Server\n(PHP + Apache)"]
    API --> DB[(MariaDB)]
    API -. FCM .-> App
    App --> Maps["Google Maps API"]
    App --> PublicData["KRIC Public Data"]

The server ran on PHP and Apache. I had worked with this stack before, which mattered when the goal was stable operation under a short deadline. MVC and Singleton patterns shaped the code; MariaDB held station and rest-space data.

The app was built in Java. Google Maps API rendered station locations, Glide handled image caching, and Lottie animations covered small interactions. New rest area and performance alerts went out through FCM.

I worked on both the server and the Android app. The two teammates split data ingestion and additional client screens in parallel.

Key implementation

Public data integration

The hackathon’s center was transforming public data into something useful for the user. We pulled station convenience data from the Korea Railroad Industry Information Center, transformed it, and loaded it into our own database. The source structure did not map directly onto the screens, so an intermediate transformation step made sense. Our own content — performances, chat — lived in separate tables.

Library choices

With three weeks, library choice was effectively schedule management. Google Maps gave us the location UI as a drop-in. Glide reduced image-handling code. FCM let the server push alerts directly. Letting libraries cover the easy-to-miss spots freed time for the features that mattered.

Retrospective

The submission was selected. A short window with public-data transformation woven into our own content seemed to be what landed.

As team lead, scope and pacing were the heaviest part. The pull to add more features was strong, but reaching a demo-ready state in three weeks meant stopping at some point. Locking the four core features and refusing to extend was probably the single biggest factor in hitting the deadline.

It was also my first time working with public data directly. Reshaping external data into our own domain took more time than expected. Next time something similar shows up, I would start with the transformation layer before anything else.