With our shared passion in enabling enterprise mobility, Motorola Solutions is an ideal partner:

• We have the shared focus on the enterprise with a strong commitment to partners.
• Motorola Solutions will provide the scale, resources, industry knowledge to accelerate universal adoption of Rho technology.
• Motorola Solutions is strategically committed to the Rhomobile suite of products
• Motorola Solutions is committed to supporting the Rhomobile community and continuing the open source heritage of Rhodes.

We (Motorola Solutions) also  announced RhoElements Version 1.0.  RhoElements is a container for building connected hybrid apps.  As blogged about recently,  hybrid apps perform most or all the business logic on the web server backend.   And may do a small amount of device capabilities “locally” on the device.  Connected hybrid apps as mobile web apps can be easier  to deploy initially and update on an ongoing basis.  RhoElements is in effect a browser with abilities to do some device capabilities via extended HTML tags (specifically EMML 1.1).  For customers who want to write mobile web apps to perhaps ease their deployment or because they can assume 100% realtime connectivity, it can be an attractive lightweight approach to writing mobile apps.  The ease of deployment of mobile web apps while still providing some device capabilities.

So when do you use Rhodes and when do you use RhoElements 1.0? Today it is determined by your need for a true native app.  Rhodes lets you use web skills to write a native app, installed and running locally on the device, with full device capabilities and local data (synchronized or otherwise).

In RhoElements Version 2.0 we will provide Rhodes with an extended set of enterprise-focused device capabilities (details to be announced later) and the ability to do all device capabilities with both HTML tags (EMML tags and more) and JavaScript calls.   We will also support the ability for a Rhodes app to generate a mobile web app, accessed by mobile web browsers, including device clients written with RhoElements V2 itself.  Rhodes today emphasizes using writing web skills to write native apps.  With RhoElements Version 2.0 we will no longer take sides on the classic “web app versus native app” debate.  RhoElements 2.0 will support both deployment models (“native” or “web”) and provides unique capabilities for each that no other framework attempts to do today.

“With RhoConnect, we no longer need to write sync code to connect to any of our enterprise data and applications. We now have the flexibility and performance to deliver mobile app capabilities to all of our clients with both online and offline operation with dramatically fewer resources — saving as much as 50% of our overall effort.” That’s savings that can go right back into developing and enhancing other business-critical features.

If you are building a business-focused application that uses application data, you owe it to yourself and your team to investigate RhoConnect. Most importantly, tell us about your experiences and where it saves you and your team the most effort.

Right now other mobile frameworks and platforms such as Adobe Flash/Flex/AIR and Appcelerator promote their own proprietary UI libraries that duplicate what HTML and those styling libraries have already standardized (in my opinion not nearly as well).  Well now Adobe has thrown in the towel and purchased PhoneGap.  It is the first of many “proprietary UI” libraries that will soon be sent to the ashcan of history.

In summary,  if you want to write a native smartphone app, use a smartphone framework like Rhodes or PhoneGap. If you want to build an informational smartphone app use one that has MVC, synced data, an ORM, and other modern development best practices.  Whatever you do, avoid frameworks that promote proprietary approaches as you may be left behind with a deadend niche technology as many Flash developers are about to experience.

So What Is A Hybrid App Anyway?

In fact the term hybrid application refers to creating a native app shell or stub on the device,  framing a webview component, where most or all of the application pages and functionality is delivered live as a web page.  The term “hybrid” refers to the user experience in the app.  They have some aspects of native apps: they can use device capabilities and access local data when appropriate.  But much of the app functionality and content is determined by the web page that the app is connected to.

How Do You Write A Hybrid App?

Hybrid apps can be written with any number of technologies and frameworks. You can write them in Objective-C for iPhone.  For example, a tab bar at the bottom and a UIWebView framed on th page.  The UIWebView control is set to point to a page which has appropriate links that determine how the app is navigated and behaves.   You can write the same thing with a framework like Rhodes or PhoneGap as well of course.   Both of these frameworks use HTML pages for their content, generally locally on the device.   They of course have the ability to point to external content on a backend web app as well.

So Which Is Better A “Hybrid App” or a “Native App”?

Frameworks like Rhodes do not really take a position on whether it is better to have code and logic executing on the device or remotely on a backend web server.  But some (not all) of the purpose of doing a hybrid app is removed when using a framework that supports HTML for building native apps,  since part of the value of the web app having the logic is the ease and portability of coding in HTML.  Rhodes (and PhoneGap) both give you the capability of using HTML and still have a true native app with all code running locally, data available locally and full device capabilities available in every part of the app.  Apps with local code and data tend to be significantly faster.  And of course they don’t need a live connection at all times. So, all else being equal, and given a way to harness the power of web programming for building native apps, we at Rho believe that native apps are far more useful in most situations.

So When Is A Hybrid App Better? 

Given that that incentive is removed when does it make sense to have a hybrid app, written with Rhodes or with any other framework or SDK? Hybrid apps push the app logic (or much of the logic) to the backend web application. It is easy to change and update app functionality without pushing out an app update to the device.  The fully native app (written with Rhodes or Objective C or another framework) would need to be updated to get the functionality.   If you have some kind of app management capability like RhoGallery or a mobile device management solutions like Good, Sybase Afaria or Mobile Iron, this is also less of an impediment.  There are some scenarios however where apps have to be changed often and they don’t want to deal with app updated. Hybrid apps can be useful there.

How Does Rhodes Help In Building Hybrid Apps?

Rhodes allows you to write hybrid apps by just linking to an external URL from your Rhodes views.  When using remote pages access to device capabilities is via JavaScript calls or extended HTML tags (e.g. <geolocation>) instead of Ruby calls that would normally be made in a Rhodes controller.  These JavaScript or HTML extensions of course need to be embedded into these remote web pages.  Currently we only support a few operations as HTML extended tags, but over the next few months we will add support  for popular methods of performing HTML and JavaScript calls from web pages.   And of course you can “go local” whenever you want by including content that is linked to local templates on the device.   Thus you can always have the best of both worlds of ease of deployment of “hybrid apps”  and the fast execution and ability to run offline of “local” apps.

Rhodes: The Right Framework for “Hybrid Apps” or “Local Native Apps”

In summary Rhodes is the ideal environment to write hybrid apps from.  You can easily point to “live content” out on remote web applications  from your Rhodes controllers.   But more importantly you can use your web skills and the productivity and portability that they afford to write true native local applications that run on the device.

But we also offered RhoSync, a modern mobile sync server that synchronizes data from backend applications down to the Rhodes apps on devices. We were proud that we made mobile data synchronization much easier, faster and more scalable than any of the other aging MEAP platforms that offer synchronization today.

What we learned from customers and systems integrators using RhoSync was that the biggest value of RhoSync wasn’t that it enabled synchronized offline data, it was that it made it much easier to integrate with enterprise applications. By using RhoSync and writing small “source adapter” classes that run on the RhoSync server (and sync data down to the device automatically) developers were able to remove entirely the data integration part of their smartphone app, something that developers told us was 50 to 80 percent of their application development effort.

As we have discovered this we have decided to call the next version of RhoSync RhoConnect 3.0 to properly highlight the biggest value that our customers tell us that it gives them. But RhoConnect is not just a content-free rebranding. In keeping with its core value in easing mobile app integration, the theme of RhoConnect 3.0 is “low source code integration to NO source code integration”. Zero source code integration with backend applications? How is this even possible?

Well RhoSync always featured the value proposition of “write a page or so of source adapter code and your data is integrated”. How can we possibly make it “zero source code”? RhoConnect 3.0 does this in two ways. First we are shipping source adapters for all major CRM software applications. Specifically the new RhoConnect-Adapters project includes source adapters for SalesForce, SugarCRM, Oracle CRM on Demand and Microsoft Dynamics. We provide adapters for all of the major objects: Contacts, Leads, Accounts, Tasks and Opportunities. Over time we will add adapters for other backend applications, including major field service applications as well (it’s worth mentioning that your existing RhoSync source adapters will work just fine in RhoConnect).

The second major way of performing source code integration is providing “server plugins” for popular web application development environments, such as Microsoft .NET, Java Struts and Spring MVC, and Ruby on Rails. What is a server plugin exactly? Unlike source adapters which are run on the RhoConnect server, server plugins are run in the backend application itself. This means they can only be used when you have access to modify the backend app (and of course if it is written in a supported environment). But when you can do this you have an unprecedently easy method of app integration. There is no need to write a source adapter or really write any code whatsoever. You simply configure the server plugin as a component to your backend app (for example as a gem to your Rails app). You configure your component to talk back to your RhoConnect server instance. And you provide information to your models so that they know how to query the database to supply information back to the users.

The third major new feature area of RhoConnect 3.0 is support for any smartphone app development environment or SDK. That’s right, you can get the benefits of RhoConnect without necessarily using Rhodes. Of course Rhodes is still the only framework with support for Model View Controller, the broadest device operating system support and the most device capabilities (especially industrial capabilities such as barcode, signature capture and Near Field Communications). But our core business at Rho has always been our app integration server (now RhoConnect), so we want any and all smartphone app developers to be able to benefit from it. Specifically we now support Objective-C as a development environment as well as Android Java. We even support using other smartphone frameworks that have followed Rhodes into the space, such as PhoneGap. Specifically we provide a JavaScript library that can be used from JavaScript-oriented frameworks.

We are very excited about the impending production release of RhoConnect. Currently RhoConnect is in public beta. For those interested in RhoConnect’s new capabilities, we have an enticing offer for a more formal beta as well. Specifically if you want to provide direct feedback on RhoConnect’s new capabilities: out of the box source adapters, server plugins, or alternate client libraries (Objective C, Java or JavaScript), you can write to betas@rhomobile.com. In exchange for weekly structured interaction with the team, we will provide one free year of RhoConnect licensing. Whether in the formal or public beta, please give RhoConnect a try for your mobile app integration efforts. We look forward to getting your feedback directly to me or via the Rho group.

The debate about native apps versus browser-based apps is like a technology version of the pundits on cable TV. In this case, though, only one side is shouting – users have already decided that native apps are their overwhelming preference. The InfoWorld article, “Will HTML5 Kill the Mobile App?” has a great title, but the complaints boil down to the following:

The Difficulty of Acceptance into App Stores
At this point, most developers have a good sense of what it takes to get accepted. And much of the controversy comes not from the apps themselves, but conflicts with business models – generally with Apple’s. Writing apps to appropriate standards is a good idea and no app written with Rhodes has ever been rejected

Rising Above The Noise In An App Store
Anyone starting a business, producing an app, writing a blog, or establishing a presence recognizes that this is an uphill battle. But to think that a browser-based app will solve the problem is silly. Not only that, but the writer himself shows that the problem is being worked on with third-party catalogs and other media. It’s very rare for an app to become a hit without associated marketing and promotion across a variety of media.

Writing cross-platform will be easier with HTML5
Rhodes allows developers the productivity and portability of HTML5. But it also allows you to build native apps.

The writer quotes a gentleman from Mozilla with an interesting idea – that the web and native apps can coexist. We agree – each has its place. But there are two distinctions:

A native app already can take full advantage of the power on the device and reduce the amount of network traffic (since the presentation is local, only data is downloaded live). Native apps tend to have a more task-based focus. Web apps can be written to look and act like a native app, but why bother? With Rhodes, you can already use web skills (HTML and CSS) to build a native app that takes advantage of all the device capabilities.

Especially as new capabilities are added to ever-newer devices and individual companies develop new widgets and capabilities, the time to standardize them in HTML5 and successors will lag further and further. We believe in using standards where they exist (hence use of HTML5 for Rhodes views), but standards will never keep pace with the innovation happening in smartphones.

Rhomobile is a big believer in HTML5. The standard and associated toolkit provides a richer set of interface capabilities for mobile apps and make web sites even better. In fact, we recommend using HTML5-based UI styling libraries as a primary way to build the views in native apps written with Rhodes. Our beef is with the idea that HTML5 is going to save developers the trouble of either creating a good app or promoting their app effectively. With the availability of cross-platform mobile app frameworks, including those like Rhomobile that support HTML5-based JavaScript styling libraries such as jQuery Mobile and Sencha, there need not be an “OR” — developers can have their native app “cake” and eat HTML5, too.

Thanks eWeek and thanks to the OnMobile 100 for naming Rhomobile one of the top 100 companies in the industry.

Top 10 startup to watch	OnMobile Top 100 private company

There is a huge gap between what you can do with a mobile web app and what Rhodes lets you do to build a NATIVE smartphone app (but using web skills for your interfaces). With all of the new capabilities coming in smartphones this gap between what you can do with HTML alone and what you can do with a framework like Rhodes that lets you is only widening.