Thursday, June 18, 2009

Scala and Android

Recently I was working on an article for developerWorks about using Scala on Android. Stay tuned to developerWorks to see that article. Since then I have started a little side project to create a set of Scala libraries for working on Android. Now you may ask, why bother with this? Is this just a classic case of mental masturbation? Well, no, at least I hope not.

I think Scala is well suited as a programming language for mobile devices. I am not an expert on all mobile platforms, my experience is mainly around iPhone and Android development. For the iPhone you are developing in Objective-C, and for Android in Java. Now in general, I think the Android development environment is superior in almost every way to the iPhone. IDE is mostly a matter of taste, but Eclipse+ADT certainly has a lot more features than XCode. Debugging is definitely better on the Android. It is much easier to debug on a device, and the emulator gives you more ways to vary the environment (cpu/memory/network resources) for more realistic emulation. The only thing advantage I would give to iPhone is that XCode and the iPhone emulator both startup much faster than Eclipse and the Android emulator.

Programming in Java gives you a lot more options than Objective-C. There are just a lot more open source Java libraries out there to help you avoid reinventing wheels. In addition, I think the platform specific APIs added by Google are much better than the ones on the iPhone. A simple example is XML processing. Java and Objective-C both already have XML parsing APIs. However, Android adds extra APIs as they recognize this as a common task for mobile applications that leverage web services. They added convenience APIs for SAX based parsing. They also leveraged a StAX-style parser by leveraging an Apache project. There is nothing like this in iPhone, despite the fact that the iPhone has been around longer and should be more mature. It may be an oversimplification, but I think this comes back to the corporate cultures that produced these platforms. Apple has always been a company that uses software to sell hardware, and this continues with the iPhone. Google is much more of a software company, with strong ties to open source software. It should be no surprise that Android is a much more development friendly platform. And don't even get me started when it comes to garbage collection (Android has it, iPhone does not, despite the fact that Objective-C 2.0 has it.)

So Android is great, why do we need Scala? First there is verbosity. Actually both Objective-C and Java are quite verbose -- Objective-C is even more verbose than Java. Scala is a much more concise language than either. Objective-C can actually be more dynamically typed than Java/Scala, but this rarely makes the code any more concise or readable, and often makes it harder to debug. Next, neither Objective-C or Java have much support for functional programming. This is a bigger deal than you might think at first. UI frameworks are full of events that you must write code to handle. Writing a function to handle those events is so much easier than writing a class. On the iPhone you can often set any type of object as an event handler, and you just have to know the magic methods to implement. On Android, you usually have an interface to implement, and that interface has a single method. This is actually better than what you do on the iPhone, but the interface and its implementation class are both classic cases of boilerplate.

Thus it is my goal to make it possible to write Android applications in a much more concise way by using Scala. In general, you can replace Java code with Scala that is much easier to read and understand. I think this will be especially true on Android, and the contrast will be even more true.

The last reason that I think Scala is a great language for mobile development is threading. Both iPhone and Android support multi-threading, as any UI framework must. Any good UI will perform any non-trivial operations on a background thread, to keep the main UI thread responsive to the user. However, threads are tricky, especially this kind of multi-threading. Updating your UI from a background thread is a recipe for disaster. Android enforces this by using a Handler on the main thread that your background threads send messages to. If you are familiar with Scala then message passing as a way to implement multi-threading should ring a bell. This is exactly how actors work in Scala. I haven't tried using Actors on Android yet, but it sure seems like a good fit.

So there is some of the motivation. I think Scala on Android could be really compelling. My side project is pretty small so far: a handful of wrapper classes and implicit conversions to bring some syntactic sugar and functional programming into the mix on some common Android classes. The project also has a special build of the Scala library that I found necessary to get the library to work on Android and its compiler. I am hoping to add more sugar and to add the actors ideas listed above. I am also hoping to come up with a nice way to integrate something like Proguard to optimize the bytecodes that get compiled for Android.

7 comments:

p3t0r said...

I've been doing quite some android development lately and would really like to move to scala for that.

Are you planning to start an open project? I'd like to chip in!

walterc said...

you can use proguard to package scala code without the need to modify scala library. besides the convenience, you will get an .apk file that is more sensible in size.

please check out this link: http://chneukirchen.org/blog/archive/2009/04/programming-for-android-with-scala.html

Unknown said...

@p3t04 Yes, that is the point of Google code project I started: http://code.google.com/p/scala-android/. I would be happy to add developers to the project.

@walterc I am quite aware of the link you posted. However, it was carved out with older versions of Android and Scala. First of all, the Ant style of integration outlined in it will not work with Android 1.5, at least not in the way laid out. The build in 1.5 changed quite a bit. However, I agree that a solution like Proguard would be better than the custom scala-library.jar that I did. If you can get that working, please let me know.

Anonymous said...

This looks like something I've been wanting for a while.

Not sure if you've looked into any of this since these comments have been posted, but SBT and its Android plugin makes a lot of this very easy. I have an Android app being run through Proguard and automatically optimized down to about 300K (it was at 30K before I added Rhino.) I'd like to make the following suggestions if I may:

* Add an SBT-based build system. This doesn't mean that projects using this one need SBT, but it will make building and sharing a lot easier.

* Switch to a DVCS like Git. I'm partial to Git, but don't mind any other choice overly much. I just tend to do lots of work disconnected, and this seems like a great project to abstract current idioms in my Android app to, so I'll likely be adding syntactic sugar here and there.

I don't mind doing these--I likely will anyway, if only to have this library in a more convenient form to be shared among my own projects. But I thought I'd toss these ideas your way to get your thoughts.

Frank M. Eriksson said...

It is true that the iPhone has been available to customers since mid-2007, but Android, Inc. was incorporated in 2003. So with this by my hand I would like to claim that Android was superior to iPhone long before Apple even had its first thought about it ;)

Scala seems to be a quite nice alternative to Java, as I'm quite a bit allergic to Java, it is way to verbose. The "public static function main" thing must be a joke right?

I need to bathe my eyes in Holy Water after reading line 52 to 105 of Googles Android example LunarLander

Faster Than Light Technologies said...

I have scala-android post http://saadstechblog.blogspot.com/2011/09/scandroid-scala-android-tutorial.html.

Android app developer said...

I absolutely admired account your blog. It was actual able-bodied authored and accessible to understand. Unlike added blogs I accept apprehend which absolutely not that are good. I additionally begin your posts actual interesting. In actuality afterwards reading, I had to go appearance it to my acquaintance and he enjoyed it as well!