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.

A while ago, we’ve tried to use JSLint, a tool written by JavaScript guru Douglas Crockford. Unfortunately, this tools produces several thousand warnings on our code base, many of them were not really problems but debatable coding style issues and there was no way to turn them off. JSLint’s lack of customizability recently lead to a fork named JSHint that is going to provide more flexible configuration options.

Like JSLint, JSHint is written in JavaScript, but can be run on the command line using tools like Rhino or JavaScriptCore. I tried JSHint on our codebase with good results using a shell script that runs it on top of Rhino. Unfortunately, checking all our 250+ *.js files keeps my machine busy for 5 minutes and 40 seconds and effectively turns it into a fan heater. This is not because JSHint itself is so demanding, but because for every file, a JVM has to be started, Rhino has to be loaded, then Rhino has to parse and load the JSHint JavaScript library, and then finally, jshint can parse and validate the source file.

Encouraged by the good results I tried to find a solution that doesn’t have this overhead. And as an Eclipse hacker and user, I certainly wanted to integrate the tool into my daily working environment. The result is a simple, yet efficient JSHint Eclipse integration that validates the same bunch of *.js files in less than 15 seconds.

This speedup could be achieved by exploiting the way Eclipse builds projects: It uses the same builder instance to visit all files of the project recursively. That makes it possible to load and configure the JSHint library only once for the entire project and reuse it for all files being checked. Of course, validating all files of a project is only necessary for a full rebuild. During normal work, single files are being validated instantly when they have changed.

Although the configuration options are still somewhat basic, this integration proved to be very helpful already. I thought that it may be useful for others as well and decided to build and publish a first version. It’s available on the jshint-eclipse page. There’s an update site that let’s you install the plug-in right into your Eclipse IDE. If you find the plug-in useful, have ideas for improvements, find a problem or want to contribute, I’m happy to hear about it. To report problems, please use the github issue tracker.

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…

That is, when we want to debug our Object-Under-Test’s real method and the object is a spy. When we try to step into the object’s method we always land in internal Mockito code. After a little reading we can drill deeper but the next landing place is in java.lang.reflect code and so on. To be honest, this is really not the nicest way to debug code. What I want is that regardless of whether I use spies or not, when I step into an object’s method I land directly in this method. In the past my workaround was to set a breakpoint in the test at the method call and in the method itself. This enabled me to stop at the first point and resume the execution until it stops the second time in the method. But there is a much more elegant way. Let’s see how we can do this.

First of all, let’s take a look at an example. The code below shows a simple test from the last Effective Mockito post. The test uses a spy to “pseudo mock” a static method. We set a breakpoint in the line of the isPropertySet call and debug this method. Sadly when doing this we run into the effect described above.

@RunWith( MockitoJUnitRunner.class )
public class MyObjectText {
 
  @Spy
  private MyObject objectUnderTest;
 
  @Test
  public void testIsPropertySet() {
    doReturn( "some runtime property" ).when( objectUnderTest ).getProperty();
 
    boolean isPropertySet = objectUnderTest.isPropertySet();
 
    assertFalse( isPropertySet );
  }
 
}

When using Eclipse there is a very simple way to avoid this called “Step Filtering”. We can add packages or classes to this Filterlist using the preferences. When filters are activated the classes will automatically be skipped during debugging. By setting a filter like the one in the screenshot below we can simply step over the Mockito and reflection code.

If you are not using Eclipse there is probably a similar way to achieve this with your IDE. It would be cool if you would share this tip with us in a comment. Meantime, I hope that Step Filtering is as helpful to you as it is for me.  Finally, I want to thank Fluffi and Frank for getting me to dive into this.

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

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();
    while( !page.isDisposed() ) {
      if( !display.readAndDispatch() ) {
        display.sleep();
      }
    }
    display.dispose();
    return 0;
  }

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

  public void configure( Context context ) {
    context.addEntryPoint( "default", 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!

Luckily there is a lifesaver called Declarative Services. (For those of you who are familiar with declarative services, skip to the next paragraph.) The OSGi declarative services (ds) are specified in the OSGi compendium so they are standardized. It’s just a component framework on top of OSGi services. It gives you the ability to register and consume services in a declarative way using some xml files and simple accessors in your classes.

I’ll take the same example from in my last blog post and use it to look at ds for single sourcing.  In that blog, we single sourced a themed button widget.  We can use the same interfaces and service implementations, and the only differences will be how the services will be registered and referenced.

First, let’s take a look at the service registration. In our example we need to register the services in the rap and rcp bundles. It’s common practice to put all service declarations in a folder called OSGI-INF in the root of your project. Once you’ve created this folder you can create a “component definition” using the wizard. After this you need to fill in three things: first, the filename of your choice, second, the component name which needs to be unique in the framework and third, the component itself.

The component is the fully qualified classname of your implementation. In the case of service registration, it’s your service implementation. To add the service registration, press ‘Finish’ to open the component editor. We only want to register a service, so we jump to the service tab. In the bottom section you can add the service interface.

To understand what happens in the background let’s recap what we have declared. We defined a service interface, a service implementation, a component name and a filename. The component framework takes care of instantiating the service implementation and registering it as a service using the service interface. It registers the component using the component name. The filename will be automatically added to your bundle’s manifest. That’s all, the next time we start this bundle the service will be registered. Your component definition should look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" immediate="true" name="com.eclipsesource.app.rap.service.provider">
   <implementation class="com.eclipsesource.app.rap.RAPSingelSourcingService"/>
   <service>
      <provide interface="com.eclipsesource.app.ISingleSourcingService"/>
   </service>
</scr:component>

Now we get to the service referencing. As you recall, we need to reference the service in our app bundle. Therefore, we need to create a component in this bundle too. In this example I decided to reference the service in the bundle’s activator and provide it with a static accessor. But you can reference it wherever you want. In this case the component is our Activator. The only difference to the service registration is in the service tab of the component editor. Instead of providing a service, we are now referencing one. You can do this by clicking ‘Add’ in the upper section of this tab.

After this you need to declare the Interface of the service you want to reference, in our case the ISingleSoucingService. The question is now, “how does this service finds its way to the Activator?” The answer is binding methods. In the reference you can specify a bind and an unbind method e.g. setService and unsetService. You need to add these methods to your activator with the service as a parameter. That’s all – we are referencing the service now. Your component should look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" enabled="true" name="com.eclipsesource.app.servic.consumer">
   <implementation class="com.eclipsesource.internal.app.Activator" />
   <reference bind="setSingleSourcingService" cardinality="1..1" interface="com.eclipsesource.app.ISingleSourcingService" name="ISingleSourcingService" policy="dynamic" unbind="unsetSingleSourcingService"/>
</scr:component>

The last thing we need is a little bit of glue to bring these components together. The glue is in the org.eclipse.equinox.ds bundle. This bundle contains the component framework implementation, and to make everything work together you need to add this bundle to your launch configuration. It’s not included in the RAP target components, but you can download it using the Indigo release site or the Equinox SDK.

I added a branch called “ds” to the repository on github from the last blog. This branch represents an example implementation using ds for single sourcing.

Have fun declaring services

For single-sourcing a RAP or RCP application, its straightforward to use the power of OSGi because it’s included in both platforms out-of-the-box. OSGi has a central concept called services which are simply POJOs and are used to allow communication between modules. And, you can register or resolve services at any time in your code.

The basic Idea behind using OSGi services for single-sourcing is as follows. We need to extract all the things that vary into separate, platform specific bundles. To use the different implementations, we have to create an interface in a “common” bundle that contains the methods we want to use. The platform specific bundles have to register an implementation of this interface as a service. In the “common” bundle we can reference the registered services and use them to get the platform specific stuff. More specifically, we register a RAP implementation in a “rap” bundle and an RCP implementation in an “rcp” bundle. The only thing we need to do then is to start the right bundles on the associated platform to get the right service.

With this solution we can extract the platform specific stuff into separate bundles and we don’t have to rely on fragments. So enough talking. Let’s look at some code. I decided to create a very simple single-sourcing interface which can be used to get the WidgetUtil.CUSTOM_VARIANT constant value. This constant exists only in RAP so, it’s a good example for showing how to handle the differences.

public interface ISingleSourcingService {
  String getCustomVariantString();
}

I have created three bundles: one that contains the application which is entitled “com.eclipsesource.app” and one for each platform. These are called “com.eclipsesource.app.rap” and “com.eclipsesource.app.rcp”. Both platform bundles implement the interface.
RAP:

  @Override
  public String getCustomVariantString() {
    return WidgetUtil.CUSTOM_VARIANT;
  }

RCP:

  @Override
  public String getCustomVariantString() {
    // There are no custom variants in RCP
    return "";
  }

And both bundles are registering the service in their Activator during the start method call.

  public void start( BundleContext bundleContext ) throws Exception {
    Activator.context = bundleContext;
    registration = context.registerService( ISingleSourcingService.class.getName(),
                                            new RAPSingelSourcingService(),
                                            null);
  }

When it comes to using the service in the common “app” bundle we can use a ServiceTracker to get the service implementation (you can also use DS).

  private ISingleSourcingService getSingleSourcingService() {
    // We use a tracker to get the service. We also can use DS to get it.
    Bundle bundle = FrameworkUtil.getBundle( getClass() );
    BundleContext context = bundle.getBundleContext();
    ServiceTracker tracker
      = new ServiceTracker( context,
                            ISingleSourcingService.class.getName(),
                            null );
    tracker.open();
    ISingleSourcingService service = tracker.getService();
    tracker.close();
    return service;
  }

The only thing we have to do now is to create two launch configurations which contain the associated platform-specific bundle.

That’s it! You can find the sources in this github repository. Have fun using OSGi services to single-source applications.

Computer cluster, taken from http://thefullwiki.org/Parallel_programming

While most of us are busy with that latest bits of the Indigo release, some have the joy to work on one of the next new features in RAP: support for high availablity clusters.

Let me briefly mark out what we mean by clustering support and what we don’t. Load balancing clusters are used if you whish to provide your applications to a large number of users. If your application provides critical servies you may also want to make it fail safe by running it in a high availablity cluster.

A high availability cluster operates by having redundant nodes. So that if one node crashes, the service as a whole is unafected as other nodes take over the work. Whereas load balancing RAP applications is possible since ever, failover clusters put further requirements on the framework.

To be able to migrate sessions between nodes in a cluster, all session data has to be serializable. Also, the current implementation preserves the server-side execution flow within a UIThread in order to single-source RCP applications. These two form the main work areas.

• All session data must be prepared for distributing sessions among cluster nodes for failsafe operation.
• A new life cycle for processing requests without a UIThread was implemented and RAP can be configured to run with either of them.

The new life cycle also makes it easier to access security or transaction contexts and is conform to the JEE Specification. If you don’t use blocking dialogs or workbench features and want to be able to eventually run your application in a cluster – then this is for you.

For more details, see the RAP Wiki.

A few days ago some people mentioned to me that it’s great that the sources from my posts are open but they can’t install git on their machines due to security restrictions in their company. They aren’t even allowed to install egit as an Eclipse plug-in. But there is  good news. You don’t have to use git when you want to get sources from github. You can download every branch from every (public) github repository without git. When you browse to a repository you can simply press the download button on the right and download the latest version of the repository as zip or tar.gz. Is this simple? As I said, it’s a kick-ass platform

In M7, we now introduce a simple way of doing this. Let’s first have a look on how you would implement a key binding in SWT. You would have to register a global listener for key events on the display like this:

display.addFilter( SWT.KeyDown, new Listener() {
  public void handleEvent( Event event ) {
    if( event.stateMask == 0 && event.keyCode == SWT.ESCAPE ) {
      // handle escape key
    }
  }
} );

Well, you can now use the same code in RWT.

But there’s one more thing to it: RWT is a client-server architecture and we don’t want the browser client to send a request for each and every key stroke. The server should only be notified when the user presses one of the key sequences that we are really interested in. Therefore, we have to inform the client, which key sequences should be active. This information can now be attached to the display using Display.setData() with the new constant RWT.ACTIVE_KEYS as property key. The value of this property must be an array of strings, each one representing a single active key sequence. The syntax is the same that you know from key binding extensions for the workbench. So if you want to enable some simple key bindings like, for example, “c” for compose and “x” for delete, and maybe some more advanced key sequences like “Ctrl+F11″ for power-users, you could write something like this:

display.setData( RWT.ACTIVE_KEYS, new String[] { "C", "X", "CTRL+F11" } );
display.addFilter( SWT.KeyDown, new Listener() {
  public void handleEvent( Event event ) {
    if( event.stateMask == 0 && event.character == 'C' ) {
      handleCompose();
    } else if( event.stateMask == 0 && event.character == 'X' ) {
      handleDelete();
    } else if( event.stateMask == SWT.CTRL && event.keyCode == SWT.F11 ) {
      doSomeAdvancedStuff();
    }
  }
} );

Only the first line is RAP-specific. So for a single-sourcing RWT/SWT application, you only have to care about the constant. I’m sure you have an idea how to do that. M7 will be available on May 7–easy to remember.

*) Some shortcuts may be reserved by some browsers and cannot be used. Other shortcuts will override browser actions, like Ctrl-N (new window) Ctrl-T (new tab) etc. You also may not like to disable C&P in form fields by adding key bindings for Ctrl-C etc. So you have to choose your web key bindings wisely… Ah, and sequences of key strokes like Ctrl+X T are not yet supported.