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:
- Buy mobile device
- Develop mobile app
- . . .
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)
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.