We are happy to announce another preview release of RAP mobile. Version 0.5.8 adds support for even more widgets on the Android side while improving stability and performance on iOS and Android.

The new release brings improvements to the mobile client side but RAP itself has undergone some minor changes as well and we highly recommend that you update your target definition. The changes will also impact your server-side code slightly as the wording of some RAP classes has been refined.

Most notably the ApplicationConfigurator is now called ApplicationConfiguration and the ApplicationConfiguration has been renamed Application. Simply replace the names in your code and organize the imports.  You will also need to update your dynamic service declaration which now provides an org.eclipse.rwt.application.ApplicationConfiguration implementation. For more details check the great post from Ralf.

And now for the new and noteworthy features of RAP mobile. If not noted otherwise all features described here are available on Android and iOS.

New and Noteworthy

Support for the SWT Group widget

The Android client now supports the SWT Group widget. The appearance of the groups is derived from the Android holo theme with its simplistic title and horizontal line. In addition to group.setText() you can also use group.setForeground() to colorize the title and horizontal line.

Support for right-click via long-press

The right-click is a common ui metaphor on the desktop but has no clear parallel in the mobile space. In an SWT application the right-click is usually used to open a contextual menu. The RAP mobile framework therefore uses the method Control.addMenuDetectListener() to register a listener that is activated when the user long presses on an item.

Entry point discovery mechanism

RAP mobile supports a special mechanism to help you find the available entry points configured for an Application. You can append the special identifier “/index.json” to your url, which delivers a JSON document, listing all the available entry points. The RAP mobile client uses this list to let you choose the app to start. As part of that feature we also simplified the Android start activity as you can see in the screenshots to the right. On iOS the discovery menu is activated by doubletapping on the status bar at the top.

Client side caching of images

Up until this RAP mobile for Android release an image has been loaded from the server every time it was requested. We have now integrated client-side image caching on Android as well which greatly reduces the bandwidth and power requirements when an image is requested multiple times. Try out the “/virtual-tree” demo which displays the same icon dozens of times.

Improved handling of server session timeout

Since the state of a RAP mobile application is bound to a session on the remote server, there is always the possibility of a session timeout. We’ve recently improved this (expected) behavior so that you can now restart your session from the message dialog.

Android Specific

Enhancements and Bugfixes

• Toolbar has a fixed height
• ScrolledComposite supports simultaneous horizontal and vertical scrolling
• Shells now have title support for setting text and icon

Tags: android, iOS, rap mobile

Whenever we talk about server-side apps and RAP mobile, one topic always comes up: how to access native functionality like Geolocation or the Camera. With this post I want to show you how we access this functionality on the server-side. At writing, we’ve implemented Geolocation Support, and more additions are planned for the near future.

I have to point out one thing first.  When you take look at RAP mobile from a very abstract view, it is nothing more than an object synchronization mechanism. That is, if a button (or any other widget) is created on the server it also needs to be created on the client. This is exactly the same for native functionality. When the server needs the location of the client it has to tell the client that it needs the location. Then, the client has to tell the server the location and this cycle starts over again. The challenge in this approach is to hook the location to the right session. Fortunately, RAP’s server side has solved these issues a long time ago, and it’s pretty easy to hook this information together.

One issue that remains is that SWT has no API for native access because it was made for the desktop. So, a new API is required that needs be an abstraction for all devices. But wait a minute – this sounds like a well known problem that has been solved already. I’m referring to Phonegap/Cordova. This technology created a JavaScript abstraction for accessing native functionality within HTML5 Apps. And, IMHO, these guys did a really great job and there is no need to reinvent the wheel. We decided to take the Phonegap API as a template and created a very similar Java API. Our first result is the Geolocation API which is located in the RAP mobile server code. As mentioned in previous posts, everything on the server side is open source, including this API. The RAP mobile server code is located in the com.eclipsesource.rap.mobile*.jar and is included in the demos target. You can also take a look the Geolocation API here at github.

We have created a demo for the Location API, which you can see in the videos linked below. The source code for this demo is also located on github. To conclude, I can proudly say that with RAP mobile it’s now possible to access the Geolocation API of iOS and Android from Java by writing the code only once!

Tags: android, geolocation, iOS, rap, rap mobile, server-side apps

Once again we are releasing a new version of RAP mobile. This latest release 0.5.7 brings with it a very cool new feature that we call the “Client Canvas”. This extension of the classic SWT Canvas allows you to draw freehand on your screen with your stylus or even your finger.

Additional Features and API

Client Canvas

The client canvas provides you with basic freehand drawing options, allowing you to sketch with your stylus or your finger.  Like a regular drawing program, you can choose your color, brush size and opacity. And, you can step through the history of your drawings to undo/redo certain steps. To implement this feature we built upon the SWT Canvas object that allows us to change the pen properties via the established Canvas API. To get started with drawing you’ll just need to instantiate the com.eclipsesource.rap.mobile.widgets.ClientCanvas instead of the regular SWT Canvas. To demonstrate the Client Canvas we have created a sample where you try out a little draw-by-numbers.

Android

Browser

The RAP mobile Android client is catching up with iOS on browser support. We now support the SWT Browser widget, allowing you to show full websites or custom HTML snippets inside your RAP mobile application. We also support the Browser.evaluate() and Browser.execute() methods to execute javascript in the browser on the Android device and to make it possible to send execution results back to server. The screenshot to the right shows examples that display a full website, an HTML snippet and the execution of a custom javascript function.

Support for various SWT Shell style flags

SWT offers many ways to customize the appearance of a shell via the style flags passed to the Shell constructor. These flags are also important to create SWT Dialogs. We now support the additional SWT shell styles TITLE, BORDER and *_MODAL. The following screenshots demonstrate the various style combinations.

Bugfixes

We are constantly working towards a high level of stability and solid performance, and in this release, we squashed some bugs which deserve special mention:

• Fixed an issue where selecting elements inside a vertical ScrolledComposite was not possible
• The GraphicalContext used android APIs not available on the supported basline version android 2.1 (API level 7).

iOS

You’re probably already enjoying the browser support on our RAP mobile iOS client, and can now also take the Client Canvas for a test drive.  Two other things that you might notice in this release are a new UI hint to show how to enter the developer SystemMenu and improvements to modalShell rendering and animation.

Tags: android, browser, canvas, dialog, iOS, mobile, rap, rap mobile, shell

In my last post I gave you an overview of server-side apps and how they relate to RAP mobile. In this post I want to dive into some technical details. I’ll assume that you are a Java programmer and that you are familiar with servlets and tomcat. Not necessary but really helpful is some knowledge of OSGi.

So, let’s get started. To create RAP mobile Applications you’ll write Java Code only. This of course means you will have some dependencies. The basic dependencies that result from using RAP mobile are two open source jar files. One is the widget toolkit which includes the SWT API for writing UIs and some other server stuff. The widget toolkit is part of the Eclipse RAP project and is called RWT (RAP Widget Toolkit) and it’s jar file is named org.eclipse.rap.rwt_VERSION.QUALIFIER.jar. The second jar file is the RAP mobile jar itself. It’s called com.eclipsesource.rap.mobile_VERSION.QUALIFIER.jar and contains additional API and other mobile-related stuff. Of course these two jars have dependencies too. These are javax.servlet, org.json and a few others. They are included in the RAP mobile target (see the target definition file in the examples) and can also be consumed manually or via Maven.

Once you have set up your Java Project and dependencies (you can use this template) the first thing you’ll need to write is an ApplicationConfiguration. It can look like this:

public class Configuration implements ApplicationConfiguration {
 
  public void configure( Application application ) {
    Bootstrapper.bootstrap();
    application.addEntryPoint( "/my-app", MyEntryPoint.class, null );
  }
}

You may notice that the really interesting stuff happens in the configure method. This method will be called by the framework and is used to configure your environment. You’ll use the configure method most often to add IEntryPoints. An IEntryPoint marks the entry point of your UI code and can look like the following MyEntryPoint.  (If you want to go into more depth on the UI Code,  take a look at the SWT resources and the examples.)

public class MyEntryPoint implements IEntryPoint {
 
  public int createUI() {
    Display display = new Display();
    Shell shell = new Shell( display, SWT.NO_TRIM );
    shell.setLayout( new GridLayout( 1, false ) );
 
    Button button = new Button( shell, SWT.PUSH );
    button.setLayoutData( new GridData( SWT.BEGINNING, SWT.CENTER, false, false ) );
    button.setText( "Hello World" );
 
    shell.open();
    return 0;
  }
}

In the configure method of the ApplicationConfiguration you need to connect the entry point to a path, e.g. “/my-app”. This will make your application available using this URL http://SERVER:PORT/my-app. Next, you need to hook your ApplicationConfiguration Implementation to the framework.

At this point you need to make a choice between two RAP mobile operating modes. The easiest mode to use is RAP mobile together with plain servlet technology. For this variant you’ll write a web.xml to hook the framework to your application, similar to the example below:

<!--?xml version="1.0" encoding="UTF-8"?-->
 
org.eclipse.rwt.Configurator
my.Configurator
 
org.eclipse.rwt.engine.RWTServletContextListener
 
    rwtServlet
    org.eclipse.rwt.engine.RWTServlet
 
    rwtServlet
    /*

The more advanced operating mode is to use it together with OSGi, which I prefer because I like modularity much. But this requires that you have basic knowledge about OSGi and the service model. Hooking the ApplicationConfiguration in this scenario is pretty straight forward. All you have to do is register your implementation as an OSGi service and starting one more bundle called org.eclipse.rap.rwt.osgi. In an activator it can look like this:

public class Activator implements BundleActivator {
 
  private ServiceRegistration registration;
 
	public void start(BundleContext bundleContext) throws Exception {
	  Configuration configuration = new Configuration();
	  registration = bundleContext.registerService( ApplicationConfiguration.class.getName(),
	                                                configuration,
	                                                null );
	}
 
	public void stop(BundleContext bundleContext) throws Exception {
		registration.unregister();
	}
 
}

Now you can simply launch your OSGi framework – but, don’t forget the HttpService (it is in the org.eclipse.osgi.services bundle).  And now, the fun part. Point your mobile client to the url of your server and enjoy the mobile UI which should look like the advanced one below!

If you haven’t tested the clients already, don’t hesitate to request them here. We have also created some examples which can be found at github.  In upcoming posts, we’ll provide a more detailed tutorial for both operating modes.

Tags: android, iOS, rap, rap mobile, server-side apps

You may have read the title of this post and are asking yourself, “what the heck is a server-side app?”. Let me try to explain. When an app works with sensitive data there is always a security risk in storing the data on the device. If the device is lost or stolen the sensitive data is lost or worse, no longer confidential.  A server-side app can prevent this. Data is stored on the server and the client displays and manipulates it, but no data is stored locally. I think you’ve got it: server-side apps are nothing more than a thin client approach adopted to the mobile/app sector.

When you’re confronted with this problem, you’ve probably either started by designing the server application or are porting an existing server application to be accessible by mobile devices. So, your next step will be to plan how to visualize the server-side app on the clients. The most common approach is to build an App for iOS, Android and so on and render the data in a more or less generic UI. You’ll invest a lot of effort in creating and securing the communication between server and client to get your server-side app ready. And, you’ll have joined the club of developers, including me, who have reinvented the wheel once more.

This is the problem we are solving with RAP mobile. RAP mobile consists of a server and generic clients, with the server based on standard servlet technology and a kick-ass OSGi integration. The server’s open source and hosted within the Eclipse RAP project. The generic clients currently exist for iOS and Android, and in both cases, all the clients do is talk to the server and display a UI. But, every other server-side app does this too. What’s special here?

With usual server-side apps you have to couple the client to the server. The data and message contents are defined and the client needs to understand them, resulting in a more or less a tight coupling between these two all created by yourself. With RAP mobile, the work on communication is done by the framework for you. The server produces JSON based messages that the RAP mobile clients can understand. The messages contain information like “Create a Window, create a Button, set the text of the button to …”, (I think you get it). When you sketch this out it looks like this:

This approach allows us and you (because the server’s open source) to come up with any client as long as it understands JSON. I think the major benefit RAP mobile brings is that you can concentrate on the server-side and your domain requirements, instead of programming a generic UI for every platform.

When you’ve read this far you might now be asking yourself, “When everything is on the server side and I don’t have to write a native UI for the mobile devices, eg. in Objective-C, how does the native UI get created?”  And now the Eclipse open source project comes into the game with Eclipse RAP. RAP provides a widget toolkit which is based on SWT, which means that you write your UI completely in Java. When RAP was created the goal was to enable a developer to create a desktop and a web application with the same code base. As a result, the RAP developers solved problems like multi-user awareness, clustering support, styling and many many more. In the meantime, we’ve gone even further and extended this idea to the mobile space. (And, we’re making good progress, because on the server side we’re working with a mature technology.) In short, it means that when you write a RAP mobile app for iOS, Android and so on, you don’t have to worry about the native client, but you can write your UI in plain Java and run it in the server.

If you’re hungry for more , visit the RAP mobile website, watch the demo videos, clone the examples and run your own app. To join the developer preview, you’ll need to complete a short form but, in a few months we will move into an open beta. I hope you will have fun with this as much as I do. Any feedback is welcome.

Tags: android, iOS, rap, rap mobile, server-side apps

RAP mobile is progressing. In this post we’d like to give you a quick update on the latest features in the RAP mobile clients for iOS and Android.

Android

Graphical Context

For drawing arbitrary graphical elements in a widget, RAP mobile now supports the Canvas and GC (graphical context) API. This enables a variety of options for designing individual UI elements. The graphical context also lays the foundation for the development of custom widgets.

iOS and Android

Non-UI Objects

As we all know, mobile devices are equipped with local sensors and other hardware-based capabilities. With the current release, RAP mobile is ready to handle client side non-UI objects to model the local capabilities of your phone or tablet. In our first example, we developed a geolocation object to support the GPS receivers in mobile devices. In an upcoming blog post, we’ll explain the additions to the API in more detail.

Demos

The latest demos on the RAP mobile website give you a quick look at our latest development efforts. The demos contain videos of both the iOS and the Android platform as well as some code snippets. Follow the links to GIT hub if you want to take a look behind the scenes.

New demo “Dashboard”

We have created a new interactive demo called “Dashboard”. Derived from an open information project from a German publisher, the demo graphically displays information about delays in national rail traffic.

New demo “Geolocation”

The “Geolocation” demo uses RAP mobile’s new object handling feature to interact with your mobile device’s hardware and determines your current location.

Tags: android, iOS, rap, rap mobile

In this post we’d like to give you a quick overview of the latest in RAP mobile, version 0.5.5.

Android

Support for UI Callback

The UI callback mechanism enables a RAP client to automatically update the UI without user interaction. With this feature we can support progress indicators or updates to displays that are triggered by events on the server side. Watch for examples in the upcoming releases.

Label Alignment

Labels and buttons now follow the SWT alignment styles SWT.LEFT, SWT.LEFT, SWT.CENTER.

Bug fixes

• Rotating a device now correctly re-positions a scrolled composite.
• The vertical alignment of text in a label is now updated correctly when a relayout is triggered.

iOS

Automatic Discovery of Entry Points

To make it easier to access the different entry points of a RAP mobile application running on the server, the iOS client now supports automatic EntryPoint discovery. To list all available EntryPoints, navigate the native client to the server url followed by a “/index.json”. The following URL on the RAP demo server provides you with an example: http://rap.eclipsesource.com/demos-0.5.5/index.json

Property to control idle display

You can now choose to have the display automatically switch off in idle mode or remain on.

Bug fixes

• Animated widgets are now more stable (they sometimes “jumped” when the animation was playing).
• We’ve made significant improvements to memory management.
• TabFolders now support the style argument SWT.TOP.
• We’ve improved reliability when reloading a session.
• Centering TITLEs in a ToolBar is now easier – the SWT.SEPARATOR is no longer required.

Tags: android, iOS, rap, rap mobile

In this post we’d like to update you on the latest news in the RAP mobile developer preview.  We’ve just released Version 0.5.4, marking the beginning of a simultaneous release schedule across all our mobile clients. Here is what we think are the most interesting new features.

Android

The Startup page provides shortcuts to access the demo applications

Previously, to access the application demos you needed to manually update the connection urls. With this release you can easily jump into a particular demo when you start the application. Alternatively, you can input  a RAP application server URL to access another application. Of course, this “frontend” is designed to showcase the RAP mobile technology but in a production scenario you would jump right into your own application.

Added support for the Toolbar widget

The android client adds support for the org.eclipse.swt.widgets.ToolBar widget. You can easily place toolbars on any Composite and add ToolItems to it. We currently support the ToolItem styles PUSH and SEPARATOR but more types are planned for the near future. As with all our widgets we closely resemble the holo theme even on older Android 2.x devices. Newer features like a fadeout animation when pushing a tool item are only available on newer Android versions.

Changing the bounds of a widget can now be animated

You can now apply client side animations to a widget by setting the special custom variant “ANIMATED”. Enabling this property will animate all subsequent changes to the bounds of the particular widget. So for example changing the order of widgets on a composite would nicely slide the widget to its new target position. Also changing the width or height of a widget would animate the change in size. To set the custom variant you need to call:

control.setData( WidgetUtil.CUSTOM_VARIANT, "ANIMATED" );

Updated client to an optimized RAP protocol

The underlying communication protocol between RAP server and clients has been optimized further. The amount of data transferred has been reduced by almost 30%, which results in smaller protocol messages and thereby shorter load times. In fact, the messages now often fit into one “regular” sized TCP package thus requiring even less bandwidth.

Set hints in Text fields via setMessage()

The content hint in a Text field can now also be set via the SWT method Text.setMessage().

iOS

Retina Display, GEOLocation, plus all of the above

Ditto on the features listed for Android – these features and more, are available in the latest iOS client. We’ve added support for the recently released iPad Retina display as well as support for the GEOLocation API.  You’ll find better error handling with support for the new RAP Server/Session timeout as well as better MulitCore performance with GrandCentralDispatch.  And, the latest version is still a svelt 0.5 MB.

Shell animation

You might have already worked with this feature in the previous version of RAP mobile but we’d like to say a little more about this for those who haven’t started working with it yet. The client provides support for the UI paradigms found in most mobile applications, in our case through SWT.Shell. These include fullscreen, sliding areas, user actions and alert/notification dialogs. In an upcoming post we’ll go into detail about how these behaviors look and how you can integrate them into your app.

Tags: android, iOS, rap mobile

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

This blog post marks the start of an ongoing series that will highlight some of the top features of RAP mobile from an Android developer’s perspective. To kick things off we’ll look at the most visible feature: the application’s UI.

When dealing with Android development we are faced with an endless array of devices from many different manufacturers. Inherently that is a good thing as there is most likely a device tailored for everyone’s needs. From a developer’s point of view this diversity in devices can be challenging.

In order to differentiate a device from the competition, manufacturers create custom UI modifications in the form of skins. Although these skins can, in fact, enhance the user experience, it means they can also come with a different UI look and feel on every device. The same application can look vastly different on a device from manufacturer A or B. The developer has to go to some lengths to ensure that his intended UI looks the same across all devices.

When developing an application with the RAP mobile framework, we have already done the hard work for you and provide a consistent look and feel across all Android devices. There is no need to implement custom theming if you don’t need it. Your application will look the same on every device. Of course, you can also tailor the look specifically to your application.

An application developed with RAP mobile is based on a port of the new Android 4.0 Holo theme. Your application will already look like the latest Android version even when running on older devices without Android 4.0. We support every machine that runs Android 2.1 or higher.

In the screenshot above you see an HTC Magic (Android 2.2.1), HTC Desire (2.2), Samsung Galaxy S2 (Android 2.3.6) and Galaxy Nexus (Android 4.0.2) – many different forms and sizes with one consistent look.

Not only do you get a modern look for all your applications, you also get a couple of benefits on the application developer side.

• For starters you can choose to base your application on a dark or light Holo theme. This means that you don’t have to customize everything when opting for a darker look.
• Android provides four different “buckets” of screen density. Every graphical element in the default Holo theme is already available in these target densities. When providing application-specific graphics we automatically scale them for you based on the target density.
• Because the application runs server side and we do have knowledge about the theme the client uses, we can easily make assumptions about the size of a widget without actually measuring anything on the client.

In the future we will create more documentation and blog posts with sample code that will show you how you can leverage these features in your projects.

With Android 4.0, Google is forcing manufacturers to bundle the new Holo theme on their devices. This is an excellent step towards having a common base UI but currently things are still troublesome as we are dealing with older devices that make up 98% of the market. RAP mobile allows you to have a good looking base theme today, without having to wait for the industry to move to Android 4.0.

Tags: android, rap mobile, theme, themes