use your web dev skills to build NATIVE smartphone apps

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

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

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

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

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

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

0 Comments | Posted by admin

app stores for all major smartphones now live!

Yesterday Microsoft announced that the Windows Marketplace for Mobile is accepting applications. This is a great opportunity for mobile developers. Combined with BlackBerry AppWorld, Android Market and Nokia Ovi Store there are now marketplaces available to facilitate distribution to users of every major smartphone. This is a great opportunity for developers. There is now a place to highlight the availability of their app, that doesn’t rely on consumers finding out about you and your app directly. Just create a great app in a category of a consumer needs and they’ll find it.

It does beg the question however: is there sufficient consumer demand on any of these one platforms (with the possible exception of iPhone) to justify writing an app for just that one platform. This is where we are seeing the most demand for the Rhodes framework: the need to create a great app that spans all smartphones that user’s may choose to carry. With Rhodes you can do this: write your app once and Rhodes allows you to instantly build native apps for each of those device operating systems and their associated “app store”. While there are a couple of other approaches to doing both iPhone and Android apps, we are not aware of any way besides Rhodes to write a single set of code and build native apps for all major smartphones: iPhone, Android, Windows Mobile, BlackBerry and Symbian.

0 Comments | Posted by admin

simplified licensing

Today we announced simpler commercial license terms for our Rhodes and RhoSync products. Why did we change it? The previous license was fairly standard for embedded technology licensing: 5 percent of whatever you sell. Just a few years ago, the presence of an open source Gnu Public License alongside a commercial percentage-based license would have worked. You want to make a free app? Open source it under GPL and you owe nothing. Want to charge? Just give us a percentage.

In 2009 however this won’t work anymore. There are too many companies distributing “free apps” but who don’t want to open source them. And they intend to make money but in rather complicated ways that are difficult for anyone to really quantify. For other customers, they said “I don’t know exactly what I’m going to charge, but I need to know what I’m going to pay you regardless”. We needed a simple way to buy a commercial license for all of these customers.

So our new terms are:

- The Rhodes framework alone is $500 per application for an unlimited number of users

- The RhoSync Server (not required to be used by Rhodes applications but very commonly used) is $5000 for 100 users. It scales logarithmically with increasing users: 1000 users is $10,000. 10,000 users is $20,000.

Either license entitles customers to a year of free updates. You can use the last free update of Rhodes and RhoSync indefinitely for no further purchase. If you want to stay current, maintenance is 40% of the original price ($200 per year to stay current on Rhodes, $2000 per year to stay current on RhoSync).

Positive response to the new license is almost unanimous. We have had a handful of enterprise ISVs who were used to 5% embedded licensing who seemed to prefer that offer as it fits into the spirit of our partnership. Our whole goal is to make you, the mobile developer, as successful as possible, and share in a very small way in that success. It turned out on running the numbers that the actual pricepoints for those vendors ended up being very close to the new pricing (they were all RhoSync Server users).

For developers who want to use Rhodes only, the new license terms of $500 for a single app with unlimited users is of course a huge bargain compared to the old terms. We believe that when developers understand how much synchronized data can improve their user’s experience (and hence their sales) almost all developers of enterprise or informational applications will use RhoSync. “Rolling your own” mobile sync framework is just not a practical option (especially as you start to appreciate how we’ve taken advantage of things like iPhone and BlackBerry push to create super-optimized sync).

Anyway, for those of you that want a very inexpensive crossplatform smartphone app development framework, we’ve got a great deal for you: $500 to improve your productivity for even one device by a factor of five (multiply that by the number of device operating systems you want to support). We know that eventually you’ll want to use RhoSync as well.

0 Comments | Posted by admin

App Store rules

The iPhone and the Apple App Store have been THE critical agents in changing the mobile consumer’s attitude with regard to mobile applications. Specifically they have converted virtually all smartphone users (beyond just the iPhone) to wanting and expecting to use native apps on their mobile devices. This is a huge sea change in behavior, especially for U.S. consumers. As enabling technology for building smartphone apps, we (Rhomobile) are hugely grateful for the investment that Apple made here and resulting success of this new category of software. I also personally appreciated how it has eased my life and the world in general (subjects of future blog posts unto themselves)

Part of the value proposition in the App Store’s success was that Apple would test the apps and insure that they did what they said they would and nothing more. This is critical. We take for granted native mobile app usage today. But as recently as two years ago, people did not want to download mobile apps to their devices. The App Store’s guidelines and testing and implied guarantees were critical in gaining consumer acceptance of downloaded apps. In order to make these implied guarantees, Apple needed to make restrictions on how such applications were built. Some of these restrictions were on enabling developer technology. We think these restrictions are reasonable and have architected Rhodes from the start to stay within both the letter and the spirit of Apple’s guidelines.

We believe that:

1) the App Store’s restrictions on iPhone application’s use of enabling technology are actually totally reasonable.

2) Rhodes is clearly acceptable enabling developer technology that stays within both the letter and the (reasonable) intent of the App Store’s restrictions

Specifically the iPhone App Store’s Rule 3.3.2 states:

An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

This paragraph contains two key points especially with regard to a framework such as Rhodes. The most often-referenced issue is “no interpreted code may be downloaded“. Note the emphasis on “may be downloaded”. Sometimes this is misinterpreted as “no interpretors”. No, the issue is that if you download code to an interpretor then there is no way to know just what an application really does since it could change daily. Clearly there are many apps that are based on some form of interpretor. The important thing is to not download code to those interpretors, because this invalidates any attempt to test what the application does.

There is an exception to this “downloaded interpreted code” ban of course. That is, use of JavaScript within a browser control. It’s a very popular technique to use the iPhone SDK WebUIView control to quickly create user interfaces in HTML or download content from an existing external web page. Many of such existing web pages however contain JavaScript. So loading those pages would violate the “downloading interpreted code” ban. In this area, Apple seems to be exercising discretion and allow such apps when the clear intent is to just reuse existing web content to good effect.

However, there are efforts to make downloaded JavaScript much more of an “app development tool” by providing robust device and UI capabilities. Or even to allow app business logic to be embedded in JavaScript calls. In my opinion, such frameworks do violate what Apple is trying to accomplish by insisting that an application’s functionality cannot be changed after it is installed. And that Apple is in fact being reasonable by calling such capabilities questionable.

By contrast, within Rhodes we should make clear that such dynamic behavior is not possible. Rhodes does in fact contain an implementation of Ruby. However, it embeds a mobile optimized Ruby 1.9-based intermediate bytecode executor that operates on precompiled Ruby code. Also, for good measure, we have eliminated the ability to do dynamic creation of code (such as removing “eval”). We want to make sure that application developers can only create applications with behavior that is known a priori. And that they do not have the ability to inadvertently create violating apps. Given that we are well known to the App Store and have never had an app denied, it appears that these extra efforts were worthwhile.

The second issue is that “an Application may not itself install or launch other executable code”. The key thing is the ban on launching other executable from your own executable. It does NOT mean that you can’t use a “plug-in architecture, call other frameworks or call other APIs”. That would be absurd and its doubtful if any apps would pass that muster. It means that you cannot use other enabling technology (runner, plug-in, framework, API) that is delivered as compiled executable code. Examples of such technology include Adobe AIR/FlashLite/Flex, Google Gears, any JVMs. The reason for this is that if a developer is going to be truly responsible for the full gamut of his or her functionality he needs to be able to see the source for all of his resultant executable code. This is not possible if he is in effect just calling another executable. This is why we always knew we would open source Rhodes. A Rhodes-based app is just like any other iPhone app, with, in effect, some extra source code that we have provided to the effort: a sync client, a Ruby intermediate bytecode executor, and a small Object-Relational Manager. It is merely an accelerant to a developer’s own efforts by providing a headstart with some source. If it didn’t exist, many developers would build their own equivalents of several of the pieces we provide.

In summary, we think guidelines on what applications can do on mobile devices (from Apple or elsewhere) are good things. Rhodes will continue to make it easy to build rules-compliant apps for the App Store and other app marketplaces.

3 Comments | Posted by admin

EuRuKo and device capabilities

Yesterday I had the pleasure of speaking at the superb European Ruby Conference in Barcelona. It was fascinating seeing the enthusiasm of the audience for Ruby and the technologies presented. I also got to talk to several attendees about their own Ruby efforts. The most interesting chats that I had were reminders of how device capabilities on mobile are constantly expanding. This will be a constant thread and area of continued development and innovation for Rhomobile.

For example, I talked to Bart ten Brinke and other developers from Nedap Healthcare about their mobile home healthcare monitoring and timekeeping software. It runs via the builtin RFID on the nurse’s mobile. They swipe the patients card over the phone to check in and check out during their visit. Right now it’s only J2ME based for Nokia’s Series 40 RFID-embedded featurephones. But the forthcoming RFID support in various smartphones, including several accessories for the iPhone, plus support for RFID in Rhodes, would enable a much more powerful (far beyond just timekeeping with patients) suite of similar apps for the iPhone.

I also talked with Jason Goecke of AdHearsion after he did a superb talk on voice-enabling apps. I really like following great speakers as they get the audience woken up and ready to process even more information (this phenomenon contributed to our mutual five star ratings). Like Rhodes, AdHearSion is a Ruby-based framework that makes it easy to buid server apps that do voice and IVR processing for apps such as phone-based customer support systems.

The possibilities of doing interesting applications with data on the smartphone but allowing the user to voice drive a backend app via a smartphone are pretty extensive. Imagine the customer/user interface for a CRM or issue tracking system and then invoking “reach out via voice” totally within context that you’ve selected via your smartphone. With the IVR systems I’ve used I think you’d save at least “voice menu options”, which I would imagine would make customer satisfaction skyrocket in such systems.

I’m sure there are developers using Rhodes and AdHearSion today without our knowledge given our common customer base of early adopter Ruby developers. But regardless, I’m excited about about demonstrating the potential of data-oriented smartphone apps (aka Rhodes apps) to accelerate and alleviate interaction with backend IVR systems (such as those built with AdHearSion) in at least one of our sample apps.

0 Comments | Posted by admin

RhoHub: world’s first “mobile development as a service”

“Development as a service” is the newest buzzword in the cloud computing arena. Services such as Heroku and force.com have started to pioneer a new model of doing most of your development work out in the cloud with only a browser used on your local device. This is an exciting development in general. But no subdomain of app development is more in need of development as a service than mobile. Mobile apps typically require a complicated set of SDKs to be installed and require a specific type of computer operating system to run on (LInux users are often left in the cold here). At Rhomobile, we are in the process of launching the first “mobile development as a service”: RhoHub.

Some background: with Rhodes, we believe that we have provided the mobile app development industry with the ability to create native mobile apps that run across all smartphone operating systems for the first time ever. And beyond the portability benefits we’ve made it unprecedentedly easy to build apps even for a single smartphone device by letting people create native smartphone apps with the power and productivity of HTML templates (typically resulting in apps that are five times smaller in code size).

All that said, there are still ways that we can make development even easier by providing a web-based service for both Rhodes development and hosting of Rhodes apps. Although we provide nice high level rake scripts that let developers do builds for all smartphone operating systems from a single command, they still have to have the appropriate computer operating system to do the build (Macs for iPhone, Windows for other builds) and have to have the underlying SDKs (e.g. iPhone, BlackBerry, etc.) installed. Also if a developer wants to build and host an app that works with synchronized data they will typically need to set up a copy of a RhoSync server.

RhoHub allows developers to generate their client and server app code (HTML templates for the Rhodes client, source adapters for the RhoSync server) for each object of interest. They can then edit their code (HTML templates for Rhodes or Ruby code for RhoSync source adapters) online right from the RhoHub website. When the app is complete developers can then build an executable for Windows Mobile, BlackBerry, Android, iPhone or Symbian. To facilitate rapid development, RhoHub also introduces a Win32 build. Developers can build for Win32 and quickly download it to their local machine for testing (we will provide a Mac OSX Rhodes build later).

Once the app is complete, RhoHub also offers a “provisioning service”. Developers can expose a single URL to their users, e.g. “http://mobile.mycompany.com”. Users access that URL from their mobile web browsers and the RhoHub provisioning service will offer up the appropriate downloadable executable for the detected mobile device (a Windows Mobile .CAB file for a user accessing the URL via Pocket IE via their Blackjack II, a BlackBerry .COD file for a user hitting the site with their BlackBerry Bold). Developers also can easily deploy their RhoSync source adapters to the RhoHub-hosted RhoSync server, eliminating the need to host their own RhoSync server.

RhoHub will go to “public beta” next month at InterOp. Public beta means that it can be used to develop Rhodes-based apps. But it won’t be allowed to be used for production use by end users until RhoHub exits its beta phase and releases. We expect that to be some time in early July, but we’re looking for feedback from our early beta customers on this.

1 Comments | Posted by admin

SDForum: Trends in Mobile App Development

On Friday, I had the pleasure of participating in a panel at SDForum’s Developer Conference on trends in mobile application development. Alongside representatives from Sun, Nokia and others, we discussed emerging ways that mobile apps were being built. Two in particular seemed to capture the panel’s interest:

high level, declarative development

the success of HTML for web development provided a much more productive, portable, and powerful way of developing apps. Declarative development through either HTML or XML is emerging as a way to develop other kinds of apps as well: both rich desktop apps and mobile apps.

For desktop software, often known as Rich Internet Applications (RIAs), this is evidenced by technologies such as Adobe Flex (an XML for RIAs) and Titanium’s AppCelerator. For mobile software the category is even more nascent, and examples include Rhodes, PhoneGap, and Nokia’s Web RunTime (WRT) for Series 60 devices.

pushing computing to the edge

In the early days of computing, apps were primarily centralized on mainframes and minis, and accessed remotely by users. The advent of personal computers in the 1980s enabled a new generation of locally hosted and used applications on individual’s own desktops, spawning an exciting new array of capabilities. The dawn of the web in the 1990s created a swing back toward many “centralized apps” accessed by ubiquitously available web browsers. Finally in the last few year the explosion of smartphones as fullfledged computing devices has created yet another new generation of applications, that take advantage of these device’s new capabilities by executing locally on devices again.

The Rhodes framework is a great way for developers to take advantage of both of these trends.

0 Comments | Posted by admin

1.0 Out and 1.1 Plans

Two weeks ago we released 1.0 to far greater than expected press and customer uptake. Frontpage stories on CNet, VentureBeat, InfoWorld, ArsTechnica and others, with very insightful analysis (although a few other articles confused us with a mobile web development solution because of our use of HTML to create views). Ryan Paul from ArsTechnica even wrote his own Windows Mobile app. Plus we’ve had several of our developers submit apps to the iPhone AppStore. VDGGroup released their IssuesToGo app – a mobile frontend to the popular LightHouse bug tracking that we’re happily using at Rhomobile to stay on top of our bugs. Wikimedia submitted their 1.0 based iPhone Wikipedia to the iPhone AppStore and will later move it to Android.

So 1.0 is out and now supports all shipping smartphones. Plus we have all the most important device capabilities (at least for enterprise app scenarios) covered. So what are we doing in the next release? 1.1 is slated for release in mid-May at Interop in Las Vegas. What’s new in 1.1 then? We are doing a lot of work to provide robust testing frameworks to enable developers to test their apps well. This includes providing the long asked for “desktop version of Rhodes”. You’ll be able to test your Rhodes app right from your Windows laptop without running an emulator.

We’re also doing a lot of performance work. This includes faster startup time for iPhone (already checked into the 1.1 unstable branch of Rhodes). It also includes faster data synchronization. One of the features is the ability to handle very slow backend apps by allowing queries to be queued and handled completely asynchronously (the queued sync option for a RhoSync source). This is also checked into RhoSync edge. There are several other RhoSync server and client performance improvements underway as well.

We’ll always add device capabilities in each of our point releases. For 1.1, by request of some Rhodes developers, we’ll be adding video play support.

But the biggest feature for Rhomobile coming over the next month is opening up the private beta of RhoHub. Explaining RhoHub however is a much bigger blog post to come.

0 Comments | Posted by admin

for developers the best learning materials are third party tutorials

It has always surprised me in the past that the best learning materials for any language or development technology are written by those who didn’t build the technology. The best book for learning C++ way back in the early days was not either of inventor Bjarne Stroustrup’s early books. It was Lippman’s excellent C++ primer. For years the best books on learning either Rails or Ruby were written by Dave Thomas (Agile Web Development in Rails and Programming Ruby) who didn’t have much to with developing either of the two technologies (although he did write the first version of RDoc). And in our opinion, his book was surpassed by later authors such as Fulton’s excellent The Ruby Way.

The same is true for Rhodes. We were pretty happy with our tutorial. And we work pretty diligently to keep it current and accurate at all times. We’ve gotten a lot of kudos from developer users that its pretty good. But, lo and behold, we’ve been one-upped by one of our users, Makoto (who is working on a Mobile Twitter app that is available on GitHub). Check out his blog. Its devoted to “Ruby on mobile”, which as far as I know right now is basically just our technology. The first two articles very nicely summarize the development process with RhoSync and Rhodes, better than we did in the tutorial.

2 Comments | Posted by admin

The Seven Habits of Highly Effective Open Source Products

This morning I talked with Andreas Constantinou of VisionMobile who was pleasantly surprised that all of our source code checkins (”internal” and external) were available publicly on open source repositories (specifically the superb GitHub) and that our bugs and issues were also all publicly available (on the similarly excellent LightHouse). It seems like commonsense to me, that this is necessary to be able to claim that your product is open source. But, alas, many companies are not following such a process. For example, in the mobile space both Symbian and Android do NOT keep all of their checkins and issues available externally (nor do they really follow many of the habits listed below today, though I expect that to change). It’s great that those technologies are available under an open source license like GPL. But is that enough to truly say they are “open source”?

I was asked by Andreas what we believe is necessary to claim your product is open source. Here’s our take on the appropriate criteria, roughly in order of importance and prevalence in the industry.

1. public source viewing – Of course you need the source for your product to be publicly viewable and reviewable. Most products claiming to be open source meet this criteria at least on a release by release basis (whether this is sufficiently granular and realtime we’ll discuss below)
2. common license – you need to make it available under some prevailing non-company-specific open source license. For example, our product is available under Gnu Public License Version 3 (GPLv3). Making up your own license does not count. I’m a busy software developer. But I understand BSD, GPLv3 and other common licenses. If you make up your own license and I have to read it all, its not open source in my opinion
3. public source code checkins - all checkins need to be available realtime on a publicly available source code repository such as GitHub or SourceForge. No “internal company repositories” or even a publicly available source code repository hosted by the company themselves.
4. public bugs – defect reporting needs to be on a publicly available bug database such as LightHouse.
5. public forums – discussions and support should be available on a google group or some other publicly available forum. Lurking (for other users to learn) is good and should be encouraged. Few companies are doing this
6. anyone can contribute – contributions from the community are good and should be encouraged. For open source dual licensing companies (companies like ourselves that make a commercial license available for users who need one), a contribution agreement will almost always be necessary. But it should be brief and similar to others.
7. public complete and modifiable documentation – Specifications and user documentation should be publicly available on a Wiki that users are allowed to contribute. Almost noone does this now but it should be encouraged and I believe will eventually become the dominant model.

In all fairness, right now the list of companies doing all of these things is quite small. However, plenty of individual open source developers (probably the majority) follow these guidelines, mostly because each one is a win-win for getting as much done as possible with as few resources as possible, leveraging the power of the community. I believe the first four (viewable source, common license, public checkins, public bugs) should be an absolute requirement to label your product open source. The last three are very good practices that we think will become more predominant over time.

2 Comments | Posted by admin