Fwd: [Java-gnome-developer] Project

[Jeff M. <ku...@gm...>]

Forgot to copy the list.



---------- Forwarded message ----------
From: Jeff Morgan <ku...@gm...>
Date: Apr 25, 2005 10:31 AM
Subject: Re: [Java-gnome-developer] Project
To: Rafael George <geo...@gm...>


On 4/25/05, Rafael George <geo...@gm...> wrote:
> Hi guys, i have a long time just checking the list and stuff, right
> now im thinking in creating a new project Wireless based, but i have a
> doubt another person that will work with me want to do it using C# on
> Mono he saids that its faster to use GTK# instance of Java-Gtk, is
> there some benchmark out there and which are the pattern design better
> to follow to get a solid application.

I am not aware of existing benchmarks.  My view is that you would find
very little difference in the overall performance of the two frameworks.
If you do conduct a benchmark please report the results back to this list.

The strength of the Java-GNOME approach is in the combination of the
framework, the compiler (gcj supporting both bytecode and native) and
the development environment Eclipse.  Java-GNOME running natively
is quite fast and is currently confirmed running on 8 hardware platforms.
We even have Windows support now.

If I were developing a GUI application using Java-GNOME I would take
the following approach:

1) Use TDD to develop the domain model.  This should contain no visual
code and should be functional and complete before moving to the next step.

2) I would use a variation of the Model / View / Presenter design pattern
for the user interface. You can read about this patter here:

http://www.martinfowler.com/eaaDev/ModelViewPresenter.html
http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf

Details of my specific implementation are:

a) Use glade to create the user interface.  Do not write any code at this
point - just model the look and work flow of the application.

b) Use TDD to develop the View.  I would create a mock object to represent
the Presenter at this stage.  This effort will flush out the interaction be=
tween
the view and presenter and allow unit tests that do not require a GUI.  Onc=
e
this is complete move to the next step.

c) Create your Presenter using the glade file you created earlier.  Since y=
ou
used glade your presenter is much simpler than if you had coded it by hand.
You presenter is a very thin wrapper around events which are then delegated
to the view.  I would not suggest having your view register for the events =
- I
would instead have the events propagated to the presenter and then have the
presenter make a call to the view.  Once the view is finished it can make a=
 call
(via the interface) to the presenter.  This causes your presenter to be cou=
pled
with the view but it really simplifies the code over the other alternative.

If you have pop up dialogs I would recommend creating a separate presenter =
class
for each of these.  They should delegate all of their events into the prese=
nter
for your main view which in turn collaborates with your view.

If you take this approach to develop your application you will end up with =
a
GUI application that has unit tests covering all logic.  Also, you will hav=
e a
layered application that is easy to maintain.

--
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomes by it"
    - Jon Ruskin


--=20
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomes by it"
    - Jon Ruskin