The second service release for Eclipse 4.2 has been launched. Grab the latest download here or update your Eclipse IDE via
“Help -> Check for Updates”.

The new release brings the expected bug fixes and a couple of minor but useful tweaks.

Personal favorite: The git staging view has regular buttons for “Commit” and “Commit and Push”.

Although Mockito is great for mocking Java classes, it would sometimes be very cumbersome to mock entire parts of the Android UI framework. This is the place where we resort to another testing framework called Robolectric, which can be easily combined with Mockito to provide stub implementations of nearly all Android classes.

Robolectric provides concrete implementations for Android classes in the form of shadow objects. When running your test code you don’t execute the Android code but run against the shadow classes. Because you are executing regular Javacode, you don’t have to run the tests on an Android device but can execute the tests in a regular Java VM.

A Robolectric shadow class allows you to easily make assumptions about its current state because it can expose more of its internals than an Android class would. Here is a quick example to assert if an OnTouchListener has been attached to a View:

@Test
public void shouldHaveOnTouchListener() {
  View view = new View(new Activity());
  OnTouchListener listener = Mockito.mock(OnTouchListener.class);
 
  view.setOnTouchListener();
 
  ShadowView shadowView = (ShadowView)Robolectric.shadowOf(view);
  assertEquals(listener, shadowView.getOnTouchListener());
}

Don´t forget to put the @RunWith(RobolectricTestRunner.class) annotation in the test class. It is also worth noting that the new Activity() we are creating is, in fact, a ShadowActivity.

The assertion could not have been done without the ShadowView since Android does not have a getter for the OnTouchListener. Of course we could have mocked the View object with Mockito but that is not always possible, e.g. when the view has been inflated from a layout or has been created in some other place.

Sometimes even Robolectric falls short on the elements you can assert. In that case you can easily extend an existing shadow object to provide implementation details that suit your test case. Let’s say we want to assert that TextView.setIncludeFontPadding() has been called. Android does not provide a getter for that property and Robolectric does not implement the method so the call is simply swallowed. This is where we implement our own Shadow class:

@Implements(TextView.class)
public class CustomShadowTextView extends ShadowTextView {
 
  private boolean includepad = true;
 
  @Implementation
  public void setIncludeFontPadding( boolean includepad ) {
    this.includepad = includepad;
  }
 
  public boolean getIncludeFontPadding() {
    return includepad;
  }
}

Once we have defined the shadow object we can use it in our test case. Whenever our code tries to instantiate a TextView it is now providing an implementation of CustomShadowTextView. The following snippet shows how to set our custom shadow view:

@Test
public void shouldIncludeFontPadding() {
  Robolectric.bindShadowClass(CustomShadowTextView.class);
  TextView view = new TextView(new Activity());
 
  view.setIncludeFontPadding(true);
 
  CustomShadowTextView shadowView = (CustomShadowTextView)Robolectric.shadowOf(view);
  assertTrue(shadowView.getIncludeFontPadding());
}

There are some shortcomings with the way Robolectric is able to reference Android resources. Although it is generally possible to find all kinds of images, Robolectric does have problems when referencing theme and style attributes. In that case we often resort to testing specific custom shadow objects that hardwire the desired behavior. In addition, some Android classes do not have a corresponding shadow class. A good example is the Typeface class. In that case you have to compile Robolectric manually and add a Robolectric.shadowOf(typeface) method.

In general we find the features provided by a combination of Mockito and Robolectric to be more than sufficient and whole-heartedly recommend the setup to anyone serious about unit testing. The speed at which you can write and execute tests is an important factor that will allow you to iterate on your test code quickly and in a meaningful way.

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.

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

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.

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?

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.

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.

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.

To make the menu contribution show up as a toggleable button you have to provide the style value “toggle” on your commands menu contribution:

<extension point="org.eclipse.ui.menus">
  <menuContribution locationURI="...">
    <command commandId="org.eclipse.example.command.toggle"
              style="toggle" />
  </menuContribution>
</extension>

Next we have too keep track of our actual toggle state. Since it is possible to have multiple menu contributions for the same command, we have to keep track of the state in a central place. Imagine a toggle button triggerable from the main menu and a views toolbar. The state of these buttons are keept in sync by storing the state directly in the command.  The key to this is the org.eclipse.jface.commands.ToggleState. This implementation of org.eclipse.core.commands.State is a wrapper for a boolean. To attach such a State object to a command, it is provided during the command declaration:

<command id="org.eclipse.example.command.toggle"
         name="Toggle Me">
  <state class="org.eclipse.jface.commands.ToggleState"
         id="org.eclipse.example.command.toggleState" />
</command>

The state element takes the ToggleState class as a state provider and attaches itself to the command. The id of the state has to be unique to identfy the state. With the state attached to our command, how can we access it? In the Handler, reacting to the invocation of the menu contribution, we have to access the current state keept in the ToggleState. The following code demonstrates just that:

ICommandService service =
(ICommandService) PlatformUI.getWorkbench().getService(ICommandService.class);
Command command = service.getCommand("org.eclipse.example.command.toggle");
State state = command.getState("org.eclipse.example.command.toggleState");
state.setValue(!(Boolean) state.getValue());

We obtain our command from the ICommandService and ask it for our toggleState stored within the command. Next we just flip the boolean as to create the new state. Now we can just do whatever we want to do in our Handler using the new state. Great, isn’t it? Of course the ToggleState is only one possible implementation of State. One could also imagine multiple states, radio states, text states etc. Also the State class has a specialization (PersistableState), which can be persisted to the preferences as to keep track of the (toggle) states of your buttons.

But there is thing left to do: what happens to this other button which is also a menu contribution for our command? We need to toggle the pressed state of it, as to reflect the state of the first button. To do so, a Handler has to implement IElementUpdater providing the method updateElements(…). It gets an UIElement as a parementer, which can be used to trigger the toggle state:

public void updateElement(UIElement element, Map paramters) {
  element.setChecked(isSelected);
}

To broadcast the refresh event to all menu contributions we use the ICommandService in our Handlers:

commandService.refreshElements(executionEvent.getCommand().getId(), null);

I hope you find the information here valuable and i am looking forward to your comments.