IT Mill is the creator of Vaadin: A 100% Java tool for RIA.

Joonas outlines a spectrum of complexity from Basic site to 3D games examples:
Web Sites (Wikipedia), AJAX Sugar (Facebook), Full RIA

He divides „Full RIA“ divide into client side vs. Server driven. Gives a crash course in GWT.

Vaadin: Apparently 100% Java and server driven, which sounds an awful lot like ULC at this stage… But here’s a difference: It builds on GWT and relies on JavaScript on the client-side.

He goes on to present a bunch of development rules:

Rule #1: Don’t trust the browser
Rule #2: Complexity is a hiding place for bugs
Rule #3: Large surface give more opportunities for attack. This surface has increased with Web 2.0.

Difference between GWT and Vaadin architectures is that GWT relies on the client invoking a server-side Web Service API, whereas Vaadin renders the client’s view on the server.

Erm… he then offers the cures for the problems (Rules above)… which I miss because the explanation is compressed into around 5s.

I’m starting to dislike this presentation at this point. Because here comes another artificial security issue scenario… which guess which product solves. And I thought product placement in Hollywood movies was irritating.

The issues he raises are legitimate, but the lack of objectivity is obscuring the message. And as I write the presenter is debugging JavaScript which depends on analysing the DOM on the client side – I’m not sure if he’s now analysing the problem or trying to fix it!?

I am formally declaring myself lost at this stage. At least I hope the other attendees are getting something out of this presentation, which has lost focus IMO.

He continues with a discussion about attacking at the transport level, inserting new data on the fly. But come on: A secure transaction in this technical setting will operate under HTTPS, which in most instances will deal with this kind of attack. Unless, of course, that’s something else I missed.

I think I need a coffee!!!

Google Web Toolkit und Ultra Light Client

Die Anbindung an das Internet und ein Browser gehören heute zur Standardausrüstung eines jeden Arbeitsplatzrechners oder Heim-PCs.

Stefan Thomas

Viele neue Anwendungen werden darum als HTML-basierte Web-Anwendungen implementiert, die leicht verteilt und aktualisiert werden können und von überall, zu jeder Zeit genutzt werden können. Durch den Einsatz von AJAX-Technologien konnte die Benutzerfreundlichkeit der Oberflächen in den letzten Jahren deutlich gesteigert werden, allerdings bei gleichzeitig wachsender Komplexität in der Anwendungsentwicklung. Bibliotheken, Toolkits und Frameworks versprechen hier eine Erleichterung. Beispielsweise durch die Abstraktion der unterschiedlichen JavaScript-Implementierungen der Browser oder durch vorgefertigte, komplexere Bedienelemente wie Menübalken, Tabreiter oder Baumstrukturen.

The article was written by UltraLightClient customer Dr. Stefan Thomas. Dr. Thomas is an independent consultant, that has developed two large corporate web applications with Canoo’s UltraLightClient for a global retailer.

GWT vs. ULC:

Comparing the two is a bit like comparing apples and pears (the article discusses this). On the other hand, the two widget libraries can be used for similar web applications. And both of them address Java developers.

See also the corresponding product websites:
Google Web Toolkit
Canoo UltraLightClient

Here are some quick notes on the sessions I attended yesterday at Sihlcity. I believe Jazoon will be uploading videos and slides very soon:

First in my lineup was a talk on using Google Web Toolkit for a business application in a typical enterprise environment. This was kind of like a case study. Dmitry Buzdin talked about the experience his company gained and listed the various pros and cons.

Next, I listened in to Bruno Schäffer’s talk together with Christoph Henrici and Daniel Buffet of APG. The talk described the migration of an Oracle Forms application to Java forms for the advertising industry. Main requirement: development and application performance had to remain just as fast as with Oracle Forms. A requirement that the migrated application managed to over-fulfill.

Canoo’s Andreas Hölzl and Christian Stettler presented their Google Android experience report. They showed an application they developed for the Android Developer Challenge called Mobile Zoo. Their baseline: “What’s here looks promising. Let’s see the devices!”

Brian Sletten’s presentation on data-driven applications was very interesting. I particularly liked the analogy between resampling music and data.

The showcase application we developed describes the following scenario: field engineers use a mobile device to receive their daily work tasks or orders (called “mission” in our application) which they need to complete for that day and to communicate certain states such as “starting to work on mission X” or “completed mission Y” to a back office team application. The field engineer can use the mobile device to book the time spent and material used for a certain mission, so that the back office team can directly process the billing once a mission has been completed. In addition, the back office team can send “high prio” missions to a specific field engineer.

After having a look at different architectural approaches (ranging from device-specific fat clients to browser-based generic Web applications), we decided to go with an in-between approach: a GWT application tailored for mobile devices that runs in a generic, JavaScript-enabled mobile browser and connects to a server-side service infrastructure to fetch data and post back state changes.

For the target devices, we used a brand-new iPhone and an older iPAQ (about two years old, running Windows Mobile 2003).

The back office application is written in server-side Java, using UltraLightClient as the RIA technology.

Here is a screenshot of the mobile client:

Here is a screenshot of the corresponding back office application (click on the image to view a larger screenshot):

Instead of going into the gory technical details here (we will do that in a future posting), let me discuss some of the lessons learned:

First, the approach chosen (GWT application + “Web services”) works for mobile applications. We were able to deliver the mobile application to the mobile device. Nevertheless, there are some shortcomings:

• whereas the generic, browser-based approach supports any device that hosts an up-to-date browser (with JavaScript support enabled), it also prevents a tight integration into the device itself: the look and feel is not completely “native”, its usability may be different from the concepts known from other device-native applications, and the application shows a “low fidelity”. In addition, the reuse of existing device-specific applications such as map tools, address book or telephony application is either impossible or only achievable in a device-specific way (e.g. the iPhone supports dialing numbers from a website that are encoded as a URL with link type “tel://”, other devices may support the “callto://” link type, others may not support this functionality at all). A browser-based mobile application is somehow isolated from the device, running in its own world. This is especially irritating as two of the most current developments in the mobile world, Google’s Android and Sun’s Java FX Mobile, propagate an application model that is based on the reuse of existing applications available on the mobile device.
• one evil thing we know from the desktop world also holds true for the mobile world: browser hell. There is no „write once, run anywhere“ (not even with GWT’s cross-browser abstraction layer). This is due to the fact that there are various different mobile browser products and versions available on the market. Some of them are state-of-the-art and support a wide set of JavaScript and CSS features, others provide no JavaScript support at all (or only a very small subset of the language). Some of the good browsers are not available for free (such as Opera Mobile). Tweaking CSS properties and pixels was part of the daily business while developing the showcase application.
• in mobile scenarios, (bad, broken) connectivity is an important topic, and so is offline capability. Thanks to the client-side JavaScript-based approach of GWT, offline “reading” is possible to a certain extent, but modifying data offline and synchronizinig the changes back to the server has very narrow limits in a browser-based world. Typically, there is no on-device persistent storage (such as a local database) available for browser-based application, as the browser builds some kind of a sandbox for that application. Ideas and projects such as Google Gears aim to ease those limitations, but currently require the installation of additional software (i.e. a browser plugin) on the mobile device.
• even in times with high-end mobile devices such as the iPhone, performance issues on mobile devices are ubiquitous. The rendering performance is often poor, resulting in disturbing lags when rendering large option lists or tables (on the iPAQ device, even DOM manipulations on small HTML-based tables lead to unwanted “update effects”).

In addition to these shortcomings, rooted in the architectural approach chosen for the showcase, another thing became obvious to us: Rich(Mobile) != Rich(Desktop):

• one important difference when it comes to “rich”, especially related to the usability aspect of richness, is the fact that on mobile devices, users do not have a mouse pointer. Mobile users use either a pen, their fingers, or a navigation button (for devices without touch screens). These facilities reduce pointing precision. There is no “mouse move” equivalent as there is no difference between moving the pointer and activating the pointer (as soon as you touch the screen, an event is triggered). This reduces the number of available gestures and thus, prevents applications from using some of this gestures for interaction (e.g. hovering effects or tooltips are normally not supported on touch screen devices due to the lack of “mouse move” events). A further effect of the reduced set of useful gestures for mobile devices and the corresponding pointing devices is that gestures often get “overloaded” (on the iPhone, for example, dragging means “scroll the web page”, and not “perform a drag and drop operation”).
• the set of useful UI widgets is reduced as a consequence of the low-precision pointing device and the small screen size. Widgets such as spinners that allow toggling a value up and down using small arrows is not very usable on a mobile device, the same applies to scrolling in large lists (guess why the iPhone provides enhanced support for selecting a value from a combobox shown on a Web page).
• the general layout-policy for mobile devices differs from desktop-based RIAs: whereas on desktop RIAs, layouts such as the dock layout are often used to provide as much flexibility to the user as possible and let the user choose almost any desired application with as little clicks as possible, mobile applications use a stack-based layout that limits the information displayed and the actions available to the user at a given moment. A mobile application needs to reduce the application context to the most important information and actions at any given time. This layout resembles the page-based approach of old-school Web applications that the one of modern RIAs.

The bottom line: RIA4Mobiles developers will need to focus a lot more on usablility, device limitations and richness compared to the development of desktop RIAs in order to deliver highly usable, responsive and appealing mobile RIAs.

All in all, RIA4Mobiles is an exciting new application area. Stay tuned to hear more about our showcase application!

About a month ago I wrote about my experience when building a simple but configurable web site with help of the Google Web Toolkit (see Part I). I mentioned the hurdles that I encountered but also some motivating aspects when working with GWT.

An issue I haven’t reported on yet was my attempt to internationalize my GWT application. You might be surprised why this is even worth mentioning, since GWT includes I18N support. Well, let’s say it includes some I18N support – but it was not what I needed.

Giving GWT’s I18N a Try

The GWT developer guide explains the various I18N options of GWT (see GWT I18N) but all of them have one thing in common: The locale cannot be changed dynamically at runtime after a GWT application has been started. However, it is a common use case that you want to change an application’s locale at that point of time.

Providing Truly Dynamic I18N

Truly dynamic I18N means that use change the locale in the GUI at runtime. E.g., if the user changes a combo box entry, then all GUI labels magically obtain the newly localized values. To see what I mean, you may want to check out the result of my attempts.

The way to solve this was to write my own (but simple) resource bundle API, which is similar
to the one provided by the Java class java.util.ResourceBundle. Unfortunately, this requires quite some code including:

• a properties file reader,
• a locale class,
• a resource bundle loader.

The Resource Bundle Loader

As it turned out, implementing the resource bundle loader was far from trivial. One of the resource bundle loader’s tasks is to load and cache a properties file from the server on the basis of a given locale. You can access a bundle entry with a key string in order to obtain the best possible localized result value. The means that the loader might have to access a chain of properties files according the chain of locales (from the most specific current locale to the default locale).

To implement the loading of properties files with GWT, one must use the class HTTPRequest, which offers an asynchronous request API for loading files from the server. Unfortunately, coordinating the chained download of properties files such as described above is rather difficult to implement with an asynchronous API. (See my last blog about infectious asynchronous APIs.)

Summary

In the following I would like to give brief summary of my experiences with GWT:

Upsides:

• I liked the general concept behind GWT and I think it is the (or “a”) way to go for proper software engineering in the AJAX space.
• Getting in touch and getting familiar with GWT was easy enough and was great fun.
• The compiler and the debugger seemed stable, work well and the compiler generates efficient code.

Downsides:

• The widget library is far from complete and not engineered for extensions and reuse.
• The asynchronous GWT APIs are often inconvenient – Google should ofter synchronous variants wherever possible.
• Google’s I18N solution does not offer true dynamic locale changes. This is a serious drawback for many rich client applications.

Many nice and home-grown websites contain a navigation bar. But without a special design tool a navigation bar is not easy to build because it typically involves JavaScript programming. My idea was to build a simple and convenient tool such that a non-technical person with basic knowledge about static HTML can easily include a corresponding navigation bar in its pages.

The person configures the navigation bar by composing or adjusting a rather simple XML file. The HTML writer should not have to deal with server-side page scripting or anything a like. For the website to work, it should be sufficient to deploy the XML and a bunch of static HTML files along with some ready-made magic. Trying out the site should be as easy as double-clicking the main HTML file in the local file system.

I like Java and I did not want get my hands dirty with JavaScript and browser compatiblity issues. So how could I get the job done? Since I also like experimenting, I decided to give the GWT (the Google Web Toolkit) a go for the project.

When reading the GWT’s documentation, its seemed like the perfect choice for me: I program my navigation bar entirely in Java and in the end, it is all converted to a highly optimized and pure client-side JavaScript / HTML mash. Wow!

In the following, you can read about my related experience with the GWT and the many unexpected hurdles a had to take in order to reach my goal.

Here is a brief summary about the problems I encountered and my general impression, after playing with the GWT:

• The GWT misses (at least) some basic widgets, you may expect in an Ajax (library).
• (At least some) of the existing widgets are difficult to extend.
• The asynchronous programming model of the GWT (and Ajax in general) leads to problems,
  when creating higher level API. (You are forced to give it an asynchronous design, too.)
• The GWT does not well support dynamic locale changes (details will follow in an upcoming blog entry).

Although I was really enthusiastic about the GWT when I started, I have to admit that I got disappointed here and there.
An upside is the GWT’s basic infrastructure (i.e. the compiler and the debugger), which seems very mature and stable.
It’s really just the library that should be improved…

Getting in Touch with the GWT

If you are a reasonably experienced Java programmer, then getting started with the GWT is easy, and the quick results are motivating. So, after trying out some basic stuff, I wanted to make shure that the GWT API indeed allows me to realize my little project.

The Navigation Bar Hassle

The GWT library contains a widget, which is close to the kind of navigation bar I had in mind: the class com.google.gwt.user.client.ui.TabPanel. Unfortunately, it allows for creating horzitontal navigation bars only.

When looking at the GWT kitchen sink example, it seems like there is a vertical navigation bar included – but that impression is misleading. The vertical navigation bar in the kitchen sink does not use a ready-made GWT widget. Instead, it is a custom built thing made out of a bunch of hyperlink objects (of type com.google.gwt.user.client.ui.Hyperlink)

I wondered why Google did not add a built-in vertical tab panel and so I began to read the source code of the
TabPanel and the affiliated TabBar class. I could not find any good reason why this widget should not be vertical and so, I tried to subclass TabPanel in order to get a vertical version of it. Sadly, my attempt quickly came to a halt, because the TabPanel had not at all been created with extensibilty in mind. The first few lines of code of GWT’s TabPanel reads as follows:

public class TabPanel ... {
...
private DeckPanel deck = new DeckPanel();
private TabBar tabBar = new TabBar();
private TabListenerCollection tabListeners;
 
/**
* Creates an empty tab panel.
*/
public TabPanel() {
VerticalPanel panel = new VerticalPanel();
panel.add(tabBar);
panel.add(deck);
...
The TabPanel is a composite widget, which consists of simpler widgets, namely a vertical panel, a tab bar and a deck panel. However, given the code from above, none of these contained widgets can be exchanged by subclassing, and therefore, it is practically impossible to get a vertical tab panel by by subclassing TabPanel.

I felt disappointed: If the set of built-in widgets is small, then at least I expect a good degree of extensibilty of the corresponding framework.

So how did I get my vertical tab pane then? By copy and patch! I copied the entire TabPanel code and turned it into my so-called FlexibleTabPanel class.

Its first lines read as follows:

public class FlexibleTabPanel extends Composite implements TabListener,
SourcesTabEvents, HasWidgets, IndexedPanel {
 
private final WidgetCollection children = new WidgetCollection(this);
private final DeckPanel deck = new DeckPanel();
private final FlexibleTabBar tabBar;
private TabListenerCollection tabListeners;
 
/**
* Creates an empty tab panel.
*/
public FlexibleTabPanel(boolean horizontal) {
Panel panel = createOuterPanel(horizontal);
tabBar = createTabBar(horizontal);
 
panel.add(tabBar);
panel.add(deck);
...
The constructor of FlexibleTabPanel obtains a boolean, which decides, if the resulting tab pane is vertical or horizontal. The methods createOuterPanel() and createTabBar() may be overriden. Depending on the boolean flag, they create widgets for either the horizontal or the vertical case.

As you might guess, I also had to copy and patch the class com.google.gwt.user.client.ui.TabBar. I even had to subclass (the standard GWT classes) HorizontalPanel and VerticalPanel: Both classes have certain methods in common but the GWT does not factor them out in a common superclass or super interface. However, the original TabPanel class counts on these methods with respect to HorizontalPanel. Since I wanted to use the corresponding code in FlexibleTabPanel for both the HorizontalPanel and VerticalPanel, I was forced to do the following:

1. I created an interface, which contains the missing super class methods and it looks
   as follows:
   public interface FlexibleIndexedPanel extends IndexedPanel {
public void add(Widget w);
public void insert(Widget w, int beforeIndex);
public boolean remove(Widget index);
}
   (IndexedPanel is an existing interface of the GWT, which just lacks the methods from above.)
2. I subclassed HorizontalPanel and VerticalPanel in the following ways:
   public class FlexibleHorizontalPanel extends HorizontalPanel
implements FlexibleIndexedPanel {
}
 
public class FlexibleVerticalPanel extends VerticalPanel
implements FlexibleIndexedPanel {
}

The new classes FlexibleHorizontalPanel and FlexibleVerticalPanel offer the functionality needed in FlexibleTabPanel. So far I could not find any good reason, why the GWT does not share this functionality in a common super class of the vertical and horizontal panel already.

Building the Builder

XML and Properties Files for Configuration

As I mentioned in the beginning, I wanted the navigation bar to be configurable via an XML file. Essentially the XML file should determine the structure of the bar and its contents. I wrote a little interpreter, which parses a related XML file and and turns it into a widget object hierarchy. This is a similar approach as in frameworks such as SwiXML and ULCXML, but for my purpose, the navigation builder, as I called it, acts on a much smaller scale.

Here is a sample XML file that the navigation builder is able to digest:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<navigation>
<file id="home" xhref="home.html" mce_href="home.html" html="true"/>
<file id="cv" xhref="cv.html" mce_href="cv.html" html="true"/>
<file id="concerts" xhref="concerts.html" mce_href="concerts.html" html="true"/>
<navigation id="gallery" orientation="vertical" default="true">
<file id="image1" xhref="image1.html" mce_href="image1.html" html="true" default="true"/>
<content id="image2">This image is not yet available.</content>
</navigation>
<file id="contact" xhref="contact.html" mce_href="contact.html" html="true"/>
</navigation>

Based on this file, the interpreter creates an outer navigation bar with five tabs. The first tab has the id home, and when selected, it displays the HTML file home.html. The next two entry work similarly. The fourth entry defines an inner navigation bar, which is vertical and contains two tabs itself: The first inner tab relates to the HTML file image1.html and the second one adds the text This image is not yet available. in place.

As you can see, it’s usually HTML files, which determine, what’s displayed upon tab selection. But where do the display names of the tabs actually come from? For reasons I will explain later, I moved all of these names to Java properties files. E.g. the properties file navigation.properties for the XML file from above may look as follows:

home=Home
cv=CV
concerts=Concerts
gallery=Gallery
contact=Contact
image1=Image 1
image2=Image 2

Every id defined in the XML file is referenced in the properties file and is associated with an English display text.

Being Asynchronous is Contagious

After that, it was time to build the navigation builder class itself. The GWT comes with a convenient
DOM-based XML parser API and so, it was easy to write the interpreter code.
Interestingly, the way to read a corresponding XML file with the GWT has a serious impact on the entire program structure.

Reading files inside a Web page is real Ajax functionality, and the related GWT API must be used as follows:

HTTPRequest.asyncGet("myfileName", new ResponseTextHandler() {
public void onCompletion(String responseText) {
...
}
}

The code loads the file myfileName via a relative URL and upon success, the contents of the file is passed in as a string to the onCompletion() method.
Since the method asyncGet() returns its result via a callback, it is called asynchronous. The navigation builder uses asyncGet() and therefore its API became asynchronous too:

NavigationBuilder builder = new NavigationBuilder(...);
builder.buildNavigation(
new NavigationBuildHandler() {
public void onBuilt(Widget widget) {
...
}
 
public void onFailure() {
...
}
});
Asynchronous APIs considerably change the structure of depending programs and in the example above, an asynchronous low level API “infected” a higher level API.
In the context of the GWT this effect is hard to prevent, because the native
execution environment (Java Script) has no thread concept and no thread synchronization mechanisms.

Results

After putting it all together, I finally got a first version of the navigation bar. Follow this link to try out a corresponding example, which uses the XML file and the properties file from above.

The file GWTSample1.zip contains all the related source code.

Next week, I will talk about my adventures, when I tried to bring internationalization into the system. (Note that the code in the zip file contains the code for related feature already.)