The WaveConnector enables you to easily write complex GWT applications that can be tested locally.

You can download this either as jar to add to your own projects or as (recommended) turnkey zip file which includes an example setup. I haven't had time to document the jar very well yet so you should probably start from scratch with the turnkey solution.

The jar contains two GWT modules, one for local testing and one for deployment. I usually create three projects for every wave application and have one project inherit the WaveConnectorMock, one inherit the WaveConnectorImpl and one contain the actual application.

WaveConnector uses a modified version of the cobogwave wrapper for GWT. I have built an interface abstraction layer and a mock implementation on top of that

Dependencies (included in the jar and turnkey):

• gin/guice
• gwt > 2.0
• google gadgets for gwt api
• OneTwoGWT framework (not published yet)

Please make sure you have the Google plugin for Eclipse installed

I will probably post most updates over at my blog at http://thezukunft.com .

Using the Turnkey Archive

Using the turnkey is really easy.

• Download the latest turnkey archive from the left side. There is no need to extract it.
• In Eclipse, select File -> Import and look for "Existing projects into workspace".
• Select import from an archive file and select the downloaded turnkey
• Done. the turnkey comes with the example gadget from http://wp.me/pKZ6O-m
• To test locally: Run the GadgetTester
• To modify the gadget: Just change stuff in the YourWaveGadget project
• To deploy: Compile the yourWaveGadgetDeployment project and upload it somewhere (or simply use appengine)

Advantages

I realize that there are some wave emulators around (if somebody has links to that, please tell), but most of them don't seem to fit in well with GWT development best practices. The advantages of this method are

• Your Gadget is really only a UiBinder class
• It can be debugged locally in hosted mode
• You can run unit tests against your gadget (by manually firing wave events and watching what happens)
• communication with the wave is completely decoupled
• wave events are caught on a standard HandlerManager eventBus
• the wave object is provided by injection
• you will never see anything of the JS api lying underneath
• Most GWT applications can easily be transformed into wave gadgets like this (usual restrictions on networking apply)

The obvious disadvantage is that its very heavy and might be a little overengineered.

Random Notes and Hints

• If your refactor stuff, make sure to adjust the module definitions. Eclipse doesn't update them.
• The YourWaveGadgetDeployment project has AppEngine nature for easy deployment. This is not really required and you can remove the dependency.
• All events will run through the eventBus. Do not try to attach handlers to the Wave object. This is the core difference from the JS wave API.
• If you want to understand the dependency injection going on, note how the GinModules in the different projects inherit from one another.
• If you add classes to your main YourWaveGadget project that need to be injectable (like sub-widgets that need to be created by a provider), keep in mind to add them to GinModuleWaveGadget.java
• Use the Wave objects log function to log messages that are visible in the wave sandbox
• You can reduce the compile time of your gadget (because you will still be deploying it frequently) by adding something like <set-property name="user.agent" value="safari" /> to your module xml. (replace safari with your browser)
• All gadgets make use of the DynamicHeight feature. If you want to adjust the Gadget's height to fit the content fire a GadgetUpdateEvent on the EventBus.

Stuff that needs to be done

Of course there's still lots of things I'd like to do to make this into a really great library.

• Add manual modeChanges
• make this work with Maven and such (anybody here who can do this?)
• Add UI in GadgetTester to add/remove participants and to see each participant's view
• This is the final goal ;)