• 22 09/09

    the first mobile Ruby

    Our open source framework Rhodes contains the first implementation of Ruby for every major smartphone operating system: iPhone, Android, BlackBerry, Windows Mobile and Symbian. The primary benefits of the Rhodes framework are: the productivity and portability enabled by writing interfaces in HTML once (and compiling to native smartphone apps), access to device capabilities from a common library used on all smartphone devices and the ability to easily incorporate synchronized data for offline use.

    But that said, we may have been underestimating the benefits that Ruby has for mobile development irrespective of the Rhodes framework which uses it. Ruby has compelling advantages for building smartphone apps that are worth describing in their own right:

    • scripting language. Everything from implied (duck) typing to easier creation of classes and functions to built in support for regular expressions result in much higher productivity
    • economy of expression. Ruby apps are often less than a third of the size of equivalent Java apps. This helps to make apps easier to maintain even after the initial productivity boost. We’ve found that the best mobile apps are small apps. HTML for UIs helps enormously to minimize code size. Ruby for controllers helps make sure that economy gain isn’t lost. The result is that Rhodes apps are usually less than 20% of the size of underlying SDK apps (e.g. Objective-C apps)
    • rich ecosystem. On GitHub, RubyForge and elsewhere Ruby gems and plugins abound. The success of Ruby on Rails has spurred a huge industry of addon capabilities that can be leveraged by mobile developers using Rhodes as well
    • pure object-oriented design. This makes it easy to build both an overall framework on (such as Rhodes or Rails), and also develop libraries for


    If you’re not using Ruby today for web development, we strongly urge you to consider it (our RhoSync server is a Ruby on Rails app of course). Ruby on Rails can be used productively by relative Ruby novices (although being a programmer comfortable with the Model View Controller pattern certainly helps conceptually). If you’re not using Ruby for mobile development, we’d encourage you to consider the Rhodes framework. If you’re uncertain about your ability to do so without Ruby skills, we’d encourage you to try it regardless. As an MVC framework most of your UI will be done in the views as HTML templates anyway. Our RhoGen app generator creates the Ruby code for the controller, which does basic Create, Read, Update and Delete of synchronized data on your phone right out of the box. But you can also use this controller code to learn Ruby, modifying and extending the code slightly as time goes on.

    Since we first shipped Rhodes last December, we’ve been happy to see other mobile Ruby implementations emerge. Pragmaticomm has developed a mobile Ruby for Symbian. We’d like to eventually merge our Ruby with theirs. Charles Nutter has an Android version of JRuby well on its way to completion. Once it is complete we’ll take a look at the size and perhaps adopt it. I also talked with Matz at this year’s EuRuKo about factoring out our mobile Ruby implementations and getting it merged with general 1.9 development (this would save us ongoing work of course).

    Otherwise today Rhodes is the only way to do Ruby development on the leading US smartphone operating systems: iPhone, BlackBerry, Windows Mobile. But because of the advantages of Ruby listed above, I have no doubt that will change and all smartphone operating systems vendors will eventually ship their own mobile Ruby implementations. That’s OK as we really are the “open mobile framework” company not the “mobile Ruby” company. But helping you developers build apps faster by providing you that mobile Ruby implementation now instead of years into the future is an exciting privilege.

    0 Comments | Posted by admin

  • 12 09/09

    the enterprise smartphone server

    Rhodes is a great option for allowing developers to write their smartphone apps one time and have them run natively on all devices. After being out for a while several competitors emerged and now we have a product category known as the “smartphone app framework”, with several participants. We believe that our first mobile Ruby, our fullfledged MVC framework, our hosted development site RhoHub and, most importantly, support for synchronized data, are longterm differentiators. But in such as a nascent area its better to have some other players out there helping us educate the market.

    I’d like to predict a new category to beyond the device side “smartphone app framework” that I think will emerge over the following year: the “enterprise smartphone server”. One of the things that we’ve learned in working with enterprises mobilizing their apps is just how important synchronized data is to all of them. So we’ve emphasized development of the RhoSync server, adding features to take advantage of recently emerging smartphone APIs (such as the push SDK) to optimize synchronization performance and recency, enabling selective synchronization, and allowing background sync on the server (also known as paged query).

    Our belief is that every enterprise will be mobilizing several of their applications: CRM, field service, helpdesk, and one or two line of business apps (especially in certain industries such as healthcare or manufacturing or logistics). They will always want the data from those applications available on their employees smartphones whether or not its disconnected. We believe that every enterprise will thus need a smartphone synchronization server to facilitate this. With RhoSync, we believe that we’ve achieved this. And, given our support for recent smartphone push SDKs, we’re alone in this new space.

    But just as there are now several other smartphone app frameworks to write native apps one time for multiple devices, we know that eventually there will be competitors. We don’t think its likely that they will come from “old line sync servers”. Most of those are dormant: Nokia discontinued IntelliSync, Motorola cancelled Starfish. Others come from “first generation enterprise mobility” players such as Sybase, whose technology is not acceptable on the iPhone (because it requires a downloaded “runner” or “interpreter and is thus not acceptable on the AppStore).

    We do think that there are other “enterprise server helping smartphone app” needs that we aren’t quite addressing now. The biggest ones are device manageability, security, app provisioning, and analytics. Sync is the biggest need now and its what RhoSync and the runtime of RhoHub currently offer today. We do want to make all aspects of mobilizing apps to smartphones very easy for enterprises though. Over time the RhoHub hosted service and our mediating server RhoSync will add other enabling capabilities (sometimes through partnerships with existing technologies). RhoSync is thus the first “enterprise smartphone server”, but we think there will be many others.

    Given the explosive growth and emerging ubiquity of smartphones, fullfledged computers in every enterprise employee’s pocket, we see this as the most important new enterprise middleware category since the app server and the relational database server. What BEA did for app servers and Oracle did for relational database servers, we intend to do for this new category.

    0 Comments | Posted by admin

  • 07 09/09

    use your web dev skills to build NATIVE smartphone apps

    I’ve been speaking at a lot of Ruby conferences over the past few months (almost every one). The attendees of these conferences are almost all web developers. They see that the big growth opportunity in software today is writing native smartphone apps (not mobile web apps, a category that the App Store has basically killed for many good reasons). But they are worried that they have to learn specialized arcane skills such as Objective C and the iPhone SDK, or Java and the Android SDK or C++ and, if they are outside the US, the Symbian SDK in order to be productive writing such apps. Learning any of those skills individually is a daunting task. The combination of them is well nigh impossible in a timeframe sufficient to actually release an app for today’s marketplace.

    There is an alternative: a “smartphone app framework”. When we released the first version of Rhodes last December we coined this term. To our delight a robust marketplace has emerged of such tools as reported by InfoWorld recently. Flavio Ishii recently blogged on this phenomenon as well. Smartphone app frameworks let you write your user interface for NATIVE apps (NOT mobile web apps) using HTML, JavaScript and CSS. The user has no idea that these were build with an embedded browser component.

    CSS is used to style the HTML to look native. Joe Hewitt pioneered this approach prior to Rhodes existing, with his IUI library. Rhodes ships with CSS libraries for iPhone, Android, Windows Mobile and BlackBerry to make the HTML look more native very much inspired by IUI. But developers can use third party libraries such as IUI or IWebKit by just adding them in the CSS directories of their Rhodes project. Smartphone app frameworks all provide some method of accessing native device capabilities. For Rhodes this is a combination of JavaScript libraries and Ruby libraries.

    Today Rhodes goes beyond other smartphone app frameworks in several areas:

    • support for all popular smartphones
    • the first mobile Ruby implementations running on all smartphones (HTML is great for the interface, but having Ruby far more powerful than trying to write your whole app in HTML and JavaScript)
    • the only smartphone focused sync framework (client in Rhodes and separate RhoSync server) in the industry

      Discussion of each of those differentiators are worthy of their own posts.

      0 Comments | Posted by admin