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!

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.

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();
    }
  }
}

How to Build Location-Based Apps That Don't Suck

If I were forced to choose between a smartphone that could make / receive voice calls, and one with Google Maps - I would choose Maps without blinking.

Here Back in London, getting a reliable 3G connection is a challenge at the best of times - getting one while sat in most venues is about as likely as a South West Trains running a good service. So it doesn't help when I go to view details for, checkin, or review a location and a lack of 3G signal thwarts my efforts.

Whether it's opening a FourSquare app to checkin, or Qype / Zagat / Where to choose where to eat, or the London Cycle Hire Widget to find a Boris Bike - I always feel like a douche standing around with my phone in my hand for half a minute while my phone gets a GPS fix and downloads the nearest locations.

High latency and a lack of offline support in location-based mobile apps is a blight that must be cleansed

Rather than (or indeed: after) shaking my fist at the sky in impudent rage, I wrote an open-source reference app that incorporates all of the tips, tricks, and cheats I know to reduce the time between opening an app and seeing an up-to-date list of nearby venues - as well as providing a reasonable level of offline support.

You can find out more in the associated deep-dive into location on the Android Developer Blog.

Android Protips: Location Best Pratices

It should came as no surprise to learn that I've borrowed heavily from my Android Protips presentation from Google I/O. Including (but not limited to) using Intents to receive location updates, using the Passive Location Provider, using Intents to passively receive location updates when your app isn't active, monitoring device state to vary refresh rate, toggling your manifest Receivers at runtime, and using the CursorLoader.

But Wait There's More!

The post on the Android Developer Blog focusses on freshness - I'll be posting another deep-dive into the code that examines how I've made the app psychic and smooth on this blog early next week. Stay tuned.

Answers to Unanswered Questions from the I/O Protips Q&A

There's never enough time for Q&A at the end of an I/O session - particularly when the session is immediately followed by lunch. In an effort to remedy this, here are the answers to most of the questions that were entered onto the Moderator page for my Android Protips talk.

Eclipse is a wonderful development tool. However sometimes it is clunky. Generic error messages, mysteriously build problems solved by quitting & relaunching, etc. Do you ever get frustrated with Eclipse? Do you have any tips of working with Eclipse?

I do! Almost as much as I was frustrated by Visual Studio in a previous life spent writing C# Winform GUIs. I don't have any specific tips beyond the things that work with mode IDEs. Frequently restart and make sure you're using the latest stable build along with the latest version of the ADT.

Do you have any tips for working with SQLite databases through eclipse? At the minute I rely on external tools to view data that is in the database on the phone to debug problem. This means manually copying it off the device. Any tips?

You can use the sqlite3 command line tool to examine SQLite databases on the phone. It's not built into Eclipse but might save you the extra work of pulling the database off the device first.

Do the developers at Google use any hardware emulators to speed up development. If so, can you please recommend some. The soft emulator is too slow.

Unfortunately not. Generally we'll be working towards the release of the new platform on a given piece of hardware, so the internal teams will use that rather than an emulator where appropriate / applicable.

Will there be a faster Android device emulator anytime soon?

Yes! Check out this session on Android Development Tools for a preview.

Is there a suite of AVDs for Eclipse that emulate actual devices?

Some manufacturers make AVDs available for actual devices (I believe Samsung provide an AVD for the 7" Galaxy Tab). Generally speaking, no - there's no central repository or suite of all actual device AVDs.

Will there soon be a legitimate way to replace the Android lockscreen (with a lockscreen application)?

Due to the security implications, I'm not aware of any plans to make the lock screen (or in-call screen) replaceable.

You mentioned better not to loose your signing key. But how to update your app, when your certificate expired?

For now, certificates used to sign apps launched in the Android Market need to expire after 22 October 2033. We'll have a solution for replacing these certificates in place well before 2033 :)

What's the recommended way to implement a horizontally scrolling, virtualized list?

No simple answer here as it depends on the kind of data you're displaying, how long your list is, and what the best user experience would be. There are some good articles online (including this answer on Stack Overflow) that explain how to create a virtual list in a ListView, but you can use a similar technique within a Gallery or even a HorizontalScrollView to achieve a horizontal virtualized scrolling list.

Are Shared Preferences the bast way to store small piece of data?

It depends on what kind of small data you're storing. Shared Preferences are the best way to store user preferences and Activity / Application state information.

A view from one app needs to be updated by another app. Can't use the widget paradigm, is there any other way?

This depends on a number of factors. Are both apps written by you, or is one a third party? How dramatic are the changes? New layouts or changed text in a TextView?

Generally speaking, the best approach is likely to be a Broadcast Intent. You can package the data that will be used to update the View in the "other" app by including them as extras. The "other" app simply registers a Broadcast Receiver that listens for the Intent, extracts the data, and updates its view accordingly.

How would you test/optimize the apps that are not meant for the Android Market?

The principle of using Analytics for tracking bugs and doing A/B testing works just as well internally as it would on apps that will launch in Market. The biggest difference is distribution. Given the ability to side-load apps onto most Android devices, I'd most likely setup an internal website that would host the APKs you want to distribute for the Beta test.

How can we know if a certain service is already running?

You can bind to a Service using bindService without starting the Service. The Service Connection you pass in to bindService will notify you using its onServiceConnected and onServiceDisconnected handlers when the Service starts and stops. You can use those callbacks to set a variable within your code to check if the Service is running at any given time.

Is there any option to backup the default SharedPreferences via BackupManager? Do I have to use the packagename?

The default SharedPreferences file getSharedPreferences uses the Activity's class name as the preferences name.

Is there a way for accessories to "push" an embedded app or service package to the device so that specialized services for certain types of accessories will be able to automatically add functionality to the device when connected?

As part of the process of starting the device in accessory mode, you send identifying string information to the device. This information allows the device to figure out an appropriate application for this accessory and also present the user with a URL if an appropriate application does not exist. It won't install the package for you, but it will prompt the user to download it.

Just to make sure, now we can send requests to the devices in order to update the info, instead of having the refresh intervals?

That's right, you can use Cloud to Device Messaging to ping a device when it needs to perform an update.

When will we have a UI Builder that is par to what we get for iPhone?!

Check out this session on Android Development Tools for a preview of some of the cool stuff the tools team have been working on.

Can you describe your video and control hookup for your android tablet?

I wrote a blog post that describes the video and control hookup I used to do my presentation using a pair of Motorola Xooms.

Android Protips: Where to Download the Slides and Code Snippets

For those of you who want to take a closer look at my Android Protips session for Google I/O, you can now enjoy the video, slides, and code snippets in whichever format you prefer:

• The slides are now available for viewing and downloading (as a PDF from Google Docs).
• The slides are also available on SlideShare for viewing and embedding.
• The code snippets are posted at Android Protips: The Code Snippets for your copy/paste pleasure.
• The session video is on YouTube (the only way you get to watch the awesome cartoons!)
• After a brief outage, details on the software I wrote to do the presentation are back up.

One of the nice things about SlideShare is that it lets you embed slideshows into your blog post:

I plan to do a series of more blog posts that dig into some of the topics I cover in the presentation in more detail. Where do you guys think I should start?

Android Protips at I/O: The Session Video (and How I Presented It)

[Update 16/May: Reposted after Blogger outage]
[Update 2: Working links to the sessions slides are available from here]

Another Google I/O, another jam-packed Android session room. This year they nearly doubled the room capacity for the main Android track making space for 1,000 seats. That still wasn't enough though - once again people were sitting on the floor and lining up to get in.

Android Protips: Advanced Topics for Expert Android Developers

After delivering my Android Best Practices for Beginners for the better part of last year, I was really excited to take things up a notch and deliver some real advanced content. To push things one step further, I presented my session using a pair of Xoom tablets. More on that after the video.



The awesome video content was created for me by an old friend of mine (he's still young, but we've been friends since high school) pandamusk - thanks panda!

How did you do that?

There were a lot of questions on Twitter asking:

1. What app did I use to do the presentation using an Android tablet
2. How did I live tweet my own presentation in real time?
3. How did I not re-tweet everything when the tablet rebooted?

I'm an engineer so (of course) I took this as an excuse opportunity to write an app that does the former and built in functionality to do the latter (and come on — you think I didn't consider the case of having to restart? Please.)

How does it work?

One app, running on two tablets, both running Android 3.1 (with USB hostmode support) connected via Bluetooth.

Tablet one was wired up with HDMI out and a USB-connected clicker let me transition between slides. I added a "finger paint" View with a transparent background on top of the ImageView that displayed each slide which let me do the real-time annotations.

A second device (out of sight on the lectern) showed me my "Speaker View": My speaker notes, the current / next slide preview, my pre-written live tweets, and a countdown timer.

The two devices were paired and connected over Bluetooth, with the speaker view tablet set up as a slave to the presentation device. Whenever the display tablet transitioned slides, it transmitted the current slide to the speaker view tablet. It works the other way around too, so I can transition slides on the speaker view and have the live view update accordingly.

The tweeting happened on the speaker view tablet based on slide transitions (with a button for me to disable it if — for example — I had to restart half way through). I connected this one to a wired ethernet connection using a USB to ethernet dongle to avoid the notorious conference wifi syndrome.

I've got a bunch of ideas I'd like to incorporate (particularly around remote viewing), but ran out of time before I/O to get them implemented.

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

Yes and yes. I need to make a few improvements before I release it on the Android Market and I need to refactor and tidy the code before I open source it. In the mean time I'll do a couple more posts the go into more detail on how each of the components work. Stay tuned.

How to Get Your Android Protips

I/O is always a great couple of days, and after last year's jam-packed Android room they've doubled our capacity and given us space for 1,000 folks in the audience. As if that wasn't enough, we're also live streaming the Android (and Chrome) sessions for your viewing pleasure.

What Am I Presenting and How Can You Watch?

I'm presenting Android Protips: Advanced Topics for Expert Android Developers at 11:30am PDT in room 11 up on the top floor (next to the keynote room) for those of you lucky enough to be at I/O in person.

If you're not here, you can still watch my session live as it's going to be live streamed across the intertubes (Stay tuned: that page will update when I/O starts in a few short hours).

If you are planning to tune in, that's 7:30pm BST and an ungodly 4:30am on the East coast of Australia.

If you've got questions, and won't be in the audience, you can pose them (and vote for others) on the session's moderator page.

I'm also going to try live-tweeting my own presentation using an Android app I've been working on for presentations (more on that later).

Once I'm done, the recorded video and slides will be available on the Android Protips session page. I'll also post a link to the code snippets for your copy/paste pleasure.

If You Just Can't Get Enough (or You Want to Know How to Avoid Bumping in to Me)

I'm also co-hosting "Web Apps versus Native" on Wednesday afternoon with Michael Mahemoff. Should be a good way to wind down after a long couple of days. When I'm not on stage I'll be hanging out at the Android office hours, so be sure to stop by and say hi!

Using Twitter4J to Tweet in Android

So I'm working on a little project for Google I/O that requires, amongst other things, the ability to post status updates to Twitter from within an Android app. I asked about it on Twitter and a couple of people asked me to post the results (and associated code snippets) so here you go.

I was hoping for a small code snippet that would let me do that without needing any third-party libraries, but the feedback from the lazy web suggested that jumping through the hoops of an OAuth implementation myself wasn't worth the effort.

The wisdom of crowds suggested Twitter4J as a simple alternative - and as the following code snippet shows - the most simple case is pleasantly simple to implement.

Twitter twitter = new TwitterFactory().getInstance();
AccessToken a = new AccessToken(oauth_token, oauth_token_secret);
twitter.setOAuthConsumer(consumer_token, consumer_secret);
twitter.setOAuthAccessToken(a);
twitter.updateStatus("If you're reading this on Twitter, it worked!");

In this instance I'm the only one who'll be using the app, so I'm dropping an auth token and auth token secret unique to my own Twitter login rather than going through the process required to obtain a user-specific auth token. If that matches your use-case you can grab those values by clicking "My Access Token" on the Twitter developer site after you've registered your app.

You can download Twitter4J for Android here. Then just add twitter4j-core-android-2.2.1.jar into your project as an external JAR.

I'm Saying Goodbye to London

Where to next?

Mountain View in sunny California!

Following this year's Google I/O, I'll be relocating to the home of the giant dessert sculpture garden, where I've been given the opportunity to take on the role of Tech Lead for the global Android Developer Relations team.

It's a chance for me to focus on some more strategic ideas and to work more closely with the core Android engineering team. It's a challenge I'm really looking forward to.

I've spent the last 6 years in London - the last 2 working here at Google - and it's been an amazing experience. I'll be leaving the Android developers of EMEA in the very capable hands of Nick Butcher, Richard Hyndman, and Robert Rhode - and I'll still visit, I'm particularly looking forward to this year's round of Google Developer Days.

I'm still working at Google, and I'm still part of the Android team, so being based in Mountain View I'll have the opportunity to meet and work with some of our North American Android devs - so be sure to say hi if you're coming to Google I/O this year.

The move is still some months away, but in the mean time here are some of the things I will (and won't) miss about London, and what I'm looking forward to in California.

Things I'll Miss About London

• World class theatre, restaurants, and concerts all at my door step.
• Living in close proximity to the rest of Europe.
• Proper bacon and real cheddar cheese.
• Seasons (particularly Spring and Autumn).
• The awesome Android developers I've worked with over the last 2 years.
• Full English breakfasts.

Things I Won't Miss About London

• Commuting for an hour every morning, and again every evening.
• The Victoria line and South West Trains.
• Hearing my neighbor snoring.
• Driving in London.
• Black pudding.

Things I'm Looking Forward to in California

• Fruit that tastes like fruit.
• Living on the West coast (the best coast).
• Living in close proximity to an ocean.
• Living in close proximity to the rest of the US.
• Wide roads and cheap(er) petrol gas. 
• American breakfasts.

Using the New Android Market Stats for Fun and Profit

Earlier this week the Android Market Publisher site was updated to include some cool new statistics for your apps. You can now see the user distribution of your app in terms of the countries, languages, operating system versions, and devices on which your apps are running.

Better still, you can compare your app's distribution in each of these categories with the overall distribution for all apps in the Market.

What does this mean?

There are two axes for gaining insight from these figures:

• The distribution of languages, OS versions, devices, and countries of your app users.
• The variance between your app and the overall (expected) distribution.

I looked at the statistics for my three most popular / successful apps: Earthquake, Animal Translator, and Gyro Compass, and have the following observations, conclusions, and action items.

Action Items and Conclusions

• Create a Japanese and Spanish translation of Earthquake.
• Translate Animal Translator into Japanese.
• Modify culturally sensitive place names for Korean users.
• Confirm Earthquake works on small-screen devices.
• Drop platform support for Android 1.5 and 1.6 on Animal Translator.
• For new apps, it's may not be worth supporting Android 1.5 or 1.6.
• For new apps, it's worth launching with localized language support for Korean and Japan.
• When promoting apps, be aware of time-zones.
• Build tablet-targeted versions now to get first-mover advantage.

Observations: Location and Language

• All my apps do disproportionately well in the UK. I'm based in London, so it's likely that my tweeting and blogging have driven more people in my time-zone to my apps.
• The proportion of Japanese and Korean users is effected by how long the app has been around. The older apps have disproportionately more US users and fewer Japanese and Korean users, so  for new apps it's worth building with Japan and Korea in mind at launch. 
• Japanese users account for 10% of Animal Translator users (double the normal distribution). They clearly like the concept, so a japanese language version should help drive popularity.
• Around 70% of Earthquake! users are from the US (expected distribution if 60%). This is likely due to a lot of Android users in the San Adreas fault cities of San Francisco and Los Angeles.
• Earthquake has 1.5% South Korean users versus an average of 10%. Many South Korean users have complained about the USGS use of the name "Sea of Japan" which they believe should be "East Sea". This appears to have a direct impact on their usage of the app.

Observations: OS Versions

• My apps show a trend where older apps have disproportionately more 1.5 / 1.6 users, and new apps have disproportionately fewer. This seems to suggest that owners of these older devices aren't downloading as many new apps. As a result, it might not be worth supporting 1.5 / 1.6 users for new apps.
• Earthquake! already has 0.2% of users running Android 3.0. This suggests that building tablet-optimized versions now can give you first-mover advantage.
• Only 8 people are running Animal Translator on a device running 1.6 or earlier, so I can probably drop support for for < 2.0 in the next update.

Observations: Devices

• Based on the devices, there are no small-screen Earthquake! users. Does the app work on small screens?
• The popularity of devices seems heavily affected by the country distribution of users. For my apps the HTC EVO 4G and Droid series of devices seem very popular in the US, with the HTC Desire and Samsung Galaxy S very popular in Korea and Europe.

What patterns did you see?

What observations and patterns did you find looking at your app statistics?

The Rise of the Tablet and the Innevitable Death of the Netbook

Last week I added a 10.1" Motorola Xoom to my gadget bag at the expense of a Netbook. As tablets grow in popularity I predict the Netbook's days are numbered.

Shortly after buying an Asus EeePC 701 in 2008 I described it to anyone who would listen as the best technology purchasing decision I'd ever made. It cost £200, was thin, light, and cheap. It booted Windows and loaded Office in under 10 seconds - only the paltry 800x600 display resolution was a legitimate cause of grief.

I used it to write most of my first book during my daily commute, and it was light and thin enough for me to throw in my bag for holidays or trips where I wasn't keen on bringing my laptop along (at the time my laptop was as 17" Vaio desktop replacement that weighed the better part of a metric fucktonne).

Light and with a full-day battery life,  Netbooks were a cheap second computer for lightweight computing tasks and surfing the web.

A one trick pony

Growing up, my parents ran a typewriter sales and repair company. I watched as the typewriter was gradually (and then very quickly) replaced with the desktop computer. For a small while "word processors" were a popular alternative - significantly cheaper than computers, and with most of the features of Word Perfect 5.1.

As PCs, laptops, and printers become cheap and ubiquitous, word processors grew more fanciful in an effort to compete. They offered more fonts and options but at a higher price. Before long, like most one-trick ponies, it was quietly covered with a sheet and put out of its misery.

I had a distinct feeling of deju-vu when late last year  I went in search of a replacement for my EeePC in the hopes of finding something cheaper, lighter, and a little faster. Instead I was presented with devices that were:

• More expensive.
• Thicker and heavier.
• Slower to load and lacking SSDs.

At the same time, my new Macbook weighs around two kilograms and is no more than an inch thick. I can use it to write my book, write my code, edit photos, and pretty much anything else I could want to do.

It's true that a MBP is a lot more expensive than a Netbook - and bulkier - but it's not as though you would buy a Netbook instead of a real laptop. It's an additional device, so it's actually competing with tablets or smartphones - and a smartphone / tablet combo has a lot more to offer.

Smartphones and tablets make Netbooks a quaint irrelevancy

Modern smartphones, led by iPhone and Android, have largely filled the niche of mobile web browsing.

The arrival of the tablet is the final nail in the coffin, with a 10" tablet neatly filling the gap between smartphone and laptop.

With bright, high resolution displays, tablets offer an unparalleled experience for watching video. Games designed for tablets are created specifically for portable hardware featuring a touch screens and accelerometers. Similarly the rich ecosystem of apps is optimized specifically for smartphone and tablet platforms.

Typing on a 10.1" touchscreen is certainly no worse than typing on an undersized Netbook keyboard. Walking into meetings these days I'm increasingly finding people have left their laptops behind and are instead bringing along their tablets.

If you need to type, bring a laptop. If weight is an issue, bring your tablet

Tablets provide an optimized experience for portability, mobility, and touch-based input with a rich selection of apps and games designed with their size and power in mind.

Laptops are cheaper, lighter, and more powerful than ever before. They offer a rich ecosystem of apps and provide the perfect platform where text input is required.

Netbooks can still provide a great platform for getting online, but so can laptops and tablets. Laptops may one day give way to tablets and smartphones entirely, and apps may move entirely online, but Netbooks - like word processors in the 80's - will inevitably fall victim to competitors that offer a more dynamic ecosystem of apps, games, and features at an increasingly comparable price.

Mobile World Congress: Slides, Smoothies, Collectable Pins, and Gadgets Galore

On the scale on which these things are measured, Mobile World Congress doesn't have a reputation for being a "fun" event. Exciting, vibrant, interesting, and worthwhile - sure. But the number of suits and ties in attendance generally precludes the sort of party atmosphere people expect at events like SXSW or Google I/O.

Less fun, that is, until now

It turns out that if you want to see serious folks in serious suits take a ride down a slide all you need to do is build it: and they will come.

By 9:30 on Monday morning the pristine environment of the Android stand - tucked away in a corner of Hall 8 - was a heaving mass of developers, CEOs, reporters, and collectable pin enthusiasts.

The Android stand (here's some more pictures) at MWC was all about openness and inclusion. The highlight for me was the 40 or so 3rd party developers who (rightly) stole the show. They worked tirelessly, demonstrating their apps and showcasing just what's possible on the Android platform. Developers take note: this could be you next year.

Typically at MWC Tuesday is the busiest day, with Wednesday tapering off and Thursday seeing the halls empty and abandoned by midday. Not this year. The stand was packed every day from 9:00 when they opened the gates to 7 when they flashed the lights. Even on Thursday when most stands are rolling up the carpet after lunch, we had a full house until the lights went off at 4pm.

Android Gurus, 3rd party developers, and a device bar with over 80 different Android powered handsets kept the crowd entertained. The obligatory slide was in constant use, and free smoothies (the Honeycomb - flavored with honey and lychee - was my pick) were on offer served by a bevy of friendly antipodean bartenders, who towards the end of the event served as the kingpins of a roaring trade in collectable Android pins.

Have you got any pins?

So it turns out that all you need to transform a clean-cut three-piece-suited CEO into a screaming fanboi is the introduction of limited edition Android collectable pins.

What started as a curiosity on day one exploded into full-blown pin-mania by Tuesday. There were 86 of these on offer at MWC - here's a few of my favorites.

Of course what we're really here for is the gadgets

And we weren't disappointed. There were some great new handsets on display this year, including LG's fascinating Optimus 3D features a 3D display that doesn't require special glasses.

The Samsung stand was a gold mine of awesome sauce with the frankly stunning Galaxy S II and the Honeycomb-sporting Galaxy Tab 10.1 tablet. As usual the screens on these devices where gorgeous - and the 10.1" Galaxy Tab was surprisingly light - I'd like to spend a little more time with both.

Tablets were the big news of the show, with the Samsung Tab 10.1 and the LG G-Slate joining the Motorola Xoom as forthcoming tablet devices running Android Honeycomb. HTC's also announced their first Android tablet (the HTC Flyer), a 7" tablet that will apparently run Gingerbread before receiving an OTA update to bring it up to Honeycomb.

I'm a fan of HTC's industrial design, so I'm excited to see what they come up with in the tablet market.

A+++ Would attend again

Any trip to Barcelona means great food and plentiful drink and this visit was no exception.

While in Barcelona I had the great pleasure of hanging out with the folks who make up the Barcelona GTUG. These guys are as awesome as they are welcoming. MWC is famous for its extravagant parties but hanging out with these guys in a crowded local bar was a definite highlight.

Between the fun of the Android stand, the excitement of getting to play with new toys, and the gluttonous pleasure of Spanish cuisine it was an incredible experience. The only question now is how do we top it next year?

Only time will tell, but I saw the designers behind this year's stand sketching plans for a two story slide...

Strategies for Honeycomb and Backwards Compatibility

Each new Android release heralds two things: A raft of new developer APIs, and a chorus of questions on how to use them while staying backwards compatible.

Android 3.0 (Honeycomb) is notable in that it introduces Fragments, possibly the most fundamental change to how Activity UIs are constructed since Android 1.0. To add to the excitement, Honeycomb is also the first Android platform release optimized specifically for extra-large screen (tablet) devices.

The good news is that we plan to have the same fragment APIs available as a static library for use with older versions of Android; the plan is to go right back to 1.6.

The easiest short-term fix is to create separate sets of Activities

When the static Fragments library becomes available you'll be able to skip this step entirely (or simply deprecate these Activities from your application). 

The introduction of Fragments (and to a lesser degree the Action Bar) represents a significant change to the code the lives within your Activity classes.

The following technique demonstrates how you can  create two separate sets of Activities: one set that supports Fragments and another set that is designed to work without them.

To select the right set of Activities at runtime, you need to include a launcher Activity in your manifest that detects support (or lack thereof) for Fragments and then starts the appropriate Activity.

<activity
  android:name="InitialActivity"
  android:label="@string/app_name">
  <intent-filter>
    <action android:name="android.intent.action.MAIN" />
    <category android:name="android.intent.category.LAUNCHER" />
  </intent-filter>
</activity>

Within InitialActivity, you can use reflection to check if Fragments are supported on the current device.

  private static boolean fragmentsSupported = false;

  private static void checkFragmentsSupported() throws NoClassDefFoundError {
    fragmentsSupported = android.app.Fragment.class != null;
  }

  static {
    try {
      checkFragmentsSupported();
    } catch (NoClassDefFoundError e) {
      fragmentsSupported = false;
    }
  }

Then within onCreate forward the application to the "real" first Activity that either uses Fragments or not depending on the capabilities of the device.

  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    Intent startActivityIntent = null;
    if (!fragmentsSupported)
      startActivityIntent = new Intent(this, MainNonFragmentActivity.class);
    else
      startActivityIntent = new Intent(this, MainFragmentActivity.class);

    startActivity(startActivityIntent);
    finish();
  }
}

Because you're calling finish immediately after starting the new Activity, the back button behaviour of your application works as expected.

Within the MainNonFragmentActivity you simply inflate a layout resource that doesn't use Fragments

setContentView(R.layout.non_fragment_main);

While the MainFragmentActivity inflates a layout that does.

What about the rest of the Honeycomb APIs?

The upcoming static Fragment library means you probably won't need to implement the previous technique in order to use Fragments as the building blocks of your UI, but what about the other new Honeycomb APIs like the Action Bar and Animators?

Let's ignore the non-Fragment Activities and focus on the scenario where Fragments are available, but none of the other Honeycomb APIs are.

The first step is to determine the availability of the new APIs. You can implement the same exception catching technique I used above for each of the classes you wish to use, but I've found it simpler to bundle all the new APIs together and build only two variations:

  private static boolean shinyNewAPIsSupported = 

    android.os.Build.VERSION.SDK_INT > 10;

Maintaining two sets of Activities doesn't require a parallel set of Fragments, layouts and resources

Once again, I'm going to create a parallel set of Activities: One that uses the shiny new APIs like the Action Bar and animations, and another that uses traditional techniques to create a similar user experience.

The technique described above can be used in the same way - this time using the shinyNewAPIsSupported variable to determine which Activity to start.

Because most of the user-interface logic is contained within the Fragments rather than the Activity, these parallel Activities don't do much beyond inflate slightly different layouts. Where the Action Bar is available the Activity will handle the effect of navigation and action clicks. If the Action Bar isn't available, the layout used will likely incorporate a custom version that mimics its behavior.

Only the highlighted ActionBarFragment in the following snippet would be different between the pre- and post-Honeycomb app layout.

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
  android:orientation="vertical"
  android:layout_width="fill_parent"
  android:layout_height="fill_parent">
  <fragment class="com.paad.hc_backwards.ActionBarFragment"
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content"/> 
  <LinearLayout
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    <fragment class="com.paad.hc_backwards.SelectionFragment"
      android:layout_weight="3"
      android:layout_width="fill_parent"
      android:layout_height="fill_parent"/>
    <fragment class="com.paad.hc_backwards.ContentFragment"
      android:layout_weight="1"
      android:layout_width="fill_parent"
      android:layout_height="fill_parent"/>
  </LinearLayout>
</LinearLayout>

The key is that both sets of Activities will use the same fragments. Interaction between and within Fragments is usually maintained within each fragment, so only code related to the Action Bar (and other missing APIs) will need to be changed within the two Activity sets.

I expect all the apps I use on my phone to be optimized for tablets

Now lets take a look at the changes inherent in the introduction of the extra-large display. Fragments are designed specifically to make it easier to create flexible layouts, so I'm going to assume the existence of either Honeycomb or the static Fragment library when considering our options.

Device independent pixels (dp) and flexible layouts (like Relative Layout and Linear Layout) let your app scale to the dimensions and orientation of tablets. However, an app running on a 10" landscape device 1280 pixels across has a hell of a lot of whitespace when it was designed for a 4" portrait display at 480 pixels.

Consider the typical app design pattern where making a selection on one Activity determines what content is displayed another. Making a selection hides the selection Activity and displays the selected content.

Using Fragments you can easily construct layout variations for different screens

On a tablet it makes sense to position the selection and content Fragments within a single Activity, while on a phone only one should be visible at a time.

You can handle this as we did pre-Honeycomb by creating a res/layout-xlarge resource folder into which we put the side-by-side layout to use on an extra-large (tablet display).

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
  android:layout_width="fill_parent"
  android:layout_height="fill_parent">
  <fragment class="com.paad.hc_backwards.SelectionFragment"
    android:id="@+id/selection_fragment"
    android:layout_weight="3"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
  />
  <fragment class="com.paad.hc_backwards.ContentFragment"
    android:id="@+id/content_fragment"
    android:layout_weight="1"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
  </fragment>
</LinearLayout>

In practice, we'll usually want to define a portrait and landscape specific mode using port or land resource qualifiers:

res/layout-xlarge-port
res/layout-xlarge-land

For phones, we'll use the same Fragments, but the layout (stored in res/layout) would contain only one Fragment stored in a containing layout.

<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
  android:id="@+id/selection_fragment_frame"
  android:layout_width="fill_parent"
  android:layout_height="fill_parent">
  <fragment class="com.paad.hc_backwards.SelectionFragment"
    android:id="@+id/selection_fragment"
    android:tag="full_screen_fragment"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
  />
</FrameLayout>

Within our code this produces a dilemma

The selection and content Fragments will interact slightly differently in phone or tablet mode. In both cases, making a selection should be reflected in the content Fragment - however in the phone layout this should also replace the selection Fragment with the newly updated content Fragment.

public void makeSelection(int i) {
  boolean extraLargeScreen = getResources().getConfiguration().screenLayout >
                            Configuration.SCREENLAYOUT_SIZE_LARGE;
  if (!extraLargeScreen) {
    FragmentTransaction ft = fragmentManager.beginTransaction();
    ft.hide(selectionFragment);
    ft.add(R.id.selection_fragment_frame, contentFragment);
    ft.addToBackStack(null);
    ft.commit();
  }
  contentFragment.setSelection(i);
}

Note that by calling addToBackStack we ensure that pressing the back button will undo this transaction, hiding the content Fragment and displaying the selection Fragment.

Fragments are a great way to componetize your UI

The new Android 3.0 (Honeycomb) SDK introduces a number of great new APIS, many of them designed to make it easier to build tablet version of your apps by providing a flexible mechanism for building different layouts depending on screen size and orientation. The availability of a static Fragment library will simplify the process of creating flexible layouts that are backwards compatible.

It is my firm belief that any app developed for mobile should be available for tablets. When I put my credentials into a shiny new tablet, I expect it to install all the apps I use on my phone - and I expect all of them to be optimized for the tablet form factor.

That's not to say you shouldn't create apps that are designed to work only on tablets, but I believe these tablet-specific editions should be made available side-by-side with phone versions that have been optimized to work on tablets.

Android Web Market, In App Billing, and Buyer Currency

Today during the Android Honeycomb Event we launched a couple of really exciting new features Android. As well as a closer look at what's possible with the Honeycomb SDK, we also announced:

• Web-based Android Market
• In App billing
• Buyer currency support

There's more details on all three at the Android Developer Blog, and you can watch the launch event on YouTube.

Web Based Android Market

This is long awaited and seriously cool. Finally we developers have a homepage on the web for our Android apps. Not only that, but now we can install apps OTA simply by pressing install and the app of our choice will be automagically pushed to our phone.

My question to you: Have you uploaded the 512x512 alpha blended app icon and 1024x500 full bleed feature graphic? If the answer is no, then you have (at best) a 72x72 icon stretched into jaggy hell representing your app to would be users. That's probably something you want to do something about sooner rather than later.

To celebrate web landing pages for apps I've put together this list of the apps that I've been using on my Android devices.

Buyer Currency Support

You can now specify different prices for different currencies - and even more importantly, as a result users will always see the app priced in their local currency. No more "~" symbols or strange foreign currencies.

In App Billing

More ways for developers to monetize their apps can only be a good thing. A simpler purchase process for users benefits everyone.

Android App Surgery: Earthquake Redux (Honeycomb Tablet Edition)

If you follow me on Twitter you'll know I spent a great deal of the week before last firmly in The Zone, lost in the joyful exuberance of writing code. What I was working on? I was exploring the many and varied Android 3.0 (Honeycomb) SDK APIs.

To celebrate the Honeycomb preview SDK I'm doing an Android App Surgery that explores how I modified my existing Earthquake phone app for Honeycomb tablet devices. If you're interested in seeing more of these, nominate an app for review!

The App: Earthquake! (Tablet Edition)

I've taken the tablet redesign as an opportunity to implement many of the ideas that came up during my original Earthquake App Surgery. Chief amongst them was to improve the user experience, so I enlisted my colleague Roman Nurik to help me create a more polished design.

As well as a tasteful and distinctive red and white theme, this new UI style incorporates the Action Bar design pattern that simplifies navigation and highlights the refresh action. Small touches like the Level List Drawables used to indicate the relative size of each quake, the improved layout of each List View Item, and the introduction of the detail view work together to produce an app the is far more polished and intuitive.

Here's something I prepared earlier

The tablet design incorporates the distinctive new theme and List View Item layout, while the extra screen size lets me pull all three Activities (map, list, and details) into a single layout using Fragments.  In Honeycomb the Action Bar is a standard application component; I've customized it to use my theme and support my preferred navigation style and common actions.

 The defining feature of the tablet is its extra large screen

...or how I learned to stop worrying and love Fragments

The most pressing issue for most developers will be making effective use of an extra-large display. Fragments let you structure your Activities into separate interacting components.

You can easily rearrange, replace, show, and hide individual Fragments based on screen size, orientation, or user interaction. This is really useful for designing apps to support different screen sizes, or creating different layouts for portrait versus landscape.

Each Fragment encapsulates a piece of application UI and the associated functionality. Like Activities, the visual layout for each Fragment is defined in layout XML files. Typically the Activity layouts for landscape, portrait, and different screen sizes simply rearrange how the same Fragments are laid out.

I've used three Fragments plus the Action Bar. One to display the list of earthquakes, another to show the map, and a third to display the selected details.

For many tablet devices landscape will be the default orientation, so my primary design for Earthquake is landscape, but it's important to also create a compelling portrait mode.

Like Activities, each Fragment has its own lifecycle. You use the life cycle events to to save state and connect/disconnect listeners and receivers just as you used to do within Activities.

Each fragment can access its parent Activity by calling getActivity, and each Activity can find any of its Fragments with findFragmentById. This lets Fragments interact with each other regardless of their visibility or how they're laid out within an Activity.

Fragment Transactions let you modify the screen layout in real-time in response to user actions

You can show, hide, or replace individual Fragments at run time to create dynamic, interactive displays. In Earthquake I use Fragment Transactions to replace the details Fragment whenever a new quake is selected, and to hide the list and details fragments when the app switches to full screen.

FragmentTransaction ft = getFragmentManager().beginTransaction();
ft.hide(listFragment);
ft.commit();

The Fragment framework also lets you set breadcrumbs as you show, hide, or replace Fragments that allow cause the back button to revert the last transaction. In many cases your application will now contain a single Activity with a number of Fragments that are displayed, hidden, or replaced based on user navigation.

In Earthquake, for example, the normal (phone sized) UI layout would have a single Activity with the list Fragment visible at launch. Clicking a quake would replace the list with the with this transaction being added to the back stack so that a user pressing back returns then to the list view. I'd probably also use Tab Navigation in the Action Bar to let users switch between the map and list views.

The New Navigation: Introducing the Action Bar

The Action Bar component is a navigation panel that replaces the old title bar at the top of every Activity which neatly formalizes the emerging "Action Bar" design pattern. It's possible to hide the Action Bar, but best practice is to keep it and customize it to suit the style and navigation requirements of your app.

I started by applying a custom gradient to the background.

final ActionBar ab = getActionBar();
final Resources r = getResources();
final Drawable myDrawable = r.getDrawable(R.drawable.gradient_header);
ab.setBackgroundDrawable(myDrawable);

Next is navigation. There's a number of options for navigating your application - the two most common are tabs and drop down lists. I've used a drop down so users can choose the minimum magnitude of quakes to display. I might add a second drop down to also view quakes based on distance.

Here's how I create the drop down list and set the navigation mode on the Action Bar to display the drop down list.

ArrayAdapter mSpinnerAdapter;
mSpinnerAdapter = ArrayAdapter.createFromResource(this,
  R.array.magnitude_options,
  android.R.layout.simple_list_item_multiple_choice);
ab.setListNavigationCallbacks(mSpinnerAdapter, mOnNavigationListener);

ab.setNavigationMode(ActionBar.NAVIGATION_MODE_DROPDOWN_LIST);

The standard menu button has been deprecated in Honeycomb, in it's place is the on-screen menu icon at the far right of the Action Bar. The icons to its left are Menu Items that represent common actions.

To make them appear as Action Bar icons, you just flag them as SHOW_AS_ACTION, SHOW_AS_IF_SPACE, or SHOW_AS_ACTION_WITH_TEXT which will make their icons visible, visible only if there is enough space, and/or with the menu text visible respectively.

fullScreenMenuItem.setShowAsAction(MenuItem.SHOW_AS_ACTION_ALWAYS);

Animations that are smooth like butter

One of my favourite Honeycomb APIs is the new Animation framework. It boldly promises nothing less than the ability to animate any property on any object, and it delivers on that promise spectacularly.

The original idea for Earthquake was based on an inspiring exhibit at the New York Natural History Museum. It used animated expanding circles to dramatically illustrate the size and location of earthquakes and their relative timing.

I can now achieve the same effect by creating an Object Animator that animates the Image Level property of the Scale Drawable objects used to illustrate the felt radius of each quake.

final ObjectAnimator oa = new ObjectAnimator();
oa.setDuration(3*1000);
oa.setIntValues(0, 10000);
oa.setTarget(eachExandingCircle);
oa.setPropertyName("ImageLevel");
oa.start();

The silky smooth transition in and out of full-screen mode is also animated using an Object Animator. This time I'm animating the Layout Parameters of the Activity layout to adjust the relative weight of the list and map Fragments.

The animated transitions between detail Fragments are managed by a Fragment Transaction. I simply specify the fragment to replace, what to replace it with, and what animation to use for the transition.

DetailsFragment newFragment = DetailsFragment.newInstance(quake_id);
FragmentTransaction ft = getFragmentManager().beginTransaction();
ft.setCustomAnimations(R.anim.slide_in_left, R.anim.slide_out_right);
ft.replace(R.id.details_fragment_container, newFragment, "detailFragment");
ft.commit();

Still to do...

I'm pretty happy with the styling and user experience so far, the next step is to incorporate the significant improvements to the Widget and Notification APIs.

Before launch I'll create a new list-based widget of recent quakes and an enhanced notification layout.

Get Your App Reviewed!

If you'd like to see how your app might look and work on a Honeycomb tablet, you can self-nominate at the moderator site. You can also go there to vote for which app you'd like to see reviewed! If you've got questions about developing for Honeycomb, head to StackOverflow and mark your questions with the Android and Honeycomb tags.