We had a couple of hours of downtime this morning as a new diesel generator was installed at Playing With Wire’s hosting location. Sorry about that.

SwtCallback 0.1 was released only a little more than a week ago, but that’s not stopping us from releasing 0.2 today! In line with the original philosophy, SwtCallback has been extended to again reduce clutter and deep nesting in your Java code. This time SwtCallback attacks the Runnable interface.

As I wrote in my release post about SwtCallback, SwtCallback is a java library for SWT applications which adds an alternative way to handle events: callbacks. Instead of clunky listener interfaces or messy anonymous classes, SwtCallback enables one line solutions that make it easy to keep your event handling code in a single flat class – this while still being more readable and (surprisingly) improving encapsulation in some cases.

This latest release extends this functionality from just listeners to anything that takes a runnable. Prime examples in SWT are display.syncExec(), display.asyncExec() and timers.

For example, maybe you wish to refresh some UI components to reflect a change in data. But you’re not on the SWT thread so you have to use syncExec. Normally, you’d do something like,

display.syncExec(new Runnable() {
  public void run() {
    doUpdateSwtLabels();
  }
});

With a Callback you can turn this into one highly readable line:

display.syncExec(new Callback(this, "doUpdateSwtLabels"));

The most useful application may be for timers. In SWT, a timer needs to be reestablished at the end of timer execution if you wish it to recur. You may end up with unwieldy code such as,

void initWidgets() {
  /* ... */

  // Prime the timer.
  display.timerExec(INITIAL_DELAY, new Runnable() {
    public void run() {
      refresh();
    }
  }); 
}

void refresh() {
  /* ... update stuff ... */
  
  // Set the timer again.
  display.timerExec(TIMER_DELAY, new Runnable() {
    public void run() {
      refresh();
    }
  }); 
}

With a Callback you can now do this:

void initWidgets() {
  /* ... */

  // Prime the timer.
  display.timerExec(INITIAL_DELAY, 
    new Callback(this, "refresh")); 
}

void refresh() {
  /* ... update stuff ... */
  
  // Set the timer again.
  display.timerExec(TIMER_DELAY, 
    new Callback(this, "refresh")); 
}

This is much easier to read and follow, at least in my personal opinion. If you agree, go ahead and grab the download below – SwtCallback is released under the BSD license so you should be able to integrate it with whatever you’re working on.

Download the source and binary here:

Download SwtCallBack. More information is available here.

There’s some extra javadoc in this release to make it easier to get started. Still, there isn’t much in the way of documentation – we’ll go back and write some if there’s demand for it.

           

Today WireLoad is releasing SwtCallback, a Java library for SWT that enables callbacks for event handling. SwtCallback is inspired by the Swing enhancer Buoy by Peter Eastman.

If you know you want this, just skip to the bottom of this post for the download link. Otherwise, read on and I’ll explain the reason we wrote this library.

I’m a big fan of readable and concise code. Another thing I’m a big fan of is user interfaces that look and feel like what users expect. Given this, I’ve always had an aversion to UI programming in Java. Because I think it’s very telling, I’ll let this flash video illustrate: totally gridbag. Bottom line is that in Java, user interfaces look weird and often attempts to alleviate this weirdness result in enormous amounts of hard to read code.

One solution is to use the Standard Widget Toolkit (SWT) instead. SWT enables easier UI building with resulting UIs that are both faster and look and feel better for the end user. What’s more, the code is more concise thanks to FormLayouts, sane widget sizing and the availability of standard functionality.

There’s one thing I think can be improved on though: readability. SWT code has a tendency to, like Swing, become littered with hundreds of listener classes, or worse, faceless listener implementations. For example, your code may look like this:

public class Demo implements SelectionListener {

...
   void initialize() { 
      Button myButton = new Button(shell, SWT.NONE);
      myButton.setText("Click Me"); 
      myButton.addSelectionListener(this);
   }
...

   public void widgetDefaultSelected(SelectionEvent e) {
      // I don't care about this event but I have to 
      // have a handler to satisfy the interface.
   }

   public void widgetSelected(SelectionEvent e) {
      // Do something
   }
}

Notice how the method named ‘widgetSelected’ has a very generic name: it has to since that’s the name it was given in the SelectionListener interface. Also, if there are many widgets that listen for selection events, then this single method has to handle all of them with a big if statement or some such. Not very readable. We also had to thumb on conciseness by adding one method which we didn’t even want: widgetDefaultSelected.

A better method is to associate the handler with only a single widget by using an inner class, and to use an adapter to avoid having to add a dummy method. This would typically look like this:

Button myButton = new Button(shell, SWT.NONE);
myButton.setText("Click Me"); 
myButton.addSelectionListener(new SelectionAdapter() {
   public void widgetSelected(SelectionEvent e) {
      // Do something
   }			
});

Much better. Less code, easier to read and it’s clear what ‘do something’ is associated with. But now we end up with a bunch of anonymous classes and deeply nested code. It’s still not perfect.

Enter SwtCallback. With SwtCallback, our final version of the program may look like so:

void initialize() { 
   Button myButton = new Button(shell, SWT.NONE);
   myButton.setText("Click Me"); 
   Callback.add(myButton, SWT.Selection, this, 
      "myButtonSelected");
}

/**
 * Called when myButton is selected.
 */
@SuppressWarnings("unused")
private void myButtonSelected() {
   // Do something
}

This has everything we wanted: it’s clear what the ‘myButtonSelected’ method does because it’s well named. There are no listeners to implement and no inner class bloat. The definition of myButton is short without being complicated or hard to understand. As an added bonus SwtCallback allowed us to make the event handler method private – this makes sense since the method is only relevant for the corresponding UI class.

UI programmers with experience outside of Swing will hopefully immediately recognize and appreciate the idea of callbacks. If you still need more reasons though, I’ll suggest a couple:

• Less code means fewer bugs and easier maintenance. Callbacks allow you to handle events without lots of extra classes or big if-else statements.
• You can link many events to the same handler. For example, maybe you have a ‘Quit’ button in a window. This button can have the same handler as the standard close event for the window.
• No need for dummy methods. Since you’re not implementing listener interfaces you don’t have to implement handlers for events you don’t care about.
• Natural names for methods. You’re not constrained to some standard name for an event handler. You can name your method ‘handlePasswordFieldGainedFocus’ if you want to.
• Private or protected event handlers. With interfaces your event handling methods have to be public. Most of the time they’re very specific to some UI classes. It doesn’t make sense for other unrelated classes to call your handlePasswordFieldGainedFocus() method.

If you still need more, Peter Eastman, the author of Buoy, expresses the rationale for callbacks much better than I ever could here.

SwtCallback is released under the BSD license. Download the source and binary here:

Download SwtCallBack. More information is available here.

Patches and comments are welcome. Apologies for the lack of documentation – if there’s interest in this library we’ll revisit it. For now, if you find it useful, great!

Update 1: SwtCallback 0.2 has been released.

           

My recent post about Wikipedia’s Wikia linking brought on some emotional responses. Since there seems to be some misunderstandings about what I’m arguing, I’ll in this post lay out what is hopefully a more succinct description of why Wikipedia’s actions are both unfortunate, and ironically enough promotes spam rather than combats it on a large scale.

First of all, please be mindful that nowhere am I making the argument that ‘spam is good’, nor that Wikipedia should be a platform for spam. You will notice that Playing With Wire is not linked to by Wikipedia, and that we have no direct self interest in the use or lack of ‘no-follow’ tags on Wikipedia. What I do have an interest in is the health of the internet as a whole, and I believe that there is a risk that Wikipedia is causing harm to this health with its recent actions.

At the crux of the matter is the way modern search engines separates spam from useful content. Google and other search engines separate valid content from spam by inspecting the way the world wide web is interlinked. A site is considered ‘trusted’ if it has many inbound links from other trusted sites. The theory is that since humans make most links, sites that are useful for actual people get plenty of human links over their life span, while spam sites only get links from other spam sites. If you score sites based on the quality of their incoming links, you will then over time see some sites rise above the general noise. As far as Google is concerned these are the ‘non spam’ sites – other trusted websites have confirmed their validity.

You will notice that there is something circular about this system – a catch 22 if you will. To know the trusted sites on the internet, you have to already know what sites can be trusted so that they may vote. To solve this apparent paradox, Google will seed the system so that every site has some kind of base trust. From there on Google starts to count: outgoing links ‘give’ trust to other sites, and incoming likes conversely ‘receive’ trust from other sites. A mathematical formula balances the total amount of ‘trust’ so that eventually a stable structure crystalizes.

You may think of this trusted structure as the sea with little trusted islands rising out of it. Google gives you good search results because most of the time it can find you an island rather than having to dive into the sea floor mud of spam and noise that is the general internet.

It is this structure and balance that makes Wikipedia’s choice of anti-spam technique so unfortunate. Since a lot of trusted sites have given their vote for Wikipedia, they have essentially lowered themselves a little bit into the sea in the process. Normally, this would be fine because when a trusted sites lowers itself in this way, it will cause other islands to rise. These other islands in turn give away some of their buoyancy to yet other islands, and so forth. In the greater scheme of things the mud stays on the bottom and the islands stay on top.

Wikipedia has over time built a very strong position within this system. Wikipedia is one of the most trusted sites on the web as far as Google is concerned. It still amazes me how often Wikipedia comes up right on top in search queries. Wikipedia is essentially one of very few mountains in our sea analogy. But by not voting on other valid sites, Wikipedia is pushing every other island back into the mud by its own sheer weight. Google can no longer give us as many valid search results because the islands are closer to the mud as compared to Wikipedia. These sites gave away their trust in the greater balance to a site that doesn’t give anything back.

In a system where you measure importance as the relative difference between the average and the peaks, having an enormous peak will reduce the effectivity of the system. What’s worse, Wikipedia is setting a very distressing example. Imagine for a moment that every site on the internet decided to do what Wikipedia is doing now, and only use no-follow tags for external links. This is in the individual interest of every site, as they no longer give away their votes. But in doing so, the whole system is ruined as every site would be reduced to the level of the mud.

Ironically, Wikipedia is promoting spam on the internet in the process of trying to rid itself of it.

           

A while back I wrote about Wikipedia’s selfish ‘nofollow’ linking. I made the argument that by tacking on the nofollow tag on external sites, Wikipedia is tricking Google and other search engines to think Wikipedia is even more important than it already is. Intentional or not, the policy causes some significant skew in search engine results due to how many people like to Wikipedia.

Turns out that Wikipedia didn’t focus the skew purely on itself. Techcrunch has noticed that Wikipedia gives Wikia preferential treatment. Wikia is a commercial project, in part founded by Wikipedia’s founder Jimmy Wales.

Again this is not necessarily intentional but the skew is yet worse now. Wikipedia collects massive numbers of inbound links without giving anything back to the web community. Instead Wikipedia channels its importance into promoting a commercial project of the founder’s choosing. This is very unfortunate.