Wednesday, August 29, 2012

CarHacker: Defeating the Curved Interior of a Prius to Mount a Nexus7

I'm a white middle-class male working in the tech industry in the Silicon Valley, so it should come as absolutely no surprise to anyone that I drive a Prius.

As I told Ian during our podcast player App Clinic, the only thing missing from the stock version of this modern marvel of hybrid engineering technology is a convenient place to mount my Nexus 7.

The Prius interior is a combination of smooth lines and continuous curves that offer seemingly few surfaces flat enough to accomodate 7 inches of Android tablet awesomeness. Until today.

With all my music in the cloud and a full-blown addiction to the unrivaled Google Maps (and by extension Google Navigation), I elected to purchase a model without the fancier radio package or built-in GPS receiver.

The music I own is in Google Music, and what I don't own I listen to using Pandora or Spotify. If I want to listen to the radio, I use TuneIn.

As a result, my car stereo - which takes up a significant portion of the dash - is nothing more than an elaborate routing mechanism to get the audio from my Android devices directed out of the car's speakers. It also represents one of the few flat surfaces available within a vehicle seemingly designed to contain absolutely no straight sides.

When is a Tablet Stand Not a Tablet Stand? When It's a Mount.

I've been using this handy little tablet stand since I got my Xoom, and everything since - from 7 and 10 inch Galaxy Tabs to my new Nexus 7.

It has both long and a short third legs to allow for propping your tablet at either 10 or 80 degrees.

It turns out that my Prius has a legacy mounting slot at the top of the in-car stereo panel (Edit: turns out this is for playing "compact discs") into which the shorter leg fits very snuggly.

The application of a couple of 3M backing tabs from some wall hooks is used to hold it firmly in place laterally and a 3M cable tie hook keeps the power and audio cables neatly tucked away.

The pincers of the stand are collapsable, so I can bring them as close together as I need in order to use the same mount to hold a phone, 7" or 10" tablets each in portrait or landscape orientations. The whole thing leans backwards slightly, and that - plus the "tacky" pads on the stand - help to keep everything in place when driving.

It would be better if I could figure out a way to use the Nexus 7 pogo pins for charging, and maybe come up with some kind of bluetooth solution for audio, but for now I'm pretty happy!


Monday, August 13, 2012

The Friday App Clinic: Podcast Players

Every week The Friday App Clinic takes a critical look at a selection of apps in a particular category. Our focus on is to help developers learn how to make their apps magical, and we'll use these corresponding blog posts to provide links to some of the techniques you can use to make that happen.
Last Friday Ian Ni-Lewis and I took the scalpel to podcast players. Up on the tablet were Doggcatcher, Beyond Pod, Pocket Casts, Volksempfänger, Listen Up, Good News, Podax, and Hipstacast.

Podcast Player Essentials

Let's start by looking at the fundamentals to creating a good podcast player.

Audio playback and control

This Android Training class on Managing Your Audio Playback explains audio focus and how to make sure your app responds to hardware and bluetooth multimedia control keys.

We recommend you create a homescreen widget to show users what's playing, and offer a shortcut to pause or skip tracks.

Use the Remote Control Client to offer the same details and shortcuts to users from the lock screen, and enrich your ongoing Notifications to support pause and resume playback at any time. While some of the apps we looked at allowed you to pause playback from a notification, doing so removed the notification, requiring you to relaunch the app to resume playback.

Offline Media Playback

Like any media playing app, a podcast player should continue to work even when your network connection is intermittent or disabled.

You can use the Download Manager to download podcasts in the background, using techniques like prefetching, as described in Android Training class Transferring Data Without Draining the Battery, to ensure that users are never left listening to "dead air" while the next track buffers or downloads.

Taking things a step further, Ian called out the elimination of the refresh button as the gold standard for podcast players.

Eliminating the refresh button is hard - which explains why all of the apps we looked at included a refresh button. To effectively remove it, you need to ensure that all your feeds are constantly up to date.  The best solution is to use Google Cloud Messaging to notify each installation of your app whenever a new podcast is available.

Making Podcast Player Work Like Magic

Playing a Podcast

Listening to podcasts is the sort of thing you tend to do when you're using your eyes for something else.

With your eyes otherwise occupied interacting with your app needs to be intuitive and familiar.

From a user-perspective, there's very little difference between a podcast player and a music player, but we noticed that many of the podcast players were presented more as podcast feed managers rather than media players, with playback controls like pause and skip were often hidden behind secondary tabs or even menu options.

Consider arranging your UI to focus around playback, so the media control buttons should always be available whenever a podcast is playing.


Podcasts are amazing -- there's thousands of hours of fresh content in every posible genre available for free, every day. But like TV and radio, content discovery is a key challenge.

The perfect podcast player should be as easy to use as the radio. Turn it on, and you should be able to start listening to something interesting within one or two clicks. That means presenting new users with a selection of content that's likely to get them hooked.

 In the apps we looked at, we noticed that the behavior of the "next" and "previous" buttons was often unpredictable. If the user hits "next", your app should be able to determine something for them to listen to without them having to pick it out specifically.

Similarly, never present users with an empty screen, or rely on them knowing and entering a podcast URL in order to get started. Even if they're experienced podcast listeners with their favorite feeds, make it easy for them to test your app before they go to the trouble of importing their favorites.

Managing Subscriptions

The focus of many of the apps we looked at was in managing your subscriptions and controlling which episodes were downloaded. These are largely implementation details that help you decide how often to refresh feeds, which feeds to fetch, and which episodes to download ahead of time.

While important, this functionality but is secondary to the point of your app. In most cases, a user's preferences will be global for all their favorite podcasts, so rather than having them configure different settings for each feed, create a sensible (customizable) default and apply it to all their subscriptions. Now you only need to allow users to browse content and select the sources they favor.

Show users what they've got organized in ways that are familiar and obvious: genres, albums, artists, and playlists.
Tune in every Friday at 1pm Pacific Time (UTC-7) for The Friday App Clinic with Ian Ni-Lewis and Reto Meier.

Monday, July 30, 2012

Making Apps Indistinguishable from Magic

"Any sufficiently advanced technology is indistinguishable from magic."
– Arthur C. Clarke
Imagine yourself from 1990 transported to the present, and being handed a smartphone

Had you handed 12 year-old me a Galaxy Nexus and a Nexus 7, and I'd have assumed they were props from ST:TNG. Show Asphalt 6: Adrenaline to a kid who's been obsessively playing Test Drive II on his 33Mhz 386, and watch him shit his pants.

When I was 12 years-old, it was 1990. I was running a BBS out of my parents living room and the World Wide Web didn't exist, but I downloaded shareware from local BBSs and browsed USENet with my brand-new 14.4kbit/s modem.

I'd seen a mobile phone, but the first SMS message wouldn't be sent for another 2 years.

Today we all have handheld devices that operate by voice and touch, that let you take pictures, record video, watch movies, and play songs. If that would have been vaguely comprehensible to a 12 year old in 1990, throw in a quick demo of Shazam or an international video Hangout.

You're not building apps for a portable handheld computer with a cell radio-based Internet connection. You're developing apps for a magic box

When you watch a good movie you don't think about how it was made. It's only when something breaks the illusion: an actor glancing at the camera, a piece of the set falling over, or a boom mic dropping into frame, that you're reminded that you're not looking through a magic window, but at actors on a set.

As developers, our goal should be to provide an app experience so immersive, that 12 year-old me never loses the feeling of wonder while playing with the magic box from the future.

Hide the connection

Make it seem as though all the information your app provides is somehow magically stored within the device itself.

You don't stop to think how you're online until you need to wait for a download to complete or when a connection fails. Aggressively prefetch and queue-and-send messages when you're next connected.

It's your responsibility to ensure that network speeds and intermittent connectivity don't leak in to the user experience.

Hide the Internet

The Internet Protocol provides best effort delivery over a service characterized as unreliable. That means downloads will fail, connections will be dropped, and errors will be received.

Your users don't need to know or understand what this means or why it happens; implement silent retries with exponential back-offs to handle data transfer problems without interrupting your users, and display error messages only when they're actionable.

Hide your user interface

We learn through positive and negative reinforcement, so when you guess wrong Venkman gives you a shock, and you're that much more hesitant to guess the next time.

The best interface is the one you don't notice, where the very first thing you try does exactly what you want it to do, and any accidental actions that prove destructive are easily reversed.

Help your users establish and build trust with your app.

Hide the battery

Magic devices run forever without being plugged in. You can't stop the battery from draining all by yourself, but you can do your part to ensure it lasts as long as possible.

Hide the device

A good app includes a combination of dynamic layouts flexible enough to support any screen size. A great app considers how its core functionality is best served given the screen and hardware on which it's running.

That probably includes a series of different layouts, but might also require an entirely different user experience when the underlying hardware is radically different from a standard smartphone. A magic app seems as though it's designed specifically for whatever platform you're running it on.

Hide your app

A magic box provides a series of useful actions and functions: sending a message, looking at a map, or recognizing music.

To keep the magic alive your app should should be designed to serve a particular function, one that's obvious as soon as the app loads. Similarly, it should be available whenever you need it (even if you didn't realize you needed it), and should be accesible by clicking an intuitive icon, a widget, or a notification.

An alternative title

Sometimes you don't know what point you're trying to make until long after you've finished making it. Such was the case for me this year upon reflecting on my Google I/O 20212 session, "Making Good Apps Great", which - as it turns out - I should have titled: "Making Apps Work Like Magic."

Monday, July 09, 2012

Making Good Apps Great: The What and the How

Once again the 1,300-seat main Android session room at Google I/O was consistently jam-packed, with attendees sitting on the floor and lining up to get in. As such, it was a real thrill to deliver my sequel to last years Android Protips presentation -- Android Protips 2: Electric Boogaloo.

It's now on YouTube for your viewing pleasure.

If you want a closer look at the slides, I've created this gallery, which features speaker notes as the captions.

If downloading is more your thing, they're also available for downloading as a PDF.

The code snippets are posted at Making Good Apps Great: The Code Snippets for your copy/paste pleasure.

Presenting Without a Computer

Like last year, I presented without a computer -- instead using a Asus Transformer Prime paired with a Nexus 7. One app, running on two tablets, connected via Bluetooth.

The Transformer Prime was wired up with HDMI-out and a USB-connected clicker that let me transition between slides.

The Bluetooth-connected Nexus 7 showed me my "Speaker View": My speaker notes, the current / next slide preview, my pre-written live tweets, and a countdown timer.

Whenever the Transformer Prime transitioned slides, it transmitted the current slide to the Nexus 7.

The slides themselves I created using Powerpoint, using the "Export as a series of pictures" option. Except the animations which were custom created by Pandamusk, as detailed here.

The app just steps through each of the images / animations in sequence.

Can I Get the App? Can I See the Source?

Yes and yes. I need to make a few improvements before I open source it.

Really? Because you said that last year and…

Yes. Sorry! The code took a little more tidying than I expected. I'll try and be a little more... prompt, this year.

Monday, April 23, 2012

Professional Android 4 Application Development: Because I only work in powers of 2

Professional Android 4 Application Development, started shipping today (Monday) from Amazon US - so those of you who pre-ordered should be seeing your copies in a couple of days. I'm really excited and can’t wait to find out what people think.

Professional Android 4 Application Development cover image
Where to buy

If you're interested in picking up a copy, you can get the paperback delivered to your door from these fine retailers:
If you prefer to travel light, there's an electronic version to suit your tastes:
I'm particularly pleased with the electronic editions of this release, which are significantly better than those of Professional Android 2. It's nice to see that this time they're  out at the same time as the paperbacks.

What's new?

This edition is a monster. Everything has been revised and expanded, with four new chapters and more than 300 extra pages (that's around 50% more) added since Professional Android 2.

Some of the highlights amongst the new content include:
  • Fragments and the Action Bar
  • CursorLoaders
  • The audio focus APIs
  • NFC, Wi-Fi Direct, and Android Beam
  • Using the Intent Service
  • A new chapter on publishing your app to Google Play
  • Introductions to LVL, IAB, and C2DM
  • Creating collection-based widgets and rich notifications
  • Using new sensors (including the barometer)
  • Property animations
  • Accessibility 
  • Implementing copy and paste
Some context

The whole thing took me a touch over a year to write. I started writing an update for Gingerbread and Honeycomb back in March of 2011 and before I'd finished, Ice Cream Sandwich dropped and I found myself doing some frantic rewrites and adding a few extra pages.

That means it's been two years between revisions, and as Professional Android 4 rolls off the presses there have been 8(!) platform releases.

Professional Android 2 was released within a few weeks of Android 2.1. As of now, 87% of devices are running a newer build of Android. The Android ecosystem has grown to include tablets, with more than 800 different Android devices created by 55 OEMs and available on over 300 carriers.

More than 850k new Android devices are activated daily, with the 450k+ apps in Google Play having been downloaded more than 10 billions time.


You can download all the code snippets and sample projects used in the book from the Wrox Open Source site.

If you've got any questions related to the book, you can post them over at the Wrox P2P forums. For anything programming related, I'd recommend using Stack Overflow (and adding a PA4AD tag). I'll be monitoring both and endeavoring to answer promptly.

I've created a +Professional Android 4 Application Development Google+ Page, and you can always get in touch with me over at Twitter or on Google+.

Monday, March 26, 2012

Understanding Mobile Radio State to Build Apps that Don't Drain the Battery

tl;dr: Read the new Android Training Class, Transferring Data Without Draining the Battery, to learn how to potentially halve the battery life impact of your apps' data transfers based on the underlying radio architecture.
One of the beauties of modern smartphone platforms is the abstraction of underlying hardware.

I've been building mobile apps for almost 5 years, and had no idea how the underlying 3G radio worked. I didn't have to. I just open a connection and start downloading data.

Dalvik negotiates a transport mechanism to ensure I get the fastest and most efficient data connection possible. Wi-Fi or mobile, Edge or LTE, it doesn't matter. Or so I thought.

We all know that data transfers on mobile radios chews up a lot of battery, so we're careful to restrict how much we download. It's a balance between app latency and chewing up bandwidth and battery life.

Turns out it's not so much the amount you transfer, but how frequently you power up the radio.

The problem with abstractions is that hiding the complexities means disguising some possible optimizations—something I came to learn after speaking to the good folks at at AT&T and DoCoMo.

Optimizing Downloads for Efficient Network Access explains that to minimize the power drain associated with the mobile radio, it will go into standbye mode whenever it's not in use. Before you can upload or download data the mobile radio needs to be powered-up. Powering up from standby introduces around 2 seconds of latency when making data transfer requests.

No one wants to wait an extra 2s every time they try to follow a link, so rather than dropping straight back to standby, there is a tail-time during which the radio stays active to reduce that latency.

The exact numbers vary depending on the carrier, but once you stop transferring data the radio stays on—at full power—for around 5 seconds. Then stays at a "low energy" state (which introduces some latency, but uses less battery) for around another 12 seconds.

Every data transfer session will cause the radio to draw energy for almost 20 seconds.

As an app developer, knowing that every time you touch the network you can draw power for nearly 20 seconds should have a dramatic impact on the way you structure you data transfer routines.

That includes prefetching, batching your downloads, eliminating redundant downloads, and prefetching even more aggressively when using higher bandwidth (but more power-hungry) radios.

Learn more at Android Training

This is just a brief summary, my Android Training class: Transferring Data Without Draining the Battery teaches you more about the underlying radio hardware, how to use that knowledge to optimize your apps' battery impact, and how to analyze your apps' current transfer profile.

Monday, January 02, 2012

2011: My Year in Review

2011 was a big year for me. I moved from London to the Bay Area, got promoted, wrote Professional Android 4 Application Development, and had my first Thanksgiving.

In amongst all that I read some books, took some pictures, and played with some Android gadgets. Here's a little summary of the highlights.


This year I used Google Books to store my 2011 reading list. My count was down somewhat (16 books compared to 23 last year), mainly due to the free-time spend writing the aforementioned book. This year's highlights:

  • Favorite Book: A Dance with Dragons by George R. R. Martin.
  • Most Read Author: I read two books by Courtney Summers and two by Wil Wheaton, but 16 books doesn't leave a lot of room for doubling up in a year when Feist, Pratchett, and Martin all release new books. 
  • Hardcover versus Paperback: 4 hardcovers, 5 Kindle eBooks, 7 paperbacks.

Lots of changes to the list this year. iPlayer, Ocado, and the London Cycle Hire Widget all drop off the list thanks to my move Stateside. Beluga gets dropped in favour of G+ Messenger, and TweetDeck gets the old uninstall thanks to increasingly poor performance and my shift away from Twitter towards Google+.

New to the list this year are Pandora and Google Music, which have revolutionized the way I listen to music since moving to the US. Cut the Rope, 3D Bowling, and the MX Video Player earned their striped keeping me entertained flying between California and Western Australia, and News Republic has come out on top when it comes to giving me news on the go.


A move to the Bay Area (and its hundreds of hiking trails through gorgeous nature reserves), a visit to NYC, and a trip back to Australia provided ample fodder for some photography. This year I tried my hand at some HDR processing too. A portfolio of my best pics is online here.


What am I carrying these days? Check out Reto Meier's Gadget Compendium.

The big changes this year were the introduction of the Galaxy Nexus to replace my Nexus S, and the inclusion of a Galaxy Tab 10.1 at the expense of the Xoom and a 7" Galaxy Tab. The 10" Tab is thin, light, and last forever -- indispensable for long haul travel.

Trends for 2011:
  • Lighter and thinner: The 10" Galaxy Tab probably weighs less than the 7" version. My Galaxy Nexus is the thinnest Android phone I've owned and is lighter than the smaller device it replaces.
  • Bigger screens: A 10" tablet replaced the 7" version and the Galaxy Nexus has a bigger screen than the Nexus S. People talk about screens being "too big", but provided they weigh less and don't suck up more power, I don't see a problem.
As for 2012? I'm hoping to see some Android @ Home gear this year. I think it might be time to upgrade my camera gear -- starting with a prime lens and going from there. I like the new Kindles, but the Kindle 3G I'm using right now does everything I need, so I don't see a Fire in my future.