Let's build an Internet Radio - Part 1

What's going on here?

I have been a radio junkie since birth. I grew up in Southern California, which meant that I had access to an incredible depth of FM radio, and at night, an impossibly wide selection of AM stations to tune in. I soon found my way into building my own shortwave radios to tune in music from around the world, and bulding amateur radio (my call is KB8QPT) gear so I could talk back.
Recently, I have become interested in internet radio. While I have been interested on and off in the past, the available bandwidth wasn't there, and the sound was not anything I could tolerate for any length of time.
Well, we now have the kind of bandwidth to receive an acceptable transmission.
The first thing I found was that none of the radios I could find fulfilled my simple expectations. Those of:

• Curated: There are thousands upon thousands of stations out there. Lots of them are low fidelity, unreliable, and even more are impossible to understand. It would be a great help if stations could be documented or curated by the listening group to aid in identification and discovery of interesting stations.
• Tags: My personal collection of stations has a hundred and a half or so stations. There are lots of times when I just want to hear the news, or pick from a Chill channel, or a modern music station. The ability to tag stations willy nilly is an absolute deal breaker.
• Social: It would be great if users could add and suggest the stations they loved.
• Cross platform: It would need to be able to run on MacOS, Linux, Windows, iOS, and Android. All applications should access a central database, and modify the database at will. This is not a deal breaker, but it would make the project much easier to manage.

Select the Tech

Database

After my last adventure in creating a REST interface to a database, I am going to use Pharo Smalltalk to build this database. Since I have a bit of practice, I should be able to knock this one out pretty quick. Using Pharo, I have lots of options for data persistence, but I will most likely use Voyage for persistence. I would like to play with Gemstone/s, I just need to spend some time learning how to install and interact with it.
Breaking the database out into a REST interface lets me build applications on other platforms without having to worry about persistence. It will also allow anyone else who wants to build their own interface using this database to do so with minimal problems.

GUI

I spent the first half of my development career writing applications for the native desktop. The second half has been spent about 25% of the time writing native applications, and 75% writing web applications. In that time, I have come to find that I much prefer writing native applications. They are much more reactive, and the interface is not detached from the application logic.
Web applications just feel laggy to me. I can feel the interface moving around, and while javascript frameworks have gone a long way in making it easier to create responsive UIs, I still don't like the feel. I did some experiments with Electron and Angular, but those too felt too "Webby" to me.
I am going to do this as a native application.
Now, to choose how to write this.
Over the years, I have used Qt for applications that I knew would fit the free use case license. I would love to use Qt for this project, but I am not sure how the license would work. I would like to publish the source code as open source, but at same time, I wouldn't mind selling the application on the app stores (to allow users who don't care about the where this application came from to just buy it.) The last time I spent any time digging through how the license worked, I got the distinct impression that it might be a better idea to discuss his with a lawyer.
Since my computer is a Mac, and all my devices are apple, it might make sense to use swift/xcode to write the application. This way, I know I can sell on the app store without worrying about licensing issues. It also allows me to immediately take advantage of all OS specific features without having to figure out how to implement them some other way.
I imagine that if users decide they want this radio app on windows (I have a fair amount of C# .net experience) or Android (I would have to relearn enough java to develop a simple application), the extra work wouldn't be horrible.
Writing natively for Apple products allows me to share lots of pieces between a desktop and a mobile product. This sounds like a good starting point.

Let's get to building

Okay, so let's round up where we are:

• Persistence: We'll write a REST interface in Pharo/Voyage (using MongoDB. This will allow us to think through all of our models and interactions before we write any other source code.
• Interface: We'll use XCode/Swift to write the interface, so we don't have to worry about licensing issues if we decide to sell the app on the the app store.

In the next article in the series, we'll write the REST interface (open source, of course) and we'll discuss how to model our data.