I want to be able to write apps for my phone in in something other than the Java language; for example Ruby or Python. This isn’t one of the things my group at Google has asked me to look at, but I think it’s worth doing and worth some of my time. I’m writing this today because I’m amused by the contrast with the current hubbub over Apple having tightened the developer thumbscrews.
Why? · I like the libraries, but I have to confess that these days, I’ve slipped into the camp of those who find the Java language verbose and rigid and overly ceremonious. It bothers me less on Android than on general-purpose computers, because Android apps tend to have a pretty thin layer of application code between calls out to the network and GPS and accelerometer and so on.
But having said that, I’m pretty sure that in, for example, Ruby, I could write less than half the number of lines of code to get any particular job done. Also, I entirely loathe Java generics.
What Google Thinks · As usual, I’m not speaking officially for Google here, but my impression is that if there were an official reaction, it’d be along the lines of “Uh, whatever, we’re focused on shipping this next release.” Which is likely appropriate; The Androiders are so zoned-in on building a great SDK and runtime and Market that my wild-eyed screw-the-semicolon ideas are not exactly likely to become front-of-mind. Well, unless I can show that they work.
It may come as a surprise to regular readers here, but there are vast expanses of our profession, including some of the best and brightest, who haven’t got the dynlang bug yet.
And the Official Policy? · That’s a non-issue. An Android app has to be an APK file, and if you generate/sign one of those and are in the developer program, and it’s not illegal or porn or something, you can drop it into the Android Market. (If falls afoul of Market rules, you can post it on your own website or some other market, and people can still install it, no jailbreaking required.) How you build the APK is up to you.
In practical terms, if you want it to look-and-feel like an Android app, you have to use the Android SDK; but what language you generate those bytecodes and method calls with, and how you compile it, well, why should anyone care? I’m using Eclipse, and while it Just Works with the library and emulators and other tools, it’s failed to win my heart. I’m seriously thinking of going to Emacs and seeing if I could replace Ant with Rake. And, of course, every piece of the toolchain is open-source and thus in principle can be forked and improved and replaced.
If what you produce sucks, the word will get around quick; having used the official Android toolchain won’t save you. And if it doesn’t suck, not having used it won’t get in the way.
I’m actually a little puzzled by the Apple policy; the technical side I mean, not the business issues, which Gruber explains with ruthless clarity. I can see Apple wanting to enforce the use of their APIs, but the compulsory linkage to the Objective C programming language makes me feel like I’m missing something; where is it carved in stone that it provides the optimal, impossible-to-improve, way to use the iPhone APIs? And if nobody’s allowed to try anything else, how will we find out?
Anyhow, the market will decide; the big small-m market, not the iPhone nor Android Markets. But in the meantime, I’d say we’ve got more scope for fun over here on the Android side.
Candidates · Right at the moment the Rubyists seem to be in the lead in this race, what with Ruboto and Duby. I can’t think of any architectural reasons why Jython shouldn’t be a candidate, except for Sun let Frank Wierzbicki go and I’m not sure anyone’s working on it much, these days.
Also, in theory you ought to be able to use the Android NDK to get the native C versions of Ruby and/or Python going. It’d be a slog, but the idea doesn’t seem insane.
There are lots of other languages, and maybe one of them is a better bet; My focus on Python and Ruby reflects my own prejudices, but my mind is open. And of course JavaScript is already a first-class citizen pretty well everywhere.
In Conclusion ·
Got any good ideas for how to let me write serious, shippable Android code
without ever having to do this again?
HashMap<String, List<Person>> buf = new HashMap<String, List<Person>>();
If you do, get in touch. I might be able to help you help me.
Contributions
Comment feed for ongoing:
From: Yves (Apr 12 2010, at 00:13)
Hi there, interesting read.
While searching for python on android I stumbled over this:
http://google-opensource.blogspot.com/2009/06/introducing-android-scripting.html
But will it ever be part of the official sdk?
[link]
From: Richard (Apr 12 2010, at 00:30)
You should probably mention up front that you've considered ASE ( http://code.google.com/p/android-scripting/ ) and discounted it, presumably because you want things to be 'native' to dalvik and not through a shim layer from an ARM/Linux (or whatever) Python or Ruby.
Other than that, I agree that the Android libraries and APIs are generally pretty decent, but the underlying Java lets them down. Being able to write first-class Android apps in Python would make me something close to ecstatically happy :)
(insert standard market location limitations rant here)
[link]
From: Will Emerson (Apr 12 2010, at 00:36)
Have you checked out Rhodes?
http://rhomobile.com/products/rhodes/
You write the app in Ruby, Rhodes compiles it to any number of mobile platforms including Android. They say they pass Apple's new restrictions. I've just played with it but it looks like it has a lot going for it.
Will Emerson
[link]
From: Guillaume Laforge (Apr 12 2010, at 00:51)
For dynamic langauges (and not only for them actually), focusing on the Dalvik JIT may be very much beneficiary, as Dalvik's not really be optimized for other languages than Java (requiring lots of object creation, long code paths and indirections, etc.)
[link]
From: tamberg (Apr 12 2010, at 00:53)
Maybe Scala is an option, as it seems to already work on Android http://www.scala-lang.org/node/160
Best regrads,
tamberg
[link]
From: Michel S. (Apr 12 2010, at 01:28)
The Scala instructions on their own website would probably work, but would generate a huge APK. You would want to add ProGuard to your build configuration, to strip out unnecessary classes. The same is probably true if you use a lot of third-party JARs on top of the Android SDK!
The NY Scala Meetup is probably worth contacting too, for the latest tips and tricks: http://www.meetup.com/New-York-Scala-Enthusiasts/calendar/past_list/
[link]
From: Steve Loughran (Apr 12 2010, at 01:29)
HashMap buf = new HashMap(); ¶
[link]
From: John (Apr 12 2010, at 01:38)
I programmed in Java for about 8 years before taking a job that was in Ruby. I have to say my next job won't be ruby. Java might be verbose, but using an IDE you don't have to type it all, and at least you can read it and know what it means.
[link]
From: Jan Berkel (Apr 12 2010, at 02:12)
Scala works quite well, the type inference means you don't have to write verbose constructs like "new HashMap<String, List<Person>>()" again while still maintaining type safety.
The two main options for using it are some additions to the android build system (http://code.google.com/p/scalaforandroid/) or a plugin for sbt, scala's own builder (http://github.com/jberkel/android-plugin).
Ruboto is coming along nicely, there are already some demos built with it performance-wise is quite slow at the moment. AOT compilation / code caching should improve things though.
[link]
From: Andrew Savory (Apr 12 2010, at 02:54)
How about considering a third option between compiled and dynamic: official web widgets on Android? It would be very interesting to see Android devices implement the BONDI specs, allowing developers to build apps using JS, HTML and CSS.
http://thewiki4opentech.org/index.php/Widget_Manager_for_Android_Bondi looks like an interesting starting point.
[link]
From: Mikael Kindborg (Apr 12 2010, at 03:16)
I have positive experiences with using the Rhino JavaScript engine on Android. See the DroidScript project. One of the best things is the ability to develop incrementally, and evaluate code directly on the device from an editor on the PC, like in a Smalltalk workspace.
Project entry point: http://droidscript.se
[link]
From: Albert Freeman (Apr 12 2010, at 03:32)
I suggest taking a look at Appcelerator. Python, Ruby, PHP, and/or Javascript. It was capable of doing both Android and iPhone development until Apple's latest stab in the face.
[link]
From: David N. Welton (Apr 12 2010, at 03:36)
I have to take a moment to promote my own language, Hecl: http://www.hecl.org - it may not be exactly what you want in a language (it's certainly not Ruby), but it runs quite well on Android and has for a while. Partially, this is due to its simplicity; JRuby does a lot of fancy stuff under the hood, which is what makes it run so well on 'normal' Java. Hecl is just a simple interpreter.
Of course, that means it's not as fast as code written in Java, but it's suitable for prototyping things.
[link]
From: Nick Johnson (Apr 12 2010, at 03:38)
Jython seems like it should be worth a look. It'll give you immediate direct access to the APIs, and you can then proceed with writing more Pythonic wrappers around the interfaces at a leisurely pace.
[link]
From: Andreas Trawöger (Apr 12 2010, at 03:43)
I think what's really missing in Android is a decent package management that is able to automatically handle package dependencies.
Putting e.g. a Python program into a single APK file will never really work without throwing away the 'included batteries' and completely abandon the Python standard library on Android.
What could work is a mechanism like rpm, apt or easy_install where you install the Python interpreter once and make your own Python packages depend on an already installed Python interpreter.
[link]
From: fabien (Apr 12 2010, at 03:55)
Could you explain why you don't simply use Android Scripting Engine?
[link]
From: Can Ozmen (Apr 12 2010, at 03:58)
I'm thinking about Scala too. At least half of this line
HashMap<String, List<Person>> buf = new HashMap<String, List<Person>>();
will go away.
[link]
From: Martin Probst (Apr 12 2010, at 04:13)
As a starter, instead of writing:
HashMap<String, List<Person>> buf = new HashMap<String, List<Person>>();
You could use Google Collections and write:
HashMap<String, List<Person>> buf = Maps.newHashMap();
That's still quite a bunch of angle brackets, but effectively you only have to tell the compiler once what your expected type is, and that is reasonable for a statically typed language, I think.
[link]
From: Stefan (Apr 12 2010, at 04:36)
currently we're porting the SqueakVM to Android:
http://code.google.com/p/squeak-android-vm/
You'll be able to write nifty Smalltalk-code, using Squeak/ Smalltalk on your Mac(or PC, or directly on the phone) and then run the image on your android-powered gadget.
Remember:
Smalltalkers do: [:it | All with: Class, (And love: it)]
[link]
From: ansgri (Apr 12 2010, at 04:38)
I think it should be Clojure, for it's natively interoperable with Java.
(and it's 'an acceptable lisp', love it or hate it, but won't be constrained by syntax any more)
[link]
From: But.... (Apr 12 2010, at 04:57)
You don't have to write:
HashMap<String, List<Person>> buf = new HashMap<String, List<Person>>();
What's wrong with:
HashMap<String, List<Person>> buf = new HashMap();
or
HashMap buf = new HashMap();
?
[link]
From: commenter (Apr 12 2010, at 05:03)
"well, why should anyone care?"
But... but... Intermediate Layers... Application Quality... does not compute!
[smoke starts pouring out of ears]
[link]
From: Sandeep (Apr 12 2010, at 05:07)
What about Clojure - it is the secret love child of Java and Lisp ?
[link]
From: Paul C (Apr 12 2010, at 05:13)
Well, instead of:
HashMap<String, List<Person>> buf = new HashMap<String, List<Person>>();
FWIW, you could always write:
Map<String, List<Person>> buf = Maps.hashmap();
with the following utility method:
public static <K,V> HashMap<K,V> hashmap() {
return new HashMap<K,V>();
}
[link]
From: JulesLt (Apr 12 2010, at 05:30)
I'd concur - I definitely think the exciting era for mobile development will be once we move beyond C-derived programming (by which I mean Obj-C, Java, C++, and dalvik).
The weird thing is that Apple actually seem to have a many of the required components for doing this with the iPhone (i.e. MacRuby, which replaces the Ruby interpreter which compiling down to native code running on the Obj-C runtime - which has always been dynamic in the Smalltalk sense).
And that very much shows the problem - if it was an open platform, I suspect someone would have done the job of porting MacRuby and wrapping UIKit in HotCocoa classes for them.
[link]
From: henk duivendrecht (Apr 12 2010, at 05:38)
I can only hope Adobe reads this post. I also believe JAVA is an outdated and overcomplex language that invites bugs and inconsistencies. Like Objective-C, JAVA needs an added layer that allows scripting languages like javascript and actionscript.
This way Android will open up to a LOT of creatives who are being excluded by Apple.
[link]
From: Mike Garrity (Apr 12 2010, at 05:47)
Nathan Hamblen did a nice presentation recently on using Scala on Android:
http://vimeo.com/10368244
[link]
From: Pablo (Apr 12 2010, at 05:52)
Well you could do something like Multimap<String, Person> buf = Multimaps.newMultiMap();
Not saying that this overweights Java in favor of Ruby or Python, but it does help reduce the verbosity a bit.
[link]
From: Rafał Dowgird (Apr 12 2010, at 05:57)
Love Java libraries? Hate the language? Clojure is for you!
The caveat? It does not run very well on Dalvik yet :(
[link]
From: chris carter (Apr 12 2010, at 06:03)
Phonegap looks promising, http://phonegap.com/, takes your html/javascript and compiles down to native iPhone/Android/Blackberry code, full access to gps, accelerometer, etc.
[link]
From: Luke Amdor (Apr 12 2010, at 06:40)
Another thumbs up for Scala running on Android.
While it's certainly not a dynamic language such as Ruby, I feel I can still be just as efficient as I would be in Ruby.
Also, I think the Scala community is slightly ahead of the curve with building for the Android platform especially with tools like simple-build-tool (http://simple-build-tool.googlecode.com) and the android-plugin for it ( http://github.com/jberkel/android-plugin )
[link]
From: Anders Norgaard (Apr 12 2010, at 06:52)
You can use Gradle to build your Android apps.
http://wiki.github.com/jvoegele/gradle-android-plugin/
[link]
From: Justin Lee (Apr 12 2010, at 06:59)
If oracle removes the Field of Use restriction on the JRE TCK, what are the odds of using openJDK rather than dalvik since it *is* being optimized for non-java languages?
[link]
From: Adam Batkin (Apr 12 2010, at 07:26)
With a little Eclipse-fu, you can often get Eclipse to autocomplete all of your generics for you, so all you type is "List Ctrl+Space" and it will do the rest. So they will take up space on your screen, but shouldn't be painful to type.
And the tradeoff is that Eclipse can often automatically prioritize things in its autocomplete dropdowns since it has better type information.
So if you have an object and you want to set it's previous occupant's addresses (house.setPreviousOccupantAddresses(List<Address>)), you'd type "house.setp", arrow down to the method name, hit Enter, then it will show you a list of in-scope variables, but only variables of an appropriate type. So rather than seeing every local variable, it can filter the list. If you are in the habit of using descriptive (and thus long) names for things, it's useful to have your IDE type them for you. About the only time that I actually type variable names now is first time. After that, Eclipse does the rest.
The REAL value of having explicit types (including Generics) is (IMHO) that you can dive into a piece of code that you have never seen before (or worked on a long time ago) and get a much better idea of what is going on. I'm not saying you can't find that information in more dynamic languages, but it is definitely more work. And even on code that I'm actively working on, anything that reduces my mental load is a good thing. I'm willing to sacrifice a small amount of screen real estate and typing for that.
[link]
From: Tkil (Apr 12 2010, at 08:50)
Tim --
I first see your posts via the Atom feed as displayed on my LiveJournal "friends list". This post broke something in that chain: the angle brackets in the generics code sample seem to be the culprit.
You can see what LJ made of the feed here:
http://syndicated.livejournal.com/timb_ongoing/474411.html
And you can see exactly which feed they're processing by going here and looking at the "XML" link button:
http://syndicated.livejournal.com/timb_ongoing/profile
Safari opens that feed just fine, so I'm assuming it's just LJ being stupid again, but in case there's wriggle room, I thought you might want to know.
(Sigh. They still haven't fixed their problems with relative links in your feed, either, and that's been a few years.)
[link]
From: Manfred Moser (Apr 12 2010, at 09:57)
Tim,
I recently started to write my app with the help of Roboguice (http://code.google.com/p/roboguice/) which is an Android wrapper on top of Google Guice. With it you can forget about a lot of the boilerplate and new keyword and just inject everything you need and concentrate on the business logic.
Also I am building my apk with the Maven Android Plugin (code.google.com/p/maven-android-plugin) and will be doing a presentation about it at the Vancouver Android Developer group later this month (here). You should drop by!
I would love to have a longer chat about a whole bunch of things related to getting the jars into maven central and more with you.
[link]
From: Brendan (Apr 12 2010, at 10:08)
There's a Clojure project for running on Dalvik, but it's slow and lags behind the main Clojure language. It's more of an experimental thing right now.
http://github.com/remvee/clj-android/
[link]
From: Cedric (Apr 12 2010, at 10:09)
We stopped writing code like this a long time ago, and we even open sourced the library that allows this (Guava):
Maps<A, B> m = Maps.newHashMap();
[link]
From: Pierre Phaneuf (Apr 12 2010, at 10:21)
A Dalvik-targeted Go compiler! :-)
[link]
From: Jason Voegele (Apr 12 2010, at 10:23)
As someone has already mentioned, I've created an Android plugin for Gradle. What was not mentioned, however, is that the true utility of this plugin is the incorporation of ProGuard into the build by default. This not only makes Java-based Android applications smaller and more efficient, but also makes Android development in Scala a realistic possibility.
For more details, see http://wiki.github.com/jvoegele/gradle-android-plugin/
[link]
From: Sivan (Apr 12 2010, at 10:59)
I like the idea, but FYI, IntelliJ mercifully does the typing and hides the generics notation on the rhs from you. Also, as others suggested, Google Collections itself brings a lot of clarity by using factory methods.
[link]
From: Raphael (Apr 12 2010, at 14:08)
How about groovy++. Succinct goodness and static typing.
List<String> list = []
[link]
From: Robert D (Apr 12 2010, at 17:03)
Scala?
[link]
From: Tony Fisk (Apr 12 2010, at 19:37)
Ah, languages!
I'm pretty agnostic when it comes to what to code in.
... OK, make that I'd *like* to be pretty agnostic...!
The fact is that, for the most of us, the language you use is mandated by the place you work. Oh, and what you get to try out is mandated by what you've done on your resume (a sad commentary on the degree of understanding the employment agencies have of the industry they supposedly support)
Which is why, after eight months of trying to market my python/PHP/ruby skills, I end up with a job doing straight out C++. (doing lots of gosh wow things with templates and boost... that are taken as a given with more modern languages)
Oh, Swig! Where art thou?
(Sorry, this was the side-topic of conversation at yesterday's team meeting. Grump mode over. All better now ;-)
[link]
From: Danyao (Apr 12 2010, at 20:41)
What about Google's own GO language? It seems to have a strong emphasis on language simplicity (semicolon free) and performance.
[link]
From: Christian (Apr 13 2010, at 00:44)
I would prefer Scala, since it is a very well designed and concise language. The code is almost as compact as Python code (which would be my second favourite). Scala gives also the power to create something like an Android domain specific language.
[link]
From: Ingo (Apr 13 2010, at 01:55)
+1 for scala!
Main reason:It's quite as fast as Java (sometimes even faster)! It's a powerful language with concise syntax.
Also, if you're a Java Programmer, you'll like its type-safety and its syntax that is closer to java than ruby's.
You can mix Scala (seamlessy) with Java.
[link]
From: Steven Haddox (Apr 13 2010, at 06:40)
I'm in the process of starting an app in Rhodes by Rhomobile (http://rhomobile.com) as my first potential iPhone app client also wants their app for Android, Blackberry, etc., etc. Not to mention that Ruby is also my development language of choice.
Anyway, I haven't had a chance to use it yet, just do the research. Thus far it is the clear winner for this kind of goal for me.
[link]
From: Carl (Apr 13 2010, at 06:49)
I think in the medium and long term perspective you could build more momentum around the GO-Language, it is getting considerable support inside of Google and there are probably a lot of good arguments for using it on Android.
There is already a compiler for ARM but its not getting much attention at this time. I think the main hurdle now is that nobody is thinking much about portability issues, cross-compiling etc. There may also be hardware issues like no FPU's available in all hardware, but it seems to me that could be accomodated.
[link]
From: dereki (Apr 13 2010, at 14:06)
+1 Scala. Nothing more to say. :)
[link]
From: Bharath R (Apr 14 2010, at 01:56)
Java might be verbose, but it's still the most readable statically typed language out there (try comparing it with Objective C with static typing for a start). Of course, there's no one size fits all, and there are situations when you'd dig into your toolbox looking for a more concise form of expression. Some of the pain points with generics might be addressed with project coin. But I wouldn't let frustration with generics make me look away from the primary android API in Java.
[link]
From: Marco Baxemyr (Apr 19 2010, at 14:38)
Yes! More languages!
I'd personally want full python support.
[link]
From: Technikhil (May 03 2010, at 21:37)
I think you should include the CLI in the Android OS. I blogged about this and why I think it's a good idea here - http://technikhil.wordpress.com/2010/05/04/google-new-hires-android-and-the-cli/
[link]