Next Project

The next version of NC Traffic Cams (version 3.0, but with a different name) is nearly feature complete.  I completely overachieved on this project, but purposefully.  Since I stopped actively building PremoFM, I wanted to start on a project that would teach me a few advanced Android development tricks.  I’m building the next version of NC Traffic Cams with the following in mind:

  • Model – View – Presenter, similar to Model – View -Controller, enforces the separation of Android specific logic and business logic in an effort to make the business logic more testable.  I’m also using Loaders to keep Presenters around.  This is great because it means I have to do no work to persist the apps state during a device rotation.
  • Lots of unit tests.
  • Lots of RxJava, in the latest released version of RxJava I wrote a ton of AsyncTasks. This time around 0 AsyncTasks.  I have RxJava to thank.
  • OrmLite for the data layer, no more writing SQL selects and inserts by hand (I actually tried to integrate with Realm, however, I threw it out because of the thread management issues I encountered).
  • OkHttp / Retrofit / Gson for the API later, no more writing HttpUrlConnection or JSON parsing logic.  I have a simple API setup for NC Traffic Cams and Retrofit made it ridiculously easy for me to get that data into NC Traffic Cams.

I wrote substantially less code this time around and the app is better, more stable, and more performant.  Can’t wait to show you all what it looks like.  It’ll be done soon™.

Here’s NC Traffic Cams v1 & v2 since it’s #ThrowbackThursday

Screen Shot 2016-03-31 at 10.41.25 PMcities_n5_v220-605x1024


PremoFM: The Source Code


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.  


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.

Bye, PremoFM


I will be ending PremoFM development and shutting the servers down on Sunday, February 14th..  I will be destroying all data, including user data, at this same time.  Users can export their current subscriptions by going to Settings > Export to OPML.  You can use the OPML file to import your podcasts into other great podcast apps like Pocket Casts (my favorite), Beyond Pod, and Player FM.

Why?  Purely, the model I adopted with PremoFM was unsustainable (and an important lesson learned).  I decided to go the free + patronage route.  In order for this to work, I’d need a ton of users, because, naturally, only a small percentage of users would opt to be a patron.  I only had 176 installs as of today, February 10, not enough by a longshot.  I’d need to invest a ton of time and money in marketing.  As a side project, PremoFM was unable to get that level of attention from me.  There are millions of apps in the Play Store, so marketing is an overwhelming requirement.  It’s rare for an app to organically get noticed or go viral.  Despite repeated attempts to have my app reviewed by various Android / Tech blogs and websites, I was mostly unsuccessful in generating sustainable attention for PremoFM.  I originally sought out to create the podcast app I would want to use and I “hoped” others would too, but I didn’t spend enough time on the business model or differentiation.  So in a sea of tens of other more well known, high quality podcast apps, PremoFM failed to acquire a ton of users.

It wasn’t all a loss.  Building PremoFM allowed me to gain a truly deep understanding of Android development and APIs. Some things I gained experience with include playing media, Google Cast APIs, Google Cloud Messenger, ContentProviders, Material Design, Services, JobSchedulers, etc.  I was able to use this experience to gain full-time employment with WillowTree Apps last fall.  I even gave a few decent talks on MediaSession APIs, added to Android 5.0.  I even gained a ton of experience spinning up servers in a hosted environments, setting up an OpenVPN network, and writing threaded XML retrieval, parsing, and processing logic.  I’d never again write threaded processes in Java ever again, but now I know.  I also achieved a 4.76 out of 5 star rating, which I’m kinda proud of, despite the low install numbers.


Moving on, I will be completely open sourcing the app, backend automation, API, and scripts in the next few weeks.  If you like the app enough and you are a developer, you *could* mate the parsing engine with the Android app, since it’s all Java and uses PremoFM without the expensive backend.

R.I.G. PremoFM

[R.I.G. = Rest in GitHub]

PremoFM 1.2 – Introducing Pinning, OPML support, iTunes links, and more Material


PremoFM, Android’s freshest podcast app, just leveled up with PremoFM 1.2 with a lot more awesome.  It’s available in Google Play now!

What’s new?

Pinning allows you save episodes to your device without subscribing to the podcast.  Want to check out Tim Ferriss Podcast w/ Jamie Foxx, but don’t want to subscribe?  Pin that episode to your device and you can listen to it, download it, add it to a collection or playlist.  Remove it when you’re done with it.

OPML Support allows you to import all of your podcasts from another podcast player, into PremoFM.  You can also export all of your PremoFM podcast subscriptions to an OPML file.  Access both features in settings.

iTunes Podcast Link opening allow you to click on an iTunes podcast link and open it in PremoFM, to that specific podcast.  Most podcasts list their iTunes link directly on their landing page.  This allows you to subscribe to podcast from the web on your Android phone more seamless.

Notifications have been improved.  Not only are they more readable, but now you’ll be able to check out show notes directly from your lock screen when you received a new episode notification.

Not familiar with PremoFM?  Check out the video below, then head to Google Play.



Cursors, RecyclerViews, and ItemAnimators

RecyclerView is an Android support library class that was introduced with the launch of Android “Lollipop” (compatible all the way back to Android 2.1).  It has a ton of new capabilities and built on a new architecture that promises flexibility and scalability for Android apps.

It’s ListView predecessor didn’t age too well and became cumbersome to use and extend.  ListView had a plethora of built in adapters (classes for binding data to the ListView), including an adapter for binding a ListView to a Cursor.  RecyclerView is great, but it’s missing a cursor adapter.  Because RecyclerView is so extensible, developers can easily write one, like the one written by Jason Yu:

Well, great, now I can use CursorLoaders, Cursors, and RecyclerViews in my Android app.  There’s one problem.  Backing up a bit, RecyclerViews introduced ItemAnimators.  They provide an easy way to run animations when items in the data backing a RecyclerView are inserted, removed, or changed.  If you’ve done any type of animations with ListView, you’d appreciate the ease of ItemAnimators.  RecyclerView determines which animation to run using RecyclerView.Adapter functions called in an implementing adapter:

  • notifyItemChanged
  • notifyItemRangedChanged
  • notifyItemInserted
  • notifyItemRangeInserted
  • notifyItemRemoved
  • notifyItemRangeRemoved
  • notifyItemMoved

Each of the mentioned functions requires an index, or range of indexes indicating which items were inserted, removed, or changed.

Going back to the problem, using a CursorLoader and Cursors in an Android app.  A dataset change (new record, deleted record, changed record) causes CursorLoader to initiate the allocation of a new Cursor that points to the new dataset.  This is great, we can pass that new Cursor to our CursorRecyclerViewAdapter seen above.  This is where our problem rears it’s head.  Our default implementation only knows that the dataset has changed, but doesn’t know the particulars (which records are new, removed, or changed)…so it calls notifyDataSetChanged, which causes the entire RecyclerView to be invalidated and redrawn.  It looks bad and is inefficient (see explanation at the end).

I needed a way to determine which records were inserted, which were removed, and which were changed.  I had a cursor to the old dataset and a cursor to the new dataset.  My only options were to diff them, building a list of records that were added, removed, and changed.  This allowed me to run the appropriate notifyItem* function and gain the corresponding animation that improved the user experience.  This is the RecyclerView adapter I use in my podcast app, PremoFM.

In this Gist, I’ve added several things to make this diff possible, built on the great work of Jason Yu.

First, my dataset contains a column I use to record a timestamp when that record is updated.  I pass the name of the column to the CursorRecyclerViewAdapter.  This becomes my comparison column (mComparisonColumn).  This saves me from having to compare each value, in each row in a record from one cursor, to each value in each row in a record in another cursor.

Second, I’ve added several functions that compare a new cursor and an old cursor:

  1. getChangeOrInsertRecords – iterates over the incoming cursor, then the outgoing cursor in an inner loop.  Matches each record on a row ID.  If a match is found, it then compares the comparison column.  If the values in that column don’t match, this record was edited.  If a record in the incoming cursor is not found in the outgoing cursor, then it’s a new record.  If the incoming cursor is empty, then all the records were deleted.  If the outgoing cursor is empty, then all the records in the incoming cursor can be assumed as inserted.
  2. getDeletedRecords – iterates over the outgoing cursor, then the incoming cursor in an inner loop.  It matches each record on a row ID.  If a record in the outgoing cursor is not found in the incoming cursor, then we can assume that the record has been deleted.

The result of running these two functions is a list that contains the index and that indexes difference (insert, remove, change).  I use this data in swapCursor to run the corresponding notifyItem* function and I gain animations when items change.

What does all of this get me?  Look at the user interface differences below.

notify_dataset  notify_item

Left: notifyDataSetChanged / Right: notifyItem*

Downsides?  The diff is a O(n^2) operation.  If you have a ton of records, this operation could take a while.  A possible optimization is to only diff the records that are visible in the RecyclerView and not the entire dataset behind each cursor.

Let me know if you have any questions by hitting me up on Twitter.  Also download my podcast app, PremoFM, in the Google Play Store now by going to

Why is using notifyDataSetChanged with RecyclerView bad and inefficient?  Calling notifyItemChanged causes RecyclerView to make a requestLayout for the RecyclerView.  So even if the text was updated in the first item in my RecyclerView, all the items will be redrawn.  The function notifyDataSetChanged triggers a call to RecyclerView.AdapterDataObservable.notifyChange.  In this function, each RecyclerViewDataObserver.onChanged function is called, which eventually triggers a requestLayout call.

Evidence is freely available for in the Android source code.