HackerNewsApp

The problem

Learning declarative UI properly, on a platform where the imperative version was the norm for a decade. A feed reader is the right size for that: a network layer, a list, a detail action, and navigation between two screens. Small enough to finish, large enough that the architecture has to be real.

Constraints

• Compose only. No XML layouts as an escape hatch, including where XML would have been quicker.
• The Hacker News API returns IDs, not stories. The story list is a list of integers; every item is a second request.
• Ship something finished rather than something ongoing.

Decisions

MVVM with a strict separation. The View renders state and emits events, the ViewModel owns UI state and survives configuration changes, the Model defines the story shape. On a two-screen app that is more structure than the app needs — which is the point, because the exercise was the structure.

Retrofit with coroutines. Fanning out from a list of IDs to individual story requests is exactly what structured concurrency is for.

Open stories in the system browser. No in-app WebView. The link goes to the device’s browser with its extensions, its reader mode, and its session — a worse-looking decision that produces a better read.

Tradeoffs

Archived deliberately. It did what it was built to do, and the honest thing is to leave it as a dated artefact rather than pretend it is maintained. It is in this list because a portfolio of only web apps would misrepresent the range — this one is Kotlin, on a device, against a platform with different rules.