Common Problems

While porting Riena to RAP we encounter several issues (some say challenges). Most (or probably all) of these issues are well known and RAP has already solutions for them - see FAQs and Tips and Tricks.

The goals for the port are:

do not place a burden to the users of Riena

the impact (of this port) should not harm (efficency, code bloat, ..) Riena when used in a RCP fashion

..

The following sections describe concrete problems and patterns how to solve them.

Platform specific implementations

Although RAP handles a lot of SWT's funtionality for the web, there is functionality that it does not (yet) handle.
For these cases Elias introduced the facade factory pattern. (The following description is picked from a mail to riena-dev)

The facade factory only works because of some careful bundle/classpath engineering. It is crafted for one particular use, i.e picking between RAP/RCP.

Here are the prerequisites:

three bundles are necessary. Two of them have different dependencies (swt vs rwt)

facadeFactory and the facade implementations are in the same package in all three bundles

the .swt.rap and swt.rcp bundles are buddies to o.e.r.ui.swt so that the FacadeFactory has access to their classpaths and can instantiante classes from the common package.

there is a naming convention <FacadeName>RAP <FacadeName>RCP

Singletons

Class.staticMethods() based singletons (based on static methods and static fields, i.e there is some state), e.g. ApplicationNodeManagerNote: Classes with only static methods and no static fields are not singletons

Two solve the singleton problem within RAP it provides the (abstract) SessionSingletonBase class that is able to create session-dependent singletons. This class may be used directly by calling it's (static) getInstance(Class type) method or by sub-classing and providing a taylored (static) getInstance() method.
With this it is very easy to transform the first singleton type and a little bit more work to transform the second type - both without breaking the current interface of course.

The straightforward technique of just passing a class to the getInstance() method is for most cases sufficent. However, it does not allow to:

use constructors with parameters

it is not possible to "wire" the singleton (wiring is the term we use for Riena's dependency injection)

Of course, it possible to create workarounds:

use setters instead of constructor parameters - may result in undesired usage

do the wiring within the constructor - makes e.g. unit testing more complicated

The introduction of e.g. an IInstanceFactory interface with a single getInstance() method could solve this. The class implementing the IInstanceFactory could then internally be used for creating the key to store the singleton in the session store.
And the usage of generics would be a nice bonus.