Wednesday, September 24, 2014

Devoxx 2013 Presentations

All of the talks from Devoxx 2013 are now freely available on the website. This includes all of the talks that I did with Romain Guy on Android:
Filthy Rich [Android] Clients
What's New in Android
Android Performance Workshop Part 1
Android Performance Workshop Part 2

There's also an interview about the new features in KitKat.

Then there's this somewhat less relevant Patterns, Shmatterns talk I did about software design patterns.

All of the slides from the Android talks are posted on Romain's blog.

Friday, June 27, 2014

Google I/O 2014: Rehash

All of the videos have been posted from the various sessions I was in this year. Here they are, along with links to the slides.

What's new in Android

A presentation with +Dan Sandler that provides a quick overview of some of the larger features and new APIs in the L Developer Preview release and other new bits in the recent Androidosphere. There's also a really good deep-dive into Notifications, since Dan's the non-local expert on the subject.

Slides (PDF)

Material science

This session, presented with +Adam Powell, provides an overview of the engineering side of the Material design system. Many of the other sessions at Google I/O this year discussed the design side; this presentation covers the technical details of the APIs and the capabilities exposed by the framework for Android developers.

Slides (PDF)

Material witness

I was happy to be joined once again by former Android developer and UI Toolkit team lead +Romain Guy for this talk on some of the new Material design elements in the L Developer Preview release. The idea behind this talk was to go a bit deeper into using and explaining the new APIs, as well as explaining how some of the features, like realtime soft shadows, work.

For slides as well as demo code, check out Romain's blog at

Android fireside chat

This session, organized and moderated by +Reto Meier, I found to be more interesting than other such panels I've seen. Often, these things tend to have a lot of awkward silences as the panelists try to figure out the most interesting way of saying "No comment" since there's a general policy on Android of not talking about future development plans. This time, there was a lot of discussion around how and why some parts of the system work, which I enjoyed as an audience member that just happened to be sitting somewhat closer to the panel.

Friday, March 7, 2014

Android Developers Backstage: The Podcast. Episode 5 and Counting

In an earnest attempt to reach more people (or perhaps a desperate attempt to build up a larger audience) I though it would be good to post this reference to the existing five (5) episodes of the podcast that Tor Norbye and I have been working on for the past several weeks. And by "working on," I mean we get together every 2-4 weeks, sit down with someone interesting on one of the Android development teams and talk about technology and APIs that interest us, and then let someone else figure out the tedious details of actually recording and posting the results. So it's not really work as much as work-related.

The goal of the podcast from the beginning was to have conversations with engineers and teams that listeners might not otherwise know and to talk about details of features and functionality of the Android platform that might not be obvious from simply reading the documentation. Because, hey, who reads the docs anyway, right?

So far we've released five (5!) episodes, although there is a rumor that there is already a sixth (6th!) episode (already recorded!) that is being closely held onto until an undisclosed date (soon!) with a secret person (Dr. Daniel Sandler!) talking about a mysterious project on Android (the System UI!), so who knows where things will go from here? (Maybe to Fresno!)

Since you're probably dying of too-much-text and too-few-links, here is the huge list of episodes so far:

Episode 1: KitKat (with your hosts, Chet and Tor)
Episode 2: Storage (Tor, Chet, and Jeff Sharkey)
Episode 3: Security (Chet, Tor, and Adrian Ludwig)
Episode 4: Google Play Services (Tor, Chet, and Jeff Hamilton)
Episode 5: RenderScript (Chet, Tor, and Tim Murray)
Episode 6: THERE IS NO EPISODE 6!!!!!! (yet)

The feed itself is available through Feedburner, and of course the podcast is also in iTunes for those that live their audio lives there.

By the way, if you have suggestions about teams, individuals, or technologies that you would like to hear more about, please leave a comment. We have a pretty much infinite list of people that we're going to try to get onto the show, but we're open to suggestions.

Wednesday, November 27, 2013

Android Developers Backstage: The Podcast

Are there any geeks out there interested in new podcasts? What about podcasts about Android development?

Tor Norbye and I are proud to announce a new podcast we've started called Android Developers Backstage. It's a podcast by and for Android programmers, featuring engineers on the Android team at Google talking about features, APIs, and technologies that we think are important for developers to know about. Or which we find interesting. Or which randomly happened to come up on the show.

If your podcast client still has room and you have an extra half-hour (ish) every month (ish), then subscribe and tune in. You can find the podcast on Feedburner. Just click on one of the various links on that page to add it to your podcast client of choice.

The inaugural episode is about Android KitKat, with Tor and I talking about some of the new features in the latest release. In future episodes of the podcast, we'll interview other engineers on the team to deep-dive technologies they've worked on. Android development info, straight from the source.

Thursday, October 31, 2013

Android KitKat: Developer Info

We just released Android KitKat and posted lots of information about it:

Developer highlights:

Android Developers Blog:

Videos (an overview one plus lots of others that dive deeper into specific features):

I'll specifically call out the video on Transitions, which is something I recorded last week after finally finishing the feature. I hope that the API is another step toward making animations easier and more automatic in Android applications.

Thursday, September 12, 2013

Lazy Lists

Let's talk about laziness. No, let's not just talk about being lazy - let's do something about it. Let's be lazy.

There's a common pattern that I use in Android programming where I will create objects lazily, especially when these objects will not necessarily or frequently be needed at runtime. This is especially true for code that I write for the Android framework, where we like to be as lean as possible and leave more memory available for the system and the application.

Often, these objects are collections. My personal favorite is ArrayList (ever since I moved on years ago from the original, but somewhat crusty, Vector class), although I am also known to use Hashmap for those key/value pair situations (especially after I got used to ActionScript's paradigm of everything-is-a-hashmap).

Of course, you can't simply start poking into a lazily-created collection willy-nilly, unless you're a big fan of NullPointerExceptions. So you need to first check whether the thing is null, and then create it as necessary. Similarly, if you're removing an item from the collection, you might want to check if it's now empty and reset the field to null again.

None of this is difficult... but it is tedious. And it tends to bloat the code that you have to read and write and maintain all over the place. And it's exactly the kind of thing that is easy to get wrong because your mind just blurs over the repeated pattern like it's yet another pile of dirty laundry next to the bed.

So I wondered if there was a way I could encapsulate the behavior I wanted to make my laziness easier, simpler, and more readable. And it turns out there was such a way (or else this would be a very short article that would have ended right around... now).

But first, let's look at the problem a bit more, to understand what we're trying to fix.

I have a class called LazyLists with a couple of List fields and some methods for adding and removing items of various types. First, there are the fields:

List<Integer> intList = null;
List<Float> floatList = null;

Then there are add/remove fields for the int/float types I care about:

public void addItem(int item) {
    if (intList == null) {
        intList = new ArrayList();
    if (!intList.contains(item)) {

public void removeItem(int item) {
    if (intList != null) {
        intList.remove((Object) item);
        if (intList.isEmpty()) {
            intList = null;

public void addItem(float item) {
    if (floatList == null) {
        floatList = new ArrayList();
    if (!floatList.contains(item)) {

public void removeItem(float item) {
    if (floatList != null) {
        if (floatList.isEmpty()) {
            floatList = null;

There are a few things to notice about these methods:
  • There's all of that boilerplate code I mentioned before that lazily creates and nulls out the appropriate list based on the state of the list at the time. This is what we'd like to clean up, since this code is repeated as many times as we have to access these list fields.
  • I run a uniqueness check in the addItem() methods because it suits me; I only want to add unique items, not the same items over and over. That's kind of a detail that's specific to my situation, but produces more boilerplate that I'd love to get rid of.
  • There an interesting nuance to the int variation of removeItem(). Do you see it? It's the cast to Object prior to removing the item from intList. This is because of the awkward crossover between primitive types (int, float, etc.) and Object types (Integer, Float, etc.) in Java. There are actually two remove() methods on List, one that takes an int and one that takes an Integer. The one that takes an int removes the item at that index, whereas the Integer variant removes that item itself. That's a pretty huge distinction. And maybe it's well-known to you if you've worked with Lists and ints, but I hit it when working on this example, and thought it was interesting enough to call out.
Anyway, moving on.

We can call the methods above and produce lists that dynamically change with the items that we add/remove. For example, this code creates the class, adds items to the two lists, and removes those items:

LazyLists lists = new LazyLists();

Adding a bit of tracing code gives us this output:

starting lists = null, null
populated lists = [0], [1.0]
ending lists = null, null

So there's not too much cruft above, but I figure the second time I'm repeating the same code, I should think about refactoring it in a way that avoids the repetition. And it's easy to imagine that there might be several places in real code that wants to add/remove items, or several different types going into several different types of collections. Then it's easy to see the little bits of repeated code above bloating into more than you might want to manage in the long haul.

There are various ways that you could do this, depending on the collection(s) you want to support, the extra logic you'd like (like my requirement for uniqueness in the lists), and stylistic elements about static methods, etc. But here's what I wound up with:

public class LazyListManager {

    public static  List add(List list, T item) {
        if (list == null) {
            list = new ArrayList();
        } else if (!list.contains(item)) {
        return list;

    public static  List remove(List list, T item) {
        if (list != null) {
            if (list.isEmpty()) {
                list = null;
        return list;

This simple class has two static methods on it to support adding and removing from an arbitrary List object. As needed, it will create a new List (actually, an ArrayList, but that's an implementation detail). It will check for uniqueness in the add() method, check for nullness in the remove() method, and null out an empty list in remove() as appropriate.

There is an important piece here that makes this work - callers must supply their target list as both a parameter to the function and as the recipient of the return value; this is what makes it possible for these utility methods to allocate or null-out the list as appropriate (since they do not have access to the original list, but only have a reference to it).

Given these two static utility methods, we can now write new addItem() and removeItem() methods that are a significantly better (you can't get less than one line of code, unless I missed that part in my CS education):

public void addItemBetter(int item) {
    intList = LazyListManager.add(intList, item);

public void removeItemBetter(int item) {
    intList = LazyListManager.remove(intList, item);

public void addItemBetter(float item) {
    floatList = LazyListManager.add(floatList, item);

public void removeItemBetter(float item) {
    floatList = LazyListManager.remove(floatList, item);

Calling these methods looks remarkably similar to what we saw before:


and results in exactly the same output (which shouldn't be a surprise. If the results were different, this approach wouldn't be a utility as much as a bug):

starting lists = null, null
populated lists = [0], [1.0]
ending lists = null, null
populated lists = [0], [1.0]
ending lists = null, null

The LazyListManager class has taken out all of the tedious boilerplate related to null checks, uniqueness, allocation, and nullification, and has left us with just one line of code to write whenever we want to add or remove items to/from one of our lists. That's just about the right amount of code for me to write without making a typo or a copy/paste error along the way.

If this were public API, I could envision the manager class offering various different kinds of collections and options, or maybe wrapping more of the capabilities of collections classes (like isEmpty() or contains()). But for now, it's a nice little internal class that can help me simplify my code whenever I need to use this lazy-allocation pattern.

All of the interesting code is inline above, but if you want the two source files, you can download them here.