This version of RhoHub features several significant new features:
- you can build apps with Rhodes 2.0 or any other development branch of Rhodes
- if you choose to use sync in your app, your RhoSync server is hosted on Heroku. This provides a high level of reliability and easily scalable infrastructure
- we provide built in source code control by supplying you with your own git repository.
- the built in git repo also makes it very easy to use your own local IDE or editor and still get the benefits of hosted build and runtime synchronization

Note that because of the desire to integrate local editors and IDEs there is a significantly different workflow for app development. To “offline Rhodes developers” it will seem quite familiar. To existing RhoHub users the development process changes a bit. We will be reenabling a new much more scalable and powerful web-based IDE in a coming release.

Most importantly the new RhoHub is a great platform to add other robust services to facilitate mobile development. Forthcoming features include a hosted streaming media server (bidirectional high definition audio and video to and FROM your smartphone) and a hosted app provisioning and management portal (host your enterprise-focused app store online!).

One very important distinguisher of better quality informational apps is synchronized offline data. Specifically giving your users the ability to read and work with their information when disconnected. The widespread failure of mobile web browsers to make a dent in enterprise app usage demonstrated that user’s want to interact with data locally before trusting that their changes are applied. Just as all mobile email clients use synchronized data, study after study shows that users won’t interact with their app backends unless the data is made available locally. Even in the cases where data is just read or downloaded (such as a newspaper app with articles or an RSS reader), having the data cached and available offline is very valuable and is almost universally done among the higher rated reader apps.

So how do you as an informational app developer do this? At a high level there are three options:

1) write the synchronization yourself
If you want to provide incremental data updates you’ll need some kind of server logic hosted somewhere to figure out the deltas to send to the device. If you want to do it bidirectional data sync it becomes even more forbidding, especially if you want to handle or prevent conflicts. If you want to do “push sync” it becomes extremely impractical
to write this yourself. If you are talented enough to do any of the above your talents are better applied writing great apps then squandering them to avoid buying a sync server license.

2) use a “first generation” sync server
Sync servers for mobile apps have been around for a while. Pumatech’s IntelliSync was a huge business before being bought by Nokia and discontinued. These days Sybase does a great business around mobile synchronization. So does Antenna (note that servers for PIM and email sync such as Funambol are not included here as “sync servers” – we are referring to sync servers for arbitrary structured data not PIM information). There are many other sync servers that got their start ten to fifteen years ago. We certainly recommend this option over writing your own or not doing sync at all.

3) use a sync server targeted at the modern smartphone
RhoSync was written from the ground up to target the modern smartphone. For one, modern smartphones all have push APIs built in. iPhone has had push since the 3.0 SDK. BlackBerry introduced push into their latest BES server. Use of push-based sync let apps receive data updates near realtime AND insures that battery life is not drained on the devices due to the need to constantly poll. Finally modern smartphones are more than an order of magnitude more powerful which allows the sync and database handling to be tuned to these devices, which are very different from the featurephones that earlier sync servers were targeted at.

RhoSync has many key aspects that alleviate the fear that some modern developers have about sync:

1) it’s open source under the GPL
There is no lockin to proprietary vendor technology. IntelliSync users faced a lot of pain when Nokia discontinued that product. RhoSync enjoys many key contributions from the wider open source community

2) it’s much less expensive than earlier sync products
RhoSync licenses start at just $10,000. As the numbers of users grow the price per user drops drastically to as little as $0.16 per user

3) it’s much easier to write for than other sync server yet released
The typical RhoSync source adapter is less than a page of Ruby code and four significant methods: query, create, update and delete. The experienced mobile developer is usually stunned by how much simpler we have made the process.

4) the programming model of the client app is usually drastically simplified
At least with the Rhodes framework, if you use synchronized data (which is NOT required, you can connect Rhodes apps directly to your backend application if you wish) you have a much easier development effort. You can just assume that all of your data is available locally in your database. There is no effort expended in connecting over http or https and parsing either XML or JSON. RhoSync does all of that work for you. The data is all available in the local database. And you can use the ORM (Rhom) to access it without writing SQL.

To see an example of development of a RhoSync app, consider attending tomorrow’s free training webinar where we will show building a synced data app for BART train schedules in a handful of lines of code. And the resulting app is usable by occasionally disconnected harried commuters wherever they are.

There are recorded webinars on all of the features of Rhodes on our Vimeo channel (this Friday’s webinar is on PIM contacts and alerts).

And just an update for many of you because you asked, Rhodes apps are continuing to be accepted on the App Store (as we indicated they would be) even after the iPhone 4.0 Terms of Service went into effect. Some of the recent apps accepted include TrackR 2.0 (a free app for PivotalTracker), Metalingual (an app for language translation from Sarah Allen), WorshipPlanner, and iFirefigher.

We’re looking forward to seeing many more Rhodes 2.0 apps from all of you. Drop us a line to tell us about them.

A couple of the other talks, from otherwise insightful web framework developers, who apparently have “smartphone envy”, were disturbing. One speaker talked about his efforts to make Rails a little better for iPhone browsers accessing it as enabling “mobile apps”. This is a bit ludicrous now because users clearly prefer to run local native apps on their device versus accessing websites, especially for anything they use more than once.

One theme I’ve heard (again more from people pushing their web framework enhancements than from app developers, web or otherwise) is “once HTML5 is commonplace on mobile browsers that will all change and users will prefer browser-based apps”. So let’s take a look at this theory more closely:

First of all we should clarify that advances in HTML are unambiguously a great thing for mobile, whether for true native apps (such as those created by Rhodes) or mobile web apps. Rhodes uses HTML, CSS and JavaScript for its user interface rendering (as do other smartphone app frameworks that have followed us into the space). The richer the HTML capabilities, such as the extensions available in HTML5, that are available the better all such framework apps can be.

But of course HTML5 support on mobile devices also allows better mobile web apps. HTML5 supports storage to the device database. It also provides geolocation. So does that mean that mobile web apps are poised to become things that smartphone users interact with primarily? That won’t happen for several reasons:

device capabilities

Although geolocation is now present in HTML5, smartphone device capabilities are exploding by leaps and bounds. Smartphones pretty much all support: interaction with PIM contacts, camera, accelerometer, magnetometer, push, and native mapping. It will be many years before these capabilities show up in a W3C proposed standard and many more years before a smartphone browser implements them. If you have any doubt track how long it took from the proposal for HTML support for database storage to take effect (first floated in the 1990s). By that time there will be many more device capabilities as smartphones continue to evolve at a furious pace.

synchronized local data

It’s one thing to say that you can store some information to a table, or even cache it. It is quite another to intelligently, incrementally and efficiently synchronize that data to connecting devices so that information can be used offline. For purely one way data, automatic caching has its place with some more unstructured data apps and sites (such as news reading and social networking). For more structured bidirectional data the ability to store a record locally via HTML and JavaScript isn’t providing much compared with the ability to truly synchronize structured data bidirectionally. That typically is going to require some significant logic on the device.

offline usage

But even if the app isn’t information intensive it is critical for the app to be able to be used offline. All modern smartphones today are “occasional connected”. But its rare today (and will be for a while) for a device to have 100% reliable connectivity all the time. Users want apps that they can use whenever they want to, wherever they are. That is a big driver of the success of the App Store. Its just not possible with a mobile web app.

Its great for both users and developers of both mobile web apps and true native smartphone apps that HTML5 brings more capabilities to the table. But if you are a developer who wants to get the most usage of your app the maximum amount of time from your users, you’ll want to provide them with a native app.

Most refreshingly if you use a framework like Rhodes, you don’t have a big dilemma. You can use the power and productivity of HTML5 in your Rhodes views and still deliver the usability and ubiquity of a true native app.

• streaming bidirectional High Definition audio and video (to and from the device)
• a “metadata framework” which lets software developers write apps that work with enterprise applications that do not have fixed schemas or database structures
• a much faster sync server
• our own comprehensive styling library that provides optimized interfaces on ALL smartphone devices.

Sign up for the beta today!

We were also very surprised and pleased to win the Web 2.0 Launchpad award yesterday.   This was given out by audience acclaim (a “Clap-O-Meter”) and seems to be validation that our message of “use your existing web development skills to write native apps” has resonance among web developers.     In particular, based on booth traffic and feedback, this audience of modern web developers seemed to really appreciate the industry’s only Model View Controller framework for smartphones.

But to make sure our loyal developers are 100% safe in using our framework, we will be announcing some new products soon that facilitate enterprise app distribution for iPhones and other devices, completely bypassing any App Store. These products will ensure that Rhodes remains the go to framework for cross-platform development on all major smartphones.

Finally we will be taking our RhoSync sync server and forthcoming server products and supporting client apps written in Objective C. Even prior to the latest iPhone 4.0 TOS controversy we had many Objective C developers asking to be able to use our sync server. We will be providing a C++ library usable from your Objective C apps to provide your users with the convenience of synchronized offline data. We will also be providing an Object Relational Manager that is usable from Objective C that allows you to work with data intensive apps without working with SQL

In summary your investment in learning the Rho toolset will be maintained regardless of future App Store testing procedures, especially if you are an enterprise app developer.

We always knew that the base “write HTML/CSS/JavaScript to generate native apps” category would explode. Because it is so clearly the right way to rapidly write apps across multiple devices. And it has: there are now seven players in this base category including PhoneGap. Rhodes has several major architectural aspects that differentiate it longterm from all of these entrants.

ONLY MODEL VIEW CONTROLLER FOR SMARTPHONES
Rhodes is the only framework that uses the Model View Controller pattern. You can write just HTML, CSS and JavaScript to do all of your app. In effect, writing your entire app in the View. If you do this Rhodes is just like all of the imitator frameworks.

But the value of a Controller and use of MVC is very real. It is theoretically possible to write a web app or website with HTML, CSS, and JavaScript and no backend logic, putting all of your logic into JavaScript in the page. But this NEVER happens for an app or site with any complexity whatsoever. All web apps have some backend: either Java or PHP or ASP.NET or Python or Ruby. That is what the Rhodes MVC framework gives you for native smartphone apps: the ability to write real business logic in your local native app on the device.

Rhodes is the only framework with MVC support. This explains why there are so many robust enterprise apps written with it something missing entirely with other frameworks. Rhodes enables you to take modern web development and enterprise app development goodness and apply these best of breed techniques to building native smartphone apps.

ONLY OBJECT-RELATIONAL MANAGER FOR SMARTPHONES
In 2010 ORMs are the way that web developers interact with databases. In web apps it’s rare now to see direct SQL calls. And that’s a great thing for developer productivity and reliable code. Rhodes features the only ORM for native smartphone apps, whether from frameworks or even direct smartphone OS SDKs.

ONLY FRAMEWORK WITH SYNCHRONIZED OFFLINE DATA
This is the ability, provided by the Rhodes framework combined with the RhoSync server, for apps to make data available to their users when they are offline and disconnected. Rhodes is the only framework to offer sync. Doing sync servers well is a very nontrivial effort (far larger than the effort to build a HTML/CSS/JavaScript framework) so this is likely to be true for some time.

The availability of data when disconnected and the ability to transparently synchronize with a backend app have been shown time and again to be necessary to making enterprise users comfortable with transacting from their devices.

SUPPORT FOR ALL DEVICES
Rhodes supports all smartphone device operating systems as first class citizens: iPhone, Android, BlackBerry, Windows Mobile and Symbian. Symbian support was held in abeyance at 1.1 but will be caught up in the 2.0 release soon. WebOS support is underway. There will be more smartphone operating systems emerging as well including Intel and Nokia’s Meego OS. Rhodes has always led in the device OS support area and will continue to do so in the future.

FIRST MOBILE RUBY
Much of the benefit of Rhodes would be achieved no matter what we chose for the language that is used in the Controller. But Ruby is very understandable, terse and powerful and the world’s fastest growing programming language. We’ve seen Java shops and .NET shops enthusiastically embrace Rhodes.

We built the first Ruby implementations for every smartphone device operating system. There is now a Symbian Ruby available as well from Pragmaticomm. And there is also a JRuby implementation running on Android (our Ruby is C-based and hence smaller and faster). We actually look forward to the day when Ruby implementations will ship with all phones. Our value is in the entirety of the framework and supporting servers. But in the meantime providing an advanced dynamic language like Ruby on the device is pretty exciting to many developers.

HOSTED SERVICE FOR DEVELOPMENT
Rhodes provides the world’s first Development as a Service for mobile. You can write your apps online on RhoHub. In effect we give you a web-based Integrated Development Environment. We also let you do builds for all smartphone operating systems online. Finally at runtime we host a sync server for you and app provisioning is under development.

We do tell developers that if they don’t need ANY of these capabilities they should consider a simpler framework such as PhoneGap. That said we have yet to see an enterprise state that none of these differences were relevant and choose another framework.

Our lead over imitator frameworks is very large and growing larger. Over the next few weeks we’ll unveil some of the new features that are even more exciting than these major differences.

The Wholesale Applications Community finally creates a viable app marketplace for phones beyond the iPhone. Yes, there were marketplaces for Android, Windows Mobile and Palm, but with far less traction. This new marketplace should gain critical mass quickly. More interesting is how to target an app for all of the phones available on that marketplace. Rhomobile’s Rhodes is the only framework that allows building native apps with synchronized data for all of those devices.

Microsoft finally shipped Windows 7 aka Windows Phone. With support for touchscreen usage through and through it looks to be a big winner. Developers will get the features of some “more modern” smartphones with Microsoft’s huge installed base of Windows Mobile apps. Using Rhodes will let developers write for Windows Phone and their apps will work on all other smartphones as well.

Also, smartphone installed base leader (by a wide margin) Nokia and Intel announced a new smartphone OS, Meego. Meego combines features of Moblin and Maemo to create yet another strong contender in the smartphone marketplace. So, as predicted on this blog many times, there are now seven major smartphone OSes. Rhodes supports five of them today, and the other two soon. Developers are flocking to smartphone app frameworks (a term we coined) to enable them to handle this dizzying diversity.

To address this today we announced Rhodes 1.4 stable production release. Among the many new Rhodes 1.4 features:

* support for a host of new Ruby gems in Rhodes: net/http(s), JSON, REXML (XML) , crypt, openssl, digest, lang, set, fcntl
* extension framework for adding third party extensions (gems) to Rhodes* API for returning screensize (write apps that handle the iPad gracefully!)
* native mapping for RIM BlackBerry (in addition to native mapping on iPhone)
* improved logging (from Ruby in Rhodes)
* support for the RIM BlackBerry 5.0 Java Development Environment
* a Mac OSX debugger (stepwise debugging in Ruby)
* improved spec running framework (do Test Driven Development on your smartphone! where else can you get that)

Support for net/http and net/https is being widely used to connect directly to backend sites. JSON and Rexml let you work with data on the device. The screensize API lets you conditionally handle different screensizes even better. Due to use of the browser component Rhodes excels at handling different screensizes. But having an explicit API makes it even better. The Mac OSX debugger for Rhodes allows you to debug your smartphone apps realtime.

In summary, Rhodes 1.4 provides a rich Ruby environment for native smartphone development. Write powerful apps once – compile to run everwhere. It offers a modern, productive development capabilities hitherto not available in mobile. Specifically interactive debugging, logging and spec-driven Test Driven Development is now possible in a framework which reaches all smartphones.

But we’re seeing a lot of the projects that enterprises exposes to consumers. These include claims apps for three different insurance companies that should all be hitting the market soon (I won’t steal their thunder by announcing them now). Consumers can use them to manage claims and other aspects of their vehicle or healthcare insurance right from their device. We’re also still happy by the Wikipedia app and its status in the top 100 public apps on the AppStore.

I met with Michael King of Gartner yesterday. He made the point that these apps were not “outliers”. The value that the Rhodes framework has that doesn’t exist in other frameworks (synchronized data, a Model View Controller paradigm, support for all devices, Ruby on the device and a hosted development environment), also apply to consumer apps. But the common thread is that the apps must be of a certain complexity and focus on data in order to necessitate most of these features (well certainly synced data, MVC and Ruby). Or you need it to go beyond two or three smartphone device operating systems.

If it’s a simple consumer “branding app” of a page or two, and its just for a couple platforms (iPhone and Android) its likely that either a small Objective-C app (rewritten for the other device) might suffice. Or you can write it in some other HTML framework such as PhoneGap since you don’t truly need the power of Rhodes sync or MVC or Ruby or multiple devices.

But for a wide swath of consumer apps you do care about hitting every available smartphone, you want a bigger hammer than just HTML and Javascript (such as Ruby on the device) and you want a more maintainable approach such as MVC for larger apps. Furthermore, though most App Store apps don’t use sync, the ones that do get a lot of differentiation in the sea of copycat apps that are appearing up there. For example, the claims apps qualify, location finder (of whatever: coffeeshops, restaurants, points of interest) apps qualify, anything where the user’s enter information (reviews, ratings, and pictures for annotation) qualify. How to describe these information oriented, utilitarian more complex apps for consumers.

How about “infotility?”. There was a category on feature phones called “infotainment” a few years ago. Infotilities are larger (more than one page), richer in capabilities (exploit what the modern smartphone can do, often sync or cache data and are often bidirectional.

So… thanks Michael. We’ll be sure not to ignore these consumer developers as you suggest. And let us know what the right category phrase is.