RubyMotion gives you a toolchain to write iOS and OS X applications in Ruby, which are then compiled to native code using an LLVM based compiler. With the upcoming 3.0 release, it will also include support for Android. The development process on Android will be similar to the iOS one: rake is used to build and run the apps, and also to generate the manifest and handle resources.
For the Android version, HipByte built a new Ruby runtime from scratch. To improve performance and Java interoperability, the Ruby core classes (Fixnum, String, Array, etc) are based on their Java counterparts:
This unified runtime approach provides an excellent integration with Java APIs as well as good performance, since objects do not have to be bridged. The runtime uses the Java Native Interface (JNI) in order to integrate with Java, and the entire set of Android APIs is available in Ruby, out of the box.
The memory management is delegated to Dalvik’s generational and concurrent garbage collector. The runtime creates and destroys global references when needed (such as when an instance variable is set), and the destruction of local references is determined at compile time.
The garbage collector is very efficient; it features a per-thread allocation pool for fast allocations, finalizations can happen on dedicated threads, and cycles are properly handled.
We were curious on how exactly they managed to implement a garbage collected Ruby runtime that is statically compiled to machine code and integrates with Android's runtime, so we talked to HipByte's founder Laurent Sansonetti.
InfoQ: In RubyMotion, Ruby classes are mapped directly to Java classes without bridging, but it's still compiled to machine code. Could you elaborate on how this all plays together?
The Android Java virtual machine exposes a C-level API called JNI, that lets you interface with the Java VM from a C code base. In the Android world, this is part of NDK.
RubyMotion is a statically compiled version of Ruby. The static compiler will transform Ruby code into machine code. In the case of Android, the generated machine code will call into the JNI API in order to interface with Java (ex. send Java methods).
The process is similar to what ART, the new Android runtime, is doing. With the exception that RubyMotion apps are already pre-compiled into machine code, while ART, as far as I know, does the compilation on the device.
The Ruby object model has been rewritten on top of Java, which means that objects do not need to be bridged, converted, translated from Ruby to Java, and vice versa. Similarly, some of the Ruby core builtin classes are based on their Java counterparts (ex. Array is based onjava.util.ArrayList).
InfoQ: How do you handle Ruby's meta-programming facilities when you compile the code?
The fact that RubyMotion offers a compiled version of Ruby does not limit meta-programming. We support the entire set of meta-programming APIs, with the sole exception of #eval, since we do not ship an interpreter with apps (mostly to comply with Apple's policies).
InfoQ: You are using Dalvik's GC, but how does this work with the memory allocated by the native code?
The native code that we generate from Ruby uses the Dalvik (or ART) GC indirectly, all the memory is therefore managed. For certain objects, the runtime might allocate memory manually, and it will be free'ed when the finalize method is called.
InfoQ: Can I continue to use my favorite Ruby Gems?
RubyMotion for Android has certain limitations, exactly the same as RubyMotion for iOS and OS X. Because it’s a statically compiled version of Ruby,#requireis not supported (all the files have to be provided at build time) and#evalis also not implemented (see above). Therefore, regular Ruby gems will not work.
RubyMotion has its own version of gems, specifically designed for it. motion-toolbox.com is a curated list maintained by the community.
InfoQ: Can you already say something about performance of RubyMotion apps? Isn't there a significant performance penalty when using JNI?
We haven’t done any performance work yet, but I did preliminary testing and our implementation seems to work just fine with no significant performance increase. Calling into JNI doesn’t seem to be a problem. In fact, a lot of the Android runtime is written at the same level and uses the same APIs that we do.
InfoQ: Thank you for the interview!
RubyMotion for Android isn't available yet, but they are looking for interested beta testers. The final release is expected later this year.
Do you have a RubyMotion iOS app that you are planning to move to Android? Are you an Android developer looking forward to (or maybe you already are) writing apps with Ruby? What do you think about RubyMotion for Android?