Good keyboard controls have become a staple of modern web applications, such as Google Mail, Github (press “?”) and Flickr. However, almost every browser implements key events slightly differently, all with some quirks, and none of them like in SWT. For this reason, key events in RAP had, until recently, several issues and limitations. That is a thing of the past now, as the key events implementation has been largely rewritten in RAP 1.5M5, and now finally works reliably. This also brings some general changes to RAP key event handling.

• Some keys that didn’t work at all (like arrow-keys in Firefox), work fine now. This also fixes the JFace Content Proposal.

• Several non-alphanumeric keys had the wrong keycode,  those are fixed.

• Key events are no longer blocking the UI when sending the Ajax request to the server.

• There is now a feature called “active keys”, which makes it possible to drastically reduce traffic traffic.  It was already present in RAP 1.4, but has been greatly improved.

• Another new feature is called “cancel keys”. It allows to suppress the browsers and widgets default operations associated with any given key.

• The “cancel keys” replace the now-defunct support for the doit flag on key events.

Continue Reading »

Tags: eclipse, juno, Key Events, Keybindings, rap

The latest Android client for RAP mobile (v0.5.3) is now available. We are always looking for feedback so we urge you to take part in our developer preview program to experience the client firsthand.

Besides the usual bugfixes, performance and stability improvements, the 0.5.3 release brings some often requested features to an Android handset near you.

For more information visit: http://rapmobile.eclipsesource.com

The Tree widget supports the SWT.VIRTUAL style flag

The support of the SWT.VIRTUAL style flag allows you to easily scroll through huge amounts of data. While you are scrolling through tree content, the data to be displayed is automatically loaded on demand in the background. Intelligent pre-caching makes it possible to have content visible even when scrolling very quickly. If the complete data cannot be delivered quickly enough, you are still able to scroll through the available content while the data is fetched in the background.

Buttons can be colorized programmatically

We refined the support for background colors on buttons. You can now call button.setBackground(redColor) to change the background color of the button. The change in color applies not only to the default state but to all button states such as pressed, disabled, focused etc.

Opening and closing shells is animated

In the Android client we map an SWT shell to behave similarly to an Android activity. Multiple activities can be stacked on top of each other and the user is able to switch between them with the back button on the device. The creation and destruction of an activity is animated according to the current device. We play these very same animations on shells when they are created or closed. On a Samsung Galaxy S2 (Android 2.3.x) a fly-in animation is performed whereas on a Samsung Galaxy Nexus (Android 4.0.x) a fade/scale animation is applied.

Text widget tooltip is displayed in text field

If a tooltip is set on a Text widget we now display the tip inside the Android EditText. You can use this to add hints for completing fields.

Font probing on startup is implemented

When starting a new RAP session we measure the probe strings sent from the server. These probe strings allow the server to categorize the clients according to their text sizes. The server can use cached string sizes so that it doesn’t have to request that the client re-measure strings cached in a previous session.

UI updates are accumulated to execute in one operation

When a server response triggers UI changes, we now gather all these changes and execute them altogether. Previously, we applied the UI changes on the fly which resulted in incremental changes to the UI. The new approach creates a more native-like experience as the UI changes state in one operation.

Client sends a customized HTTP User-Agent string

The RAP mobile Android client sends a customized User-Agent string. It contains the Android version, information about the device and the RAPmobile client version. Example: Android/4.0.2,14 (samsung; Galaxy Nexus) RAPmobile/0.5.3

Tags: android, new and noteworthy, rap, rap mobile

A few months ago my colleague, Ralf Sternberg, wrote an article on “how to access a huge dataset with the web browser“.  Now, if it’s possible to access very large datasets with a browser, wouldn’t it be really cool to access it in the same way with mobile devices?

As you may have heard, we launched RAP mobile two days ago. And, we did just that. With RAP mobile you can access exactly the same dataset with exactly the same code as in Ralf’s post. The dataset contains over 500,000 emails totaling over 2GB of space. Check out the screencast below and the source code on github.

What I find intriguing about this framework is that it is fast. There is no data on the phone. The information displayed in the UI is retrieved asynchronously from the server while the user is scrolling through this enormous set of data. The native iOS client takes care of the proper preloading, caching and memory management.

Tags: android, enron, iOS, rap, rap mobile

Industry experts have predicted that mobile computing is going to have a huge impact on the software industry. I agree. That’s why we asked ourselves if OSGi, RAP and Eclipse RT can help overcome some of the challenges in mobile app development.

Some of the most common problems involved in mobile development include dealing with multi-platform, security and maturity of the available platforms. But does multi-platform really matter with iOS breaking adoption records? I am sure that Google and Microsoft believe that their platforms will become breakthrough successes as well. While no one can make a definitive statement about their future success, I don’t think that anyone would bet a fortune on their failure either. This leaves us with three options for addressing multi-platform: HTML5, development for each platform or making a bet on which will be the most successful.

HTML5 is great technology – not only for mobile – but there is a growing body of lessons learned the hard way. Our own experience revealed that it is easy to get started with HTML5 and that the state-of-the-art JavaScript libraries look really great. But when it comes to running and using the apps the excitement mostly turned into disillusion. The other two options did not seem like good solutions for us, so we decided to add another option: RAP mobile.

RAP mobile gives us some key advantages over the alternatives. First, it allows multi-platform development in Java. It uses the iOS and Android native widget toolkits for rendering the user interface with optimal performance and native look and feel. And, it provides a mature and Open Source platform for writing and deploying business applications on standard JEE servers. It also provides a solution for common data security concerns with mobile devices.

Today we launched the RAP mobile developer preview program and the RAP mobile project site. If you are curious about how RAP mobile works and what it has to offer visit http://rapmobile.eclipsesource.com.

Tags: android, eclipse, html5, iOS, mobile, rap, rap mobile

In the RAP framework, the widgets in a website are remotely controlled by the web server. The server does this by sending messages to the client in response to Ajax requests. Until now, those messages used to contain proprietary JavaScript that has been evaluated by the browser. Apart from the drawbacks of using eval to process server responses, this tightly couples RAP to its default browser client. The messages were so specific that only this client could understand them.

One of our goals for RAP 1.5 is to open the framework for alternative client implementations. After all, the messages from the server contain precise rendering commands that are not at all specific to JavaScript. Commands like “create a button with text ‘Ok‘, set its size to 190x25px, and place it at pos (23,42)” or “change the text color of the label with id ‘w47‘ to ‘#ff0000‘” can be rendered by any client that is able to create and manipulate widgets. It doesn’t have to be a JavaScript client, also clients written in other languages like Java or Objective C can implement it. Clients can render widgets with any UI technology, be it SVG or even a mobile device’s native widget set.

To allow for those cases, we exchanged the communication format with a simple predefined format based on JSON. With the M4 build published today, all responses from a RAP server are now plain JSON. This also makes the debugging much easier, since developer tools like Firebug display the structure of a message.

When designing the protocol, we took great care not to limit the exchange format to widgets. Instead, we created a generic synchronization protocol for any kind of objects. Objects are identified with a unique id, and every operation is related to a target object that is referenced by its unique id. There are different types of operations: one to create an object, one to destroy it, one to change some properties on an object, etc. Every message from the server contains a list of operations, besides some meta information.

You’ve guessed that we already have some prototypes for alternative RAP clients in progress. We’ll write about them soon…

Tags: eclipse, juno, new and noteworthy, protocol, rap

Consider this:

I measured the time needed to create 200 Buttons in RAP 1.4 and RAP 1.5M3, and it shows a considerable performance boost (at least for the browsers i tested). One reason for this is that we changed from quirksmode to standard rendering in IE9, which among other things, finally allowes us to use its new HTML5-features (in this case SVG and CSS3). I expect another little boost with IE10, which has even more CSS3 support.

However, what i did not expect was a significant improvement in any other browser, in this case Google Chrome. This is likely due to the implementation of the JSON-based RAP-protocol. It remains to be seen how this develops, as work on the protocol is still going on. Currently eval() is used to parse the JSON. In the final release we will probably use other methods, such as the native JSON-parser present in many modern browser. Older browser may gain only little or no performance.

What is really awesome though is the improvment of the GC/SWT-Canvas performance in IE9 (and only IE9). Drawing in browser (without any plug-ins) used to be a real pain. While other browser adopted the HTML5-Canvas and SVG standard very early on, Microsoft stubbornly stuck to its horribly old VML implementation, making my work needlessly hard. One of the main problems with VML is that it gets exponentially slower the more elements you draw, from about 200 elements on it’s almost painful to watch. But this is 2011, HTML5 is all the buzz, and even MS could no longer ignore it. IE9 now has a decent HTML5-Canvas implementation that we use in RAP 1.5, and it shows:

The fine print:
These results were achieved on my Windows 7/64bit Intel i5 2,4 GHZ laptop. No other systems or browser were tested. Measurement was done using JavaScript. The 32bit version of IE9 was used. I did only 3 iterations each, but the deviance was relatively small. The results in the final RAP 1.5 release my be very different due to ongoing development. You can check out the code i used here.

Tags: canvas, CSS3, html5, IE9, Internet Explorer, rap

Update 2: The new interfaces have been renamed again in RAP 1.5M7. Please refer to this post for the details and check out the updated code example.

Update: APIs have changed a bit meanwhile, so I updated the code below accordingly. Entry points are now registered by path, and JEE_COMPLATIBILTIY has become the default mode, which makes the main loop obsolete in this kind of applications.

RAP is well known as an “RCP for the web browser”, including workbench, extension points, and all that stuff. Indeed, one of the greatest features of RAP is its ability to reuse RCP code in web applications. But did you know that you can also use RAP’s widget toolkit (RWT) to create simple web UIs for your applications, without the heavy weight Eclipse UI stack?

With RAP 1.5, you can now simply include RWT in any OSGi application. You only need two bundles: org.eclipse.rap.rwt (the RAP widget toolkit itself) and org.eclipse.rap.rwt.osgi which integrates RWT with the OSGi HTTP service. There are no tie-ins with Equinox anymore, thus RAP also works with other OSGi containers.

To create a UI with RWT, you have to implement the interface IEntryPoint, here’s a simple example:

  public int createUI() {
    // Create a maximized top-level shell without trimmings that represents the main "page"
    Display display = new Display();
    Shell page = new Shell( display, SWT.NO_TRIM );
    page.setMaximized( true );
    page.setLayout( new GridLayout() );
 
    // Create contents of main shell
    Label label = new Label( page, SWT.NONE );
    label.setText( "Hello" );
    Button button = new Button( page, SWT.PUSH );
    button.setText( "World" );
 
    // Open the top-level shell and run the main loop to process events
    page.layout();
    page.open();
    return 0;
  }

Now what’s new is that, instead of registering this entry point with an extension point, you can now implement the new ApplicationConfigurator interface like this:

  public void configure( Context context ) {
    context.addEntryPoint( "/simple", SimpleEntryPoint.class );
    context.addBranding( new AbstractBranding() {
      @Override
      public String getServletName() {
        return "simple";
      }
      @Override
      public String getTitle() {
        return "Simple RWT Example";
      }
    } );
  }

When this implementation is registered as an OSGi service, you can access the UI with a web browser:


You can check out the example project example.rwt.simple from my rap-helpers repository on github. Please note that for this example to run you need declarative services in your target platform, which are not included in the RAP 1.5M1 target but in the latest nightly build. Also be aware that the new API is still provisional and may change again until the final release.

Kudos to Frank Appel, who contributed the new OSGi integration. He has a more detailed introduction to the new OSGi integration and examples for configuration in his blog. BTW, Frank and me plan to demo the possibilities of this approach in our talk Dynamic web applications with OSGi and RAP at the EclipseCon Europe – vote for it if you’re interested!

Tags: eclipse, milestone, new and noteworthy, OSGi, rap

The Enron Corporation was the American energy company that was involved in accounting fraud which led to the Enron scandal in 2001. During the investigation, large parts of the company’s email conversations were published. The result is that a huge, real-life data set including more than half a million emails from 150 Enron executives came into the public domain.

I thought that this data would be a good example to show the ability of the new Tree widget in RAP to display huge datasets.

It’s clear that you cannot create half a million UI elements in a browser without running out of memory. Neither can you load the entire dataset (> 2GB on disk) into memory on the server. You need a mechanism to load and display data on demand.

As of this week, the RWT Tree widget has full SWT.VIRTUAL support, i.e. it is capable of creating Tree items only at the moment they become visible. This feature is used by the JFace TreeViewer to request data from a lazy content provider on demand.

So, in order to make a complex data set accessible with a web UI, you just need to write an ILazyTreeContentProvider implementation. That’s about one screen of Java code, mostly copied from a JFace snippet. That’s all.

Check out the example on our online demo (navigate to the tab called Complex Data). The source code of this demo page is available on github.

Full SWT.VIRTUAL support for the Tree widget is available in CVS and will be part of RAP 1.5M1.

Tags: ajax, new and noteworthy, rap

First, a bit of news for developers following the Virgo project:  The release day for Virgo Maya is getting closer[1] with the successful RC1 release a few weeks ago.

Meantime, in this blog post I’ll describe another way of running RWT (the RAP Widget Tookit) based applications on the Virgo Jetty Server. I want to use Virgo’s RFC66 support to deploy web applications in OSGi.
The RFC66 Web Container specification creates an open standard that enables developers to deploy WAR files on OSGi. With a few modifications (see below) it is possible to deploy an RWT standalone application into an RFC66 container like Virgo.

Note: In addition to using the HttpService described here[2] with RAP 1.5 you can register RWT directly with an OSGi HTTP service. We’ll describe this in a follow-up post.

To extend Virgo you need to:

1. Get a Virgo Jetty Server Release Candidate[3].
2. Install our extension of Virgo as suggested here[4] into /repository/ext.

Note: You can get a patched RWT bundle here that  supports RFC66 deployment of RWT applications and the plan here. The Virgo deployment plan describes all bundles needed to support RWT applications in Virgo.

Copy the two downloaded artifacts into repository/ext:

~virgo-jetty-server> ls -1 repository/ext/*rwt*
repository/ext/org.eclipse.rap.rwt-1.5.0.plan
repository/ext/org.eclipse.rap.rwt_1.5.0.201108081102.jar

Next I added our RWT extension to the initial Virgo artifacts. This is configured in
config/org.eclipse.virgo.kernel.userregion.properties. We simply add our plan:

initialArtifacts=repository:plan/org.eclipse.virgo.kernel.userregion.springdm,\
         repository:plan/org.eclipse.virgo.jetty.web,\
         repository:plan/org.eclipse.rap.rwt

That’s all that has to be done on the Virgo side. If you start Virgo Jetty Server you should
see the extension starting properly:

[2011-08-08 12:23:45.909] system-artifacts              Installing plan 'org.eclipse.rap.rwt' version '1.5.0'.
[2011-08-08 12:23:47.626] system-artifacts              Installing bundle 'org.eclipse.rap.rwt' version '1.5.0.201108081102'.
[2011-08-08 12:23:47.663] system-artifacts              Installed bundle 'org.eclipse.rap.rwt' version '1.5.0.201108081102'.
[2011-08-08 12:23:47.665] system-artifacts              Installed plan 'org.eclipse.rap.rwt' version '1.5.0'.
[2011-08-08 12:23:47.725] system-artifacts              Starting plan 'org.eclipse.rap.rwt' version '1.5.0'.
[2011-08-08 12:23:47.729] system-artifacts              Starting bundle 'org.eclipse.rap.rwt' version '1.5.0.201108081102'.
[2011-08-08 12:23:47.734] start-signalling-2            Started bundle 'org.eclipse.rap.rwt' version '1.5.0.201108081102'.
[2011-08-08 12:23:47.737] start-signalling-2            Started plan 'org.eclipse.rap.rwt' version '1.5.0'.

Because an RWT standalone application doesn’t know about OSGi classloading, I thought that one solution might be to use buddy classloading. First, I enabled buddy classloading in org.eclipse.rap.rwt.

Bundle-SymbolicName: org.eclipse.rap.rwt
Bundle-Version: 1.5.0.qualifier
...
Eclipse-BuddyPolicy: registered

Then I registered the RWT application com.eclipsesource.sovereign.swt.layout.web as a buddy:

Bundle-SymbolicName: com.eclipsesource.sovereign.swt.dialog
...
Require-Bundle:
 org.eclipse.rap.rwt
Export-Package: com.eclipsesource.sovereign.swt.dialog
Eclipse-RegisterBuddy: org.eclipse.rap.rwt
Web-ContextPath: /rap

Note: In the MANIFEST.MF of the web bundle we specified the context path to “/rap”.

Next I setup the RAP web application. The web.xml almost looks like that of a standard RWT standalone application. For more details please go to the RAP Wiki [5]:

<context-param>
  <param-name>org.eclipse.rwt.entryPoints</param-name>
  <param-value>com.eclipsesource.sovereign.swt.dialog.SwtDialogEntryPoint</param-value>
</context-param>
<listener>
  <listener-class>org.eclipse.rwt.internal.engine.RWTServletContextListener</listener-class>
</listener>
 
<servlet>
  <servlet-name>rwtDelegate</servlet-name>
  <servlet-class>org.eclipse.rwt.internal.engine.RWTDelegate</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>rwtDelegate</servlet-name>
  <url-pattern>/</url-pattern>
</servlet-mapping>

You’ll see an additional section for the RWT resources:

<servlet>
  <servlet-name>rwtResources</servlet-name>
  <servlet-class>org.eclipse.jetty.servlet.DefaultServlet</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>rwtResources</servlet-name>
  <url-pattern>/rwt-resources/*</url-pattern>
</servlet-mapping>

Now I was ready to deploy my RAP application. I simply copied the webbundle into Virgo’s pickup folder.

Note: You can get the sample RAP webbundle here.

[2011-08-08 12:25:34.421] fs-watcher                    Hot deployer processing 'CREATED' event for file 'com.eclipsesource.sovereign.swt.dialog_0.1.0.201108081127.jar'.
[2011-08-08 12:25:34.476] fs-watcher                    Installing bundle 'com.eclipsesource.sovereign.swt.dialog' version '0.1.0.201108081127'.
[2011-08-08 12:25:34.486] fs-watcher                    Installed bundle 'com.eclipsesource.sovereign.swt.dialog' version '0.1.0.201108081127'.
[2011-08-08 12:25:34.492] fs-watcher                    Starting bundle 'com.eclipsesource.sovereign.swt.dialog' version '0.1.0.201108081127'.
[2011-08-08 12:25:34.494] start-signalling-3            Started bundle 'com.eclipsesource.sovereign.swt.dialog' version '0.1.0.201108081127'.

And the application is available at localhost:8080/rap

[1] Virgo 3.0 (Maya) Release Candidate 1
[2] Running RAP on Virgo
[3] Milestone Downloads
[4] Extending Virgo with a HttpService
[5] How do I use an RWT standalone application in Tomcat

Tags: OSGi, rap, rwt, virgo

Have you ever heard about RWT standalone?  RWT standalone applications use the widget toolkit of RAP called RWT for their user interface.  These applications can be standard Java applications with no need to create an OSGi based application.

For Java applications it can be quite challenging to find the required dependencies but Maven can help here. And, to make the life easier for RWT standalone developers, we contributed the RAP bundles and the dependencies needed for a RWT standalone application to the Maven Central Repository. To find the RAP bundles in the Maven Central Repository just search for “org.eclpse.rap”.

To try it yourself,  I recommend that you download the latest Eclipse for RCP and RAP Developers package from here. Then you can install the Eclipse Maven Integration into your IDE from here.  After that you can import the example project into your IDE. The example project contains a launch configuration which you can start with the RWT-Launcher included in the RCP and RAP Developers package.

Tags: indigo, maven, OSGi, rap