The story of the Torch contacts list debacle is just astounding. How on earth could a system ship with redundant, easily-desynchronized versions of the contacts database? To me, that says the architectural problems run deep, and further, that there's no effective user experience apparatus in place to even try to deal with the usability problems that inevitably bubble up from it.
One thing the author doesn't really touch on, though, is the acquisitions that would appear to be directed right at remedying these problems. QNX has already been integrated into the Playbook, and by all appearances it's destined for BlackBerries, where hopefully it will sport things like a non-ludicrous contacts list API. The acquisition earlier this month of Swedish UI design firm TAT shows they understand that need, and could actually be a huge turnaround if TAT is actually given enough latitude within the company.
I was actually pretty hopeful about RIM on the QNX and TAT acquisitions, but I am worried about the emphasis on AIR on the Playbook. I just don't see anyone reliant on a cross platform environment (more than a framework) as being able to get the most out of the unique features of their system. It also might not be a happy choice for their existing Java developers.
I have a ... friend ... who has been doing Blackberry Java Development, and this ... friend ... was less than impressed by RIM hopping into bed with Adobe.
I think what exacerbated the situation was that when RIM announced the development kit for the new playbook, they led with the AIR kit, with no defined date for when they'll get Java on there. Which is probably good news for Flash developers, but doesn't look good if Java is your tool of choice.
Now, while RIM has brutally chopped the price of a dev licence (down to something ridiculous like $5 or $10), and they are giving away the dev kit, the tools you need (from Adobe) cost (if memory serves) about $8-900.
The good news is, if you happen to know what you're doing, you can take your Flash app and use some free command line tools to go and wrap it up. So you don't _need_ to spend that big chunk of change on Adobe products... you can trade off your own misery for it instead.
It seems a really raw deal for the Java devs, but if RIM can replace their lost Java devs with Flash devs they might consider that a decent trade-off.
This kind of platform volatility doesn't bode well for developers. Who wants to invest their time learning something that will just be deprecated shortly after? Before RIM started hyping playbook, 8 months ago they were hyping OS 6. Now you don't hear anything about OS 6.
This looks to me like almost exactly the same situation as with Nokia and Symbian. At this point, it's fairly obvious MeeGo is the way forward for the company, and they're trying to put Symbian out to pasture gently, but there's really no way to do it without the appearance of platform volatility.
I'm feeling vaguely nauseous about doing it, but I'm going to defend Adobe. I've criticised Adobe a great deal in the past, but I think that Flash is slowly becoming a legitimately open platform.
The top-end Premium version of Flash Builder is indeed $699, but there's a version available for $249 and a perfectly good compiler available for bupkis. Adobe offer completely free Flash Builder licenses for students and unemployed developers. Beyond Adobe there's an excellent open source IDE for Windows (FlashDevelop), a very powerful proprietary IDE (FDT), Eclipse plugins and a TextMate bundle. There are several good free options for AIR developers.
Adobe have really been sweating it over the image of Flash amongst developers. They're still a long way from perfect, but they seem to really be sorting their act out. While they would very much like developers to buy their expensive IDEs, they certainly aren't obstructing competition. It would be nice if AIR went open source along with the Flex/Flash core SDK, but compared to Apple it's a very open platform.
I don't really have any disagreement with what you've said, but I don't see the value proposition for RIM in using an open platform that can be duplicated by one of the Android phones. It seems like an incredibly bad way to treat your current Java developers and provide no diferention. Putting your development future in a 3rd party's hands seems rather wrong.
I still don't understand how RIM ended up deciding on Flash for the Playbook SDK. Flash has never been known for its performance. They might have been able to get away with it on overpowered desktop machines, but performance is critical on a CPU/memory/battery limited mobile device.
Even on with Objective-C on iOS there are a bunch of tricks you have to employ to keep things running smoothly, and if you're not careful you can still end up writing fairly poorly performing apps. I can only imagine this being much, much more difficult if you're working with Flash.
One thing the author doesn't really touch on, though, is the acquisitions that would appear to be directed right at remedying these problems. QNX has already been integrated into the Playbook, and by all appearances it's destined for BlackBerries, where hopefully it will sport things like a non-ludicrous contacts list API. The acquisition earlier this month of Swedish UI design firm TAT shows they understand that need, and could actually be a huge turnaround if TAT is actually given enough latitude within the company.