Try the SL4A scripting environment for your Android device

Do you have an Android device, knowledge of a popular scripting language, and a few minutes to kill? If so, then why don't you write an Android app with the Scripting Layer for Android?

Mobile platforms are becoming a popular target for software developers. A lot of the activity looks a bit like the dot-com boom, with many people appearing to think they have found a new path to riches:

  1. Buy mobile device
  2. Develop mobile app
  3. . . .
  4. Profit!

The world is nowhere near that simple. The few people who have followed that formula to success were often among the very first to develop something completely new for that platform -- and something for which people are willing to pay real money. Convincing people to pay money requires more than just putting a logo on some half-baked widget.

For those of us who just want to be able to do something useful with our mobile devices, though, the prospect of being able to carry around computers in our pockets with fairly robust networking capabilities and rich development APIs is certainly a drool-worthy idea. Too bad the development process is so involved and limited -- right?

Well . . . sometimes. Apple has made some waves in tech press with its draconian policies (which seem to rise and fall with the tides) about how developers are allowed to write software, what they are allowed to make their software do, what programming languages and APIs they are allowed to use, and what content they can distribute through their software. Let us not forget the bureaucratic hoops through which you have to jump just to get a bugfix update to your application published to the App Store.

Android makes things a bit friendlier for the developer who actually wants to make software available to users. It is easier to get software approved for the Android Market, but it is also dead easy to circumvent the Android Market altogether if you want; for instance, users can download your applications from a Webpage if they prefer. Android still limits your choice of language to its own variant of Java -- right?

Well . . . no. As it turns out, while Apple has been dreaming up new ways to keep people from writing code for the iPhone in whatever language they want, a cottage industry has sprung up around the idea that you should be able to write code in whatever language you like and "compile" it to some form that will run on the Android platform. Such tools get mixed reviews, but the very fact they exist suggests a much more developer-friendly ecosystem surrounding Android devices, above and beyond the simple fact of Apple's sometimes developer-hostile management of the App Store.

Things may be even better than you thought for choosing whatever language you like. There is a free open source app in the Android Market called the Scripting Layer for Android. Abbreviated SL4A, it is a combination IDE, API wrapper, and interpreter plug-in framework that can be used with a series of different language interpreters to run code. Among the currently available interpreters for SL4A are:

  • Bean Shell
  • JRuby (Ruby on Java)
  • Lua
  • Perl
  • Python
  • Rhino (JavaScript on Java)

SL4A is more than a mere toy; it exposes a subset of the Android development API to your scripts using the language's own syntax. It is even possible to bundle up your scripts into Android packages that can be installed like any other Android app. The developers do not make any claims of suitability for production use:

SL4A is designed for developers and is alpha quality software.

Every time I run a Ruby script in a terminal on my Android 1.5 device, I can see the "alpha quality" shine through: It starts by puking a full screen of error output into the terminal while JRuby starts up. Aside from that, I have encountered no problems with SL4A itself when writing and executing scripts written in Perl or Ruby.

Given that the Android API is an interface to the underlying Java API, there are some basic assumptions that can reasonably be made about how it works, but checking SL4A's API Overview and API Reference directly is a much better idea than trying to guess.

What SL4A calls the AndroidFacadeAPI is inescapably object oriented in flavor. For fundamentally object-oriented languages such as Ruby and Python, you should feel fairly well at home, aside from little coding conventions that differ between community best practices for the language and the AndroidFacadeAPI (such as using camelCase for method names rather than snake_case in Ruby). As I have rediscovered, however, Perl's reference-based implementation of its standard object model, combined with its painfully complex syntactic dereferencing rules, can be a bit of a stumbling block with an object-oriented API.

My day-long struggle with writing code on a cell phone in Perl while sitting in waiting rooms, eating lunch, and otherwise going about my day, reminded me in excruciating detail why it is that -- though I quite like Perl for many purposes -- object-oriented programming is something I avoid like the plague in that language. By contrast, I wrote scripts in Ruby using the AndroidFacadeAPI that present information gleaned by scanning local wireless access points, or information roughly equivalent to the output of ifconfig on a BSD Unix or Linux-based system, in a couple of minutes apiece in Ruby.

With SL4A installed, you can even use the built-in mechanisms on your Android device for adding application shortcuts to your "desktop" area to create icons that launch your scripts once you have written and saved them. The code-test-debug process offered by the minimalistic IDE that comes with SL4A is simple but effective and rewarding, especially if you find yourself sitting in an airport for a couple of hours, or waiting outside the changing rooms of a department store, with nothing but your Android device and an urge to write code as a means to occupy yourself.

Since installing SL4A on my Android device, the biggest problem I have had with it is getting myself to stop playing with it when my number is called at the sandwich shop.


Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

Sterling chip Camden
Sterling chip Camden

This environment is finally getting truly scriptable. Almost thou persuadest me to go out and buy a smartphone.

Justin James
Justin James

I just sent in a submission to Mary... about my struggles getting IronRuby working on WP7. :) It's theoretically applicable to IronPython as well, and I found a guy offering a Ruby interpreter to run on the phone as well. J.Ja


I think I understand the main underlying reason for your preference for WP7 over Android, now. Of course, your previously stated complaints about Android are valid -- but so are your previously stated complaints about WP7, so I have never really felt like those complaints were enough to explain the strength of your preference. The key, I suspect, has more to do with what you use on your workstation, as contrasted with what I use on mine. Because I tend to use Unix-like systems as close to exclusively as is reasonable, and you tend to use MS Windows systems, there is a built-in preference. It's not about the basic interface, though, given that WP7 and Android interfaces are more similar than either is to its workstation-installed genetic sibling. Instead, it's about the fact that we both write a lot of code. Until I started writing code for Android, I had a vague philosophical preference for it over WP7, but no particular practical preference to speak of. My preference for Android has grown as I have done more coding for mobile devices, though. That's because Android is essentially more compatible with my preferred development tools. Meanwhile, WP7 is essentially more compatible with the development tools you use every day. As I read your brief mention here of struggles getting IronRuby working, I found myself thinking "Why go through that trouble? In the end, all he's going to have is more .NET development, and there's almost no real benefit in that. I'd much rather just use Vim on my laptop, or even the SL4A native editor on my Android device, than screw around with a .NET reimplementation of Ruby." Then . . . it hit me! .NET is your de facto preferred development environment, because that's your habitual development environment. It is only natural that you would feel more empowered using IronRuby with .NET; by contrast, it is only natural that I would feel more empowered using JRuby with SL4A's API wrapper, especially since I get to just write what amounts to standard, portable Ruby code with no regard for a .NET ecosystem or anything like it, aside from my code that has to interact with the mobile hardware platform. For you, .NET code feels "portable", but for me it feels like the opposite; for me, run of the mill non-.NET Ruby code feels "portable", but for you it feels like the opposite. Both the Android and WP7 platforms have their problems for the user -- big, huge, annoying, face-stabby problems. They also present problems for developers. Each presents a very different development culture and environment; each of us has a different sense of what development culture and environment feels like "home". There, I think, is the real difference in preference. Let me know what you think about it.

Justin James
Justin James

Within a week of the RTW of the WP7 toolkit in its final form, I had my first WP7 app ready to go, despite never touching Silverlight before... simple familiarity with Visual Studio and the .NET libraries and the .NET concepts of "how things are done" got me most of the way there. Less than a week after getting my WP7 phone running, I had sideloaded an application which I've had under development (nowhere near ready for the marketplace) for personal use. What WP7 gives *me* is what *Nix gives *you*, which is the ability to rapidly leverage existing knowledge to customize and tweak things to work precisely the way I want. In fact, if you look at a lot of my WP7 development complaints (the technical issues), they revolve around that very issue, places where the SDK doesn't let me do what I want to really tweak things (like volume control). And you are 100% right about why IronRuby is attractive to me. It's because I have a great history with dynamic languages, and Ruby is really great to me... but at the same time, I have a huge investment in the .NET ecosystem. And my investment is *not* financial, it's time, energy, and learning. I've been using .NET as my primary development platform for 8 years now (has it been that long?). Switching platforms would mean having to relearn: * A language * The base libraries * The key libraries/frameworks for accomplishing common tasks (Web dev, I/O, XML processing, DB access, desktop apps, console apps, etc.) * The overall workflow model (for example, WinForms uses events to handle user actions... what do other systems do?) * Surrounding tools (debuggers, profilers, etc.) * The ecosystem (such as, "what Web sites have accurate information?") A lot of people seem to think that it's no big deal to learn a language... and it's not, at least not learning the basic syntax. I picked up Ruby's basic syntax fairly quickly, as expected. But for me to take "I know Ruby's basic syntax" and suddenly move to Eclipse + JRuby... well, not only would I be dumping years of learning, but I'd be spending months to daily work to achieve my current levels of proficiency. One of the things that I've learned is that there's a difference between spending 1 hour a week on something for 40 weeks straight, and 8 hours a day for 1 week on something... you'll learn a LOT more with the latter. Intense, regular work always teaches you more than casual use, even if the total time is the same. For me to be as effective in Eclipse + JRuby as I can be in Visual Studio + IronRuby, even if the former is provably a much better combination (and I have every reason to believe that Eclipse + JRuby is excellent), would take me months if not years. As you say, .NET is "portable" to me. I will, most likely, be able to get more done in Visual Studio + C# + Mono on a *Nix system than I could in Eclipse + Java on a *Nix system, despite the quirky nature of Mono and that fact that the combination violates so many principles of *Nix application design. Likewise, you'd probably do better with Perl (or Ruby) + Tk to develop a Windows application than you would to learn Visual Studio + C# + WinForms or WPF, even though the latter is much more so the "right way" to write a Windows app. Portability is not merely a function of technical specifications, ability to cross compile, etc., it's also a function of the knowledge base. Even when I was writing Perl/CGI, I deliberately went out of my way to write them in a manner that the base OS was irrelevant... despite writing Perl/CGI for many years, I never learned a thing hands on from the experience about the *Nix development philosophy. For example, while I have a passing familiarity with the fork/join model for parallel processing, it's at the "Wikipedia entry" level, not the hands-on, "could use this in a real project" level. But put me in the .NET environment, and I can write multi-threaded apps in 4 different paradigms without thinking too hard, just because I have a lot of hands on experience with the threading models that .NET likes. In terms of feeling like "home", yes, that's an astute observation. Every time I've started Eclipse, I felt lost. The only comparable feeling I've ever had like it in my life, was the first time I found myself in Penn Station in NYC trying to get a train back home. I had taken trains many times before, and coming *in* to the station was OK, but walking in that door and trying to go from "I'm in the station" to "I'm on the proper train with the correct ticket" was incredibly difficult, emotionally it was incredibly draining. It isn't that Eclipse is significantly more complex that Visual Studio (if anything, it's the other way around) or that the Ruby/JRuby/Java ecosystem is any more complex that .NET (they seem to be comparable), but that it's so different, I don't know where to start. I can't tell you how many times I tried re-igniting my learning of Java, only to fail an hour later... stymied by the Web site and not being able to figure out what to download! What's the different between J2SE and J2EE? Does JDK5 uses Java 6 or Java 5? What in the world is a "Spring" or a "Struts" or a "JNI" and do I need them too? Likewise, I'm sure that a non-.NET developer would have the same experience... what version of .NET lets me develop Web apps? What's the difference between ASP.NET, ASP.NET MVC, WinForms, WPF, etc.? LINQ-to-SQL vs. ODBC vs. ADO.NET vs. Entity Framework vs. LINQ-to-Entity Framework? When I started looking at Ruby, there were questions like, "what's a YAML and why is it important?" and "what exactly does 'Rails' or 'rake' or 'gems' do?" These are the kinds of things which insanely few tutorials, getting started guides, etc. take the time to explain. Hmmm. I think I know what to write about for two weeks out now. :) J.Ja


I was thinking you wanted to write an article about different developers' perspectives on different development ecosystems and platforms, based on their experience and skills. I don't think I'll ever write a complete article just about that, at least for TR -- it occurs to me there simply isn't enough concrete material in it to make it appropriate as an article for this venue. I will, however, touch on it briefly in the introduction to an article I'm planning for the open source column right now, though. I might put together something along the lines of a "basic Ruby techs" explanation, I guess. I'll have to see if there's a set of "default" technologies that makes sense to explain. Considering the open source Unixy culture of the main Ruby community, though, it's difficult to settle on a single example of central categories of technologies to consider "basic" or "default". It would be a lot easier to write an article covering the different Ruby implementations, and another covering the various Web frameworks, and so on. I mean, sure, YARV is the new default Ruby implementation, and Rails is the default Web application framework, but there's no single default marshaling format, no single database access library, and so on. An article covering three "basic" Ruby technologies with three to five sentences each seems pretty scant and dull. I guess I could spin a "basic Ruby techs I use a lot", and ignore the "defaultness" or popularity of my choices for the most part. > The JRuby ecosystem is only appealing to me because it allows Ruby to be run in places it normally would not go. Considering YARV runs just about everywhere, there are few cases where JRuby would be needed, by that standard. Android is the only platform that comes immediately to mind, and if you have a rooted Android device you might even be able to port YARV to it as a native binary. I'm not sure about that, though.

Sterling chip Camden
Sterling chip Camden

I saw a quotation the other day that had me in stitches: Saying that Java is great because it's portable is like saying that butt-f***ing is great because it works on all genders. That analogy works on multiple levels.

Justin James
Justin James

I'm going to write a brief primer on the basic .NET techs, what they are, what they do, etc. Something where I spend maybe 3 - 5 sentences per item. I'd love to see something similar for the Ruby ecosystem (for example, "YAML", "Rails", "Rubinius", etc.). That makes sense about not wanting to use JRuby until you wanted to do Android. The JRuby ecosystem is only appealing to me because it allows Ruby to be run in places it normally would not go. The Java libraries and interaction with the OS are not appealing to me. There's some useful stuff in there, don't get me wrong, and I feel like Sun's inability to do anything useful made the open source community around Java much more active than .NET's. But for the most part, the .NET world just watches Java (and Ruby, for that matter) and copies anything truly useful (ASP.NET MVC and NHibernate are two great examples of .NET cherry picking ideas from other systems) while leaving the less useful stuff aside. It's too true about Java & licensing issues. I tried a Java-based CMS on my FreeBSD machine ages ago... what a nightmare it was. Never mind the fact that I've always thought that Tomcat felt like a helpless kludge (my opinion of Apache dropped a lot due to Tomcat), just getting the JVM itself installed and running was a truly mindbending experience due to the licensing. I was utterly baffled by the decision making process that went into it. J.Ja


> Hmmm. I think I know what to write about for two weeks out now. Good thing I have other stuff in the queue, or I might beat you to it. By the way, I have never felt any urge to use JRuby until I basically had the choice to either do so or not write Ruby on Android. I don't really consider the JVM any more a Unix-compatible platform than Mono, and that poor fit between Java and Unix becomes incredibly clear in the way it is such an incredible hassle to install and set up for basic use, sometimes. Unlike Mono, it's not even "free" enough to install legally without bowing and scraping for a corporate benediction. Attempts to integrate it with the primary software management archives of open source OSes result in more of a pain to install than downloading an installer from Oracle and doing so outside of the software management system on Red Hat. Of course, the latter results in a lack of centralization of managing your installed software, which means you're breaking one of the benefits of using an open source OS. Java is "portable" in that it's about equally annoying and ill-fitting on every platform. re: portable code (as you mentioned with Perl) For anything more than a glorified sysadmin shell script, I try to write platform-independent code as well. It's pretty much the case that, as long as your OS has something the language can treat as STDIN and STDOUT, my code should probably run on it. I find that this greatly improves the quality of code when working with a dynamic language, since touching the underlying system too intimately starts making the design of the system show through the syntax of the language too much, damaging the illusion of a consistent development model built into the language. Knowing how the underlying system works is important, of course, but that doesn't mean your code should look like the underlying system when writing code in the Unix tradition.

Editor's Picks