Clang now has support for blocks, which are basically a way to bind stack variables to hidden structs and a pointer to a code block on runtime (link via John Gruber). It's very interesting to compare this approach to C++0x lambda functions. C++ takes the language way, by adding a new syntax to the language and making the feature depend heavily on templates and metaprogramming. Clang is primarily a C and Objective-C compiler and blocks are implemented with small syntax additions and a small runtime library that uses concepts such as reference counting. Very much like Objective-C.
There is a little gem in the documentation of the latest Android SDK version. A mention of native NPAPI plugins:
WebViews now support plugins. The location of the plugin is set via WebView.setPluginsPath(). Plugins are native (C/C++) code that implement the NPAPI interface.
This opens the door to native plugins on the browser. Including Adobe Flash, if Adobe wants to.
Android is a managed platform running interpreted bytecode. But there is now an explicit mention of native, third-party binaries in the form of NPAPI complaint browser plugins. This is understantable since such plugins often implement audio and video codecs and a bytecode interpreter is probably not fast enough. But this also means it may be possible to develop applications that bundle a native WebView plugin for internal usage.
The SDK is not yet 1.0 but I hope we hear more about this feature. Let's hope it remains here for every developer who wants to use it and on shipping devices.
Loving to hate the iPhone
The iPhone is a sweet platform to develop for, but its distribution model for third party code is like a textbook definition of the walled garden. Every line of code you are writing depends on the blessing of Apple to make it to the hands of your customers. The EULA on the SDK goes well into what could be called editorial control. The lame excuse of caring for the cellular network is false. For example the majority of Windows Mobile smartphones being sold by the same operators that now sell the iPhone are application unlocked and offer full hardware access to third parties. This includes the radio hardware and it is what makes features like the GPS-less localization in Google Maps for Windows Mobile possible.
The App Store is fine. The problem is that it is the only way to sell or distribute your application. If you are a small company and want to do iPhone development you are in the hands of Apple. They decide if you applications can be sold or not. They can control the positioning of your product inside their store (the only store). They decide if you can make it to end of the month. If you don't like it you cannot sell your product from your site or in another store. You are screwed, your code and effort is worthless, and you need to start from scratch on another platform.
The niceness of the tools makes it worse. The programming environment, its API, even Objective-C. It's all good, usable, thoughtful. It's developer-friendly. You want to keep programming on it. You loathe the time to go back to the perverted flavor of C++ Symbian forces you to use, or the endless rigid verbosity of Java. And that siren call is what dooms you in the end. Java code can be ported with some effort between its main mobile platforms (J2ME, Blackberry and soon Android.) And non-UI C++ code can be made portable between Symbian and Windows Mobile. On the iPhone platform you are effectively locked by Objective-C.
It's going to be very interesting to see how the situation evolves in the next 12 months. Apparently the App Store debuted with certain amount of usefulness challenged software, contradicting what many thought was going to be an opportunity for keeping a consistent user experience and quality level; which, along with the cell network collapse doomsday scenario, was the other favorite excuse for the wall garden apologists.