What would you like to see Google (and others) do with Android in 2009? Here are some things I came up with.

• Multitouch.
• Bluetooth APIs.
• Explicit support for unit testing, with clear examples and IDE support.
• Step-by-step OpenGL tutorials, along the lines of the excellent Notepad tutorial.
• A first rate IDEA plugin.
• A damn good GUI builder.
• Winchester hard disk drive support.
• Longer G1 battery life
• The ability to install apps on the SD card, and make it obvious how to put SQLite DBs on the SD card.
• More standard actions and reusable activities. For example, make it easy to select pictures from the filesystem, crop photos, etc. These pieces are all there, but not always included as public APIs. Over time, I hope to see more reusable building blocks, making application development easier.
• A pre-built JAR file containing all the SDK sources, so I can download a single JAR and drop it into my IDE.
• Improved navigation on the Reference Information web site. There are a large number of examples, but the web site is hard to navigate. At a minimum, some kind of breadcrumbs would be nice. It’s really easy to get lost on the current site.
• Never, ever release another phone without a standard headphone jack.
• Improved contact management. My main gripe is when editing contacts, I get duplicate email address conflicts, with no smart merging of the duplicate entries.
• ** Update: Flash support (see Michael’s comment below)

I suspect we’ll have most of these items sometime in 2009.

I finished a rough draft for an article on an Android threading technique. If you want to see the draft, or are interested in being a tech reviewer, here it is:

android.pdf - the article
android.zip - should be ready to go in Eclipse

Setting Up The Examples

• Download and unzip android.zip
• Make sure you have Eclipse with the Android SDK and plugin installed.
• I zipped up my entire workspace and project, so I’m assuming you can simply open it up in Eclipse. I still need to try this on someone else’s computer to verify this works, I’m no Eclipse expert.
• If you’ve never done anything with Android, this example is going to be challenging. You might want to go through the Notepad tutorial first.

Final publication is scheduled for Jan 2, so I’ll need any tech reviews a few days before that. Thanks!

The first 30 minutes of my OCI Java Lunch presentation on Android is on YouTube. We had to split it up into 3 10-minute segments due to YouTube size limits.

The remaining two segments are on the OCItv Channel.

I haven’t watched this myself…I think I was really nervous the first few minutes, but the talk really picked up steam in segments 2 and 3. The second part of the hour isn’t online yet. That’s when I did live demos with my G1, Eclipse, and the SDK. Mario is working on getting that online as well.

Yesterday I showed how lifecycle events fire in response to starting and stopping an Activity. Next, let’s see what happens when you change the display orientation:

That’s what happens without any customization. I marked two methods bold because they are different than yesterday’s diagram. See this comment from Ed Burnette for more details on customizing rotation behavior. Specifically, you can retain data by overriding onRetainNonConfigurationInstance(), or you can prevent activity destruction via the android:configChanges XML attribute.

Phone Call

Android is also useful as a telephone, believe it or not. This next diagram shows what happens when a phone call interrupts an Activity:

See Also…

• Part 1

This is Part 1 of a multi-part series explaining how events, such as clicking the Home button, trigger transitions in the Android Activity lifecycle. You might want to refer back to this Activity Lifecycle Diagram I posted 20 days ago.

This particular comment inspired me:

I like your diagram, the only thing its missing is what causes each transition to happen (i.e. User hits “back” button, user clicks “home” button etc…)

The activity lifecycle is a complicated state machine which cannot live completely in my head so i like having a diagram to reference, however without the transition events its not a complete reference.

This is indeed complex, and one diagram cannot capture all possible transitions. So I’ll split this up into several blog entries. Here is the first diagram I came up with:

To create this diagram, I wrote an Activity that overrides most of the onXXX() methods, writing log messages:

    @Override
    protected void onDestroy() {
        begin("onDestroy()");
        super.onDestroy();
        end("onDestroy()");
    }
    ...
    private void begin(String signature) {
        // super-hacky code to indent nested method calls
        StringBuilder sb = new StringBuilder();
        for (int i=0; i<indent; i++) {
            sb.append("  ");
        }
        Log.i(TAG, sb.toString() + "BEGIN: " + signature);
        indent++;
    }

    private void end(String signature) {
        indent--;
        StringBuilder sb = new StringBuilder();
        for (int i=0; i<indent; i++) {
            sb.append("  ");
        }
        Log.i(TAG, sb.toString() + "END: " + signature);
    }

I then ran the Activity in Eclipse, viewing the log in the DDMS LogCat window. (NOTE: DDMS is an Eclipse perspective, the LogCat window is in that perspective). I created the diagram using OmniGraffle.

I hope to create additional diagrams showing the sequence of method calls for a variety of events, such as:

• An incoming phone call
• The user hits the Menu button
• Showing a dialog
• Navigating to a different view
• The phone going to sleep after inactivity
• etc…

I suspect that learning the Activity lifecycle is one of the more challenging aspects of Android development. I hope this and future diagrams help.

See Also…

• Part 2

Some fun constants in the Android SDK:

GRAVITY_DEATH_STAR_I

Star Wars fans, obviously. I think someone on the team is also a Lost fan:

GRAVITY_THE_ISLAND

And don’t forget Star Trek:

SENSOR_TRICORDER

Here are my slides from today’s OCI Java Lunch:

My slides are pretty sparse, so I’m not sure how much value these are to people who were not there. During the second half of the presentation, I showed several code samples in Eclipse, hooked up my G1 phone and installed an app, and showed the CompareEverywhere application.

Oh yeah…I made these slides in Keynote. I then exported as PowerPoint, then uploaded to Google Docs. Some of the font effects were lost, and I had to indent the text a bit in the code samples. But overall, the conversion went very smoothly. Nice work, Google!

This is how easy it is to activate the Android dialer:

startActivity(new Intent(ACTION_DIAL, Uri.parse("tel:6365551212")));

And here is a complete Activity that shows the code in context. Specifically, this code:

• Creates a screen (an “Activity”) with a button
• Registers a listener with the button
• When you click the button, it starts the dialer
• When dialing completes, the user returns to this screen

public class DialerDemo extends Activity {

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        Button dialButton = (Button) findViewById(R.id.dial_button);
        dialButton.setOnClickListener(new OnClickListener() {

            @Override
            public void onClick(View v) {
                dialPhone();
            }
        });
    }

    private void dialPhone() {
        Intent dialIntent = new Intent(Intent.ACTION_DIAL, Uri
                .parse("tel:6365551212"));
        startActivity(dialIntent);
    }
}

When you run this you see a button:

Clicking the button brings up the dialer, with the number pre-typed:

Then you hit the green phone button to make the call:

Making the Call

You can also write code that actually makes the phone call using the ACTION_CALL intent. For that to work, your manifest needs to include the CALL_PHONE permission.

Perhaps you could use this feature to keep track of your kids. If they venture too many miles away from home, you could have their phone automatically dial home.

They actually have a permission to brick your phone:

android.permission.BRICK

I like this video, it’s the perfect length for a screencast:

That’s a different Eric, if you are wondering — not me!