Author Archives: adam

February 24 2011

How RhoSync Makes Smartphone App Integration Easier

In the last post we described the typical steps involved in building smartphone apps that integrate with enterprise application backends. The big tasks in writing mobile apps that do this are: connecting to backend apps, retrieving the data, parsing responses, populating the local database, secure storage, app and data deprovisioning, and data synchronization. In discussions with smartphone app developers writing apps in Objective C or Java, or using frameworks like Rhodes or PhoneGap, we usually hear that these tasks involved the majority of the development effort and code size.

In this post we will describe how the RhoSync App Integration Server and other components provided by Rhomobile help with each of these tasks, drastically reducing the effort involved in mobilizing an enterprise application. RhoSync automates most of this process by allow the developer to just provide a “source adapter” for each model. The RhoSync server then does all of the work to connect to the backend application, retrieve the data, parse the response, and populate a server cache (specifically a very efficient Redis database) with the information. The RhoSync server then monitors all of the smartphone devices that connect to it and efficiently sends them just changes to the information that they need. The RhoSync server can be used whether or not the smartphone app was written with the Rhodes framework. We ship with Objective C libraries with RhoSync. And we are working on a JavaScript -based RhoSync client which will allow you to use RhoSync from any smartphone operating system, including apps written with other frameworks.

Writing a RhoSync Source Adapter
Note that in most cases a “source adapter” must still be written to connect to the backend application. Specifically this means writing “query”, “create”, “update” and “delete” methods to interact with the backend system. The source adapter query method returns data in a standard “hash of hashes” result and the RhoSync server does the rest of the work to get all of the data down to the device’s database. The create, update and delete methods can expect information on the record to be created or updated or deleted to be provided to it by the RhoSync server. For example the query method might connect to the backend application’s REST interface, retrieve the data as a JSON payload and then put which typically exposes a REST or SOAP interface that the source adapter can consume. The code can be as simple as:

  def query
    items.each do |item|

Assuming an app that might just retrieve information those five lines of code replace hundreds of lines of Objective C or Java code of an app that might connect directly. And of course you get the benefit of automatically synchronized offline data in the process. And note that often a RhoSync source adapter already exists for the enterprise backend application that you have in mind. RhoSync ships with source adapters for SalesForce. And there are third party source adapters for other CRM systems such as Oracle (Siebel) and SugarCRM.

Bulk Sync
With the creation of a source adapter then, RhoSync handles the connection and retrieval of data, parsing the response and populating the local database. Note that RhoSync also handles performing large database delivery through its “bulk sync” feature. If bulk sync is turned on the RhoSync server will create a SQLite database on the server and send it down to all devices compressed. This is very helpful for model (business objects) with large amounts of data such as product catalogs or customer account lists.

Rhodes Automatic Encryption
For sensitive data (such as patient information in a medical information system or personal financial information in a banking system) the enterprise will often want to have the data be stored encrypted on the device. If the smartphone app is written with Rhodes and the “secure app” option is turned on then the data will be populated in encrypted form into the database. No code to perform encryption needs to be done in the smartphone app.

Automated Deprovisioning
Another concern when integrating smartphone apps with critical enterprise systems is what happens if a device is lost or stolen or an employee is terminated. The RhoGallery feature on RhoHub allows apps and data to be deprovisioned whenever the IT administrator chooses.

We have described primarily how RhoSync eases the app integration process versus writing code directly from the device to integrate with backends. But of course RhoSync also provides for synchronized offline data. This means users can use their apps completely whether or not they are connected to the Internet from their device at a given time. It also means a higher perceived level of performance for the user. The data is just always present on the device. The user doesn’t have to wait for information to be retrieved from the backend.

Note that writing an app that just retrieves information and stores it on the device is not synchronized offline data. One reason is lack of “push data”: data must be retrieved by explicit request or action by the user. With RhoSync data can be pushed to the device realtime (it is unusual to unheard of for “manually written direct from device to backend application sync” to do push data). Another is that without a server like RhoSync to keep track of the “master list of data” the device cannot just receive only the changes.

True “No Code” Integration for Ruby on Rails Developers
If you are writing your backend application in Ruby on Rails we will soon be providing a Rails plugin that literally removes all of the code necessary to synchronize the data to the smartphone app on the device. In other words a source adapter is no longer necessary. By including the “RhoSync Rails plugin” in your Rails app, your Rails app will push data through RhoSync directly to the device. Data associated with all models (or selected models) of your Rails app is just replicated efficiently down to the device. No source adapter needs to be provided at all.

RhoSync makes it much easier to integrate smartphone apps with enterprise backend applications. It automates much of the repetitive and laborious process involved in integrating with backend data feeds. In some cases RhoSync can remove literally all of the code required to integrate with a backend app. Use of Rhodes to write your app makes encryption of data automatic where appropriate. And using RhoGallery to manage your apps handles the app deprovisioning and management issues with enterprise apps and data. Regardless of whether you use RhoSync and other Rhomobile components or not, you should think carefully through all of the common steps identified in enterprise application integration and make sure your development plan addresses each of them.

January 29 2011

smartphone enterprise application integration

Smartphone app usage is exploding, by both end consumers, and, more recently, by businesses using the most recent more powerful devices to make their workers more productive. One of the most interesting things about this trend is that it is a changed paradigm over most new applications done in the last fifteen years (which have been primarily centralized computing as web apps). By contrast smartphone apps are dominated by native apps running on the device itself, locally and utilizing device capabilities. This is truly “computing at the edge”, utilizing the incredible burgeoning power of the modern smartphone. Because of this many of the best practices that have emerged for enterprise applications need a serious refresh – new rules for optimal smartphone app development. One subarea of those overall best practices is how to most effectively integrate with existing enterprise applications. This is worthy of its own discussion.

In the enterprise scenario there are many common tasks that need to be performed to build an informational app that integrates with an existing enterprise backend app. This integration is proving to be the majority of the effort in building these apps, and in many cases the majority of an enterprise’s entire IT efforts. We will try to describe in more detail then where that effort is, and some best practices in reducing it and overall time to deployment.

When writing apps for modern smartphones to connect to enterprise backend applications, there are several areas of effort that must be solved to build the full app. You need to connect to the backend application, generally through some web service protocol. You need to retrieve the payload data from that backend. The data needs to be parsed into a consumable form. Generally the data needs to be stored locally on the device in some form of database. If the data is stored locally then some form of ongoing database management in the face of changes needs to take place. In some scenarios the data will need to be encrypted on the device. Finally there will generally need to be some way of making sure that the data and apps can be remotely wiped if the device is lost or stolen or the employee is terminated.

In the cases where synchronized offline data is required (most of the time for an enterprise app) many of these steps can be eliminated and the overall effort wil be simplified. But it also raises some additional steps to be performed: hosting the sync server, tying it in with the overall enterprise authentication directory, and writing some form of sync “source adapter” to interact with the backend application.

In talking with smartphone app developers we have found that all of these steps constitute more than half of every enterprise smartphone app’s code and overall effort. In the rest of this document we will break discuss each of these steps individually.

You will almost always want to connect via http or securely via https. You will need to think about how to handle authentication in a secure way. Generally you will want to use basic authentication challenges from smartphone devices versus some more elaborate protocol such as NTLM. On devices such as BlackBerry you may need to explicitly control which network (Wifi or carrier for example) is used as the transport.

You should try to execute some form of asynchronous connection to keep the smartphone user interface responsive. Many desktop apps and web apps can get away with synchronous connections where you wait for the response. On a mobile device you will want to keep the user interface responsive while you wait for the connection and information retrieval. So some method of connecting asynchronously with a callback on the return should be performed.

Data Retrieval
The first step in integrating to the enterprise backend application is to decide how to expose that backend. The common ways of doing this now are REST and SOAP web services. You may have inherited older methods such as DCOM, Corba or XML-RPC gateways.

Then the question is what is the payload format. Common approaches include XML or JSON payloads. JSON is much smaller and easier to process.

If you are communicating directly from a device we recommend a JSON payload exposed via a REST interface. When absolutely necessary you can connect directly to a SOAP service. But you would want to avoid this when using older BlackBerry devices. And you should be sure that the payload is not too large if you are doing this from SOAP.

When using a sync server, it may be OK to use some legacy method as the sync server can act as a proxying mechanism to make data easily retrievable by the device.

Parsing Responses
Once you retrieve the data you will then need to extract the data that your app needs from the payload. The options for doing this are most often either JSON parsing or XML parsing. If you are handling a large XML payload you will want to consider using either a stream or pull parser versus using the XML Document Object Model (DOM) to retrieve the data.

If you have a large amount of data (greater than 10MB) you will want to consider using some more efficient method than a text stream to get the data to the device. You could create some archived compressed format and deliver that in bulk to the client device (a technique sometimes referred to as “bulk sync”).

Populating the Database
Once you have the data, generally you will want to provide some way of populating a database or local cache. The user should not have to wait each time they start their app for their data to be retrieved from the server. You will want to populate some form of local database or cache. Generally this means taking the parsed data and creating records in database. Also in order to have users be comfortable creating or changing data for an enterprise application, you will need to give them a way to store their changes locally before it is applied. This requires managing the local database. It also generally requires some approach to data synchronization, which we will discuss shortly.

Secure Storage
In some cases if there is local data you will want encrypt that data before storage. This could be because of regulatory standards such as HIPAA. It could be sensitive information such as personal financial information or confidential trade secrets on a smartphone device with a chance of being stolen or lost. However, be careful when applying this technique. Encryption tends to be slow especially on older BlackBerry or Windows Mobile devices. Use it where necessary and nowhere else.

App and Data Deprovisioning
In the cases where sensitive data is on the device (whether or not the data is encrypted) you will want to have a way to deprovision apps and data if the device is lost, or an employee is terminated. There are many mobile app and device management solutions from vendors such as Sybase, Good Technology, Mobile Iron and Rhomobile. You should strongly consider having one of these solutions in place as part of your general app planning.

Data Synchronization
As mentioned, in enterprise application usage scenarios to get your app used you will need to provide some way for users to store their changes locally whether or not they are connected. One reason is the obvious one: so that users have their data and can do their work (such as creating and editing information) when they are offline. But the more critical reason is so that users know that their changes are made reliably, one and only one time. Users do email with rich client apps on their mobile devices – apps that store data locally and sync the email in background (versus using a mobile web browser). They have the same expectations for their enterprise apps. Finally having the data available locally creates a faster user experience – the data is always available for them immediately on startup.

A side benefit of using data synchronization is that it simplifies the app integration scenario just described above. Instead of doing all the work to connect, retrieve, parse and store the data, a good synchronization server and client app framework will perform all of that work. The only task for the app developer is to write the code for the sync server to connect to the backend application. That work is typically called a “source adapter”. The app developer needs to write code to enable the server to retrieve or query information. If they want bidirectional data they will need to write code to create, update and delete information as well. This is typically much less code than performing all of the connection, retrieval, extraction and storage from the device. And usually the sync server has a richer set of libraries and tools available to make those backend connections. The server can usually handle whatever format the backend application exposes, versus requiring a new web service to be exposed.

There are several things that you should look for in a sync server and sync client framework if you want to have an optimal solution. First of all your server should support “push sync”. This means that changes made to the backend application get immediately sent to the devices that need them. This avoids the device having to “poll” occasionally for changes. Polling results in mobile device battery drain and some level of staleness of data for the user. Note that your backend application must have some kind of notification mechanism exposed. Also there must be some way of performing a push to the device to make this work. It is unusual “homegrown” approaches to sync to do push.

If you are considering building an enterprise app for modern smartphones, we would encourage you to look at each of these steps to performing integration with your backend enterprise application. In the next post we will describe how RhoSync makes each of these steps easier. But thinking carefully through each of these issues is likely to accelerate your development efforts and result in a better solution, whether or not you use Rhomobile products.

December 09 2010

Ruby for the Enterprise is Taking Off

When we first put out Rhodes two years ago it was the first “smartphone app framework”. Rhodes provides a Model View Controller architecture for your smartphone apps (the only smartphone framework with MVC). You write your Views in HTML and your business logic (Controllers) in Ruby. To do this of course we had to implement Ruby for the first time on each smartphone device operating system. Now suddenly Ruby developers could write true native smartphone apps that take advantage of device capabilites such as GPS, PIM contacts and calendar and camera. Ruby developers finally could do mobile in their favorite language.

But Ruby for enterprise? Although you can write any smartphone app with Rhodes, we have always been focused on enterprise apps. “Why would you use Ruby for enterprise apps?” many early customers asked. Our answer: we wanted something high level, terse and powerful. Ruby based controllers are a fraction of the size of their Java, C++ or JavaScript equivalents. And Ruby is quite easy for new developers to pick up. Though unconventional, this decision turned out to be a blessing: Rhodes became popular with Java and .NET shops alike. And developers all seemed to enjoy the chance to use a simple to learn, powerful language with a rapidly growing community, despite the fact that few early Rhodes developers came to it with existing Ruby knowledge.

That said, Ruby was never the selling point of Rhodes. The core value was the MVC framework, the broad device support, integrated sync, and a rich device capabilities library. Though the Ruby community loved Rhodes (inducing apps for Ruby conferences, the Wikipedia app from Ruby luminary Hampton Catlin, and the TrackR PivotalTracker app for agile developers to name just a few created by existing passionate Rubyists), Ruby was just something that helped developers be quickly productive, and a great Switzerland amongst the competing enterprise development languages and stacks. It wasn’t really a selling point in the enterprise, nor was it a negative.

Well that has all changed since then. Yesterday SalesForce announced their acquisition of our partner Heroku, a Ruby web app hosting company, for $215 million. As quoted in the release:

“The next era of cloud computing is social, mobile and real-time. I call it Cloud 2,” said Marc Benioff, chairman and CEO, “Ruby is the language of Cloud 2…”

SalesForce already had Java hosting capabilities. So the clear value here was a belief in the future of Ruby for enterprise apps. This is not a conventional no-brainer decision. Marc Benioff showed true vision in betting on the growth of Ruby, beyond just consumer and social networking web apps.

We were personally excited to see this. Heroku is the backend hosting company for our RhoHub hosted service. All RhoSync servers deployed on RhoHub get their own Heroku server stack. We are clear to acknowledge that what Heroku did for hosting Ruby on Rails web applications, RhoHub does for native smartphone apps (building them and providing hosted sync). It’s great to see the value of innovative Ruby based companies recognized.

We also believe enormously in Ruby itself and always have, doing whatever we can to support the amazing Ruby community. The inventor of Ruby, Yukihiro Matsumoto aka “Matz”, chairs our advisory board (the only board Matz serves on). We are working with Matz on getting the core Ruby implementation decomposed from Rhodes and made available independently to the community at large (with contributions accepted as well). And we will define a standard subset of Ruby that is appropriate for mobile, building upon the de facto standard set by Rhodes. The Rhomobile team and our community present at almost every Ruby conference. And we contribute fixes back to important Ruby projects such as Ruby rest_client and others. We knew the day would come when using Ruby would become a reason to choose Rhodes. With decisions like SalesForce’s, the day when Ruby will become the preferred language for new enterprise apps is fast approaching. Rhodes allows that decision to be made for native smartphone apps as well – today.

Whether you are planning an enterprise web app or an enterprise-focused smartphone app, you should consider leveraging the ease of use of Ruby, its burgeoning developer community and its rapidly evolving toolset, in choosing your development language.

December 03 2010

security in enterprise smartphone apps

Smartphone usage has exploded over the last couple of years. And its usage has been with a different architecture than the past fifteen years of information technology has used. Specifically smartphone app usage is dominated by NATIVE apps not web apps. This pushes computing back to the edge as opposed to centralized processing done by web apps. With this new paradigm there are a new set of security issues and best practices that are not simply a rehash of web app best practices.

Smartphone apps for the enterprise also require true synchronized data to get true usage in the enterprise. Synchronized data, while the only way to get true app usage, does introduce security issues that need to be handled. This document describe the five big areas of native smartphone app security issues: transmission security, storage security, app management, enterprise authentication and backend app authorization. Along the way we describe how Rhomobile products handle each of these issues. But these areas apply to any enterprise smartphone app. We hope you will benefit from the outline whether or not you use Rhodes or RhoSync.

Transmission Security

If you are sending sensitive information over the public Internet (generally the case with most smartphone apps) then you will need to secure it in some way. This should be with SSL, and sending over an https comnection.

With Rhodes, just as with an Objective C or Android Java app, you will transmit the data over SSL (https). Both Rhodes alone and Rhodes plus RhoSync support use of https as a transport. In fact it is easier with Rhodes than with Objective C. This is because with the Rhodes AsyncHttp.get call, you just list an https URL and Rhodes will connect to the backend appropriately. This is in contrast to underlying SDKs where significantly different code is written to connect to an https URL.

Storage Security

With native smartphone apps (unlike web apps or mobile web apps), generally you want to have data available on your device. And of course if you are using synchronized data that will always be the case. If you are concerned about the availability of data on your device in the clear then you can encrypt that data. As a best practice we recommend encrypting only the attributes that are truly sensitive information.

In Rhodes you can encrypt data with your Rhodes app using the Ruby crypt library calls. Block cyphers currently available include Blowfish, GOST, IDEA, and Rijndael (AES). Cypher Block Chaining (CBC) has been implemented. Twofish, Serpent, and CAST256 are planned for release soon.

You can also use SQLCipher for transparent encryption. Finally to ease some of the burden of integrating SQLCipher into your app we will be adding transparent encryption as a model option in Rhodes 2.3 (to ship by end of 2010).

App Management

Native smartphone apps presented new issues of managing access to apps and updates to those apps. We recommend that enterprises consider some product to manage their apps and the data for those apps. It is important that that software:

  • update users with new apps that they should have
  • provide updates to those apps
  • remove apps that those users should no longer have and the associated data
  • remove the app management portal when appropriate
  • Note that in these “Bring Your Own Device” days we do not recommend full mobile device management. MDM creates additional maintenance burden for IT administrators and is not likely to be accepted by users on their own devices.

    Rhomobile’s solution for this problem is called RhoGallery. RhoGallery is the first hosted app management solution, providing ease of deployment and use not seen before. Whether or not you use RhoGallery we recommend choosing some mobile app management solution but steering clear of full device management due to the complexity, cost and conflict with the BYOD future.

    Enterprise Authentication

    There needs to be delegated authentication to some form of enterprise directory for optimal sync server security. Ideally this should be the company’s well-maintained LDAP directory. It is important that any sync solution support “delegated authentication” to tie into a company’s overall directory system for authentication.

    RhoSync makes it very easy to perform delegated authentication by simply providing an “authenticate” method that can call to any directory authority. A typical authenticate method is less than five lines of code.

    Backend App Authorization

    All sync source adapter should always login with the appropriate userid to the backend. This insures that they are only getting the information that they have rights to. It is important not to use some form of global “app ID” to perform this data synchronization, otherwise overall information authorization schemes would be compromised.

    There is also the issue of how does RhoSync authenticate with your backend app. This is done via the “login” method in each source adapter itself.

December 01 2010

CSS/JavaScript web toolkits

There are now at least five major CSS/JavaScript web toolkits on the market, focused on building mobile web apps that look native on iPhone and Android. These include jQTouch, Sencha, JQuery Mobile, IUI, SproutCore/Strobe. Occasionally we have been getting questions about whether these toolkits are competitive with Rhodes. Actually they are only complementary to Rhodes. In fact, Rhodes encourages using such tools. We ship with an enhanced version of JQTouch to style the HTML and HTML5 that Rhodes utilizes for writing apps. And we have plenty of Rhodes developers using Sencha and IUI in their Rhodes apps as well.

Rhodes focuses on its differentiators as a full framework:
- the only Model View Controller framework for smartphones
- the only support for all devices
- the only Object Relational Manager
- the only app generator
- a robust device capabilities library
- the industry’s only smartphone-focused sync

The mobile web toolkits don’t do any of these things, or try to. But, since Rhodes uses HTML, CSS and JavaScript in its views, their presence is very helpful to developers building apps with Rhodes. And it lets us at Rho concentrate on the true IP of Rhodes and RhoSync, allowing the “mobile web toolkits” provide UI enhancements for us and our developers. That IP (see that list) is large and growing. And they are not things that are going to appear in web standards.

Of course the companies that should be really worried are those that have tried to create their own UI libraries as alternatives to HTML’s abstractions, generally in Javascript. These include Appcelerator and Ansca Corona. They are competing headon with the ways that JQTouch, Sencha, JQuery Mobile and Strobe are making HTML/CSS/JavaScript user interfaces better and more native. We are very happy that the Rhodes approach of HTML/CSS/JavaScript for views is able to leverage their tens of millions of development dollars versus duplicating on a proprietary (albeit JavaScript) basis.

So thanks to Strobe/Sproutcore, Sencha, JQTouch, JQueryMobile and IUI for creating great tools. We aren’t seeing many developers wanting to build mobile web apps nowadayy. But your libraries help Rhodes developers in writing what users do want: native apps with great HTML-based user interfaces.

November 17 2010

“bring your own device” and the importance of app management

I had the pleasure yesterday of participating on a panel at the SIIA “All About Mobile Conference”. The leading device and app management vendors were there. This included Sybase (which has long sold the Afaria device management solution), Apperian (which provides app management for iPhones and iPhone apps) and us (we provide RhoGallery, the first hosted app management product). As everyone recognized, the long predicted “Bring Your Own Device” movement is real now. Enterprises are providing per diems and reimbursement for employees running their own smartphones. Part of the savings for the enterprise is that they don’t have to purchase devices for employees. But an even bigger part of the ROI of this decision is removing responsibility for MANAGING devices.

So what does this mean for enterprise IT staff (administrators and developers) wanting to provide order to the chaos of getting the right apps out to the right people in their organization? Using a full-fledged mobile device management solution is now both overkill and probably not going to work anyway. Part of the appeal to employees of BYOD is that they control their device. And to IT it is the avoidance of owning the ongoing maintenace of those devices. But there still needs to be some way of making it easy to get apps out to users. And control the availability of enterprise apps and data when devices are lost or employees are terminated.

The solution is APP MANAGEMENT not device management. This new lighter weight simpler approach also coincides with big shifts in how apps are made available. The app management solution should handle apps being made available with Apple’s enterprise distribution server (which is now available to enterprises of all sizes not just large companies). It also should be available in a hosted Software as a Service model.

The first product that meets these criteria (even just hosted app management) is Rhomobile’s RhoGallery service. RhoGallery lets administrators define “galleries” of apps (whether or not those apps are written with Rhodes or RhoHub). They can be app executables that are uploaded or just links to URLs of external apps (including those on an enterprise’s Apple iOs enterprise distribution server).

They invite groups of users to those galleries via email or SMS. The user then has all of the apps that they need to do their job from a single “launchpad” app. As new apps are added to the Galllery the user sees them appear on their device. If it is desired to remove a user from access to an app or data, those changes are pushed out as well.

We think RhoGallery represents the first of a new breed of lightweight mobile app management that will get far more adoption than earlier device management software ever did, both due to cost and difficulty of deployment and the new realities of enterprise device usage that make full device management less relevant.

November 09 2010

RhoGallery – the Enterprise App Store

The best product ideas always come from customers. As an open source company, we’ve always had the advantage of a community of tens of thousands of Rhodes developers to help provide feedback on product direction as well as contributions to the product. This community helped to spur creation of RhoHub, the first Development as a Service for mobile.

Our RhoHub community also has been asking for some solution to how to install and manage the plethora of apps that RhoHub enables. We initially tried to refer this opportunity to existing players in this space (“mobile app management” has been around for a while). But the feedback that we got was that those existing mobile app management products were far too expensive, difficult to deploy and difficult to use. “Give us the lightweight model and inexpensive monthly billing that you have for RhoHub” we heard you say.

So we’ve spent the last several months hard at work on building a new product in this space: the first hosted SaaS mobile app management solution. Yesterday we unveiled RhoGallery as a new service available on RhoHub in Beta form. RhoGallery lets administrators manage the set of apps exposed to their users (whether those apps were written with Rhodes or not). And makes it easy for them to get mobile apps onto their devices. It gives users a single place to launch all of their important enterprise apps from. RhoGallery consists of a management console for “galleries” on RhoHub. And a RhoGallery app that users load onto their devices. That app is then used by those user to install (the first time) and subsequently launch their important apps. Even for an individual developer with one or a few apps, RhoGallery makes it easy to expose those apps to their users. RhoGallery handles inviting the users and determining the appropriate downloads to provide them.

RhoGallery provides:

* administrator management of exposed apps to end users
* central user launching of the apps that they need from one place
* automatic provisioning of appropriate apps for end users

To get started, create a Gallery and upload or link to one or more apps. For each app upload one or more builds for various smartphones. These can be from:
* local files that you have available (.apk files for Android, .cod files for BlackBerry, .cab files for Windows Mobile)
* from RhoHub builds that you have made
* from some external remote URL (note that they do not have to have been built with Rhodes or even built by your own enterprise).

Now invite some Consumers (a term to refer to “end users” or “enterprise workers”) to that Gallery. Those “consumers” or users will then receive SMSes or emails with a link to install the RhoGallery app. After installing they can then download the apps to their device. RhoGallery is included with each RhoHub subscription level (e.g. $99 per month for 100 devices, and $499 for 1000 devices).

Please give RhoGallery a try and give us your feedback. We will have a few months of Beta as we incorporate your suggestions and then launch the product formally towards the end of the year.

October 21 2010

best practices in informational smartphone apps

This is a summary of the paper that I am going to be delivering on Monday at MobiCASE organized by my dean at Carnegie Mellon Martin Griss. I’ll be showing a lot of examples there of good and bad native smartphone apps (putting all those pics in a blog post is probably not as effective). It is not an ad for Rhodes and RhoSync, although using them makes it MUCH easier to do most of these things. Interested in hearing your opinions on these issues, especially ahead of my talk on Monday.

Effective Informational Smartphone Apps

Usage of modern smartphones, as exemplified by recent powerful devices such as Apple’s iPhone and many different Android devices, has exploded recently. The usage on these devices is dominated by local native apps (versus mobile web pages). Over 6.5 billion apps have been downloaded from the iPhone App Store. There are over 200,000 apps on the iPhone App Store and more than 100,000 apps on the Android Market.

The success of local native apps over web apps raises some new questions in how to build optimal mobile apps. Most of the information technology industry has focused on how to best build web apps (mobile and otherwise) over the past 15 years. In effect these are truly centralized in their logic and information architecture. Local rich client native apps are a new development in the industry (or a resurgence of the truly distributed computing model). In either case it is worth examining how best to approach what, for most developers, is a new development problem.

Note that that we won’t be doing here however is making the case for native local mobile apps versus web apps. This paper assumes that the reader is already interested in building that native local mobile app.

For building native smartphone apps there are several guidelines emerging followed by the best smartphone apps. Most of these are quite distinct from best practices in either web apps, mobile or otherwise. It’s also worth noting that the guidelines here are really for informational smartphone apps (for enterprise or consumers) not for games, for which an entirely different set of best practices applies.

Context Sensitivity

Because of the latency necessary to navigate in mobile, it is best to take users directly to the most likely task that they may want to perform in the app. Given that an app can perform many tasks or manage multiple business objects, this “guess” of the appropriate task may or may not be correct. But getting it right most of the time will create a more usable app.

For example, a smartphone app for Customer Relationship Management could take the sales rep user right to the account that they wish to edit based on their location determined via GPS. An app can also take the user right back to the last screen that they used when the app was last used.

Avoid Typing

Modern smartphones are dominated by “soft” keyboards. And when they aren’t soft the keyboards are limited and small. The most usable apps use many clever techniques to minimize typing. There are many techniques available to do so:
- use far more select wheels and radio buttons than most web apps do, even at the cost of flexibility or more app data maintenance
- use the device’s knowledge of location for filling in geographic information
- use predictive text techniques such as Swype

Leverage Device Capabilities

Smartphones are more than small laptops. All modern smartphones ship with a wide array of “sense”: sight (the camera), “hearing” (microphone and voice phone connections), “touch” (as in touchscreen) and a sense of location in space (GPS). The best smartphone apps take advantage of these capabilities.

They make use of multitouch to zoom in and out, GPS to determine their location, use the camera to record images and videos, and integrate with other capabilities of the phone such as the phone dialer and the Contacts database.

Support All Devices

To reach the maximum potential user community, app developers need to be able to target all popular smartphones. There are a variety of techniques to building single apps that work on all smartphones. These include cross-platform frameworks which are burgeoning in popularity. Or developers can use the underlying SDKs for development (e.g. Objective C on iPhone) but use the browser component (e.g. the UIWebView control in the iPhone SDK) for rendering user interfaces.

Synchronized Local Data

If the app is an informational app, the best apps allow that information to be accessible whether or not the user is online. There should be some way of insuring that the necessary information is pulled down from any backend application servers, kept current based on changes and resynchronized back up to the central server when appropriate. Historically apps that only support “live data access” get far less usage, especially when the app supports creating, updating and deleting data.

Synchronization solutions can either rely on the device polling or some form of push solution. Polling-based sync drains device battery life and results in stale data. Push-based synchronization is better, and can now be done as modern smartphones now support push natively in the operating system (iPhone, Android and BlackBerry now all have native push capability).

Offline Usage

Beyond data synchronization (which allows offline usage of critical information) there is the general problem of making sure that apps can be used efficiently and completely when offline. Data synchronization solves part of the problem. In general however, the app should pay attention to make sure that the most important operations can all be performed whether or not the user is online. Not all apps insure this, but the best ones emphasize this ability.

Handle Varying Metadata

Perhaps the subtlest problem with the reemergence of truly distributed local applications running on modern smartphones is handling changes to the backend applications schema. With a web application when the data schema changes the application’s full stack is changed: the database, the business logic (usually in the form of a web applications controller) and the interface (the web app’s view).

With smartphone apps running locally on a remote device, its difficult for the central application developer (generally of a web app) to insure that all remote smartphone apps are updated. Thus there is usually a need for smartphone apps to handle changes in the underlying schema of the app or database that they connect to in a more sophisticated way.

This problem has been a big hindrance to the widespread availability of smartphone apps for enterprise applications on the smartphone “app stores”. The few developers that have been successful have handled this with some for of custom way to communicate metadata changes to the remote smartphone app. This is an area of emerging research and discovery among smartphone app developers.


In general smartphone app usage is rapidly expanding. There are a new set of emerging guidelines for how to build the best possible smartphone apps that app developers should carefully consider before building their app.

At Rhomobile we are committed to providing a framework that takes the best of modern web development techniques to attack the difficult problem of building great native smartphone apps for enterprises. What techniques have we left out here? What are other approaches to tackling these issues?

October 15 2010

Rhodes 2.2 released! Bluetooth, calendar integration and Android cloud push

We are very excited to announce the release of Rhodes 2.2. Rhodes 2.2 now offers Bluetooth integration. You can communicate between smartphone devices with Bluetooth support, to desktops with Bluetooth and to external accessories. See the documentation on it in the Rhodes Developer Reference here.

Rhodes also offers calendar integration now. You can create calendar appointments on the fly from your device and store it in your local calendar and look up calendar events as well. There is documentation and code samples here.

Rhodes continues to be the only framework with support for sync (the ability to provide your app users with access to their data even when offline and disconnected) with its builtin (but optional) connectivity to our RhoSync server. RhoSync is the most scalable sync server on the market (because of its use of NoSQL). It is also the only sync server that uses native smartphone push APIs to perform push-based sync (resulting in near realtime data updates and low battery drain on the device).

With the introduction of support for Android cloud push our sync servers “only native push sync” advantage now extends to Android devices as well. This is especially exciting given that Android is the clear volume shipping leader amongst smartphones now. All other sync servers from first generation enterprise mobility players deploy their own parallel messaging/push infrastructure to achieve the benefits of pushed data sync, an unnecessary complexity since iPhone, BlackBerry, and now Android all have their own native push capabilities.

Its an exciting day to be a Rhodes app developer, particularly if you are building a synchronized data app and targeting Android.

October 10 2010

modern development goodness for native apps

The explosion of smartphone app development and usage is a great thing for programmers and users alike. People are productive and entertained in so many more places and situations than they ever were.

But as exciting as new smartphones and their apps are, developing for them is like going back three decades in computer science. I remember complaining about the awkwardness of Objective C in the early 80s (almost thirty years ago). It isn’t just iPhone developers who have to suffer with antiquated approaches to software development. Android developers work with Google’s own strange J2ME superset/J2SE subset, created just for Android. As powerful as Android devices are now, the need to not just standardize on J2SE is very dubious (J2SE is certainly not too big for today’s Android). BlackBerry also introduces their own strange superset of J2ME for phones. And it is notoriously difficult to install and develop for. Both environments feature painfully slow emulators that are so cumbersome that most developers just dispense with the emulator entirely and use a device. Windows Mobile is such a travesty to develop for (with a cumbersome multistep provisioning process to their emulator) and such resultant low developer adoption, that Microsoft was forced to start back at square one and create a whole new operating system for smartphones.

Rhodes provides benefits of the last thirty years of progress in computer science to today’s mobile developers. Specifically Rhodes has the following aspects core to its architecture. Our apologies for the long post. In the past we have highlighted these core differences as “MVC, sync, all devices, hosted service”. But we have had many requests to be a bit more comprehensive in our description.

Model View Controller

All major web development languages (Java, PHP, ASP, Python and Ruby) now feature MVC frameworks that are preferred for development. Though there isn’t, and will never be, one language for web development, there isn’t much debate on the value of MVC. But for mobile there is just one way to use the power and maintainability of MVC: Rhodes.

Rhodes allows you to write apps which separate business logic in a Controller from interface design and appearance in a View. Other smartphone app frameworks force you to put everything, interface and business logic, together in the View. Specifically as JavaScript in your HTML pages. If you really want to you can do this in Rhodes: write your whole app as HTML and JavaScript.

But you’d be missing out on the maintainability and separation of concerns that MVC offers. With Rhodes you can write your app logic in Ruby in the controller. And then write interfaces for each controller action in HTML.

App Generator

Rhodes even offers an application generator that creates an initial app based on the structure of your models or business objects in your app. It’s very similar to the scaffolding offered by most modern web frameworks: a controlled with basic “list/create/read/update/delete objects” functionality. For each basic CRUD action views in HTML are also offered. App developers spend most of their time just modifying views as they see fit. No other framework provides an app generator, nor does any SDK. But modern web developers have gotten to expect it and find Rhodes offering it very comforting, familiar and massively productive.

Object Relational Manager

Regardless of your language or development tool used for web development it is doubtful that you are doing most of your development handcrafting SQL statements. You are using Hibernate with Java or ActiveRecord with Rails or Python Django’s built-in ORM or ADO or LINQ with ASP.NET. Code is generally “.find” instead of “SELECT * FROM WHERE…” or “.create instead of INSERT”.

But whether you are writing in Objective C for iPhone or Java for Android or BlackBerry, though, you probably you to hack out your own INSERT and SELECT statements yourself if you want to work with local data. Rhodes provides the only Object Relational Manager available on any mobile device whether from another framework or another local SDK.


Enterprise apps pretty much require local synchronized data to get used. And informational consumer apps benefit as well from local data that is kept current with data from the backend. Older sync servers don’t support modern smartphones such as iPhone and Android. Most iPhone developers that need sync just end up writing their own synchronization. Doing synchronization well though requires supporting “push sync”: data is pushed to the phone when updates happen on the backend (the alternative is polling which results in “always somewhat stale data” and battery drain on the device. Building a one-way polling based sync server is sometimes possible by talented app developers. I have yet to see bidirectional sync OR push-based sync successfully implemented by a mobile app developer.

Enter Rhodes. Though Rhodes supports connecting directly and live to backend applications, Rhodes was built from the ground up to support synchronized data well, with its built-in support for the RhoSync mobile sync server. In additional RhoSync has several compelling advantages over every other sync server yet built. Specifically it is the only sync server that has a built in “no SQL” key value store, making it more scalable than other sync servers which all feature internal relational database servers for caching. RhoSync also performs its push-based sync using the native smartphone push SDKs, which no other sync server does.

Metadata Framework

Every enterprise application used to run a company’s core business has a different schema for its business objects. For every example every application (whether it is Oracle CRM On Demand, SalesForce, or SugarCRM) has varying and customized structure for their core abstractions of accounts, customers, tasks, leads, opportunities or field service issues. The dilemma for software developers trying to provide generically usable true native smartphone apps (not just mobile websites) is that the structure of those objects needs to be present locally on the device.

So how do you ship a generic usable smartphone app that works with any installation of a population enterprise application (CRM or otherwise) on an App Store? In fact, this is a huge problem. Most App Store “enterprise apps” for CRM, ERP or other categories are in fact just “teaser apps”. They are a chance for the consulting services driven company that wrote them to do some paid customer engagements, but aren’t really used by end customers “out of the box” from an App Store. But independent software vendor that want to ship immediately useful mobile app software for backend enterprise applications (and not make money by selling customization services) need some solution to this “varying enterprise app metadata” problem. The metadata framework offered by Rhodes and RhoSync provides this.

Support for All Devices

Rhodes was the first smartphone app framework (we even coined the term) when it was released two years ago. Because of that and its widespread adoption Rhodes now supports far more device operating systems than any other framework: iPhone, Android, Windows Mobile, BlackBerry and Symbian. We only kept Symbian support up to Rhodes 1.1 due to the seeming falloff of Symbian app development. But we are working on support for new Nokia devices with Meego. And of course we will be released Windows Phone 7 support (a separate implementation than Windows Mobile) soon as well.

There are other frameworks that support just iPhone and Android and claim to be “cross-platform”. Some of these frameworks introduce their own user interface abstractions in JavaScript versus using HTML for their user interface as Rhodes does (of course we style that HTML to look native so our user interfaces are just as, if not more, attractive). Frameworks that introduce their own user interface abstractions will find it very difficult to support other operating systems as the porting process is much more difficult than it is for Rhodes. Smartphone diversity is just increasing more and more so such frameworks will just fall farther and farther behind.

Hosted Development and Build

In addition to inventing the smartphone framework category, Rhomobile also created the first Development as a Service for mobile: RhoHub. Local Rhodes development is still possible of course. But, as with all frameworks, Rhodes wants to build a true native project and app. Hence you need to install the SDKs for the different smartphone operating systems in order to build apps for them. While Rhodes is very easy to install (“gem install rhodes”) smartphone SDK installation can be quite painful. Hence we created RhoHub. RhoHub can perform the builds for every major smartphone operating system on your behalf without you installing any SDKs locally.

The combination of all of these capabilities make Rhodes far more productive than writing with any other framework or underlying SDK. Especially for modern web developers. And it gives them an environment that truly leverages all of their background in good and modern development habits rather than forcing them to give up on those modern skills and productivity.