Software Everywhere — David Beers on Mobile Computing

Eclipse is going to release 1.0 of the embedded Rich Client Platform any day now and I'm shopping around for a new smartphone I can use to evaluate it. eRCP has not been receiving a lot of buzz outside of the Eclipse community although its development has been a partnership by heavy hitters like Nokia, Motorola and IBM. I blogged about my interest back in July but wanted to explain in not-too-technical terms why I think this new way to run Java applications on a mobile device is potentially a big deal that's flying in under the radar.

Java on mobile phones has been in certain respects an enormous success. Java ME (formerly known as J2ME) will be on more than a billion handsets this year, which if I'm not mistaken must make it the most widely deployed software platform of all time--far outnumbering Windows PCs for example. At the same time, though, mobile Java has fallen well short of its potential. The platform is notoriously fragmented into dozens of only partly compatible implementations by various vendors, making it a costly and tedious process to create software that will run correctly on the majority of Java-enabled phones. While Java ME environments need to be certified by Sun there is no published test suite to create a standard for proper behavior or simply to catch the widespread bugs (an initiative by Motorola aims to fix this). These incompatibilities combined with the design-by-committee Java Community Process have hobbled innovation, making it difficult or sometimes impossible to build the kind and quality of applications that can drive demand the way voice communication and messaging have. Some specific shortcomings of the most popular Java ME profile (MIDP) include:

• Weak user interface. While Java has some decent graphics and multimedia capabilities it falls far short in offering the kinds of UI controls needed for many business and productivity applications.
• Poor integration with the underlying operating system. On most phones Java applications do not do a good job of respecting the look and feel the user has selected for the handset. They also have limited and inconsistent access to built-in platform features like web browsers, Bluetooth radios, or even file systems.
• No communication between applications. Java can only run one MIDlet at a time so there is no way for an application to deliver services to other running applications or for applications to share the user interface in any way.
• No component model. There is no way to create software components that can be shared by more than one application. There is also no way for developers to push an update or a new feature to an application over the air without asking the user to reinstall the whole application.

What Eclipse has done is to create an open source project that purports to deliver mobile Java from these shortcomings, and this is eRCP. Actually, for the sake of limiting your exposure to Java's notorious penchant for acronyms, gentle reader, I'm using "eRCP" loosely to refer to three separate technologies from Eclipse (eSWT, eJFace, and eRCP, if you must know). Here's what you get:

• Native user interface If the user selects a theme where a button has a white Tahoma font, a gold border and a dark blue background image on the device's native applications then the buttons in an eRCP application will have the same look and feel. That's because an eRCP application actually uses native widgets. Running on the more advanced operating systems that it's intended for, it can provide even very sophisticated controls like grids with user-resizable columns and tree controls. And since the controls are supplied by the OS instead of generated with lots of Java code, the user interface is faster and uses less memory.
• Good integration with the underlying platform. Here's a screenshot of a page in an embedded Eclipse application with two controls: a label (the text reading "Title: eRCP Download Page") and a browser widget displaying a page from eclipse.org.
  
  
  
  Thanks to Chris Aniszczyk for the screenshots
  
  It's running on a Nokia S60 platform and the browser has all the capabilities of the S60 browser--because it is the S60 browser, exposed as an embeddable component that could be used to render HTML email, navigate a hypertext document system, or what-have-you. Notice below the native look and feel (and the ability to query the system for the free storage space) in a wizard page running on a Windows Mobile 5.0 device:
  
  
  
  
  
• Applications can be composited from high-level plugin components, services or applications. Any developer who has used the Eclipse IDE (built on the desktop version of the same framework as eRCP) knows that you can download and plug in new features and applications using Update Manager and see these integrate seamlessly into the IDE: chat programs, issue trackers, time trackers, report designers, games...there are literally hundreds of them. A huge ecosystem just to serve Eclipse developers. Eclipse offers a facility for "extension points" that enable one plug-in to make contributions to another, including GUI elements like new menu options that trigger actions with additional screens. It's a platform that was designed from the bottom up to give users the ability to create mash-ups. At some point I need to blog about Mylar, an Eclipse IDE plug-in that exploits this facility more powerfully than any other I have seen in Eclipse, but for now just consider for a few moments what it would be like if phone applications were user- or administrator-customizable by simply adding and removing plug-ins over the air. eRCP's eUpdate feature (pictured above in the "Application Manager" screen) makes this possible. On larger-screen devices, two plug-in applications could share a split screen (how often have you wished for this when having to read and write something at the same time) or even drag and drop items from one application pane to the another that belongs to a different plug-in but can accept that data type.

Here's the catch: eRCP needs a Java environment but it won't run on just any Java phone. For now there are ports to Windows Mobile 2003/5.0, Symbian S60/S80, and a new one to QT embedded devices. But desktop RCP has good support for GTK+, so a port to platforms like Maemo, the ACCESS Linux Platform, and other mobile Linux platforms that use GTK should be a fairly simple matter. Another caveat: the full eRCP framework requires a beefier version of Java ME than is found on most mobile phones: Foundation Profile. To get the whole plugin/extension point framework, and eUpdate, for example, you won't be able to use S60--yet. But even on S60 you can still use the nice native graphical UI toolkit in place of the ugly and anemic MIDP ui library.

These device requirements put you into the $350 plus range for a smartphone that runs eRCP, although a Dell Axim PDA will do the job nicely for a lot less if you don't care about WAN connectivity. Gorkem Ercan, the lead committer for the eRCP project and a member of Nokia's S60 team told me that future S60 phones will run Foundation Profile Java and will therefore support full eRCP, not just the eSWT UI toolkit. S60 is the most popular smartphone platform in the world by quite a large margin, so that will be dramatically extend the reach of embedded Eclipse on mobile phones.

As I said once before, a big question in my mind is real-world performance of a framework like Eclipse on resource-constrained hardware. I'm assured that launch time is the slow part and that the UI is very responsive once everything has loaded. It seems to me that someone needs to give some thought to an application launcher plug-in (implementing IPlatformRunnable) that would display icons for launching plugins as applications similar to the Palm OS. This would move eRCP in the direction of being a full-fledged platform within a platform--and in some ways one with more powerful high-level capabilities than the native platform it runs on top of. You'd have your contacts, calendar, phone, browser, chat and email apps in there--all integrated with each other--along with whatever third-party plugins you cared to install and you'd rarely, if ever, bother to exit the Eclipse runtime. A phone vendor with a similar vision to say, SavaJe, could turn eRCP into the application stack for the entire phone.

Note: This was written late after a long day. I'll probably come back and edit it!

I spoke last week with Darren Shaffer, a Microsoft MVP who is a member of Colorado Mobile Developers and a busy enterprise mobility software consultant. It had been about 18 months since we last talked and it was interesting for us to compare notes about how our work has evolved during that time. It seems that our consulting work has moved in a very similar direction, despite the fact that he is completely in the Microsoft camp and I've been mostly on the Java side during that time. It quickly came out that we both had moved from an almost exclusive focus on mobile device software to one that added rich desktop client applications to the project mix.

It's been a couple of years since I've done any .NET work and he mentioned something I hadn't heard of called the Composite UI Application Block (CAB) that he said was a key part of the architecture of his current "Smart Client" projects. Reading about CAB tonight, a big grin spread across my face. It's trying to accomplish exactly the same things that RCP does. In paragraph after paragraph you could actually substitute "Eclipse RCP" for each mention of "CAB" and end up with something that was essentially correct. Here's an example from a .NET blog that was high in Google's ranking, followed by my "translation" into Eclipse:

In .NET:

The CAB uses the concept of a shell application, within which one or more SmartParts can interact. SmartParts are the minimum unit of management of a solution and a solution is built from a collection of collaborating SmartParts that ship inside plugins called Modules. The shell application is simply a Windows Form application that uses the Component Model to provide services to the SmartParts.

Translated into Eclipse:

Eclipse RCP uses the concept of a workbench application, within which one or more views can interact. Views (and editors) are the minimum unit of management of a solution and a solution is built from a collection of collaborating views that ship inside plugins called, well... plugins. The workbench application is simply an SWT/JFace application that uses the OSGi framework to provide services to the views.

Both CAB and RCP use a lightweight container that manages the lifecycle of these collaborating plugins and supplies services to them, like application updates, logging, help infrastructure and application preferences. This encourages a style of programming that lends itself to more loosely coupled designs. In one podcast (sorry, lost the link) the developer spoke of how this didn't always prevent tight dependencies between plugins from creeping back in as the solution develops and I thought I was listening to myself talk! I wasn't surprised, then, to learn that CAB employed some fancy Aspect Orient Programming to implement the dependency injection pattern and keep plugins loosely coupled--because this is exactly what the OSGi and Spring teams have done recently to provide the Spring framework's dependency injection on top of the OSGi services platform. It's like a parallel universe. Or twins separated at birth.

What's funny about all this isn't that there is so much similarity in the work being done in the Eclipse and Microsoft camps--the fundamental value of a cohesive, loosely coupled component-based model for assembling complex applications is the same no matter what language or API you develop against. What is funny is that RCP and CAB are obviously "big news" in their respective worlds, yet those worlds are so isolated that I've never heard anyone refer to both in the same sentence, much less compare or contrast them. I might never have even heard of CAB were it not for the fact that I participate in a professional developer group with a focus that quite intentionally cuts across those language and platform boundaries.

Here are a couple of screenshots of CAB in action, giving you the distinct flavor of an RCP-like structure of composited views... er, SmartParts. Here's a screenshot of one of my current RCP projects illustrating the same kind of structure:

Pikesoft is juggling near-simultaneous 1.0 releases for two clients, so forgive me if "Eclipse Week" gets stretched out over two or three weeks. Not too coincidentally, both of the products we're in the process of releasing include desktop applications developed with the Eclipse Rich Client Platform.^* The first, EpiSurveyor, is a contender to replace Epi Info, an aged but heavily used health data collection solution with over a million downloads in 180 countries. The second is [redacted]. When I said that I'm impressed with the Eclipse platform I didn't mean it in the abstract: I bank heavily on it for almost all of the desktop rich client application development my company does, and so do my clients.

I'm also getting ready to evaluate the Eclipse Embedded Rich Client Platform (eRCP) as a mobile application framework, and I'd like to explain both my interest and my concerns. First a little background about eRCP.

What is Eclipse eRCP?

eRCP is a trimmed down version of the plug-in architecture, "workbench" and UI libraries that form the framework of Eclipse. As such it runs in a Java environment on a mobile device and uses a similarly trimmed down version of SWT to produce user interfaces with native widgets. On Windows Mobile it's indistinguishable in look and feel from a .NET Compact Framework app and on Symbian Series 80 it's indistinguishable from a native S80 app. eRCP requires a J2ME CDC environment since it uses JNI, Java reflection and custom classloaders that are not possible in the vastly more common CLDC/MIDP environments. That means it won't run on Palm OS, BlackBerry OS, or Nokia S60 devices (not yet anyway). But it's also a much more powerful environment than MIDP.

What's exciting about having Eclipse on your phone?

Keep in mind we're not talking about running the Eclipse IDE on a mobile device. But you have most of the things that have made Eclipse spread like wildfire through the software developer communities:

• a component architecture (OSGi) that enables plug-ins to be uploaded, updated and installed on the fly
• a system of extension points that allow plug-ins to contribute features to existing plug-ins without a recompile
• light-weight, cross-platform native GUIs
• open source SDK and tools

I enjoy developing with SWT and JFace and the fact that I can leverage those same skills--and even some existing code--in my mobile application development is attractive. But for me, 90% of what makes eRCP interesting is that it implements OSGi. OSGi can be thought of as a container for Java clients much like Java application servers are containers for web applications: it's what gives Eclipse this amazing and flexible component model. OSGi is what allows Eclipse to be a true "smart client" with a rich, native interface but the easy remote management that IT guys usually expect only from a web application. The difficulty of deploying, administering, and updating devices in the field causes a lot of push back in IT departments that are considering mobile solutions. Many try to settle for WAP browser applications to avoid the hassles, but the poor user experience of a web application on a mobile has dampened interest in server-side mobile solutions. I think eRCP (and other OSGi implementations like ProSyst and Knopflerfish) offer a vision of mobile computing that is much more open and dynamic than anything we have seen with J2ME or even native APIs.

So what's the downside?

Ok, first I want to remind you that I have yet to actually evaluate eRCP, so the concerns I express here are more from what I know about mobile software development in general and the Eclipse SDK more specifically, not from any actual testing. But there's no doubt that eRCP requires mobile phones or PDAs that are high end: they need enough memory and processor cycles to drive a Java environment that is much fuller featured than what is on 95% of the mobile phones today. That means a smartphone OS like Windows Mobile, Symbian S80, or embedded Linux and a pricey PDA or PDA-phone that adds a lot to the cost of a mobile deployment. Having spent a lot of time reading, patching, and adding new features to JFace over the last year, I can guess that it's not just OSGi's requirements for JNI and custom classloading that force the use of high-end hardware. It's also the fact that the APIs and implementation code the eRCP team are starting with were never written with resource-constrained devices in mind. The team is trying to keep the main packages of eRCP, eJFace, and eSWT as strict subsets of their desktop GUI counterparts. I can understand why they'd like to do this, but as Microsoft has learned the hard way, PC software is not necessarily a good foundation on which to build mobile software, no matter how much you try to trim and optimize.

I will be delighted to learn I am wrong about this. I was eyeing a Nokia 9300 smartphone at the Cingular store today and thinking that it would make an interesting test device for eRCP. Sure, it's a high-end S80 handset, but it also runs an OMAP processor with a mere 150MHz clock speed. Nokia has been one of the companies (along with IBM and Motorola) that have contributed resources and developers to the eRCP project, so it should be a fair test of the platform to see how it runs on a slow processor like the OMAP 1510. OSGi has been given the impression that Nokia will release a phone with OSGi baked in Real Soon Now. Future S60 phones are supposed to have CDC Personal Profile Java environments in them, so perhaps we will see this powerful framework on some lower cost mass-market devices before long.

eRCP is at version M9 right now, so the 1.0 release shouldn't be far off. They've just added the Update Manager feature, which delivers most of the function of the desktop Update Manager in the Eclipse IDE. That's where things are starting to get interesting. So when I'm past my huge deadlines I'll be giving it a look.
______

* Both of the projects I'm working on involve mobile device software as well: Pampered Chef is still in a requirements-gathering stage, but EpiSurveyor is really a rapid application development platform for PDA data collection applications.

Motorola has been showing encouraging signs that all its fancy words about loving open source software are more than just lip service. Things were not always so, as seen by sundry complaints like this one over Motorola's failure to publish an SDK for the EZX framework it uses on some of its current Linux smartphones. But now Moto has joined the open source Eclipse Foundation and proposed a top-level Eclipse project called Tools for Mobile Linux, or TmL. This comes on the heels of the announcement just over a week ago that Moto is joining Samsung, NEC, Panasonic, NTT DoCoMo, and Vodafone to create an open source Linux phone platform of some kind. Also not long after they created a developer site to host an open source Java MIDP 3.0 implementation and a testing framework for MIDP 3.0.

It's worth noting that Motorola has also been a contributor to another Eclipse project that I will discuss in a later post this week: the Embedded Rich Client Platform (eRCP) project. That intriguing project brings Eclipse's OSGi-based plug-in architecture, the Standard Widget Toolkit (SWT) and frameworks like Update Manager to a mobile device near you. Well, it does if that device runs Windows Mobile or Symbian and has a lot of memory and processor horsepower, anyway.

From the new project proposal page at www.eclipse.org/proposals/tml/:

The primary focus of the Eclipse TmL project will be to provide the extensible frameworks and exemplary tools for the development of C++ applications targeting mobile devices. Included within this goal is the need to provide an optimized development environment for the creation and testing of end-to-end services which requires the integration of server side development with the device-side emulation environment. A secondary goal will include providing a complete environment for the development and building of the entire target device software stack (OS, drivers, middleware, and applications).

So the tools Moto plans to contribute (some of which they suggest will be derived from existing open source tools, including I presume Eclipse CDT) are aimed first at application developers and second at system developers. I like the fact that they see this as a platform for developing not just native phone applications, but end-to-end services. Part of Eclipse's advantage here is that there are already Eclipse plug-ins for server side development, debugging and testing that can be leveraged by Motorola and any other companies that join the project.

Speaking of other companies, though, where are they? Where are the other members of the as-yet-unnamed Linux phone consortium that Moto just joined--and who presumably would be using these tools to develop their planned phone platform? Where are TrollTech and MontaVista, both partners with Motorola in developing their current Linux smartphones? I'll be interested to see who actually contributes resources to this project, a test of the sincerity of these companies who claim to be supporting mobile Linux standards and fighting fragmentation.

Yes, the fact that we now have no less than four overlapping mobile Linux standards initiatives makes me a skeptic that the mobile Linux cats can form a single herd and raise a credible challenge to the reigning commercial phone OS vendors. All the same, I'm glad Motorola isn't waiting around for standards before it starts developing badly needed open source tools for mobile Linux. It's hard to form standards from thin air, and it's easier when there is a recognized leader that has created defacto standards by developing popular open source software. Eclipse has been a great "market square" for attracting and cultivating an ecosystem of industry standard tools, and Motorola is as good a candidate for leading the mobile Linux charge as any company, so it's good news that they are teaming up.

I think I'm going to make this "Eclipse Week" here at Software Everywhere. I've got a backlog of Eclipse-related things I need to write about and Motorola's announcement that they are joining the Eclipse Foundation and contributing open source mobile Linux tools to what promises to be a new top-level project is as good a reason to get caught up as any.

Those who know me as a Palm developer may be surprised to learn that about half the work I've done for the last two years has been developing Eclipse plug-ins and Rich Client Platform applications--mostly ones designed to sync up with mobile client apps, which constitutes the other (and indispensible!) half of my company's work. When I'm not developing Eclipse-based desktop applications I'm still using the Eclipse IDE for 90% of my development.

Here I have a confession to make: I'm not talking about using the Eclipse-based Palm OS Developer Suite. I remain an enthusiastic Palm OS supporter and usually recommend it over the alternatives to my clients, but almost 100% of the production Palm development I've done since the Fall of 2004 has been with the SuperWaba SDK and the Eclipse Java Development Toolkit. For J2ME I use EclipseME. These days my recommendation to clients is that if you're going to invest in custom software you should protect that investment by building against an SDK that is cross-platform, and if at all possible, open source. For projects that target Palm OS, Windows Mobile, or Symbian OS that means SuperWaba, which is like an open source J2ME on steroids. For the desktop that means Eclipse RCP. Except to develop the occasional native library for SuperWaba I've scarcely touched Visual Studio or Codewarrior for Palm OS since September of 2004. Looking back I have no regrets at all.

More about my Eclipse conversion and interesting developments like Moto's membership during the week, but for now suffice it to say that I'm very big on Eclipse specifically and open, extensible plug-in software architectures in general.