Sudoku ported to Android

I've written a free Android version of Sudoku. It's very basic, but after I clean it up I hope it will serve as a good example to beginning Android programmers. Here's a screen shot:

The source code and binaries can currently be found here. Consider this to be a very early 'alpha' version. The code is rough, undocumented, it only has 3 puzzles, and it doesn't know when you've solved the puzzle. But rather than sit on it until it was 'perfect' I decided to release it as-is. Future updates will address all these things.

Comments and suggestions for improvement are encouraged, but keep in mind this is a teaching example. Each feature should hold some lesson for aspiring Android developers.

I learned a lot when writing this. One thing is that Android documentation isn't as good as I thought it was. Some parts are great, like the documentation for Activity and life cycles. But there are large swaths missing, like all the things you can do in XML resource files. Hopefully future versions of the SDK will fill out the missing doc pieces.

Here are some more features and lessons:

• Background music in both the main and game screens. Since this is a free example, I hope I can get away with using the tunes. Unfortunately playing MIDI files causes a segmentation violation in M5 so I had to use MP3 files, which are much larger.
• Input with touch and dpad. Or both. Often I find myself switching back and forth between the two. On the emulator, the mouse cursor is used to represent your touch, though it's rather limited. A real touch screen has size and pressure information that an application could use.
• Activities that look like dialog boxes. For the About box I used an Activity but themed it like a Dialog. This seems kind of strange, but powerful. Themes are more than just a few color settings - it's more like skinning. BTW, in case you're wondering, I did try to use a WebView in the About box but couldn't figure out how to make the background transparent. So I used TextView, which accepts very simple HTML formatting but not images.
• Life cycle. The Android life cycle is one of the more unique aspects of the platform. It doesn't work the way you think it does, as a programmer, but it's pretty intuitive to the user. It's going to be interesting trying to explain this to new Android developers.
• Passing information between Activities. It looks like in M5 the developers started to move towards Java Serialization, but changed their minds because it was too slow. There's a Parcelable interface and a Bundle interface for packaging up data but I decided to just stuff things in a String (the 81 cells in a Sudoku puzzle, or the set of tiles that shouldn't be displayed in the Keypad).
• Animation. The only animation I'm using right now is a little shake of the screen if you enter a bad number. The documentation is non-existent though there are some interesting examples in the SDK. But I can tell it has a lot of possibilities and power.
• Tool support. The Eclipse Android plug-in is essential, but I miss all the cool features in the Instantiations GWT designer. For example, maintaining string resources is a manual process. It's very easy to type in a literal string and forget to move it to a resource file, or for things in the resource strings file to get stale. There is no refactoring of resources.
• Stability. It's not too hard to crash your program since the libraries make heavy use of Native C code (for example in the MediaPlayer). Luckily the error messages and other diagnostics are pretty helpful, and other processes are not affected. Another peeve: the launcher in Eclipse has a curious tendency to just stop working (at 9% progress) after a while, and Eclipse has to be stopped, its process manually killed, and restarted. I've learned to start the emulator outside of Eclipse instead of letting Eclipse start it, so that if I have to restart Eclipse I don't have to wait a couple minutes for the emulator to boot.

The Android SDK is still under development, so there's plenty of time for Google to work out the kinks. If the Google folks are reading this, though, one thing that would really help is to release the source code now instead of waiting until the handsets come out. That way a) people in the community would have an easier time debugging things when they go wrong, and b) some motivated folks might even send in patches.