Wednesday, June 25, 2014

What's the best way to learn Android?

It's a question I've heard a lot, and there's lots of good answers:
  1. Check out the Android developer Site is the most common answer, but there's a lot of documentation on DAC, and it can be hard to find a path that takes you from "getting started" to "protips" without reading everything.
  2. Read this book by that guy is one of my favorites! But book-learning isn't for everyone - and books aren't interactive or social (...and it's hard to keep them fully up to date).
  3. Download some samples and use StackOverflow works for a lot of people, but it's a very unstructured way to learn, and what you're building may not map well to the samples you're using.
Today I'm thrilled to announce the newest answer: a Massive Open Online Course (MOOC) created by me and my fabulous colleagues from Google's Developer Relations team and the awesome people at Udacity: Developing Android Apps: Android Fundamentals.

We're launching today at I/O with a sneak-peak at Lesson 1, with the rest of the course opening up July 15.

It's not the first Android course, or the first Android MOOC, but I sincerely believe it's the best one.

While creating this course, we tried to follow a couple of basic principles:
  • Get. Coding. Faster. Typically you’ll see courses like these spend the first 3 lessons introducing theory or building hello world. Not here.
  • Recalibrate your intuition. Mobile is different, and often what we’ve learned from years of desktop, web, and server development will take us in the wrong direction. We look for times when your gut will tell you to do one thing, and explain why it’s better practice to go in another direction.
  • Have fun. Coding is fun — or at least it should be. We had a lot of fun building this course, and tried to make sure students would enjoy it just as much. These days Android is Serious Business, but that doesn’t mean learning it has to be.
  • Get there faster. Online courses are self-paced, so we move quickly and give you the resources you need to dive deeper where you need to.
The result -- I hope -- is a course that teaches you not just how to develop for Android, but how to start thinking like an Android developer. So if you want to learn Android (or want a refresher) -- check it out, and let us know what you think!
What makes me the most proud of this course is how much of a team effort it's been. It required extraordinary efforts from my co-instructors Katherine and Dan, as well as Alex Lucus and Neto Marin who led the development of the "Sunshine" sample app, Mike Denny who helped design the UI, and a whole team of people at Udacity including Jennie Kim, Sarah Spikes, James Williams, Calvin Hu, Katy Reichelt, and Larry Madrigal without whom this could never have been possible.

Monday, May 20, 2013

Android Protips 3: Making Apps Work Like Magic (and more!) at Google I/O 2013

This year at Google I/O, I had the opportunity to present two sessions: Android Protips 3: Making Apps Work Like Magic and What's New in Google Play Services, as well as moderating the Android Fireside Chat, and interviewing Hugo Barra and Hiroshi Lockheimer.

Presenting on stage in a packed room in front of over 1,000 Android developers is one of the highlights of my year. The lead up to Google I/O involves weeks of late nights and seemingly endless practice and reviews, but the positive reaction from the attendees (and online viewers) makes it worth it.

My first session was the third part of my Android Protips trilogy: Making Apps Work Like Magic. During the keynote Larry Page talked about building things that don't exist - that theme was central to my session. It's easy to get caught up in the details, looking to what others are doing and figuring out how to get just that little bit further ahead of our competition. But in an industry where progress moves so quickly that what we grew up with as scifi becomes reality by the time we're adults, real success means breaking out of that cycle - thinking bigger - and instead of developing apps for the future, defining the future itself.



You can check out the slides - with speaker notes - in this gallery:



Or you can download the deck as a PDF. The code snippets are posted at Android Protips 3: Making Apps Work Like Magic - The Code Snippets for your copy/paste pleasure.

As in the past couple of years, I presented entirely using an Android tablet (the Transformer Prime with HDMI out). The interstitial animations where created by a very good friend of mine -- Pandamusk, with additional music provided by Joel Alford "Bliss".

I also had the pleasure of presenting What's New in Google Play Services with Rich Hyndman.

We offer a brief introduction to Google Play services, how to install and use them, and what was added for Google I/O 2013. We give an overview of each of the new services without digging too deep - so if you're new to Google Play services, or just want to get an idea of which of the deep-dive sessions you should check out, check it out.



I always enjoy the candor and insight the engineering and design leads share during the Android Fireside Chat, and have to admit that it was a little intimidating interviewing that many people, who are so much smarter than me, all at once. I'm pretty happy with how it turned out though, and thought they gave some great answers that help explain where Android is and where it's going.



As a bonus, I also had the chance to interview Android VP of Engineering Hiroshi Lockheimer and Android VP of Product Management Hugo Barra as part of the Google Developers Live clips.



As always, I/O was an exhilirating and it was exhausting. All the videos for all the sessions will soon be available on YouTube and the I/O session pages. Hopefully you find them interesting, educational, and useful - and go out and start building things that don't exist!

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.

Discovery

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.

Support

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.

Books

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.
Apps

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.

Photography

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.


Gadgets

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.

Wednesday, November 09, 2011

Australia in High Dynamic Range

I've been really impressed with the work +Trey Ratcliff has been sharing on Google+, which led to me wondering if HDR might be a way to add some "punch" to my landscape photography. My recent holiday back to Oz offered the perfect excuse to experiment. I've put my best HDR photos so far into this Google+ album.

I've been working on my photography skills for a while now, but there are certain scenes that I've  found particularly challenging. Dramatic sunsets, photos taken in bright sunlight (or towards the sun), or photos taken on dark, gray days have been a struggle to capture adequately on camera.

HDR seemed like a technique that might help me capture on film what I could see with my eyes, and what better place to practice than on a Western Australian beach at sunset?

We also spent some time in Ballarat, over in Victoria. In recent years rural Australia has been known for a crippling drought followed by devastating floods, but when we visited it was a velvet field punctuated by saphires, with the dams and lakes all filled to capacity.

We were staying within the shadow of Mount Buninyong, which provided the perfect opportunity to experiment with some midday shots taken from a high vantage point.

Bird's eye views are always stunning in person, but I've had difficulty turning that view into  interesting photos -- particularly as I seldom make it to these places at dusk or dawn when the natural light would be more favorable.  My initial results were definitely encouraging.

To help experiment, my trusty Canon EOD 500D has an exposure bracketing option that lets me take three consecutive pictures using different exposures. Photoshop comes with an automation plugin that merges multiple exposures to produce HDR images.

I learned a few things from my experience so far. The first - somewhat obviously - is to look for scenes with an abundance of color depth. Rich greens offset by deep blues and grays look fantastic.

Somewhat less obvious is the effect that a hint of rich color can add to an otherwise monochromatic scene. HDR will add layers of depth to grey clouds and dark seas, so a small splash of red or green can produce dramatic results.

I also learned that taking portrait photos in HDR is much more difficult. Close-ups can be incredibly unflattering as skin tones are exaggerated and people start to creep into the uncanny valley.

It's also tricky to photograph scenes with movement. When you merge the images, slight differences are often shown up as artifacts or ghosting. A steady hand is a must (my best results used a tripod), and shooting toward the sun will minimize your exposure times. Looking at the images blown up on my 24" monitor, it's also clear that there are more annoying pixel artifacts, halos, and ghosting that I need to work on to improve the final effect.

Overall, I need to practice to get better results, but I the progress so far is promising and HDR is definitely a tool I'll be adding to my amateur photography tool-belt.

[I've disabled comments here in favour of using Google+. Feel free to join the conversation over there.]

Tuesday, November 08, 2011

Memories in the White Space

A distinct melancholy accompanies me as I sort through the images and artifacts of my youth.


My wife and I left Australia almost 7 years ago. We lived in London and now the Bay Area, but for me home is still Perth. We're back this month—the first time in three and a half years—and I'm using the opportunity to free my parents of some of the detritus I left with them before taking off in 2005.

Our visit has been timed to coincide with the wedding of one of my very best friends. I've been friends with the groom and most of his side of the wedding since our first year at Duncraig Senior High. We were all members of the Academic Extension program (a particularly nefarious way to target those of us most likely to be on the fringes of high school social life and stigmatize us further by segregating us into separate classes.)

When we all get together for some quiet drinks the night before the wedding it's only a matter of minutes before my accent has slowed and thickened, and we're poking fun and chatting as though I'd never left. The same pattern repeats as we catch up with close friends I'm lucky to see every few years. We share a hug and a beer and talk about their new kids, houses, fiances, spouses, and business ventures with an easy comfort that makes it seem like only a or two week has passed since we last hung out.

Back at my parent's house, amongst the polyhedral dice, Star Trek VHS tapes, and school assignments are 10 A3 scrapbooks filled with photographs of me, my friends, and family from birth until I moved out at 21.

I grew up in the age before digital cameras and smartphones captured every moment (magic or otherwise) ready for posting to Facebook. As teenage boys, my friends and I were particularly adept at avoiding my mum's instamatic. As a result, flipping through the stacks of photo albums is a surreal experience. Christmases, birthdays, high school balls, and graduation ceremonies are all captured in full colour—but what strikes me most is the memories that live in the white space between the photos.

A thumb-obscured image doesn't capture the experience of all-night LAN parties spent playing Doom 2. A single photo of us playing pickup basketball (without the hoop in frame) is a faint reminder of the hours spent on court and the four broken arms collected between me and the aforementioned groom during games; plaster-cast testimony to our passion for the game.

A shot of me posing, awkward and gangly, in my inter-school sports uniform captures nothing about the day, but brings back the crowd of apathetic high-schoolers gathering around the high-jump mats, and the rush (and not a small amount of surprise) I felt as they genuinely cheered me on to jump my own height and break the school record.


There aren't any photos to commemorate the long nights spent playing AD&D, or the Friday nights we all spent at WesTrek watching boot-leg videos of each new episode of TNG, but the Player's Handbooks and mountains of Star Trek videos, books, and technical manuals bring back the memories all the same.

20 years. That's how long I've known some of my closest friends. Two thirds of my life. I'm a proper geek, so don't find it easy to build these effortless friendships, so the comfort of sliding back into them is tempered by the knowledge that it'll be years until I can next hang out with some of my best friends.

Email, Facebook status updates, and Google+ will help us stay in touch until the next time we voyage the 8,000 miles back home. When that happens there'll be more kids to meet, new houses to tour, and new businesses to hear about. We'll hug, share a few beers, and it'll be like we never left.

[I've disabled comments here in favour of using Google+. Feel free to join the conversation over there.]

Thursday, July 07, 2011

Obligatory Post Speculating on Google+

I love product launches. It's the perfect time to speculate with no inconvenient research or history to get in the way.

This goes for everything on this blog, but it's probably worth highlighting in this instance that these opinions are my own. They do not represent the thoughts and opinions of Google, the Google+ team, or anyone else who works at Google.

My history of speculating on products tends to be bullish on Google and cynical of social. I thought Android and Wave were going to change the world, and that Twitter was a waste of time.

Twitter with conversations

Despite my initial reservations I'm a big user of Twitter, but I find that most of my interaction there is effectively anonymous - I'm either reading things by interesting people I don't know, or sharing things I think are interesting with people I've never met.

I've found that half my use of Google+ works similarly - by posting publicly and creating a "My Stream" circle full of interesting folks who I don't know personally.

Where I think Google+ adds value is with threaded conversations. By attaching the conversation that emerges from each post, anonymity is reduced and the process of sharing and reading are suddenly more social.

Facebook with sharing controls

I remember quite clearly the moment my use of Facebook went from regular to sporadic. My manager's passing comment on my most recent status update (something along the lines of "I'm so bored I'm considering setting myself on fire just to liven up my day") prompted this blog post.

I've always maintained a policy of only adding people I know and would recognize in person as Facebook friends. Nonetheless, when your extended family, school friends, and current / former work colleagues are all reading the same stream, and seeing the same pictures, the intersection of "appropriate material" rapidly tends towards zero.

Using circles to fragment my audience has been an elegant solution for me.

I've created the obvious circles like "friends", "family", and "Googlers" but I've found smaller adhoc circles particularly useful when socializing

Socializing+

In the paleolithic age we used email to arrange social events and share the photos afterwards, but it never really worked.

Facebook is a good alternative, but it requires adding people you don't necessarily know to your "friends" list.

Being able to create an adhoc circle (or just add individual people to a post) - makes it easy to work out the details for a 4th July BBQ - and then post the photos - all in one place.

I've not spent a lot of time with Huddles or Hangouts yet, but they seem a natural extension. I can see using Huddle instead of SMS to let folks know you're running late, to get parking advice, or confirm the orders for a lunch-run. I've used similar products (most notably Beluga and GroupMe) to coordinate amongst a large group at conferences or events like MWC or Google I/O.

Social photo sharing without wanting to punch your screen

Photos are probably the reason most folks joined Facebook to begin with. It's also the reason many people hate Facebook.

I'll happily rave about the Google+ photo experience which is awesome. It's easy to share photos with just a small group, or post your best amateur photography for the world to critique.

I don't want to be social at work

For all the good uses, let me highlight a couple that I don't see catching on.

I admit to having been a little skeptical of Google+ during the dogfooding stage. With 20/20 hindsight, I think a lot of that had to do with it being effectively a corporate social network. My email inbox is full enough as it is; I really don't need another stream to monitor in order to be involved in work conversations.

This is not a blog

You'll note that I haven't posted this directly on Google+.

I don't want to read your essay in my social stream, just give me an abstract and link to your blog. For added bonus points, make sure your blog links back to your Google+ profile.

In Conclusion

Twitter is entirely public and as a result my interactions there are regular but tend towards the impersonal. Facebook is limited to people I know so the interactions are more personal, but (increasingly) less frequent.

Google+  lets me choose which group of people I'm comfortable sharing something with to a degree that lets me have regular, personal conversations.

As many of you have no doubt noticed - that makes for an addictive combination.

Wednesday, July 06, 2011

London 2005-2011 in Photographs

I really like the photo sharing and viewing experience in Google+ so I decided to sort through my massive collection of "London" photographs and share some of my favorites.

Selecting and preparing photos to share has a way of focussing your attention and allowing you to really look at them critically. As I sifted through the thousands of photographs I'd taken in London it quickly became obvious that I've got some work to do before I'm competing with Romain Guy.

It was also clear that I had a couple of preferred sources of inspiration.

The Seasons

Grey skies and light rain don't make for great photos and an overcast Winter that starts in October and ends around April does little to provide inspiration.

London is blessed with real seasons though, and Autumn and Spring (however brief) are an entirely different matter. They offer some of the most amazing light and color for taking photos. And when it snows? London transforms briefly into a winter wonderland.

By 10am the skies cloud over and the snow turns to mush, so to take advantage you need to be out there at dawn. I worked in banking, so that was never a problem.

Each of the following thumbnails links to a gallery of my pictures of London in Winter, Spring, and Autumn respectively.


The Sights

London has some of the most easily recognized landmarks in the world. Because of the seemingly perpetually grey and overcast skies, lots of tourist snaps come out flat and dull. To get around that I've taken most of them at night or very early in the morning.

Tuesday, June 28, 2011

A Deep Dive Into Location Part 2: Being Psychic and Staying Smooth

This is part two of A Deep Dive into Location. This post focuses on making your apps psychic and smooth using the Backup Manager, AsyncTask, Intent Services, the Cursor Loader, and Strict Mode.
The code snippets used are available as part of the Android Protips: A Deep Dive Into Location open source project. More pro tips can be found in my Android Pro Tips presentation from Google I/O. 
Being Psychic

You've just had to factory reset your device - never a good day - but yay! You've opted in to "backup my settings" and Android is happily downloading all your previously installed apps. Good times! You open your favourite app and... all your settings are gone.


Backup Shared Preferences to the Cloud using the Backup Manager

If you're not using the Backup Manager to preserve user preference to the cloud I have a question for you: Why do you hate your users? The Backup Manager was added to Android in Froyo and it's about as trivial to implement as I can conceive.

All you need to do is extend the BackupAgentHelper and create a new SharedPreferencesBackupHelper within it's onCreate handler.

As shown in the PlacesBackupAgent, your Shared Preferences Backup Helper instance takes the name of your Shared Preference file, and you can specify the key for each of the preferences you want to backup. This should only be user specified preferences - it's poor practice to backup instance or state variables.

public class PlacesBackupAgent extends BackupAgentHelper {
  @Override
  public void onCreate() {
    SharedPreferencesBackupHelper helper = new
      SharedPreferencesBackupHelper(this, PlacesConstants.SHARED_PREFERENCE_FILE);
    addHelper(PlacesConstants.SP_KEY_FOLLOW_LOCATION_CHANGES, helper);
  }
}


To add your Backup Agent to your application you need to add an android:backupAgent attribute to the Application tag in your manifest.

<application android:icon="@drawable/icon" android:label="@string/app_name"
             android:backupAgent="PlacesBackupAgent">


You also need to specify an API key (which you can obtain from here: http://code.google.com/android/backup/signup.html)

<meta-data android:name="com.google.android.backup.api_key"
           android:value="Your Key Goes Here" />


To trigger a backup you just tell the Backup Manager that the data being backed up has changed. I do this within the SharedPreferenceSaver classes, starting with the FroyoSharedPreferenceSaver.

public void savePreferences(Editor editor, boolean backup) {
  editor.commit();
  backupManager.dataChanged();
}


Being Smooth: Make everything asynchronous. No exceptions.

Android makes it easy for us to write apps that do nothing on the main thread but update the UI.


Using AsyncTask

In this example, taken from PlaceActivity, I'm creating and executing an AsyncTask class to lookup the best previous known location. This isn't an operation that should be particularly expensive - but I don't care. It isn't directly updating the UI, so it has no business on the main application thread.

AsyncTask<void, void, void> findLastLocationTask = new AsyncTask<void, void, void>() {
  @Override
  protected Void doInBackground(Void... params) {
    Location lastKnownLocation =
      lastLocationFinder.getLastBestLocation(PlacesConstants.MAX_DISTANCE,
      System.currentTimeMillis()-PlacesConstants.MAX_TIME);

    updatePlaces(lastKnownLocation, PlacesConstants.DEFAULT_RADIUS, false);
    return null;
  }
};
findLastLocationTask.execute();


You'll note that I'm not touching the UI during the operation or at its completion, so in this instance I could have used normal Thread operations to background it rather than use AsyncTask.

Using the IntentService

Intent Services implement a queued asynchronous worker Service. Intent Services encapsulate all the best practices for writing services; they're short lived, perform a single task, default to Start Not Sticky (where supported), and run asynchronously.

To add a new task to the queue you call startService passing in an Intent that contains the data to act on. The Service will then run, executing onHandleIntent on each Intent in series until the queue is empty, at which point the Service kills itself.

I extended Intent Service for all my Service classes, PlacesUpdateService, PlaceDetailsUpdateService, PlaceCheckinService, and CheckinNotificationService.

Each implementation follows the same pattern, as shown in the PlacesUpdateService extract below.

@Override
protected void onHandleIntent(Intent intent) {
  String reference = intent.getStringExtra(PlacesConstants.EXTRA_KEY_REFERENCE);
  String id = intent.getStringExtra(PlacesConstants.EXTRA_KEY_ID);

  boolean forceCache = intent.getBooleanExtra(PlacesConstants.EXTRA_KEY_FORCEREFRESH, false);
  boolean doUpdate = id == null || forceCache;

  if (!doUpdate) {
    Uri uri = Uri.withAppendedPath(PlaceDetailsContentProvider.CONTENT_URI, id);
    Cursor cursor = contentResolver.query(uri, projection, null, null, null);

    try {
      doUpdate = true;
      if (cursor.moveToFirst()) {
        if (cursor.getLong( cursor.getColumnIndex(           PlaceDetailsContentProvider.KEY_LAST_UPDATE_TIME)) >
          System.currentTimeMillis()-PlacesConstants.MAX_DETAILS_UPDATE_LATENCY)
            doUpdate = false;
      }
    }
    finally {
      cursor.close();
    }
  }

  if (doUpdate)
    refreshPlaceDetails(reference, forceCache);
}


Note that the queue is processed on a background thread, so I can query the Content Provider without having to spawn another background thread.

CursorLoaders are awesome. Use them.

Loaders are awesome; and thanks to the compatibility library, they're supported on every platform back to Android 1.6 - that’s about 98% of the current Android device install base.

Using CursorLoaders is a no-brainer. They take a difficult common task - obtaining a Cursor of results from a Content Provider - and implement, encapsulate, and hide all the bits that are easy to get wrong.

I've already fragmented and encapsulated my UI elements by creating three Fragments -- PlaceListFragment, PlaceDetailFragment, and CheckinFragment. Each of these Fragments access a Content Provider to obtain the data they display.

The list of nearby places is handled within the PlaceListFragment, the relevant parts of which are shown below.

Note that it's entirely self contained; because the Fragment extends ListFragment the UI is already defined. Within onActivityCreated I define a Simple Cursor Adapter that specifies which Content Provider columns I want to display in my list (place name and my distance from it), and assign that Adapter to the underlying List View.

The final line initiates the Loader Manager.

public void onActivityCreated(Bundle savedInstanceState) {
  super.onActivityCreated(savedInstanceState);
  activity = (PlaceActivity)getActivity();

  adapter = new SimpleCursorAdapter(activity,
    android.R.layout.two_line_list_item,
    cursor,
    new String[]
      {PlacesContentProvider.KEY_NAME, PlacesContentProvider.KEY_DISTANCE},
    new int[] {android.R.id.text1, android.R.id.text2}, 0);

  // Allocate the adapter to the List displayed within this fragment.
  setListAdapter(adapter);

  // Populate the adapter / list using a Cursor Loader.
  getLoaderManager().initLoader(0, null, this);
}


When the Loader is initiated we specify the parameters we would normally pass in to the Content Resolver when making a Content Provider query. Instead, we pass those parameters in to a new CursorLoader.

public Loader<cursor> onCreateLoader(int id, Bundle args) {
  String[] projection = new String[]
    {PlacesContentProvider.KEY_ID,
    PlacesContentProvider.KEY_NAME,
    PlacesContentProvider.KEY_DISTANCE,
    PlacesContentProvider.KEY_REFERENCE};

  return new CursorLoader(activity, PlacesContentProvider.CONTENT_URI,
    projection, null, null, null);
}


The following callbacks are triggered when the Loader Manager is initiated, completed, and reset respectively. When the Cursor has been returned, all we need to do is apply it to the Adapter we assigned to the List View and our UI will automatically update.

The Cursor Loader will trigger onLoadFinished whenever the underlying Cursor changes, so there's no need to register a separate Cursor Observer or manage the Cursor lifecycle yourself.

public void onLoadFinished(Loader loader, Cursor data) {
  adapter.swapCursor(data);
}

public void onLoaderReset(Loader loader) {
  adapter.swapCursor(null);
}


The PlaceDetailFragment is a little different; in this case we don't have an Adapter backed ListView to handle our UI updates. We initiate the Loader and define the Cursor parameters as we did in the Place List Fragment, but when the Loader has finished we need to extract the data and update the UI accordingly.

Note that onLoadFinished is not synchronized to the main application thread, so I'm extracting the Cursor values on the same thread as the Cursor was loaded, before posting a new Runnable to the UI thread that assigns those new values to the UI elements - in this case a series of Text Views.

public void onLoadFinished(Loader loader, Cursor data) {
  if (data.moveToFirst()) {
    final String name = data.getString(
      data.getColumnIndex(PlaceDetailsContentProvider.KEY_NAME));
    final String phone = data.getString(
      data.getColumnIndex(PlaceDetailsContentProvider.KEY_PHONE));
    final String address = data.getString(
      data.getColumnIndex(PlaceDetailsContentProvider.KEY_ADDRESS));
    final String rating = data.getString(
      data.getColumnIndex(PlaceDetailsContentProvider.KEY_RATING));
    final String url = data.getString(
      data.getColumnIndex(PlaceDetailsContentProvider.KEY_URL));

    if (placeReference == null) {
      placeReference = data.getString(
        data.getColumnIndex(PlaceDetailsContentProvider.KEY_REFERENCE));
      updatePlace(placeReference, placeId, true);
    }

    handler.post(new Runnable () {
      public void run() {
        nameTextView.setText(name);
        phoneTextView.setText(phone);
        addressTextView.setText(address);
        ratingTextView.setText(rating);
        urlTextView.setText(url);
      }
    });
  }
}


Using Strict Mode will prevent you from feeling stupid

Strict Mode is how you know you've successfully moved everything off the main thread. Strict Mode was introduced in Gingerbread but some additional options were added in Honeycomb. I defined an IStrictMode Interface that includes an enableStrictMode method that lets me use whichever options are available for a given platform.

Below is the enableStrictMode implementation within the LegacyStrictMode class for Gingerbread devices.

public void enableStrictMode() {
  StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
    .detectDiskReads()
    .detectDiskWrites()
    .detectNetwork()
    .penaltyDialog()
    .build());
}


The only thing I hate more than modal dialogs in apps is apps that freeze because a network read or disk write is blocking the UI thread. As a result I've enabled detection of network and disk read/writes and reports using a modal dialog.

I've applied Strict Mode detection to the entire app by extending the Application class to instantiate the appropriate IStrictMode implementation and enable Strict Mode. Note that it is only turned on in developer mode. Be sure to flick that switch in the constants file when you launch.

public class PlacesApplication extends Application {
  @Override
  public final void onCreate() {
    super.onCreate();

    if (PlacesConstants.DEVELOPER_MODE) {
      if (PlacesConstants.SUPPORTS_HONEYCOMB)
        new HoneycombStrictMode().enableStrictMode();
      else if (PlacesConstants.SUPPORTS_GINGERBREAD)
        new LegacyStrictMode().enableStrictMode();
    }
  }
}