Chapter 47

Other Alternative Environments

The alternative application environments described in the preceding chapters represent but a few of the growing flood of such technologies. Here, we will take a brief look at a few other alternative application environments.

Rhodes

Rhodes (http://rhomobile.com/) is similar to PhoneGap insofar as you develop an Android application whose user interface is defined via HTML, CSS, and JavaScript. The difference is that Rhodes bakes in a full Ruby environment, with a Rails-esque framework. Your Ruby code generates HTML and such to be “served” to an activity via a WebView widget, much like a server-side Ruby web app would generate HTML to be served to a stand-alone web browser.

Similar to PhoneGap, you can either build the project on your development machine or use their hosted build process, RhoHub. The latter method is recommended, partly because the requirements for local builds are higher than those for PhoneGap—notably, Rhodes requires the Native Development Kit (NDK) for building and linking the Ruby interpreter to your application.

Rhodes winds up creating larger applications than does PhoneGap, due to the overhead of the Ruby interpreter (~1.5MB). However, if you are used to server-side web development, picking up Rhodes may be easier for you than picking up PhoneGap.

One area in which Rhodes differentiates itself is by providing a set of connectors and a server-side service known as RhoConnect, all of which act to offer integration between Rhodes-developed Android applications and various enterprise and business systems.

Flash, Flex, and AIR

Adobe worked long and hard to extend its Flash, Flex, and AIR technologies to the mobile space. Histroically, you could use Flex (the “Hero” edition) and Flash Builder (the “Burrito” edition) to create Android APK files that can be distributed on the Android Market and deployed to Android devices. Those devices would need to have the Adobe Integrated Runtime (AIR) installed, which is free, but is a large download and works only on Android 2.2 or later devices with later-model ARM processors (specifically, ARM v7 or later processors, so some early model devices that run Android 2.2 or 2.3 are out of luck, such as the LG Optimus V).

Then in November 2011, Adobe announced that Flash for mobile devices (Android and other platforms) would be no more. If you read the preceding chapter on PhoneGap, you can probably draw your own conclusions about where Adobe is going in the mobile space. Adobe certainly has been gathering a lot of technology and know-how in the realm of tools to build Flash code and then convert it to HTML5 and related non-Flash technologies. Only time will tell if this move is a success for them in the mobile space.

AIR is not as tightly integrated with the platform as PhoneGap is (e.g., AIR provides no access to the device's contacts), though this is an area to which Adobe likely will devote more resources now, likely leveraging the know-how it acquired with the purchase of Nitobi.

JRuby and Ruboto

JRuby (www.jruby.org/) is one of the most popular languages designed to run on the JVM—besides Java itself. JRuby was quickly ported to run on Android, but with some optimizations disabled, since JRuby is actually running on the Dalvik virtual machine that underlies the Android environment, not on a classic JVM.

However, JRuby alone cannot create Android applications. As a scripting language, there is no way for it to define an activity or other component—those need to be registered in the application's manifest as regular Java class files.

This is where Ruboto (http://ruboto.org/) comes in. Ruboto is a framework for a generic JRuby/Android application. It provides skeletal activities via a code generator and allows JRuby scripts to define handlers for all of the lifecycle methods (e.g., onCreate()), define user interfaces using JRuby code, and so forth. The result can be packaged as an APK file using supplied Rake script. The results can be uploaded to the Android Market or distributed however else you desire.

Mono for Android

Mono is an open source reimplementation of C# and .NET for non-Windows environments. Mono has had its fair share of controversies, mostly stemming from Microsoft, such as whether Microsoft will someday squash Mono over patent considerations.

Mono for Android has been in the works for some time. This would allow Mono developers to target Android for their apps. In principle, one could develop C# applications for Android this way.

While Mono itself is an open source project, Mono for Android “is a commercial product...licensed on a per-developer basis,” hosted by Xamarin (http://android.xamarin.com/). This may come as a bit of a shock to developers who are expecting Mono on Android to remain open source. As of late 2011, the Xamarin web site lists prices starting from $399 per developer.

App Inventor

App Inventor (http://appinventor.googlelabs.com/) is an Android application development tool made available by Google, but outside of the normal Android developer site. App Inventor was originally developed for use in education, but Google has been inviting others into their closed beta.

App Inventor is theoretically a web-based development tool. Here, “theoretically” means that, in practice, users have to do a fair amount of work outside of the browser to get everything set up:

• Have Java 1.6 or later installed and functioning in the browser, capable of running Java Web Start (.jnlp) applications
• Download and install a large (~55MB) client-side set of tools

Once you set it up, App Inventor gives you a drag-and-drop GUI editor, as shown in Figure 47–1.

Figure 47–1. The App Inventor “Designer” view

App Inventor also gives you a Blocks Editor (see Figure 47–2), where you attach behaviors to events (e.g., button clicks) by snapping together various “blocks” representing events, methods, and properties.

Figure 47–2. The App Inventor Blocks Editor

While working in the GUI editor, if you've chosen to build your applications directly to an attached device, you see what you are building live on the attached device and can test it in real time. Later, when you are ready, you can package the application into a standard APK file.

However, App Inventor is not really set up for production application use today:

• You cannot distribute App Inventor apps on the Android Market. Google claims this is due to technical limitations that were being actively worked on, but this status has not changed for much of 2011.
• It has more components aimed at “sizzle” (e.g., Twitter integration) and fewer components delivering capabilities that a typical modern app might need (e.g., relational databases and lists).
• Shared development is primitive, where additional developers upload and download ZIP files of the project code.
• Perhaps the biggest limitation is its single-screen focus, meaning having additional activities with different screens is beyond App Inventor's scope.

In the future, it is possible that App Inventor will become a solid option, or that App Inventor will trigger other firms to create similar sorts of programming-free development options for Android.

Titanium Mobile

Titanium Mobile's claim to fame is that it uses JavaScript only to define the user interface, and eschews HTML entirely. Its JavaScript library, in addition to providing access to databases and platform capabilities, lets you declare user interface widgets. But its layout capabilities, for positioning said widgets, leave something to be desired.

As of the time of this writing, Appcelerator (www.appcelerator.com/), the creator of Titanium Mobile, does not offer a cloud-based set of tools. It does offer a program called Titanium+Plus, offering additional SDK components to talk to other cloud-based services such as Twitter and PayPal. Its Titanium tool has a very slick-looking UI, but it still requires the Java SDK and Android SDK in order to be able to build Android applications, making the setup a bit daunting for some.

As of the time of this writing, Titanium Mobile supports development for Android and iOS. Plans for Blackberry support, which was in a private beta, seem to have been suspended.

Other JVM Compiled Languages

If you are happy with regular Android development, but you just do not like Java, any language that can generate compatible JVM bytecode should work with Android. You would have to modify the build chain for that other language to do the rest of the Android build process (e.g., generate R.java from the resources and create the APK file in the end).

Scala (www.scala-lang.org/) and Clojure (http://clojure.org/) are two such languages, whose communities have put together instructions for using their languages for Android development.