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

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 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

Already running the latest and greatest Ubuntu with the new unity desktop?
It also introduced a new menu bar and java apps seam to have probs with that. When your eclipse doesn’t want to make use of it check out this post: http://blog.matto1990.com/2011/04/using-eclipse-under-ubuntu-11-04-natty/

Not running the unity desktop yet? Try it in your VirtualBox and follow these steps to enable the 3d support for unity: http://www.webupd8.org/2010/12/how-to-test-ubuntu-1104-with-unity-in.html

In the last few weeks i was confronted with several projects and developers, who were trying to incorporate the scrum process into their project environment. The following remarks will pinpoint some of the problems and challenges several of the projects had and what a possible solution might look like (your mileage may vary).

Upfront i have to say, that i am a strong believer in scrum and its gains. This opinion originates from the fact, that i have worked in scrum projects which turned out very well. Why did they work well? Because they applied scrum!

The Fundamentals

We all know the sentence “yeah, we are an agile team”. And next they present you their fixed road map with milestones etc. The opposite is the “no planning agility”. We just fiddle along on a daily basis. That is not agile either.

I think the sweetspot is where scrum enters the stage. The product backlog dictates your workload and the sprint backlog defines your daily work. What’s the gain? Transparency and flexibility. The two virtuoso every one wants, most people claim and the fewest projects actually have. Lets see what these two words actually mean.

Transparency - Like a glass window transparency has two sides. When looking at the team we want to know what the team is actually working on and what their progress state is. The scrum wall with its small tasks and the sprint burndown is the place to find these information. When looking at the product owner, it is his job to provide a well formed backlog. Well formed means stories with clear scope and manageable volume. From both perspectives you have the ability to intervene when necessary.

Flexibility - Flexibility allows to refocus the course of the development efforts while being way under way. Only after you have finished the current sprint you plan the next one with the stories you need the most. After your project time has elapsed you can be certain that everything that is in your project right now is what you really need. No extras. Just the right features. Admittedly we could miss a few features but that would simply require more man power or more time. Most importantly: the scope is spot on because of constant corrections of the project plan.

So that is great theory. Now on to the problems…

Oh wait. This blog post is getting to long and i have to many points on my list. So lets take a break here and discuss the above until part II is ready.

Are you applying scrum? What are the biggest gains for you?

Tags: Agile, Scrum

A few days ago i gave Google Wave a spin. I was already quite familiar with the conversation features and thought it was time to extend the wave by some custom functionality. I therefore created a robot extension to enrich a wave conversation with some additional functionality. The idea was to fetch details about an eclipse bugzilla bug when a bug is referenced in a wave conversation. To see how that works check out the screencast below (click the image).

The development of the robot was rather straight forward. The robot itself is deployed on the google appengine and communicates with the wave via HTTP REST calls and uses JSON as its language dialect. The communication was encapsulated in a client library which did have some bugs though. Working with the app engine was a joy i must add. Deployment and management of the application was quite cool. Fetching the bugzilla data was also easy as it is able to spill out bug details in XML format.

All in all i am very excited to see how easy it is to provide additional wave capabilities and am hopping that the wave will make its way into every days life. Also the appengine gets a thumbs up from me (at least for such simple tasks as this wave robot). You can fetch the source of the robot project here.

Tags: appengine, bugzilla, robot, wave

In the last blog entry regarding databinding, we learned how to create a custom observable for a DateTime widget. Starting with Eclipse 3.5 there is a new approach to creating custom observables as described by Matthew Hall in the comments to that post. Which ever way you choose, we will now use the observable to showcase another cool databinding feature: Crossvalidation. Crossvalidation was introduced with Eclipse 3.4 and describes the process of validating one IObservable based on the value or state of another IObservable. A classic example is the input  of a date ranges where the start of the period can not be after the end of the period.

As we can see on the screenshot above, the status message informs us of a violated validation constrain. So, how is such  kind of crosscutting validation achieved? First of we need some kind of model, to hold the start and end value. Next we need the two DateTime widgets and the corresponding DateTimeObservableValue. The observables can than be tied to the bean model, holding the start and end values. In order to create a crosscutting validation for the dates, we introduce a custom PeriodValidator extending a MultiValidator, which is in fact an implementation of a ValidationStatusProvider.The MultiValidator lets us implement a validate() method, returning an IStatus corresponding to our validation results. Since we are implicitly implementing a ValidationStatusProvider, the state of our validation can be bound to any party interested in the validation result. Here is the implementation of the PeriodValidator, comparing the start and end date (ignore the shortcomings of the Date class):

public class PeriodValidator extends MultiValidator {

private final IObservableValue start;
private final IObservableValue end;

public PeriodValidator(final IObservableValue start, final IObservableValue end) {
this.start = start;
this.end = end;
}

@Override
protected IStatus validate() {
Date startDate = (Date) this.start.getValue();
Date endDate = (Date) this.end.getValue();
IStatus status = ValidationStatus.ok();

if ((this.start != null) && (this.end != null)) {
     if (startDate.after(endDate)) {
          status = ValidationStatus.error(”The start date has to be before the end date.”);
     }
}
return status;
}
}

As we can see, there is not much magic going on in the PeriodValidator. Lets have a look at the broader context, in which this MultiValidator is applied. The following code demonstrates the overall setup of the databinding. Note how the validation status (wrapped in an IObservableValue) is obtained from the PeriodValidator and bound to the status Text widget.

private void createDatabinding() {

DateTimeObservableValue startObservable = new DateTimeObservableValue(this.dateTimeStart);
DateTimeObservableValue endObservable = new DateTimeObservableValue(this.dateTimeEnd);
DataBindingContext context = new DataBindingContext();

// bind start and end
UpdateValueStrategy modelToTarget = new UpdateValueStrategy(
UpdateValueStrategy.POLICY_UPDATE);
UpdateValueStrategy targetToModel = new UpdateValueStrategy(
UpdateValueStrategy.POLICY_UPDATE);
context.bindValue(
     startObservable,
     BeansObservables.observeValue(this.period,Period.PROP_START), targetToModel, modelToTarget);

context.bindValue(endObservable,
     BeansObservables.observeValue(this.period, Period.PROP_END), targetToModel, modelToTarget);

// bind status
PeriodValidator periodValidator = new PeriodValidator(startObservable, endObservable);
modelToTarget = new UpdateValueStrategy(UpdateValueStrategy.POLICY_UPDATE);
modelToTarget.setConverter(new Converter(IStatus.class, String.class) {

public Object convert(final Object arg) {

if (arg instanceof IStatus) {
     IStatus status = (IStatus) arg;
     return status.getMessage();
}

return null;
}
});

targetToModel = new UpdateValueStrategy(UpdateValueStrategy.POLICY_UPDATE);
context.bindValue(
     SWTObservables.observeText(this.status),
     periodValidator.getValidationStatus(), targetToModel, modelToTarget);
}

The validation status of the period validator is updated everytime any of the DateTime widgets is changed. In turn the validation message is updated to reflect the validation state.

You can download the the entire project containing the sample snippets here.

Also note that you will need to adjust the elements on the classpath. See the .project file for the required libs.

I hope you found these hints valuable and am looking forward to your comments and suggestions.

Tags: databinding, jface, tips

The introduction of the databinding framework in Eclipse 3.3 is with no doubt one of the most useful tools in the hands of the form developer. The ability to transform and validate user input in such a flexible and reusable way is a great enhancement. But where there is light, there is shadow. Sometimes there is just no IObservable available for your target or model object. This blog entry will demonstrate how easy it can be to create a custom IObservable for a DateTime widget.

The DateTime widget represents one value: a java.util.Date. This Date object is the one we want to get and set on the target (target being the UI widget). Therefore we wrap the DateTime in an IObservableValue by extending the AbstractObservableValue class. Essentially an IObservable* offers methods to get and set data, to determine the type of data and to register listeners to be notified of changes. The following code demonstrates a skeleton implementation of an IObservableValue.

public class DateTimeObservableValue extends AbstractObservableValue {

  private final DateTime dateTime;
  Listener listener = new Listener() { ... };

  public DateTimeObservableValue(final DateTime dateTime) {
    this.dateTime = dateTime;
    this.dateTime.addSelectionListener(this.listener);
  }

  @Override
  protected Object doGetValue() {
    // the utility method creates a Date from the DateTime
    return dateTimeToDate();
  }

  @Override
    protected void doSetValue(final Object value) {
      if (value instanceof Date) {
        // the utility method sets the date on the DateTime
        dateToDateTime((Date) value);
      }
  }

  @Override
    public Object getValueType() {
    return Date.class;
  }

  @Override
    public synchronized void dispose() {
    this.dateTime.removeSelectionListener(this.listener);
    super.dispose();
  }
}

The implementation details are not very special. The getValueType() method has to return the type represented by this IObservableValue (which is the type Date). The do methods set and get the Date value. Since the observable has to propagate changes in the DateTime widget as soon as they ocurre, we attach a listener on the DateTime widget to inform any registered IValueChangeListener of the event. The listener implementation looks like the following:

Listener listener = new Listener() {

  @Override
  public void handleEvent(final Event event) {
    Date newValue = dateTimeToDate();

    if (!newValue.equals(DateTimeObservableValue.this.oldValue)) {
      fireValueChange(Diffs.createValueDiff(DateTimeObservableValue.this.oldValue, newValue));
      DateTimeObservableValue.this.oldValue = newValue;
    }
  }
};

In the DateTime listener we inform any interested IValueChangeListener of our DateTimeObservableValue. In order to avoid unnecessary propagation of update events in the databinding context, we compare the last set Date in the IObservableValue with the new value. Next we create a ValueDiff from our new date value and fire the the value change event. The advantage of listening to the changes in the DateTime widget, is that we are able to fire events which are either invoked by the user changing the DateTime widget or by programmatic changes of the IObservableValues wrapped Date.

You can download the full listing of the observable class here: DateTimeObservableValue.zip

As we can see, it is quite easy to write a custom observable for any kind of widget or datastructure, represented by a single value…  So, how do you embed your data in custom observables? Any obstacles you had to overcome? Problems you faced? Share them with us.

Tags: databinding, datetime, eclipse, jface, observable, tips