Deserializing/serializing JSON with GWT

A fairly typical use case: a GWT server-side component serializes java objects into Json, to be consumed by GWT clients.

Server-side serialization is actually very easy thanks to the google-gson library. It's literally a one-liner:

String json =new Gson().toJson(myObject);

On the client side things are a little bit more complicated. Gson (or any other library with features which are not supported on a GWT client such as reflection, dynamic class-loading, multithreading... ) cannot be used.

One possible alternative is to use autobeans

To deserialize a Person class

class Person {
   private String name;
   public String getName();
   public void setName(String s);
}

1. define an interface for the class to deserialize

interface IPerson {
   public String getName();
   public void setName(String s);
]

2. Mark the class to deserialize as implementing the above interface

class Person implements IPerson {...}

3. Define the interface extending AutoBeanFactory

interface Beanery extends AutoBeanFactory{  
   AutoBean <IPerson> createBean();
}

4. Instantiate the bean factory and deserialize

 
Beanery beanFactory = GWT.create(Beanery.class);
IPerson person = AutoBeanCodex.decode(beanFactory, IPerson.class, json).as();

Infinite scroll with GWT

The classical pagination pattern leads the user to click on numbered icons to navigate in a long list, each icon being associated with a different page in the list. This is how you browse google search results for instance. This is optimal when moving from page 1 to page 999, but not so much when moving from page to page in sequential order, which is the most frequent use case.

The alternative is the "infinite scroll" technique. Here the application detects when the user scrolls down to the bottom of the list, and automatically adds the result of the next page to the list. Scrolling can go on this way for as long as results are available to be added to the list, hence the term "infinite scroll". Obviously it's infinite in theory only... but I guess "very long scroll" doesnt have quite the same ring to it.

Building an infinite scroll component withb GWT is easy.... because it's already been done. Check out the GWT showcase  for an example. Or have a look at my side-project javadevjobs.com .

The key is in the ShowMorePagerPanel class (source code available from the showcase page) which listens for scroll events and  increases the display range when the it detects that the scrollbar has nearly reached its bottom position. This triggers in turn a rangeChangeEvent which acts as cue for the dataProvider to go and fetch more records from the database.

volatile piggybacking

Volatilty piggybacking is the (dubious ?) technique which attributes volatile-like semantics to non-volatile variables.

The new memory model , from java 5, states that "a write to a volatile field (§8.3.1.4) happens-before every subsequent read of that field".

i.e writing to a volatile field creates a memory fence, which will flush the data held in memory cache, so that anything visible to the thread writing to a volatile field becomes visible to any other thread reading that same field. 

The "anything" in the sentence above might be a non-volatile variable - which will end up being visible to all threads in the same way the volatile which initially triggered the memory fence is. Thus the former piggybacks on the memory flush triggered by the later.

Examples of this technique in core jdk classes are hard to come by (ie. I havent found any...) . Possibly a reflection on how fragile that technique is. 

First steps with GWT Bootstrap

Gwt-Bootstrap is the port for Gwt of the Twitter Bootstrap framework. Twitter Bootstrap  defines a set of javascript and css components which are used to kickstart the development of websites (at least on the client-side).

The idea is to make it easy to develop a reasonably-good looking website without too much effort. Although of course a truly polished result will require additional customisation work on top of the framework. Twitter bootstrap also provides advanced features out-of-the-box, eg. responsive design (the components size is automatically adjusted function of the resolution of the device they're being drawn on to). 

How to use.

The best way to learn is to download the Gwt-bootstrap sources from Github and study the examples provided... but to sum up:

- Grab the GWT-bootstrap jar , version 2.0.3.0-SNAPSHOT at the time of writing.

- Add the jar to your project build path (menu File->Properties->Java Build Path in Eclipse)

- In the gwt.xml config file add a reference to the gwt-bootstrap library.

 <inherits name ="com.github.gwtbootstrap.Bootstrap"/>

- Assuming you're using UI binder then add the following namespace to the <ui:UiBinder> element.

xmlns:b="urn:import:com.github.gwtbootstrap.client.ui"

- the bootstrap components are now ready to be used:

<b:heading size="2">Hello World</b:heading>

    

Downsides.

- Gwt-Bootstrap it's still a work in progress. Not all Gwt widgets have been ported yet, eg.CellTable is missing at the time of writing.

- Most sites built with bootstrap tend to look a little bit similar. Greyish tones, the top navigation bar and the "Hero" unit underneath are the usual dead giveaways.

Examples.

Builtwithbootstrap has an extensive collection of websites leveraging Twitter bootstrap.

For Gwt-bootstrap specific websites - the main reference is the gwt-bootstrap showcase.


Edit 1: my side-project also runs gwt-bootstrap. Check it out.

Edit 2: one of the GWT-bootstrap committer copies most of the above post, without attribution. Now - as the saying goes imitation is the most sincere form of flattery but still that's another point in the downsides section - dubious ethics from (some) of the developers on this project.

Comparing csv files with the linux shell

My heart sinks whenever I witness people resorting to Excel to compare large files. It's kind of ok when the files to be compared are below 10K rows in size... anything bigger than that and the time it takes to select the rows to compare (and the comparison in itself) becomes too much of a frustration.

The alternative is to use the command line of course.

To compare two csv files file1.csv and file2.csv, columns to columns, on a Linux operating system.

step 1. copy all lines containing the string to search from the first input file

grep 'searchString' file1.csv > f1.csv

step 2. extract the relevant columns (here columns 3,4 and 5)

cut -d',' -f3,4,5 f1.csv  > cols_f1.csv

step 3. sort on the 2nd column (for example)

sort -k2  -t"," cols_f1.csv > sorted_f1.csv

step 4. remove duplicates

uniq sorted_f1.csv > uniq_f1.csv

Quite a bit of typing here... and that's only to extract the columns from the first file. Fortunately all of these commands can be piped.

steps 1,2,3 and 4 for the second file.

grep 'searchString' file2.csv | cut -d',' -f3,4,5 | sort -k2 -t"," | uniq > uniq_f2.csv

And finally the last step.  Show all lines unique to file1, all lines unique to file2 and all lines common to both files, arranged in a 3-columns output

comm uniq_f1.csv uniq_f2.csv

The Guava Joiner - an example

Google Guava ships a nice utility to transform a list of strings into a single string, with invidual elements separated by a separator character.

import com.google.common.base.Joiner;
List words = newArrayList("abc","def","ghj");
System.out.println(Joiner.on(",").join(words));

is a replacement for the rather verbose:

List words = newArrayList("abc","def","ghj");
StringBuilder sb = new StringBuilder();
Iterator iterator = words.iterator();
if (iterator.hasNext()) {
   sb.append(iterator.next());
   while (iterator.hasNext()) {
      sb.append(","); 
      sb.append(iterator.next());
   }
}
System.out.println(sb);

Unsprung! moving away from Spring DI

Advantages of Spring (when used for dependency injection):

- separates configuration from the code. Thus the wiring of the application can be modified without recompiling, in theory. Not sure how often this happens in practice.

... and the cons:

-   Xml config files are easy to get wrong (no compile time checks obviously)
- Annotations spread through out the code are not terribly visible
- Error messages thrown by the framework can be cryptic at times

There is a simpler alternative. Do away with the Spring container and inject the dependencies manually. All that is needed is a class to inject the dependency, a context which creates the appropriate dependency, and a bit of application code to wire the two together.


A DbReader uses a constructor-injected datasource to retrieve database results.

class DbReader{

  DataSource dataSource;

   DbReader (DataSource dataSource){
     this.dataSource= dataSource;
   }

   public  Object fetch(){
    //use the data source to execute a database query
   }

A Context  holds a reference to a data source (mock or real)

class Context {

  DataSource dataSource;

  static Context liveContext(){
     //get production db data source
     DataSource dataSource = ...;
     return new Context(dataSource);
  }

  static Context mockContext(){
     // get in memory test db data source (or mock)
     DataSource dataSource = ...; 
     return new Context(dataSource);
  }

  Context(DataSource dataSource){
      this.dataSource = dataSource;
  }

  DataSource getDataSource(){
     return dataSource;
  }

}

Project classes inject the datasource associated with a live context in the DbReader constructor.

   public static void main(String args[]){
      Context ctx = Context.liveContext();
      //fetch data from a prod database
      Object result = new DbReader(ctx.getDataSource()).fetch();
   }

while integration tests inject a mock datasource from a mock context.:

   @Test
   public void Test(){
     Context ctx = Context.mockContext();
     //fetch data from  a mock or in-memory db
     Object result = new DbReader(ctx.getDataSource()).fetch();
     //assert that result is as expected...
    }

Simple, easy to understand (and to debug), compile-time checks in place, no messing around with xml configuration files (or annotations).

...and it's even simpler with the Unsprung project which can help generate the Context class above from a Spring configuration file.