Puls'Radio web radio player

Context

This was the project that taught me what shipping really means.

Puls'Radio was a French association running a web radio dedicated to dance and trance music. The stream was easy to play in a browser, harder to play on the move. In 2010 that meant building an Android app — and "Android app" in 2010 meant Java, Eclipse, and an emulator that took five minutes to boot.

What I built

A small, focused player. The whole app did exactly one thing: open the stream, play it, keep playing it through screen lock and incoming calls. Underneath it was Android's MediaPlayer wired to two stream URLs (MP3 + AAC fallback), with a tiny state machine for connecting / buffering / playing / paused, and a foreground notification with play/stop controls — written before that was a stock pattern, when you hand-rolled the layout in XML and prayed manufacturers didn't break it.

The hardest parts had nothing to do with the audio:

• Wake-locks done right. Letting the device sleep without killing the audio meant figuring out the difference between PARTIAL_WAKE_LOCK and the stream that just-keeps-playing, and being honest about battery drain.
• Lifecycle. Android's activity/service split was new, the docs were thin, and the stream needed to survive screen rotation, calls, and Bluetooth disconnects.
• Distribution. The Android Market accepted whatever APK you uploaded, signed with whatever keystore you happened to generate. Forgetting that keystore means losing the listing forever — a lesson I learned the hard way two devices later.

Outcomes

• The app shipped to the Android Market and stayed installed on a small but loyal listener base for the lifetime of the original Puls'Radio brand.
• It taught me to design for the device, not the desktop emulator.
• More importantly, it was the first project I shipped publicly that other people actually used. Everything I've shipped since has the shape of that lesson.

Status today

Archived. The original Google Code listing is preserved at the link above. The audio pipeline I'd build today looks nothing like this — ExoPlayer exists, foreground services have proper APIs, and Compose-based UIs read like prose. But the lesson — ship the thing, listen to the people who use it, fix what they actually run into — is still load-bearing.