Thursday, September 23, 2010

WindowBuilder Pro brief sample – Part 1 of 3

Last week, Eclipse users received good news: Google relaunched Instantiations tools for free. Not just for GWT, but for all the technologies supported by the suite.

When I read the notice, my mind went back to 2005, when I tried to use Eclipse Visual Editor in a project. It was a little frustrating since the plugin didn't worked very well. Back in that moment, I didn't find any good free SWT/Swing editor for Eclipse.

Currently at Oxen, we have a customer that uses NetBeans. Since I´m an Eclipse fan, we always make fun kidding about which one is the best. But when the discussion turned about visual editor, it was clear that NetBeans surpassed Eclipse. Now, it's time for revenge :)

So, let's make a brief review of WindowBuilder Pro. The first step is to install the tool through an update site, as explained here.

There is another update site just for GWT Designer, but it seems that WindowBuilder Pro site includes all the tools (for GWT, Swing, SWT and so on).

The first thing that causes a good impression is the number of things that can be created using the plugin.




(wow, Mac OSX screenshots... today you can't make a post showing Linux/Windows images... it wouldn't be cool enough!!!)

Talking seriously... Too many options! We are going to try just some of them. Let's begin with a GWT project:



The second screen will ask us for GWT installation directory. If you don't have it installed, download it from here.


On the following screen, select “Create GWT module” and enter names for module and package:


The support for Ext GWT, GWT-Ext and Smart GWT is pretty cool. I would found it useful two years ago, when I developed an application using GWT-Ext (currently superseded by Smart GWT). Now I'm working in a project that uses Vaadin. But Vaadin support would be too much happiness for a single tool.

On the next screen, select a name for your project... and that's it! Your'e ready to edit the module with the two-way editor:



As a negative point, the first access to the editor is really slow. It seems that it uses something from GWT hosted mode. After the editor is started, it's use is relatively fast (well, I didn't tried creating very complex layout).

In order to test the application, select Run As → GWT Application over the project. This will start GWT in hosted mode.



The hosted mode requires installing a plugin on the browser. Too bad that such plugin is not available for Google Chrome on Mac OSX. I needed to use Safari.



So, that's all folks! (for today). It's late and I'm pretty tired. On next posts I'll make some examples with Swing and SWT. See you, good night!

Related posts:


Monday, September 20, 2010

Generic MVP with Properties and binding

A few months ago at Oxen we started an Android project. It was our first Android project (which made us very happy since we're working for iPhone until that moment :P - goodbye Objective C, at least for a while).

The application required a lot of forms (login, signup, etc.) and we built an ad-hoc FormBuilder class that dynamically binded UI fields to model beans. But this was an application-specific solution. We realized that Android didn't provided a form-to-bean binding facility.

For future projects, we stared a proof-of-concept: to build a generic binder for Android. After reading some sites explaining the Model View Presenter pattern, we thought that it would be possible to create a generic MVP implementation, not just for android, but in a technology-agnostic way.

Our first try was to abstract property and event acces. We built two interfaces:

public interface ActionAccessor {
   Observable getActionNotifier();
}


and

public interface PropertyAccessor extends ActionAccessor {
    Object getValue();
    void setValue(Object newValue);
}


Plus, we created a Binder class that connects properties, propagating changes from one to another. This allowed us to build a generic view presenter, with a generic presentation model, binded to both, UI components and to a bean model. We tested it creating both, Vaadin and Swing PropertyAccessors.

This model could be used to implement validations and data conversion.

The problem was that using such accessors was very verbose. We solved it by creating a name-convention-bean-like dynamic proxy. All this seemed to fit well.

When we where about to upload this proof-of-concept to Oxen Java Commons, I read the following links (from a post on The Server Side):

The idea of using a class for accessing properties instead of using name convention based beans seemed to fit very well. With that, the proxy will not be necessary. In fact, the author was promoting exactly the oposite idea: deprecating beans!!!

So, we made a refactor of the code to follow this approach. We used an interface instead of a Property class and added an Observable interface in order to handle events. The results are explained here:


We put a simple example where the same presenter is binded to Vaadin and Swing. Also, we created an Android implementation:


which was the first motivation for all of this.

This is just a proof-of-concept. Maybe it makes no sense to create too much verbose code just to make a presenter independent. Or maybe yes (we'll know after implementing this in a project).

The main doubt is if this model can be applied more generically, not just for simple forms (for example, for UIs with data lists).









Hello World!!

Hello, this is the first post.

The idea behind this blog is to post information the technical stuff used in Oxen Software Studio. It can be ideas, dicussions, research, etc. Anything that could be of interest, regarding software development (technology, methodolody, etc.).

Enjoy!

Lautaro