Writing native Android applications with Javascript? Not yet.

Writing native Android applications with Javascript? Not yet.


The number of people using Linux (and I mean Linux the kernel) and free software in general has exploded in the last 2 years thanks to Android and Google. Even if you want to discard phones and only count the tablets (which are starting to get very close to laptops in terms of what you can do with them), the number of new users is huge. And yet, we are all hostage of a choice -- a bad choice, in my humble opinion -- that Google made: Java.

Why Java?

Reason #1: Android came with Java! To be fair, it wasn't Google's choice as such: Google bought Android in 2005, and I can only suspect that Android was well entrenched in Java at that point.

Reason #2: In 2005, Java was still pretty much your only choice if you wanted to write applications once, and expect them to run regardless of what CPU you used.

Reason #3: Java was (and is) well known and widely used.

It's all about timing

In 2005, it probably made a lot of sense using Java. So, what has changed? Two words: 1) Chrome 2) Javascript I am convinced that Chrome and Javascript changed the whole IT landscape radically. Mind you, Chrome beta was released in September 2008. The first version of Android would be released a couple of months later (!). While Android was being created, Chrome simply wasn't around.

What's so important about Chrome?

Chrome came with the v8 Javascript engine. V8 is a monster of a virtual machine, able to get Javascript code and make it spin really, really fast -- faster than the speed of light. With Chrome, Javascript turned: it went from being a sluggish scripting language, to being something that could be used for real applications. Google was interested in a browser that people could use to run their emerging online applications (Google Docs was around in 2006). I am not sure they realised that they could push Javascript to run that fast -- maybe it caught Google itself by surprise.

In the end, if Google had to decide how to build Android in 2008 rather than 2005, I have little doubt that they would have picked Javascript as their language of choice. Instead, Android has fully embraced Java -- although they tried to bypass some of the patents and issues with Java by using Dalvik. At the moment, to develop an Android application you write Java code, compile it into a .class file (Java's compiled code), and then convert that .class file into a Dalvik file (which will be then interpreted by Android's internal Dalvik virtual machine).

Is it too late?

At the moment, if you want to write an application for Android you are pretty much stuck with Java. There are ways around I must say: one of them is Phonegap which is released under a free license and is indeed very exciting. PhoneGap is essentially a browser application that will contain your code, written as HTML/CSS/Javascript. Whatever you create is not native: it's a custom browser that has access to the device's hardware, and that runs your web-like code.

What about native Applications?

You could convert Javascript code into a Java class using Rhino. However, things are not easy: the Dalvik virtual machine doesn't work nicely with dynamic languages . It's a pretty messy business.

The possible solutions

Since Google is about to include V8 into Android 4 (or so it seems), we would have a situation where your phone would include two very fast virtual machines (Dalvik for Java and V8 for Javascript), but you can only write native applications for one of them.

My idea is that Google should provide, natively, a bridge between the Dalvik world and the Javascript world, so that it is finally possible to write native Android applications using Javascript. This can be done two ways: the obvious way is to make Dalvik work with Javascript code. To me, it's looking less and less likely that this will ever happen.

The other option is quite involved: it would require Google to make it possible to have native applications written in Javascript, and allow them to access the system libraries (System C library, Media Libraries, Surface Manager, SGL, LibWebCore, 3D libraries, FreeType, SQLite) from Javascript. You will also need the Java.hardware classes (in Javascript). This way, Native Javascript applications wouldn't come with an overhead as big as a full browser for a start (there would be no need, since all you are using is the V8 virtual machine, like Node.JS did).

Am I dreaming? Maybe. I wonder if I am the only one who thinks that being locked to Java deserves a solution -- a real one.

Category: 
Tagging: 
License: 

Comments

gweeper64's picture
Submitted by gweeper64 on

The WebOS Enyo framework is JavaScript/CSS based and is now open-sourced. Quite a few WebOS apps have alerady been rehosted on Android and iOS already with little effort. You need to check it out.

Author information

Tony Mobily's picture

Biography

Tony is the founder and the Editor In Chief of Free Software Magazine