Python, JRuby on the Android Platform in 10 Steps
thebitsource.com
thebitsource.com
The title, to me, implies Google backing & compilation for Dalvik.
My money is on Mirah, a new fast, lightweight JVM language that feels like Ruby but compiles to identical-to-Java bytecode: https://github.com/mirah/pindah I don't think shoehorning existing runtimes is a suitable long-term approach.
I have to say that now that I'm slowly getting over the verbosity of Objective-C I'm finding ansi C + a dynamic messaging layer to be a pretty nice combination on iOS. It looks like I'd have to work both below Java with the NDK (painful) and above it with some kind of scripting layer to get similar speed + flexibility on Android.
It even has an app for android (https://market.android.com/details?id=org.ruboto.irb), which works very well, even with OpenGL.
With Titanium you get access to all the native controls, maps, audio/video, camera, Facebook, and a _ton_ of other stuff. You can check out their Github profile for more info: http://github.com/appcelerator/titanium_mobile. Beyond the basic UI stuff, Don Thorp and his excellent Android develops have recently added the ability to use Android.R resources, intents, activities, services, notifications, and other advanced API's that you'd be hard pressed to find in an app developed via PhoneGap. Not only is it free, but you can use the same codebase (with some changes) to create an iOS (iPad or iPhone) app.
Unlike Mono Droid/Mono Touch, Titanium is 100% free.
Enjoy! I know we'll be using this soon.
What I'd like to see is applications for things like Android becoming packaged up "web pages", with platform-specific extensions to access the native APIs. Considering webkit/V8 are already bundled, it'd make a lot of sense...
It was a horrible experience. Mobile Webkit is buggy and inconsistent and comes with restrictions; and trying to emulate the native look&feel ... it's like trying to provide a native look an feel for a Java AWT interface, running on top of IExplorer 6.
I don't see it happening, and I don't wish to see it happening. Just build the damn thing with whatever native platform the phone comes with, and leave the platform-specific extensions out of WebKit.
Thanks,
If mobile webkit is as "buggy and inconsistent" as you describe, than I'd rather see that fixed than have developers write for a completely different language/API for each platform they want to target.
HTML/CSS/JS are open standards and supported relatively consistently across desktop operating systems and mobile devices. I just think it makes a lot more sense for each platform to expand that when they need to, rather than reinvent the wheel with, for example, their own button API every time.
Sadly, thought, this still won't make apps easier to sell on the Android Market, but that's for another discussion.