Rhomobile’s open source mobile application framework Rhodes lets you quickly build native mobile applications for all smartphone operating systems: iPhone, BlackBerry, Windows Mobile, Symbian and Android. These are true native device applications (not mobile web apps) which work with synchronized local data and take advantage of device capabilities such as GPS, PIM contacts and camera.
It is licensed under GPLv3. So if the you are willing to open source your application, then you are compliant with that license and owe Rhomobile nothing. However, if you want to keep the application source code private then you need to purchase a commercial license from Rhomobile. The proposed licensing model is a percentage of the app proposed price.
The main shortcoming of the library is that it is currently unable to do anything with multimedia (audio and video). So it is great for any database-driven app with on-line synchronization, in fact the framework is optimized for interacting with transactional enterprise application backends. It is also designed to work with synced local data using a local database such as SQLite or DB40 and a generic backend synchronization framework such as RhoSync (another open source component available from Rhomobile).
It is available for iPhone, Research in Motion (Blackberry), Windows Mobile, Symbian and Android support has been recently added.
Basically, it takes the idea I had the moment the iPhone came out of getting a webserver and an interpreter into the device to a whole new level, by integrating those components into the compiled native application for all those platforms, along with some interface libraries such as IUI to make the app look and feel like a native app.
Rhodes takes much of its inspiration from web-oriented MVC style frameworks such as Ruby on Rails. However it has several simplifications and optimizations for the mobile scenario. Most of them are to keep the framework as lightweight as possible to be able to run on mobile devices with limited memory.
The main attractive of this framework is the ability to develop once and distribute on all App Stores for all these mobile platforms (iPhone, Blackberry, Windows Mobile, Symbian and Android).
Where Technology and Religion Collide
iPod Touch 4th Generation, iPad revision and new mysterious iDevice coming in autumn
How to install QuickTime Player 7 on Mac OS X 10.6 Snow Leopard without the DVD
Copy of an NSObject subclass
Android iPad knockoffs… pass
Hi,
You stated: “These are true native device applications (not mobile web apps)”
Then you also stated: “Basically, it takes the idea I had the moment the iPhone came out of getting a webserver and an interpreter into the device to a whole new level, by integrating those components into the compiled native application for all those platforms, along with some interface libraries such as IUI to make the app look and feel like a native app.”
I think the second statement is better than the first. “It just looks and feels like a native App.”
The first is only for the user who doesn’t look deeply at the system. But as the view of a developer, it is actually a webserver running on the client device, so it looks like an application. But look from developer’s point of view, first the web request is stateless, also, if you would like to do anything you have to use HTML, also, if you need further things like Polling, you need JavaScript, etc… all in all, you develop a web site, and you are running a website in the local Web Server app running at the local device.
And the important thing is that, you are still limited by the browser capabilities of the mobile device. Let’s say if your Pocket PC is running Windows Mobile 2003, you may not be able to use some AJAX facilities. So again, it stills depending on the browser’s capability, so it is not “Native Application”.
Correct me if I am wrong somewhere.
Regards,
Pham Van Vung.
Hello,
Initially, when Apple presented the iPhone to developers, we were only allowed to create web applications that would run in the built-in Safari web browser. That is what I was referring to with “mobile web apps”.
Rhodes apps are true “native” mobile apps because they get compiled for each platform and you can publish them within the iPhone’s App Store.
Your point is perfectly true: you are limited by the browser capabilities the mobile device development environment will make available to you.
However, it is likely that all major mobile platform will catch up on iPhone’s Safari capabilities, therefore starting with a Rhodes app development today aimed at the iPhone will kick-start the development for other platforms.
It’s still quite a decision to make though. There are several pros and cons to keep in considerations and this one you point out I didn’t mention in my latest post. I’ll update it. :) Thank you.