5 Tips learned from building an large GWT application with Apptegic

I should really start with an apology.  For the past year or so I have been working at a fantastic startup and have really let my blog submissions slide.  So to the three people that have been sitting on the edge of your seats, I apologize.

So where have I been?

UNLOCK CUSTOMER USAGE DATA, DRIVE CUSTOMER SUCCESS
www.apptegic.com

In November 2011 I interviewed for a company called Apptegic.  A Boston based tech start-up that is helping businesses unlock their customer behavioral data to measure engagement and reduce churn.  There is a lot to that last sentence so lets break it down.

Unlocking behavioral data relates to how Apptegic integrates with your site and leverages data so you can understand what your customers are doing.  Using a customizable piece of javascript customer information is sent including user and account, coupled with any custom field key-value pair you want to record.  This information is processed and using our analytics platform you can view what your customers are, and sometimes more importantly, are not doing.

Engagement is a customizable measurement based on  key data, such as visit, user performed actions, and business information.   The measurement helps answer common key questions all web based businesses have:  How engaged your users?  How does this engagement change over time? Has engagement changed after releasing new features?

Reduce Churn:  A wise woman once said: "it is easier and more cost effective to retain a customer than to go find a new one".  Apptegic helps reduce churn by helping you understand what your customers are doing but also offers one distinct and important advantage.  Behavioral based messaging.   This is the killer feature, in my humble but biased opinion, whilst the user is in the application, and in real time, you can display messages based on their usage behavior.  The traditional model is to analyze stats the next day, build an email campaign based on usage, then send out an email two days later.  Ours is to collect metrics in real time, display relevant message whilst you are in the application, and increase your engagement with the product.  By informing you with relevant information we can prevent you from losing that customer - churning.

Using Google Web Toolkit at Apptegic

At Apptegic we have built a large scalable application using common techniques recommended by the GWT community.  Below are five tips that I would recommend to anyone building a large scale GWT application:

Tip 1: Scalability built-in

If you aren't using a design standard to build your application you are going to run into problems when you scale your application.  You'll end up in a spaghetti highly-coupled mess.  Believe me I have been there.  For GWT I recommend GWTP.  The guys over at GWTP are great.  Over the past several years they have built a mature useful MVP implementation for GWT.  I have used it on several products now and it just keeps getting better with time.  I will leave their own marketing to help with the promotion.  Grab the framework over at GitHub:  https://github.com/ArcBees/GWTP

Tip 2: Decouple, decouple, decouple
Use the Dependency Injection design pattern.  Separate all of your concerns into logical entities then when you need them inject them as a dependency via the constructor or autowiring a variable.  For GWT the only choice is to use Google's GIN framework.  If you know Spring DI it is the GWT client equivalent of @Autowired.
http://code.google.com/p/google-gin/

Tip 3:  Helping the UI
GWT Query is basically a JQuery implementation for GWT.  It has lots of helper methods for direct dom manipulation, binding events and animations.  We found it to be great at writing succinct code that achieves a great deal.  In addition it has an active plugin community which build various beautiful UI components.  We use their draggable implementation and a fantastic looking combo box called GWT Chosen.  Check out the GWT Chosen demo page its awesome.

GWT Query: http://code.google.com/p/gwtquery/

GWT Query Plugins: http://code.google.com/p/gwtquery-plugins/

GWT Chosen: http://jdramaix.github.com/gwtchosen/

Tip 4: Be careful when selecting Smart GWT

I am am split on SmartGWT.  The widgets that come with GWT are woefully short of being fully featured.  With SmartGWT you get fully featured widgets that are more difficult to customize visually.  The problem lies in being able to mix the two.  It is well documented that mixing SmartGWT with regular GWT widgets is not supported and from experience is painfully difficult to achieve successfully.  My guideline would be:  If you are building an internal product that requires a full feature set but you don't want to customize visually;  or perhaps you are trying to prototype an idea and wan't to get something up and running quickly; then go with SmartGWT.  If however you want to build a customer facing beautiful SaaS application then I would use native GWT and pick certain SmartGWT widgets selectively.

Tip 5:  Build-in Customer Usage Analytics

If you are building a customer facing website and you want to understand how your users are utilizing your product.  Then build-in analytics from the ground-up.  As I am biased I will of course be recommending our own product - Apptegic.  There are alternatives, so go check out the competition I am confident that you will like what Apptegic is offering.

UNLOCK CUSTOMER USAGE DATA, DRIVE CUSTOMER SUCCESS

Dart and GWT Videos from Google IO 2012

Google I/O 2012 - Dart - A Modern Web Language

Migrating Code from GWT to Dart

Putting the App Back into Web App - Web Programming with Dart

Subjective thoughts on best practice with GWT applications.

If you have spent anytime with me you know I love GWT.  But in my humble opinion there are ways to build web applications that still involve the gamut of javascript frameworks and bog-standard HTML5 and javascript.  Through my vast and continued learning experience of GWT I am beginning to see it in its current guise as being great for building complex and large widgets embedded in a web environment that is built in a more traditional web application framework.  Using the word tradition is kind of absurd in the web application design sphere because a tradition is established in a matter of months and then disposed for a new tradition within a couple of years.  However we appear to be heading towards a path of convergence in how and the way we code.  I recognise this as entirely subjective but for companies adopting GWT for the first time, experimenting with complex GWT widgets, then embedding them into their existing web applications is a great way to start on the GWT path.

Model-View-Controller (MVC) and Model-View-Presenter (MVP) are becoming the de-facto design patterns for building desktop, web and mobile applications.  Developers pay attention, if these are not on your resume, get them on there as fast as possible.  You should not leave home without it.  Many frameworks in almost every language develop according to this pattern.  So whether you are using Ruby on Rails, Grails, GWT, Spring MVC, Backbone.js they all design their frameworks around this convention.  GWT is a little late to the game with regards to this and so two additional frameworks have been around for a while which in my opinion currently offer a lot more features than the "Activities and Places" inbuilt infrastructure.  These two frameworks are GWT-Platform and MVP4G.   They are both on Google Code and both have extensive user collaboration and input.  Developing outside of GWT in the standard HTML-CSS-JS arena backbone.js offers a Javascript implementation of MVC.  I haven't used it as of yet but from the brief tutorials I have read it appears to be very easy to use.

In a similar vein, Dependency Injection is also a must have.  Design your code to interfaces and inject interfaces at runtime.  This is achievable in GWT using Google GIN on the client and Google GUICE on the server.  However my current overwhelming suggestion on the server is the Spring framework.  If you are writing Java server code and not using Spring, you are probably writing lots of boilerplace bullshit.  Stop it now!.  My server side framework knowledge is limited so would love to hear from other developers on alternatives, but from what I have seen this is well adopted, supported and promoted in the media and job adverts.  Spring is about more than Dependency Injection but this is at the core of the framework.  If you want to develop modular, testable code then you need to use DI.

Using the Facebook web site as an example lets look at how you might construct this from scratch.  Some GWT developers will suggest that the whole site should be built in GWT.  I disagree but more on that later.  However I believe that you will have a more flexible and productive if you develop the complex parts of your web site in GWT and embed them into the website.   So when looking at your newsfeed the complex box that controls updating your status etc might be a small GWT application but it is embedded in an AJAX-controlled feed panel table.  The reason I think this?  Unless your whole team consists of ninja, ex-Google GWT developers that worked on the ad-sense or ad-words interface, then you are going to experience delays in your project as you migrate your developers to a new way or working.  By concentrating complexity in small manageable chunks you reduce your exposure to delays in your project.

Spring Roo 1.2.0 with GWT and Google App Engine

I was first introduced to Spring Roo at Google IO 2010 and I was amazed with the product, it allowed a developer to prototype an application very quickly, building everything from the server, domain, and GWT client.  It looked awesome.

When I got home I realised that we were shown a fixed demo in that many of the features didn't really work when building on Google App Engine and Google Web Toolkit.  Not a problem as all developers know we are used to living on the cutting alpha-beta edge of software where great new features come with one huge caveat, they occasionally don't work.

That was then and this is now.  Like Sushi which I try every 6 months just to confirm that I still am not a huge fan, it doesn't taste of anything right?, I try the latest version of Spring Roo.

The Upgrade Path
Let me just say that I love SpringSource they provide a lot of excellent tools for the Java developer and the Spring Roo documentation is no exception.  The upgrade path is very easy, unpack the latest Spring Roo to a directory of your choosing, amend your $ROO_HOME variable in .profile (Mac OSx) and then re-establish the symbolic link to the roo command line.  (sudo ln -s $ROO_HOME/bin/roo.sh /usr/bin/roo)

Done and done!

The Bleeding Edge
So I tried Spring Roo 1.1.5 and it was giving me lots of errors with trying a GWT-GAE project.  It seemed as equally unreliable as I had tried with previous versions.  Let me just add if you are using a standard database such as MySQL or any of the other persistence options, I believe Spring Roo works just fine.  The problems I usually run into are related to the peculiarities of Google App Engine and how Roo handles those.

Since most of my current projects are currently in the GAE-GWT sphere and Roo advertises that it is suppose to work in this area, I decided to upgrade to the very latest Spring Roo, so I delved into the nightly builds and installed (1.2.0.BUILD-SNAPSHOT [rev 176e407]).

Go for 1.2.0 Its Much Better
After building a couple of projects with 1.2.0 I can honestly say this is the best version yet by far.  Why?  Well it appears to work this time for GWT-GAE projects.  Most of my personal work is done on Google App Engine.  This might change as I am not really liking the new billing restrictions but we will see how those actually plan out when implemented.

I typically build small projects that utilise some sort of reference between domain objects and then build a GWT project and then test it to see if it actually works.  I will deal with deployment in a different post.  What is great about Roo is that you can amend say the domain objects and the auto UI will get updated automatically.  Simply add the line : private String userName; : to your domain object, boot up Roo and it auto creates the UI amendments needed.  Pretty stunning.  I haven't yet got to work out how you prevent it from doing this should you want to improve the UI, but I am sure that will come soon.

The project I have built it is that for a taxi company to take bookings.  It includes three domain objects Contact, Booking and Journey.    A booking can have one or more contacts, and one ore more journeys.

A Spring Roo GAE GWT project that works
 Here is the contents of my Roo file, hopefully this will help you work with your project.

project com.prestige.booking

persistence setup --provider DATANUCLEUS --database GOOGLE_APP_ENGINE --applicationId PrestigeBooking

enum type --class ~.shared.domain.ContactType
enum constant --name Booking
enum constant --name Billing
enum constant --name Passenger

entity --class ~.shared.domain.Contact  --testAutomatically 
field string --fieldName fullName --notNull
field string --fieldName email
field string --fieldName phoneNumber
field enum --fieldName contactType --type ~.shared.domain.ContactType

entity --class ~.shared.domain.Booking --testAutomatically 
field reference --type ~.shared.domain.Contact passenger

entity --class com.prestige.booking.shared.domain.Journey --testAutomatically 
field date --fieldName journeyDate --type java.util.Date 
field string --fieldName startAddress 
field string --fieldName endAddress
field string --fieldName startTime 
field reference --fieldName booking --type com.prestige.booking.shared.domain.Booking 

loggin setup --level INFO

web gwt setup

Next Steps
If you have used Roo or have done some interesting things with a Roo project please get in contact.  I have yet to explore the AddOns or detailed more information on the workflow in a Roo project that goes from prototyping to real world application.  Get in contact and lets document some Best Practices for this awesome product.

XML to POJO Mapper for GWT using a GDATA Example with Google Contacts (ContactEntry).

If your like me I dislike cowboy coding.  You are hacking away at something to get the job done, but the nagging thought at the back of your head is telling you "You kow you shouldn't be doing this".  The best path maybe unavailable because a lack of experience, or perhaps we are unaware of suitable boilerplate-removing framework.  We've all been there time is in the essence, deadlines are pressing and your new TPS Reports Engine needs to be delivered yesterday.  Well I found myself in such a quandry recently and found a tool which will solve a common problem for many GWT developers. So instead of waffling what actually is the problem?

Imagine an application that communicates with Google Contacts.  Server-side you receive a an atom-rss feed representation of a contact in the form of a ContactEntry object.  Google kindly provides you with GData POJOs which are already populated with the information you require.  On the server this is beautiful, Google has done all the hard work and the POJO is populated with data.  If you were using the wonderful Spring MVC you could render the contact information very easily.  However you are a profound, if not magical developer that has the GWT Swiss army knife in their toolkit, and you want to send this POJO to the client.  In the words of Mr. J. Carrey you reach the Alrighty Then brick wall of stoppage.  The ContactEntry POJO is not serializable to the client.  Or is it?

One giant caveat is that I maybe encountering a newbie problem and someone may have created an easy way to make GData objects serializable for sending over GWT-RPC, but at present the only way I have found to do it, is manually, i.e. boilerplatery.  Create my own ContactEntry objects on the server and populate them.  This obviously involves copious amounts of repetition.  It can be done this way, and is the way I have done it in the past, before I knew better, but it isn't efficient. 

Lets recap:  We want a solution to send a GData ContactEntry object to the GWT client that we can use in a POJO, without becoming America's best plumber to create all the additional boilerplate code.

My proposed solution:  Send the XML as a String to the client and use a fancy GWT plugin, Piriti, XPath to auto populate a client side POJO.  Quick, efficient and maintainable.  So how do we do this?

Caveat:  If someone has a better way of doing this please let me know.  I am all ears.  This may not be the best solution and I would love to know how anyone else has tackled this issue.

Step 1: Extract XML
Lets assume you know how to get the ContactEntry from Google using their GData library but now you want to convert that into XML to transport to the GWT Client:

public String getContactEntryXml(ContactEntry entry) {
StringWriter sw = new StringWriter();
String entryXml = "";
try {
XmlWriter xw = new XmlWriter(sw);
entry.generate(xw, contactServiceFactory.getBasicContactsService().getExtensionProfile());
entryXml = sw.toString();
} catch (IOException e) {
e.printStackTrace();
}

return entryXml; // sw.toString();
}

Step 2: Transfer to Client
I am assuming you know how to write GWT applications and communicate back and forther between the server and client.  There are man built in libraries to do this, GWT RPC, Request Factory, and may external third party modules; net.customware.gwt.dispatch, GWTP etc.
Step 3: Create POJO
The key here is reaally the library we are going to use.  After looking at many examples I am using Piriti's library.  It appears to be well used and has good documentation: http://code.google.com/p/piriti/

Piriti (Maori for "bridge") is a JSON and XML mapper for GWT based on annotations and deferred binding. The following code snippets show the basic idea behind Piriti.   

So create a POJO and add these lines to the top of your POJO class:

public class ContactEntrySoho {

public static interface ContactEntrySohoReader extends XmlReader { }
public static final ContactEntrySohoReader XML = GWT.create(ContactEntrySohoReader.class);

These lines are used when mapping the POJO members to their XML nodes.
Step 4 : Map atom:title to an instance member
Let's start easy lets map the atom:title entry of the ContactEntry XML.  First it is probably worth taking a look a the XML:

<atom:title type='text'>Alan UserA1</atom:title>

Now lets look at how we would map this using XPath in the Pojo:

@Path("atom:title") private String title;

For a more in-depth view of XPath look online for various cheat-sheets and tutorials it is very powerful and very useful.
Step 5 : Load the Pojo
All we need to do now is load the POJO with information to do this see the below:

@Override
public ContactEntrySoho parse(String xml) {
try {

Map<String, String> namespaces = new HashMap<String, String>();
namespaces.put("atom", "http://www.w3.org/2005/Atom");
namespaces.put("gContact", "http://schemas.google.com/contact/2008");
namespaces.put("batch", "http://schemas.google.com/gdata/batch");
namespaces.put("gd", "http://schemas.google.com/g/2005");
Document doc = new XmlParser().parse(xml, namespaces);

//Document doc = new XmlParser().parse(xml, NAMESPACES);
ContactEntrySoho sContactEntry = ContactEntrySoho.XML.read(doc);
return sContactEntry;

} catch (Exception e) {
return null;
}
}

The namespaces tell the parser what the tag mean and correspond to the root note elements of the ContactEntry XML:

<atom:entry xmlns:atom='http://www.w3.org/2005/Atom' 

xmlns:gContact='http://schemas.google.com/contact/2008'  

xmlns:batch='http://schemas.google.com/gdata/batch' 

xmlns:gd='http://schemas.google.com/g/2005'>

Remember those additions we added to the POJO we simply call those (XML.read) to parse the xml Document.  Et Voila!  You have your own POJO created with hatever components from the XML you require.
Step 6 : A more complex example please sir.
As you can see I have chosen the easiest node to map and as all articles which only go into the most basic of examples infuriate me, I shan't do the same here.  Let's take a look at an example where we need to map to another POJO.  Take the StructuredPostalAddress component of the ContactEntry class.
The XML in ContactEntry:

<gd:structuredPostalAddress primary='false' rel='http://schemas.google.com/g/2005#home'>
<gd:formattedAddress>6217 Woodlawn Ave N, Seattle, WA. 98103</gd:formattedAddress>
<gd:street>1234 Acme Ave N</gd:street>
<gd:postcode>11111</gd:postcode>
<gd:city>Seattle</gd:city>
<gd:region>WA.</gd:region>
</gd:structuredPostalAddress>

The data in our parent ContactEntrySoho class:

@Path("//gd:structuredPostalAddress") private List<GDStructuredPostalAddress> gdStructuredPostalAddresses;

Wait what is GDStructuredPostalAddress? This is another POJO with the headers defined in Step 3.

public class GDStructuredPostalAddress extends ABaseElement{

public interface GDStructuredPostalAddressXmlReader extends XmlReader<GDStructuredPostalAddress> {}
public static final GDStructuredPostalAddressXmlReader XML = GWT.create(GDStructuredPostalAddressXmlReader.class);

@Path("gd:formattedAddress") private String formattedAddress;
@Path("gd:street") private String street;
@Path("gd:postcode") private String postcode;
@Path("gd:city") private String city;
@Path("gd:region") private String region;

Et Voila! I found when using this that the POJO members sometimes had to be public otherwise they wouldn't populate but this problem was intermittent, so I am unsure whether this is an issue with Piriti's excellent XML->POJO Mapper or my inept code ;).
I would love to hear how other people are doing this as this seems like a good solution but I am sure there are many others.

Integrating GWT applications into the Google Apps Marketplace

This article examines how easy it is to integrate a GWT application into the Google Apps Marketplace. Application stores are becoming the de-facto method to distribute software. It is a clean, secure and hassle free method of introducing users to a large software base. In the near future Google will be releasing an application store for chrome to distribute software, and it currently offers a business software alternative for its Google Apps users. This article takes a look at how easy it is to change an existing GWT application for integration into the Google Apps Marketplace.

Google Apps is the term used for a suite of applications that run under your own domain name. You get the Mail, Calendar, Documents, Sites and overall Google experience but it is configured to run on your own domain. A recent extension to this is the Google Apps Marketplace which allows anyone with a useful application, to integrate into the Google authentication and authorization system. Thus allowing the user a seamless experience through their current Google applications and any third-party applications configured to run on this system. The power of this feature cannot be underestimated.

Opening up the Google Apps world to all application developers provides developers with a easy to integrate revenue stream and customer marketplace. Whilst providing the end users with an easy to use configure application store for Google Apps. This is a win, win situation. No whilst it is easy to see how this will be a benefit for web application developers it might be interesting to see how easy it is in practice to integrate your application into this system.

Background Reading

You didn't think I was going to do everything did you? I would seriously recommend reading this article first to get an overview of what we are trying to do here. This gives an overview from a development perspective of what we are trying to achieve.


Writing your First Marketplace App using Java: http://code.google.com/googleapps/marketplace/tutorial_java.html

In addition this page gives a rough overview of the whole process including development, but also submission to the Google Apps Marketplace:
http://developer.googleapps.com/marketplace

On your marks...

The application I am discussing is, my often touted, Simple CRM application, Soho CRM (http://sohocrm.appspot.com). It is a small business focussed CRM system aimed at the small business market. The application is developed in GWT, using Java, and is deployed to Google App Engine.

As you can see from the picture the application looks like a Google application with the familiar toolbar users come to expect. What follows is the process involved in converting this to fit into this architecture.

Step 1 : Create Vendor Profile

In order to get anywhere in this system you first need to become a vendor. The overview page here, http://developer.googleapps.com/marketplace/getting-started, explains how to do that in the section "Becoming a Vendor".

Step 2 : Download Code

Google provides us with an example application which you can deploy to Google App Engine and integrate into your own vendor profile in the Google Apps Marketplace. This code is located here:

Google Apps Marketplace Hello World Java

Step 3 : Integrate code
If you understand theory then the developer resource above would have been good enough for you. I prefer real code so I can create my own internal models of what is happening during this process. To get started I copied all the code in the directory:

\helloworld-java\src\main\java\com\google\code\samples\apps\marketplace

to a marketplace pacakge in my own GWT code

~\server\marketplace\

I also flattened the package all files required existed in this package and it wasn't distributed amongst several packages like it is in the example.

I also renamed the OpenIdServlet class to GoogleAppsOpenIdServlet because regular open id users can already log into the application and I didn't want the classes to become confusing.

GuiceModule.java: This file is in the downloaded code but not in the integration above, because this application already had GUICE configured. I simply took the code from the HW example and integrated it with my own.

ConsumerFactory.java: This file was excluded because again it wasn't required.


A final step in this process is integrating all the required libraries. The downloaded code comes with a library folder to make this easier.

Step 4 : Map Servlets
Examination of the web.xml file reveals the servlets you need to map. These can either be setup here, or if you have a code alternative set them up there. You will need to record what URL is used as the OpenID authenticator as this is sent to the Google Apps Marketplace when you install your application.

Step 5 : Create the manifest file
By this stage your application will be ready for installing. You just now need to configure Google Apps Marketplace to accept your application. The first step in this process is creating the manifest.xml file. This file is a configuration file which tells Google Apps the name and description of your application; how to authenticate; and what Google Services the application should be given access to. The manifest is quite an extensive piece of kit so the full explanation on the file is listed here:

Creating the manifest: http://code.google.com/googleapps/marketplace/manifest.html

Step 6 : Getting Excited - We are almost there!!!
The next stage is to add the application to the Google Apps Marketplace. The vendor profile was created earlier, so after navigating to that URL : https://www.google.com/enterprise/marketplace/viewVendorProfile
You should now be able to see a button which says "Create new listing". Click that button and fill in your application details.

Make sure you check the button "My product may be directly installed into the Google Apps domain". This then reveals the Manifest box in which you will place the manifest.xml code to set the application up.

After completing all the sections click "Save and Preview". On the screen that follows do not publish your application as you will first need to test it.

Step 7 : Grab oAuth Key and Secret
Back on the application listing page of your vendor profile your application should now be listed. If the stages above were completed correctly then a new link "View OAuth Consumer Key" will show under the application. Click this and record this information as you will need it to authenticate your application.

Step 8 : Add oAuthKey and Secret into web.xml.
If you are following the Hello World example then you will need to place the OAuth Key and Secret into the web.xml file. This correctly identifies your application to Google which will then authorise you to view the users OpenId details.

Step 9 : Integrate the user logon process into your application.
In the doPost method of the OpenIdServlet you can see what the application does after authenticating a user. In this section you need to introduce whatever code you need to setup the logged in user. In my code this involved setting the session.user variable to the current user. Then simply redirect the user to the application home page.

Step 9 : Test
If all has gone well then you should be ready to perform two important tests:
1) Installing this application on your domain.
2) Testing the application as an end user.

Installing: Is easy enough. Go to the marketplace home page for your application and click the button "Add It Now". This simply takes you to the domain administrator page for this application and gives you the option of installing the application or not.


Testing: Once installed simply log into your domains mail application and on the right hand side where the more dropdown shows your application should now be visible.

This is where most of my time was spent developing this application. I haven't worked on many OpenID projects so understanding the concepts was a large part of this, but the Hello World example given was very helpful in solving the problems involved. This article, although long, is a cursory look at the steps involved. Any readers wanting help, or more explanation on any of the steps, please let me know and I would be glad to help.

Initial Thoughts on Vaadin : Not so much a GWT complement more of a replacement.

I have had the intention for a while now to try and comment on the Vaadin framework.  The website, plugins and demos exude confidence for this comprehensive toolset.  After a commentator on my last post  suggested that I try the framework, I took this advice and proceeded through the tutorials.

The address book tutorial is a great introduction to the framework, the web application demonstrated is quite comprehensive and is fairly boiler-plate code free.  Check out my finished application here: http://thinktaxi.appspot.com.  I, like most developers, dream of the ultimate framework where we can get on with just programming the logic of the application and the boiler place code is handled beautifully and efficiently by the abstraction the framework provides.  It is like the search for the Holy Grail, except of course I hope one day that this framework may actually exist.

Vaadin is advertised as being: "Built on GWT-based widgets, Vaadin applications support all Ajax-capable browsers, with no plugins."  This is a true statement but after completing the tutorial I feel that this needs further explanation.  Vaadin runs completely on the server, using GWT as a container.  The integration of GWT and Vaadin appears to be quite separate.  An initial peruse around the documentation may lead you to think that Vaadin is a set of GWT-Widgets that can be used to dress up your typical GWT application.  This assumption maybe false.  I say maybe because I am fully expecting a Vaadin expert to correct my assumption here.  Vaadin is almost completely separate to GWT and shouldn't really be considered to be part of it.

So, Vaadin runs on the server, which allows you to write complete Java code, a "benefit" when compared to GWT in which you are allowed to use certain Java libraries in the client code.  However the downside is that everything you do in Vaadin involves a trip to the server.  This in itself is a crucial point and raises the question.  How efficient can Vaadin be if everything requires a round trip?   An additional downside is that you are learning a whole new architecture system on top of GWT.  Which restricts your future solutions if your companies knowledge base is Vaadin only.

Anyway I am not a hater.  Although I am a GWT fanboy so Vaadin lovers prepare to feel the love. What applications might make Vaadin a good solution.  Well I think the quick small utility type applications that maybe used on an intranet or for just one company might be the answer.  In business, typically the speed of development and deployment is more important than how well your application performs.  The function of the application may never reach more than 100 users, so the load on the application will never be high.  I was very impressed by the speed and complexity of the application developed through the tutorial and I could see many benefits for RAD development.

In summary Vaadin good for small business development, but it is not a GWT framework contribution and shouldn't be considered as such (If you made that assumption like I did).

The increasing importance of GWT

Google Web Toolkit is a fantastic piece of kit.  As a developer, or as anybody really, when you do a repetitive task for any period of time you become fully aware of the problems associated with it and how to improve them.  Microsoft’s take on this problem is to make applications prettier, and more complex, whereas Google and Apple, try to increase complexity utilizing simplicity.  My personal opinion is that GWT addresses this by making web application development a lot simpler at every stage of the software lifecycle.

It is clear to any academically minded individual that open source is the best route forward because it takes in the ideas of the people you are trying to encourage to adopt.  There is an instant connection and contribution between you and your client base.  As the web develops in complexity it is increasingly important that a robust top to bottom professional framework exists to develop complex and layered applications.  Developers are increasing excited and frustrated with the multitude of decisions required for any web product.  GWT helps with this problem by providing a toolset that addresses many layers in the stack.  The proof is also in the proverbial pudding.  If you think Google Wave is a good product, then wouldn’t you like to use the same toolset that was used to produce that?  Take a look at the popular websites on the web, very few, I am aware are developed using Microsoft technologies, and the ones that are, feel like they have been developed by Microsoft technologies.

The success of the iPhone, iOs and Android platforms is clear.  The business model clearly works.  At Google IO 2010 the Chrome Applications store was announced which will provide another one stop shop for people to try and buy web applications.   With  HTML5 on the horizon it is clear these applications are becoming feature rich and their complexity and adoption is likely to increase exponentially.  As a result it is essential that the developer be allowed, to use a professional programming language, top to bottom in the software stack.  It makes life easier, more robust, and fulfills the need to program professionally.  As we move towards the cloud, frameworks such as GWT, will increase in importance as the de-facto choice for cloud based web application programming.

Objectification is not always bad.

We are like things that make our lives easier, unless the task of completion is the glory unto itself.  When it comes to GWT and JDO, a nice layer of abstraction exists already so it is easy to develop a data model and implement it in your system.  When GAE is added into the mix, which isn't really a relational database, certain nuances make the implementation just a little more complicated and so any library which helps with this operation is warmly welcomed.  The downside is that you are building your application specifically for Google App Engine, rather than any DB which implements JDO.

Luckily, I Love Google.  Google I Heart You... And so that is where Objectify steps in.  Objectify is a layer which sits on top of your objects to provide easy, get, put, delete and query operations into your Google App Engine database.  At this stage I am just promoting and highlighting this functionality but will be soon posting examples of how to use this system.

How to create a custom event handler in GWT

After struggling for longer than I should have I need to document the process partly for my own benefit and because if I struggled then someone else probably will as well.   So what am I documenting.

Scenario:
You have created a custom control Composite and want to implement a custom event for your control.  For example in the same way a button has a click event which is handled by the controls that use it.

Technology:
GWT 2.0, Java

Solution Outline:
In this example we are using a paging control as the example.  This is a custom control that aims to replicate the kind of functionality as seen in the next, first, prev, last and message functionality when navigating between emails.

Step 1: Create the custom event - PageChangedEvent

The PageChangedEvent will be fired when ever a paging action takes place.  For instance if a move next, prev, first or last action is called.  The code is pretty self explanatory but for clarity I have separated the code into the boiler-plate section and the code specific to this event.

public class PageChangedEvent extends GwtEvent<PageControlHandler> {

// Boiler plate code required to make your event work correctly in the GWT system

private static final Type<PageControlHandler> TYPE = new Type<PageControlHandler>();

@Override

public com.google.gwt.event.shared.GwtEvent.Type<PageControlHandler> getAssociatedType() {

return TYPE;

}

@Override

protected void dispatch(PageControlHandler handler) {

handler.onPageChanged(this);

}

// Code specific to this custom event

public enum PageChangeType {

first, prev, next, last

}

private final PageChangeType pageChangeType;

public PageControlEvent(PageChangeType pageChangeType) {

this.pageChangeType = pageChangeType;

}

public static Type<PageControlHandler> getType() {

return TYPE;

}

public PageChangeType getPageChangeType(){

return pageChangeType;

}

}

Step 2 : Advertise that this control has this types of events
In the PageControl which has these kinds of events we need to advertise this fact to the other classes, therefore the control will advertise this by implementing an interface called HasPageChangedHandler:


public class PageControl extends Composite implements ClickHandler, HasPageChangedHandler {

However this interface has yet to exist so we need to create it:


import com.google.gwt.event.shared.HandlerRegistration;
import com.google.gwt.event.shared.HasHandlers;


public interface HasPageChangedHandler extends HasHandlers {


  public void addPageControlHandler(PageChangedHandler handler);
}


This invites other parent controls to use this event by registering a PageChangedHandler with this control

Step 4 : Create the PageChangedHandler Interface
The handler interface indicates what type of events, or methods are required when implementing a handler of this type:


import com.google.gwt.event.shared.EventHandler;


public interface PageChangedHandler extends EventHandler{

 void onPageChanged(PageChangedEvent event);


}


Step 5 : Implement the methods in the composite control
In Step 2 we implemented an interface, and Step 3&4 we created those interfaces now we need to go back to the PageControl and the unimplemented methods.


@Override
public void addPageChangedHandler(PageChangedHandler handler) {
addHandler(handler, PageChangedEvent.getType());
}


This is an important step.  This registers the handler for this type of event.  The "addHandler" method is part of the GWT Widget class and is native to GWT.  Therefore this method doesn't need to be created.

Step 6 : Wire up the parent control to respond to onPageChangedEvents
There are a myriad of ways of doing this but assuming the parent control has only one page control then I wired it up by implementing the PageChangedHandler onto the main class:


public class MainSearchPresenter extends PresenterImpl<MainSearchPresenter.MyView, MainSearchPresenter.MyProxy>
implements SearchChangedHandler, ContactAddedHandler, ShowSearchResultsHandler, PageChangedHandler {

Which then shows the method that is run when a PageChangedEvent is called:

@Override

public void onPageChanged(PageChangedEvent event) {

if (event.getPageChangeType() == PageChangeType.next) {

getView().setupPager(1l, totalRecords, 20l);

}

}

However this will not work yet as we haven't registered this class as being ready to accept incoming onPageChanged requests from the pageControl.  Therefore whereever you bind up your controls, which will differ depending on what framework you use then you will need to add something like this:

pageControl.addPageChangedHandler(this);

If you were implementing this an anonymous inner class then this kind of setup would be used, which is very similar to the click handlers which are often implemented.

pageControl.addPageChangedHandler( new PageChangedHandler(){

@Override

public void onPageChanged(PageChangedEvent event) {

if (event.getPageChangeType() == PageChangeType.next) {

getView().setupPager(1l, totalRecords, 20l);

}

}

});

Step 7 : But wait - how do I fire this event from the child control?
Using whatever constructor arguments you require depending on the  type of event to fire then you simply call the composites native fireEvent method.



  this.fireEvent(new PageChangedEvent(PageChangeType.first));

Conclusion
This took me a day to figure out.  Ouch.  A lot of it had to do with getting confused with the old listeners method.  Which you should ignore if you are using 2.0 GWT or higher.  But there were plenty of code examples, which weren't quite complete.  I am hoping that this might help a newbie in the future like myself understand this process better.

All aboard the GWT-Platform

GWT is a fantastic tool but after building a fairly simple application I realised that my code had a sort of spaghetti quality about it.  Which may be fine if I was cooking some delicious Italian recipe, but is far from ok if I am trying to construct a logical, maintainable and scalable application.

After attending Google IO 2010, and having previously used the MVC paradigm in Python and Ruby on Rails, and after reading several Google articles on the framework I decided that this "sort" of architecture was the way to go.  Google recommends the MVP framework and so this is the approach I initially took. After reading the articles and going through the Contacts examples it was easy to see, although I didn't fully understand, that this approach was very logical.  However, I don't really like using however as a linking word as it indicates a lack of vocabulary, but anyway, and however, I ultimately decided not to go with Google MVP because their examples didn't cover enough of the scenarios I needed to see before I could fully move on in converting sohocrm.appspot.com to this framework.

That's when I came across GWT-Platform which is headed by several very knowledgeable people and which incorporates MVP, Dependency Injection, Command Pattern and an RPC dispatcher into one framework.  So many bases covered in one framework, could this be the way to go?  After reading their documentation and completing the examples it seemed this could be the choice.  They have some simple examples and one very complicated (PuzzleBazar).  Which after you delve into answer most of your questions, along with the responsive discussion forum over at GWTP Google Groups.

After reviewing their new contributors issue list over at Google Code.  I decided it was time to get involved and the Clean up Wiki issue seemed the way to go.  As I will still be learning this framework for many months to come, I shall be bothering Philippe Beaudoin at the discussion forum, in trying to come up with and answer many F.A.Q. questions new users to the framework may have.  At the moment I feel like I am, not quite at the rabbit hole, but sometime next week I hope to step through it.

In summary.  GWTP has a lot of interesting features in one package, and while it might take some upfront work in learning the framework, the OCD inside all of us will be satisfied by its logical approach.

Newbie confronts GWT, GUICE, GIN, MVP and Dependency Injection.

Well the life of a fairly new Java developer is interestingly complex.  I guess that is why I love computer programming its like solving little puzzles all day long.  Studying the concepts of OO using Java has been very interesting and has given my skill set a new edge.   Originally I come from an engineering background and have learned computer programming on-the-job.  This technique has gotten me through the last ten years of investment banks, universities and blue-chip companies but it hadn’t left me with a very good design metholody when it comes to applications.   I utilised OO rudimentarily, using classes as containers for similar functionality.  In the main still running a procedural based programming paradigm where most parts of the application have to know what the other parts are doing for it to work correctly.  Highly coupled you might say….

So where am I now?  Well through a process of SCJP training, examining example code, watching Google IO sessions, and attempting to program a small GWT application.  I am a lot clearer on some aspects, but on others, well this adventure has opened up a great many doors on how to design my programs.

Two design patterns which are paramount in my opinion for good design are Dependency Injection and a MVP architecture?  Why you may ask?  In short Google uses them and that’s good enough for me.
MVP stands for Model View Presenter and is similar to MVC except in our case the view knows nothing of the presenter, so you can swap out the views for different ones, i.e. a web page or an Android application, and your application still works.  As long as your view implements its relevant presenters interface. 

As a design pattern this approach appears to be very good and the example Contacts application that Google provides helps clear up any confusion from purely reading the articles.  What is interesting with the example is that the core of the application is demonstrated very clearly, allowing other developers to easily pick it up, and event bus and rpc handling is centralised, removing the ugly spaghetti code, that I currently, but have not yet talked about.  

At the moment I have developed a very simple CRM application using GWT located at: http://sohocrm.appspot.com.  Completing this project allows me to get my feet dirty and by doing so has lead me to these design methodologies which I now have to attempt to embrace and learn.  I can feel my brain whirring as I try to understand these concepts. 

So MVP is a good pattern because it gives a very clear architecture on how your application works.  However in order to clear up more of the spaghetti code we also need to utilise dependency injection.  Now I only have a basic concept of this, so please correct me if I am wrong in what I am about to say, but DI is this.   When instantiating an object you create additional objects which are utilised in order for the object to complete its class.  This might be any object which is declared with a new keyword.  What this means is that the current class is dependent on these other classes in order for it to work.   The dependency component.   Now in order to write modular code and to make testing easier, it would be good to have any dependencies injected into the constructor as an instance when the object is created.  That way you can clearly see what classes your objects are dependent on and it allows modular testing to be a lot clearer.  I think it applies to only classes which exist within your current project as I don’t think you will be injecting in int's, textboxes etc, but the exact delimination of this area is unsure at the moment – for myself – and I hope to clear that up over the coming weeks.    Google uses a product developed by itself called GUICE to do this on the server side java and another called GIN which is a GWT version for the client side.

How did I come across these technologies?  Well after building that relatively small application I noticed how spaghetti looking my code was and realised early on that this can’t be the way much larger programs such as Google Wave are constructed so realised, intuitively knew as we all do when we are accomplishing a task we aren’t quite proficient at, that there must  be another way.

So the next stage of my application is to re-write it in a MVP style.  Then take a look at how I can implement Gin and Guice to build a scalable, understandable and modular application.

GWT and Spring Roo Has Great Potential

After messing with Spring Roo and GWT yesterday I can confirm three things:

1. The potential of this is amazing.
2. It isn’t quite ready.
3. Did I mention that this might be amazing?

Spring Roo is a command shell that, as far as I can tell so far, I have a feeling I might be only scratching the surface, creates much of the boiler plate code that we get bored of creating.  By using an automated solution it allows the development of the code to increase, raises quality and allows you to develop application very quickly.
By entering a series of commands into a roo shell on the command line or in the Spring Source Tool Suite Roo Shell you can create an application configured with different databases and database providers.  Whilst developing the data structures and GUI interfaces required for them.
In order to increate my understanding of Spring Roo I am heading to the command line and following their tutorial to increase my understanding.
Here is an example script:

mkdir hello
cd hello
roo
roo> hint
roo> project --topLevelPackage com.foo
roo> persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY
roo> entity --class ~.Timer --testAutomatically
roo> field string --fieldName message --notNull
roo> hint controllers
roo> controller all --package ~.web
roo> selenium test --controller ~.web.TimerController
roo> gwt setup
roo> perform tests
roo> quit

It is quite readable and quite amazing!