- I'm really grateful for the excellent upgrade documentation provided by Google. Having a complete and concise explanation of all the removed methods, and what to replace them with, makes the whole process far less painful.
- Dick Wall's ContentProvider diff is extremely useful as well. It would be nice if it was included in the official documentation - you need to dig a bit to find it.
- Most of the API changes look fine to me. Have you ever used an SDK that had some functions which just seemed poorly designed or named? Did it gnaw on you for weeks, months, and years, when even the SDK provider's engineers admitted it didn't make sense? I'm willing to change my code now if it means not having to do that next year. Things are now more clearly named or more elegant. (Big example here is the AlertDialog change - it's a low more elegant now, and to some extent future-proofs against further API changes.)
- I'm glad I wasn't using XMPP. This no longer seems as disastrous as I had first thought - it sounds like most of the old functionality is now present in the GTalk API - but the volume of the outcry has been as loud as I predicted.
- Those buttons really are big! I've probably heard more about this than any other change, so I was prepared for it. What is weird, though, is that the TextViews are still as tiny as before. If your views are stacked vertically this looks fine, but if they're horizontal it's hideous.
- I was pleased to see that the changes in View size didn't have a big impact on my design. Oh, it looks different, but not actually bad. I suspect that a lot (not all) of the people having trouble now were using absolute positioning or other funky layouts. If you stick to the basic built-in layouts, things look pretty good.
- I wish I could say the same for other components. The TimePicker dialog, which looked good (if simple) in M3, is so ugly in M5 that it isn't an option for me to use. That leaves me with the unpleasant choice between re-implementing this View from scratch so it looks right, coming up with my own design for picking a time, or swallowing and hoping that they fix this soon.
- Along the same lines, I wish they would finish open-sourcing Android and put in place a system for submitting patches. I'd much rather spend the few minutes I think it would take to fix this bug than fill out a report and wait for the next SDK.
- Because of this and other factors, I'm now wondering whether it's worth re-submitting on M5. I kind of want to do it, since it's working on the latest and greatest, but it looks really bad in a couple of places. This would require additional design work just to reach the level of functionality I had before. Is it worth it, especially if these things will be fixed soon? I'm doubtful.
- On the other hand, the bug fixes have been impressive. The improvements in MapActivity alone give a big boost to application stability, and may be worth the price.
- It has definitely been a valuable exercise, though. Now that I know up front what to avoid, future designs will be much more likely to look great out of the box. (Just don't use any dates, or times, or long alerts...)
- The M5 emulator seems a bit slower than the M3, but not by an order of magnitude like some people on the group have been reporting. I actually bought a new computer to handle the emulator, and am glad I did - the M3 went from taking over 2 minutes to boot up to less than 30 seconds.
- The home screen looks better than I expected. When I first saw the screen shots from Barcelona, I thought it was hideous. After you use it, though, it makes more sense - it's showing you the applications you actually use, and you can quickly launch anything on the phone with a single tap.
- With this and most other screens, it becomes really helpful to remember that M5 is for touch screens. This does, however, make it even more jarring when you run across Views that don't properly support touch.
- The new XML editors are a little fluffy, but make Android feel like a more professional product. It's most useful when you have a limited and well-defined set of choices like in Android Manifest - it becomes an integrated tool for discovery. It's least useful when it becomes a thin and encumbering veneer over raw XML, like in the resource XML. It would be great if future Eclipse plugins could identify the valid entries and only show us those.
Friday, February 29, 2008
I finally took the plunge to upgrade my code from M3 to M5. The whole process was smoother than I expected - I had assumed it would take a few days, and managed the whole thing in just a few hours. My thoughts so far: