I’ve been spending a great deal of time working with Eclipse runtime technology recently. Specifically, I’ve been building an example application that deploys using Eclipse Rich Client Platform (RCP), Rich Ajax Platform (RAP), and embedded Rich Client Platform (eRCP). The application itself is simple enough: I like examples to be as simple as possible, but useful, so I built an expense tracker. I figure that, if I can make it useful enough for my purposes (i.e. help me keep track of my travel expenses and automatically fill out those forms I hate love so much), it will give me great motivation to keep it up-to-date and new versions of the technology becomes available.
I started first with an RCP version of the application. I’ve been building applications using RCP for a while, so this seemed like a natural enough step.
After I got some bits of the functionality working, I switched over to RAP. The switch to the technology itself was pretty straightforward. I installed the development plug-ins from the update site (they provide some handy launchers that make testing super easy), and downloaded and unpacked the runtime target platform. RAP applications, just like RCP applications require a target platform which provides a set of bundles that form the foundation of the application. The cool thing about RAP is that it lets you build applications using almost exactly the same set of APIs that you use when building RCP applications. In the ideal case, you switch from an RCP target to an RAP target and you’re in business.
While RAP provides a growing subset of the the same APIs made available to RCP developers, they are packaged differently. In my original work, I had specified a number of bundle dependencies. Since the names and organization of the bundles in RAP are, in some cases, different than those of RCP, many of the dependencies could not be found (package and class names are the same). I switched from using bundle dependencies (Require-Bundle) to using package imports (Import-Package). I’m not sure if there is a recommended practice in this domain yet, but I opted to use package imports for all “system” dependencies, and bundle references for dependencies on other bundles I created.
The conversion of the application from RCP to RAP was pretty quick and relatively painless. With this success in hand, I turned my attention to eRCP.
The conversion to eRCP required a bit more work. First, I had made the cardinal sin of using Java 5 (language syntax and libraries). Most of the migration effort to eRCP was a pretty mechanical process of converting to the version of Java supported on the device. Specifically, I had to convert everything down to Java 1.3 and CDC-1.1/Foundation-1.1 libraries. This required more than just changing syntax as I had used some APIs not included in the target environment; this sent me searching for replacements for functionality such as regular expression parsing. Once I worked out my addictions to Java 5, I turned my attention to the user experience. Before I started down this path, I knew that eRCP didn’t have a notion of perspectives (tiny screens don’t lend themselves to perspectives), I tried to carefully design the various views in my application to work with this restriction.
My initial effort has resulted in an application that runs on all three platforms. Some 90% of the code is exactly the same on all platforms. In fact, I have a handful (recall that I wanted to have a relatively small application) of bundles that are just shared and so are immediately testable and deployable on the various platforms.
I have an “application” bundle for each platform that pulls all the parts together in different ways. The RAP version of the application presents itself in full screen (full browser?); the RCP version uses the Nebula CDateTime widget, the eRCP version adds explicit navigation between views and leverages the special “command” buttons available on a device. I can envision other “application” bundles that assemble and manage the components for different types of devices; the way that I interact on an iPhone (at least theoretically) is different than I do on the Nokia E90 I’ve been playing with; I can capture the different navigation aspects in a separate bundle while still leveraging the 90% functionality reuse.
I intend to talk more about this application over the next few days and weeks (and post some pictures). When I get home from from JavaOne this week, I’ll start the process of contributing this application to the new Eclipse Examples Project. In the meantime, I’ll be at the Eclipse booth at JavaOne. Find me there (or at the Thirsty Bear on Wednesday night).
