Android SDK update M5 has big changes for developers

Earlier today, the Google Android team announced version m5-rc14 of the Android phone SDK so I downloaded it and put it through its paces. Everyone over on Planet Android seems to be focusing on the cosmetic differences in the Home application, but I suspect many carriers are going to chuck that out and write their own so I wouldn't pay too much attention to that. The real differences are under the covers.

If you've written an application with earlier versions of the SDK, you're going to be in for some conversion pain. It may take a few minutes to a few hours, depending on how large the project is. Luckily, Google has provided a nice document on how to migrate your code from M3 to M5, in addition to directions on installing and updating the SDK and Eclipse plug-in. (And before you ask, I don't know what happened to M4).

I really don't understand why Garett Rogers considers the Android documentation to be "sub-par". After spending countless hours pouring over it in preparation for writing an Android book, I have to say I'm more than a little impressed. There are hundreds of pages of detailed information there. For example, take a look at the Javadoc for the Activity class. Have you ever seen documentation like that in any project, let alone one that is free?

Google was kind enough to run the JDiff utility over Android M5, comparing it to the M3 version. JDiff creates a lengthy report showing what packages and classes were added, removed, or modified. According to the API diff report, the overall difference between the two versions is approximately 31%. There were nearly 4,000 changes in all. That's very high; probably the highest we'll ever see for an Android update. If you ask me, I think they waited a bit too long before refreshing M3. Hopefully smaller, incremental changes will be the norm from now on.

Many of the diffs can be traced back to renaming a couple of classes that were used all over the place. ContextURL was renamed to Uri, and Paint was replaced in the text packages with the TextPaint subclass. Some interfaces were changed to abstract classes, and a lot of things were made final.

Aside from those trivial changes, here are some of the more substantial differences I found interesting:

• Animations can be used in more places now. You can add an animation to a layout, so that elements fly in or fade into being instead of just suddenly appearing.
• The media package has undergone some simplifications and other changes to support more formats including  OGG Vorbis, MIDI, XMF, iMelody, RTTL/RTX, and OTA audio file formats.
• Searching is becoming a first class citizen. Don't be surprised if you see a dedicated "search" button showing up on future prototypes. When the user starts a search, your application gets a chance to intercept it and offer search within your program and on other places on the phone, in addition to traditional web search.
• Geocoding is now a standard feature. You can translate a string that has a street address or a business name into a longitude and latitude, and vice-versa.
• Google has adopted the Builder pattern in a few more places, notably in the creation of Alert dialogs. Instead of having a bunch of constructors that take zillions of parameters you string method invocations together, like "a.setB(3).setC(5).show()".
• The new SDK has more support for instrumentation, debugging, and performance monitoring. For example there's a class called InstructionCount that lets you time your routines down to the number of instructions they run. Other classes let you log events and view them in a new tool called traceview. You can find some screenshots here.
• The socket library now appears to have support for Multicast, though I haven't tried it yet.
• There's a new "touch mode" that affects how widget focus is done. The user gets into touch mode by, you guessed it, touching the screen, and it lasts until they press a key. See Touch Mode and Focus Handling in android.view.View for the nitty gritty details.
• Context menus have been added. To get a context menu to show up the user can hold the select button or do what Google calls a "long click", i.e., hold your finger on the screen for two seconds.

There are a few tantalizing glimpses of other functionality, such as documentation (but no code yet) of an AWT package that should make porting Java SE programs easier, and a mention of "velocity tracking" and "flinging" (think: put your finger on a globe and set it spinning at different speeds). But my favorite addition to M5 has to be a function called "getDataFilePath()". The documentation says:

DO NOT USE THIS FUNCTION!! Someone added this, and they shouldn't have. You do not have direct access to files inside of a content provider. Don't touch this. Go away.

Ha! M5 is still a ways off from version 1.0 so I'm sure there will be lots of surprises in future releases for us to play with. Remember, be sure to file any bugs you find in the new issue tracking system. If you don't report 'em, they won't get fixed.