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

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.

Bye, PremoFM

sad_jordan_logo

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.

Screenshot_20160210-211744

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]

OMG Kotlin

I finally got around to watching Jake Wharton’s talk on how developers can use Kotlin to build their Android apps.  It’s a must watch.  For Android developers.

My initial thoughts on Kotlin were:

  1. Hmmm, reminds my of Swift (of Apple fame).
  2. Oh my goodness, take my money.
  3. Oh, oooh, ooooooooooooh.
  4. Nice.
  5. Kotlin is compiled to Java bytecode.  You still need to have reasonably deep knowledge of the compiler to avoid creating unnecessary objects or have inner classes hold onto references to the outer class, fail…
  6. …but, you need to have reasonably deep knowledge of the Java compiler anyway, even if you are writing just Java code (kind of invalidating point 5).
  7. This is amazing, this is the future.

One thing I have begun to realize as I learn Swift and now have seen Kotlin.  Java is VERY verbose with tons of ceremony.  Swift, Kotlin, and other similar languages are doing a good job stripping that all away and making coding genuinely fun and clean.

Super Artificial Intelligence

Last week, I read a two part piece, by Tim Urban, describing super artificial intelligence, it’s origins and inevitable ramifications on human life.

The AI Revolution: The Road to Super Intelligence

The AI Revolution: Our Immortality or Extinction

Tim does a very good job of putting everything in context, whereas, we might not be able to envision a future incredibly enhanced by super AI (most experts agree we’ll see super AI in the lifetime of the average millennial), but that’s perfectly human.  I certainly had a hard time wrapping my head around some of these notions.  He describes artificial intelligence that will appear to have been a sudden discovery, but we’ve been chipping away at it slowly and methodically (but faster and faster as technology progresses).

ibm20ps220model2030-11382846

Kind of on a related note, I look at where technology was when I used a computer (that IBM PS/2 Model 30) for the first time, then fast forward to today, an incredible amount of progress that is very easy to be taken for granted.  Technology has progressed rapidly over the past 20-30 years, and it’s advancements, when summed up, are pretty incredible.  I carry a device in my pocket (and on my wrist) that has more computing power than a lot of the computers I’ve owned, combined.  

The advancement of artificial intelligence will be like this.  Seemingly tiny iterations that we all just get used to like Gmail spam filtering, Google Now, Google Photos face detection, Siri, credit card fraud detection systems, Google Maps navigation, music suggestion / playlist creation, etc.  One day, we’ll have super artificial intelligence.  Now I don’t know what it’ll look like.  Will my Google Maps navigation all of a sudden just become awesome?  Or will Google market their branded super artificial intelligence solution.  Who knows?

Consequently, today Google’s DeepMind division made a particularly big advancement in artificial intelligence with AlphaGo, a computer that can beat the world’s best Go players.
¯\_(ツ)_/¯