PremoFM: The Source Code

web_hi_res_512

I just uploaded the source to my podcast app, PremoFM, to GitHub.  PremoFM was my attempt to create the podcast player I loved using.  I was super successful at that.  However, I built PremoFM with too many costs, mainly servers.  It didn’t make a lot of sense to keep that going with no revenue so I ended it.

However, PremoFM was super important to me and crucial to my career as a now, full-time, Android developer.  It is a modern Android app that embraces Material Design and some of the latest APIs available on Android.  I want to share this with the world.

What are the top three aspects of PremoFM that make me the proud?

  1. The podcast player service is baller.  I built an Android service that leverages new MediaSession APIs introduced in Android 5.0 “Lollipop”.  I also refactored that actual MediaPlayer so that I can seamlessly switch between MediaPlayer (plays media through the phone’s speaker or headphones) and the CastMediaPlayer (plays media through a Google Cast device).  The LocalMediaPlayer was built on Google’s awesome, open source media player, ExoPlayer.  I was one of the first apps to build an experience around ExoPlayer.
  2. User interface and design.  PremoFM was not the prettiest podcast app, but I thought it was the cleanest and most intuitive.  It presented everything you wanted to look at up front and didn’t require the user to do too much digging.
  3. Notifications and the Download service.  PremoFM never polled the API server for new episodes periodically.  A Google Cloud message was sent to the device when new episodes were ready.  This allowed me to alert users of new episodes almost immediately.  The Download service cached episodes and podcasts in the background in a battery efficient manner because it was built on JobScheduler (introduced in Android 5.0 Lollipop).  JobScheduler allowed PremoFM background services to run in the most battery efficient manner, when other things were happening, like the Google Play Store updating apps.  

notify_item

What are the top three disappointments?

  1. Architecture.  I failed to separate lot of the business logic from Android-centric components like Activity, Fragment, and Service.  This made it really hard to write tests.  If I had to do it all over again, I would use a modern Android development architecture like MVP (Model, View, Presenter)…that would enforce some code and logic compartmentalization.  It would allow me to easily write unit test for important business logic without needing to worry about mocking Android APIs and components.
  2. Database stuff.  I wrote all of the database logic from scratch.  I built the entire app on ContentProvider.  While it worked well for PremoFM, it was a headache to maintain.  I often introduced bugs because I’d add a column and would forget some important aspect like making it nullable.  I did not have a ton of unit tests so many of these problems made it to beta when they could have been prevented earlier.  If I were to change something I would use a library like OrmLite to make this portion of the app simpler and easier to maintain.
  3. JSON & HTTP.  Again, this is another area of the app where I was better off leaving it to a library like OkHttp, Retrofit, and GSON.  I wrote all the code that dealt with HTTP (built on HTTPURLConnection), JSON parsing, and serialization / deserialization.  On one hand I learned a lot of what happens underneath the hood.  On the other hand I spent a lot of time on parts of the app where my time should have been spent on something else.

Other things to browse the codebase for:

  • Integration with Google Cloud Messenger
  • Using the Material Design Support library for the navigation drawer
  • The episode downloaded
  • Cursors and CursorLoaders
  • Implementation of the Sonic library to altering the playback speed of audio in ExoPlayer
  • Aggregation of new episode / download notifications, built on a network of PendingIntents
  • My abstraction of image loading libraries, halfway through this project I switched from Picasso to Glide.  Due to the fact that I abstracted this from the app, all of my code changes happened in one or two files despite the use of image loading in tons of places.
  • Tricky tricky SQL queries

I do have plans to make PremoFM functional again.  If you build it, chances are you won’t get far because it requires the PremoFM backend and API.  All of the XML parsing happened on the server.  I have plans to port all of the XML retrieval and parsing logic to the app because I desperately want to use this app again.  Clone it, fork it, and hack away at it to your hearts content.

Be on the lookout for my apps from me…soon.