Podcasts for Android Developers

I listen to a bunch of podcasts, but there are a core few that make me better at what I love doing, writing Android apps.  Here are some of podcasts I listen to that are tailored to Android developers.  I more or less take at least one thing away that makes me a better Android developer or makes my current project, PrēmoFM, better.

Queue the Xzibit meme…


Android Developer Backstage


Link -> androidbackstage.blogspot.com

Android Developer Backstage (ADB? <— well played) is a podcast hosted by engineers who work on Android at Google.  Chet Haase leads the podcast.  They’ll often have guests on from other teams within Google, such as the tools team, Google Play Services, Android Wear, and many more.  There’s nothing like getting tips on Android development from those building the operating system and tools.



Link -> fragmentedpodcast.com

Fragmented is a recently launched podcast, hosted by Donn Felker & Kaushik Gopal.  These two often provide tips, tricks, and tools tons of Android developers would benefit from exploring, such as tools for unit testing, emulator alternatives, new libraries, etc.  The latest episode (Episode 3) includes a guest developer from Trello, Dan Lew, who offers some knowledge using RxJava on Android.



Link -> autocomplete.fm

Autocomplete has a similar feel to Fragmented.  The hosts, Jay Ohms, Jordan Beck, and Michael Novak, are all Android developers who have written apps.  I know them from their work on the beautifully designed RSS app, Press.  They tend to dive into relevant Android / Android development topics of the time.  They haven’t released an episode in a few months, but their backlog is still very relevant.

Differentiation, Bootstrapping, & More

As is normally the case, Exponent.FM is easily the smartest thing I listen to in any given week.

“It’s really hard to be the exact same but better.  It’s a lot easier to be different.  Ehh, it’s not easier to be different, but it’s much easier to communicate your value to potential customers, by being different than it is to try to convince them you’re slightly better.”

Ben Thompson describes how built Stratechery.com.  It began as a blog that has rapidly turned into full-time business that has 2,000+ monthly subscribers paying anywhere from $8 and $12 a month.  Sure he’s not setting the world on fire, but he’s found an incredibly passionate, influential, & growing audience willing to pay for his insights on the technology industry (top notch).  It also sounds like his work aligns with his passions.  What’s even more admirable is that he’s done it by himself.  Some very sound advice and experience for those who desire to bootstrap their own businesses.

The Story of Stratechery @ Exponent.fm

Identifying The Right Customers

Shift Jelly developer, Russell Ivanovic, shared some insights on the breakdown of Pocket Casts users on Android.

First of all, Android version adoption numbers.


Developers should spend an overwhelming amount of their time developing and shipping products for Android 4.1 “Jellybean” – Android 4.4 “KitKat” because that’s where the users are right?  Well, it depends.

Pocket Casts specific Android adoption numbers (ie. what versions of Android are my users running).


My lone Android application, NC Traffic Cams, Android adoption numbers.

Screenshot from 2015-01-31 11:33:01

So while Android 5.0 has less than 1% adoption in the overall Android eco-system, 23% of our customers already run it. This makes sense when you put a bit of thought into these numbers. People that have the money to buy apps, and are passionate about Android, have up to date phones. While some users who run Android 2.3 on their 5 year old phone might be perfectly happy, they probably weren’t ever going to buy Pocket Casts. It’s also worth noting that Pocket Casts sells in much larger volumes (and makes more revenue) than any numbers I’ve seen for an equivalent iOS app. We’ve slowly moved our minimum version from 2.3, to 4.0, to 4.1 and it hasn’t hurt sales at all.

I, 100%, agree with Rusty.

Android adoption numbers, provided by Google, are only relevant if your target customers include ALL Android users.  This is rarely the case.  I’d imagine only a very few developers and companies can afford to target all Android users as customers for their apps and services (depending on the complexity of their apps, most in this group are large public corporations or venture backed startups ie. the Facebooks, Twitters, Instagrams, and Ubers of the world who aim for ubiquity).  Android is such a huge market (1 billion devices sold in 2014) that there are bound to be smaller, profitable, niche markets available.  Enthusiast and indie developers need to spend sometime identifying these smaller, niche markets before starting on new products.

While building NC Traffic Cams, a relatively simple product, I essentially targeted Android users who were interested in North Carolina traffic imagery.  I wasn’t using the latest and greatest APIs because my priority was providing visual traffic information to as many Android users as possible.  Early on, I used libraries (ActionSherlock, Google Play Services, etc.) that made it easy for me to provide a consistent user experience across various versions of Android (at that time, starting at Android 2.1).  I eventually dropped support for Android 2.1 and 2.2 because the Google Play Services library eventually dropped support for these versions.

I, of course, did not completely follow my latest insights with regards to my current project, PremoFM.  In the beginning, I identified, at a very-high-level, business-diagram-type-of-way, the customers I am targeting, but I failed to identify the specific profile of Android users I am targeting until midway through the project.  For example, I targeted Android customers running Android 4.0 through to Android 5.0 (I at least had enough foresight to cut out Gingerbread support).  Then I began writing code and realized how many specific APIs weren’t available on older versions of Android.  I was definitely on the road to a bad user experience and high support costs, given my real life constraints (one person, doing this in my free time).  I took a step back and asked a few questions, some of them being:

  • How much effort or time am I willing to sacrifice to provide support to users with older devices (fixing bugs specific to these version, etc.)?
  • What versions of Android will allow me to provide the best user experience possible?
  • Are there enough paying customers using older versions of Android to make supporting these versions worthwhile?

In the end, it’s all about establishing your priorities (and more importantly, de-prioritizing other things!).  The time you spend working on XYZ will mean you won’t have that time to work on ABC.

As an side, it would be really interesting to see general data on which types of users spend the most money and what versions of Android they use.  My guess is pretty consistent with Android adoption numbers provided by Russell.

-> How New Versions of Android Work @ RustysRants


Easy to Understand?

Is it easy to understand? There is an app on the app store that’s a game, and the point of the game is to hold your finger on the screen over a word, like elephant or monkey or cup. When the icon that flashes across the screen is your word, you lift your finger. It’s a fun 4 player game. However, It wasn’t successful because you couldn’t explain the concept well. People tried to tell their friends and their friends didn’t get it, so they gave up. In contrast, the app iBeer is easy to explain — “It’s like beer on your iPhone!” and it went viral for Hottrix.

If your app idea can’t be explained in a single sentence, you need to refine it further. You can never capture the fabled virality or word-of-mouth craze if your users can’t actually explain your app to their friends or coworkers.

I’ve had this problem up until recently where I’d have some grand idea for an app that does all these things, adds tons of value, and even made you coffee.  When I pitched the idea I always end up taking a deep breath, then adding a couple of minutes of back story.  If I haven’t already lost the listener I’d dive into a list of features.

I’ve learned that it is important is to distill your idea down to something you can explain in one or two sentences, that generate intrigue and interest, but contains enough information relative to the audience you are targeting.  This has the great effect of forcing you to focus on that one thing during the development of your product (and executing it very well).

Before Prēmo was a “beautiful, social podcast experience”, it was a messaging app, in a sea of messaging apps.  My single differentiating feature was the ability to send messages that had context.  By context (most people don’t understand the concept of context relative to messaging), I mean location or a date & time ie. you get messages when you are at a certain place or at a certain time.  This is a relatively complex concept to the audience I was going after.  The next immediate step was explaining use cases, which only applied to me.

Check out the rest of a great read on Medium and visit GetPremo.com to sign up for a rapidly approaching beta!

Source: How to Refine Your App Idea

Podcasts by the Numbers

I’m building a mobile podcast “catcher” app (called Prēmo – GetPremo.com, pronounced Preeemo).  Midroll, a company that connects podcasters with advertisers, publishes some interesting results from their quarterly survey, which has 279K responses from 106 podcast shows.

Just a few interesting statistics:

  • 58% of podcast listeners have at least a Bachelor’s degree
  • 80% of podcast listeners listen using their mobile device (iPhone, Android, other)
  • 67% of podcast listeners are in the 18-34 year old demographic (ie. the most desirable demographic)

That was just a small sample of some amazing and insightful statistics published by Midroll.

Check the rest out for yourself.