If you’re interested enough in Flash Lite to (like me) buy a phone to experiment on, I’ve got some recommendations for you. My recommendations are based on experience spent on two recently completed Flash Lite projects (one Flash Lite 1 and one Flash Lite 2) where I worked with over twenty different phone models during the past three months.

From a Flash Lite performance perspective, I recommend a Symbian S60 2nd Edition phone. The S60 2nd Edition phones consistently worked better for me than all others and never crashed. It’s funny. I’d think that if “2” is good then “3” would be better, but that’s not the case here. Flash Lite performs better on S60 2nd Edition than the S60 3rd Edition. I recommend the following phones in the following order based on Flash Lite performance:

1. Symbian S60 2nd Edition phones
2. Symbian S60 3nd Edition phones
3. Symbian S40 phones
4. Verizon Wireless supported handsets
5. Windows Mobile 5.0 devices

Until recently, most of my Flash Lite experience was with version 1.1. Flash Lite 1.1 is hard. The language is different, and you’re restricted to writing code in Flash Authoring on the timeline. This makes working on a team or using source control nearly impossible. And, without a team or source control it’s much harder to build anything complicated or interesting…

If you’re someone who looked into Flash Lite 1 and quickly turned to run for cover, I don’t blame you.

If you’re still taking cover, I want to share what I’ve recently learned with you – Flash Lite 2 isn’t bad. Actually, from a development perspective it’s quite good! To show you what I mean, I’ve written what could count as your second Flash Lite 2 application. An app you might write after knocking out a “Hello World”. The app is a text messenger, and here it is:

Let’s take a look at the application code…

The video above demonstrates the Google Calendar edition of the Flash Lite 1.1 mobile calendar project we’re working on at Pattern Park. Please forgive the video quality. It’s just a sneak peak, and we’re not marketing guys.

In the video, I walk through launching the calendar (which, as a nod to CL2, we call CaLendar2) from a deck icon; navigating its month, day, and event views; and adding an event to Google Calendar with the application’s hook to Google’s SMS gateway.

The version demo’ed above is a quite a few iterations beyond what I showed during my MAXUP presentation. In fact, it’s bug free. You may be wondering, “it sounds mature, is CaLendar2 available in source or packaged form”? Well, for those asking, thanks for asking. The answer is, “not yet”. We still need to implement a distribution process because of some Flash Lite 1.1 details. Our plan is to have that process complete in time to release CaLendar2 with Lifebin. We’ll be talking about Lifebin quite a bit in future posts.

If you’re interested in CaLendar2, will you please post a comment letting us know? If there’s enough interest, we’re willing to shift priorities to get the distribution process implemented sooner. Also, if you feel like CaLendar2 is something you would pay for, will you please include how much you feel it’s worth in your comment? Luke and I plan for it to be free, but it’s always interesting to get a feel for something’s value.

I must have learned something from the first chapter of The Pragmatic Programmer by Dave Thomas (who’s probably better known these days for his contributions to the Ruby community through his publishing company and must-have book Programming Ruby) when I read it long ago. In that chapter, Dave’s 8th tip is to, “Invest Regulary in Your Knowledge Portfolio”. One of the ways he suggests doing so is to learn one new language a year. Well, this year I seem to be making up for years gone by, because I’ve been spending a lot of my extra time working with several different languages and their frameworks. This year, I’ve been working with – in order as of today – haXe, Flash Lite 1.1, Ruby, ActionScript 3.0, XUL, and the Nullsoft Scriptable Install System. I’ve been working with their frameworks Ruby on Rails, Flex, and XULRunner.

All of these languages are tools to build the kind of software that I’m interested in building: software that’s fun to write, easy to distribute, a pleasure to use, useful, and affordable. For software to be distributed easily and a pleasure to use has to be universally available. And, to be universally available it needs to be truely cross-platform – cross-software and cross-hardware. It needs to work on win, mac, and nix and also in a browser, on a desktop, and on a palmtop. Today, the best format to make software universally available is the SWF format. It’s undeniable, more people have the Flash Player than any other piece of software .

It is, granted, worth noting that some feel like traditional Java, non-traditional Java, Python, Ruby, .NET, and the Mozilla Foundation’s XUL are also acceptable tools to make available software, and depending on the goal, they’re correct. In many cases, these technologies can even enhance a SWF’s funcionality. For example, it’s possible to use Mozilla’s XULRunner as a desktop wrapper for SWFs, or if you’re really smart, to do what Rich Kilmer did and write a SWF view to a Ruby controller and Berkeley DB model. Rich gave me and Luke a sneak peak at his indi product at RailsConf, and we were blown away. The product is a great idea, and it’s built on an extremely smart and interesting architecture. Get indi when it’s available.

Invest regularly in your knowledge portfolio.