RAP becomes the Remote Application Platform

RAP is approaching its second major release in its 6 year history, and major releases should be accompanied by major new functionality – at least this is our take on versioning.

With RAP 2.0 we are changing the project name from Rich Ajax Platform to Remote Application Platform (RAP as a short name remains the same), so there is something really significant happening. RAP has always been an implementation of the half-object pattern – synchronising the User Interface between a server and its clients. A specialty of RAP is that the half objects are implemented in different languages. The server part uses Java, the browser client is using JavaScript (and HTML5) for implementing the half objects. Recently we added (commercial) clients for Android and iOS providing native widgets to mobile users. The implementations of the clients are using the corresponding languages – Java and Objective-C. With version 2.0 RAP is no longer only an AJAX framework for creating powerful web applications, it is becoming a platform for remote applications independent of the UI technology that renders the client.

Implementing clients in other languages has become possible with the introduction of the RAP protocol, which standardizes the synchronization of objects between the RAP server and its client based on JSON based messages.

The protocol does not only enable clients in other programming languages, it also opens the door to a new class of applications – applications that need to address a wide range of hardware from desktops to specialized devices (e.g. mobile data entry or point of sales solutions). Or applications that require an integration with attached hardware devices. We think that this is a major new achievement for RAP warranting a major release – and a feature that sets RAP apart from other frameworks.

My colleague Ian Bull created a proof-of-concept implementation of a native SWT client. This is interesting because SWT already implements support for 14 platforms. The creation of the proof-of-concept took only a single day using our Android implementation as a template.

RAP windows64 RAP becomes the Remote Application Platform

RAP Cocoa64 RAP becomes the Remote Application Platform

RAP GTK64 RAP becomes the Remote Application Platform

If you want to get your feet wet and implement a client for another platform the only thing you need is the latest milestone build from RAP. If you need help, existing code or a partner for the imiplementation just contact us.

You may also like...

Share this Post

Twitter14
Google+5
LinkedIn
Facebook

Tags

6 Responses to “RAP becomes the Remote Application Platform”

  1. Tom Schindl says:

    So can i sync any object graph between server and client or is it optimized to SWT controls and the client has to have an SWT-like-API implementation?

    More concrete can one do something like Canoo does with https://github.com/canoo/open-dolphin e.g. writing an JavaFX-Client?

  2. Ian Bull says:

    @Tom,
    You could easily write a client in JavaFX (I was debating that last week when I wrote the SWT one). You just need to implement the client side of the RAP Protocol (which is simply JSON). You could implement the client in C# with a MetroUI, or even a C client that uses NCurses.

  3. Tom Schindl says:

    Ian, do I not need both a stub version on the server e.g. SButton where e.g. my action handler is attached to and on the client a CButton which calls out to the FX-APIs?

    I’d really like to take a look at this in conjunction with JavaFX. Hope I have time to play with it soon.

  4. LuisCM says:

    Great post!

  5. Jeeeyul says:

    It’s so cool!

  6. Jochen Krause says:

    Hi Tom,

    In general you can sync any kind of object, you can get an idea how that works looking at the code for camera support (in Tabris). The camera is not an SWT widget.

    https://github.com/eclipsesource/tabris/tree/0.9.0/com.eclipsesource.tabris/src/com/eclipsesource/tabris/camera

    The RemoteObject API will become available in RAP 2.0 M4.

    However, providing an entire widget toolkit for JavaFX based on this infrastructure will be a significant amout of work. Displaying SWT widgets remotely in JavaFX and adding widgets that don’t exist in JavaFX (thats what Ian is talking about) would be much simpler.

6 responses so far

Written by . Published in Categories: EclipseSource News, Planet Eclipse